CDMA RF Network Optimization Guidebook

Optimization Procedures and Guidelines, Ver. 1.2

Motorola Confidential Proprietary 1

CDMA RF NETWORKOPTIMIZATION GUIDEBOOK

NETWORK SOLUTIONS SECTOR

May 16, 2000

Version 1.2

MOTOROLA CONFIDENTIAL Copyright Motorola 1999

This document and the information contained herein is CONFIDENTIALINFORMATION of Motorola, and shall not be used, published, disclosed, ordisseminated outside of Motorola in whole or part without Motorola’s consent. Thisdocument contains trade secrets of Motorola. Reverse engineering of any or all of theinformation in this document is prohibited. The copyright notice does not implypublication of this document.


Motorola Confidential Proprietary i

Revision History

Date Version Authors Editors Revision3/2/99 1.0 Muhammad Alazari

Jason BurkartRay CarboneJohn CastoniaBrenna HallDennis HelmJonathan HutchesonSandra MartinJay PatelCharles ReismanDwaine Spresney

John CastoniaPaul Venizelos

First Release (withoutChapter 11)

1/27/00 1.1 Jason Burkart Jason Burkart Removal of references toVol.2 and mailto links forJ.Castonia

5/16/00 1.2 Jason Burkart Removal of PRM note forlink to be added (p.29).NSS as author, removedNES.


Motorola Confidential Proprietary ii

TABLE OF CONTENTS

1.0 INTRODUCTION............................................................................................................................. 13

1.1 PURPOSE ......................................................................................................................................... 131.2 ORGANIZATION OF THIS DOCUMENT ............................................................................................... 14

2.0 NETWORK DESIGN VERIFICATION/REVIEW....................................................................... 17

2.1 DESCRIPTION................................................................................................................................... 172.2 TOOLS REQUIRED............................................................................................................................ 182.3 PERSONNEL REQUIRED.................................................................................................................... 212.4 ENTRANCE CRITERIA....................................................................................................................... 212.5 PROCEDURE..................................................................................................................................... 252.6 ANALYSIS CONDUCTED................................................................................................................... 272.7 EXIT CRITERIA ................................................................................................................................ 302.8 RECENT DEVELOPMENTS ................................................................................................................ 30APPENDIX 2A: NEW DEVELOPMENTS IN SIMULATION DOMAIN OPTIMIZATION................................... 31APPENDIX 2B: SAMPLE PROBLEM RESOLUTION MATRIX (PRM)......................................................... 50

3.0 EQUIPMENT INSTALLATION AND TEST ................................................................................ 51

3.1 DESCRIPTION................................................................................................................................... 513.2 TOOLS REQUIRED............................................................................................................................ 523.3 PERSONNEL REQUIRED.................................................................................................................... 523.4 ENTRANCE CRITERIA....................................................................................................................... 533.5 PROCEDURE..................................................................................................................................... 533.6 ANALYSIS CONDUCTED................................................................................................................... 543.7 EXIT CRITERIA ................................................................................................................................ 54APPENDIX 3A: ITP CHECKLISTS............................................................................................................... 55

4.0 DATABASE VERIFICATION ........................................................................................................ 63

4.1 DESCRIPTION................................................................................................................................... 634.2 TOOLS REQUIRED ............................................................................................................................... 654.2 PERSONNEL REQUIRED.................................................................................................................... 664.4 ENTRANCE CRITERIA....................................................................................................................... 664.5 PROCEDURE..................................................................................................................................... 664.6 ANALYSIS CONDUCTED................................................................................................................... 714.7 EXIT CRITERIA ................................................................................................................................ 714.8 RECENT DEVELOPMENTS ................................................................................................................ 71APPENDIX 4A: SHOW_ALLPARMS USAGE ............................................................................................. 72APPENDIX 4B: PROCEDURE TO EVALUATE TRANSCODER PARAMETERS.............................................. 74

5.0 SPECTRUM CLEARING, NOISE FLOOR TEST VERIFICATION, AND NOISEMONITORING........................................................................................................................................... 78

5.1 DESCRIPTION................................................................................................................................... 785.2 TOOLS REQUIRED............................................................................................................................ 805.3 PERSONNEL REQUIRED.................................................................................................................... 805.4 ENTRANCE CRITERIA....................................................................................................................... 805.5 PROCEDURE..................................................................................................................................... 815.6 ANALYSIS CONDUCTED................................................................................................................... 825.7 EXIT CRITERIA ................................................................................................................................ 835.8 RECENT DEVELOPMENTS ................................................................................................................ 83

6.0 TOOLS SELECTION, INSTALLATION, AND TEST................................................................. 86

6.1 DESCRIPTION................................................................................................................................... 866.2 TOOLS REQUIRED............................................................................................................................ 89


Motorola Confidential Proprietary iii

6.3 PERSONNEL REQUIRED ....................................................................................................................... 896.4 ENTRANCE CRITERIA....................................................................................................................... 906.5 PROCEDURE..................................................................................................................................... 906.6 ANALYSIS CONDUCTED................................................................................................................... 926.7 EXIT CRITERIA ................................................................................................................................ 93APPENDIX 6A: TOOLS REFERENCES ........................................................................................................ 94

7.0 SINGLE CELL FUNCTIONAL TEST (SCFT) ............................................................................. 98

7.1 DESCRIPTION................................................................................................................................... 987.2 TOOLS REQUIRED.......................................................................................................................... 1007.3 PERSONNEL REQUIRED.................................................................................................................. 1007.4 ENTRANCE CRITERIA..................................................................................................................... 1007.5 PROCEDURE................................................................................................................................... 1017.6 DATA ANALYSIS PROCEDURES...................................................................................................... 1117.7 EXIT CRITERIA .............................................................................................................................. 119APPENDIX 7B: SAMPLE CALL SAMPLING DATA LOG SHEET.............................................................. 121APPENDIX 7C: SINGLE CELL FUNCTIONAL TEST TRACKING SHEET .................................. 122APPENDIX 7D: .TIM FILE HEADER (DESCRIPTION OF .TIM FILE DATA CONTENTS) ........................... 123APPENDIX 7E: COMPAS IS-95 MESSAGING ACRONYMS.................................................................. 124

8.0 INITIAL COVERAGE TEST........................................................................................................ 126

8.1 DESCRIPTION................................................................................................................................. 1268.2 TOOLS REQUIRED.......................................................................................................................... 1288.3 PERSONNEL REQUIRED.................................................................................................................. 1298.4 ENTRANCE CRITERIA..................................................................................................................... 1298.5 PROCEDURE................................................................................................................................... 1298.6 ANALYSIS CONDUCTED................................................................................................................. 1398.7 EXIT CRITERIA .............................................................................................................................. 142APPENDIX 8.A: SAMPLE DIRECTORY STRUCTURE .................................................................................. 143

9.0 RF NETWORK OPTIMIZATION................................................................................................ 145

9.1 DESCRIPTION................................................................................................................................. 1459.2 TOOLS REQUIRED.......................................................................................................................... 1469.3 PERSONNEL REQUIRED.................................................................................................................. 1489.4 ENTRANCE CRITERIA..................................................................................................................... 1489.5 PROCEDURE.............................................................................................................................. 1489.6 ANALYSIS...................................................................................................................................... 1509.7 EXIT CRITERIA .............................................................................................................................. 188APPENDIX 9A CHANGE REQUEST FORMS AND CHANGE ORDERS ........................................................... 189

10.0 FINAL COVERAGE SURVEY & WARRANTY VERIFICATION..................................... 192

10.1 DESCRIPTION ............................................................................................................................ 19210.2 TOOLS REQUIRED ..................................................................................................................... 19310.3 PERSONNEL REQUIRED ............................................................................................................. 19310.4 ENTRANCE CRITERIA................................................................................................................ 19310.5 PROCEDURE.............................................................................................................................. 19410.6 ANALYSIS CONDUCTED ............................................................................................................ 19610.7 EXIT CRITERIA: ........................................................................................................................ 197APPENDIX 10A.................................................................................................................................... 198

11.0 SYSTEM OPERATIONS .......................................................................................................... 201

11.1 DESCRIPTION ............................................................................................................................ 20111.2 TOOLS REQUIRED: .................................................................................................................... 20311.3 PERSONNEL REQUIRED: ............................................................................................................ 20411.4 ENTRANCE CRITERIA:............................................................................................................... 20411.5 PROCEDURE:............................................................................................................................. 204


Motorola Confidential Proprietary iv

11.6 ANALYSIS CONDUCTED:........................................................................................................... 20611.7 EXIT CRITERIA: ........................................................................................................................ 206

APPENDIX A ROLES AND RESPONSIBILITIES.............................................................................. 210

A.1 WHITE BELT (SYSTEM ENGINEER –ENTRY LEVEL) ....................................................................... 210A.2 GREEN BELT (SYSTEM ENGINEER) ................................................................................................ 211A.3 BLUE BELT (SYSTEM ENGINEER) .................................................................................................. 213A.3 BLACK BELT (SYSTEM ENGINEER)................................................................................................ 214A.4 DIAGNOSTIC MONITOR (DM) OPERATOR ..................................................................................... 214A.5 LANDLINE OPERATOR ................................................................................................................... 215A.6 DRIVER.......................................................................................................................................... 215A.7 BRIDGE OPERATOR ....................................................................................................................... 215A.8 CBSC/SWITCH ENGINEER ............................................................................................................. 215A.9 CFE............................................................................................................................................... 216A.10 DATABASE ENGINEER............................................................................................................. 216A.11 DEVELOPMENT SUPPORT ........................................................................................................ 216

APPENDIX B HARDWARE/SOFTWARE ........................................................................................... 217

APPENDIX B-1: CHECK LIST FOR METRIC OPERATORS ........................................................................... 218


Motorola Confidential Proprietary v

LIST OF FIGURES

Figure 2.1-1: Relationship of Network Design Verification to Entire OptimizationProcess....................................................................................................................... 17

Figure 2.4-1: Design Review Check List (Page 1)........................................................... 23Figure 2.4-1: Design Review Check List (Page 2)........................................................... 24Figure 2.6-1: Simulation Prediction of Coverage Areas .................................................. 28Figure 2.6-2: Final Checklist for System Acceptance Criteria ......................................... 29

64Figure 4.1-1: Relationship of Database Verification Activity to Entire Optimization

Process....................................................................................................................... 64Figure 5.1-1: Relationship of Spectrum Clearing Activity to Entire Optimization Process

................................................................................................................................... 79Figure 5.8-1: Output of banditview script ......................................................................... 85Figure 6.1-1: Relationship of Tools Selection, Installation and Test Activity to Entire

Optimization Process................................................................................................. 87Figure 6.1-2: Tools Overview ........................................................................................... 88Figure 7.1-1: Relationship of Single Cell Functional Test Activity to Entire Optimization

Process....................................................................................................................... 98Figure 7.5.1.1-1: Sample SCFT drive route map for Method 1. .................................... 103Figure 7.5.1.1-2: Sample SCFT drive route map for Method 2 ..................................... 104Figure 7.5.1.1-3: Sample Soft Handoff drive route map................................................. 104Figure 7.5. 2-1: Block Diagram of a Typical CDMA Drive Test Van Setup. ............... 105Figure 7.6.1.2-1: Example of a Browsed CDLLOG (Start) ........................................... 112End of Figure 7.6.1.2-1: Example of Browsed CDLLOG ............................................. 114Figure 7.6.3-1: PN Plot for Site 106, Sector 6: .............................................................. 117Figure 7.6.3-2: PN Plot for Site 106, Sector 1 ............................................................... 118Figure 8.1-1 Relationship of Initial Coverage Test Activity to Entire Optimization

Process..................................................................................................................... 127Figure 8.5.4-1: PMMCC Report ..................................................................................... 134Figure 8.5.4-2: CEM Report ........................................................................................... 1358.5.4-2B Device Outage and Alarm Listing.................................................................... 1368.5.4-2C Alarm Summary ............................................................................................... 137Figure 9.5-1: Overall Optimization Flow....................................................................... 149Figure 9.6.3-1: PN offset plan (text file)........................................................................ 160Figure 9.6.3-2: PN Output Plot in Compas .................................................................... 161Figure 9.6.3-3: NetPlan Path Profile Plot........................................................................ 165Figure 9.6.3-4: COMPAS Plot Illustrating an Overshooting PN................................... 166Figure 9.6.4-1 System Architecture Overview................................................................ 169Figure 9.6.4.2-1: Drive Test Log Sheet to correlate with CFC 9 problem................... 174BROWSE CDLLOG....................................................................................................... 175Figure 9.6.4.2-2: CDL Log Correlating to Drive Team Log Sheet.............................. 175Figure 9.6.5-1: Excerpt from esn.t20 from CAT............................................................ 180Figure 9.6.5-2: Excerpt from esn.t20 for “bad mobile” ................................................. 181Figure 9.6.5-3: Excerpt from call_dur.dst from CAT .................................................... 182


Motorola Confidential Proprietary vi

Figure 9.6.6.1.1-1: Example of Error Window in Compas ............................................. 184Figure 9.6.6.1.1-2: Example of Missing Data ................................................................. 184Figure 10.1-1: Relationship of Final Coverage Survey and Warranty Testing Activity to

Entire Optimization Process.................................................................................... 192


Motorola Confidential Proprietary vii

LIST OF TABLES

TABLE OF URLs ............................................................................................................... 9Table 2.2-1: Candidate Network Planning and Simulation Tools .................................... 19Table 2.2-2: NetPlan Reference Documentation............................................................... 20Table 2.2-3: NetPlan CDMA Static Simulator Documentation........................................ 20Table 2.3-1: Personnel Required...................................................................................... 21Table 2.6.1: Simplified Problem Resolution Matrix for Simulation Prediction ............... 28Table 3.3-1: Personnel Required....................................................................................... 53Table 4.2-1: Database Verification Tools and References................................................ 65Table 4.3-1: Personnel Required....................................................................................... 66Table 5.2-1: Interference Isolation Tools......................................................................... 80Table 5.3-1: Personnel Required...................................................................................... 80Table 6.2-1: Tools Required To Conduct CDMA Optimization Tools Survey ............... 89Table 6.3-1 Personnel Required ........................................................................................ 89Table 6.5.2-1: Sample Tools Evaluation Spreadsheet...................................................... 92Table 6A: Motorola Developed Tools & Products .......................................................... 94Table 7.2-1: Tools Required............................................................................................ 100Table 7.3-1: Personnel Required..................................................................................... 100Table 7.5-1: Tools Required For SCFT Data Analysis.................................................. 102Table 7.5.3.3-1 Channel Verification for 3-sector MCC 16. ......................................... 108Table 7.6.1.2-1: Entry Type Definitions for CDLs ........................................................ 112Table 8.2-1:Tools Required for Initial Coverage Test.................................................... 128Table 8.3-1: Personnel Required..................................................................................... 129Table 8.6.1.1: Relationship Between Number of Pilots Serving an Area and Acceptable

Mobile Receive Signal Strength.............................................................................. 140Table 9.2-1:Tools Required for RF Network Optimization ........................................... 147Table 9.3-1: Personnel Required..................................................................................... 148Table 9.6.3-1: Pilot Analyzer Output .............................................................................. 161Table 9.6.3-2: Data table for Non-Dominant Pilots ....................................................... 163Table 9.6.4.1-1: Drive Team Problem Reports and Likely Causes................................. 170Table 9.6.4.2-1: “Normal” CFC distribution.................................................................. 172Table 9.6.4.2-2: Optimization Problem Troubleshooting Table (start).......................... 176Table 9.6.4.2-2: Optimization Problem Troubleshooting Table (finish) ....................... 177Table 9.6.4.4-1 Problems Seen and Escalation Procedures ............................................ 179Table 10.2-1: Tools Required for Final Coverage Survey/Warranty Verification ......... 193Table 10.3-1: Personnel Required................................................................................... 193

Optimization Procedures and Guidelines, Ver 1.2

9

TABLE OF URLs

URL Description Category Chapter

http://www.cig.mot.com/cdma_ase/index.htmlFor simulations, default parameters listed in [MattDillon’s] release-specific spreadsheets should be used asinputs; choose the link for the target release.

Reference 2,9

http://www.cig.mot.com/TED/docs.htmlNetPlan reference documentation, including the CDMASystem Static Simulator. Follow the steps under "Howto Order Manuals and CD-ROMs".

Reference 2

http://www.cig.mot.com/TED/docs.htmlThe manual “RF Engineering User’s Manual” shows thedifferent images in NetPlan; manual number is68P09245A02-O.

Reference 2

http://www.rochellepark.pamd.cig.mot.com/~blashkar/bestpractices.html

“CDMA RF System Design Procedure” and“CDMA RF Planning Guide” - procedures andguidelines for the network design activity. Select the RFPlanning button.

Reference 2,9


Technical reference documents on the usage of theCDMA System Static Simulator. Select the RF Planningbutton.

Reference 2


“Drive Test Procedures and Xlos Tuning Using DriveTest Data” document. Select the RF Planning button.

Reference 2

http://www.sesd.cig.mot.comNetPlan product group’s home page. Network planningand simulation tool by Motorola.

Tools 2

http://ww.glenayre.com 3rd party network planning and simulation tool. Tools 2http://www.lucent.com/ 3rd party network planning and simulation tool. Tools 2http://www.lucent.com/ page 16 3rd party network planning and simulation tool. Tools 2http://www.msi-world.com/home.html 3rd party network planning and simulation tool. Tools 2http://www.primeco.com/ 3rd party network planning and simulation tool. Tools 2http://www.uswest.com/ 3rd party network planning and simulation tool. Tools 2

Not sure where this will go yetDownload a sample of a Problem Resolution Matrix(PRM).

Tools 2

http://www.safco.com Information on SAFCOs design tool, Wizard. Tools 2http://www.qualcomm.com Candidate network planning and simulation tool. Tools 2http://www.cig.mot.com/TED/Training/training.html Information regarding NetPlan training. Training 2

http://www.cig.mot.com/TED/docs.htmlBTS Optimization/ATP procedure manuals for variousBTS models.

Reference 3

http://www.cig.mot.com/cdma_ase/index.html

http://www.cig.mot.com/Organization/TED/docs.html








http://ww.sesd.cig.mot.com/

http://ww.glenayre.com/

http://www.lucent.com/


http://www.msi-world.com/home.html

http://www.primeco.com/

http://www.uswest.com/

http://www.safco.com/

http://www.qualcomm.com/

http://www.cig.mot.com/Org.new/TED/Training/training.html



10

http://www.cig.mot.com/cdma_ase/index.htmlSpreadsheet containing recommended default parametersettings for each software release.

Reference 4

http://www.cig.mot.com/cdma_ase/index.html Matt Dillon’s ’Parameter and Optimization Guide’. Reference 4

http://www.cig.mot.com/TED/docs.html

Reference to all system commands, their syntax andsample outputs. Click on the hyperlink "Online ProductDocumentation", choose the Supercell button, then theSC Product Family-CDMA button. Click on thehyperlink "OMCR/CBSC/SYSTEM" and then scrolldown to "System Commands Reference".

Reference 4

http://www.pamd.cig.mot.com/nds/cts/rftech/App_Notes/icsho/Tables required for Inter-CBSC Soft and anchor handoffconfigurations. Select the hyperlink entitled“icsho_CAN_v0_1.fm”.

Reference 4

http://www.pamd.cig.mot.com/nds/cts/rftech/App_Notes/icsho/icsho.html#fyis

Where to check for FYI's concerning ICBSC-SHO. Reference 4

http://www.rochellepark.pamd.cig.mot.com/software.htmlScript that graphically displays neighbor lists andvarious parameter settings.

Tools 4

http://www.cig.nml.mot.com/~spresney/Compas_NL/Compas_NL.html

Path to download the script “Compas_NL” whichgenerates a file that can be read into NetPlan so theneighbor list can be displayed graphically.

Tools 4

http://www.pamd.cig.mot.com/~toolprod/falcon Java-based, database visualization tool that providesinsight into the contents of the MIB.

Tools 4


The “show_allparms” script that compares the installedMIB to the recommended default RF parameter settingsand generates a report of the differences. Click on thescripts button and choose the correct version.

Tools 4,10


Procedure for performing noise floor testing entitled“CDMA Uplink Noise Survey Procedure” under the RFPlanning option.

RelatedProcess

5

http://scwww.cig.mot.com/~thakkar/smap.htmlA tool used to detect and isolate noise or interference-induced problems.

Tools 5

http://www.cig.mot.com/ted/EXT_WEB/TED/pdf/english/R7pdf_nof/226A24GO/226A24GO.PDF

Information about the CLI command “browse cdllog” inthe chapter titled “Event Management”.

Reference 6

http://engdb.tlv.cig.mot.com/tools/PilotAnalyzer.htmlTool that is recommended for the RF optimization of aCDMA system. Input is HP Pilot Scanner Data.

Tools 6,9

http://www.cig.mot.com/~spresney/sho_time/sho_time.htmlTool that is recommended for the RF optimization of aCDMA system. Generates neighbor list

Tools 6,9




http://www.pamd.cig.mot.com/nds/cts/rftech/App_Notes/icsho/



http://www.rochellepark.pamd.cig.mot.com/software.html



http://www.pamd.cig.mot.com/~toolprod/falcon





http://scwww.cig.mot.com/~thakkar/smap.html



http://engdb.tlv.cig.mot.com/tools/PilotAnalyzer.html

http://www.cig.mot.com/~spresney/sho_time/sho_time.html


11

recommendations from DM data.

http://www.cig.mot.com/~reimrsrr/NLP.htmlTool that is recommended for the RF optimization of aCDMA system. Generates neighbor listrecommendations from CDLs.

Tools 6

http://www.cig.nml.mot.com/~spresney/CT_neighbor_scripts.htmlTool that is recommended for the RF optimization of aCDMA system. Generates neighbor listrecommendations from scanner data.

Tools 6

http://www.cig.mot.com/~spresney/sho_time/sho_time.htmlAlternate location for “sho_time” tool. Generatesneighbor list recommendations from DM data.

Tools 6,9

http://www.sesd.cig.mot.com/compas/Tool that is recommended for the RF optimization of aCDMA system. Post-processing tool using DM data andSMAP data.

Tools 6

http://www.hp.com/go/drive_test/ Information on the Hewlett Packard pilot scanner. Tools 6http://www.qualcomm.com/cdma/optimization/ Windows based DM from Qualcomm. Tools 6http://www.qualcomm.com/cda/technology/display/0,1476,1_21,00.html

A listing of CDMA licensed suppliers from Qualcomm. Tools 6

http://www.rsd.de/produkt/215a.htm Information about a DM from Rohde & Schwarz, Inc. Tools 6

http://www.rsd.de/produkt/tm_mob.htmAlternate location for information about a DM fromRohde & Schwarz, Inc.

Tools 6

http://www.tmo.hp.com/tmo/datasheets/English/HPE7472A.htmlHewlett Packard E7472A CDMA Integrated RF and callperformance coverage test system.

Tools 6

http://www.global.anritsu.com/products/test/rfmicrowireless/MT8802A.html

Information regarding Anritsu Company (RadioCommunication Analyzer).

Tools 6

www.grayson.comInformation about Grayson’s wireless PN scanner andwireless analyzer.

Tools 6

http://www.rochellepark.pamd.cig.mot.com/software.htmlScript to install PM reports based on PM statisticsgenerated on the OMCR.

Tools 6

http://www.safco.com3rd party tool that may be considered as a candidate forvarious optimization activities.

Tools 6

http://www.cig.mot.com/~reimrsrr/NLP.html

http://www.cig.nml.mot.com/~spresney/CT_neighbor_scripts.html


http://www.sesd.cig.mot.com/compas/

http://www.hp.com/go/drive_test/

http://www.qualcomm.com/cdma/optimization/

http://www.qualcomm.com/cda/technology/display/0,1476,1_21,00.html

http://www.qualcomm.com/cda/technology/display/0,1476,1_21,00.html

http://www.rsd.de/produkt/215a.htm

http://www.rsd.de/produkt/tm_mob.htm

http://www.tmo.hp.com/tmo/datasheets/English/HPE7472A.html



http://www.grayson.com/




12

http://scwww.cig.mot.com/SC/mgmt/tools/CDMA/Test_Tools/CAMPS/index.html

Information about CAMPs DM which collects mobilephone data and GPS position data.

Tools 6, 7

http://www.cig.mot.com/~wheelrts/analyzer.htmlInformation on the CDL Analysis Tool and path todownload script to install.

Tools 6, 7, 9

http://www.cig.mot.com/~klnknbrg/r5cfcdocument.htmlCall processing sequences, including call set ups forboth originations and terminations.

Reference 7

http://www.cig.mot.com/~wheelrts/analyzer.htmlExplanation of the reports/files created by the CDLanalysis tool.

Reference 7, 9

http://www.safco.com/measurement/walkabout.html Information about SAFCOs DM. Tools 7

http://www.cig.nml.mot.com/cdma/kctopt/tools/A Motorola tool capable of viewing a PN plot within theCOMPAS tool. Select “PN Plot” from the “Tool Box”.

Tools 7

http://www.trimble.comTrimble GPS information. Required to supplytime/location data for each DM.

Tools 7

http://www.cig.mot.com/Organization/TED/Documentation/Tools/tools.html

Information about COMPAS. The document number isCOMPAS3.2 – 68P09248A05-A

Tools 7


Auto Dial, call termination script. Tools 8

http://www.cig.mot.com/~thakkar/smap.html. SMAP installation and configuration notes. Tools 8,10

http://scwww.cig.mot.com/~thakkar/smap.htmlSMAP installation and configuration notes for OCNSforward link loading.

Tools 8,10

http://scwww.cig.mot.com/people/cdma/PjM/product/release_info/Product Release information Reference 8

http://www.cig.mot.com/~dillon/Reference material regarding how to diagnose and solveproblems.

Reference 9

http://scwww.cig.mot.com/people/cdma/PjM/product/release_info/Information regarding specific releases. Reference 9http://scwww.cig.mot.com/~thakkar/smap.htm Reverse link messaging tool. Tools 9

http//www.rochellpark.pamd.cig.mot.com/software.htmlPMSUM suite of scripts combines the most widely usedPM reports into four reports for easy usage. Select the“pmsum” section on the web page.

Tools 9

http://www.cig.mot.com/~reimrsrr/SOS.html SOS script looks at the mobile messaging Tools 9

http://www.cig.mot.com/standards/CDMA_STDS/TIA_CDMA_STDS.html#ai

IS-95 and TIA/EIA-95 specifications Reference 9

http://www.rochellepark.pamd.cig.mot.com/~dhelm/Path to download “ASSIST” script that is run on the*.map files created by COMPAS; choose the link titled“RF Warranty Tools Page”.

Tools 10



http://www.cig.mot.com/~wheelrts/analyzer.html

http://www.cig.mot.com/~klnknbrg/r5cfcdocument.html


http://www.safco.com/measurement/walkabout.html

http://www.cig.nml.mot.com/cdma/kctopt/tools/

http://www.trimble.com/



http://merchant.hibbertco.com/pub/pubprd/bud.html?DocNumber=68P09248A05&Suffix=A



http://www.cig.mot.com/~thakkar/smap.html


http://scwww.cig.mot.com/people/cdma/PjM/product/release_info/

http://www.cig.mot.com/~dillon/


http://scwww.cig.mot.com/~thakkar/smap.htm

http://www.cig.mot.com/~reimrsrr/SOS.html



http://www.rochellepark.pamd.cig.mot.com/~dhelm/

Optimization Procedures and Guidelines, Ver 1.2Introduction

13

1.0 Introduction

1.1 PurposeThe purpose of this document is to consolidate and provide CDMA RF networkoptimization engineers with the necessary information to optimize a CDMA system.This guidebook frequently refers to other reference materials, providing the necessarylinks to useful web sites, both internal and external to Motorola, as the intent of this is notto reinvent any work already completed.

To begin planning for the optimization process, the market manager and/or leadoptimization engineer should determine the resources available and the resources neededfor each step of the process. There is a deployment plan template found athttp://www.rochellepark.pamd.cig.mot.com/~blashkar/bestpractices.html, click on theProject Planning button, click on the link “CDMA Project Plan IDP Template” and thenon the link “CDMA Project Plan Template v5”. This template will walk the marketmanager through each step of planning the project and will provide general guidelines onthe number of resources needed for each step.

The network optimization process focuses on getting the network ready for commerciallaunch. Typically, this testing is done under an unloaded condition. Primary objectivesof network optimization are to identify and eliminate any hardware and databaseimplementation errors and arrive at a set of “optimal” operating parameters andequipment settings (e.g. antenna tilts, azimuths, and SIF power settings) to provide an“acceptable level of performance”. That acceptable level of performance can bespecified and measured in terms of a combination of any of the following:

- coverage area: measured in terms of Mobile Receive Power, adequate Ec/Io,and/or Mobile Transmit Power, and/or

- voice quality criteria: measured in terms of Frame Erasure Rate (FER) on theforward and/or reverse links, and/or

- target call completion and call drop rates

Specific targets such as those listed above for acceptable levels of performance aremandated by the contract. Market managers and the lead system engineer of theoptimization team should thoroughly review the contract and know the deadlines andpenalties. They should also have a copy of the contract for reference.

In most instances, customers will want to compare the coverage of the deployed networkto the original predicted coverage generated with a network-planning tool. Portions ofthis optimization process are iterative, collecting and analyzing drive test data toconverge to an optimal set of operating parameters.

Much of the material in this document will be very familiar to practicing optimizationengineers, and many engineers may have in fact already contributed to previous, similardocuments. What this guidebook focuses on is coordinating and cross-referencing the



14

wealth and diversity of information from various departments and markets, ranging frombasic optimization processes to discussion of more “advanced” product features (e.g.multi-carrier). Each update will attempt to standardize the optimization practice, capturerecent developments in optimization practices and strategies in various markets, andpresent and discuss recent tool developments – as reported back by the readers and usersof this document.

References to recent developments in the area of network optimization are contained inshaded boxes in this document.

1.2 Organization of this DocumentOptimization Procedures and Guidelines, discusses the optimization process (what needsto be done), and provides guidelines (entrance and exit criteria) for each step in theprocess. Where possible, tools to support each activity are introduced and analysismethods are discussed. The organization of this document follows the structure laid outin Figure 1.2-1, Overview of Network Optimization Activities. Emphasis is given toChapters 6 through 10, and new developments affecting optimization in other areas.

Following along with Figure 1.2-1, a description of the contents of each chapter isprovided.

Chapter 2: Network Design Verification: Familiarizes the optimization engineer with thenetwork design conducted to date. Identifies and documents predicted problem locations.

Chapter 3: Equipment Installation And Test Verification: Facilitated coordinationbetween the optimization engineering team and CFE crews to verify that the BTSs foreach cluster are operational and properly integrated with the CBSCs prior to start ofsingle cell functional test.

Chapter 4: RF Parameters Database Verification: Checks all RF related parameters,neighbor lists and supporting tables, and transcoder parameters.

Chapter 5: Spectrum Clearing: Ensures that the spectrum in the area of network operationstays adequately cleared during network optimization activities. Focuses on use ofalarms and mobile data to identify noise rise conditions.

Chapter 6: Data Collection and Analysis Tools Selection, Install, Test: Guidelines forselection and implementation of optimization tools for a specific market. Includesreferences to Motorola and third party vendor tools. Data collection tools include mobilediagnostic monitors (DM), pilot analyzers, System Monitoring Application Processor(SMAP), Call Detail Logs (CDLs), PM Data. Data analysis tools include COMPAS,OPAS, CAT (CDL Analysis Tool), PM Reports and scripts to be executed at theCBSC/OMC-R.

Chapter 7: Single Cell Functional Test: Use of a mobile diagnostic monitor (DM) and testphones to generate test calls. Specifies drive route definition, pre-departure checks, data


15

collection, and data analysis procedures using both CDLs and DM (mobile messaging)data.

Chapter 8: Initial Coverage Test: Makes use of an initial coverage test in each cluster tobaseline system performance and to identify problems. Problems are recorded in aProblem Resolution Matrix (PRM) which will be used during the system optimizationprocess to track progress and communicate issues to the customer.

Chapter 9: System Optimization And Detailed Problem Resolution: After each cluster’sperformance has a baseline establish, optimization and detailed problem resolution withineach cluster can proceed until the “acceptable level of performance” is achieved. Thischapter discusses the use of data and analysis tools used during the system optimizationprocess. The intent of the optimization process is to isolate and resolve all of the issuesthat will impact the overall quality of the CDMA system. This may also include “inter-cluster”, “inter-CBSC”, and “inter-EMX” handoff issues.

Chapter 10: Final Coverage Survey and Warranty Testing: Presents information for thefinal performance drive and simultaneous collection and processing of adequate data todemonstrate satisfactory compliance to contractual or warranty clauses.

Chapter 11: System Operations: Chapter 11 covers network performance monitoring andexpansion. The bulk of this material is covered in a separate, companion document, butis introduced here in the context of the Friendly Users trial. The primary benefits of thisFriendly User trial are the additional identification of faulty hardware throughout thenetwork, and reports from customers identifying problem areas that may not have beentraversed during the original optimization.


16

Network Design Verification(Chapter 2)

Spectrum Clearing(Chapter5)

Optimization Preparation

Single CellFunctional Test

(Chapter 7)

Initial CoverageTest

(Chapter 8)

Network Optimization

Equipment Installationand Test Verification

(Chapter 3)

RF ParametersDatabase Verification

(Chapter 4)

Data Collection andAnalysis Tools

Selection, Install, Test(Chapter 6)

System Optimization andDetailed Problem Resolution

(Chapter 9)

Final CoverageSurvey and

Warranty Testing(Chapter 10)

System Operations(Chapter 11)

Commercial Service:Network Performance

Monitoring and Expansion(Chapter 11)

Accurate Terrain,Clutter,Xlos Tuning Data

System Designvia

NetPlan/CSSS

Figure 1.2-1: Overview of Network Optimization Actives

Optimization Procedures and Guidelines, Ver 1.2Network Design Verification/Review

17

2.0 Network Design Verification/Review

2.1 DescriptionThe initial network design activity employs simulation tools, such as NetPlan, andfollows specific system design planning guidelines to predict and assess networkperformance based upon placement of BTS locations across a network coverage area.Figure 2.1-1 shows that this process is actually the first step of the optimization cycle.The optimization team should participate in the system design review of this simulationwork to help orient the team to potential problems predicted by the simulation tool.





(Chapter 3)


(Chapter 4)




(Chapter 9)







System Designvia

NetPlan/CSSSSpectrum Clearing

(Chapter5)


(Chapter 7)


(Chapter 8)

Figure 2.1-1: Relationship of Network Design Verification to Entire OptimizationProcess


18

The primary objective of the design review is to evaluate the system design to ensure thatit meets customer requirements for coverage and capacity, and to generate an initialassessment of where problems may be encountered in the deployment and RFoptimization of that system. Many times this activity is coupled with contractualwarranty development. Since the skill set required to do a system design using NetPlan(or other tools) is fairly specialized, it is very infrequent that the optimization engineer isthe same person as the simulation guru. The design review provides an opportunity tocommunicate critical network design issues to the optimization team. It is desirable tomaintain and use this simulation work throughout the system optimization process. Thenetwork planning tools should be used to play the “what if” games necessary to evaluateproposed changes intended to improve coverage or resolve other RF related issues. Suchchanges may include antenna pointing angles and SIF pilot powers.

The procedures and guidelines for the network design activity are beyond the scope ofthis chapter; however, they are contained in the following documents:

CDMA RF System Design ProcedureCDMA RF Planning Guide

Both of these documents can be found by selecting the RF Planning button athttp://www.rochellepark.pamd.cig.mot.com/~blashkar/bestpractices.html. Follow thedirections for downloading or ordering a bound copy on this web site.

Recent developments in the area of improving simulation accuracy include a new “auto-optimizer” tool. This is documented in Section 2.8 and Appendix 2A of this chapter.

2.2 Tools RequiredTable 2.2-1 contains a list of candidate network planning and simulation tools along withsources of data (i.e. clutter, terrain, etc.) that would be used by these tools. Only one isrequired to plan and simulate a CDMA system. The Motorola tool is NetPlan. Forinformation on the NetPlan tool, see the NetPlan product group’s home page athttp://www.sesd.cig.mot.com. “NetPlan is designed to assist engineers in optimizing andimplementing wireless networks by providing an accurate and reliable prediction ofcoverage. With a database that takes into account data such as terrain, clutter, antennaradiation patterns, and traffic modeling, as well as an intuitive graphical interface,NetPlan gives RF engineers a state-of-the-art tool to estimate RF propagation, designwireless networks, plan network expansions, optimize network performance, anddiagnose system problems.”1 There is also a specialized CDMA System Static Simulator(CSSS).

Regarding NetPlan, Table 2.2-2 contains information on reference documentation for thisMotorola tool, including the CDMA System Static Simulator. These documents may beordered from the TED web site at http://www.cig.mot.com/TED/docs.html. Follow thesteps under "How to Order Manuals and CD-ROMs".

1 Description of NetPlan taken from the web page.


http://ww.sesd.cig.mot.com/



19

Tool Name Description and VendorSOFTWARE:

NetPlan Propagation Engineand NetPlan CDMA StaticSystem Simulator (CSSS)

The NetPlan application automates many cellularsystem planning and analysis functions. Orderinginformation can be found athttp://www.sesd.cig.mot.com/order.html.

Informix (required byNetPlan)

Database Software, Informix

Auto Optimizer Tool – NEWFeature Request # 00019504(uses output of NetPlan)

Automated tool that uses predictive methods tooptimize any combination of antenna azimuths,downtilts, and/or pilot powers in a CDMA system. Tooland users manual by Charles Reisman. See Appendix2.A for a copy of the Users Guide and an email of betatest results.

CellCAD Simulation Tool, More information can be obtainedfrom LCC, 7925 Jones Branch Drive, McLean, VA22102, USA. Phone: (703) 873-2000

CE4 DOS Simulation Tool. More information can beobtained from Lucent's web site at,http://www.lucent.com/.

Cell Designer Simulation Tool. For more information, see the websites for USWest or Primeco athttp://www.uswest.com/ or http://www.primeco.com/.

Planet Simulation Tool, More information can be found at theMSI web site:http://www.msi-world.com/home.html.

QEDesign Simulation and Planning Tool, See the Qualcomm website for more information at http://www.qualcomm.com.

WiNGS Simulation Tool, More information about Glenayre andtheir products can be found at http://ww.glenayre.com.

Wizard Simulation Tool, Information on SAFCOs design toolcan be found at http://www.safco.com.

Motorola, Inc., GIS & RemoteSensing Center of Excellence

Source of input data (clutter, terrain, road networks,etc.). More information can be found on their web pageat http://www.imd.cig.mot/rm/gis.html.

CRC Reserch Institute, Inc.2-7-5, Minamisuna, Koto-ku,Tokyo 136

Source of input data (clutter, terrain, road networks,etc.) for Japan.

Table 2.2-1: Candidate Network Planning and Simulation Tools

Name Order Number OverviewBasic Concepts User'sGuide

68P09245A01-O Combines reference information withprocedures for using NetPlan.

http://www.sesd.cig.mot.com/order.html


http://www.uswest.com/

http://www.primeco.com/

http://www.msi-world.com/home.html

http://www.qualcomm.com/

http://ww.glenayre.com/


http://www.imd.cig.mot/rm/gis.html


20

RF Engineering User’sManual

68P09245A02-O Explains the different elements of NetPlan andhow they are used.

Hardware/SoftwareInstallation Guide

68P09245A04-O Describes how to install and configure NetPlanhardware and software on HP and Sun systems.

Data Formats andConversion Guide

68P09245A07-O Describes file formats and how to use theconversion utility programs.

Tutorial 68P09245A08-O Provides quick, hands-on introduction toNetPlan.

System AdministrationGuide

68P09245A03-O Intended to provide NetPlan SystemAdministrators with information and proceduresnecessary for effective and efficientmaintenance of the NetPlan system.

CDMA Static SystemSimulator User’s Guide

68P09245A09-O Operator’s manual for the CDMA Static SystemSimulator feature of NetPlan.

New Features and ReleaseNotes

68P09245A06-O Overview of the new features andenhancements of NetPlan.

Table 2.2-2: NetPlan Reference Documentation

Technical reference documents on the usage of the CDMA System Static Simulator arelisted in Table 2.2-3 and can be found by choosing the RF Planning button athttp://www.rochellepark.pamd.cig.mot.com/~blashkar/bestpractices.html

Document Name Author Overview"NetPlan 3.0 CDMASimulator: A TechnicalOverview"

Ashish Kaul This document will provide atechnical overview of the keyfeatures, components and outputs ofthe CDMA simulator in NetPlan.

"ISI Settings within NetPlan3.0CSSS"

Bob Love/Jim Panwell ISI Settings within NetPlan 3.0 CSSS

"T_ADD/T_DROP CSSSSettings vs. Field Settings"

Bob Love/Jim Panwell T_ADD/T_DROP CSSS Settings vs.Field Settings

Table 2.2-3: NetPlan CDMA Static Simulator Documentation

Finally, additional information can be obtained, and specific questions can be answeredabout the NetPlan family of tools (NetPlan, CSSS, and COMPAS) by subscribing to theNetPlan posting group. Put any of the following messages in the main body of an email

subscribe np-prod subscribe np-cdma subscribe np-compas

and send the message to the following email address to subscribe (as desired):Email address: [email protected]



21

2.3 Personnel Required

Type Skill LevelRF System Engineer White Belt (See Appendix A)

Table 2.3-1: Personnel Required

Special training is required for personnel conducting the system design activity.Motorola provides comprehensive training classes on the NetPlan Tools that are offeredby the Technical Education and Documentation Center (TED).

The class numbers and names are:PER 300 NetPlan 3.1PER 310 CompasPER 130 NetPlan CDMA (for the Static Simulator)

Upon completion of these NetPlan courses, students are capable of using the NetPlan RFplanning tool in cellular system planning, design, and optimization. TED can becontacted at 1-847-435-5700 or at http://www.cig.mot.com/TED/Training/training.htmlfor course dates and availability.

2.4 Entrance CriteriaIn order to start the design review the following activities should be completed as part ofthe system design activity:

1. NetPlan Tool Installation

Before the NetPlan tool can be used, certain tasks must be completed. It isassumed that the system administrator tasks have been completed. Users will entera basic system plan, where they will need to know the number of switches neededto handle traffic in that area and the number and type of sites needed to handletraffic in that area. Configurators are available for various products to help the userplan the system. The configurators and “read_me” files can be found athttp://www.acpg.cig.mot.com/w3/apd/PIOI/new/configurator.html.

For more information, see "NetPlan RF Planning Tool, Student Guide" availablefrom the NetPlan 3.1 class offered by TED. See the TED web page forinformation on when the course is available and how to register.

2. Network Planning Data

A. Prior to the design of a CDMA system, network planning information such aspropagation parameters, subscriber profile, call model (busy hour call completion,Erlangs per subscriber, average hold time per access), terrain data, and landuse/land clutter data, should all be available or estimated in adequate fidelity andresolution to properly represent the network to be simulated. [NOTE: Anysimulator will suffer from the “garbage in Í garbage out” syndrome. Therefore it

http://www.cig.mot.com/TED/Training/training.html

http://www.acpg.cig.mot.com/w3/apd/PIOI/new/configurator.html


22

is critical to ensure that the data is as accurate as possible.] Settings of importantparameters and tips on how to address them during system design are listed in the"CDMA RF Planning Guide".

B. When simulating the system, the default parameters listed in [Matt Dillon’s]release-specific spreadsheets should be used as inputs. These spreadsheets can beobtained from http://www.cig.mot.com/cdma_ase/index.html, choose the link forthe target release.

3. Propagation Model Tuning Using XLOS Data

Data should be collected through drive tests to improve the accuracy of (orcalibrate) the NetPlan Xlos propagation model. For information on conductingthis drive test, verifying the drive test data, and then using the drive testmeasurements to tune the NetPlan Xlos model see "Drive Test Procedures andXlos Tuning Using Drive Test Data" found by selecting the RF Planning buttonlocated athttp://www.rochellepark.pamd.cig.mot.com/~blashkar/bestpractices.html.

4. Design Outputs should be available.

These are listed below in Figure 2.4-1, in the form of a Design Review Checklist.The items in this checklist should be available for review during the design review.




23

Figure 2.4-1: Design Review Check List (Page 1)

Coverage Area (as defined by Customer)

______ Image/Map indicating the Desired Coverage Area

______ Identification of critical regions within Desired Coverage Area

Rx Link Budget

______ Link Budget(s) used for Rx Pathloss Coverage Plot. Should be supplied on aper site/sector basis if there is variation in antenna gain, line loss from site to site andsector to sector.

______ Calculations of NetPlan Rx “ERP” and system level cutoff.

NetPlan Pathloss Plots

______ Most likely Server image

______ Receive Voice Power image “coverage” (unloaded)

______ Coverage Exclusion Mask image (if used)

______ Clutter image (optional)

______ Virtual Obstruction Heights (if not standard)

______ Elevation image (optional)

______ Propagation boundaries

Cell Configuration –data/site/sector

______ Antenna Configuration: type, height, bore, tilt, gain, beam, width, ERP, eff,gain, cell Noise Figure and ambient noise.

______ Antenna pattern modifications (if used)

______ Pilot _____ Page _____Sync ______ T_ADD

______ Tch_Max _____ Tch_Min ______ T_DROP

NetPlan CDMA Simulation Parameters:

______ Complete printout of the Basic and Advanced CDMA parameters.


24

Figure 2.4-1: Design Review Check List (Page 2)

Simulation Images:

______ Best Ec/Io ______ Best Ec/Io Server/Sector

______ Soft Handoff State ______ Forward required Power

______ Reverse Required Power

BBN Cornerstone Statistics /Sector (50-200 drops):

______ NumMob ______ Links ______Rise

______ MobGood/NumMob ______Soft Handoff Factor

______ Total Forward Power

Traffic specific information

______ Traffic distribution image ______ # Mobiles

______ Weighting specifics of clutter /roadways, etc.

______ Traffic exclusion Mask image (if used)

ISI Information (for 800 MHz systems <1:1 deployment)

______ AMPS only site cell data with ERP used

______ CDMA images with and without presence of ISI

Neighbor List

______ Not used ______ Used and applied at the end of optimization

Other general Information:

______ Where is D/A handoff region defined


25

2.5 ProcedureEach of the items in the Design Review Check List should be evaluated with emphasisgiven to learning about the system design and identifying any problem areas.

2.5.1 Review of Propagation Model Tuning

Validation procedures to tune the Xlos propagation model are found in the manual "DriveTest Procedures and Xlos Tuning Using Drive Test Data" by selecting the RF Planningbutton located athttp://www.rochellepark.pamd.cig.mot.com/~blashkar/bestpractices.html.The usage of these procedures should be reviewed, and reasonableness checks for theNetPlan Pathloss Plots should be conducted.

2.5.2 Review of NetPlan Inputs

The simulator inputs should be reviewed to assess their accuracy and resolution. Theinput items listed in Figure 2.4-1, Design Review Check List, consisting of CoverageArea Definition, Rx Link Budget, Cell Configuration Data, and NetPlan CDMASimulation Parameters should be reviewed.

2.5.3 Review of NetPlan Image Outputs

Reference material on NetPlan Simulator Statistical Output and Analysis, NetPlanCell/Mobile Analysis, and NetPlan Simulator Images Output and Analysis can be foundin "CDMA RF System Design Procedure".

NetPlan will create a variety of images that quantify various predicted performances ofthe network. Since it is important for the system optimization team to understand thesystem design to help guide optimization activities, the images listed below should beexamined during the design review. The following images should be inspected todetermine any basic design issues:

1. Site Propagation Images:

A. Best Signal Strength (Ec/Io): This is the best signal strength of the bestserver/sector. For each point in the image, the best signal strength is the signalstrength of the strongest sector. A coverage report is also included.

B. Best Server/Sector: This will show which site or sector is the best server for agiven area on a site-by-site or sector-by-sector basis. The best server is the sectorwith the strongest signal strength at that position. A coverage report and a sectorboundary image are included.

C. Forward Required Power: At each geographic bin, this image displays the trafficchannel power required to be transmitted by the best serving sector/site (asdisplayed in Best Ec/Io Server/Sector image) to make the forward link with theprobe mobile placed in that bin successful. Locations in the system that do not



26

have any Best Ec/Io Server/Sector are assigned 70 dBm value by default and binsoutside the Combined Image boundary are assigned the value of 100 dBm.

D. Reverse Required Power: The Reverse Required Power image displays the truepower required to close the reverse link. If the reverse required power exceeds themaximum power the mobile can transmit, this will create a coverage problem onthe reverse link. At each geographic bin, this image displays the traffic channelpower required to be transmitted by the probe mobile to close the reverse linkwith the best serving sector/site (as displayed in Best Ec/Io Server/Sector image)successful. There have been occurrences of locations in the system that do nothave any Best Ec/Io Server/Sector being assigned a default value of 100 dBmlink.

*Note: Comparison of forward and reverse required powers mayindicate some disparity in the link budget on the forward and reverselinks. Diversity receive antennas may be situated more optimally thansingular downtilt antennas creating differences in coverage patterns forforward and reverse links. The height of the transmit vs. the receiveantennas can also have an impact on coverage patterns. The engineershould also know the antenna type(s) as well as the tilts on both the Txand Rx antennas.

2. Interference Images (High FER Areas):

A. Worst Interferer: This image will show which site or sector provides the strongestinterfering signal.

B. Single C/I: This shows the carrier to interferer ratio for the best sector and thestrongest interferer.

C. Multiple C/I: Multiple C/I images show the carrier to interference ratio betweenthe best sector and all interferers. A negative number means that the sum of theinterferers is stronger than the carrier.

3. Delta Images (Difference between the values in any two images of the same type.)

A. Best Server/Sector Delta: This compares two Best Server/Sector images. Theimage shows points that are in image 1 but not image 2, points that are in image 2but not in image 1, points that have the same value in both images, and points thathave different values in the two images.

B. Signal Strength Delta: This image compares two signal strength images, eitherantenna signal strength images (site propagation images) or Best Signal Strengthimages. Points in the image show the difference between the signal strengths inthe images being compared.

C. C/I Delta: This will compare two C/I images. Points in the image show thedifference between the carrier to interferer ratios of the images being compared.


27

2.5.4 Review of PN Offset Plan

A PN Offset Plan should be reviewed during the design review. A comprehensivediscussion on PN Offset Planning and Search Windows can be found in the “CDMA RFPlanning Guide”.

2.5.5 Neighbor List Review

An understanding of how neighbor lists were used in the simulation environments shouldbe developed by the optimization team members. For more information on review ofneighbor lists, see Chapter 4 (Database Verification).

2.6 Analysis ConductedThe primary analysis centers on understanding any network designissues. These issues may include but not be limited to missing sites,interference, inaccurate or sub-optimal placement of sites by thecustomer. These issues should be captured in a Problem ResolutionMatrix (PRM). The PRM will be used later in the optimizationprocess to track performance issues. Entry of specific problem areas(into the PRM) predicted by simulation work can guide optimizationteams so that they do not waste time focusing on known problemareas. The PRM should clearly capture the rationale why there maybe sub-optimal performance in various areas of the desired coveragearea. An example may be zoning laws, which could restrict thelocation of a site or the height of an antenna.

Using the images, a PRM can be generated. For more information on the differentimages in NetPlan, please see the manual “RF Engineering User’s Manual”, manualnumber 68P09245A02-O. This can be ordered from the TED web site athttp://www.cig.mot.com/TED/docs.html. Follow the steps under "How to Order Manualsand CD-ROMs".As a very simple example, perhaps the simulation tool predicted the following, as shownin Figure 2.6-1, based upon the input to the design process:

Covered area

Missing Site

Pathloss

Interference

No coverage desired�

�

�

�

��



28

Figure 2.6-1: Simulation Prediction of Coverage Areas

Given this scenario, a simplified corresponding PRM may look like Table 2.6.1 below:

TrackingNumber

Description Cause ProblemDate

ResolutionDate

Status/Possible Fix(es)

1 No coverage Site 101missing

1/21/99 Waiting for equipment

2 No coverage/path loss

Ridgeblockingantenna

1/21/99 Raise antennas

3 Interference MultiplePilots

1/21/99 Confirm in field andcreate dominance

4 No coverage Site 122missing

1/21/99 Awaiting zoningapproval

5 Interference Sites 132,144 too hot

1/21/99 Confirm in field; lowerpilots of 132, 144

6 No coverage/path loss

Sites 145 and148 too farapart

1/21/99 Confirm in field; changeor raise antennas, orincrease pilot power

Table 2.6.1: Simplified Problem Resolution Matrix for Simulation Prediction

A more detailed PRM example is included in Appendix 2B.Finally, in addition to the problems captured above, the system design must meet theintent of the contract. A final checklist, as shown below in Figure 2.6-2, should be usedto determine if the simulation will produce a system that will meet the contractualcommitments.


29

System acceptance Criteria (check if met)______ ngmob/nmob >95% system mean

______ ngmob/nmob >90% any individual cell/sector

Description of Rx Coverage

______ Good

______ Moderate / Poor –problems may be due to

_______ Terrain/Clutter limitations______ Cell Configuration

Description of Simulation Coverage

______ Good

______ Moderate / Poor –problems due to:

______ Terrain limitations ______ ISI

______ Multipath pilots ______ High traffic

Description of coverage variations compared to Pathloss only study:

_____ More CDMA coverage ______ Less CDMA coverage

Overall assessment

______ Pass-Proceed with implementation

______ Recommended Changes need to incorporated and followed by another Designreview

Detailed Assessment: (attach documents providing additional detail if required)________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Figure 2.6-2: Final Checklist for System Acceptance Criteria


30

2.7 Exit Criteria- Propagation model tuning was adequate.- The target release default parameters were used as inputs to the system design.- Different inputs were used and the different effects were compared. The design

verification team reviewed images.- A preliminary neighbor list has been generated and handed off to the person(s)

responsible for creating the MIB.- A valid PN Offset Plan has been designed.- An initial PRM has been completed.- The system design meets the customer requirements.

2.8 Recent DevelopmentsAppendix 2A shows results of an auto-optimizer tool that is used in conjunction withNetPlan/CSSS. This auto-optimizer tool focuses on converging to a set of antennaazimuth and tilt angles and BTS SIF pilot powers. This tool has been successfullydemonstrated to provide improvements in performance in CDMA systems in Sapporoand Osaka, Japan (both DDI systems), and Curitiba, Brazil (Global Telecom). Thisutility is currently being tracked as Feature Request (FR number 00019504) forincorporation into NetPlan. [Note: This new auto-optimizer tool is not the same as thepreviously tested “auto-pilot optimizer” tool previously investigated. The new tool alsohas the advantage of included antenna angle optimization as part of its routine.]


31

APPENDIX 2A: New Developments In Simulation DomainOptimization1. Email from Charles Reisman Outlining the Auto-Optimizer Test Results

Subject: KCT and DCT Antenna Downtilt Change Test ResultsDate: Mon, 02 Nov 1998 18:26:09 +0900From: Charles Reisman

I would like to thank everyone for your cooperation with the antenna downtilt testingwhich has been performed in Sapporo and in KCT.

The Sapporo area (DCT) downtilt testing has been completed, analyzed, and presented tothe customers, and the first problem location within the KCT system has also been testedand analyzed. I would like to take this opportunity to summarize the results and alsoconvey the customer reactions (in the case of the DCT testing).

I’d like to start with the KCT testing. This testing focused on the area between andimmediately around sites 89, 114, and 514, where simulations predicted a significantcoverage hole (This area was called Problem Location 2 in previous mails.). The areawas first driven with the existing tilts in order to establish a baseline, and then 7 sectors’antennas were uptilted and the area was redriven.

The following table shows a before/after comparison of the KCT results:

Type of Data BEFORE AFTERAvg. Forward FER 1.2% 1.0%Avg. Best Ec/Io -7.1dB -6.9dBAvg. Aggr. Ec/Io -5.3dB -5.2dBAvg. Mob Tx Power -18.6dBm -21.5dBmAvg. PMRMs per minute 9.2 8.5% of Data where Mob Tx Pwr >= 10dBm 0.0% 0.0%% of Data where Mob Tx Pwr >= 17dBm 0.0% 0.0%% of Data where Fwd FER >= 10% 1.7% 1.8%% of Data where Fwd FER >= 20% 0.7% 0.4%% of Data where Fwd FER >= 30% 0.5% 0.2%% of Data where Best EcIo <= -13dB 0.6% 0.2%% of Data where Best EcIo <= -15dB 0.4% 0.1%% of Data where Agg EcIo <= -10dB 1.0% 0.5%% of Data where Agg EcIo <= -12dB 0.5% 0.1%

It’s especially noteworthy that the average forward FER dropped (i.e. improved) byalmost 20%. In addition, the quantile data shows that the percent of area with very highFER (>= 20%, >= 30%) was greatly reduced by the downtilt changes. This shouldmanifest itself to the end users in improved voice quality. Furthermore, the nearly 3dB


32

reduction in mobile transmit power will equate to improved battery life, and the reductionin PMRMs will likely translate to slightly reduced average transmit power levels at thebase stations. Although not shown in the above table, the results also showed slightreductions in the channel element SHO factor and call processing messaging rates (e.g.,PSMMs, EHDMs, HCMs). From this, we can conclude that the customer will also beable to get more out of the infrastructure (i.e., fewer channel elements required andgreater MM capacity) as a result of the downtilt changes.

In summary, this test was an all out success. We definitely should continue this testing,and I hope that the other predicted problem areas show similar improvements. I am notsure whether or not these results have been presented to DDI and KCT. If they haven’tbeen, then it would probably be best to present them soon.

The DCT experimentation showed similar results to the KCT testing, although thebaseline drive (which was based on PDC downtilts) showed comparatively betterperformance than the KCT baseline did. The Sapporo test drive area was significantlylarger than that of the KCT testing, and along with specific areas which got better therewere also specific areas that got worse (e.g., in terms of forward FER).

The following table summarizes the major results from the DCT testing:

Type of Data PDC Tilts SimulatedAvg. Forward FER 2.0% 1.9%Avg. Best Ec/Io -6.9dB -6.8dBAvg. Aggr. Ec/Io -5.5dB -5.4dBAvg. Mob Tx Power -19.6dBm -19.6dBmAvg. PMRMs per minute 10.9 9.8% of Data where Mob Tx Pwr >= 10dBm 0.5% 0.1%% of Data where Mob Tx Pwr >= 17dBm 0.1% 0.0%% of Data where Fwd FER >= 10% 4.3% 3.6%% of Data where Fwd FER >= 20% 1.6% 1.3%% of Data where Fwd FER >= 30% 0.8% 0.7%% of Data where Best EcIo <= -13dB 1.1% 0.6%% of Data where Best EcIo <= -15dB 0.3% 0.2%% of Data where Agg EcIo <= -10dB 1.6% 1.0%% of Data where Agg EcIo <= -12dB 0.8% 0.4%

This data shows that the downtilt optimization process was very effective in reducing thepercentage of area with poor coverage, resulting in net performance improvementsoverall. And as with the KCT testing, the SHO factor and call processing rates were alsoreduced, indicating that the customer will be able to get more out of the deployedequipment.

I would like to note the following two items in regards to the DCT results:


33

1. In this testing, the XC-related R8.1 PSMM filtering functionality was accidentally leftenabled in both test cases (while the MM-related parameters were disabled). Thismay be the cause of the slightly higher than expected forward FER levels. In anycase, since these settings were used for both test cases, it should still be possible todraw conclusions from the above data.

2. Simulations predicted relatively similar performance in terms of basic coveragebetween the PDC downtilts and the simulated downtilts. The results above confirmthis, although it’s also clear that the simulated tilts perform a drop better. As thesystem loads, however, the improvement associated with the simulated tilts shouldbecome more and more significant. (The main point here applies to all systems.)

DDI agreed that the simulated tilts provide a better starting point for system optimization,and Ozaki-san (of DDI) even went as far as saying that it seems to have been the wrongconclusion to arbitrarily want to go forward with PDC downtilts. DCT was also happy tosee the positive results today, and requested the new design methodology to be used overa wider area (i.e., to re-simulate portions of the system including more of Sapporo andalso Asahikawa). Ozaki-san also mentioned that the preliminary drive testing in TCT -where the new design techniques have been used to some degree - is showing excellentresults.

The results of these two experiments indicate that simulations are fundamentallyaccurate, and that the new design methodology does indeed produce system designs withimproved system performance. They also show that simulations can be a useful tool toidentify poorly performing areas and to improve them. Since the DCT downtilts werealso determined in part by the downtilt auto-optimizer, the DCT results speak favorablyof its performance as well.

Going forward I think it would be great if we could apply the new design methodology toall system design work, including retroactively applying it to problem areas in alreadyexisting systems such as KCT, QCT, and OCT. It would be possible to set up the auto-optimizer, for example, let it run for some period of time, and apply the results.

Please let me know if you have any questions or comments.

Best Regards,Charles


34

2. Auto Optimizer Tool User’s Manual

By Charles Reisman

The auto optimizer is an automated tool that using predictive methods optimizes anycombination of antenna azimuths, downtilts, and/or pilot powers in a CDMA system.

Rather than focusing on antenna changes during the system optimization stage, these canbe evaluated and “optimized” during the system design stage, leaving fine-tuning for thesystem optimization stage. This can yield significant cost savings in deploying systemsand can also result in significant reductions in project schedules as well. Furthermore, itis likely that the final system performance will be more optimal, as it is very difficultduring the system optimization stage to do anything more than localizedparameter/setting optimizations. The only reasonable place for comprehensive changes –e.g., widespread antenna downtilting – is in the initial system design itself.

This tool is especially useful for markets or systems relying on NetPlan RF propagationpredictions in which the predictive model is based on accurate elevation and clutter dataand has been validated and/or tuned.

This paper describes how to set up and use the auto optimizer program. The appendixalso provides some degree of explanation regarding the tool’s theory of operation. Theinformation herein is accurate as of the auto-optimizer version 1.00.

Overview

The traditional system design methodology relies on generating baseline plots, makingchanges, regenerating plots, and evaluating the effects of the changes. This, of course, isan essential process, but many changes to the system result in visually imperceptiblechanges in performance, and as a result, many such modifications may not be followedup on and implemented even though they may actually provide coverage and/orperformance benefits. In addition, many potential improvements may not be obvious tothe system designer, and as such these parameter/setting changes may not even beconsidered and attempted within the traditional system design work. When many suchchanges are passed over, the result is a system that by design does not perform as well asit could.

The design methodology upon which the auto-optimizer is based looks for performancetrends in the CDMA simulator output images. Specifically, the auto-optimizer judgesgood and bad based upon coverage (both forward and reverse links) and pilot Ec/Iopredictions. In this sense, it relies on both pathloss and Ec/Io levels in evaluatingwhether or not a certain change represents an improvement, with pathloss being weightedhigher than Ec/Io.


35

The user can specify to optimize one or more of azimuths, downtilts, and pilot powers,including in which order to proceed in the case of multiple types of optimizations. Inaddition, the user can specify which sectors to optimize, whether it be all or a reducedsubset.

Baseline images are created and bin-counts are tallied at the start of the optimizationprocess. After that, sector settings are changed and tested one by one. The auto-optimizertool wraps around the NetPlan XLOS and CDMA simulator executables and repeatedlymakes such single sector changes, rerunning pathloss calculations (only when performingazimuth or downtilt changes) and CDMA simulations each time on the way to optimizingthe system. The tool utilizes bin-counting metrics to determine whether attemptedchanges are accepted or rejected. If the auto-optimizer accepts a change, the new talliesbecome the new baseline.

The key to the auto-optimizer’s effectiveness is its ability to decode the NetPlan binaryimage contents, map the bins from one image with those from the others (e.g., forwardpower threshold, reverse required power, and best Ec/Io), and map best server sectors toeach of the bins - thereby linking each bin in the image to a particular sector. Instead of abest server, one may choose to create and use a natural server image for generallyimproved results. A natural server image is similar to a best server image, and, in fact, isidentical in form, but there is a significant difference in that the natural server imageshows the server with the lowest pathloss2 to a particular bin.

In the course of operation, the auto-optimizer does not generally reverse changes onitself, but it will reevaluate a sector any time a change made on a different sector appearsto affect the sector under consideration. In this sense, if another sector sufficientlychanges the RF environment in a particular area it is possible that a previous modificationmay be reversed. Of course, it is also very possible that a change brings further change –a chain reaction.

Since the auto-optimizer relies on XLOS RF propagation predictions – as well as theCDMA simulator model – it is only as accurate as the underlying calculations.Therefore, for maximum accuracy it is recommended to use it in conjunction with high-resolution elevation data and high-resolution clutter (land use/cover) data into NetPlan,and to tune the propagation prediction model in one way or another. At the very least,one should verify that the propagation predictions are within the ballpark, and apply sometype of error correction if they are not.

The auto-optimizer has been tested in three markets as of December 1998: Osaka, Japan(KCT); Sapporo, Japan (DCT); and Curitiba, Brazil (Global Telecom). In addition, theunderlying design techniques are being used in other Japan markets as well. In the Japanmarkets, only downtilts have been modified to date. In Brazil, changes have been to bothantenna azimuths and downtilts. In each market, before and after drive tests wereperformed and analyzed, and the system performance was found to improve as a result of

2 This is not necessarily entirely true in practice, but the reader is encouraged to conceptualize naturalserver images as such.


36

the recommended changes. It is noteworthy that the KCT system had undergone a fullsystem optimization process already, and the new design methodology lead to problemfixes in areas that the system optimization team did not even realize could be improved.

Lastly, it should also be noted that the auto-optimizer is a work in progress. Thealgorithms used within the tool are known to be effective, but it is not yet clear whetherthey are as optimal as they could be. If you should have any comments, please send themby Email to Charles Reisman ([email protected]).

Requirements

In order to use the auto-optimizer, it is necessary to have a computer with NetPlan 3.1(either Sun or HP) with the CDMA Simulator option and Perl version 5.0 or later.NetPlan 3.2 may also work, but it has not been tested yet.3

Several sub-utilities and general purpose Unix utilities are also required. These include:

Calc_Bins (includes calls to sub-executables image_values, hist_values andCalc_Max_RevPwr)POLYFILcompress_allStandard NetPlan sub-executables: glosB, compimages, grid_comb, and cdmaStandard Unix programs, such as cp and cmp

When you launch the auto-optimizer, it will confirm that each of the above programs(except POLYFIL) is available, and the run will fail if any is not found.

Setup

To set up the auto-optimizer the following steps should be followed:

Set up a NetPlan analysis.For speed and efficiency during the auto-optimizer execution, it is recommended tocustomize the sites’ propagation boundary using the NP_to_CSSS tool. Since the auto-optimizer repeatedly calls for XLOS and CDMA simulator calculations to be performed,and these calculations take much time, it is desirable to minimize the calculation area.The NP_to_CSSS tool requires the user to specify a calculation frame and a maximumpropagation distance. The frame setting specifies a window size around the cell sites inthe analysis, such that if the frame is set to x meters, calculations will not be performedbeyond x meters west of the westernmost site, north of the northernmost site, east of theeasternmost site, and south of the southernmost site. The maximum propagation distancesetting serves as a maximum value in case the calculated distances (i.e., to the frame) 3 Whatever the case, the auto-optimizer will be made to work with NetPlan 3.2.

mailto:[email protected])


37

would otherwise exceed it. For example, if the distances from a site to the western edgeof the frame were 100km, and the maximum propagation distance were set to 48km, thesite’s propagation boundary in the western direction would be set to 48km. A calculateddistance of 30km, for example, would be left as is since it is less than the maximumpropagation distance setting. The NP_to_CSSS utility creates an SQL script that shouldbe run directly on the NetPlan Informix database. An alternate method to limiting theimage calculation space is to customize the combined image propagation boundarieswithin NetPlan. This will save time on the CDMA calculations, but it will not minimizethe time required for XLOS pathloss calculations.Modify the antenna pattern(s) and make a natural server image. This is essentially thesame process as when creating a best Ec/Io server/sector image, except before runningthe CDMA simulations, one should either:Create a special antenna pattern or patterns with the vertical pattern data points all set to0dB. (recommended)Set all antenna downtilts to 0 degrees.This particular simulation should be performed with very favorable conditions – e.g.,unloaded, no vehicle/building penetration loss, etc. – as the only purpose of the resultingimage is to tie each bin to a best server, and as many bins should be tied to best servers aspossible (i.e., it is undesirable to have uncovered bins). It does not serve in any way toshow the effects of loading on performance. Only one Monte Carlo drop is required.The resulting EcIoServer_1 image (which can be found in the CDMA_DROP/EcIoServerdirectory below the NetPlan analysis’ main directory) must then be copied into a newdirectory called NaturalEcIoServer, which must be created below the analysis’ maindirectory.Apply a polygon filter to the natural server image. Create a polygon, which defines theouter edge of the area, which you’d like to consider. In general, this polygon serves tofilter out areas, which are not within the intended coverage area, such that terrain and/ortopology do not adversely affect simulation results. For example, consider a flat urbanarea, which is immediately surrounded by mountains. It is very likely that themountainsides will not show good coverage, and therefore, the simulations wouldconsider those as areas of potential improvement. Downtilt optimization – were that theoptimization mode in question - might therefore lead to a significant degree of uptilting ifnot otherwise controlled, yielding improved mountainside coverage, but at the expense ofthe more important area below. The polygon filter is needed in order to minimize suchundesired changes.To apply the polygon filter, first create a polygon or polygons using the NetPlan polygontool, and then create a traffic distribution map using the Create Map from Polygonsoption with an arbitrary non-zero Erlang levels for the polygon(s). Then, copy thecreated traffic distribution map, which will be located somewhere under the traffic_mapdirectory within the analysis’ main directory, into the NaturalEcIoServer directory. Next,from the NaturalEcIoServer directory apply the polygon filter as follows:

POLYFIL EcIoServer_1 Polygon_Map

Substituting the appropriate name for the polygon traffic map as necessary. Next, backupthe original EcIoServer_1 file, which will not have been touched by the above operation.


38

Lastly, rename the filtered image file, which will be called EcIoServer_1.FIL, toEcIoServer_1. The natural server image is now ready for use.Restore the actual antenna patterns if changed above, and rerun all pathloss calculationssuch that they are up to date.Start up a new NetPlan session from the shell4 after entering the following command(assuming K-Shell is the shell in use):

export AIM_DEBUG=3

Open up the analysis, and confirm once again that step 5 above has been executed. Then,using the Edit->Antenna function, arbitrarily change the antenna downtilt for one andonly one sector. Press the “Update” button to have the change registered in the database.Then, return the changed downtilt parameter back to its original setting, and press the“Update” button once again. Then launch site propagation calculations by choosing the“Images->Create” option. Click on “Site Propagation”, and then choose the site whosedowntilt was changed and add the “CDMA Antenna Gain” to be calculated and press“OK”. Be sure not to include any of the analog/TDMA transmit/receive calculationoptions. Various debug messages will appear in the AIM window. Take special note ofthe /tmp directory (e.g., /tmp/BD12a345678) in which these AIM files are located. Thisis the directory, which will be entered as the NP_GLOS_DIR in the main auto-optimizerconfiguration file (see below).Set up the CDMA simulation parameters for one Monte Carlo drop (for both statisticsand images) and for the various other design parameters. Unlike the previous simulationrun in which the natural server image was created, this time the simulation should be setup to reflect the actual design conditions which should be considerably moreconservative. The number of mobiles should be set to a moderately heavy load (inconstant mode) and the other link budget parameters – e.g., mobile antenna gains, fadingmargin, etc. – should likewise be set conservatively. In fact, at the system designer’sdiscretion, these settings might be set even more conservatively than the actual designcalls for. In this manner, it might be possible to guard against degradation to in-buildingcoverage, for example, for a system that was otherwise designed only for in-vehicle loss.Without making any further database changes, once again select the “Images->Create”option, but this time select the “CDMA Simulator”. Then, select the followingimage/data types and press “OK”:Reverse Required PowerBest Ec/IoBest Ec/Io Server/SectorMaximum TCH Threshold ExceededCell and Mobile StatisticsOnce again take note of the /tmp directory name which appears in the window. This willbe the name that is entered as the NP_CDMA_DIR variable setting in the mainconfiguration file.Using the npadmin utility, export the Informix database data associated with the analysisunder test. It is okay if the exported data includes more sites or site versions than those in

4 The exact command will depend on the installation, but may be as simple as “NetPlan”.


39

the analysis. The path for the unload (“unl”) directory will become the setting for theNP_UNLOAD_DIR configuration file entry.Set up the main auto-optimizer configuration file. The file is comprised of various tokendefinitions one per line, in which all of the major settings and execution options arespecified. Please refer to the next section for more detail on the various tokens.Execute the auto-optimizer with the following command:

Auto_Optimizer –C Auto_Optimizer.cfg

substituting the name of the main configuration file, as appropriate. The auto-optimizermust be launched from the NetPlan analysis’ main directory, regardless of where theconfiguration file and miscellaneous input and output directories are located.

The Main Configuration File

In order to use the auto-optimizer, one must set up a configuration file that contains thenecessary settings and references to other files and directories. The following is a sampleconfiguration file:

#Sample Auto_Optimizer Configuration File: ADJUSTABLE_SECTOR_FILE = Optimizer/adjustable_sectors ANT_INFO_FILE = Optimizer/antenna_info ARCHIVE_DIR = Optimizer/Opt_Archive AZIMUTH_INCREMENT = 5 AZ_ADJ_SECTOR_FILE = CALC_BINS_CONFIG = Optimizer/Calc_Bins.cfg DT_ADJ_STRATEGY = B-U EMAXX_MODE = YES INDEX_SECTOR_COUNT = 5 LIMIT_BINS = YES MAX_AZIMUTH_SHIFT = 180 MAX_PILOT_POWER = 6 MIN_PILOT_POWER = 0.75 NONADJUSTABLE_SECTOR_FILE = NP_CDMA_DIR = /tmp/BD56c501239 NP_GLOS_DIR = /tmp/BD25c429269 NP_SITE_VERSION = 2 NP_SYSTEM_NAME = DCT_CDMA NP_UNLOAD_DIR = Optimizer/export/unl OPTIMIZATION_MODE = DP OUTPUT_LOG_FILE = Optimizer/Auto_Opt.out PILOT_ADJ_FACTOR = 1.26 PP_ADJ_SECTOR_FILE = Optimizer/adjustable_sectors PRIMARY_REGION = A PRIORITY_SECTOR_FILE =


40

RESULT_TABLE_FILE = Optimizer/Result_Table RUN_INIT_SIMULATION = YES TIME_LIMIT = USE_NAT_SERVER = YES

Any line beginning with a “#” is taken as a comment and is ignored. Any white spacecharacters are also ignored. The token name falls to the left of the equals (“=”) sign, andits value is to the right. In some cases when a certain setting is not applicable, it is allright for the value to be left null.

The various configuration file tokens carry the following meanings and usages:

ADJUSTABLE_SECTOR_FILE –Defines the file that specifies which sectors’ downtilts may be adjusted by the auto-optimizer. If not set, then the auto-optimizer assumes that all sectors’ downtilts may beadjusted (barring entry in the NONADJUSTABLE_SECTOR_FILE). The file containsone sector per row, represented by two columns with the site number in the first column,and sector number in the second. The two columns should be separated by a white-spacecharacter (e.g., a tab).Optionally, the user may also include a third column, which defines the region code withwhich the particular sector will be associated. If used, this code will tie the site to aCalc_Bins calculation region. If the third field is not present, the sector will beassociated with the PRIMARY_REGION. When using a polygon-filtered natural serverimage, the region field is generally left unassigned, with the polygon filter serving toeliminate unwanted areas from the calculations.ANT_INFO_FILE –Specifies the name of the antenna information file, a required file that defines thecharacteristics of the antennas in use in the analysis. This file is described in greaterdetail later in this document.ARCHIVE_DIR –Specifies the directory in which the individual trial data directories are archived. Thisdirectory must be empty at the start of the auto-optimizer run.AZIMUTH_INCREMENT –Defines the increment by which antenna azimuths are changed. For example, if thisvalue is set to 10, then antenna bore angles will be adjusted clockwise orcounterclockwise in 10-degree steps.AZ_ADJ_SECTOR_FILE –This is the equivalent of the ADJUSTABLE_SECTOR_FILE setting, but it applies toantenna azimuth adjustments. Unlike the case of downtilt adjustments, however, sectorsmust be defined in this file in order to be adjustable (as is the case withPP_ADJ_SECTOR_FILE).CALC_BINS_CONFIG –Defines the Calc_Bins utility configuration file. The Calc_Bins utility is documentedseparately. When using the auto-optimizer with a polygon-filtered natural server image,it is generally preferable to use a default Calc_Bins configuration file that containsnothing, except for one line with the PRIMARY_REGION code letter.


41

DT_ADJ_STRATEGY –This setting defines how the auto-optimizer should approach antenna downtilt changes.There are six options defined as follows:D – Specifies to perform downtilts only.U – Specifies to perform uptilts only.B-D – Attempts both uptilts and downtilts in an alternating fashion, but will first attempta downtilt. This setting is essentially the same as B-U, except for the very first trial.B-U – Attempts both uptilts and downtilts in an alternating fashion, but will first attemptan uptilt. This setting is essentially the same as B-D, except for the very first trial.D-U – Will perform only downtilts to start out with, and when it finds it cannot make anymore adjustments will also attempt uptilts. After uptilt changes begin, further downtiltsare still possible, as changes can trigger additional changes.U-D – Will perform only uptilts to start out with, and when it finds it cannot make anymore adjustments will also attempt downtilts. After downtilt changes begin, furtheruptilts are still possible, as changes can trigger additional changes.EMAXX_MODE –Should be set to “YES” when simulating with the EMAXX chipset and to “NO”otherwise. When set to “YES” the auto-optimizer sets up the CDMA_EMAXX=1environment variable for the user.INDEX_SECTOR_COUNT –Specifies how frequently the auto-optimizer should retest sectors that have beensuccessful thus far and for which further testing remains. Please refer to the Theory ofOperation section to get a better understanding of what this means, but when set to anarbitrarily high value, sector retesting is essentially disabled until all sectors have beentested at least once; and when set to a low value (e.g., approaching 1), will give a strongemphasis to those sectors which it has already tested. The default setting is 5, whichgives a strong emphasis to untested sectors, but will at the same time reasonablyfrequently retest a sector which shows significant potential for further improvement.LIMIT_BINS –When set to “YES” causes any bins that do not have an associated natural server/sector tobe ignored. In general, this value should be set to “YES” whenever a polygon-filterednatural server image is used, and to “NO” otherwise.MAX_AZIMUTH_SHIFT –Defines the maximum azimuth (bore angle) shift in degrees that any sector may beadjusted as part of azimuth auto-optimization. A setting of 40 degrees, for example,would mean that a sector initially with an azimuth of 60 degrees must end up somewherebetween 20 degrees and 100 degrees (inclusive). The default value is 180 degrees.MAX_PILOT_POWER –Sets the maximum pilot power (in Watts) to which any sector may be increased. Thedefault value is 6W.MIN_PILOT_POWER –Sets the minimum pilot power (in Watts) to which any sector may be reduced. Thedefault value is 0.75W.NONADJUSTABLE_SECTOR_FILE –


42

This optional file complements the ADJUSTABLE_SECTOR_FILE by specifyingsectors that may not be adjusted for downtilt trials. This provides an extra degree offlexibility in setting up the auto-optimization data.NP_CDMA_DIR –Defines the NetPlan AIM temporary directory in which the CDMA simulator templateexists. This setting is described in greater detail above in the Setup section.NP_GLOS_DIR –Defines the NetPlan AIM temporary directory in which the GLOS template exists. Thissetting is described in greater detail above in the Setup section.NP_SITE_VERSION –Specifies the site version for all of the sites in the analysis. All sites must have the sameversion number. This setting defaults to 1.NP_SYSTEM_NAME –This setting defines the system name in the NetPlan database under which the switch,sites, and sectors exist.NP_UNLOAD_DIR –Specifies the path for the exported Informix database unloaded data directory. The valuemust include the “unl” directory itself. The exported data must represent up-to-datedatabase settings as of the start of the auto-optimizer execution.OPTIMIZATION_MODE –Specifies what the type or types of auto-optimization and the order of the processes. Thissetting will consist of one or more of the following in a single string:A – Azimuth auto-optimizationD – Downtilt auto-optimizationP – Pilot power auto-optimizationA setting of “D” would specify that only downtilt auto-optimization will be performed.A value of “DP” would specify for downtilt auto-optimization to be performed followedby pilot power auto-optimization. A setting of “PD” could be used to perform the sameauto-optimizations, but in opposite order.OUTPUT_LOG_FILE –Specifies the file in which the auto-optimizer output is logged. Generally speaking, theauto-optimizer outputs miscellaneous information to both the log file as well as the Unixstandard error file handle (which will normally be output to the terminal).PILOT_ADJ_FACTOR –Specifies the linear multiplicative step-wise increase/decrease factor for pilot poweradjustments. A value of 1.26, for example, is equivalent to specifying that pilot poweradjustments be made in steps of +/- 1dB in log scale (10 * log 1.26).PP_ADJ_SECTOR_FILE –This is the equivalent of the ADJUSTABLE_SECTOR_FILE setting, but it applies topilot power adjustments. Unlike the case of downtilt adjustments, however, sectors mustbe defined in this file in order to be adjustable (as is the case withAZ_ADJ_SECTOR_FILE).PRIMARY_REGION –Defines the region to be associated with any adjustable sector that does not specificallyhave a region defined for it in the adjustable sector file (see theADJUSTABLE_SECTOR_FILE description). When using a polygon-filtered natural


43

server image, this should be set to match the single region code which is entered in theCalc_Bins configuration file (see CALC_BINS_CONFIG).PRIORITY_SECTOR_FILE –This optional file specifies priority sectors for downtilt adjustments. The auto-optimizerwill complete downtilt trials for all priority sectors before moving on to the remainingadjustable sectors. The priority sector list should be a subset of the adjustable sector list.RESULT_TABLE_FILE –Defines the file in which the auto-optimizer results data is summarized in tabular form.RUN_INIT_SIMULATION –This setting determines whether or not the auto-optimizer executes a CDMA simulationto create baseline data. If set to “YES” a simulation is run before calculating the bintotals. If set to “NO”, the auto-optimizer assumes that a simulation has already been runwhose results are still valid. This variable defaults to “YES”, but can be set to “NO”when valid simulation data already exists to save a little time.TIME_LIMIT –The user may optionally specify a time limit expressed in hours. The auto-optimizer willbegin to test modifications and if it is still running when the time limit expires, it willfinish the current trial and then end, cleaning up after itself restoring the original settings(as it normally does upon completion).USE_NAT_SERVER –Specifies whether or not a natural server image is to be used. This should be set to either“YES” or “NO” and will default to “NO”. If a natural server image is used, the file mustexist at NaturalEcIoServer/EcIoServer_1 under the analysis’ home directory. If set to“NO” the Ec/Io best server/sector from each respective trial will be used to map each binto a server/sector.

The Antenna Information File

The following is an example antenna information file:

#Antenna Definitions File

Antenna Model Definitions:#AntModel AntClass ElecDTmd8cr6xs8-u 2md8cr6xs8 u2md8cr6xs8-u 1md8cr6xs8 u1md8cr6xs8-0 md8cr6xs8 0md8cr6xs8-1 md8cr6xs8 1md8cr6xs8-2 md8cr6xs8 2md8cr6xs8-3 md8cr6xs8 3md8cr6xs8-4 md8cr6xs8 4md8cr6xs8-5 md8cr6xs8 5md8cr6xs8-6 md8cr6xs8 6md8cr6xs8-7 md8cr6xs8 7md8cr6xs8-8 md8cr6xs8 8md8cr6xs8-9 md8cr6xs8 9


44

md8cr6xs8-10 md8cr6xs8 10md8cr6xs8-11 md8cr6xs8 11md8cr6xs8-12 md8cr6xs8 12m8-cr9-800f m8-cr9-800f

Antenna Class Definitions:#AntClass E/M Gain HORIZ VERT MIN_DT MAX_DT DEPTH PRECm8-cr9-800f M 17.0 60 3 u2 6 0.200 1md8cr6xs8 E 16.0 60 4 u2 12 0.180 1

Models to Avoid:md8cr6xs8-1 0md8cr6xs8-3 0md8cr6xs8-11 0md8cr6xs8-12 0

This file is divided into three parts, which are identified by the three key phrases“Antenna Model Definitions:”, “Antenna Class Definitions:”, and “Models to Avoid:”.

The individual antenna models are defined in the section of the file denoted by the“Antenna Model Definitions:” key phrase. Each antenna model which exists in theexported NetPlan database must be specifically entered in this section. The first columnshall contain the model name verbatim, the second name shall contain the assignedantenna class (re: the “Antenna Class Definitions:” section), and the third column shallcontain the downtilt value for electrically downtilted antennas. The third column may beleft blank for mechanically downtilted antennas.

It’s important to note the distinction between mechanically and electrically downtiltedantennas from the auto-optimizer’s point of view. For the purposes of this tool, amechanically downtilted antenna is one for which a downtilt is applied by changing theNetPlan downtilt parameter. An electrically downtilted antenna is one in which theantenna model itself is changed when changing the antenna tilt. For this reason, it isnecessary to clearly define the downtilts for electrically downtilted antennas. In addition,all antennas in the same family of electrically downtilted antennas must be defined withthe same antenna class. This is how the auto-optimizer links the antennas as a set.Likewise, antenna models that should not be linked must be assigned different antennaclasses.

Antenna classes are defined in the “Antenna Class Definitions:” section. It is here thatthe user specifies whether an antenna is electrically or mechanically downtilted and whatthe minimum and maximum applicable downtilts are. The precision column specifies theresolution (in degrees) for downtilt changes. A value of 1, for example, indicates thatdowntilt adjustments are made on a one degree by one-degree basis, pending antennamodel definitions in the case of electrically downtilted antennas.


45

The remaining columns in the antenna class definition section are required asplaceholders. The entered information is not used, however, and therefore is notsignificant.5

The final section of the file, “Models to Avoid”, is optional, applies to downtiltadjustments, and defines any downtilt settings which should not be tested by the auto-optimizer. This is useful if one knows that the antenna pattern differences between twodowntilts are insignificant, or if one wants to reduce antenna inventory by limiting thenumber of downtilts in use in the system (in the case of electrically downtilted antennas).Even if the precision setting would otherwise specify to test a certain antenna downtilt, itwill be skipped if a model or downtilt is entered here.

The Output Files

The auto-optimizer generates the following three types of output files:

Output logResults summary tableTrial archives

The output log file is specified by the OUTPUT_LOG_FILE configuration file token.This file contains miscellaneous messages from and information regarding the auto-optimization process. For a normal execution of the auto-optimizer, the first part of thefile contains information related to the initialization process. Next comes messagesassociated with each of the trials, including specific numerical results information. Lastcomes messages associated with the cleanup process, if applicable. The single mostvaluable use of this file is to confirm that the auto-optimizer both executes and terminatesproperly. After the auto-optimizer run completes, the user should search for the strings“Warning” and “Error” in the output log. If occurrences are found, the cause will need tobe identified, additional cleanup may be necessary, and the auto-optimization run willneed to be repeated. Otherwise, if none are found, the user may go on to examine theother results.

Among the various auto-optimizer outputs, the RESULT_TABLE_FILE contains themost useful information in a very concise format. The following is a sample file:

Trial S-S Msc From Antenna To Antenna S/F Row Change Comp1 124-3 UUA md8cr6xs8-3, 0.0 md8cr6xs8-2, 0.0 S 23 1/91 02 137-1 UDA md8x6u212-7, 0.0 md8x6u212-8, 0.0 U 20 -1/12 03 126-5 UUA md8cr6xs8-8, 0.0 md8cr6xs8-7, 0.0 F 23 -3/-123 14 1-5 UDA md8prx006-3, 0.0 md8prx006-4, 0.0 S 11 2/28 15 126-6 UUA md8cr6xs8-10, 0.0 md8cr6xs8-9, 0.0 F 23 -1/-51 26 146-1 UDA md8cr6xs8-4, 0.0 md8cr6xs8-5, 0.0 S 11 1/104 27 126-5 IDA md8cr6xs8-8, 0.0 md8cr6xs8-9, 0.0 S 23 1/63 1 5 Users of the NP_to_CSSS tool may recognize the similarity between the antenna info files for the twotools.


46

8 111-6 UUA m8-cr9-800f, 3.0 m8-cr9-800f, 2.0 F 11 -1/-45 2

The first column shows the trial number. The second column, labeled “S-S” contains thesite and sector that was tested. The next column contains a three-letter code, which canbe decoded according to the following table:Optimization Mode First Character Second Character Third CharacterAzimuth Untested/Index Azimuth Region CodeDowntilt Untested/Index Uptilt/Downtilt Region CodePilot Power Untested/Index Pilot Power Region Code

The next two columns in the table show the "from-state" for the sector under test and the"to-state" for the sector. The type of information shown will depend upon the type ofoptimization – i.e., whether the azimuth, downtilt, or pilot power is being tested.

The sixth column shows the result of the test; This will always be either a “S” forsuccess, “F” for failure, or “U” for unclear. On successes, the change is accepted and thenew state and results become the new baseline for ensuing tests. The opposite is true offailures; the result is rejected and the system is reverted to the previous baseline. Unclearresults are treated similarly to failures in that the system is reverted to the previousbaseline, but there is a difference in that the sector is kept, to be re-tested at a later time.

The seventh column of the results table shows the row in which the decision was made6.This is a code for the condition by which the test was judged to be a success or failureand can be interpreted via the following table:

Row Number Condition5 Forward Link Coverage8 Reverse Link Coverage11 Coverage (Both Fwd. and Rev. Links)14 Coverage and Ec/Io >= -10dB17 Coverage and Ec/Io >= -12dB20 Coverage and Ec/Io >= -13dB23 Coverage and Ec/Io >= -14dB

In cases where no performance change is found through the sector change under test, thiscolumn will not contain a number, but rather will contain “-“.

The eighth column of this file shows a summary of the numerical comparison results.The first of the two numbers shown shows the change in the decision row (of theprevious column) at the decision power (please refer to the Theory of Operation sectionfor more detail). A positive number indicates that the change results in improvedperformance for the condition indicated by the previous column (corresponding to thepower level, which can be found in the output log file). A negative number likewise

6 This information comes directly from the Image.stats-* files which are logged in the archive directories.Row numbers correspond to row numbers in those files.


47

indicates degradation. The second number in the pair represents the overall change, andis a tally of each of the individual conditions’ changes for each of the power levels underconsideration. Again a positive number indicates an overall improvement, and a negativenumber represents overall performance degradation.

The final column of this file shows a count of the number of sector-directions that havebeen tested and completed. This is an approximation, as sectors that are once consideredto be completed may need to be re-tested due to a chain-reaction effect. In the case ofazimuth optimization, pilot power optimization, or downtilt optimization in which bothuptilts and downtilts are to be performed, the completed sector count will go up to twicethe number of sectors under test. For downtilt optimization in which only one of eitheruptilts and downtilts is performed, this count will come to equal the number of sectorsunder test.

Various files are stored in each of the trial sub-directories within the archive directory.Many of these files are direct outputs of the Calc_Bins utility (such as the Image.stats-*files mentioned in the earlier footnote), but the most useful file – and the only one to bedescribed here – is the output of the auto-optimizer. Only for trials which weresuccesses, there will be a change recommendations file – called eitherAZ_Recommendations, DT_Recommendations, or PP_Recommendations, as appropriate– which contains a listing of all change recommendations for all testing (for the type ofoptimization currently under consideration) up until then. Therefore, when the auto-optimization run completes, the results table file should be checked to see what the lastsuccessful trial was for each optimization type, and then the archived trial directory ordirectories should be consulted to see the list of recommended changes.

Stopping Execution Midway Through an Auto-Optimization Run

There may be occasions in which the auto-optimizer must be stopped before it completesits operation naturally. Since the tool works directly on the NetPlan XLOS files in thecase of azimuth and downtilt optimization and on the CDMA simulator template file inthe case of pilot power optimization, the auto-optimizer must clean up after itself torestore all critical files to their original states before terminating operation. It is thereforeextremely dangerous to terminate the auto-optimizer prematurely with a control-C.

Rather, there is a mechanism built into the auto-optimization tool for this very purpose.After each test trial, the program pauses for 20 seconds during which time the programwaits to receive a QUIT signal. If it does not receive this signal, the auto-optimizationcontinues therefore. If a signal is received, the auto-optimizer recognizes that it needs toterminate the run and begins to clean up after itself. The signal is sent to the process withthe following command:

kill –3 PID

from a different shell, where PID should be replaced with the auto-optimizer’s process ID(which can be determined with the help of the ps command). In the case of pilot power


48

optimization the cleanup process will be very quick, but for azimuth and downtiltoptimization runs, the cleanup process may take some time, depending on the number ofchanges accepted thus far in the run.

Theory of Operation

Whether the optimization mode be azimuth, downtilt, or pilot power, the auto-optimizertests and changes a single sector’s setting one notch at a time. The results of each test arecompared to the current baseline and the change is accepted if the results are judged toimprove. In such a case, the baseline is revised appropriately to reflect the newinformation. If the test is deemed a failure, the setting is reverted to the previous settingand the previous baseline is maintained.

Whenever a test results in a failure, that change direction is marked internally as beingcompleted. Furthermore, if a test is successful, the opposite direction is marked as beingcompleted. Any sector direction which is marked as being completed will not beretested, unless it should become unmarked. Any marked sector will be unmarked if atest for a sector is successful, and the resulting bin counts show that the conditions for thesector have changed. This is determined by counting the number of bins associated withthe marked sector as their best server at maximum power and within 3dB of thatmaximum power (also noting that maximum power level). Should any of these valueschange, the sector will be unmarked, thereby enabling it for further testing.

As the auto-optimizer runs, it keeps track of those sectors that have been tested alreadyand those which have yet to be tried. For those that have been tested it maintains anindex value which is a function of the results associated with that sector’s last trial. Morespecifically, an index is maintained for each change direction. For example, in the caseof downtilt optimization, a separate index will eventually exist for each sector for bothuptilts and downtilts. The greater the value, the more promise for further changes in thatdirection for that sector. In addition, when a sector is first tested in either direction, theindex is entered not only for that direction, but the negative of the index is entered for theopposite change direction. Therefore, if a test yielded excellent results, this is reflected inthe index for that change direction for that sector so as to indicate that further change inthat direction has the strong potential to yield further performance improvement.Likewise, the index for the opposite direction will be assigned a highly negative value toindicate that there is little potential for such a test.

The auto-optimizer will tend to concentrate on untested sectors when it first starts out,though this behavior can be modified with the INDEX_SECTOR_COUNT configurationparameter. The auto-optimizer will begin by testing untested sectors. AfterINDEX_SECTOR_COUNT instances of either successes or outright failures onpreviously untested sectors, it will then test a previously tested sector, if one exists. Itchooses which sector to test and in which direction based upon the index value, with thesector direction with the highest index value being selected. This pattern will continue


49

until no untested sectors remain, after which testing will continue based only upon theindex table. Testing will then continue until no uncompleted sector directions remain.

Trials are accepted as successful whenever the two results values that are logged in theresults table file are both positive or if the first is positive and the second is zero (theopposite case is not possible). A trial results in failure if both of those values arenegative, or if the first is negative, and the second is zero. If one value is positive and theother negative, the result will be unclear (similar to a failure, except the sector is notmarked as being completed) if there are untested sectors remaining, or a failure if nountested sectors remain. In this sense, the auto-optimizer is more forgiving early on in itsoperation, but then gets stricter as It approaches its completion. From this, it can also beseen that the auto-optimizer places emphasis on improving areas with weak coverage. Itwill only accept changes in which overall performance is improved while the amount ofweakly covered area is likewise reduced.

The testing order for untested sectors and sector directions is initially selected based uponlooking at the maximum mobile transmit powers associated with the natural serversectors. For uptilt and azimuth optimization, the as-of-yet untested sector with thegreatest maximum mobile transmit power is selected. For downtilt and pilot poweroptimization, the untested sector with the lowest maximum mobile transmit power isselected. In this manner, downtilt and pilot power optimization will tend to moveoutwards from urban areas to rural areas, and uptilt and azimuth optimization will tend toproceed in the opposite direction.

Algorithmically speaking, because testing for any sector will end as soon as a failure isencountered and because a change direction will not be tested if a change in the oppositedirection was already found to result in improvement, the auto-optimizer may not findideal settings if it were to become trapped in a local maximum point. The extent to whichsuch local maxima exist is unclear. In any case, because of this aspect of its operation,the effectiveness of the tool may to some degree be a function of the set of startingparameters. It is hoped that retesting sectors when necessary will serve to minimize thiseffect.

As a final note, the importance of applying a polygon filter to the natural server imageand of using other techniques to improve execution speed cannot be underestimated. Inparticular, the use of a polygon filter will not only speed up the post-processing of thesimulation data, it will also significantly increase the accuracy of the results. Any areawhich is not to be covered by the sites in the simulation – e.g., mountainsides, excessivedistances, oceans, etc. – should be filtered out so that the auto-optimizer can concentrateon maximizing performance in those areas which the system is meant to cover.


50

APPENDIX 2B: Sample Problem Resolution Matrix (PRM)

This PRM shows various examples of problems encountered in the field.

Legend: good = + marginal = * poor = -Rx: > -80dBm -80dBm < Rx < -

90dBm < -90dBm

Ec/Io: > -12 dB -12dB < Ec/Io < -15dB < -15 dBFFER: < 3%, 3% < FFER < 5% > 5%

Tx: < +17dBm >+17dBmRFER: < 3%, 3% < RFER < 5% > 5%

Physical Performance Problem DescriptionDate Problem

IdentifierSectors Cluster/B

TSRx

(dbm)Ec/Io FFER

%Tx (#FTO’s, Drops, etc.) Status, Action Plan Closed Date

3/13/98 B1 2-4; 53-1; 32-3

SouthBTS 2;North

BTS 53;East BTS

32

* * + - FTOs and drops; marginalEc/Io and Rx; no dominantserver in area

Redrive area after uptilt done on32-3 and 2-4; probably willcreate set of dominant servers

open

3/13/98 B1 42-4; 33-1; 33-2;

32-5; 32-6

SouthBTS 42;Northeast BTS33; WestBTS 32

+ - - - FTOs and drops; poorreadings for Ec/Io, Fwd. FERand Tx pwr; may be due toBTS 74 off air

Redrive after fixing BBX’s onBTS 74 to determine if stillproblems in this area. Most ofthese pilots are weak, and BTS74 should be dominant serverwhen working.

open

3/13/98 B1 & B2 Allsectors

77 * - * - Off air due to CSMs -affected border between B1& B2; specifically NorthBTS 77; East BTS 46;Southwest BTS 70

Redrive after fixing CSMs onBTS 77 to determine if stillproblems in this area. Areashould see better Ec/Io when itcan use BTS 77 for soft(er)handoffs.

open

3/13/98 B1 & B3 33-4, 33-5; 74-all;

69-all;29-1; 29-2; 29-6;

30-3; 30-4; 30-5

"Ring ofFire"Cluster

+ - - + Multiple Pilots serving area. Increase downtilts on 29-2 and29-6 that are overshooting intothis area. Reduce SIF pilotpowers on 30-3, 30-4, 30-5(already at 9 degrees downtilt).

open

3/13/98 B3 Allsectors

BTS 61 - - - - Coverage boundary cellgoing into mountains.Coverage spotty.

Recommend repointing antennasalong major roads to minimizeimpact to users.

open

Optimization Procedures and Guidelines, Ver 1.2Equipment Installation and Test

51

3.0 Equipment Installation and Test

3.1 DescriptionThis activity encompasses verification that the installation and test of new CDMA BTSequipment at site locations was properly performed. By working with the CFE crews toevaluate the BTS ATP (Acceptance Test Procedure) data, the RF system optimizationteam will ensure the cell sites are ready to start Single Cell Functional Test (Chapter 7).The lead System Engineer should be aware of any site-specific issues that may delay theavailability of a site.

The BTS Optimization/ATP process encompasses the tasks of installing the BTSsoftware, performing the cell site ATP, optimizing per the ATP and verifying thefunctionality of the site to be sure the cell is properly operating (e.g. making calls on allMCC channel elements). The BTS Optimization/ATP is a sanity check that verifies thehardware is doing what it is advertised to do.

Going beyond the BTS Optimization/ATP procedure, it is critical that the cell site befully integrated across the span lines to the CBSC. Several markets have developed“Integration Test Checklists” to follow to ensure that this work is performed properly.Appendices to this chapter contain a sample checklist that can be used to verify that thisBTS/CBSC integration activity is complete. Naturally, modifications to this checklist areappropriate for various equipment configurations, and should be implemented asnecessary.

[Note: In practice, this type of formal review is not typically conducted. Usually,notification is provided to the system optimization teams from the CFE teams that acluster is ready for optimization. However, this chapter gives the RF optimizationengineer the necessary guidelines and information to work with the CFEs to isolate anyproblems that may have been overlooked. As an alternative, the CFE manager could dothis quality review and sign off on the turnover of BTSs to the system engineering teamprior to start of SCFT.]


52





(Chapter 3)


(Chapter 4)




(Chapter 9)







System Designvia


(Chapter5)


(Chapter 7)


(Chapter 8)

Figure 3.1-1: Relationship of Equipment Installation Verification to EntireOptimization Process

3.2 Tools RequiredNo specific tools are required for this task. However, to enable this verification, thesystem engineer should understand the BTS Optimization/ATP procedure, BTS/CBSCintegration procedures, and be capable of reviewing these data sheets with the CFE. BTSOptimization/ATP procedure manuals for various BTS models can be ordered from TEDat: http://www.cig.mot.com/TED/docs.html. These manuals list additional documentsand tools required to perform optimization of the cell site equipment. [An LMF or LocalMaintenance Facility will be used to conduct many of the ATP tests. The LMF Basicsare covered in the "LMF Operator’s Guide, Local Maintenance Facility", order manual #68P09226A13-B from TED at http://www.cig.mot.com/TED/docs.html.]





53

Type Skill LevelRF System Engineer White Belt (See Appendix A)Cellular Field Engineer (CFE) See Appendix A


3.4 Entrance Criteria1. The system engineer should verify that the BTS optimization/ATP has been

completed for each BTS being reviewed, and that the datasheets/ATP reports fromeach BTS are available. This can be for an entire cluster at a time for maximumefficiency. The system engineer can review the data sheets even if they have a mastersign-off by the CFE manager.

2. Any additional data sheets from other test activities, such as Integration TestProcedures, are available. ITPs traditionally cover tests above and beyond the normalOpto/ATP procedure and are directed at ensuring proper integration between the BTSand CBSC. ITPs may include special considerations for more complex BTSequipment configurations, such as double-density cages supporting multi-carrieroperation where additional cabling requirements are present.

A sample data sheet for a set of ITP tests conducted for deployment of 2nd carrier inLos Angeles is contained in Appendix 3A.

3.5 ProcedureThe system engineer should coordinate with the CFE to evaluate the Optimization/ATPdata sheets from each BTS to learn the following for all sites in a cluster underevaluation:

1. Check the last date of the BTS Optimization/ATP procedure (to ensure that thelatest procedure was used)

2. BTS ATP datasheets should be reviewed to make sure all test results were withinacceptable limits for each BTS and module. Particular attention should be paid towhether the Tx Cal and the Rx FER tests passed. (This tells the systems engineerthat the Transmit path and modules are working properly and the Receive pathand modules are working properly.)

3. Determine whether any modules were replaced or if any ATP tests failed initiallyand then subsequently passed.

4. Verify all cables were calibrated correctly.

5. Ensure that the latest cal file was backed up onto the OMC-R at the MTSO. Thiswill also tell the system engineer when the site was calibrated last.


54

6. Integration Test Procedure (ITP) data sheets should be reviewed to ensure that alltests have passed.

3.6 Analysis ConductedIf there were any problems identified while conducting the procedure above, thisinformation should be entered into the Problem Resolution Matrix for this cluster tocapture this historical information for future reference. Any repeat failures at a particularBTS, during either ATP or ITP, should be highlighted.

One of the most common equipment installation problems found is with antennainstallation. The problems may include incorrect antenna type/orientation/tilt, faultycabling, and improper antenna mounting. Reasons for incorrect installation may includebut not be limited to subcontracted work, overworked or non-trained antenna crews. Toeliminate or reduce such occurrence each market should have specific guidelines tofollow. The engineer responsible for the optimization team should conduct random sitevisits to spot-check installations. All problems encountered should be entered into thePRM so they can be tracked and a CFE dispatched to the site if necessary. The engineershould also coordinate with antenna crews to ensure timely a timely installation schedule.

3.7 Exit CriteriaThe system engineer has verified the following for each BTS in the cluster (and first tiersurrounding sites at a minimum):

1. All BTS optimization/ATP tests have been completed.2. All the calibrations are correct.3. The calibration files are backed up to floppy and the OMCR.4. All modules are in service.5. The ITP has been successfully completed6. The site is on the air and working properly.


55

Appendix 3A: ITP Checklists

,73�7HVW�3ODQSite Name : ________________________________Site Number : _________________Site Model : _________________New [ ] Upgrade [ ] Expand [ ] Other [ ]

$OO�WHVWV�DQG�GRFXPHQWDWLRQ�DUH�VSHFLILF�RQO\�WR��QG &DUULHU�6HFWLRQ��9HULILFDWLRQ�DQG�+DUGZDUH�&RQILJXUDWLRQ

&RPSOHWH ,QFRPSOHWH 1$

$��)LOO�LQ�DWWDFKHG�FDUG�DXGLW >��@ >��@ >��@


%��9HULI\�DQG�RU�GLDJUDP�FDEOLQJ�� >��@ >��@ >��@��SHU�FXVWRPHU�GRFXPHQWDWLRQ

3DVV )DLO 1$

&��9HULI\�6SDQ�OLQH�KDV�EHHQ�LQVWDOOHG��DQG >��@ >��@ >��@��*/,V�FDQ�FRPPXQLFDWH�ZLWK�&%6&

'��9HULI\�DQWHQQD�WLOWV�DQG�D]LPXWKV 3DVV )DLO 1$

��)URP�1HW3ODQ 6HFWRU�� >��@ >��@ >��@��6LPXODWLRQ 6HFWRU�� >��@ >��@ >��@

6HFWRU�� >��@ >��@ >��@6HFWRU�� >��@ >��@ >��@6HFWRU�� >��@ >��@ >��@6HFWRU�� >��@ >��@ >��@

�6HFWLRQ��3LORW�31�2IIVHW�9HULILFDWLRQ

&DQ�EH�YHULILHG�ZLWK�'0 31�2IIVHW 3DVV )DLO 1$

6RPH�SKRQHV�PD\�EH�SXW 6HFWRU��BBBBBBBBBB >��@ >��@ >��@LQWR�WHVW�PRGH�DQG�XVHG�WR 6HFWRU��BBBBBBBBBB >��@ >��@ >��@YHULI\�31� 6HFWRU��BBBBBBBBBB >��@ >��@ >��@

6HFWRU��BBBBBBBBBB >��@ >��@ >��@6HFWRU��BBBBBBBBBB >��@ >��@ >��@6HFWRU��BBBBBBBBBB >��@ >��@ >��@


56

6HFWLRQ��&DOO�&RPSOHWLRQ�DQG�0&&�7HVWLQJ��3ODFH�FDOOV�WR�DQG�IURP�0762��

0RELO�WR�/DQG��HDFK�6HFWRU�� 3DVV )DLO 1$

7HVWV�PD\�EH�FRPELQHG�ZLWK �6HFWRU�� >��@ >��@ >��@�'LYHUVLW\��WHVWV� 6HFWRU�� >��@ >��@ >��@

6HFWRU�� >��@ >��@ >��@6HFWRU�� >��@ >��@ >��@6HFWRU�� >��@ >��@ >��@6HFWRU�� >��@ >��@ >��@

/DQG�WR�0RELOH��HDFK�6HFWRU�� 3DVV )DLO 1$

6HFWRU�� >��@ >��@ >��@6HFWRU�� >��@ >��@ >��@6HFWRU�� >��@ >��@ >��@6HFWRU�� >��@ >��@ >��@6HFWRU�� >��@ >��@ >��@6HFWRU�� >��@ >��@ >��@

0RELO�WR�0RELO��HDFK�6HFWRU�� 3DVV )DLO 1$



57

'LYHUVLW\��0RELO�WR�ODQG�FDOO�ZDV�VXFFHVVIXOO\FRPSOHWHG

3DVV )DLO 1$

��ZLWK�'LYHUVLW\�5;UHPRYHG

��6HFWRU�� >��@ >��@ >��@

��ZLWK�3ULPDU\�5;UHPRYHG

��6HFWRU�� >��@ >��@ >��@


6HFWRU�� >��@ >��@ >��@


6HFWRU�� >��@ >��@ >��@


6HFWRU�� >��@ >��@ >��@


6HFWRU�� >��@ >��@ >��@


��6HFWRU�� >��@ >��@ >��@


��6HFWRU�� >��@ >��@ >��@


��6HFWRU�� >��@ >��@ >��@


��6HFWRU�� >��@ >��@ >��@


��6HFWRU�� >��@ >��@ >��@


��6HFWRU�� >��@ >��@ >��@

&KDQQHO�(OHPHQWV��3ODFH�FDOOV�RQ�DOO�UHPDLQLQJ�FKDQQHO�HOHPHQWV�

1XPEHU�RI�0&&V��BBBBBBB � � � � � � � �1XPEHU�RI�6HFWRUV��BBBBB 0&&�� >��@ >��@ >��@ >��@ >��@ >��@ >��@ >��@

0&&�� >��@ >��@ >��@ >��@ >��@ >��@ >��@ >��@0&&�� >��@ >��@ >��@ >��@ >��@ >��@ >��@ >��@0&&�� >��@ >��@ >��@ >��@ >��@ >��@ >��@ >��@0&&�� >��@ >��@ >��@ >��@ >��@ >��@ >��@ >��@0&&�� >��@ >��@ >��@ >��@ >��@ >��@ >��@ >��@0&&�� >��@ >��@ >��@ >��@ >��@ >��@ >��@ >��@0&&�� >��@ >��@ >��@ >��@ >��@ >��@ >��@ >��@


>��@ >��@ >��@


58

�6HFWLRQ��5HGXQGDQF\�7HVWV��SHUIRUPHG�ZLWK�DQ�DFWLYH�FDOO�XS��*/,V��)LUVW�YHULI\�*/,��LV�,16�DQG�*/,��LV�,16�67%<�$��3XVK�UHVHW�EXWWRQ�RQ�*/,��IRUFLQJ�*/,��,16�DQG�*/,��226��YHULI\�ZLWK&%6&%��/RDG�DQG�(QDEOH�*/,��9HULI\�*/,��,16�67%<��&��3XVK�UHVHW�EXWWRQ�RQ�*/,��IRUFLQJ�*/,��,16�DQG�*/,��226��YHULI\�ZLWK&%6&%��/RDG�DQG�(QDEOH�*/,��9HULI\�*/,��,16�67%<��'��9HULI\�*/,��LV�,16�DQG�*/,��LV�,16�67%<�


>��@ >��@ >��@

�%%;V��)LUVW�YHULI\�DFWLYH�%%;V�,16�DQG�%%;��LV�,16�67%<�$��)RUFH�DFWLYH�%%;�226�DQG�%%;��,16�E\�SXOOLQJ�DFWLYH�%%;�RXW�RI�VORW�%��5H�LQVHUW�%%;��5HORDG�%%;��DQG�(QDEOH�%%;�&��9HULI\�%%;�LV�,16�DQG�%%;��UHWXUQV�WR�,16�67%<�'��5HSHDW�VWHSV�$��%��&�IRU�HDFK�6HFWRU� 3DVV )DLO 1$


6HFRQGDU\�7LPLQJ�6RXUFH�7DNHRYHU$��&RQQHFW�/0)�WR�00,�SRUW�RQ�&60��YHULI\�*36�$1'�/)5�WLPLQJ�VRXUFHV�%��'LVFRQQHFW�*36�$QWHQQD�IURP�WRS�RI�ED\�&��9HULI\�/)5�RU�+62�WDNHV�RYHU��DQG�WKDW�YRLFH�TXDOLW\�UHPDLQV�WKH�VDPH�RQFDOO'��5HFRQQHFW�*36�$QWHQQD�WR�WRS�RI�ED\�

3DVV )DLO 1$

>��@ >��@ >��@

3RZHU�6XSSOLHV��7KLV�WHVW�FDQ�DOVR�FRYHU�$ODUPV��QG�&DUULHU�RQO\��$��3XOO�3RZHU�6XSSO\��YHULI\��KROGV�XS�VKHOI��DQG�FDOO�UHPDLQV�WKH�VDPH�%��9HULI\�&%6&�UHFHLYHV�$ODUP�PHVVDJH�&��5H�LQVHUW�3RZHU�6XSSO\��DQG�YHULI\�&%6&�$ODUP�FOHDUV�'��3XOO�3RZHU�6XSSO\��YHULI\��KROGV�XS�VKHOI��DQG�FDOO�UHPDLQV�WKH�VDPH�(��9HULI\�&%6&�UHFHLYHV�$ODUP�PHVVDJH�)��5H�LQVHUW�3RZHU�6XSSO\��DQG�YHULI\�&%6&�$ODUP�FOHDUV�

3DVV )DLO 1$

>��@ >��@ >��@


59

6HFWLRQ��$ODUPV6/3$�PRGXOHV��6LWHV��QG�&DUULHU�RQO\�

$��3XOO�6/3$�PRGXOH�RQH�DW�D�WLPH��YHULI\�&%6&�5(&(,9(6�$ODUP�PHVVDJH�%��5H�LQVHUW�6/3$�PRGXOHV�DQG�YHULI\�&%6&�$ODUP�FOHDUV�

3DVV )DLO 1$


&60��%'&�5HGXQGDQF\�$��9HULI\�%'&��&60��DUH�LQVHUWHG�LQ�VORWV�%��+DYH�&%6&�EULQJ�%27+�&DUULHUV�GRZQ��/RDG�&60��%'&��'LVDEOLQJ�%'&��ZLOO�EH�HQRXJK��&��(QDEOH�&60��DQG�%'&��WKHQ�(QDEOH�%'&��'��+DYH�&%6&�(QDEOH�0&&V�DQG�%%;V�(��5HSHDW�VWHSV�$��%��&��'�WR�UHWXUQ�WR�&60��%'&��)��3XOO�RXW�&60��UHVHDW�/)5�WKHQ�UH�LQVHUW�&60�� 3DVV )DLO 1$

��7KLV�ZLOO�UH�HQDEOH�/)5�WUDFNLQJ�� >��@ >��@ >��@

0&&�$ODUPV��QG�&DUULHU�RQO\�$��3XOO�HDFK�0&&��RQH�DW�D�WLPH��9HULI\�&%6&�UHFHLYHV�DQ�$ODUP�PHVVDJH�IRUHDFK�0&&�%��5H�LQVHUW�HDFK�0&&�DQG�9HULI\�ZLWK�&%6&�$ODUPV�FOHDU

3DVV )DLO 1$

>��@ >��@ >��@

6HFWLRQ��+DQGRII�7HVWV 3DVV )DLO 1$ 3DVV )DLO 1$

$��6RIWHU�KDQGRII�IURP ��WR�� >��@ >��@ >��@ ��WR�� >��@ >��@ >��@��6HFWRU�WR�6HFWRU� ��WR�� >��@ >��@ >��@ ��WR�� >��@ >��@ >��@

��WR�� >��@ >��@ >��@ ��WR�� >��@ >��@ >��@��WR�� >��@ >��@ >��@ ��WR�� >��@ >��@ >��@��WR�� >��@ >��@ >��@ ��WR�� >��@ >��@ >��@��WR�� >��@ >��@ >��@ ��WR�� >��@ >��@ >��@


60

$QWHQQD��'LDJUDP��6KHHW6LWH�1DPH��BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB6LWH�1XPEHU��BBBBBBBBBBBBBBBBB6LWH�0RGHO��BBBBBBBBBBBBBBBBB1HZ��>��@��8SJUDGH��>��@([SDQG��>��@��2WKHU��>��@

��'UDZ�LQ�DOO�FRQQHFWLRQV�DQG�GHYLFHV�EHWZHHQ�%76�DQG�:DYH�*XLGH(QWU\�3RUW��9HULI\�WKDW�DOO�7UDQVPLW�DQG�5HFHLYH�5)�&DEOHV�DUH�FRQQHFWHG�WRFRUUHFW�DQWHQQDV�IRU�ZKLFK�WKH\�ZHUH�DVVLJQHG�WR��1RWH��FDEOHV�PD\�EH�GLIIHUHQW�WKDQ�WKRVH�VKRZQ�

%76��32576

'7$��

'7$��

'5$�

'5$�

'7%��

'7%��

'5%�

'5%�

'7*��

'7*��

'5*�

'5*��

'7$��

'7$��

'5$�

'5$�

'7%��

'7%��

'5%�

'5%�

'7*��

'7*��

'5*�

'5*��

$17(11$��32576


61

,73�,QYHQWRU\6LWH�1DPH��BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB6LWH�1XPEHU��BBBBBBBBBBBBBBBBBBBBBBBB6LWH�0RGHO��BBBBBBBBBBBBBBBBBBBBBBBBBB1HZ��>��@��([SDQG��>��@8SJUDGH��>��@��2WKHU��>��@

Card Name Part Number ATC Serial # Card Status CSM # 2 GLI # 3 GLI # 4 BDC # 3 BDC # 4 BBX # 5 BBX # 6 BBX # 7 BBX # 8

MCC # 21 MCC # 22 MCC # 23 MCC # 24 MCC # 25 MCC # 26 MCC # 27 MCC # 28

Power Supply # 3Power Supply # 4

LPA # 7 LPA # 8LPA # 9

LPA # 10 LPA # 11 LPA # 12

EXTRA CARDS Part Number ATC Serial # LOCATION


62

&HOOXODU�)LHOG�(QJLQHHU�6LJQDWXUH�BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB 'DWH��BBBBBBBBBBB

1HWZRUN�)LHOG�0DQDJHU�6LJQDWXUH�BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB 'DWH��BBBBBBBBBBB

Optimization Procedures and Guidelines, Ver 1.2Database Verification

63

4.0 Database Verification

4.1 DescriptionFigure 4.1-1 shows the relationship of this database verification activity to others withinthe network optimization flow. Database verification is the examination of key RF-related parameters. These parameters are defined by either the system design (e.g. SIFpower settings, neighbor lists) or network and equipment deployment considerations (e.g.ICBSC border placement). Parameter settings should comply with recommended,release-specific default parameters, which are available on-line. (See Section 4.2 forinformation on how to access these spreadsheets.)

Since the network optimization engineer may not be the same person who generates thesystem databases or participates in the system design review (Chapter 2), this is anopportunity to become more familiar with the network design intentions and verify thatthe systems database is appropriately configured for system optimization. After thevarious database input tables representing RF parameter settings and neighbor lists havebeen created and the MIB has been generated using database tools (such as Condor=CMTool), the information should be extracted from the system database and compared to theoriginal design intentions to verify it’s accuracy. In addition, the transcoder databaseshould be reviewed. Three basic sets of parameters are investigated in this activity: RFparameters, neighbor lists and supporting tables, and transcoder (XC) parameters.


64





(Chapter 3)


(Chapter 4)




(Chapter 9)







System Designvia


(Chapter5)


(Chapter 7)


(Chapter 8)

Figure 4.1-1: Relationship of Database Verification Activity to Entire OptimizationProcess


65

4.2 Tools RequiredThere are a variety of tools available to inspect and evaluate the system database settingsas listed in Table 4.2-1.

Item Description and Vendorshow_allparms script A script that compares the installed MIB to the recommended

default RF parameter settings and generates a report of thedifferences. To obtain the script, click on the scripts button at:http://www.rochellepark.pamd.cig.mot.com/~blashkar/bestpractices.html and choose the hyperlink for the correct version of the"Show Parameters" script by Dennis Helm to download. Thisscript also has the capability to provide differences between theinstalled databases examined on different days.

get_mib Script that extracts the MIB and creates an output file; used byXfreq. This script can be found athttp://www.rochellepark.pamd.cig.mot.com/software.html; clickon the xf-nbr.tar.Z link to download.

xtract7_nlist Script that extracts the neighbor list from the MIB; used byXfreq. This script is packaged in the xf-nbr.tar.Z file and can bedownloaded from the above link.

Xfreq Script that graphically displays neighbor lists and variousparameter settings. This script can be found athttp://www.rochellepark.pamd.cig.mot.com/software.html.

Compas_NL The Compas_NL tool will generate a file that can be read intoNetPlan. The neighbor list can then be displayed graphically. Formore information and to obtain this script, the URL is:http://www.cig.nml.mot.com/~spresney/Compas_NL/Compas_NL.html

Falcon Falcon is a Java-based, database visualization tool that providesinsight into the contents of the MIB. It can run on a variety ofplatforms. More information and a demo version of the script canbe found at http://www.pamd.cig.mot.com/~toolprod/falcon.

ParameterSpreadsheets[Matt Dillon]

Spreadsheet contains recommended default parameter settings foreach software release; URL:http://www.cig.mot.com/cdma_ase/index.html

System CommandsReference

Reference to all system commands, their syntax and sampleoutputs. This manual can be downloaded fromhttp://www.cig.mot.com/TED/docs.html click on the hyperlink"Online Product Documentation", choose the Supercell button,then the SC Product Family-CDMA button. Click on thehyperlink "OMCR/CBSC/SYSTEM" and then scroll down to"System Commands Reference".

Table 4.2-1: Database Verification Tools and References







http://www.pamd.cig.mot.com/~toolprod/falcon




66


Type Skill LevelSystems Engineer White Belt (See Appendix A)


4.4 Entrance Criteria1. The RF parameters, Sectop, XASect, and XCSect tables are completed and are loaded

into the system MIB. The XC database is installed as well.2. Review the “read_me” files for the current versions of scripts and tools which will be

used for any new information.3. A copy of all network design outputs for the system is available to use as a baseline

for database checks.4. A copy of the parameters spreadsheet for the system release being deployed has been

downloaded and printed for reference.5. A copy of the ITP data sheets is available from the equipment installation verification

activity (Chapter 3).

4.5 Procedure

4.5.1 MIB Parameter Audit

Appendix 4A contains reference information on how to use the show_allparms script tocollect the information required for this exercise.

4.5.1.1 System Wide Parameters

Install and run the show_allparms script and view the output files highlighting differencesbetween the MIB and the recommended default RF parameters. Any discrepanciesreported by show_allparms should be investigated to determine why they exist.Corrections should be made to the database as appropriate. Consultation with the systemdesign team or customer may be required. The show_allparms scripts will enable a quickcheck of the parameters listed below:

Call Processing:BusyidleUp, MmCpT3, MmCpT10, MMCpT11, MMCpT14, ToMMFep,PingMMfep, FepBundleflag, MM Bundling, FepMxWaitBundle.

4.5.1.2 BTS and Sector Parameters

Using the output report from the show_allparms script, evaluate any discrepanciesreported between the existing database and the recommended RF default parameters.Identify the reason for any discrepancies to determine if there is good reason to divergefrom the recommended default values. Consultation with the system design team orcustomer may be required. The following categories of parameters are evaluated byshow_allparms:


67

MAHO:T-ADD, T-DROP, T COMP, TTDrop.

MM N-Way:MaxActSetSz, MaxCEPPerCall, MaxBTSLegs1, MaxBTSLegs2, MaxBTSLegs3,Softer Shuffle Comp, Soft Shuffle Comp, BTS Shuffle Comp, Enable SofterShuffle, Enable BTS Shuffle, Enable Soft Shuffle, Num Candidate,SendHopermMess, ComplexShoENA.

XC N-Way:Aggr Active Set 1BTS, Aggr Active Set 2BTS, Aggr Active Set 3BTS,XCTComp, TcompEnaTrsh.

Neighbor Lists:NeighAssoc, SrchWinA, SrchWinN, SrchWinR, NghbrMaxAge.

Reverse Power Control:RPCMaxEbNo, RPCMinEbNo, RPCNomEbNo, RPCUpPFull, RPCUpPNFull,RPCDownP.

Forward Power Control, (Mobile):PwrRepThresh, PwrRepDelay, PwrRepFrames, PWRThreshEna, PwrPeriodEna.

Mobile Initial Power:NomPwr, InitPwr, PwrSet.

Forward Power Control CBSC/BTS:FwdPwrThresh, OrigDely, DeltaTime, StepDownDelay, OrigGain, FER_traget.

PPS Powers:PilotGain, PchGain, SchGain, SifPilotPwr.

Forward Traffic Channel Gain:MaxGain1Way, NomGain1Way, MinGain1Way, MaxGain2Way,Nomgain2Way, MinGain2way, MaxGain3Way, NomGain3Way, Mingain3Way,MinPcbGainFact, StepUp, StepDown.

Access Channel:AccTmo, AchPaml, AchPamEbNo, AchPamWinSz, cell Radius, NumStep,MaxCapSz, PamSz, Psist0to9, Psist09, Psist10, Psist11, Psist12, Psist13, Psist14,Psist15. MsgPsist, RegPsist

Reverse Traffic Channel:TchPamEbNo, TchPamWinSz, TchPamlper, TchAcqWinSz, TchAcqEbNo,TchAcqlPer, TchMpthWinSz, TchMpthebNo, TchMpthlper, MccCpT1.

____________________________________________________________________


68

4.5.1.3 SIF Pilot Powers and Antenna Tilt/Azimuth

SIF Pilot Powers

Using the outputs from the network design activity (Chapter 2), evaluate the installedvalue of each sector’s SIF pilot power to ensure that the value matches therecommendation provided by the system design activity. The show_allparms script byDennis Helm also shows the SIF pilot powers by CBSC. As an alternative, to obtain theSIF pilot powers on a per BTS/sector basis from the MIB, log onto the OMC-R, open aCLI window and type the command "disp carrier-bts#-sector#-carrier# ppsgain". Theitems in bold are to be typed as shown, the items in italics need to be filled in with thecorrect BTS #, sector # and carrier #. To learn more about this command, see the SystemCommands Reference, Volume 3, Chapter 11.

Antenna Tilt and Azimuths

At this time it would be convenient to use the ITP data sheets collected during theequipment installation verification activity (Chapter 3) to verify that the installed antennatilts match the system design tilts. Proceed through each site and sector and confirm thatthe installed tilt angle on each sector is identical to the desired simulation activity output.Note any discrepancies for future reference.

4.5.1.4 Neighbor List Check

4.5.1.4.1 Neighbor List (Sectop) CheckThree tools are available for reviewing the network neighbor list. These tools are:• Compas_NL• Xfreq (in conjunction with extract7_nlist and get_mib)• FalconThe intent at this starting point of the network optimization cycle is to ensure that theinstalled neighbor lists meet the intent of the system design and make sense from apractical perspective (do they pass the “common sense” test).The tools listed above can be used to graphically display the network neighbor lists.Select one of the tools to facilitate this audit, and proceed using the following basicchecklist to prioritize the initial neighbor lists:

- Adjacent sectors at the same site should be included in each other’s neighborlists, and be positioned at the top of the list. For six sector system, sectors onthe other side of the site should be maintained, in general, in the top 11 entriesin the neighbor list.

- Sectors pointing towards each other should be in each other’s neighbor lists.- Sectors pointing into the same coverage areas should be in each other’s

neighbor lists. These should be prioritized based upon amount of coverageoverlap.

- Special cases may include:- Sectors facing in the same direction (azimuth) where one sector overshoots

another site: If there is desired coverage overlap, then the sectors should be


69

neighbored. (E.g., This may be typical of sites that are at the base of amountain, and are only one tier away from each other.)

- Sectors separated by terrain obstacles: For example, if there are two clusters,but they are separated by a mountain range and could not enter into softhandoff with each other because their coverage footprints do not overlap,there is no need to put them in each other’s neighbor lists. Make use of theelevation data in NetPlan using the Profile function to confirm any terrainobstacles, or use the Best Server Ec/Io image to determine whether coveragefootprints overlap.

Additional checks for neighbor list development are listed here:

- Verify that reciprocal neighbors are entered into each other’s sectors neighbor lists.- Verify that neighbors for a specific sector are within the cell radius limits (eliminate

distant neighbors).

4.5.1.4.2 Neighbor List Support TablesIn addition to the sectop tables, there are related tables whose configuration must beconsistent with the neighbor lists to facilitate various types of handoffs. These handoffsinclude D-to-A, D-to-D (inter-CBSC Soft Handoff and CBSC anchor handoffs), multi-carrier handoffs, and inter-EMX handoffs. The discussion of each type of handoff isbeyond the scope of this chapter; however, high level guidance, including specificreferences and tools that may be used are discussed below to facilitate the investigationand verification of these database entries. More specific guidelines are planned forreleases of this document.

XASect and XCSect VerificationThe Falcon tool is intended to graphically display various portions of the database and dosanity checks on linkages contained within the MIB. This should enable consistencychecking of XASect and XCSect tables for systems that are configured to use thesedesignations.

Inter-CBSC Soft and Anchor Handoff ConfigurationsTables required for inter-CBSC soft handoffs are discussed in the ICBSC application noteat http://www.pamd.cig.mot.com/nds/cts/rftech/App_Notes/icsho/. Select the hyperlinkentitled “icsho_CAN_v0_1.fm”. A brief list of the most important checks forimplementing XASects and ICBSC-SHO and anchor handoffs is included here:

1. XCSects must have their HandoffMethod indicator set to Soft_Trunking. Also, theHOOverride attribute associated with parent ICTRKGRP (identified in the XCSect)must be set to No_Override.

2. The Outward Route Index (ORI) for a XCSector should be non-zero, indicating therewill be outward route traversal.

http://www.pamd.cig.mot.com/nds/cts/rftech/App_Notes/icsho/


70

3. The AnchorHoMethod is set at a CBSC level to one of four choices: No_Legs,Legs_Remote, No_Legs_Wait, or Keep_Soft (Simple).

4. A value for OmcGroup must be provided for all OMC-R. The value may range from1-8 and up to 8 CBSCs may be in each group.

5. The SELECTMODE parameter is set for either Round_Robin or Top_Bottomresource allocation.

More information on these checks, as well as additional CLI commands and databaseconfigurations, can be found in the section "Database Configuration" in the chapterentitled "Implementation" of the Inter-CBSC Soft Handoff Cellular Application Note.

Configuring the following EMX database tables facilitates inter-EMX handoffs (foundalong some CBSC borders) if the anchor handoff method is not set to Keep_Soft:

1. The BSS BSSRTE database entry on the EMX contains the Destination Point Code(DPC) for A+ messaging and the BSS Trunk Group for the Terrestrial Circuits to thetarget BSS.

2. The BSS CELRTE database entry on the EMX tells the target EMX where to find thetarget BTS. This entry will point to the BSS BSSRTE above, giving the EMX therequired information to send A+ messages and set up Terrestrial Circuits to thecorrect target BSS.

These tables should be evaluated for accuracy. Reference documentation to enable thisinvestigation is included in the section "EMX Commands" in the chapter titled"Implementation" of the Inter-CBSC Soft Handoff Cellular Application Note.

It is advisable to always check the FYI’s concerning ICBSC-SHO at the following webpage: http://www.pamd.cig.mot.com/nds/cts/rftech/App_Notes/icsho/icsho.html#fyis forthe latest information.

Multi-carrier ConfigurationsDatabase configurations for multi-carrier operation, in particular pilot beacon or DAHOdatabase setup can be investigated by referring to the Multi-carrier Cellular ApplicationNote. This can be found at:http://www.rochellepark.pamd.cig.mot.com/~fcleary/appnotes.html

4.5.2 XC Parameter Audit

Appendix 4B contains a detailed procedure on how to access and examine specifictranscoder related parameters. Using this procedure, the following XC parameters shouldbe verified:

XcHoT7, XcHoT1, XcHoT5, XcHoT3, XcHoT6, XcHoT2, XcHoT5, HHORetryCnt,PMRM_Threshold, handoff_mode, XC State1 - XC State 11, XcSoT7, XcSoT8,Acquisition Count, Fast Repeat, Max Retry, RF Loss Count, Retry Timer Count



71

4.6 Analysis ConductedIf any parameters are set differently in the database than the recommended defaultparameters or desired system design parameters, or there are any problems identified inany of the database tables, these discrepancies should be documented. Following thatreporting, analysis must be done to discover the reason for the discrepancy. Errors notmeeting the intent of the network design activity or desired default parameters should becorrected. Some parameters may be different from the recommended default because ofoptimization done in the simulation domain (e.g. SIF pilot powers). SIF powers shouldbe checked against the system design. All discrepancies that have been documentedshould be worked off in the form of a punch list until all parameter settings are acceptableand agreed upon. Neighbor lists and supporting table issues should be resolved in asimilar manner. Transcoder database values should be verified as well.

4.7 Exit Criteria

- All RF parameter checking script output reports have been reviewed to identifydiscrepancies between the installed MIB and the recommended default parameters.

- Any errors have been identified and the parameters have been corrected.- Any settings not meeting the intent of the system design have been corrected.- Any missing neighbors have been added to the neighbor list.- Any undesired neighbors have been deleted from the neighbor list.- All handoff tables and settings, including XASect and XCSect, AnchorHoMethod,

ORI, BSSRTE, CELRTE should all be set correctly to facilitate inter-CBSC soft andanchor and inter-EMX handoffs as required.

- The transcoder database has been investigated and deemed appropriate for thisnetwork design.

4.8 Recent DevelopmentsA new database visualization tool will be available in early March, 1999. This tool iscalled Falcon. Information on Falcon can be obtained by going to:http://www.pamd.cig.mot.com/~toolprod/

http://www.pamd.cig.mot.com/~toolprod/


72

APPENDIX 4A: show_allparms usageThis information has been recreated from “RF Database Audit Procedure”, February 5,1999, Dennis Helm.

Note: For each OMCR release and vocoder rate, there is a version of 'show_allparms'.Verify that the correct version of 'show_allparms' is being used.

Execution of Script

1. All of the RF-audit tools will be located in the 'rf-audit' directory. If this directory doesnot exist then create it by typing the following command:

omcr scadm}$ mkdir rf-audit

2. Copy show_allparms to /home/scadm/rf-audit of OMCR.

3. Change permissions to make the script executable:

omcr scadm}$ chmod +x show_allparms

4. Execute script:

omcr{scadm}$ show_allparms

5. Evaluate output. The following are the output files that are generated by'show_allparms':

<date>.allparms.out

This file is comma delimited ASCII text and can be easily imported into Microsoft Excel.See the example below.

diff_rec.out

The file 'diff_rec.out' contains all of the parameters that are not set as per (Dillon's)default spreadsheet as shown in the example below. The audit engineer should be readyto discuss these parameter changes with the customer. A good reference document isMatt Dillon's 'Parameter and Optimization Guide' located at the following web site:

http://www.cig.mot.com/~dillon

All differences should be noted in a final report along with parameter descriptions.

http://www.cig.mot.com/~dillon


73

Example of diff_rec.out script:

The Recommend values are listed as the first row of each SectionThe values are from Dillons’ spreadsheet dated 10/16/97These recommended values are based on a 13k Vocoder and MCC-8 systemThese parameters are listed in parenthesisBTS-SEC PARAMATER = Current Value (Recommended Value)2-2-1 TTDROP=2 (3)7-1-1 TDROP=-15 (-16)10-1-1 TTDROP=2 (3)12-2-1 TTDROP=4 (3)16-1-1 TTDROP=2 (3)16-1-1 SRCHWINA=7 (6)7-3-1 CELLRADIUS=5.7 (10)8-2-1 CELLRADIUS=8.6 (10)9-2-1 CELLRADIUS=11.5 (10)8-2-1 TCHPAMWINSZ=75 (25)58-1-1 TCHPAMWINSZ=66 (25)

Example of <date>.allparms.out script:

The Recommend values are listed as the first row of each SectionThe values are from Dillons’ spreadsheet dated 10/13/97These recommended values are based on a 13k Vocoder R7 system

BTS,SEC,CAR,PILOTPN,TADD,TCOMP,TDROP,TTDROP,SRCHWINA,SRCHWINN,SRCHWINR,NGHBORMAXAGERec,Val,,,-14,7.5,-16,3,6,8,9,01,1,1,174,-14,7.5,-16,3,6,8,9,01,2,1,180,-14,7.5,-16,3,6,8,9,01,3,1,177,-14,7.5,-16,3,6,8,9,02,1,1,255,-14,7.5,-16,3,6,8,9,02,2,1,261,-14,7.5,-16,2,6,8,9,02,3,1,258,-14,7.5,-16,2,6,8,9,03,1,1,246,-14,7.5,-16,3,6,8,9,03,2,1,252,-14,7.5,-16,3,6,8,9,03,3,1,249,-14,7.5,-16,3,6,8,9,0


74

APPENDIX 4B: Procedure to Evaluate Transcoder Parameters

(Taken from Application Note entitled “Changing Transcoder Parameter Procedure” by Jim Woeste.)

Step 1)

Open a window on the X-Term and at the scadm prompt (in the /home/scadm/rf-auditdirectory) type the following command:

tqcomm a0 9600

Wait a couple of seconds and hit the <RETURN> key until you see the following XCprompt.

Cust BSS MMI-0115->

The above prompt tells you that you are entering the XC through the OMP by thenumbers 0115 at the end of the prompt. The OMP is located in Cage 0 slot 20 in everyXC. If you see another number at the end of the prompt you should exit your tqcommsession by typing the following at the XC prompt (0XXX).

Cust BSS MMI-0XXX-> ; Cust BSS MMI-0XXX-> q

Move your RS-232 cable from whatever GPROC it is on to the RS-232 connector on theOMP and type in the tqcomm command again at the scadm prompt. Once you see the0115 prompt type in the following commands.

Cust BSS MMI-0115-> ; (; asks you for a command) Cust BSS MMI-0115-> l (l is the command for logging)

Starting logging.

Log File : rf_xc_audit.out Log file created. Logging on.

You may lose your prompt for a second but keep hitting <RETURN> until it comes back,(usually a few seconds after entering the log file name). Once you see the prompt againproceed to Step 2).

Step 2)

Once you see the prompt again type:

Cust BSS MMI-0115-> chg_lev


75

Enter password for security level you wish to access: 5cardstud (if 5cardstud doesn’t work try the following)Enter password for security level you wish to access: 3stoogesEnter password for security level you wish to access: 4beatles (The 3stooges password will prompt you for the 4 beatles password)5cardstud (as well as the other 2 passwords) will not be displayed when you enter it. Thiswill give you security level 3 access (which is unlimited access). You will need to havesecurity level 3 access to display the set_state_timeout values on the XC.

Step 3)

To display the call processing parameters, type the following command at the XCprompt:

Cust BSS MMI-0115-> disp_cp_params

This will give you the following XC parameters.Call processing timers: XcCpT2, XcCpT5Handoff timers: T1, T3, T5, T7, T6

Step 4)

The set_state_timeout command provides you with each of the State Timer values on theXC.

DO NOT ENTER A VALUE WHEN YOU SEE THE PROMPTS WITH THECURRENT SETTING IN THEM UNLESS YOU ARE MAKING A CHANGE. IF YOUJUST WANT TO DISPLAY THE CURRENT SETTING THEN HIT ENTERWITHOUT ENTERING A VALUE. A PROMPT WITH A CURRENT VALUE ISSHOWN BELOW AS AN EXAMPLE.

Enter the Timeout Value (0-86399999 in ms)(cur = 2500 ms):

The set_state_timeout command will only allow you to view one State Timer at a time;therefore, you will need to enter the command 11 times. Each time you re-enter thecommand you will be prompted for the State Timer you wish to display/change. See theexample below for the command sequence as well as the current settings in Lombard.Notice that this only displays the values and does NOT change them in the examplebelow.

Cust BSS MMI-0115-> set_state_timeout Enter the CDMA CP State Number (0-20): 1 Enter the Timeout Value (0-86399999 in ms)(cur = 2500 ms): Cust BSS MMI-0115-> set_state_timeout Enter the CDMA CP State Number (0-20): 2 Enter the Timeout Value (0-86399999 in ms)(cur = 5000 ms):


76

Cust BSS MMI-0115-> set_state_timeout Enter the CDMA CP State Number (0-20): 3 Enter the Timeout Value (0-86399999 in ms)(cur = 7000 ms): Cust BSS MMI-0115-> set_state_timeout Enter the CDMA CP State Number (0-20): 4 Enter the Timeout Value (0-86399999 in ms)(cur = 5000 ms): Cust BSS MMI-0115-> set_state_timeout Enter the CDMA CP State Number (0-20): 5 Enter the Timeout Value (0-86399999 in ms)(cur = 5000 ms): Cust BSS MMI-0115-> set_state_timeout Enter the CDMA CP State Number (0-20): 6 Enter the Timeout Value (0-86399999 in ms)(cur = 5000 ms): Cust BSS MMI-0115-> set_state_timeout Enter the CDMA CP State Number (0-20): 7 Enter the Timeout Value (0-86399999 in ms)(cur = 5000 ms): Cust BSS MMI-0115-> set_state_timeout Enter the CDMA CP State Number (0-20): 8 Enter the Timeout Value (0-86399999 in ms)(cur = 5000 ms): Cust BSS MMI-0115-> set_state_timeout Enter the CDMA CP State Number (0-20): 9 Enter the Timeout Value (0-86399999 in ms)(cur = 5000 ms): Cust BSS MMI-0115-> set_state_timeout Enter the CDMA CP State Number (0-20): 10 Enter the Timeout Value (0-86399999 in ms)(cur = 2000 ms): Cust BSS MMI-0115-> set_state_timeout Enter the CDMA CP State Number (0-20): 11 Enter the Timeout Value (0-86399999 in ms)(cur = 10000 ms):

Step 5)

To verify that all layer 2 parameters are set correctly type the following command at theXC prompt.

Cust BSS MMI-0115-> Cust BSS MMI-0115-> disp_l2_paraEnter the XCDR identifier (0 - 85): 0 <--- Where the XCDR identifier is the XCDR cardnumber. This implies that for each XCDR card in your system you will need to repeat thedisp_l2_para command.

Step 6)

You can end your tqcomm session by typing the following command at the XC prompt.

Cust BSS MMI-0115-> ; Cust BSS MMI-0115-> q


77

Your prompt should now be the same type of scadm prompt on the X-Term window thatyou had before the tqcomm session began. Your logfile from the tqcomm session shouldbe in the UNIX directory you are located in (/home/scadm/rf-audit). Type l’s at the scadmprompt to see the logfile you created.

----------------------------------------------------------

----------------------------------------------------------

NOTE: IF YOU HAVE PROBLEMS GETTING THE TQCOMM SESSION TO WORK- PERFORM THE FOLLOWING STEPS. MAKE SURE THAT THE REASON YOUARE UNABLE TO START A TQCOMM SESSION IS NOT DUE TO HAVING MORETHAN ONE TQCOMM SESSION OPEN AT THE SAMETIME.

STEP 1. Type at the scadm prompt, the commands in bold below.

lombardomc2{scadm}$ cd /bin

lombardomc2{scadm}$ cfreset asynch# port#

Where # in the asynch# word is the asynch card your are using on your OMCR.

Where # in the port word is the port number on the asynch card your are using

Usually the asynch# word is asynch0 and the port# word is port0

Example;

omc{scadm}$ cd /bin

omc{scadm}$ cfreset asynch0 port0

STEP 2. Now try using the tqcomm command to access the Transcoder. If your stillunable to get a transcoder prompt then try the following process.

A) Remove the RS-232 cable/connector from the OMP.B) Using another RS-232 cable, hook up a dumb terminal to the OMP before turning the

dumb terminal on.C) Turn the dumb terminal on. XC Alarms should be scrolling across the screen. You have

successfully unlocked the RS-232 port for communication with the OMCR.D) Un-plug the new RS-232 cable and hook up the old RS-232 cable/connector. The

TQCOMM session should work fine. If not, call MSCS and open a call log.

Optimization Procedures and Guidelines, Ver 1.2Spectrum Clearing, Noise Floor Test Verification, and Noise Monitoring

78

5.0 Spectrum Clearing, Noise Floor Test Verification,and Noise Monitoring

5.1 Description

The purpose of spectrum clearing is to eliminate any non-CDMA RF interference on theforward and reverse CDMA links throughout the area of network operation. Thepresence of any additional noise in the network could adversely impact the coverage andcapacity of a CDMA cell. It is possible that the spectrum targeted for CDMA operationhas not been cleared of AMPS channels operation (in the 800 MHz band). This may bemore of an issue in areas where CDMA operation is targeted, but immediately adjacentareas of operation are still using some of the CDMA channels for AMPS operation.Similarly, in the case of PCS or non-domestic systems, existing microwave or otherspectrum users need to be cleared from the frequency band that CDMA is targeted tooperate in.

Since it is the customer’s responsibility to ensure that spectrum is clear, the focus of thischapter is to provide a description of key indicators that signal increasing levels ofinterference which would trigger follow up spectrum clearing or noise floor testingactivities at particular sectors or sites. These triggers should be monitored during SCFT(Chapter 7) and beyond through the entire optimization activity and into commercialservice. Once a problem is identified, via examination of either system data (alarms) ordrive test data, the procedure referenced in this section can be used to further characterizethe interference at a particular cell site or sector. Figure 5.1-1 (next page) shows therelationship of the initial spectrum clearing verification to other optimization activities.After that, the monitoring techniques presented in this chapter can be used to continuallyidentify noise in the network.


79





(Chapter 3)


(Chapter 4)




(Chapter 9)







System Designvia


(Chapter5)


(Chapter 7)


(Chapter 8)

Figure 5.1-1: Relationship of Spectrum Clearing Activity to Entire OptimizationProcess


80

5.2 Tools RequiredThe tools listed in Table 5.2-1 can be used to detect and isolate noise or interference-induced problems.

Item Description or Vendor

Compas Used to evaluate DM and SMAP data. See Chapter 6 (ToolsSelection) for more information

Event LogsProvide a history of possible service affecting conditions. See“System Performance Monitoring Guide”. (Separate document.)

banditview

Recently developed tool can be found at:http://www.cig.nml.mot.com/cdma/kctopt/tools/. Generates a view ofBBX Balance and BBX Reverse Noise Rise Alarms for a particularsite over a given hour of operation. Input is event logs.

SMAP http://scwww.cig.mot.com/~thakkar/smap.html

Table 5.2-1: Interference Isolation Tools

In the event that a problem is identified at a certain site or sector, the actual procedure forperforming noise floor testing is entitled “CDMA Uplink Noise Survey Procedure”. Thisprocedure can be located athttp://www.rochellepark.pamd.cig.mot.com/~blashkar/bestpractices.html under the RFPlanning option. This document contains specific references to equipment used at a cellsite to characterize the noise. Substitution of specific equipment may be necessary tocompensate for differences in frequency and equipment variations from market to market.


Type Skill LevelRF System Engineer, to oversee noisemonitoring and elimination activities

White Belt (See Appendix A)

Cellular Field Engineer, to execute NoiseFloor Test Procedure

See Appendix A

CBSC Engineer, to monitor noiseindicators

See Appendix A


The number of locations to have noise floor testing performed will dictate the number ofteams and the time required to complete this test. For further information, pleasereference the “CDMA Uplink Noise Survey Procedure”.

5.4 Entrance CriteriaThe activity of noise monitoring should commence once the customer has indicated thatthe spectrum has been cleared to the best of his ability, and the system is ready foroperation. In general, the following are triggers or inputs that could be used to trigger theexecution of the noise survey procedure at a cell site/sector:





81

1. Interference may be identified by excessive BBX Balance or BBX Reverse NoiseRise Alarms in the event logs generated at the OMC-R.

2. Drive data from SCFT or optimization activities may indicate that the forward orreverse link is suffering from high FER. This may include temporal variations ofnoise levels, which are more difficult to isolate.

3. Status report from the customer that indicates the spectrum clearing results. This willidentify any area that the customer was unsuccessful at identifying and eliminatingany potential interferers. The service provider should be able to migrate his usersfrom the band being cleared to other AMPS channels. However, there is no guaranteethat the system being installed will not be subject to intersystem interference-especially along boundaries where the service provider has not cleared the CDMAband of analog users in immediately adjacent geographic areas. (This type ofscenario may be encountered when a service provider wants to offer CDMA servicein a core area, then expand the CDMA system boundaries on a piecemeal basis.) Noris there any guarantee for new spectrum allocations that there will be no illegalspectrum users once the band is “cleared” of traditional analog users. The customermay require assistance in characterizing the noise sources.

5.5 ProcedureIdentifying areas affected by interference can be accomplished by either monitoring theBBX Reverse Noise alarms or BBX Balance alarms that appear on the system, or viaactive drive testing. Noise present on the forward link does not confirm noise on thereverse link, and vice-versa. Each condition must be checked separately.

5.5.1 Forward Link Noise

Drive testing with either a mobile or spectrum analyzer is the only method that willidentify noise present on the forward link. A typical scenario of finding noise on theforward link will be consistent or intermittent call failures at a specific location coupledwith increase in Mobile Receive (MobRx) levels, elevated FER, and degraded Ec/Io onthe forward link. If this happens, the engineer should consult with the customer todetermine if the area is a known problem (interference) area. If the noise source isunderstood, then it should be documented so no more time is wasted on this area. If thenoise source is not understood, the engineer should investigate with a directional yagiantenna feeding into a spectrum analyzer tuned to the CDMA band of interest to isolateand identify the source of interference. If the type of interference can be characterized,this information should be provided to the customer organization to eliminate theinterference. (In the case of forward link interference, it is not necessary to execute thenoise floor testing procedure at a cell site.)


82

5.5.2 Reverse Link Noise

The most efficient method to identify noise issues on the reverse link is to performroutine checks of the alarms. The use of alarm data to trigger and justify the effort toexecute the noise floor testing is discussed in Section 5.6.1.

A new tool to identify presence of excessive noise on the reverse link is calledbanditview.

The only drawback with using alarms is that noise levels must exceed specific thresholdsbefore the alarms are triggered and recorded in the event log. There may be other noisepresent, but not enough to register the alarms.

Alternatively, SMAP provides both main and diversity RSSI data for all the three/sixsectors. This helps to ensure that the spectrum is clear of any unwanted noise on theCDMA band before putting any commercial traffic on the system. SMAP providesreverse link frame erasure rates (FER) can be collected during drive test activities. Themobile must be in Markov mode in order to collect valid SMAP Reverse FER data.Follow the guidelines in the SMAP documentation to set up the proper SMAP profiles tocollect RFER data for the Markov mobiles used during the drive. (In areas near ICBSCborders, note that Markov calls will not perform ICBSC handoffs.) The usage of SMAPdata to trigger the noise floor investigation is described in the Section 5.6.2.

It also helps to determine if main and diversity antennas are connected properly. Anexample of problem solved is that inadvertently many times during installation cables areswapped and sometimes two diversity antennas are swapped. Although system engineerscan indicate that main Rx antennas are swapped by looking at a PN value, they cannotconfirm if diversity antennas are swapped without using SMAP because there is no suchtool that can show this data.

For information on running SMAP go tohttp://scwww.cig.mot.com/~thakkar/smap.html

5.6 Analysis Conducted

5.6.1 Use of (Reverse Link) Alarm Data to Trigger Noise Survey Procedure

An increase in the number of BBX Reverse Noise alarms or BBX Balance alarms is aprimary indication of interference on the system. This information can be obtained fromthe system event logs. The event logs are located at the CBSC on the OMC-R in the/sc/events directory.

Alarms are time stamped so it is possible to check for interference during a specificperiod(s) of time. This information should be monitored over a period of time tocharacterize alarm variations. The alarm variations should direct selection of times tovisit cell sites for noise floor testing. A few days or a week should be a sufficient amountof time to establish noise trends.



83

A script called “banditview” can provide an indication of the number and severity ofBBX Balance and BBX Reverse Noise Rise Alarms for any given hour of operation.This tool can be used in conjunction with drive testing. If interference is suspectedduring a specific period of time in a specific location, this script will report alarmconditions on a BTS/sector during a specific hour for the script user. This script isdescribed in Section 5.8 (Recent Developments), and can be retrieved from:http://www.cig.nml.mot.com/cdma/kctopt/tools/.

For more information on long term monitoring of the network’s event logs please refer tothe “System Performance Monitoring Document”, section TBD “Event Logs”.

5.6.2 Use Of (Reverse Link) SMAP Data To Trigger Noise Survey

The engineer can use the SMAP (System Monitoring Application Processor) datagenerated by any Markov mobile specified in the SMAP profile to identify poor RFER.The engineer should look at the RFER data (either plotted using a tool such as COMPASor looking directly at the SMAP messaging) to identify areas that are worse than 3 to 5%.He should also look for areas that may have poor Mobile Transmit (MobTx) values orinstances when the MobTx approaches maximum power then falls to < –30 dBm (mobileshuts off) as either case may indicate interference.

If areas of interference are identified the engineer should request that a CFE performnoise floor testing at specific BTS/sector(s) surrounding the problem area. Use the“CDMA Uplink Noise Survey Procedure” document. These procedures are specific toconversion of an 800 MHz system from analog to CDMA operation. For differentsystems, appropriate modifications should be made to the equipment setups andfrequencies investigated. Results of the noise floor survey should be discussed with thecustomer to identify an appropriate resolution plan.

5.7 Exit CriteriaNoise monitoring is an ongoing activity. At this stage (prior to start) of the optimizationcycle, it is important to verify that:

- Spectrum is cleared if any previous analog users or other system users.- Adjacent geographic areas are cleared of CDMA band analog users.- Any noise floor testing procedures that have been executed by CFEs is shared with

optimization engineering team. Any interference problems during this testing havebeen resolved.

5.8 Recent Developments

5.8.1 The banditview Script

5.8.1.1 Description

Given a specific BTS number, the event logs containing information for that BTS, and aspecific time of interest (in hours) as inputs, the banditview script will provide a



84

graphical view of "BBX Reverse Noise Rise Alarms" and "BBX Balance Alarms" forthat specific time period. The BBX reverse noise rise alarms and BBX balance alarmscan help spot potential interference from any external or equipment inband sources ofnoise in a specified area. This interference is expressed in terms of a “bandit index”. Thisindex can be calculated for an area with the following formula:

Using banditview, count the number of minutes in which BBX alarmswere reported for a specific hour and CBSC. Then total the minutes forall sectors under the given CBSC. Divide the total by the number ofsectors. The result will be a number between 0 and 60. Since this is arelative measurement, depending upon the number of users and externalinfluence, a baseline should be developed and then tracked against.

5.8.1.2 Usage

This is a UNIX script. The command line is:<directory containing script>/banditview <bts> <eventlog>

where:bts = the specific BTS numbereventlog = the event log for the specific hour (e.g. evt.19990418010005,year/month/day/hour). If necessary, provide the path to the event log location.

5.8.1.3 Output

The X axis represents time in minutes over one hour and should be read vertically (e.g.first time is 00, second 05, third 10, etc.), and the Y axis represents the Sector andCarrier.

An example of the output follows:

(*------- BBX Noise and Balance Alarm Report for Site 000 -------*)

No Noise = . Noise Rise Alarm = o BBX Balance Alarm = O

Time 0 0 1 1 2 2 3 3 4 4 5 5 5BBX 0 5 0 5 0 5 0 5 0 5 0 5 9--- +----+----+----+----+----+----+----+----+----+----+----+----+1 ….oo…..oo.0……….ooooooooooooo….oooo….000…ooo2 ………..oooooooooo…0000…ooo.000000000000000….ooo003 ………….0000000000…………………………ooo….4 ………..oo…oo…ooo…ooo….ooo..ooo…..ooooooo…..o5 ..oooooooooooooooooooooooo………ooooooooooooooooo…….6 ……….oooooooooooooooooooooo…….oooooo…..ooo….ooo21 oooooooooooooooooooooooooooooooooooooooooooooooooo………22 oooooooooooooooooooooooooooooooooooooooooooooooo………..23 ……………………………………………………………24 ooooooo….oooooooo….oooooooooooo…….……………25 .o.o.o.o.oooooo.oooo.o.oo.ooo.o.o………ooooooooooooooooo


85

26 oooooooo..ooooooooooo…….ooooooooooo.ooooooooooooooo…..

Figure 5.8-1: Output of banditview script

5.8.1.4 CreditsThis script was written by Jonathan Hutcheson of MJL.

Optimization Procedures and Guidelines, Ver 1.2Tools Selection, Installation, and Test

86

6.0 Tools Selection, Installation, and Test

6.1 DescriptionThe purpose of this section is to offer guidelines for selection of CDMA data collectionand analysis tools used in the RF optimization of the CDMA system. Motorola and othervendors are constantly upgrading their product offerings. Many of these offerings arecaptured in this chapter for reference. Each account team should use the guidelines andreferences within to select the tools to meet their specific deployment requirements. Therelationship of this activity to other network optimization activities is shown in Figure6.1-1 below.

Figure 6.1-2 shows an overview of the general classes of data collection and analysistools that are used during network optimization activities. Some of the tools or scriptsused to collect and analyze data Motorola products or created by Motorola employees.Typically, these tools operate on proprietary or customer sensitive data outputs of thesystem. Some classes of tools, such as mobile diagnostic monitors, are more generic, andmay be procured from any number of vendors. Appendix 6A contains more detailedinformation on both Motorola and non-Motorola tools. (All tools should come withinstallation and operation guides. The details of installation, test, and operation for eachtool are beyond the scope of this discussion. Please refer to specific tool documentationfor necessary information.)


87

N etw ork D esign V erification(C hapter 2 )

O ptim iza tion Preparation

N etw ork O ptim ization

E quip m ent Insta lla tio nand T est V erificatio n

(C hapter 3)

R F Param etersD atabase V erificatio n

(C hapter 4)

D ata C ollec tion andA nalys is T oo ls

Se lec tion, Insta ll, Test(C hapter 6)

System O ptim izatio n andD eta iled P rob le m R eso lu tio n

(C hapter 9 )

F ina l C o vera geS urvey a nd

W arra nty Testing(C hapter 10)

S yste m O pera tions(C hapter 11)

C om m ercia l Serv ice :N etw ork Perform a nce

M onito ring a nd E xpansion(C hapter 11)

A cc urate Terra in,C lutte r,X los T uning D ata

S yste m D esignvia

N etP la n/C SSSSpectru m C learing

(C hapter5 )

S ingle C e llFunctio na l Test

(C hapter 7)

In it ia l C o verageT est

(C hapter 8 )

Figure 6.1-1: Relationship of Tools Selection, Installation and Test Activity to EntireOptimization Process


88

;& 00

&%6&

60$3

%76 %76

(0;

20&�5

&DOO�3URFHVVLQJ6&$3�'HEXJ

�UHVLGHV�RQ�00�

6\VWHP�&RPPDQGVIRU�GLVSOD\LQJ�VWDWXV

30�'DWD

30�'DWD�GLVSOD\VFULSWV��ZHE�EDVHGSHUIRUPDQFH�UHSRUWV

0RELOH'LDJQRVWLF0RQLWRU 06

&'/$QDO\VLV7RRO

&'/V3RVW�3URFHVVLQJ�5)�3HUIRUPDQFH*UDSKLQJ�7RROV�6SHFLDO�3XUSRVH2SWLPL]DWLRQ�7RROV�&203$6��23$6��626��%DQGLW9LHZ�$&&(376��VKRWLPH�QOS�SO��3LORW$QDO\]HU

$LU�LQWHUIDFH

&DOO�'HWDLO5HFRUGV

3LORW6FDQQHU

0,%'DWDEDVH�7RROV�&RQGRU��)DOFRQ

*36

*367KHVH�WRROV�DUH�W\SLFDOO\XVHG�LQ�WKH�IULHQGO\�XVHUDQG�FRPPHUFLDO�VWDJHV�RIQHWZRUN�OLIH�F\FOH��,QDGGLWLRQ��&'/V�VKRXOG�EHXVHG�IRU�WURXEOHVKRRWLQJDW�DQ\�WLPH�LQ�WKH�QHWZRUN·VOLIH�F\FOH�

0RVW�RI�WKHVH�WRROV�DUH�KHDYLO\�XVHG�GXULQJ�LQLWLDORSWLPL]DWLRQ�VWDJHV�RI�WKH�QHWZRUN·V�OLIH�F\FOH��

7KHVH�GDWDEDVH�WRROV�VKRXOGEH�XVHG�GXULQJ�LQLWLDO�0,%FUHDWLRQ�DQG�IRU�XSGDWHVWKHUHDIWHU�

Figure 6.1-2: Tools Overview


89

6.2 Tools RequiredTo evaluate and select CDMA optimization tools requires a minimal set of office tools aslisted in Table 6.2-1.

Tool Name Description and Vendor Recommended QuantityComputer with printer Any Market dependentAccess to the Internet,Motorola Intranet, ande-mail

Any Market dependent

Word processingapplication and spreadsheetsoftware

(examples: Word,WordPerfect, Excel, orFrameMaker)

Market dependent

A folder or binder All relevant notes will beplaced along in it with thevendor documentation forthe final assessment.

Market dependent

Table 6.2-1: Tools Required To Conduct CDMA Optimization Tools Survey


Type Skill LevelRF System Engineer Blue Belt (See Appendix A)Market Manager The ability to appropriate the necessary resources,

so that the tools can be acquired in a timely manner,to meet the required engineering needs for themarket.

Table 6.3-1 Personnel Required

This selection process and evaluation is highly dependent upon response times fromvarious vendors. Hopefully this should take one to two weeks for the RF systemengineer. The market manager will then be required to review the recommendations andprocure the necessary equipment. Following that, the tools will need to be installed andtested by the engineering (team).


90

6.4 Entrance CriteriaThere are no specific entrance criteria for starting research of the tools.

6.5 ProcedureThe procedure for selection of tools is fairly straightforward at a high level and consistsof the following four steps:

1. Evaluate market requirements2. Tools research and evaluation3. Tools procurement4. Tools installation and test

A detailed technical evaluation is required to ensure that the tools will meet the specificjob requirements. Many tools will be selected because there are no alternatives. Wherealternatives exist, the best selection should be made. The activities listed above arediscussed below.

6.5.1 Evaluate Market Requirements

The following issues should be considered by the RF network optimization engineeringteam and market manager to identify specific tool requirements for the optimizationactivity:

1. What are the requirements of the data collection and analysis tools for verifying thatMotorola has fulfilled its contractual obligations of RF performance (before handingover the CDMA system to the customer)? What types of reports must be supplied toshow satisfactory compliance to contract warranties? What tools will be requiredafter the system reaches commercial status?

2. What is the schedule for completing the RF network optimization? How large is theengineering team that will be sharing these tools? How many types of each tools areneeded? How many teams will be working in parallel (each requiring a set of tools)?

3. Are there any market specific deployment issues requiring support from prospectivetool vendors to be able to log/convert/process data that will be relevant for any newfeatures in the deployment? Are the tools current or outdated?

4. To what extent and how thorough will the data collection and documentation need tobe? [Certain tools offering cost savings may sacrifice quality in some areas.]


91

6.5.2 Tools Research and Evaluations

From the requirements derived from the exercise above and the list of candidate toolsfound in Appendix 6A, generate a customized candidate list of tools that will beconsidered for procurement. The following tasks should be required during this researchactivity:

1. Contact vendors to request updated specifications. Pay particular attention to datacompatibility. Use the phone, fax, or Internet to gather data.

2. Request demonstrations when possible – especially on newly advertised tools andfeatures.

3. Gather tool pricing data. Quotes may have to be requested from vendor’s salesdepartments; these people may be separate from the technical contacts.

4. Summarize the information gathered on a spreadsheet listing the pros and cons ofeach tool. For example, Table 6.5.2-1 is a snapshot of a spreadsheet that was puttogether for the Japan market containing high level pros and cons.

5. Can tools be borrowed from other Motorola account teams that may not be usingthem at this time? If so which tools.


92

Candidate Tool Pro’s Con’s Cost/Availability

Multiple phones can be logged atonce.

Additional hardwareneeded. Can not plug amobile directly into PC.

$XXXXXper unit

Hardware can contain a Pilot scanneras well as mobile ports.

Not yet compatible withJCDMA band.

Available onMM/DD/YY

GraysonSurveyor

Poor data loggingprocedure, only logswhen event "triggers"logging.

Walkabout is designed for in-building coverage testing.

Log files onlycompatible withOPAS32 post-processing tool.

$XXXXXper unit

Safco WinDM /Walkabout

Windows configuration makes real-time troubleshooting very easy.

Difficult for non-English speaker to use.Very "menu intensive".

Available onMM/DD/YY

Easy to setup, easy operation.Log files are compatible with all postprocessing applications, includingCompas.

QualcommCAIT

Only software to install, customercan use existing laptops* and GPSsetups.

* Will need to addWin95/98 OS to NTcomputers.

Table 6.5.2-1: Sample Tools Evaluation Spreadsheet

6.5.3 Tools Procurement

Once the tools have been identified and selected, the recommendations, including vendorpart numbers, descriptions, quantities, pricing, and vendor contact information should beentered on the purchase requisition form. This form must be submitted to appropriatemanagement for signature (program manager, finance), then forwarded to purchasing toplace orders. Due dates are critical.

6.5.4 Tools Installation and Test

Once the tools have been received, then they should be installed and tested on the actualsystem as it nears readiness for Single Cell Functional Test (SCFT). Engineers shouldrefer to the documentation that comes with the individual tools. References are given inAppendix 6A for the Motorola tools.

6.6 Analysis ConductedTradeoff analysis should included the following items:


93

1. Cost. This should not only take into consideration the expense of the tool, but alsoprocessing time required by the tool, the configuration time, and what will be thelearning curve on using the tool.

2. Tool Features. Is it compatible with other tools? Does it do everything you want it todo? Does the tool have too many options that it becomes user-unfriendly and requiresthe user to do multiple steps to complete a single task?

3. Vendor reliability. This should include the cost for the vendor support packages.

4. Tool availability. What will be the lead times? Does the vendor have a workingviable solution today or is the vendor promising something, in the way of a feature,which they will be delivering in the near future.

6.7 Exit Criteria1. Tools have been evaluated and selections complete.2. Tools have been purchased and delivered.3. Tools have been installed and tested.


94

Appendix 6A: Tools References

Information in table 6A-1 below is a sample listing tools that will be required for the RFoptimization of a CDMA system. The first set of tools contained in the table below areMotorola tools. The second sets of tools are third party tools that can be procured fromoutside of Motorola. [Note: It is important to realize that this list is only a snapshot atpublication time; one should do additional research into recent product offerings prior tofinal selection and purchase.]

Table 6A: Motorola Developed Tools & Products

Tool Name Operates On ReferenceCAMPS Collects Mobile

Phone Data andGPS PositionData


SMAP SMAP Datacollected fromLAN

http://scwww.cig.mot.com/tools/smap/http://scwww.cig.mot.com/~thakkar/smap.html

COMPAS DM Data andSMAP Data


Pilot Analyzer HP Pilot ScannerData


CDL Analysis Tool(CAT)

Call Detail Logs http://www.cig.mot.com/~wheelrts/analyzer.html


PM SUM, PMTRAF,PMMCC, CEM

PM Data http://www.rochellepark.pamd.cig.mot.com/software.html


SCUNO System EventLogs and AlarmData


Show or Compare AllParameters Script

MIB http://www.rochellepark.pamd.cig.mot.com/~dhelm/omcr.htm



http://scwww.cig.mot.com/tools/smap/














http://www.rochellepark.pamd.cig.mot.com/~dhelm/omcr.htm

http://www.rochellepark.pamd.cig.mot.com/~dhelm/omcr.htm


95

Neighbor List Tools:sho_time (generatedneighbor list (NL)recommendationsfrom DM data or HPscanner data)

ProcessedCOMPAS Data


nlp_pl5 (generates NLrecommendationsfrom CDLs)

Processed CDLs http://www.cig.mot.com/~reimrsrr/NLP.html

In addition to the Motorola tools previously listed, the following 3rd party tools may beconsidered as candidates for various optimization activities:

Field Data Collection Tools

1) Mobile Diagnostic Monitors

QUALCOMM CAIT (Windows) Software Package6455 Lusk Blvd, San Diego, CA 92121 Phone (800) 349-4474 Fax(619) 658-2567http://www.qualcomm.com/cdma/infrastructure/ancillary/For a listing of CDMA licensed suppliers from QUALCOMM go tohttp://www.qualcomm.com/cdma/tech/license.shtml.

Grayson Wireless Illuminator140 Vista Centre Drive, Forest Virginia 24551 USA Phone 800-800-7465 or 804-386-5300 Fax 804-386-5324 www.grayson.com orhttp://www.grayson.com/contactus.html

SAFCO Technologies, Inc. (WALKABOUT™, SMRTSAM2/PLUS™,and PROMAS32™)6060 Northwest Highway, Chicago, IL 60631-2518Tel: 1-800-843-7558 (toll-free in USA; press 1 for Support, press 3 forSales)Tel: 1-773-631-6216; Fax: 1-773-631-1626; Sales: 1-773-467-2707Product Support: 1-800-544-1431 or 1-773-467-2706 email:[email protected] Email: [email protected]://www.safco.com/products.html

ROHDE&SCHWARZ Inc.4425 Nicole Drive; Lanham, MD 20706Tel. (301) 459-8800; Fax (301) 459-2810http://www.rsd.de/produkt/tm_mob.htm orhttp://www.rsd.de/produkt/215a.htm



http://www.cig.mot.com/~reimrsrr/NLP.html

http://www.qualcomm.com/cdma/infrastructure/ancillary/

http://www.qualcomm.com/cdma/tech/license.shtml


http://www.grayson.com/contactus.html

mailto:[email protected]

http://www.safco.com/products.html

http://www.rsd.de/produkt/tm_mob.htm

http://www.rsd.de/produkt/215a.htm


96

2) CDMA pilot scanners and/or spectrum analyzers:

Hewlett Packard Pilot ScannerHP E7472A CDMA Integrated RF and Call Performance CoverageTest Systemhttp://www.tmo.hp.com/tmo/datasheets/English/HPE7472A.htmlhttp://www.hp.com/go/drive_test

Grayson Wireless PN ScannerGrayson Wireless Analyzer140 Vista Centre Drive, Forest Virginia 24551 USA Phone 800-800-7465 or 804-386-5300 Fax 804-386-5324 www.grayson.com orhttp://www.grayson.com/contactus.html

Berkeley Varitronics Systems255 Liberty StreetMetuchen, NJ 08840(732) 548-3737Fax (732) 548-3404http://www.bvsystems.com/Products/CDMA/cdma.html

LCC International, Inc7925 Jones Branch DriveMcLean, Va 22102, USA(703) 873-2000http://www.lcc.com/http://www.lcc.com/whaznew/Newsletter/OptimEyes_Trblsht/body_optimeyes_trblsht.html

ANRITSU COMPANY (Radio Communication Analyzer)1155 East Collins BoulevardRichardson , TX 750811-800-ANRITSU (800-267-4878); Tel: 972-644-1777; Fax: 972-644-3416Email: [email protected]://www.global.anritsu.com/products/test/rfmicrowireless/MT8802A.html

http://www.tmo.hp.com/tmo/datasheets/English/HPE7472A.html

http://www.hp.com/go/drive_test



http://www.bvsystems.com/Products/CDMA/cdma.html

http://www.lcc.com/

http://www.lcc.com/whaznew/Newsletter/OptimEyes_Trblsht/body_optimeyes_trblsht.html

http://www.lcc.com/whaznew/Newsletter/OptimEyes_Trblsht/body_optimeyes_trblsht.html




97

3) Post-Processing Tools

OPAS32™ (SAFCO Technologies, Inc.)6060 Northwest Highway, Chicago, IL 60631-2518Tel: 1-800-843-7558 (toll-free in USA; press 1 for Support, press 3 forSales)Tel: 1-773-631-6216; Fax: 1-773-631-1626; Sales: 1-773-467-2707Product Support: 1-800-544-1431 or 1-773-467-2706 email:[email protected] Email: [email protected]://www.safco.com/products.html

Grayson Wireless Analyzer140 Vista Centre Drive, Forest Virginia 24551 USA Phone 800-800-7465 or 804-386-5300 Fax 804-386-5324 www.grayson.com orhttp://www.grayson.com/contactus.html

mailto:[email protected]

http://www.safco.com/products.html



Optimization Procedures and Guidelines, Ver 1.2Single Cell Functional Test (SCFT)

98

7.0 Single Cell Functional Test (SCFT)

7.1 DescriptionThe purpose of the Single Cell Functional Test (SCFT) is to ensure basic functionalityand operation of each cell, and to identify and resolve any remaining hardware orsoftware issues. Single cell functional testing is required at each site in a cluster and thefirst tier sites surrounding that cluster prior to performing the initial coverage survey for agiven cluster. SCFT schedule should be arranged such that an entire cluster is ready foroptimization before moving on to the next cluster. The relationship of the SCFT to therest of the optimization cycle is shown in Figure 7.1-1.





(Chapter 3)


(Chapter 4)




(Chapter 9)







System Designvia


(Chapter5)


(Chapter 7)


(Chapter 8)

Figure 7.1-1: Relationship of Single Cell Functional Test Activity to EntireOptimization Process

The Single Cell Functional Test will ensure:

• The cell site hardware is functional• The connection between the site and the CBSC is functional


99

• The ability to place Land to Mobile calls and Mobile to Land calls on each sector• The antennae are pointing in the correct directions and are broadcasting the correct

PN• The PN footprint plots show adequate mobile receive and Ec/Io levels• Softer & soft handoffs occur. Softer: handoff between sectors of the same cell site.

Soft: handoff between two different cell sites.


100

7.2 Tools Required

Item Description or Vendor Recommended Quantity

Diagnostic Monitor (DM)

Laptop Computer with CDMAtesting software. Candidates:Motorola CAMPSQualcomm MDM or CAITSafco WalkaboutOr equivalent.

2 per vehicle

Global Positioning System(GPS)

Trimble Placer GPS orequivalent.

Required to supplytime/location data for eachDM

CDMA Phone

Qualcomm, Sony, Motorola,Toshiba, Panasonic, orequivalent – compatible withmarket frequency bands.

1 per DM

Drive Test Data Post ProcessingTool(s) & RF performanceverification tool

COMPAS, OPAS, or equivalent(See Chapter 6 Tools Selection)

Dependent on size ofmarket

CDL’s and CDL processing toolCdl_browse, CDL AnalyzerDependent on marketconfiguration

Table 7.2-1: Tools Required


Position Skill LevelRF Optimization Engineer White Belt ( See Appendix A)Data Collector/ Field Engineer Good computer background, capable of operating DM

& mobile. Good penmanship. See appendix A.4Driver Valid drivers license. See A.6CBSC Engineer Knows CBSC operations. See appendix A.8Landline Operator Can talk on the phone and fill out test forms.


7.4 Entrance Criteria1. Network Design and Optimization Preparation steps must be successfully completed.2. The spectrum should be clear of all unauthorized users.3. BTS must be completely installed, ATP’d and OPTO’d.4. The database must be complete and checked against design and default values.5. All necessary tools must be installed and operational. This may include setting up PN

mapping files for use by the DM display.

7.4.1 Notes on Entrance Criteria

In an ideal situation, all sites in a cluster should be installed, ATP’d and OPTO’d prior tostarting Single Cell Function Testing. Having all neighboring sites ready when doing theSCFT will allow verification of soft handoff functionality. Having all sites up will also


http://www.qualcomm.com/corporate/locations.shtml

http://www.safco.com/measurement/walkabout.html

http://www.trimble.com/



101

give more realistic detail in viewing the RF propagation of each sector. Due to cell site,BTS link, and database install scheduling, having all sites ready at one time may not bepossible. If a new site needs to be function tested before its neighbors are ready, theengineer must setup further plans for soft handoff testing after the neighboring sites areup. The SCFT procedure was written from the perspective that at least one tier ofneighboring sites is operational while performing the function test. Again the point of theSCFT is to test the functionality of the new BTS, one of those functions being handoffcapability with its neighbors.

7.5 ProcedureThis procedure covers data collection and subsequent analysis required for SCFT. Twodata collection / analysis methods are proposed. Method 1 assumes that data is collectedin the field by less skilled personnel (as compared to an engineer) and returned to thefield office for evaluation by the engineering team. Method 2 assumes a more skilleddata collector or engineer is dispatched to the field to do “real-time” SCFT verification.For this method the data collectors or system engineers will be adequately versed in theusage of the DM. In both methods, the data should be post-processed to guarantee thatall SCFT requirements are met, therefore discussion emphasizes analysis by theengineering team. (Conversely, there still may be specific problems encountered in thefield that require the engineers to perform drive test investigations themselves.) In bothmethods, the basic flow of this activity involves:

- definition of drive test routes- pre-departure equipment testing- data collection- origination termination tests along metric routes- hardware testing (if not completed by CFE’s)- continuous call or Markov data collection along metric routes- data processing (mobile and CDLs)- data analysis (mobile and CDLs)

Data collected includes DM data and CDLs. Each type of data plays a different role inthe SCFT activity as shown in Table 7.5-1.


102

Data Source Data Used To Verify Analysis Tool UsedMobile DM Markov orContinuous Call DataSMAP (optional)

- Antennas pointing in correctdirections and antenna cabling iscorrect

- PNs broadcast on correct antennas- Adequate Mob Rx levels on each

sector- Adequate Ec/Io levels for each PN- Soft and softer handoff capability (1)

Post-processing toolsuch as COMPAS,OPAS or equivalent

CDLs for call sampling(originations andterminations) ESNsused during drive test

- Verifying M Å L and L Å M callsfor each sector

- Soft and softer handoff capability (1)

CDL Analysis Tool

Table 7.5-1: Tools Required For SCFT Data Analysis

(1) Usage of only one set of data and accompanying tool is sufficient to validatesoft/softer handoffs. Both techniques are discussed for reference.

7.5.1 Drive Route

7.5.1.1 Drive Route Definition

The drive route definition will depend upon which method is used to collect and analyzedata. Both methods are discussed below.

7.5.1.1.1 Drive Route Definition – Method 1Determine the number of cells in each cluster. The customer and Motorola should agreeon this. A cluster normally consists of approximately 10 to 15 contiguous cell sites orone CBSC. This number may vary depending on the size of the system. Once a clusterhas been defined identify the first tier sites around that cluster, which must undergoSCFT and be operational prior to any initial coverage testing for that cluster. Next, createa drive route that assimilates a perpendicular X/Y “crosshatch” pattern around each siteundergoing SCFT. The routes should extend approximately two-thirds of the distancefrom the site undergoing SCFT to the first tier of neighboring sites in all directions (thisshould enable soft handoff to these neighbor sites). The drive route for each site shouldalso traverse through all sectors of that site, passing through sector boundaries (thisshould allow the mobile to enter softer handoff). Where possible, emphasize majorstreets, roads or highways to expedite the drive data collection. A sample of a crosshatchpattern consisting of perpendicular, East/West and North/South streets is shown inFigure 7.5.1.1-1.

[Note: Careful development of SCFT drive routes can save time during the datacollection. Engineers should brief data collection teams on the simple rules above in caseobstacles are encountered along the drive route. If any highways or Interstates are to bedriven, make sure the access points are at available entrance ramps. Also, take note ofone-way streets or dead end roads, it is important for the drive route to flow continuously.Be familiar with the area to be driven.]


103

The “X” in the center represents the site undergoing SCFT.“Y’s” are neighboring sites.

Figure 7.5.1.1-1: Sample SCFT drive route map for Method 1.

7.5.1.1.2 Drive Route Definition – Method 2The drive route used when performing “real time” SCFT is a circular route. The driveroute begins in the first sector of the site undergoing SCFT and continues in a circlepattern to include all other sectors of the site. For example in a 3 sector system the drivetester would begin at a start/ stop point that is identified in sector one , see point A inexample 7.5.1.1-2. From point A the drive team should proceed to point B in sector 2and begin testing, when testing is complete in sector two the team should proceed to pointC in sector 3 and begin necessary testing, upon completion of sector 3 testing the driveteam should proceed back to point A. For softer testing the drive team should ensure thatthey are within 2-3 blocks of the site being tested to ensure that the mobile is only usingthe tested site.


104

Figure 7.5.1.1-2: Sample SCFT drive route map for Method 2

7.5.1.1.3 Soft Handoff Drive Route DefinitionIf the SCFT site has no neighbors, or its neighbors have not been function tested, it isrecommended to delay this test until all sites in the cluster are ready.For Soft handoff testing for both method 1 and method 2, the drive team should begin atthe BTS (point 1) and drive away from the site, remaining inside the coverage area of thatsector. When the PN for the adjacent site is the best active (point 2) the team should turnaround and drive back to the starting point to ensure proper handoff back into the sitebeing tested. See figure 7.5.1.1-3 for an illustration of the soft handoff drive route.

Figure 7.5.1.1-3: Sample Soft Handoff drive route map


105

7.5.2 Pre-Departure Equipment Test

Test all equipment before leaving the facility. Minimally7, this should includeverification of:• 1 CDMA mobile phone (for call sampling)• 1 CDMA mobile phone connected to:• 1 Laptop computer loaded with DM software, connected to:• 1 GPS receiver (to log time and position data)

Figure 7.5.2-1 shows a sample drive test van equipment configuration block diagram;variations will exist for each supplier’s equipment. All equipment should be madefunctional once connected.

GPS Antenna

Laptop/ DiagnosticMonitor

Com Pwr SerialCoax Cable

GPS Unit

CDMA Phone

Serial Link

GPS Power

AC/DC Inverter

AC

DC

DC Power FromVehicle

12V

Cigarette Lighter

AntPwrDataPort

Figure 7.5. 2-1: Block Diagram of a Typical CDMA Drive Test Van Setup.

Drive test equipment troubleshooting checklist:

• Are all components powered and turned on?• Have all cables and connectors been tested?• Is the cabling correct? (correct GPS port, correct ports on the PC)• Does the PC meet the minimum system requirements for the DM software?• Does the PC have all necessary drivers installed with no resource conflicts?• Is each component functional independently? (DM works with no phone or GPS

plugged in? Mobile is functional?)• Are all configuration settings correct as specified by the components manufacturer?

(GPS settings like data transfer rate and parity.)• Are all accessory devices attached and functioning? (Mobile antenna, attenuator)

7 If desired, a DM can be connected to the second phone. This is sometimes useful to confirm performanceof network phones, both of which would show the same performance in the same area.


106

7.5.3 Data Collection Activity

Two phones will be used for SCFT data collection. One phone will perform eitherMarkov or continuous call data collection. This phone will log RF performance dataconnected to the DM for the duration of the test. The second phone will perform callsampling to facilitate origination and termination testing. The procedures for each typeof data collection are discussed below. The drive team should go to the start of the driveroute, start making both types of calls while logging data and documenting the results.The route should be completed as efficiently as possible. Any problems, such asexcessive call setup failures or dropped calls should be called into the engineeroverseeing this data collection activity. (Contingencies must be addressed by the leadengineer as appropriate. A line of communication to qualified personnel at the CBSC isrequired to facilitate any troubleshooting activities.) An example of a SCFT data sheet isincluded in Appendix E. This should be used to track completion SCFT on all sectors ina cluster.

7.5.3.1 Markov or Continuous Call Data Collection Procedure

The preferred type of call to characterize system performance around a cell site or in acluster is a Markov call. Markov calls transmit prescribed distributions of full, half,quarter, and eighth-rate frames on both the forward and reverse links as long as the call isactive. This allows the engineering team a fair calculation of frame erasure rates (FER),(typically for full-rate frames only) on both links. Markov calls are pegged to specific,designated transcoder circuits at the CBSC. Markov calls are silent, i.e. no noise is heardon either link of this call.Some precautions must be taken before using a Markov call. First, ensure that the phonebeing used is capable of Markov calls for the rate set being used by the system. Second,if the cell site is near an inter-CBSC border, and ICBSC-SHO is enabled, since ICBSC-SHO or anchor handoffs are not supported for Markov calls, then data collection shouldbe conducted using a “regular”, (non-Markov), but still continuous call. A continuouscall can be set up to a dedicated circuit, where a radio station can be re-broadcast. (Thedrawback with having the operator just listen to the radio station to grade forward linkaudio quality is that there will not be any activity on the reverse link.)The test is conducted by placing a call to (in order of preference) the Markov circuitphone number, or a source of continuous audio (such as the re-broadcast radio station), ora land-line party (only one is required). The DM should be set up to record data prior tomaking each call to ensure that the origination sequence information is logged at the startof the call. Each test call should be kept active for a maximum of 30 minutes or until adrop (RF Loss) occurs, whichever comes first. (This precaution attempts to minimizeany lost field data due to equipment, connection, or phone failures in the field.) The fileis then saved. After each call is saved, the DM recording should be reinstated and thenext call set up as quickly as possible to minimize data collection holes. Appendix 7Acontains a sample Markov or continuous call log sheet. This form should be modified tomeet the requirements of each market. All calls should have their start time and locationdocumented. In addition, if a drop occurs, document the drop location and time.Refer to specific phone and DM user documentation to program the phone and/or DM forMarkov operation.

7.5.3.2 Origination/ Termination Test Procedure

Two methods of conducting origination/termination testing are discussed below.


107

Method 1: The RF Engineer will use the CDLs in order to verify call origination andterminations on each sector of the new site. A DM is not required, but is useful to helpinvestigate any problem(s) encountered with the Markov/continuous call. If available, itshould be used. If equipment resources are thin, then just a phone will suffice.The DM operator should make three Mobile-to-Land calls and have the land operatorthen make one Land-to-Mobile call. Call duration should be 10 seconds long with a 10-second interval between calls. This quick call approach should produce an adequatenumber of Call Detail Log (CDLs) to be generated for this test ESN. This processshould be repeated throughout the entire drive route. The tester will not have time todocument all details for each call. However, in case of a call setup failure or call drop,the most important details to record are the failure time and location. See Appendix 7Bfor drive test log sheets.

Method 2: Is primarily for the experienced engineer or an experienced DM operator whogoes into the field and does verification real time. Method 2 is not recommended for a 6sector system because it is very difficult to identify the direction of sectors due tooverlap. Start at point A, make an origination, keep this call up while driving along thecircular route explained in section 7.5.1.1.2, while keeping the call up, record thefollowing data; the desired PN and actual PN, Ec/Io, Mobile Receive and MobileTransmit Values. Also, enter the location where the measurements are taken. If thedominant PN does not match the expected PN, indicate this problem in the “Comments”section of the SCFT Form. If there is more than one dominant offset (Ec/Io valueswithin 3 dB), indicate this in the same section. End the call. To verify terminations havethe switch call the mobile. This is defined as a mobile terminated call. Repeat theorigination/termination process for all sectors. The DM should be logging data to a filefor this test as a precautionary measure. Post processing and analysis of collected data isnot necessary unless a problem is identified. If problems are identified while testingaccording to method 2 revert back to method 1 for data processing and analyzing.

7.5.3.3 Hardware Testing

The BTS hardware and cabling are typically tested by CFE’s during the ATP(Acceptance Test Procedure) and OPTO (hardware optimization) see Chapter 3Equipment Installation and Test. The hardware tested should include the BBX, CSM,and MCC’s.

• Performing the origination test on each sector will complete BBX verification. If thecorrect PN appears and the tester can originate calls on that sector, then the BBX isfunctional.

• CSM functionality is verified by doing soft handoffs from the new BTS to itsneighbors. See 7.5.3.4 Soft/Softer Handoff Verification.

• MCC functional testing is done by placing 15 second calls from any one sector of thenew BTS. Verify that calls are placed on all channel elements for all MCC cards.Note that there are two overhead channel elements (paging & access) per sector thatwill not carry voice traffic. The specific channel elements being accessed can bemonitored from the CBSC using call-proc or by “tailing” the test phone. If a failureoccurs on a specific MCC card and channel element, the SNAP command should beused to see if the failure re-occurs on the same channel element. If a channel element


108

is found to repeatedly cause failures, that element should be disabled (OOS_MAN)and the card should be replaced. Table 7.5.3.3-1 shows an MCC checklist for a threesector system with 4 MCC-16 MAWI cards where the cells for paging andregistration channels are black. In this instance 58 calls must be placed to access allchannel elements.

CE1

CE2

CE3

CE4

CE5

CE6

CE7

CE8

CE9

CE10

CE11

CE12

CE13

CE14

CE15

CE16

Mawi 1

Mawi 2

Mawi 3

Mawi 4

Table 7.5.3.3-1 Channel Verification for 3-sector MCC 16.

7.5.3.4 Soft/Softer Handoff Verification

Softer handoffs can be verified between origination/termination test between sectors.After completing the termination test for a sector, originate a call, keep the call up andproceed to the start/stop point for adjacent sector verifying that a handoff occurs from thestarting sector to the next sector. If a handoff is verified, enter “pass” on the SCFT Form.If a handoff is not verified, enter “fail.” Upon arriving at the destination sector, end thecall. Do the origination/termination testing for the second sector then repeat the abovesofter handoff process for all sectors.

To test soft handoffs see the soft handoff drive route definition in section 7.5.1.1.3. If ahandoff is verified, enter “pass” on the SCFT Form. If a handoff is not verified, enter“fail” and continue with the process.

The SCFT form referenced in this section has been included in Appendix 7D. Pleasemodify the forms according to the number of sectors in each site.

7.5.3.5 Receive Diversity Testing (optional)

This test will help verify proper cabling and antenna configuration for a new BTS. Thetools required are:

• Portable transmitter (phone capable of transmitting at 23dBm)• SMAP

The test should be performed in each sector. From the start point of one sector (See pointA in figure 7.5.1.1-2) the portable transmitter should be keyed up. With SMAP, recordeach sector’s main and diversity RSSI levels. Verify the two strongest receive levels arefrom the receive paths associated with the specific sector being tested. If the strongestreceive paths are not from the test sector there may be a problem with antennaconfiguration or cabling.


109

7.5.3.5.1 SMAP Procedure for Receive Diversity TestingSMAP provides both main and diversity RSSI data for all the three/six sectors. This helpsto ensure that the spectrum is clear of any unwanted noise on the CDMA band beforeputting any commercial traffic on the system. It also helps to determine if main anddiversity antennas are connected properly. An example of problem solved is thatinadvertently many times during installation cables are swapped and sometimes twodiversity antennas are swapped. Although system engineers can indicate that main Rxantennas are swapped by looking at a PN value, they cannot confirm if diversity antennasare swapped without using SMAP because there is no such tool that can show this data.

The user needs to turn on RSSI filters for desired sectors. This can be done by justplacing a bts and sector number in the appropriate fields and by turning on appropriateSector Data Log (SDL) message. Use SDL2 filter for single carrier systems.

Select “BTS Status Display” under the monitoring display menu. Enter the correctCBSC, BTS, and sector values. This screen shows a graph where RSSI values areplotted. They’re also displayed in numeric format on the right.

The goal is to identify the sector the mobile is in using RSSI values. You’re looking forRSSI values higher for both main and diversity antennas for that sector. The receivedvalue depends on how strong the mobile is transmitting and how far it is from theantennas. It is important to transmit a strong signal to distinguish the sector you’retransmitting from on SMAP. The best possible solution is to transmit at 23dbm on thereverse link using a modified Qualcomm phone. For example, cutting a particularresistor on the receiver circuit can modify the QCP-1900. This gives you a delta of about10-20db and identifies the sector you’re in very clearly. If this is not possible, try to beabout ¼ mile away from the site, which should give you about 2-3 dB delta betweensector you’re on and other sector.

7.5.4. Mobile and CDL Data Processing

There are many tools available to process mobile data and many different ways to useeach of those tools. This procedure will use Motorola tools as examples to show how toprocess mobile data. CDL data processing is very specific and only the CDL AnalysisTool is used to process CDLs.

7.5.4.1 Mobile Data Processing

Once the mobile data is collected and transferred to the computer system and directorydesignated for data processing, the data can be processed using COMPAS. In order tolearn more about COMPAS see the TED (Technical Education & Documentation) webpage. The document number is COMPAS3.2 – 68P09248A05-A

The two required outputs from the COMPAS-processed data to perform SCFT analysisare mobile messaging (finger lock information) and time / location data.

Mobile Messaging Data

A sample of a comma-delimited, mobile message containing information indicatingfinger locks in a COMPAS-produced MOBILE (.mob) file is shown here:



110

Time, Date, State, IS-95 message, Dir, AckSeq, MsgSeq, AckReq, Decoded Contents

13:58:28:253, OCT 20 1998, HANDOFF, PSMM, <--, 4, 3, 1,ENCRYPTION=0, REF_PN=231, PILOT_STRENGTH=-2.500000, KEEP=1,PILOT_PN_PHASE=228, PILOT_STRENGTH=-31.500000, KEEP=0

This sample shows that the mobile is locked on to reference PN 231, and is alsorequesting to drop pilot PN228.

Time / Location DataTime and location data are contained in the COMPAS-produced, comma-delimited,TIME (.tim) file. A sample header for a TIME file is shown in Appendix 7C. Theheader shows the order of the collected and post-processed data for each entry in theTIME file. Definitions of each of these data fields can be found in the COMPAS productdocumentation.After processing the drive test data through COMPAS, these *.mob and *.tim files willbe found in the following directory structures of the analysis where COMPAS has beenrun:

/analysis/COMPAS/TIME/*.tim/analysis/COMPAS/DECODE/*.mob

7.5.4.2 CDL Data Processing

CDL data should be transferred from the OMC-R to an off-line analysis workstation.(Avoid running the CDL Analysis Tool on the OMC-R.) The tools used to “browse” theCDLs are discussed in Chapter 6. The CDL file name will be cdl.<date & time>, it isbest to use the “tar” utility in order to keep all the CDLs for a specific date together. Thetar file should be compressed before being transferred. Once the binary CDLs have beentransferred and processed, the output file can be “grep’ed” to isolate the CDLs created bythe Origination/Termination test mobile. Here is an example of how to use the UNIXgrep command:

Cdl_browse cdl.* | pgrep “ESN=0xabf0c83” >> Test_mobile.cdl

Cdl_browse cdl.* -- this simply reads through all of the cdl.<date> files in the currentdirectory and changes them from binary to ASCII format.

| pgrep “ESN=0xabf0c83” – pulls out the entire CDL record where “ESN=0xabf0c83” isfound.>> Test_mobile.cdl -- writes the grepped data to the filename “Test_mobile.cdl”. Two“>” symbols mean append to the file.

This Test_mobile.cdl file will be used in the next section to verify originations andterminations.


111

7.6 Data Analysis Procedures

7.6.1 Origination / Termination Verification Methods

Three methods are presented to verify originations and termination on each sector usingeither CDLs or mobile (messaging) data. The primary approach is to use the bts_orig.dstfile created by the CDL Analysis Tool (CAT). The secondary approach is to process thebrowsed CDLs through a script that could extract a list of all BTS/SECTOR upon whichorigination and terminations were made. Both the primary and secondary approachestake advantage of not having to use a DM connected to the call sampling phone. Thetertiary approach would require use of the DM to collect mobile message files. This datawould be processed and examined to extract the PN upon which the calls set up, andthose PNs would be mapped to various BTS/Sectors. Each of these methods is presentedbelow. (Finally, as an alternative, the drive test technician could write down all the PNsoriginated on as he/she drove around a cell site. This would required a fairly skilledtechnician and is not as robust as any of the approaches laid out below.)

7.6.1.1 Origination Termination Verification Using bts_orig.dst

One of the simplest ways to verify originations and terminations on each sector of thenew site is to process the browsed CDLs with the CDL Analysis Tool (CAT) and viewthe bts_orig.dst file. One very useful report produced by the CAT is the bts_orig.dst. Asample of this output report from the CAT, for BTS 51 (6-sector site), is shown here:

BTS/SEC Orig/Term RateBTS SEC Orig Term Orig% Term% O_C% T_C% CCR51 1 2 1 66.67 33.33 11.11 5.556 10051 2 1 1 50 50 5.556 5.556 10051 3 3 2 60 40 16.67 11.11 10051 4 2 1 66.67 33.33 11.11 5.556 10051 5 0 1 0 100 0 5.556 10051 6 2 2 50 50 11.11 11.11 100

The headings of this report/file and all other reports/files are explained in the CDLAnalyzer documentation (http://www.cig.mot.com/~wheelrts/analyzer.html). This reportshows that all sectors had successful terminations. Also, all sectors except 51-5experienced successful originations. In this case, a follow up drive test should bescheduled to verify that this sector can perform successful originations.

7.6.1.2 Origination/Termination Verification Using Browsed CDLs

Looking through the ASCII CDL is another means to verify that each sector hadsuccessful originations and terminations. The best method to determine if a call is eitheran origination or termination is to check the “Entry Type” field in the CDL for that call.Table 7.6.1.2-1 lists the various entry types.

ENTRY_TYPE Type of Call0 Origination1 Termination2 CDMA to CDMA hard handoff3 CDMA to CDMA soft handoff



112

Table 7.6.1.2-1: Entry Type Definitions for CDLs

By looking at the ACCESS_BTS and ACCESS_SECTOR fields, the CDL below showsthere was a successful termination on BTS-51, Sector-5 for ESN=0x0abf0c83. (Also, forterminations, the “DIALED_DIGITS=” field is null.) Perusing the browsed CDLs, orwriting a short script to extract the ACCESS_BTSs and Sectors for the test ESNs willgive you a list of all sectors that supported successful originations and/or terminations.

Handoffs can also be verified using the CDL by comparing the ACCESS_BTS field withthe LAST_MAHO_ACT or LAST_SHO_BTS fields. The LAST_SHO_BTS andSECTOR fields state the last CBSC, BTS, and Sector the mobile was in soft handoffwith.

Figure 7.6.1.2-1: Example of a Browsed CDLLOG (Start)

BROWSE CDLLOG MSI-4406239975 99-01-13 13:08:33 omc MM-6 L000000.00000 112209/164884CDL:1 Call Detail LogCDL_SEQ_NUM=0x7d3d LAST_RF_CONN2_SECTOR=5CALL_REF_NUM=0x02b3 LAST_RF_CONN2_SSECTOR=6CBSC=6 LAST_RF_CONN2_MCC=22MMADDR=0xa6 LAST_RF_CONN2_ELEMENT=19XC=1 MCC_RELEASE2_TIME=0x8b3bCPP=4 LAST_RF_HIGA2_INTERVALS=0MID=4406239975 LAST_RF_HIGA2_BEGIN=0x0000ESN=0x0abf0c83 LAST_RF_HIGA2_END=0x0000SCM=0x62006200 LAST_RF_HIGA2_COUNT=0MOBILE_PROTOCOL_REV=3 LAST_RF_HIGA2_TEMP=0x0000DIALED_DIGITS= LAST_RF_SETP2_INTERVALS=0ACCESS_TIME=13:08:28 LAST_RF_SETP2_BEGIN=0x0000ACCESS_PN_OFFSET=21 LAST_RF_SETP2_END=0x0000ACCESS_STR=0x0ff7 LAST_RF_SETP2_COUNT=0ACCESS_CHANNEL=1120 LAST_RF_SETP2_TEMP=0x0000ACCESS_BTS=51 LAST_RF_CONN1_MMADDR=0xa6ACCESS_SECTOR=5 LAST_RF_CONN1_BTS=51ENTRY_TYPE=1 LAST_RF_CONN1_SECTOR=4SERVICE_OPTION=0x0003 LAST_RF_CONN1_SSECTOR=0NEGOTIATED_SO=0x0003 LAST_RF_CONN1_MCC=22LAST_MM_SETUP_EVENT=23 LAST_RF_CONN1_ELEMENT=7CIC_SPAN=68 MCC_RELEASE1_TIME=0x8b3dCIC_SLOT=30 LAST_RF_HIGA1_INTERVALS=0XCDR=0x0110 LAST_RF_HIGA1_BEGIN=0x0000INIT_RF_CONN_BTS=51 LAST_RF_HIGA1_END=0x0000INIT_RF_CONN_SECTOR=5 LAST_RF_HIGA1_COUNT=0INIT_RF_CONN_MCC=22 LAST_RF_HIGA1_TEMP=0x0000INIT_RF_CONN_ELEMENT=19 LAST_RF_SETP1_INTERVALS=0INIT_RF_CONN_CHANNEL=1120 LAST_RF_SETP1_BEGIN=0x0000CFC=1 LAST_RF_SETP1_END=0x0000


113

RELEASE_TIME=13:08:51 LAST_RF_SETP1_COUNT=255XC_RELEASE_TIME=0x8b31 LAST_RF_SETP1_TEMP=0x87e8INIT_MM_REL_EVENT=3 INIT_MAHO_TIME=0x870fONE_PILOT_COUNT=0 INIT_MAHO_CAUSE=8TWO_PILOTS_COUNT=1 INIT_MAHO_ACT_STR=0x14THREE_PILOTS_COUNT=1 INIT_MAHO_CAND1_MMADDR=0xa6LOC_S_ADD_COUNT=1 INIT_MAHO_CAND1_BTS=51LOC_SR_ADD_COUNT=1 INIT_MAHO_CAND1_SECTOR=6LOC_S_DROP_COUNT=0 INIT_MAHO_CAND1_STR=0x14LOC_SR_DROP_COUNT=0 INIT_MAHO_CAND2_MMADDR=0x00EXT_S_ADD_COUNT=0 INIT_MAHO_CAND2_BTS=0EXT_SR_ADD_COUNT=0 INIT_MAHO_CAND2_SECTOR=0EXT_S_DROP_COUNT=0 INIT_MAHO_CAND2_STR=0x00EXT_SR_DROP_COUNT=0 INIT_MAHO_CAND3_MMADDR=0x00BETTER_ACTIVE=0 INIT_MAHO_CAND3_BTS=0LOC_S_PILOTS_REL=1 INIT_MAHO_CAND3_SECTOR=0LOC_SR_PILOTS_REL=2 INIT_MAHO_CAND3_STR=0x00EXT_S_PILOTS_REL=0 LAST_MAHO_TIME=0x88f9EXT_SR_PILOTS_REL=0 LAST_MAHO_CAUSE=8LAST_HO_BLOCK_CAUSE=13 LAST_MAHO_ACT1_MMADDR=0xa6LAST_HO_BLOCK_TIME=13:08:39 LAST_MAHO_ACT1_BTS=51LAST_HO_BLOCK_PN=370 LAST_MAHO_ACT1_SECTOR=5ICS_BEGIN_TGT_MMADDR=0x00 LAST_MAHO_ACT1_STR=0x18ICS_BEGIN_TGT_BTS=0 LAST_MAHO_ACT2_MMADDR=0xa6ICS_BEGIN_TGT_SECTOR=0 LAST_MAHO_ACT2_BTS=51ICS_BEGIN_SRC1_BTS=0 LAST_MAHO_ACT2_SECTOR=4ICS_BEGIN_SRC1_SECTOR=0 LAST_MAHO_ACT2_STR=0x1fICS_BEGIN_SRC2_BTS=0 LAST_MAHO_ACT3_MMADDR=0xa6ICS_BEGIN_SRC2_SECTOR=0 LAST_MAHO_ACT3_BTS=51ICS_BEGIN_TIME=0:00:00 LAST_MAHO_ACT3_SECTOR=6ICS_END_TGT_MMADDR=0x00 LAST_MAHO_ACT3_STR=0x0aICS_END_TGT_BTS=0 LAST_MAHO_CAND1_MMADDR=0xa6ICS_END_TGT_SECTOR=0 LAST_MAHO_CAND1_BTS=51ICS_END_SRC1_BTS=0 LAST_MAHO_CAND1_SECTOR=3ICS_END_SRC1_SECTOR=0 LAST_MAHO_CAND1_STR=0x19ICS_END_SRC2_BTS=0 LAST_MAHO_CAND2_MMADDR=0x00ICS_END_SRC2_SECTOR=0 LAST_MAHO_CAND2_BTS=0ICS_END_TIME=0:00:00 LAST_MAHO_CAND2_SECTOR=0ICS_COUNT=0 LAST_MAHO_CAND2_STR=0x00ICS_CBSCS=0 LAST_MAHO_CAND3_MMADDR=0x00LAST_RF_CONN3_MMADDR=0x00 LAST_MAHO_CAND3_BTS=0LAST_RF_CONN3_BTS=0 LAST_MAHO_CAND3_SECTOR=0LAST_RF_CONN3_SECTOR=0 LAST_MAHO_CAND3_STR=0x00LAST_RF_CONN3_SSECTOR=0 LAST_SHO_TIME=13:08:30LAST_RF_CONN3_MCC=0 LAST_SHO_CAUSE=8LAST_RF_CONN3_ELEMENT=0 LAST_SHO_RESULT=1MCC_RELEASE3_TIME=0x0000 LAST_SHO_MMADDR=0xa6LAST_RF_HIGA3_INTERVALS=0 LAST_SHO_BTS=51


114

LAST_RF_HIGA3_BEGIN=0x0000 LAST_SHO_SECTOR=4LAST_RF_HIGA3_END=0x0000 LAST_SHO_MCC=22LAST_RF_HIGA3_COUNT=0 LAST_SHO_ELEMENT=7LAST_RF_HIGA3_TEMP=0x0000 SETUP_EVENTS=0x080c7efcLAST_RF_SETP3_INTERVALS=0 FWD_QUALITY=0LAST_RF_SETP3_BEGIN=0x0000 LAST_FWD_INCR=0x0000LAST_RF_SETP3_END=0x0000 MEAS_COUNT=0LAST_RF_SETP3_COUNT=0 RVS_QUALITY=0LAST_RF_SETP3_TEMP=0x0000 LAST_RVS_INCR=0x8080LAST_RF_CONN2_MMADDR=0xa6 RVS_ERASE_COUNT=5LAST_RF_CONN2_BTS=51 RF_FADE_COUNT=0

End of Figure 7.6.1.2-1: Example of Browsed CDLLOG

7.6.1.3 Origination/Termination Verification Using Mobile Data

Since the data collection procedure used did not call for (unless available) a DM to beconnected to the call sampling phone, this is not a primary approach, but is included as analternative. The COMPAS-produced <esn>.mob file contains the IS-95 messaging. TheCOMPAS-produced <esn>.tim file contains location and signal strength information (seeSection 7.5.4.1). These COMPAS messages are abbreviated using acronyms. (A list ofthese acronyms and their meanings can be found in Appendix 7D.) Look through themobile messages to look for an Origination Attempt message. In order to determinewhich PN the mobile originated on, look for the first Power Strength MeasurementMessage (PSMM) after the call is set up. Note this PN, then also look in the PagingChannel System Parameter Message (PCSPM) prior to the origination attempt. The PilotPN is given. The PN found in both of these is most likely the same and is the PN usedfor origination. In the event of a discrepancy, the actual PN used is the one noted afterthe call setup. (In cases where the PNs are different in these two messages, this typically,indicates an area of many pilots or rapidly changing pilots. This should not happen toooften unless the drive test vehicle is traveling at high speeds or operating in a regionwhere many pilots are present.)

Example of First PSMM Showing Reference PN on Which Call Was Set Up:

11:57:33:161, SEP 29 1998, CALL_UP, PSMM, <--, 0, 0, 1, ENCRYPTION=0, REF_PN=362,PILOT_STRENGTH=-7.500000, KEEP=1, PILOT_PN_PHASE=382, PILOT_STRENGTH=-11.000000, KEEP=1, PILOT_PN_PHASE=366, PILOT_STRENGTH=-14.000000, KEEP=1,PILOT_PN_PHASE=372, PILOT_STRENGTH=-10.500000, KEEP=1

Accompanying Example of Paging Channel System Parameter Message (PCSPM):

11:57:28:546, SEP 29 1998, CALL_DOWN, PCSPM, P, -, -, -, PILOT_PN=362,CONFIG_MSG_SEQ=1, SID=12336, NID=1, REG_ZONE=21, TOTAL_ZONES=1,ZONE_TIMER=0, MULT_SIDS=0, MULT_NIDS=0, BASE_ID=3537, BASE_CLASS=0,PAGE_CHAN=1, MAX_SLOT_CYCLE_INDEX=2, HOME_REG=1, FOR_SID_REG=1,FOR_NID_REG=1, POWER_UP_REG=0, POWER_DOWN_REG=0, PARAMETER_REG=0,REG_PRD=0, BASE_LAT=0x07A41C, BASE_LONG=0x1DBFB4, REG_DIST=0,SRCH_WIN_A=6, SRCH_WIN_N=8, SRCH_WIN_R=9, NGHBR_MAX_AGE=0,PWR_REP_THRESH=2, POWER_REP_FRAMES=9, PWR_THRESH_ENABLE=1,


115

PWR_PERIOD_ENABLE=0, PWR_REP_DELAY=1, RESCAN=0, T_ADD=28, T_DROP=32,T_COMP=8, T_TDROP=3, EXT_SYS_PARAMETER=1, EXT_NGHBR_LIST=1,GLOBAL_REDIRECT=0

If the call was a termination attempt, this can also be confirmed by searching for a PagingChannel General Page Message (PCGPM) which will be followed by the first PSMM asdescribed above.

Call processing sequences, including call set ups for both originations and terminationsare described in the Motorola Confidential and Proprietary document, “Call ProcessingSFS”. Excerpts of this document are described at:http://www.cig.mot.com/~klnknbrg/r5cfcdocument.html.

7.6.2 Soft/softer Handoff Verification Methods

Two methods are discussed to verify soft and softer handoff instances for each site/sector.These methods use either mobile messaging data or CDLs as discussed below.

7.6.2.1 Soft/Softer Handoff Verification Using Mobile Messaging

The best approach, getting the most “bang for the buck” to identify occurrences of softand softer handoff would be usage of mobile messaging data. Throughout the duration ofa Markov or continuous call, there are likely a large number of combinations of soft andsofter handoffs that the mobile encounters. To identify which PNs the mobile used forsoft/softer handoff for the entire duration of the call, the mobile messaging would need tobe examined. Soft/softer handoffs can be tallied by looking at all the HandoffCompletion Messages (HCM). These HCM messages will show the variouscombinations of PNs that were in soft/softer handoff together during the drive. A sampleHCM is shown below. This HCM indicates that the mobile has entered soft handoff withPNs 362 and 372.

11:57:34:119, SEP 29 1998, HANDOFF, HCM, <--, 2, 3, 1, ENCRYPTION=0,LAST_HDM_SEQ=0, PILOT_PN=362, PILOT_PN=372

A simple script would be required to parse through the mobile messaging of all filescollected along a SCFT drive route to identify all combinations of soft and softerhandoffs. Then a simple checking routine could identify if all sectors entered into softerhandoff with same site sectors and into soft handoff with neighboring sites/sectors.

7.6.2.2 Soft/Softer Handoff Verification Using CDLs

CDLs can also be used to verify soft and softer handoffs. A set of fields calledLAST_RF_CONNX_BTS and SECTOR (X=[1:3]) can be used to identify whichsites/sectors the mobile is in soft or softer handoff with when the call ends. Alternatively,the INIT_MAHO_CANDX fields also indicate BTS/Sectors that the mobile will havebeen in soft(er) handoff with immediately after call setup. The only drawback from thisapproach is that this limits the number of reports of soft/softer handoff partners, sincethese CDL fields are only pegged at the end of the call. An example of this can be seenin the Browsed CDL shown previously in Figure 7.6.1.2-1. Softer handoffs betweensectors 4, 5, and 6 are also verified by looking at the various RF_CONN fields. If onewere to use this method, the call sampling ESNs should be used since they wouldgenerate many more CDLs than the Markov or continuous call ESNs.

http://www.cig.mot.com/~klnknbrg/r5cfcdocument.html


116

7.6.2.3 Soft/Softer Handoff Troubleshooting

If a particular type of handoff is not happening or can not be located in the mobile data orCDLs, a special troubleshooting drive may need to be scheduled. Typical problems seenwith handoff failures are incomplete Neighbor Lists or hardware issues such as GLI/BBXfailure (puts a site/sector off the air), CSM failure (site/sector loses CDMA timingreference so mobile can not use this site/sector to enter into soft/ softer handoff with).The engineering team should investigate these problems and re-schedule a new drive testin the areas around a problem site/sector. The engineer should see real-time variations ofcombinations of PNs in the active set. If this real time troubleshooting exercise does notindicate that the problem has been solved, then the integrity of data collection toolsshould be checked.

7.6.3 RF Performance Verification for Each Sector

For each sector evaluated during SCFT, the following RF performance items should bechecked:

- Verify propagation pattern for each sector (Is correct PN being broadcast oncorrect antenna in the correct direction?)

- Is the sector transmitting an acceptable signal as evidenced by adequate MobRx levels at the mobile?

- Is the link balanced, as evidenced by the mobile transmit value conforming tothe IS-95 link balance equation (Mob Tx = -(Mob Rx) - 73 + TxAdj)?

- Is there adequate signal quality at the mobile, as evidenced by reasonableEc/Io levels?

Propagation Pattern and Ec/Io VerificationThe RF propagation pattern of a specific sector, also known as a “PN’s footprint”, is auseful tool to determine if a particular site’s RF plumbing and PN database are correctlyset up. Many post-processing tools have the capability of graphically displaying a singlePN offset. The method of displaying specific PNs will vary depending upon the tool. AMotorola tool capable of viewing a PN plot within the COMPAS tool can be found at:http://www.cig.nml.mot.com/cdma/kctopt/tools/ . Select “PN Plot” from the “Tool Box”.If all sites surrounding the new BTS are on the air during the SCFT, the followingmethod can be used to verify antenna orientation and relative pilot strength. If the sitehas no immediate neighbors or its neighbors are not up yet, then simply assign one colorfor each PN. This would show where all the sectors propagate within one plot, but wouldnot show each PN’s strength.

The following two figures (7.6.3-1 and 7.6.3-2) are examples of PN Plots generated withthe PN Plot tool. The Ec/Io of the PN is displayed on a scale from black to light gray.Use of the PN Plot tool automatically gives the user an indication of the Ec/Io levels foreach sector. A black “&” means the Ec/Io was greater than or equal to Tadd dB, a lightgray “&“ means the Ec/Io of that PN was less than Tadd dB. Notice how the PNfootprint for values above Tadd for sector 6 looks evenly spread, albeit somewhat shiftedcounterclockwise. This slight shifting must be evaluated in terms of the roads driven. Forexample: Did the drive route enable uniform coverage around each sector, or did it skewthe results one direction or another? Also, any obstacles that may reflect the energyfrom an antenna to a different area must be considered: Is there a large building across



117

the street from the antenna that acts as a reflector? One can see that energy from sector6 shows up all around the site in all sectors, although a good portion of it is below Tadd.This is typical of a dense urban environment from which this sample was taken. Moresuburban and rural areas may have “cleaner” propagation patterns, but precautions shouldbe taken in rough terrain (hills, valleys) areas. (Note that this 6-sector site also employs60 -degree azimuth beam width antennas.) In contrast, Figure 7.6.3-2 shows an RFpattern for values above Tadd for sector one which is highly irregular. The PN for sectorone is showing up as a strong influence in sectors 2, 5, 6, and along the border betweensectors 3 and 4. However, the largest single occurrence of energy from sector 1 is in thebounds of sector 1. Does this positively guarantee that sector 1 antenna is pointing in thecorrect direction with the correct PN? Since this is again a dense urban environment, theanswer is probably “yes”. However, the optimization engineer should continue tomonitor this situation during subsequent optimization activities including the initialcoverage test.

Figure 7.6.3-1: PN Plot for Site 106, Sector 6:


118

Figure 7.6.3-2: PN Plot for Site 106, Sector 1

7.6.4 Mobile Receive and Transmit Level Verification

The next step of SCFT analysis is to determine if the mobile receive and transmit powersare within acceptable ranges for the new site/sector, and comply with the IS-95 linkbalance equation. Again, use the post-processing tool to view plots of each parameter.The diagram below is a general table of acceptable ranges for these RF parameters withinthe coverage footprint of a cell site/sector. Generally speaking if the levels fall outside ofthese bounds, that the mobile is outside of an adequate coverage area.

Parameter Acceptable LevelRSSI -40 to –90 dBmMobile Transmit < +17 dBm

Of course, these values will vary depending on the terrain, amount of blockage betweenthe sector and the mobile, mobile antenna length, antenna position, or many othervariances within the drive test vehicle.


119

7.6.5 Troubleshooting

In troubleshooting problems with new sites, make sure to check the obvious solutionsfirst:Does this site/sector undergoing SCFT meet all the Entrance Criteria requirements?Was the site turned on and functional from the CBSC perspective?Were there problems with a specific mobile?Is the database correct for the new site?Does the site have the correct neighbor list?Is the PN offset correct?

The “Event Logs”, which are logged on the OMCR, should be checked at the time of thetest. Event Logs will sometimes show problems, such as alarms, that can affect a specificsite or sector.

7.7 Exit CriteriaThe single cell functional test data sheet is complete.Origination and termination tests pass successfully.Soft and softer handoffs occur as appropriate.The PN offsets and RF propagation patterns have been verified for each sector.Mobile receive and transmit levels are acceptable.Problem resolution matrix has been updated with any unusual findings.


120

APPENDIX 7A: Sample Markov or Continuous Call Data Collection Log Sheet

Date: MOBID: ESN: Operator:

Direction: Area: Phone Manufacturer & Version:

Call # Start Time End Time

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

Start Location End Location File Name


121

APPENDIX 7B: Sample Call Sampling Data Log Sheet

Date: MOBID: ESN: Operator

Zone: Direction &: Phone Manufacturer & Version: Configuration (hArea

CallType

#ofType

Call #

DM Time Call Proc Time Ref # Location

VOXQual.

FTOFTT RF

NoService

Analog

D-AH/O

OpErr Active(s) File Name

M-L 1/ 1 14:23:00 : : .

M-L 2/ 2 14 : 25:00 : : .

M-L 3/ 3 14: 27: 00 : : .

L-M 1/ 4 : : : : .

M-L 4/ 5 : : : : .

M-L 5/ 6 : : : : .

M-L 6/ 7 : : : : .

L-M 2/ 8 : : : : .

M-L 7/ 9 : : : : .

M-L 8/ 10 : : : : .

M-L 9/ 11 : : : : .

L-M 3/ 12 : : : : .

Jan 24, 2000 812-555-4365 03FF0C93

New Site 389

4th & Roswell St. 1 214, 218, 320 0124001423.qlc

4th & Fleming Ave.1

222, 324, 418 0124001425.qlc

4th & Becker Ln. 1 332, 418 0124001427.qlc

D 8

B


122

APPENDIX 7C: SINGLE CELL FUNCTIONAL TEST TRACKING SHEET

ClusterName:EMX-C/MM- 3

ClusterLocation:Downtown

Dates Tested:1/3/99 –1/15/99

Numberof BTS:16 RF Check

BTS andSector List

Originations(Pass/Fail)

Terminations(P/F)

Soft HO(P/F)

SofterHO (P/F)

AntennaDirection/ PNCheck (P/F)

MobRx

MobTx

EcIo Comments

BTS-1-1BTS-1-2BTS-1-3BTS-1-4BTS-1-5BTS-1-6BTS-86-1Etc..First TierSitesBTS-93-1BTS-105-6Etc...


123

APPENDIX 7D: .TIM File Header (Description of .tim File DataContents)

Relative Offset, Time, Date, Latitude, Longitude, Average Speed, Forward FER Average,Forward FER Sum, Forward Burst Error Max, Forward FER Samples, Reverse FERAverage, Reverse FER Sum, Reverse Burst Error Max, Reverse FER Samples, TransmitPower Average, Receive Power Average, Spectrum Analyzer Energy, Eb/No, TrafficChannel Gain, Power Control Gain, Voice Gain, Combined Finger Ec/Io, Number ofActive Pilots, Aggregate Active Ec/Io, Best Active PN, Best Active PN Ec/Io, PilotDominance, Aggregate Interfering Ec/Io, Worst Interfering PN, Worst Interfering PNEc/Io, Active vs. Other Pilot Ec/Io Delta, State Of Call CBSC, Call Status, Call Reason,Layer 2 Message Type, Number of Times 0 Locked Fingers, Number of Times 1 LockedFingers, Number of Times 2 Locked Fingers, Number of Times 3 Locked Fingers, CellID 1, Cell ID 1 Forward Power, Cell ID 1 RSSI for Main, Cell ID 1 RSSI for Diversity,Cell ID 2, Cell ID 2 Forward Power, Cell ID 2 RSSI for Main, Cell ID 2 RSSI forDiversity, Cell ID 3, Cell ID 3 Forward Power, Cell ID 3 RSSI for Main, Cell ID 3 RSSIfor Diversity, BSC PN offset 1, BSC PN offset 2, BSC PN offset 3, Mobile PN offset 1,Mobile PN offset 2, Mobile PN offset 3, Finger PN offset 1, Finger Energy 1, Finger PNoffset 2, Finger Energy 2, Finger PN offset 3, Finger Energy 3, Markov 9600 Exp Full RxFull Bit Error, Markov 9600 Exp Full Rx B&B1, Markov 9600 Exp Full Rx Half,Markov 9600 Expected Full Rx Quarter, Markov 9600 Expected Full Rx Eighth, Markov9600 Exp Full Rx Prob Bit Error, Markov 9600 Exp Full Rx Erasure, Markov 9600 ExpFull Rx B&B2, Markov 14400 Exp Full Rx Full Bit Error, Markov 14400 Exp Full RxFull B&B1, Markov 14400 Exp Full Rx Full B&B2, Markov 14400 Exp Full Rx Half,Markov 14400 Exp Full Rx Half B&B1, Markov 14400 Exp Full Rx Half B&B2,Markov 14400 Expected Full Rx Quarter, Markov 14400 Exp Full Rx Quarter B&B1,Markov 14400 Exp Full Rx Quarter B&B2, Markov 14400 Expected Full Rx Eighth,Markov 14400 Exp Full Rx Eighth B&B, Markov 14400 Exp Full Rx Erasure, Voice14400 Exp Full Rx Full B&B1, Voice 14400 Exp Full Rx Full B&B2, Voice 14400 ExpFull Rx Erasure, Voice 9600 B&B1, Voice 9600 Prob Bit Error, Voice 9600 Erasure,Voice 9600 B&B2, MCAP Full, MCAP Half, MCAP Quarter, MCAP Eighth, MCAPInvalid Full, MCAP Invalid Half, MCAP Invalid Quarter, MCAP Invalid Eighth, MCAPB&B, MCAP D&B, MCAP Full Erasure, MCAP Half Erasure, MCAP Quarter Erasure,MCAP Eighth Erasure, MCAP Full Errors, MCAP Half Errors, MCAP Quarter Errors,MCAP Eighth Error


124

APPENDIX 7E: COMPAS IS-95 Messaging Acronyms

Abbreviations Message Types

ACACRM Access Channel Authentication Challenge Response MessageACDBM Access Channel Data Burst MessageACM Authentication Challenge MessageACOM Access Channel Order MessageACORGM Access Channel Origination MessageACPRM Access Channel Page Response MessageACREGM Access Channel Registration MessageACRM Authentication Challenge Response MessageACSRM Access Channel Status Response MessageACTCM Access Channel TMSI Assignment Completion MessageAHDM Analog Handoff Direction MessageAWIM Alert with information MessageEHDM Extended Handoff Direction MessageFDBM Forward Data Burst MessageFFWIM Forward Flash With Information MessageFOM Forward Order MessageFPCPM Forward Power Control Parameters MessageFSBDM Forward Send Burst DTMF MessageHCM Handoff Completion MessageHDM Handoff Direction MessageITSPM In-Traffic System Parameters MessageLAST_ACC_CH Last Access Channel Information MessageLAST_FWD_TCH Last Forward TCH MessageLAST_PAGE_CH Last Page Channel MessageLAST_REV_TCH Last Reverse TCH MessageMSRM Mobile Station Registered MessageNLUM Neighbor List Update MessageOCM Origination Continuation MessagePCACM Page Channel Authentication Challenge MessagePCAPM Page Channel Access Parameters MessagePCCAM Page Channel Channel List MessagePCCLM Page Channel CDMA Channel List MessagePCDBM Page Channel Data Burst MessagePCENLM Page Channel Extended Neighbor List MessagePCESPM Page Channel Extended System Parameters MessagePCFNM Page Channel Feature Notification MessagePCGPM Page Channel General Page MessagePCGSRM Page Channel Global Service Redirection MessagePCNLM Page Channel Neighbor List Messages


125

PCOM Page Channel Order MessagePCPM Page Channel Page MessagePCSLPM Page Channel Slotted Page MessagePCSPM Page Channel System Parameters MessagePCSRM Page Channel Service Redirection MessagePCSSDUM Page Channel SSD update MessagePCSTRM Page Channel Status Request MessagePCTAM Page Channel TMSI Assignment MessagePMRM Power Measurement Report MessagePRM Parameters Response MessagePSMM Pilot Strength Measurement MessageRDBM Reverse Data Burst MessageRFWIM Reverse Flash With Information MessageROM Reverse Order MessageRPM Retrieve Parameters MessageRSBDM Reverse Send Burst DTMF MessageSCCM Service Connect Completion MessageSCONM Service Connect MessageSEREQM Service Request MessageSEROCM Service Option Control MessageSM Status MessageSOCM Service Option Control MessageSPM Set Parameter MessageSREQM Service Request MessageSRESM Service Response MessageSTATRM Status Request MessageSTRM Status Response MessageSUM SSD Update MessageSYNC Sync Channel MessageTAC TMSI Assignment Completion MessageTAM TMSI Assignment MessageTAC TMSI Assignment Completion MessageTAM TMSI Assignment Message

Optimization Procedures and Guidelines, Ver 1.2Initial Coverage Test

126

8.0 Initial Coverage Test

8.1 DescriptionThe purpose of the initial coverage test is to characterize the coverage and performanceof a group (cluster) of cells that provide contiguous coverage. The initial coverage testwill identify coverage boundaries using measured (not predicted) data and initialize a callsampling benchmark. The initial coverage test will also continue to use the problemresolution matrix (PRM) to confirm predicted (via simulation) problems and record newproblems measured during the initial drive test. The initial coverage test drive data,combined with the call statistics, will provide guidance to focus troubleshooting andoptimization activities. The relationship of this initial coverage test activity to the entireoptimization process is shown in Figure 8.1-1.

Note that it is not the intention during this initial coverage test to perform any networkoptimization. The intent of the initial coverage test is to get an accurate “snapshot” ofinitial system performance as designed. Corrective actions may be required to ensure thatthe system performance snapshot is an accurate one, void of any system hardware andsoftware problems. Given a stable, accurate snapshot of the network performance, thenoptimization can start. Optimization is addressed as part of Chapter 9, Detailed ProblemResolution.


127





(Chapter 3)


(Chapter 4)




(Chapter 9)







System Designvia


(Chapter5)


(Chapter 7)


(Chapter 8)

Figure 8.1-1 Relationship of Initial Coverage Test Activity to Entire OptimizationProcess


128

8.2 Tools RequiredTable 8.2-1 contains a list of tools required to conduct the initial coverage test.Additional logistics and support items may be needed. Lead engineers should plan forefficient operations.

Item Description QuantityVehicle Preferably a van with enough room for all data

gathering equipment plus DM operators. Should beequipped for drive testing, including power source androuting for external antennas if necessary.

1 per team;number of teamsper cluster TBDby lead engineer

Lap TopComputer

Which can be used as a DM containing large harddrive (e.g. 2 GB), compatible with DM and GPS H/W& S/W, phone interface

2 per drive testvehicle

DM Software Capable of collecting IS-95 messages in differentmodes of operation (e.g. Markov, various rate sets)

1 per Laptop

GPS Position locating receiver compatible with DMsoftware and laptop computer.

1 per DM

CDMA Phonewith extrabatteries or poweradapter

Phone must have valid ESN and phone # forcurrent system.

1 Per DM

HP Pilot Scanner HP E7472A RF Measurement System or Equivalentfor proper frequency

1 per team

Analog or othernon-test phone

Used for coordinating activities with test leader andcontacting MTSO personnel or CFEs as needed, or foremergency purposes.

1 per vehicle

SMAP Used for collecting messaging and Reverse Link FERat the BTS/CBSC.

1 per MM

RF PerformanceAnalysis PostProcessing Tool

COMPAS, OPAS or equivalent that will enableplotting of RF performance characteristics

Scale toaccommodatenumber ofclusters

CDL AnalysisTool (CAT)

Used to verify system stability as part of post-processing and analysis.

1

PM Reports Network performance statistics that are displayedfrom the CBSC

1 per CBSC

Event Logs Used to verify system stability during initial coveragetest

1 per CBSC

Color Plotter orPrinter

Hewlett Packard or Equivalent Scale for numberof clusters

Table 8.2-1: Tools Required for Initial Coverage Test


129


Personnel Skills

DM Operator Good computer background, capable of operating DM, andCDMA phone. (See Appendix A)

Driver Valid drivers license. Must keep safety and comfort of datacollectors in mind at all times.

CBSC Engineer Strong in Unix operations and experienced in Motorolainfrastructure equipment. (See Appendix A)

System Engineer White Belt through Blue Belt as appropriate (See Appendix A)


8.4 Entrance CriteriaFor the cluster that will be tested, collect the data sheet(s) filled out during Single CellFunctional Test (Chapter 7) and examine them to verify that all cells in the cluster and thefirst tier surrounding sites have passed the SCFT. The cells must all be in service andstable with no service affecting alarms during the time of data collection.

8.5 ProcedureThe following activities are required in order to obtain an accurate report of the network’sperformance as designed:

- Generate Drive (Metric) Routes- Tools Preparation- Collect Performance and System Stability Data- Evaluate System Stability Data- Process and Plot Performance Data, Calculate Call Statistics- Data Analysis, Update Problem Resolution Matrix

Each of these is described below.

8.5.1 Generate Drive (Metric) Routes:

Guidelines are presented to develop coverage test drive routes:

- Obtain road maps for the cluster area and identify drive test or metric routesfor the cluster.

- Metric routes should focus on traversing the coverage area. The route shouldgo through all sectors and extend to the edge of the predicted coverage areas(use the simulation outputs to guide this part of the activity) and into coverageareas of surrounding tier sites (far enough to enter into soft handoff with thefirst tier sites).

- Special attention should be paid to points or routes of extreme interest such asstadiums, arenas, interstate or major highways, and locations where many


130

users may congregate. The customer should be consulted to help prioritizethese areas.

- Drive routes should be designed so they can be completed in a single shift.Include time for breaks, lunches, dinners, etc.

After the engineer specifies preliminary drive routes, the task of final route selectionshould be given to the drive teams. The final drive routes should account for one waystreets, construction, etc.

8.5.2 Tools Preparation

The following tools will need to be configured properly for operation in the cluster undertest:

- DM and/or Pilot Scanner- SMAP- Post-processing tools, including plotter and/or printer- Phone

8.5.2.1 DM/Phone Configuration

The DM should be properly configured to collect data in the cluster of interest. This willinclude setting up the PN-to-BTS/Sector conversion tables (named differently for variousDM products) so they are properly displayed on the real-time DM displays. Examples ofconfiguration items to verify would be slot cycle index, antenna configuration (e.g. hand-held or external mount w/ attenuators), etc.

Precaution: In areas of ICBSC-SHO, Markov mode should not be used if ICBSC-SHO is enabled. Markov calls are prohibited from doing anchor handoffs. For thisreason, clusters should be defined so they generally do NOT cross CBSC seams. Inareas near CBSC seams, use continuous voice calls (perhaps pegged to a radio stationre-broadcast) to collect continuous data. (There are separate issues associated withFER reporting when not using Markov calls. These are discussed below.)

8.5.2.2 HP Pilot Scanner Configuration

The HP pilot scanner will require configuring per the user’s manual. Primaryconsiderations are antenna placement for CDMA and GPS, connections betweenantennas, receiver unit, phone (if used), PC, and dead reckoning sensors if used. Inaddition, the software should be installed and verified.

8.5.2.3 SMAP BSC Configuration

SMAP profiles should be set up to collect data for the ESNs being used. Priority shouldbe given to the Markov or continuous call mobiles. In smaller systems with only a fewtest mobiles, all test mobiles can be logged. SMAP has a limit of logging 10 ESNs attime if configured properly. Refer to the SMAP documentation to identify and set up thecorrect profile or see http://scwww.cig.mot.com/~thakkar/smap.html for information onthe ISMAP script.



131

8.5.2.4 Post-Processing Tools Configuration

Refer to the individual tools user’s guides to install and test the post-processing andanalysis tools. These will include COMPAS/OPAS32/or equivalent, CDL Analysis Tool,PM Reports, and others as listed in Table 8.2-1. Many of these will already have been setup to facilitate the SCFT discussed in Chapter 7.

8.5.3 Collect Performance and System Stability Data

Data collection activities are broken down into (real-time) performance data collectionand (post-drive) stability and performance data collection.

8.5.3.1 Real-Time Drive Data Collection

The initial coverage drive should collect both call sampling and Markov data.Call sampling data can be collected in one of two manners. The first method would bethe most efficient, taking advantage of DM features such as drummer mode (CAMPS) toautomatically place calls at prescribed intervals for specific durations. Since originationsrequire more IS-95 message exchanges, this method also provides a more complete testof the system than terminations. Using this method, all calls placed along the entire driveroute would be mobile-initiated. If this approach is used during the initial coverage driveand subsequent metric drive routes, then at some point in the optimization cycle a specialtermination-only test should be performed. This can be facilitated by using a specialtermination test script found on the NSS Best Practices web page. Click on the scriptsbutton at: http://www.rochellepark.pamd.cig.mot.com/cdma/bestpractices.html.Download either the “16 Bit AutoDial! script Version 2.3 for Windows 3.1/95” or “32 BitAutoDial! script Version 3.1 for Windows 95/NT”. See the “Readme” information foradditional details on this tool. The data sheets in Appendix 7B should be modified forthe all-origination or all-termination test scenario.

The second approach would be to collect call data using the customer call model. Thecustomer should be consulted to determine the ratio of land-to-mobile and mobile-to-landcalls and the typical duration of each call. If used the call sampling data sheets shown inAppendix 7B should be modified to reflect the call model.

The Markov data collection sheet shown in Appendix 7A should be used to collectMarkov data. To minimize data loss, the maximum duration of Markov calls should be30 minutes. In addition, the following activities should be undertaken during the datacollection period:

- Problem Reporting: An appropriate command and control structure should be setup so that problems in the field can be resolved as quickly as possible. Reports ofoutages should be dispatched immediately to CBSC operators and/or CFE crewsto correct the situation. The lead engineer should act as the “switchboard” todirect all real-time problem resolution.

- CBSC Monitoring: MTSO personnel should be notified which cluster(s) arebeing driven so they know which CBSCs and BTSs to monitor for stability andavailability. This requires continuous vigilance for device outage and alarmconditions. Any service affecting outage should be reported to the lead engineerso he may notify drive crews and test leaders as quickly as possible. The SMAP

http://www.rochellepark.pamd.cig.mot.com/cdma/bestpractices.html


132

AP should be checked periodically to ensure that it remains operational andcontinues collecting SMAP data. This can be done by periodically checking theSMAP file sizes. Any problems should be logged in a notebook.

- CFE Crew Availability: CFE crews should be on standby to address any BTS-related outages that occur during the drive test.

- DM Monitoring: The drive team should be trained to continuously monitor theDM to make sure that it has not locked up and that the system always appears tobe operating properly.

8.5.3.2 Post-Drive Data Collection

Set up a logical directory structure that accounts for multiple types and sets of datacollected on multiple days. A sample directory structure that can be used to store data onanalysis computers is shown in Appendix 8A. Following the drive test activity, the datasets listed below will need to be collected in the appropriate directory in a central locationfor follow-up processing and evaluation:

- Drive test data for all test mobiles, including call sampling and Markov (orcontinuous) call mobiles. Transfer the mobile files to the appropriate directory onthe analysis computer.

- SMAP data should be retrieved if the tool was used during the drive test. This willbe used as input to generate RF performance plots. This data is typicallytransferred across a network to the analysis computer.

- CDLs for the ESNs that were used, and for the duration of the drive test, shouldbe extracted from the OMC-R. This data is typically transferred across a network.

- Event logs for the period of the drive test should be collected. This data istypically transferred across a network.

Caution: The optimization teams should adopt the policy to move data fromthe OMC-R and CBSC APs to different processing machines so that no dataprocessing occurs on the operational system.

8.5.4 System Stability Verification

This exercise includes verification that the system was stable during data collection.System stability can be quickly verified for the time during which data was collected byusing the Performance Management Reports (PMReports). PMReports are networkperformance statistics that are displayed from the CBSC. The PMSUM Suite of scripts isderived from the PM records, which are collected in the OMCR and reside on the AP(Application Processor). PMSUM suite of scripts combines the most widely used PMreports into four reports for easy usage.

1. The PMMCC report, will provide information for every channel with traffic. Thereport contains information on channel usage, OOS time, originations,terminations, access failures, RFloss and channel usage time per attempt. This


133

information is provided in the form of a report that can be easily viewed for eachcell in the drive area as shown in figure 8.5.4-1 below.

2. The CEM report, which provides information on unplanned BTS availability, totalBTS availability, and alarms within a 24hr period. Example reports are shownbelow in figure 8.5.4-2.

3. The PMSUM report, which includes the Cell RF Loss and Access Report, the CellHandoff Report, the MM Summary, the Carrier Summary, and the Worst 15 CellsFailing above 1%. These reports give details regarding walsh code hours, D-D, D-A, Soft and Softer handoffs, as well as much more. An example of each report isshown in figure 8.5.4-3.

4. The PMTRAF report reports traffic data including traffic minutes and load % asshown in figure 8.5.4-4.

After obtaining these reports review them to ensure that there were no outages or alarmsand that every cell/sector in the area being driven had channel usage. There may beinstances where a cell/sector in the area being driven will not report usage due to thedrive route designed for this area. In this case, it is important to review the first tworeports mentioned above.For executables, as well as documentation for the PMSUM suite of scripts visit theRochelle Park Software Archive web page:http//www.rochellpark.pamd.cig.mot.com/software.html in the “pmsum” section.


134

Figure 8.5.4-1: PMMCC Report

MCC AND CHANNEL REPORT

Cell MCC CEUsagemin

OOSmin

OrigAtts

OrigComps

OrigFail %

TermAtts

TermComps

TermFail %

RFLoss

RFLoss %

Usage/Att

5 1 2 61.8 19.2 34 29 14.7 7 7 0 2 5.6 90.45 1 3 84.5 19.2 25 23 8 11 9 18.2 4 12.5 140.95 1 4 53.5 19.2 24 23 4.2 17 14 17.6 7 18.9 78.25 1 5 64.7 19.2 31 28 9.7 13 11 15.4 3 7.7 88.25 1 6 67.5 19.2 27 27 0 6 6 0 2 6.1 122.85 1 7 59.6 19.2 21 20 4.8 13 11 15.4 3 9.7 105.1

5 2 0 54.5 19.5 27 26 3.7 12 10 16.7 3 8.3 83.95 2 1 81.5 19.5 21 19 9.5 12 11 8.3 1 3.3 148.15 2 2 74.3 19.5 23 22 4.3 13 11 15.4 5 15.2 123.85 2 3 76.3 19.5 26 23 11.5 15 15 0 2 5.3 111.65 2 4 58.2 19.5 20 20 0 13 12 7.7 2 6.2 105.85 2 5 63.5 19.5 21 19 9.5 18 16 11.1 6 17.1 97.65 2 6 62.5 19.5 26 23 11.5 10 9 10 2 6.2 104.25 2 7 53 19.5 29 27 6.9 8 7 12.5 3 8.8 85.9

Equation Notes:CE: Channel elementUsage min: Number of minutes channel element is in useOOS min: Number of minutes channel element is OOSOrig Atts: Origination AttemptsOrig Comps: Origination CompletesOrig Fail%: Origination (Attempts - Completes) / AttemptsTerm Atts: Termination AttemptsTerm Comps: Termination CompletesTerm Fail%: Termination (Attempts - Completes) / AttemptsRF Loss: Total of 1+2+3 way RF Losses on channel elementUsage/Att: Average number of usage seconds per attempt


135

Figure 8.5.4-2: CEM Report

8.5.4-2A BTS/MCC Availability

MM BTS SecTotMCCs

AvailableMinutes

OOSRedundantMinutes

OOSManualMinutes

OOSAutomaticMinutes

UnplannedOOS_AUTOAvail%

TotalAvail%

3 26 1 12 1440 0 0.5 0.2 99.99% 99.95%3 26 2 12 1440 0 0.5 0 100.00% 99.97%3 26 3 12 1440 0 0.9 0.2 99.99% 99.92%1 152 3 12 1440 0.3 1379.7 0 100.00% 4.19%1 164 3 12 1440 0 0.5 0.2 99.99% 99.95%2 169 1 6 1440 0.1 0 3.5 99.76% 99.76%2 169 2 6 1440 0 0 3.8 99.73% 99.73%1 191 1 4 1440 0 0 1.3 99.91% 99.91%1 191 2 4 1440 0 0 1.3 99.91% 99.91%1 193 1 4 1440 0 0 744.4 48.31% 48.31%1 193 2 4 1440 0 0 742.2 48.46% 48.46%1 207 1 4 1440 0 0 1 99.93% 99.93%1 207 2 4 1440 0 0 1 99.93% 99.93%2 304 2 12 1440 0 0.5 0 100.00% 99.97%2 308 1 10 1440 0 0 15.5 98.92% 98.92%2 308 2 10 1440 0 0 15.5 98.92% 98.92%2 308 3 10 1440 0 0 15.5 98.92% 98.92%2 308 4 10 1440 0 0 15.5 98.92% 98.92%2 310 1 12 1440 0 0 8.3 99.42% 99.42%2 310 2 12 1440 0 0 8.3 99.42% 99.42%2 310 3 12 1440 0 0 8.3 99.42% 99.42%2 310 4 12 1440 0 0 8.3 99.42% 99.42%


136

8.5.4-2B Device Outage and Alarm Listing

AlarmsMM Device Initial Status Final Status OOS

Manual(min)

OOSAuto(min)

OOSParent(min)

Cri Maj Min

1 CBSC-1 INS INS 0 0 0 0 0 31 FEP-1-1-8 INS INS 0 0 0 1 0 01 FEP-1-1-13 INS INS 0 0 0 1 0 01 MSIP-1-1-6 PRECUT PRECUT 0 0 0 0 2 11 MSIP-1-1-8 PRECUT PRECUT 0 0 0 23 9 81 MSIP-1-1-17 PRECUT PRECUT 0 0 0 18 20 21 MSIP-1-1-26 PRECUT PRECUT 0 0 0 1 0 01 MSIP-1-1-27 PRECUT PRECUT 0 0 0 1 0 11 MSIP-1-1-52 PRECUT PRECUT 0 0 0 1 14 71 MGLI-5-2 OOS_MANUAL OOS_MANUAL 1440 0 0 0 0 01 GLI-5-3 OOS OOS 0 1440 0 0 0 01 GLI-5-4 OOS OOS 0 1440 0 0 0 01 BBX-5-21 OOS_MANUAL OOS_MANUAL 1440 0 0 0 0 01 BBXR-5-21 OOS_MANUAL OOS_MANUAL 1440 0 0 0 0 01 BDC-5-3 OOS_MANUAL OOS_MANUAL 1440 0 0 0 0 01 MCC-5-21 OOS_MANUAL OOS_MANUAL 1440 0 0 0 0 01 MCC-5-22 OOS_MANUAL OOS_MANUAL 1440 0 0 0 0 01 CSM-106-1 INS INS 0 0 0 1 0 01 BBX-152-1 INS INS 0 0 0 0 8 01 BBX-152-3 OOS_MANUAL OOS_MANUAL 1380 0 0 0 0 01 BBXR-152-1 OOS_MANUAL OOS_MANUAL 1380.2 0 0 0 0 01 BBX-152-21 INS INS 0 0 0 0 19 01 BBX-152-23 OOS_MANUAL OOS_MANUAL 1379.3 0 0 0 0 01 BBXR-152-

21OOS_MANUAL OOS_MANUAL 1379.6 0.1 0 0 0 0

1 CSM-153-1 INS INS 0 0 0 1 0 01 BBX-153-1 INS INS 0 0 0 0 3 01 BBX-153-2 INS INS 0 0 0 0 2 01 BBX-153-21 INS INS 0 0 0 0 6 01 BBX-153-22 INS INS 0 0 0 0 1 0


137

8.5.4-2C Alarm Summary

Total First Last Sev Alarm # Card Description2 0:22 10:33 ** 1-1038 MGLI MF FAN #8 - Low Speed Alarm

3 11:22 16:49 1-1351 MGLI BTS LAPD GLI-MM Datalink - Failure: Recovered

2 12:33 14:31 1-1352 MCC BTS LAPD GLI Datalink #1 - Failure: Recovered






4 11:22 14:31 1-1372 BBX BTS LAPD GLI Datalink #21 - Failure: Recovered



2 1:12 2:01 ** Jan-50 LCI LPA Unit: Pilot Tone Suppression Alarm Detected

1 15:23 15:23 ** Jan-10 FEP FEP Detected Unroutable SCAP Message - Link not INS

2 0:46 10:10 *** Jan-11 FEP FEP Detected Unroutable SCAP Message - Path not Open

1 15:24 15:24 *** Jan-12 FEP FEP Detected Unroutable SCAP Message - Invalid Path

7 2:08 23:58 * Jan-02 BBX BBX - CHI Link B: Frame Sync Error

7 2:08 23:58 * Jan-12 BBX BBX - CHI Link B: Frame Slip Error

1 12:15 12:15 * Jan-20 BBXR BBX Detected Forward Link Parity Burst Error

3 12:15 12:15 * Jan-20 BBX BBX Detected Forward Link Parity Burst Error

257 7:27 18:16 ** Jan-41 BBX Forward Power Very High Alarm: Sector 1



437 6:38 21:51 ** Jan-51 BBX Reverse Noise Rise Very High Alarm: Sector 1

139 0:27 20:33 ** Jan-52 BBX Reverse Noise Rise Very High Alarm: Sector 2

Once the system and has been evaluated to determine that the data is worthy of beingprocessed and has some value, then the data should be processed. Not all serviceaffecting outages would necessarily dictate that the data does not have some value.Engineers will have to make judgement calls to determine if the data has merit.

8.5.5 Process and Plot Performance Data, Calculate Call Statistics

8.5.5.1 Process and Plot Performance Data

Using the post processing tool(s) selected and installed (Chapter 6), generate thefollowing, minimum set of RF performance plots:

- Forward Link Performance Plots:- Mobile Receive- Ec/Io- Frame Erasure Rate (FFER)

- Reverse Link Performance Plots:


138

- Mobile Transmit- Frame Erasure Rate (RFER) (this will only be possible if SMAP data is

available)

It will also be useful to plot and evaluate (if possible) the Active vs. Other Ec/Io Delta.This ratio gives an indication of where the active set pilots are relatively stronger (orweaker) than the rest of the pilots in an area, and can be useful in repairing possibleneighbor list and pilot pollution issues.

8.5.5.2 Calculate Call Sampling Statistics

For the call sampling ESNs used along the metric route, calculate call completion andcall drop statistics from the perspective of both the drive team and the CDLs. Anyoperator errors should be culled from the statistics.

Call Completion Rate

For drive test data, the formula to use for calculation of call completion rate (CCR) is:

CCR = Number of Completed CallsNumber of Attempted Calls

All operator errors should be excluded from this calculation.

For CDLs, the formula to use for calculation of call completion rate is:

CCR = S / X

Where: S = total number of calls completed as defined as the sum of all CDLswhose LAST_MM_SETUP_EVENTS is less than or equal to 17 andLAST_MM_SETUP_EVENTS is greater than or equal to 23.

X= total number of calls (i.e. CFC’s 1+3+4+5+9+13+…)

There may be a slight difference between these sets of statistics because some originationattempts may have never been “seen” or registered on the system. In addition, CDL callcompletion relies on the mobile reaching operation on the traffic channel. In someinstances, calls will get to traffic channel, but there will be no audio. Typically, theoperators do not regard these as completed calls. Note: The CDL Analysis Tool (CAT)generates call completion rates based upon specific releases. Refer to CATdocumentation for specifics.


139

Call Drop Rate

The formula to use for calculation of call drop rate (CDR) using drive test data is:

CDR = Number of Calls Ended Normally by EitherDM or Operator After Full Call Duration

Number of Completed Calls

The formula for calculation of call drop rate using CDLs is:

CDR = All RF Losses (CFC 4’s)All S’s except CFC 1’s and 25’s

Note: The CDL Analysis Tool generates statistics for call drop rate that are specific to agiven release.

These baseline statistics should be recorded or logged to start developing a performancehistory profile for this cluster.

8.5.6 Data Analysis, Update Problem Resolution Matrix

Following the guidelines outlined in Section 8.6, perform an initial assessment of the RFperformance of the cluster under investigation. This exercise will be used to confirm ifthe system design that was prepared for the area is accurate or not. In addition, assumingthe system was stable during the data collection, then this exercise will also identify anyother problems that were not originally indicated with the network planning tools.Once the area has been analyzed, then the Problem Resolution Matrix (PRM) should beupdated to capture all the problems. This PRM may be reviewed with customers to helpprioritize resolution of the issues.

8.6 Analysis ConductedAnalysis for this initial coverage test data is limited to review of the RF performanceplots to identify areas that do not meet specific RF performance criteria. Each of the RFperformance indication plots should be reviewed with the simple guidelines that follow.Particular focus should be given to revisit problems already existing in the PRM. Allproblems should be captured in an update to the PRM.

8.6.1 Forward Link Performance Evaluation

The forward link performance indicators evaluated should include Mobile Receive, Ec/Io,FFER, and Active vs. Other Ec/Io Delta. If the basic criteria listed below are not met, thearea on the map should be highlighted, defined as a problem, and entered into the PRM.


140

8.6.1.1 Evaluation of Mobile Receive Strength

Receive power is a composite measurement indicating the signal strength in the CDMAband of interest at the antenna. This level is primarily affected by the number of pilotsserving a particular area and the distance between the mobile and the BTS antennas.Terrain, foliage, buildings or highway structures between the mobile and BTS antennaswill reduce the measured signal strength at the mobile. Table 8.6.1.1 shows suggestedcutoff levels for acceptable signal strength based upon the number of pilots contributingto that composite measurement. Please keep in mind that these are suggestions derivedfrom field work, where fading, vehicle velocity, antenna placement, and other factorsaffect the “real world” measurements. (I.e. Results that would be obtained in a wired labor controlled experiment would be much better.)

Number of Serving Pilots Acceptable Mobile ReceiveLevel (dBm)

1 -872 -843 -82

>3 -80Table 8.6.1.1: Relationship Between Number of Pilots Serving an Area and

Acceptable Mobile Receive Signal Strength

Naturally, signal strengths measured closer to BTSs should be higher. If they are not, thiswould be an indication of a potential problem.

8.6.1.2 Evaluation of Ec/Io

Ec/Io is a measurement of usable energy in each chip (for a specific PN) as compared tothe total noise at a particular location. This value is used to trigger handoffs at themobile.

Any areas where all pilots are consistently below Tadd are a problem. These locationsshould be noted in the PRM. For these cases, signal strengths of the best potentialserver(s) will be primary candidates for increasing their signal presence in the area, viaeither antenna tilt or SIF power changes, in order to provide adequate signal quality. Thisproblem may or may not be combined with poor Mobile Receive power levels. Inaddition, suboptimal neighbor lists can create poor Ec/Io, regardless of receive levels.

Areas that have multiple pilots present, where all pilots fluctuate between Tadd+3dB andTdrop-3dB are areas referred to as non-dominant pilot areas. In this case, some of theserving sectors will have to be identified as candidates for power increases and/ordecreases. The key is to create an appropriate number of adequate pilots. If N-way isavailable, up to six pilots are useable. Without N-way, there should be no more thanthree dominant pilots in an area. Tradeoffs need to be made in surrounding areas. In anycase, this situation deserves to be an entry in the PRM.

8.6.1.3 Evaluation of Forward Link Frame Erasure Rate (FFER)

Forward FER typically is associated with areas of poor Ec/Io. However, there may stillbe areas of acceptable Ec/Io that have somewhat elevated FER. All locations where FER


141

rises above 2% should be a PRM entry. It is likely that this area can be improved unlessterrain, manmade obstacles, or interferers simply prevent adequate signal-to-noise ratio atthe mobile location.

8.6.1.4 Evaluation of Active vs. Other Ec/Io Delta

This performance parameter indicates where interference from useable pilots is simply anissue. If Active vs. Other Ec/Io < 0 in any particular area, then this location should be thetarget of an investigation and entered into the PRM. If the Active vs. Other Ec/Io > 0, thepilots contributing to the active set are stronger than the ones not in the active set. If theActive vs. Other Ec/Io is < 0, this means the composite energy is greater than the energyof the pilots in the active set, and therefore, create interference.

8.6.1 Reverse Link Performance Evaluation

Primary reverse link performance indicators include Mobile Transmit Power and ReverseFrame Erasure Rate (RFER).

8.6.1.1 Evaluation of Mobile Transmit Power

The maximum mobile transmit level allowed per IS-95 is 23 dBm. Most system designstry to maintain 6 dB of headroom under that limit. Assuming that the IS-95 link balanceequation is adhered to, and using the lower limit of –87 dBm for an acceptable forwardlink receive level, any areas where Mobile Transmit levels exceeds + 14 dBm should be aPRM entry. [Mob Tx = - (Mob Rx) + 73 + NomPwr + InitPwr]

8.6.1.2 Evaluation of Reverse Link Frame Erasure Rate (RFER)

Similar to the forward link, if FER on the reverse link rises above 2% in an area, this areadeserves to be an entry in the PRM.


142

8.7 Exit CriteriaThe following exit criteria should be met prior to taking steps to change the system(Chapter 9).

1. Data should be collected and verified as accurate and representative of initialsystem design. Some locations in the cluster may require data re-collection if therewere any service affecting problems in those areas while data was collected.

2. Call sampling statistics have been calculated and computed using drive team dataand CDLs respectively.

3. Cluster wide plots have been generated for the following RF performance attributes:

- Forward Link- Mobile Rx- Ec/Io- Forward FER- Active vs. Other Ec/Io Delta (desirable, but not necessary)

- Reverse Link- Mobile Tx- Reverse FER (if SMAP data is available)

4. The problem resolution matrix has been updated based upon the preliminaryanalysis outlined in Section 8.6.


143

Appendix 8.A: Sample Directory Structure

1. For Mobile logs, CDLs, Event logs, SMAP logs and SCUNO (or otherinformation) from the field:

/Hard Drive Partitions/Project Name/Subproject Identifier/Field_Data/Date/CBSC/Typeof data/- Hard Drive Partition (e.g. local_data)- Project Name (e.g. JCDMA)- Subproject Identifier (e.g. KCT)- Field_Data (use “Field_Data” as the directory name)- Date (YYMonDD – e.g. 98Apr02)- CBSC (e.g. B1)- Type of Data (e.g. mobile, CDLs, Events, SMAP, etc.)

Under Mobile directory:/CS (for call sampling logs) /ESN (e.g. 088d0c85) /Type of failure (e.g. FTO, DROP, etc.)/CS_out (for COMPAS reports)/Mkv (for Markov logs) /ESN (e.g. 04030c85) / Type of failure (e.g. FTO, DROP, etc.)/Mkv_out (for COMPAS reports)

2. For system configuration files (Antenna tilts, neighbor lists, etc.):

/Hard Drive Partitions/Project Name/Subproject Identifier/System_Config/- Antenna tilt list (naming convention: MMDD<System>_<name>; e.g.

0406K_antenna_tilt_list)- Neighbor lists (naming convention: MMDD<System>_<name>; e.g.

0415Q_master_list)- MIB (e.g. SIF pilot power list, CLI commands, etc.)

3. For Plots:

/Hard Drive Partitions/Project Name/Subproject Identifier/Plots/Date/- Plots (naming convention: <Area>_<variable>.plot; e.g. B1_EcIo.plot)

- Variables: EcIo, Tx, Rx, Fails


144

4. For Tools/Scripts:

/Tools/- pgrep- banditview- etc.

5. NetPlan Projects and Information (color files, etc.):

a) Analysis path and naming convention: NetPlan/Projects/Subproject ID/- MMDD<cluster><call type><time>

- Cluster = B1, B3, etc.- Call Type = C (Call sampling), M (Markov), S (Special test)- Time = N (Night); D (Day)

- (e.g. 0403KB3CN)

b) Color Files: NetPlan/color_files

Optimization Procedures and Guidelines, Ver 1.2RF Network Optimization

145

9.0 RF Network Optimization

9.1 DescriptionThe purpose of RF network optimization is to ensure each cluster is integrated into theoverall network and prepare the CDMA system for commercial service. When thisactivity is completed, the network should pass the final coverage test and contractualwarranty performance criteria. These are the performance targets that should be achievedby the network optimization team. This chapter provides guidance on characterizing andresolving a variety of common problems, with the emphasis on resolution of RFperformance problems. Problems can generally be classified into four main categories asfollows:

System Design – RF coverage, multiple pilot problems, parameter settingsInfrastructure – database errors, hardware and software problemsSubscriber Unit – phone problemsEquipment or Processing – problems with data collection or post-processing tools

References for basic optimization activities such as neighbor list prioritization and cellradius checking are provided. Detailed analysis for RF coverage problems will includeboth the forward and the reverse links. Multiple pilot problem analysis will coversolutions for both too many pilots and lack of a dominant pilot. Infrastructure andsubscriber unit problems will be discussed in less detail, as these are typically related to aspecific release or product issue. Additional reference material is contained in“Parameters and Optimization” found at http://www.cig.mot.com/~dillon/. It is not theintent of this chapter to recreate that information. Optimization engineers should readthat document and see http://scwww.cig.mot.com/people/cdma/PjM/product/release_info/for specific information for the release being optimized.

The relationship of this activity to the overall network optimization process is shown inFigure 9.1-1.

http://www.cig.mot.com/~dillon/



146





(Chapter 3)


(Chapter 4)



RF Network Optimization(Chapter 9)







System Designvia


(Chapter5)


(Chapter 7)


(Chapter 8)

Figure 9.1-1: Relationship of System Optimization and Detailed ProblemResolution

9.2 Tools RequiredTable 9.2-1 contains a list of tools required to conduct the RF network optimization.Additional logistics and support items may be needed. Lead engineers should planefficient data collection and processing operations. Specific considerations shouldinclude number of drive teams and vans, arrange night driving in crowded, congestedareas, and avoiding rush hour whenever possible with basic metric routes, scheduling ofCBSC operators and CFE personnel to support drive testing, availability of datacollection and post-processing tools. Other specific market concerns should be addressedas required.


147

Item Description QuantityVehicle Preferably a van with enough room for all data

gathering equipment plus DM operators. Should beequipped for drive testing, including power source androuting for external antennas if necessary.

1 per team;number of teamsper cluster TBDby lead engineer

Lap TopComputer

Which can be used as a DM containing large harddrive (e.g. 2 GB), compatible with DM and GPS H/W& S/W, phone interface


DM Software Capable of collecting IS-95 messages in differentmodes of operation (eg. Markov, various rate sets)

1 per Laptop

GPS Position locating receiver compatible with DMsoftware and laptop computer.

1 per DM

CDMA Phonewith extrabatteries or poweradapter

Phone must have valid ESN and phone # forcurrent system.

1 Per DM

Analog or othernon-test phone

Used for coordinating activities with test leader andcontacting MTSO personnel or CFEs as needed, or foremergency purposes.

1 per vehicle

SMAP Used for collecting messaging and Reverse Link FERat the BTS/CBSC.

1 per MM

RF PerformanceAnalysis PostProcessing Tool

COMPAS, OPAS or equivalent that will enableplotting of RF performance characteristics

Depends on howmany clustersare beingoptimized

CDL AnalysisTools

Used to verify system stability as part of post-processing and analysis.

1

PM Reports Network performance statistics that are displayedfrom the CBSC

1 per CBSC

Event Logs Used to verify system stability during systemoptimization

1 per CBSC

Table 9.2-1: Tools Required for RF Network Optimization


148

9.3 Personnel RequiredKey personnel required to conduct RF network optimization are identified in Table 9.3-1.Additional persons and skill sets may be required to address logistics and planning issues.

Personnel SkillsDM Operator Good computer background, capable of operating DM, and

CDMA phone. (See Appendix A)Driver/Navigator/Map Maker

Valid drivers license. Must keep safety and comfort of datacollectors in mind at all times.

CBSC Engineer Strong in Unix operations and experience in Motorolainfrastructure equipment. (See Appendix A)

System Engineers White Belt through Blue Belt as appropriate (See Appendix A)


9.4 Entrance Criteria1. An updated Problem Resolution Matrix contains a prioritized list of all the problem

areas identified in the initial (or most recent) coverage drive and latest simulationactivities.

2. Plots of the following RF performance are available from the previous drive test:

Forward link performance:• Mobile Receive• Forward FER• Aggregate Active Ec/Io• Active vs. Other Ec/Io Delta (to give an indication of pilot pollution)

Reverse Link performance:• Reverse FER• Mobile Transmit

3. A current list of Antenna azimuth and downtilt angles and SIF powers is available.These will be used to help generate recommendations for changes.

4. Contract warranty performance criteria are set and understood by the optimizationteam.

9.5 ProcedureThe high level, iterative procedure to determine whether the optimization activity for theinitial network configuration has been completed is shown in Figure 9.5-1. Initially, theinput data to this activity will be the Initial Coverage Test described in Chapter 8. Thedata will be used to support the basic optimization processes including integration of eachcluster into the overall network, neighbor list prioritization, cell radius checks, RF


149

coverage analysis, pilot pollution analysis, and basic database and infrastructure problemcorrections. Statistics and drive test data will be evaluated to determine if the networkperformance meets contractual warranty criteria. If so, then the optimization team shouldenter the final coverage drive and warranty test activity (Chapter 10). If the data does notpass the exit criteria, then necessary changesmust be made to enhance system performance. Change recommendations generated byvarious engineers should be reviewed by the lead engineer to ensure consistency for theentire area being optimized. Each change made in the system should be recorded andarchived so there is a history of each change and why it was made. These changes shouldbe entered on a “change request form” or a "change order” along with the PRM. Thechange request forms/orders are usually signed by a lead engineer and then given to theperson(s) who will be implementing the change. A copy of the change order shouldalways be kept by the optimization team in a central notebook or binder for easyreference. Three examples of these forms can be found in Appendix 9A. The results ofthese changes must be characterized by an iteration of data collection and analysis. Thisrepetitive process continues until the exit criteria are passed.

Figure 9.5-1: Overall Optimization Flow

Collect Data: DM,Scanner, SMAP, CDLs,

Event Logs

(Initial Set of Drive TestData is Generated During

Initial Coverage Test – Chapter 8)

Process data.Generate plots.Update PRM.

Chapter 9

Data Analysis: Neighbor List Updates, Cell Radius Checks, RFCoverage Repair, Pilot Pollution Clean Up, Infrastructure

Troubleshooting, Phone Problems, Data Collection Problems

Does the networkMeet the contract warranty

Performance criteria? Yes

Done, go toChapters 10 & 11

Evaluate all recommendations.Implement best recommendation.


150

9.6 AnalysisThe basic non-RF network optimization activity will be to ensure each cluster isintegrated into the overall network, while the RF network optimization activities includeneighbor list optimization, cell radius checks, RF coverage assessment, elimination ofpilot pollution, and correction of database and equipment stability problems. Thesetopics are discussed below.

9.6.1 Neighbor List and Cell Radius Checks

Two of the most basic checks that should be done for each set of drive data collected areneighbor list prioritization and cell radius checks. Neighbor lists are important to enablethe mobile to enter into soft handoffs with any PN offsets displaying adequate Ec/Io thatmay be present in an area. Cell radius checks are required to ensure that the mobile canuse PN offsets with adequate signal quality to access the system.

9.6.1.1 Neighbor list (NL)

Inaccurate neighbor lists (NL) can have adverse effects on the mobile operation. FERcan be caused by strong, interfering pilots that are not scanned or added to the active setbecause they are not found in the neighbor list update messages sent to the mobile. Thepresence of various pilots in the same geographic area mandates that those pilots be ineach other’s neighbor lists. Early in optimization, three primary data sources can be usedto update neighbor lists. These data sources are the DM, pilot scanner, and call proc logs.The DM and scanner will collect information on pilots present in a specific area. Sincemarkets may not have access to both a DM and pilot scanner, both methods are presentedbelow. Call proc logs should not be used as a source of optimization data, therefore theyare not discussed.

Later in optimization (e.g. friendly user or commercial stages) neighbor list optimizationshould be done using CDLs. A relatively new tool called nlp.pl5 can be used to optimizeneighbor lists using CDLs as the input. Reference information and this tool can bedownloaded from http://www.cig.mot.com/~reimrsrr/. Since this chapter primarilyaddresses the initial optimization activities, nlp.pl5 is not discussed here. Chapter 11,which discusses network monitoring, provides additional guidance on the usage ofnlp.pl5.

9.6.1.1.1 Neighbor List Optimization Using DM Data

Use of Dropped Call Data to Identify Neighbor List DeficienciesAfter a dropped call, look at the sync channel message to determine the PN offset themobile used to re-sync itself. If this PN offset was not in the active set when the calldropped, or in the last neighbor list update message (NLUM), either the PN offset shouldbe added to the neighbor lists of the active set or moved up to a higher position in theneighbor list. This will require looking at the messaging and/or using the tool calledSOS. See: http://www.cig.mot.com/~reimrsrr/SOS.html for more information on SOS.Selection of which neighbor list(s) the missing PN should be added to will be based onrelative distances and angles of the PNs serving the area where the call was dropped.

http://www.cig.mot.com/~reimrsrr/

http://www.cig.mot.com/~reimrsrr/SOS.html


151

Use of Extended Handoff Direction Messages to Re-Prioritize Neighbor ListsThe frequency of occurrence of Extended Handoff Direction Messages (EHDM) orHandoff Direction Messages (HDM), which are logged in the DM log files, can beeffectively used to rank the neighbors in the neighbor list and also can indicate missingneighbors. This is done by calculating the amount of time and number of times a sourcesector spends in handoff with other target sectors, and from this information a prioritizedneighbor list can be generated. This type of updating for the neighbor list can be donethrough tools like shotime, but one must be careful to make sure that data sampling isvalid for making the recommended changes. The follow is a list of question one shouldask before using drive test data to make neighbor list updates.

- Is the data sampling size statically significant?- Do the drive-test routes provide a balanced representation of the sector’s coverage

area?- Was there any malfunctioning, or out-of-service sectors in the area when the driving

was performed?- Are there hills, buildings, or other obstructions, which may explain the difference

between a manually generated or simulated neighbor list and the indicated changesfrom the data sample?

The shotime tool and reference documentation can be obtained from:http://www.cig.nml.mot.com/cdma/kctop/tools/shotime.html andhttp://tcsc.cig.nml.mot.com/~reisman/tools/sho_time.doc.txt

9.6.1.1.2 Neighbor List Optimization Using Pilot Scanner and MIL Pilot Analyzer

Pilot Analyzer RecommendationsThe Pilot Analyzer developed by MIL provides a variety of output recommendations,among them is neighbor lists. The "Pilot Analyzer: Design Overview and Users guide,"can be found at: http://engdb.tlv.cig.mot.com/tools/PilotAnalyzer.html

The following excerpt from MIL documentation provides theory of operation of how thepilot analyzer provides neighbor list recommendations:

Neighbor List recommendations are generated for all sectors and based upon a bin-by-bin evaluation of HP scanner drive test data. For each bin, the analyzer willidentify the best server seen in that bin. Then the analyzer will add all subsequentsectors above Tdrop to the neighbor list of the best serving sector for that bin. Theneighbor list order will then be determined by keeping track of the number of bins aneighboring sector is seen. The user can set a Neighbor Threshold in percentage inthe configure window. Neighbors with number of links less than this threshold willbe removed from the list. Default recommendation is set to 1% or set to 0% and filterthe list manually. When trying to generate a neighbor list the user will be asked to setup the maximum delta between the neighbor sector to the best server sector. After theNeighbor list has been generated it can be saved and loaded latter on. LoadingNeighbor list is done via the File Menu and viewing the neighbors graphically can bedone using the View Menu.

http://www.cig.nml.mot.com/cdma/kctop/tools/shotime.html

http://tcsc.cig.nml.mot.com/~reisman/tools/sho_time.doc.txt



152

9.6.1.2 Cell Radius Checks

The determination of proper cell radius settings is documented in “Parameters andOptimization” by Dillon/Anderson. See that document for details.

9.6.2 RF Coverage Problems

This section provides general guidelines for classifying and correcting RF coverageproblems. The emphasis is on improving or correcting those coverage problems thoughthe implementation of SIF pilot power, antenna azimuth, or antenna tilt changes.Additional checks are included to separate out infrastructure, mobile, or data collectionproblems. Appropriate references to additional information are provided.

The improvement of poor RF coverage areas can be classified into three basic cases. Thefirst case is characterized by low mobile receive levels next to the cell site. The secondcase attempts to improve coverage at the outer bounds of the network’s predictedcoverage area. The third case involves correcting a localized coverage hole within thepredicted coverage area, but not near a cell site. Once a problem area has been properlycharacterized, then corrective actions are recommended to resolve the poor coveragecondition.

The entrance criteria to investigate and correct poor coverage problems is that field datahas been collected, processed, and the following images or plots are available:

1. Mobile receive (Rx)2. Mobile transmit (Tx)3. Mobile Ec/Io4. Mobile Forward FER5. Ec/Io per PN of interest.

In addition, RF coverage prediction images and database information such as SIF pilotpower settings, antenna configuration information (azimuths, tilts, beam patterns), andneighbor list information should be available.

9.6.2.1 CASE 1: Poor RF Coverage Next To Cell Site

To start, review the mobile receive plot to identify any low Mobile Rx values near thecell sites. Low mobile Rx should be considered less than –85 dBm or values that aresignificantly less than the mean values near sites for the specific system under evaluation.A poor RF coverage pattern next to the cell site can be caused by obstacles such asbuildings, trees/foliage, or terrain, or may be caused by antenna nulls in the vertical beampattern that are appreciable and impact the signal strength. These conditions will tend tocause acute irregularities in the homogeneity of mobile receive levels as the mobile’sdistance increases from the site. In some cases, the antennas may be mounted directly onthe top of buildings, but not close enough to the edges, thereby creating shadowingdirectly underneath the antennas. Antenna tilt angles should be verified, and the engineershould be aware of the antenna heights to determine if the receive value is reasonable forthe equipment installation and configuration. The optimization engineer should work toidentify if any obstacles could be the cause of low mobile receive levels and either workaround or remove those obstacles if possible.


153

If obstacles are not determined to be the cause of the low mobile receive, one should nextinvestigate possible infrastructure problems to determine if the site was off the air or notfully functional during the data collection period. This type of situation is evidenced inthe mobile receive plot as lower than expected values around the entire site or in aspecific sector. Of course some mobile receive energy will be indicated from distantsites, but the key is to look at adjacent sites and compare the mobile receive levels on thesuspect site to others and determine if they are relatively consistent at similar distancesfrom the cell sites. Event logs, alarms, and CDLs should be checked to see if any serviceaffecting alarms were registered on the site, and whether or not the site was taking callsfrom the test ESN(s) while the data was collected in that area. Finally, the engineershould investigate database errors related to mobile receive levels, such as SIF pilotpower settings. Additional information on how to troubleshoot these infrastructure issuesis found in Section 9.6.4.

The last item to check is whether the data collection equipment (including the phone),method or processes deployed in the data collection, and post-processing tools workedcorrectly. Some insight into these problems can be derived from Sections 9.6.6.

9.6.2.2 CASE 2: Evaluating Coverage At The Limits of the Predicted Coverage Area

The best indicator to use to determine whether or not coverage can be improved at thelimits of the network is mobile transmit power (mobile Tx). Typically the reverse link(mobile Å base station) is the limiting link due to power restrictions of the mobile. Referto the predicted “mobile transmit power required” image and compare that to themeasured data. If the measured and predicted data are within 6 dB of each other, and themobile Tx level is high, (over +17 dBm), then the network can be considered to benearing its coverage limit. To confirm whether the issue is truly a coverage problem,verify that the mobile receive and transmit level (path balance) comply to the IS-95specification (Section 6.1.2.3) at the start of a call:

Mobile Tx (dBm) = - Mobile Rx (dBm) – 73 + NOM_PWR (dB) + INIT_PWR (dB)

(NOM_PWR and INIT_PWR can be found in the database and are described in Dillon’s,“Parameters and Optimization”: http://www.cig.mot.com/cdma_ase/index.html If themeasured data does not adhere to this equation within 6 dB, then there may be excessiveinterference on either the forward or reverse link, or there may be equipment problemsthat require investigation. If the data conforms to the guideline, then increasing theforward link SIF pilot power on sectors serving the coverage-challenged areas will notimprove performance because the reverse link will not improve anyway. An antennaangle change (azimuth or tilt) might provide some incremental improvement, and thiscould be investigated.

If the Tx power has some headroom available, than changing the SIF pilot power and/orantenna pointing angles may improve the problem area. Caution should be taken toensure that other adjacent areas are not adversely affected and priority is given to areascompeting for coverage as desired. Also, increasing SIF pilot powers and modifyingantenna pointing angles to extend coverage areas can lead to overshoot problems thatshould be avoided (see Section 9.6.3, Pilot Pollution). Discussion below in Section9.6.2.3 provides guidelines for “dialing in” SIF power levels and changing antennapointing angles. Finally, with increased power and/or up-tilts one might need to increase



154

the cell radius in the database. For more information on cell site radius see Dillon’s,“Parameters and Optimization” http://www.cig.mot.com/cdma_ase/index.html.

A clear understanding of the limits of a network’s coverage is key to streamlining theoptimization activity and to avoid wasting effort in areas that aren’t predicted to becovered. The initial coverage drive should have been designed to extend slightly beyondthe predicted coverage area. Initial optimization should be conducted to maximize thenetwork’s measured coverage area, but it is important to not go past the point ofdiminishing returns. Subsequent drives do not need to be so generous after the coveragebounds have been maximized. Communication, understanding, and resolution of themeasured versus predicted coverage bounds is imperative. Despite this, in someinstances there is some justification to continue collecting data outside of the maximized,measured coverage area. For example, consider the need to travel from one area ofcoverage to another area of coverage along a specific metric route passing through anuncovered area. The area may be targeted for future cell sites, and collection of dataalong those routes would be helpful to identify the optimal number and locations of theBTSs. One caution related to this is that collection of data outside of the predictedcoverage area will skew the statistics of the overall drive. Data collected in theuncovered areas should be removed from the reporting of statistics and performancetrends, especially for warranty testing purposes (Chapter 10).

9.6.2.3 CASE 3: Poor RF Coverage Inside The Predicted Coverage Area, But Not NextTo A Cell Site.

The following 5 steps should be followed to diagnose and select specific PNs whosesignals should be strengthened to repair coverage problems, then determine the requiredchange in SIF pilot power or antenna pointing angle to repair the problem.

Step 1: Verify Existence of Coverage Problem Areas

The first step is to verify that areas exhibiting low Rx values and correspondingly highTx values inside the predicted area of coverage are actually performing poorly. Again,Table 8.6.1.1, “Relationship Between Number of Pilots serving an Area and AcceptableMobile Receive Signal Strength,” (in chapter 8) is a general guideline identifyingacceptable receive levels based upon the handoff state of the mobile. In general, themore pilots serving a given area the greater the measured mobile receive power shouldbe. Case 2 above identifies reasonable cutoffs for mobile Tx values. Once the areas havebeen identified, then the forward and reverse link Frame Erasure Rates (FER) should beevaluated. It is possible to have a low receive and high transmit power and still havegood FER if noise (Io) is minimal in the area (e.g. only one server is present in an area).However, when low receive values are coupled with multiple servers, then thesesituations need to be investigated. Generally, areas where forward FER values exceed 2percent should be investigated.

Step 2: Identify Candidate PNs Serving, or Which Should Serve, The Problem Area

At this point, one needs to get a general understanding of which sectors or PNs are, orshould be, providing service in a given problem area. Also, one needs to evaluate theassociated signal quality for those PNs. PN plots, plots of Ec/Io for various PNs, are



155

generated using the mobile diagnostic monitor’s measured and recorded temporalanalyzer data. This data represents the three “finger offset” values or fields in theprocessed data. The individual sectors or PNs serving a particular problem area can beextracted from the mobile messaging by looking at the Power Strength MeasurementMessages (PSMM). Make a list of all PNs and their corresponding Ec/Io values servingthe problem area. There may be problems with specific sectors not transmitting orneighbor lists may not be accurate and therefore not reported by the PSMMs. Thesesituations should be investigated and corrected.

Step 3: Evaluate PN Plots for Sectors Serving the Problem Area

For each PN serving the problem area, a PN plot should be generated. The PN plots forindividual sectors should be examined to determine the “reasonableness” of each sector’scoverage footprint. Examples of poor footprint patterns would include:

1. PNs that do not show up, especially along the main beam (bore), of the sector.

2. PNs that are inconsistently scattered throughout the intended coverage area.

3. PNs present throughout the intended coverage area, but consistently exhibiting Ec/Iovalues that are generally below Tadd.

4. PNs extending beyond the first tier of surrounding cell sites. (See Figure 9.6.3-4:Compas Plot illustration overshooting PN)

PNs exhibiting any of these characteristics should be investigated to determine ifobstacles are causing localized degradations in mobile receive/transmit levels that couldbe worked around by raising antennas, changing pointing angles, or increasing SIF pilotpowers. Slight path imbalances can occur on the forward and reverse links due tomultipath conditions caused by natural (terrain, trees) or man made (buildings) obstacles.

A fair evaluation of the PN plots requires that the data being evaluated adequately coverthe area of interest (sufficient drive routes). An incomplete data set might make a sectorthat actually has a good coverage footprint look like it is incomplete.

Step 4: Identify Which PNs Can Be Improved Using Mobile Tx As Guide

Similar to Case 2, the mobile Tx levels can be used to determine if the problem area canbe improved. If the Tx value is above +17 dBm, and there is no interference, the mobileis having difficulty maintaining the reverse link. If the Tx plot shows marginal (+10 to +17 dBm) or adequate (< + 10 dBm) values of mobile Tx, but the mobile Rx level is poor,then forward link improvements should be investigated. This is best achieved eitherthrough changes in SIF power values, antenna point angles, or a combination thereof.

To determine which sites/sectors should be changed, one should consider the followingquestions for each site/sector serving the poor coverage area:


156

1. Is the coverage problem very localized, and would re-directing the RF energy into theproblem area with a change in antenna azimuth or tilt help? If so, which sector wouldprovide the most improvement (based on distance between the candidate antennasand problem area and angle off main antenna beam bore)?

2. Is the coverage problem more widespread, and would a broader correction (increase)of SIF pilot power in the entire area be a better solution? If so, which sector wouldprovide the most improvement (based on relative distances from the problem area andcandidate servers)?

3. Whether the best correction is a change in antenna pointing angle or SIF pilot power,what penalty would be paid, in terms of degrading other areas, if the modification(s)were implemented?

Modifying the database or antenna configurations to correct a problem could introducenegative impacts in surrounding or adjacent areas. Prioritization of coverage areas andmaintaining pilot dominance (Section 9.6.3) are critical.

Isolating Forward and Reverse Link ProblemsThe mobile messaging sequence can be examined to determine if a coverage issue hasresulted from a forward link or reverse link problem. Forward link deficiencies (highforward link FER) will be characterized by a high number of Power Measurement ReportMessages (PMRM). See Dillon’s document describing normal forward power controloperation. The PMRMs are typically accompanied by repeats in the reverse link (mobileÅ base station) that requiring an acknowledgement (e.g. PSMM), receiving inconsistentor non-existent responses returned from the BTS. Repeat messages can be identified bydeciphering the (acknowledgement sequence, message sequence, acknowledgementrequired) settings on IS-95 messages. Similarly, forward link deficiencies can becharacterized from mobile logs by the following scenario.

1. The mobile is receiving messaging from the base station.2. The mobile is sending acknowledgement responses back to the BTS for the

messaging that require response.3. Then the BTS sends the same message or messages with the same

acknowledgement sequence number, but increments the message sequencenumber.

For more detail on mobile messaging, see the “CDMA Call Flow Examples” in theCDMA Cellular Air Interface for “IS-95A” and “TIA/EIA-95-B” at:http://www.cig.mot.com/standards/CDMA_STDS/TIA_CDMA_STDS.html#ai

Most of forward and reverse link information can be derived from examining the datacollected by a DM. If additional verification is required, messaging collected at theBTS/CBSC can be logged using SMAP. SMAP will also provide reverse FER data. Theuse of SMAP will necessitate additional data transfer time along with processing time.http://scwww.cig.mot.com/~thakkar/smap.htm)


http://scwww.cig.mot.com/~thakkar/smap.htm


157

Step 5: Determining Power and Tilt changes

SIF Power Changes

Permanent changes in SIF pilot power should be directed toward affecting a widespreadcoverage problem area where a particular PN serves. The diagnosis should indicate thatan increase of a particular sector’s power level will not adversely affect surrounding oradjacent areas (i.e. introduce pilot pollution or non-dominant conditions).

To make a noticeable change in the coverage, a minimum SIF change of 2 dB should beinvestigated. A rule of thumb would be to try increments of 3 dB to see usefulimprovements. It is recommended that the power differences between adjacent sectorson the same cell site do not exceed 6dB. This large variation could cause degradation insystem performance when a CDMA system becomes loaded. For, allowable BTS PilotPower Adjustment Ranges see Table 5-7 in the “CDMA RF Planning Guide”. Thisdocument can be downloaded from:http://www.pamd.cig.mot.com/nds/cts/rftech/public_html/Documents/RFPG2.1/rfguideV2.1.html

A precise estimation of what the SIF pilot power value should be can be arrived at bycalculating the power at the BTS antenna, and using the mobile receive level to calculatethe path loss. For equations related to calculating the path loss see “Propagation Modelsin the CDMA RF Planning Guide”. Using the calculated path loss information one canderive the required SIF power setting. Ideally, one would then run a simulation to verifythat the new value does not have any negative impact.

Antenna Pointing Angle Changes

Redirecting antennas will reallocate the RF energy in a most efficient manner. Thissolution should be considered for acute, focused problem areas requiring substantialcorrection. In general, implementation of antenna angle changes is more timely andcostly than SIF power changes. There also may be added complexity when CDMAantennas area shared with other cellular technologies, such as analog or TDMA networks.Options for electronic vs. mechanical tilting should be investigated. If the antennaredirection produces minimal results, the effort for the antenna redirection might not bejustifiable.

Investigation of changes in azimuth or tilt angles can be simulated, short term, byincreases or reductions in SIF pilot powers. This will require a very focused drive test inthe problem area; care must be taken on deriving conclusions from surrounding areas thatmay appear degraded or improved. If the problem area has been improved with thesimulated antenna redirect, then the antenna redirection should be implemented, and thearea re-driven to verify its performance. Calculations (described below) should be madeto determine what change in SIF pilot power could emulate an antenna tilt anglechange(s). For example, if an area at the edge of the coverage area (distant from the

http://www.pamd.cig.mot.com/nds/cts/rftech/public_html/Documents/RFPG2.1/rfguideV2.1.html

http://www.pamd.cig.mot.com/nds/cts/rftech/public_html/Documents/RFPG2.1/rfguideV2.1.html


158

closest site) required 3 dB of additional power to provide adequate Ec/Io, the SIF powercould be increased that 3 dB to emulate an antenna uptilt.

The two methods for antenna titling are electronic titling, using an N-element phasedarray antenna, or mechanical tilting by physically tilting an antenna. Down tilting, canhelp RF coverage holes near the site were there are nulls in the antenna pattern. Downtilts are also deployed to reduce pilot pollution by changing the RF propagation pattern orfootprint. Up tilts are used to extend the RF propagation pattern or footprint. Up tilts,can be used in addition to SIF changes to extend the coverage of a sector.

Calculating Antenna Tilt Angle ChangesThe optimization engineer can use three approaches to evaluate antenna patterns anddetermine a required tilt change. One should select between 3 and 5 key points tocalculate the change in power distribution related to an antenna tilt. These points shouldbe selected at different distances to understand the effects on coverage footprint the tiltchange will induce. The three basic approaches are:

1. Use of Antenna Catalogs to estimate beam patterns.2. Graphically using a simulation software such as NetPlan.3. Numerically using Unix commands in conjunction with NetPlan antenna files.

Use the information gathered from the sources above to complete the exercise below.

a. Calculate the angle between vertical and the ray defined by the endpoints of theantenna location and the problem area location. The following equation can beimplemented in Excel:

A = ROUND(-DEGREES(ATAN(((h+ges)-(getl+toh))/dtl)),2)

A = Angle to target (degree); h = Ant_height

ges = Ground_elevation_at_site;getl = Ground_elevation_at_target_locationtoh = Target_object_height; dtl = Distance_to_target_location

b. Identify the antenna gain from the antenna beam pattern. In the NetPlan directory theantenna directory contains files related to the vertical tilt for each antenna type. Forexample, the file md8cr6xs8-5.v is for this antenna type at a down tilt of 5 degrees. Thisfile contains a table that starts at –90 degrees and for each entry increments by one degreefor the “Angle to target”. The data entries in the file are for the antenna vertical gain.The up tilt data files in NetPlan use the letter “u” in front of the angle. For example, thefile name md8cr6xs8-u1.v would be for the same antenna types as given above, butrepresents an antenna tilt set at one degree positive. Use these files to look up theantenna vertical gain for the current antenna tilt and the tilt angle or angles underconsideration.

c. For angles to the target containing fractions of a degree, use interpolation between therounded up/down angle to arrive at a vertical gain.


159

d. Finally, subtract the old tilt gain from the new tilt gain to get the “gain difference” forthe tilt change.

9.6.3 Pilot Pollution

This section contains procedures to help engineers identify and analyze pilot pollutionand non-dominant pilot problem areas as well as determine solutions to eliminate orreduce the problem.

The basic process for identifying pilot pollution and non-dominant pilots is the same.Pilot pollution (too many pilots) can be defined as the existence of four or more pilotswith Ec/Io values greater than Tadd. To correct this problem the engineer needs decreasethe amount of energy to the problem area.

Lack of dominance can be defined as low Ec/Io levels, numerous pilots with similarvalues of Ec/Io, and four or more pilots above the Tadd threshold. To correct thisproblem the engineer needs to make up to three of the pilots in the area stronger or theother ones weaker. These changes will create pilot dominance in the area and reduce thenumber of pilots that appear in the active set, therefore reducing the amount ofinterference in the area.

Examples given below primarily make use of Motorola tools (NetPlan & COMPAS).Other equivalent system planning and simulation tools providing the same informationcan be substituted. For a partial list of available planning and simulation tools refer tochapter 2; for other tools refer to chapter 6. Some ideas are also presented for marketsthat do not use planning and simulation tools.

Details of the basic processes which are discussed below involve:

1. Verify the neighbor list is complete

2. Verify there are no PN reuse issues.3. Create data table.4. Determine line of sight5. Identify overshooting sites6. Determine corrective action7. Evaluate recommendations8. Implement changes

1. Verify the neighbor list is complete. See section 9.6.1 for a detailed discussion onneighbor lists and neighbor list tools.

2. Verify there are no PN offset reuse issues. PN offset reuse problems occur whendifferent sites/sectors, which provide overlapping coverage use the same PNoffsets. In these cases, the MM may not make a correct decision of whichBTS/Sector is being represented by a particular PN. Interference will occur whenthe MM assigns channels from the incorrectly selected BTS to a mobile within theoverlapping coverage areas. The engineer analyzing the problem area should befamiliar with the PN offsets assigned to the sites in that area.


160

In addition, cell radius sizes should be consistent with the coverage footprint ofdifferent sectors. Cell radius sizes for various releases can be found on theparameters web page, and explanations of cell radius settings are contained in theCDMA RF Application Note: Parameters and Optimization, all located athttp://www.cig.mot.com/cdma_ase/index.html.

To investigate PN offset assignments and rule out any potential problems, the PNoffsets assigned to a BTS can be graphically displayed using various tools. Onemethod is to use the CDMA PN offset/handoff tool in NetPlan. By creating a textfile which identifies each BTS, sector and corresponding PN offset, the engineercan display all the PN offsets for the BTSs in a system analysis. An example ofthe text file display is shown in figure 9.6.3-1 and an example of the graphicaldisplay is shown in figure 9.6.3-2. The text file should be put into the Compasdirectory of NetPlan.

NetPlan - PN offset plan* Copyright(s) by Motorola Inc.* All Rights Reserved.* PN offset plan: Our_system*BTS/Sector PN

105/1 16105/2 20.105/3 24103/1 4103/2 8103/3 12124/1 28124/2 32124/3 36124/4 40124/5 44124/6 48

Note: This is only a sample, the entire PN plan would have to be in put into textformat.

Figure 9.6.3-1: PN offset plan (text file)



161

Figure 9.6.3-2: PN Output Plot in Compas

The pilot analyzer tool can also be used to view all PN offsets in an area. Theinputs to this tool are files from the HP pilot scanner. This tool can draw a plot ofthe drive route which can show areas of high FER, pilot pollution, and poor Ec/Io.For more information on this tool, see chapter 6 of this document, or the web pageat http://engdb.tlv.cig.mot.com/tools/PilotAnalyzer.html. Table 9.6.3-1 shows theoutput of a pilot pollution area as detected by the pilot analyzer.

Index Pilot Ec/Io Pk.Power

Ag.Power

Samples Delay Spread

1 348 -6.56 -70.69 -70.51 1 19.12 0.002 345 -9.80 -73.93 -73.93 1 19.61 0.083 180 -11.58 -75.71 -75.71 1 18.63 0.544 198 -13.53 -77.65 -77.65 1 27.47 0.255 27 -15.07 -79.20 -79.20 1 48.22 0.006 408 -15.13 -79.25 -79.25 1 28.95 0.007 18 -15.24 -79.37 -79.37 1 38.39 0.00

Table 9.6.3-1: Pilot Analyzer Output

If a PN reuse problem is confirmed, the engineer should re-assign PN offsets forone of the conflicting sites. For additional information on PN planning refer tothe CDMA RF Planning guide located athttp://www.rochellepark.pamd.cig.mot.com/~blashkar/bestpractices.html, selectthe RF Planning button.

3. Create data table. Whether the problem is too many pilots or lack of a dominant pilotthe beginning objective is to identify:

A. All sites/sectors pointing into the problem area.



162

B. The distance from the sites serving the area to problem areaC. Ec/Io values for PN offsets serving the problem area.

A. List all sectors pointing into the problem area. This can be done by reviewingthe mobile messaging collected within the problem area. The Pilot StrengthMeasurement Message (PSMM) contained in the mobile messaging lists thePN offsets serving that area as well as their pilot strengths. All PN offsetsserving the area should be recorded in a data table, such as the ones shown intables 9.6.3-2 and 9.6.3-3, along with their pilot strengths. Somecorresponding mobile messaging follows. The first illustrates the lack of adominant pilot in an area, four pilots are all within + 1.5 dB of each other and+ 1.5 dB of Tadd. The second illustrates too many pilots in an area. In thiscase, seven pilots are seen, all greater than or equal to Tadd. The PSMMshave been highlighted for easy reference.


163

Table 9.6.3-2: Data table for Non-Dominant Pilots

BTS-Sector

&PN#

Ec/Iovalue(dB)

Distancefrom

Sector toProblem

area

Improvementreq’d in Ec/Io

(dB)

Angle offAntenna

Bore-sight indegrees

Antennachange?

LOS orTerrainIssues?

SIF Powerchange?

297-2PN 156

-12.5 2 Km 3.5 5 No No Increase by3 dB

260-1PN 264

-14.5 2.2 Km 4 0 2° uptilt No No

297-2PN 152

-13.5 2 Km

298-1PN 40

-14 8.5 Km

298-3PN 48

-13 8.7 Km 2 90 No Small hills Increase by2 dB

Example 1: Lack of dominant pilot

23:50:40:881, FEB 08 1999, HANDOFF, PSMM, <--, 4, 0, 1, ENCRYPTION=0,REF_PN=156, PILOT_STRENGTH=-12.500000, KEEP=1, PN_OFFSET=264.0,PILOT_STRENGTH=-14.500000, KEEP=1, PN_OFFSET=152.0, PILOT_STRENGTH=-13.500000, KEEP=1, PN_OFFSET=40.0, PILOT_STRENGTH=-14.0000000, KEEP=1,PN_OFFSET=48.0, PILOT_STRENGTH=-13.0, KEEP=1,23:50:41:059, FEB 08 1999, HANDOFF, PMRM, <--, 4, 6, 0, ENCRYPTION=0,ERRORS_DETECTED=2, PWR_MEAS_FRAMES=36, LAST_HDM_SEQ=2, NUM_PILOTS=2,PILOT_STRENGTH=-13.000000, PILOT_STRENGTH=-14.50000023:50:41:169, FEB 08 1999, HANDOFF, NLUM, -->, 0, 7, 1, ENCRYPTION=0


164

Table 9.6.3-3: Data table for Too Many Pilots

BTS-Sector

&PN#

Ec/Iovalue(dB)

Distancefrom

Sector toProblem

area

Improvementreq’d in Ec/Io

(dB)

Angle offAntenna

Bore-sight indegrees

Antennachange?

LOS orTerrainIssues?

SIF Powerchange

295-2PN 16

-9.5 4 Km 20 No

230-1PN 104

-12.5 7 Km -3 45 No No Decreaseby 4 dB

219-3PN 96

-13.5 10 Km -2.5 25 No No Decreaseby 3 dB

298-1PN 40

-8 2 Km 5 No

298-2PN 44

-10 2 Km -4.5 90 3.5°downtilt

Multipathfrom

building

No

295-2PN 12

-11.5 5 Km -4 120 3° downtilt Scatter fromhills

No

297-2PN 152

-9 3 Km 10 No

Example 2: Too many pilots

03:04:34:789, FEB 03 1999, HANDOFF, FOM, -->, 2, 0, 0,ENCRYPTION=0, USE_TIME=0, ACTION_TIME=0, ORDER=16,ADD_RECORD_LEN=003:04:34:803, FEB 03 1999, HANDOFF, PSMM, <--, 7, 4, 1,ENCRYPTION=0, REF_PN=16, PILOT_STRENGTH=-9.500000, KEEP=1,PN_OFFSET=96.0, PILOT_STRENGTH=-13.500000, KEEP=1,PN_OFFSET=40.0, PILOT_STRENGTH=-8.000000, KEEP=1,PN_OFFSET=152.0, PILOT_STRENGTH=-9.00000, KEEP=1,PN_OFFSET=104.0, PILOT_STRENGTH=-12.500000, KEEP=1,PN_OFFSET=12.0, PILOT_STRENGTH=-11.50000000, KEEP=1,PN_OFFSET=44.0, PILOT_STRENGTH=-10.000000, KEEP=1

The engineer should also include PN offsets for sectors that are physicallypointing in towards the problem area and may not show up in the PSMM. Thislist will be used later to determine corrective action.

B. List the distance (physical, i.e. miles/km) from the site broadcasting aparticular PN offset to the problem area. The distance between the site andthe problem area will help you prioritize which PN offsets require adjustmentsto the SIF pilot powers or antennas to eliminate the problem. The distancefrom the BTS to the problem area can be determined using the path profilefeature in NetPlan, this distance can also be determined using topology mapsor other system planning tools. The distances identified should be recordedalong with information obtained in step A.


165

Figure 9.6.3-3 illustrates the path profile plot generated when using NetPlan. TheX axis represents the distance between the cell site (the first latitude and longitudelisted) and the location of the problem area or mobile (the second latitude andlongitude listed). In addition the bearing from the cell site to the problem area ormobile with respect to due north is provided. The Y axis shows the height abovesea level in meters with the thin line, and the antenna height is represented withthe heavy line. The dotted line from the top of the antenna to the problem area ormobile is the Fresnel zone. The solid upper line is the direct line of site from theantenna to the problem area or mobile. The solid lower line represents the terrain.

Figure 9.6.3-3: NetPlan Path Profile Plot

C. List the Ec/Io values for the PN offsets listed in steps A and B. Sites withEc/Io values significantly below Tadd should be considered as sites on whichto perform corrective action.

4. Determine Line of Sight. Determine if the sectors identified in step 3 above haveunobstructed line of sight with the problem area. This can be done using the pathprofile feature mentioned in item B above (see figure 9.6.3-3), in NetPlan/COMPAS.This may also be done with other planning tools that check line of sight or byreviewing topology maps and site pictures that provide a view of surroundingbuildings and/or terrain. If none of the above is available a site visit may benecessary. If sites have obstructed views which contribute to the interferenceproblem they can be included on the list of sites to be considered for correctiveaction.

5. Identify overshooting sites. Identify any PN offsets that originate from more than onetier away from the site surrounding the problem area. If using COMPAS use the PNplot feature to plot individual PN offsets. See the COMPAS output in example 9.6.3-4.


166

40

297

148

152156

260

264

268272

295

8

1216

298

4448

40

230

104

108112

219

88

9296

Non-dominant

server area PilotPollution

Area

Figure 9.6.3-4: COMPAS Plot Illustrating an Overshooting PN

The pilot strength information and the PN distance information obtained in step 2can be used to determine overshooting PNs by correlating the PNs identified inthe problem area with the PNs that should actually be serving the area. PNs thatovershoot their expected coverage area should be put on the list of candidates forcorrective action. It is most desirable to provide coverage in all areas using theclosest site.

A data table such as the one shown in Figure 9.6.3-5 is helpful in keeping track ofinformation obtained in the previous steps. It will assist the engineer inidentifying candidate sites for corrective action.


167

6. Determine Corrective Action. After reviewing the list of data collected from theprevious steps the engineer must determine which PN offsets require corrective actionin order to remove the pilot pollution. The key is to create an appropriate number ofadequate pilots, preferably three. For cases of too many pilots, the objective is toremove the excessive numbers of strong pilots by increasing or decreasing the amountof energy of each pilot either by changing SIF powers or making antennaadjustments. In example 1 in section 3.A there are 7 pilots listed in the PSMM for theproblem area. PN 16, pilot strength = -9.5, PN 40, pilot strength = -8.0 and PN 152,pilot strength = -9.0 are the three best active PN offsets illustrated by this example. Ifsteps 1-5 have already been completed and the remaining four PN offsets are listed inthe data table for corrective action, the engineer should decrease the total amount ofenergy provided by these site in the area with SIF power changes and/or antennachanges.

For non-dominant pilots, the engineer needs to up to three of the pilots in the areastronger. In example 2 in section 3.A, there are five PN offsets in the PSMM. Allfive have relatively low pilot strengths. After completing steps 1-5, the engineershould select the strongest three pilots and increase the energy provided by them tothe area. It may also be necessary to decrease the energy of the other PN offsets.

After determining how many dB the various sectors must be raised or lowered, theengineer must determine whether an antenna adjustment or a SIF power change is thebest solution to correct the problem. Refer to section 9.6.2 for information regardingantenna adjustments and SIF power changes. If neither a SIF power change or anantenna adjustment is effective by itself, a combination of the two may be useful.

7. Evaluate recommendations. Determine if the proposed changes will adversely affectother areas. Some things to check for:

A. Will antenna/SIF power changes decrease/increase coverage for thissite or adjacent areas?

B. Will antenna/SIF power changes create pilot pollution problems inadjacent areas?

After evaluating the results of proposed changes, decide which change will have themost positive effect and create the least amount of problems for the area in questionand adjacent areas. Make recommendations.

**Note: Proposed recommendations may require changes to the neighbor list ifenergy from various BTS/Sectors is redistributed.


168

8. Implement recommended changes. Update the Problem Resolution Matrix and re-drive the problem area. Process the data and re-evaluate to determine if problem hasbeen resolved. If the problem still exists, repeat this process again until the pilotpollution is eliminated or no further improvements can be made.

There are cases for which it may be impossible to completely correct the pilot pollutionin an area. These cases should be handled on an individual basis, each being reviewedwith the customer to determine the most acceptable solution.

Additional information on optimizing pilot pollution can be obtained from the CDMA RFApplication Note: Parameters and Optimization located onhttp://www.cig.mot.com/cdma_ase/index.html.

9.6.4 Infrastructure Issues

During the optimization, problems may be encountered in areas where the RF coverage isadequate and Ec/Io for all pilots is good. When problems are encountered in good RFcoverage areas, focus should turn to identifying potential infrastructure problems.Various indicators can help the optimization team isolate these problems. Thoseindicators primarily come from three sources:

- Drive team and/or CBSC operator reports- Call Final Classification (CFC) Distributions- Event Logs / Alarms

Evaluation of these sources of data can lead to isolation of the problems. Drive teamreports that may indicate specific problems include:

- Access attempts that repeatedly fail in a particular area- PN offsets that should be “seen” at a particular location are not registering on the

DM- Handoffs are not occurring at a particular location (inter-sector, inter-cell, inter-

CBSC, inter-EMX)- High RF Loss rate- Consistent or predictable drops, after a certain period of time or in a specific area.

Assuming that the data collection equipment was operating properly, then CFCs shouldbe examined to determine if there is any hardware or database configuration problems.CFCs can be used to troubleshoot a variety of infrastructure problems.

Event logs contain site/sector status and alarm information that can be evaluated todetermine the stability and functionality of the hardware, as well as provide indicators onthe presence of interference in the system.

A systematic approach to isolate possible infrastructure (database or hardware)configuration problems is represented below. The primary focus is on BTS and CBSChardware and database issues. (The EMX is not discussed). Figure 9.6.4-1 shows thehierarchy of the CDMA system. A more detailed diagram can be found in the SystemCommands Reference Volume 4 Device State Management (Figures 12-2 to 12-4).


http://www.cig.mot.com/~dillon/params/Pamind.html


Figure 9.6.4-1 System Architecture Overview

• EMX – Switch orand Public phone

• OMCR – Applicamanage BTS sof

• XC – Transcoder• MM – Mobility ma• BTS – Cell Site c

PSTN

Public PhoneNetwork

EMX

Switch

XC

(Transcoder)MM

(Mobility Manager)

OMC-R

(OperationsMaintenance

Center- Radio)

BTSLINK

MSC re system

tion allotware, a convernager hommun

BTS GLI CSM BDC LCI BBX MCC

CBSC

169

lays call status information and voice between the CBSC.wing engineers to manipulate the database, load andnd monitor system performance data.ts STRAU data to QCELP format.andles call processing functions for mobile stations.

icate over IS-95 air interface link with mobile stations.


170

9.6.4.1 Common Drive Team Failure Reports

The drive team will occasionally report problems to the system engineers. The driveteams written test logs can be used to verify where and when the problems occurred.Table 9.6.4.1-1 contains a list of common drive team problems. Along with thesesymptoms, likely causes and suggested follow-up investigations are presented.

Symptom Likely Cause(s) InvestigateBTS is off the air. Check device status, and

alarms.Access attempts arerepeatedly failing in aparticular area Mobile subscriber access

class (SAC) is setincorrectly.

ACCOLC in CBSC and inmobile.

BTS is off the air.PN offsets in databasehave been changed or areincorrect.

Device status, alarms, andCBSC database (SECGEN).

PN offsets that should be“seen” at a particular locationare not registering on the DM

Antennas are hardwiredincorrectly.

Check BTS hardware andcabling configuration.

GPS is not working.CSM is not working.

Check alarms and devicestatus; follow up with sitevisit by CFE.

Handoffs are not occurring ata particular location (inter-sector, inter-cell, inter-CBSC,inter-EMX) Neighbor lists are

inaccurate.Routing tables areincomplete.

Review NL, XC-sectdatabase and routing tables.

A BTS is off the air. Check alarms and devicestatus.

Call drop rate is extremelyhigh; (Mobile Rx value maybe lower than normal). Mobile antenna location

and orientation problem.Review equipmentconfiguration with driveteam.

Mobile subscriber accessclass discrepancy.

Check ACCOLC of mobileand CBSC database.

Calls drop or fail to accesstraffic channels consistentlyafter a specific period of time. Call setup failure in

infrastructure.Check device status andalarms.

Table 9.6.4.1-1: Drive Team Problem Reports and Likely Causes


171

9.6.4.2 Problems That Can Be Diagnosed Using CDLs/CFCs

The use of Call Detail Logs (CDLs) at the CBSC can help narrow down the time whenhardware or database problems were experienced. CDLs should be correlated withevents such as drop calls and access failures. The following steps will outline theprocedure to collect, process, and analyze CDLs.

1. Data Collection

CDLs located and downloaded from the OMC-R in the /sc/cdl/ directory. Thesefiles will be named in the format of “cdl” and date (i.e. cdl.YYYYMMDDHH) andshould be FTP’d to the engineers’ local computer.

2. Data Processing

The CDLs can be processed using cdl_browse and the CDL Analyzer Tool (CAT).Find these tools and usage documentation athttp://www.cig.mot.com/~wheelrts/cat1_5.html

3. Data Analysis

The CAT will create several reports that will effectively show the CFC distributionand highlight any abnormal levels of CFCs that may indicate an infrastructureproblem. The reports generated by the CAT can be used to find potential problemswith the infrastructure configuration or database and are described in detail athttp://www.cig.mot.com/~wheelrts/CAT1.5/docs/analyzer.doc.

Table 9.6.4.2-1 is a normal distribution of CFC’s for one CBSC. A “normal” distributionwill vary between markets due to configuration differences. However most optimizedsystems have CFC distributions where typically CFC 13’s will be less than 9’s will beless than 5’s. If there is an unusually high percentage of non-RF related CFCs (see below9.6.4.2 #2) the CFC in question should be investigated and reported to the CBSC anddatabase engineers.

http://www.cig.mot.com/~wheelrts/cat1_5.html

http://www.cig.mot.com/~wheelrts/CAT1.5/docs/analyzer.doc

http://www.cig.mot.com/~wheelrts/CAT1.5/docs/analyzer.doc


172

CFC Raw Total % of Call Total1 184608 84.77%3 428 0.20%4 4705 2.16%5 2423 1.11%7 32 0.01%8 166 0.08%9 31 0.01%

13 2 0.00%15 807 0.37%24 7787 3.58%26 16220 7.45%27 60 0.03%28 10 0.00%60 319 0.15%62 187 0.09%

130 1320 0.61%255 10 0.00%

SUB 217785 100.00%

Table 9.6.4.2-1: “Normal” CFC distribution

CFC’s 24 and 26 are considered good calls. A CFC 26 typically happens when a mobileis paged but not answered, a timer at the EMX expires and disconnects the call.Including the 24’s and 26’s our “call completion rate” goes up to 95.8%.

If a particular drive test has a high number of abnormal CFCs, i.e. not within the normalCFC distribution as seen in Table 9.6.4.2-1, follow the steps below to troubleshoot thecause of the CFC.

1) Align the drive test log sheet data with the CDLs and determine the CFC for theproblematic call. In order to align the CDLs with the mobile data, first look at thedrive test logs and identify where and when the problem occurred. Notice in thisexample the first failed call was at 8:23 a.m. Also note the dialed digits, ESN, andmobile ID from the drive test logs. Next look through the CDLs for fields with datathat match the ESN, ACCESS_TIME, ACCESS_BTS, ACCESS_SECTOR,ENTRY_TYPE, and DIALED_DIGITS. Once the closest match is found, the CFCfrom the CDL will illustrate the type of failure the drive team was experiencing. SeeFigure 9.6.4.2-1 (example of drive team log sheets with FTO’s) and Figure 9.6.4.2-2(the corresponding CDL) for an example of correlating these two data sources. Lookat the highlighted areas in the drive team log sheet and the CDL, again notice that theaccess times do not match. The access and disconnect times will not be the samebetween mobile data and CDLs. This is due to the mobile data time source beingGPS where the CBSC time source is an internal clock.

2) Determine what type of failure the mobile is having. In the example below a CFC 9 isseen as the failure. In order to determine whether the failure is database or hardwarerelated, the engineer should become familiar with what each CFC means. The CFCResolution document describes in detail the most common CFCs seen during system


173

optimization, what equipment those CFCs relate to, and possible solutions to alleviateeach particular CFC. This document can be found athttp://www.cig.mot.com/~bohrer/cfc1.2.pdf.

http://www.cig.mot.com/~bohrer/


174

Date: MOBID: ESN: Operator

Zone: Direction &: Phone Manufacturer & Version: Number to DialArea

CallType

#ofType

Call #

DM Time Call Proc Time Ref # Location

VOXQual.

FTOFTT RF

NoService

Analog

D-AH/O

OpErr Active(s) File Name Comments

M-L 1/ 1 08:17:00 : : .

M-L 2/ 2 08 : 19:00 : : .

M-L 3/ 3 08: 21: 00 : : .

L-M 1/ 4 08:23:00 : : .

M-L 4/ 5 08: 25: 00 : : .

M-L 5/ 6 08:27:00 : : .

M-L 6/ 7 : : .

L-M 2/ 8 : : : : .

M-L 7/ 9 : : : : .

M-L 8/ 10 : : : : .

M-L 9/ 11 : : : : .

L-M 3/ 12 : : : : .

3/19/99 440-782-7444 086FC1C82

CBSC 1

4th & Roswell St. 1 214, 218, 320 0319990817.qlc

4th & Fleming Ave.1

222, 324, 418 0319990819.qlc

4th & Becker Ln. 1 332, 418, 124 0319990821.qlc

D 8

Bob Testerman

X

X

X

Becker & Austin Way

Becker & 23rd

Becker & 30th

124

124

128

0319990823.qlc

0319990825.qlc

0319990827.qlc

X RF Loss on Becker & Ranch

FTO Weak Ec/Io -13

FTO Weak Ec/Io -19

FTO Weak Ec/Io -17

Pulling over to call lead engineer

090-2897-9961

Figure 9.6.4.2-1: Drive Test Log Sheet to correlate with CFC 9 problem.


175

BROWSE CDLLOG

MSI-4407827444 99-03-19 15:19:50 omc MM-1 L000000.00000 010938/051106 CDL:1 "Call Detail Log" CDL_SEQ_NUM=0x2aba LAST_RF_HIGA2_INTERVALS=0 CALL_REF_NUM=0x0c46 LAST_RF_HIGA2_BEGIN=0x0000 CBSC=1 LAST_RF_HIGA2_END=0x0000 MMADDR=0xe1 LAST_RF_HIGA2_COUNT=0 XC=1 LAST_RF_HIGA2_TEMP=0x0000 CPP=4 LAST_RF_SETP2_INTERVALS=0 MID=4407827444 LAST_RF_SETP2_BEGIN=0x0000 ESN=0x86fc1c82 LAST_RF_SETP2_END=0x0000 SCM=0x62006200 LAST_RF_SETP2_COUNT=0 MOBILE_PROTOCOL_REV=3 LAST_RF_SETP2_TEMP=0x0000 DIALED_DIGITS=09028979961 LAST_RF_CONN1_MMADDR=0xe1 ACCESS_TIME=8:19:33 LAST_RF_CONN1_BTS=214 ACCESS_PN_OFFSET=124 LAST_RF_CONN1_SECTOR=3 ACCESS_STR=0x0243 LAST_RF_CONN1_SSECTOR=0 ACCESS_CHANNEL=76 LAST_RF_CONN1_3SECTOR=0 ACCESS_BTS=214 LAST_RF_CONN1_4SECTOR=0 ACCESS_SECTOR=3 LAST_RF_CONN1_5SECTOR=0 ENTRY_TYPE=0 LAST_RF_CONN1_6SECTOR=0 SERVICE_OPTION=0x0003 LAST_RF_CONN1_MCC=1 NEGOTIATED_SO=0x0003 LAST_RF_CONN1_ELEMENT=9 LAST_MM_SETUP_EVENT=25 MCC_RELEASE1_TIME=0xe1d2 CIC_SPAN=18 LAST_RF_HIGA1_INTERVALS=0 CIC_SLOT=1 LAST_RF_HIGA1_BEGIN=0x0000 XCDR=0x1e06 LAST_RF_HIGA1_END=0x0000 INIT_RF_CONN_BTS=214 LAST_RF_HIGA1_COUNT=91 INIT_RF_CONN_SECTOR=3 LAST_RF_HIGA1_TEMP=0xe177 INIT_RF_CONN_MCC=1 LAST_RF_SETP1_INTERVALS=0 INIT_RF_CONN_ELEMENT=9 LAST_RF_SETP1_BEGIN=0x0000 INIT_RF_CONN_CHANNEL=76 LAST_RF_SETP1_END=0x0000 CFC=9 LAST_RF_SETP1_COUNT=255 RELEASE_TIME=8:19:40 LAST_RF_SETP1_TEMP=0xe0b3 XC_RELEASE_TIME=0x0000 FIRST_MAHO_TIME=0x0000 INIT_MM_REL_EVENT=7 FIRST_MAHO_CAUSE=255 ONE_PILOT_COUNT=0 FIRST_MAHO_ACT_STR=0x00 TWO_PILOTS_COUNT=0 FIRST_MAHO_CAND_COUNT=0 THREE_PILOTS_COUNT=0 FIRST_MAHO_CAND1_PN=0 FOUR_PILOTS_COUNT=0 FIRST_MAHO_CAND1_STR=0x00 FIVE_PILOTS_COUNT=0 FIRST_MAHO_CAND2_PN=0 SIX_PILOTS_COUNT=0 FIRST_MAHO_CAND2_STR=0x00 LOC_S_ADD_COUNT=0 FIRST_MAHO_CAND3_PN=0 LOC_SR_ADD_COUNT=0 FIRST_MAHO_CAND3_STR=0x00 LOC_S_DROP_COUNT=0 INIT_MAHO_TIME=0x0000 LOC_SR_DROP_COUNT=0 INIT_MAHO_CAUSE=0 EXT_S_ADD_COUNT=0 INIT_MAHO_ACT_STR=0x00 EXT_SR_ADD_COUNT=0 INIT_MAHO_CAND_COUNT=0 EXT_S_DROP_COUNT=0 INIT_MAHO_CAND1_MMADDR=0x00 EXT_SR_DROP_COUNT=0 INIT_MAHO_CAND1_BTS=0 BETTER_ACTIVE=0 INIT_MAHO_CAND1_SECTOR=0 NUM_SR_SHUFFLE=0 INIT_MAHO_CAND1_STR=0x00 NUM_BTS_SHUFFLE=0 INIT_MAHO_CAND2_MMADDR=0x00 NUM_S_SHUFFLE=0 INIT_MAHO_CAND2_BTS=0 LOC_S_PILOTS_REL=0 INIT_MAHO_CAND2_SECTOR=0 LOC_SR_PILOTS_REL=0 INIT_MAHO_CAND2_STR=0x00 EXT_S_PILOTS_REL=0 INIT_MAHO_CAND3_MMADDR=0x00 EXT_SR_PILOTS_REL=0 INIT_MAHO_CAND3_BTS=0 RELEASE_L_CE=0 INIT_MAHO_CAND3_SECTOR=0 RELEASE_L_WC=0 INIT_MAHO_CAND3_STR=0x00 RELEASE_E_CE=0 LAST_MAHO_TIME=0x0000 RELEASE_E_WC=0 LAST_MAHO_CAUSE=0 NUM_SHO_FAILURES=0 LAST_MAHO_CAND_COUNT=0 FIRST_SHO_FAIL_TIME=0:00:00 LAST_MAHO_ACT1_MMADDR=0x00 LAST_SHO_FAIL_CAUSE=0 LAST_MAHO_ACT1_BTS=0 LAST_SHO_FAIL_TIME=0:00:00 LAST_MAHO_ACT1_SECTOR=0 LAST_HO_BLOCK_CAUSE=255 LAST_MAHO_ACT1_STR=0x00 LAST_HO_BLOCK_TIME=0:00:00 LAST_MAHO_ACT2_MMADDR=0x00 LAST_HO_BLOCK_PN=-1 LAST_MAHO_ACT2_BTS=0

Figure 9.6.4.2-2: CDL Log Correlating to Drive Team Log Sheet


176

If the CFC in question appears to be an infrastructure issue, review the CBSC log sheetand look for any maintenance or outages related to maintenance. Also review alarmreports and BTS status reports generated at the OMCR. Table 9.6.4.2-2 contains a list ofcommon optimization problem symptoms along with likely causes and suggested followup activities.

Symptom Possible CFC Possible Problem Investigate IndividualDevices or

Parameters3, 5, 6, 7, 9, Site off the air.

BTS device is OOS.Too far from site.

BTS and CBSCdevice status. Devicechecks shouldinclude.Alarms and EventLogsSite Radius andSearch Window size.

BTS hardware statusCell RadiusMobile SearchWindows

11 – 23, Lack of resources Blocked calls fromlack of hardwareresources.

MCC Usage, XCusage, mobile accessclass

High FTO’sAccess attempts arerepeatedly failing in aparticular area

50 – 103,109, 255

MM, MSC, or XCproblem.Data call problem.

XC outages orconfigurationproblems.Links between MM,BSC, and MSCData call hardwarestatus.

MMTranscoderSwitchIWUCDPCPP

BTS or BTS devicesare OOS.BTS database is notcorrect.

Device status andalarms for thespecific BTS.SECGEN (list ofPNs) for BTS beingtested.

BTS devices such asBBX, BDC, andMCC.

Wrong PN’sPN offsets expectingto be “seen” at aparticular location arenot registering on theDM

3, 5, 6, 7, 9, 13, 15,255These CFC’s mayappear due toaccessing aneighboring site withno good RF signal.

BTS antennaconfiguration.

BTS antenna installreports (if available)

Antenna cablinginside the BTS.

Table 9.6.4.2-2: Optimization Problem Troubleshooting Table (start)


177

8, 10 Poor RF conditions inHard H/O area.MCC problem withHard H/O.

Neighbor Lists (XC-sects)RF coverageDevice statusPN offsets

SECTOP (NeighborList)SIF PowersMAHO/ DAHOparametersSECGEN

26 – 29, EMX configurationproblems

Device Status ofEMX

104 – 108, Data Calldisconnected.

Device status andconfiguration

IWU, CDP, CPP,status

Failed H/O’sHandoffs are notoccurring at aparticular location(inter-sector, inter-cell, inter-CBSC,inter-EMX)

130 – 133 Inter-CBSC H/OfailureXC failure

Neighbor ListsBSC statusXC status

XC-sectsICTRKGRP

3, 4 One site may beOOS.Poor neighbor listSite parameters maybe incorrect.Poor BTS antennaconfiguration.RF coverage

Database settings.Device status.

BTS statusSECTOPSIF PowersXC status andconfigurationBTS antennaorientation.Mobile Rx & Txlevels

27, 28, 29 Switch configuration. Device status MSC, BSCXC-sect

104 – 107 Data call devicemalfunction


IWU, CDP, CPPSPAN

High Drop RateCall drop rate isextremely high;(Mobile Rx valuemay be lower thannormal or mobile Txmay be higher thannormal).

130 – 133 Devices at BSCTranscoder problem

Device status BSCXCXC-sect

3, 4, 8, 10 Site may be OOS.Too far from BTS

Device status.Access parametersnot set correctly.

BTS device status.Search Window sizeCell Radius

15 Mobile overload classis not set correctly.

Service optionnegotiation settings.

Mobile ACCOLC.Service optionparameters on BSC.

27 – 29 Problem with inter-CBSC database orhardware.Switch problem

Inter-CBSC handoffdatabase.Device status

ICTRKGRPXC-sect tables,Neighbor lists.EMX

104 – 109 Data call devicemalfunction


IWU, CDP, CPPSPAN

Consistent DropsCalls drop or fail toaccess consistentlyafter a specific periodof time or in aspecific place.

130 – 133 Transcoder problem Device status andconfiguration

XCXC-sect

Table 9.6.4.2-2: Optimization Problem Troubleshooting Table (finish)


178

9.6.4.3 Problems That Can Be Diagnosed Using Event Logs and Alarms

Data Collection

Event Logs can be downloaded from the OMCR (located at /sc/event/ ). The raw eventlog files are in ASCII format and do not need to be processed by any tools.

Data Analysis

These logs will show all system “events” that occurred during each hour. Reviewing theevent logs during the hour in which call failures occurred can provide helpfulinformation. Alarms are rated as follows:No star = Warning* = Minor** = Major*** = CriticalMajor and critical alarms often can be service affecting.For example, if during one drive test a specific cell site could not do hand in or hand outs,a CSM (clock synchronization module) event or alarm may be seen when looking at theevent logs for that site during the time frame of the handoff failures. An alarm such asthis may be seen:

ALARM:1-10030Severity = CriticalDescription = CSM Lost Phase LockCategory = CSM/MAWI

If there are failures during the drive test and any pertinent events or alarms are found,correlate the specific alarm with the drive test logs. The specific event may have causedthe drive test failure if the alarm was generated in that time period. There are manyevents and alarms logged. A complete list of all events and alarms can be found athttp://www.cig.mot.com/~dimeo/all.alarms in comma delimited text format. The SystemOutput Messages Reference gives a detailed description of what the events and alarmsmean. This document can be downloaded fromhttp://www.cig.mot.com/CIG/IviewDocs/cdrom2/cci/www/colls/sc_pf/226a252.coll.As these event logs can be very large, it is useful to use UNIX commands such as “grep”to pull specific events from the event logs. If an alarm indicates that a device went out ofservice (OOS) for a period of time, scroll down through the event logs and verify that thedevice was repaired and put back into service, otherwise notify the lead CBSC engineerand lead System engineer immediately.The following hardware hierarchy should be used in the BTS troubleshooting process:BTS->BTSLINK->GLI->CSM->BDC->LCI->BBX->MCC.BTS related problems should be escalated to the CBSC engineers and Cellular FieldEngineers (CFE). Again relay as much detail as possible when escalating the problem.

http://www.cig.mot.com/~dimeo/all.alarms

http://www.cig.mot.com/CIG/IviewDocs/cdrom2/cci/www/colls/sc_pf/226a252.coll


179

9.6.4.4 Problems That Cannot Be Diagnosed or Resolved

If a problem cannot be diagnosed or resolved, it should be reported back through theproper channels. Table 9.6.4.4-1 shows the areas where problems may be seen by the RFoptimization team and who they should contact. Any problems should be noted in thePRM and the Optimization team leader or lead engineer should be informed with as muchdetail as possible.

HARDWAREProblem Area/Item Escalate ToBTS A CFE should be contacted to remove and replace the

board/part. Fill out change request form (see appendix 9A)and note in PRM.

Link Notify CBSC engineer and CFE and note in PRM.CBSC/XC/EMX Notify CBSC engineer and note in PRM.

SOFTWAREMobile Take mobile out of testing pool. If possible, send back to

manufacturer or reload software and retest.BTS Card 1. Look at FYI’s* and other available information from

CNRC.2. Call CNRC at 800-433-5202 or 847-632-5390 to speakwith a person to obtain more information if necessary.3. If this problem has not been reported to development andshould be, open an MR**.

CBSC/XC/EMX Notify CBSC engineer.

*FYI’s can be found at http://mcsc.cig.mot.com/Search/, click in the check box before“FYI – For Your Information”. Choose to sort the results by score, date or doc andchoose how many results per page to be displayed. If desired enter a start date and enddate and product name, then click the “Search” button.**To open an MR, follow the instructions found athttp://scwww.cig.mot.com/SC/sw/BuildGroup/www_sablime/sabfaq/sabfaq.html#a5-3.

Table 9.6.4.4-1 Problems Seen and Escalation Procedures

9.6.5 Subscriber Unit Issues

Call statistics are typically used to gauge network performance and partially verify thecontractual warranty performance agreement. Sometimes the statistics can be skeweddue to one or more poor performing mobiles. Identifying and removing any problematicmobiles will more accurately represent system call statistics. The performance should bemonitored for all mobiles used in drive testing. Sometimes one mobile may be testing inparticularly poor RF coverage, therefore do not assume the mobile is “bad” by looking atonly one drive test. In most cases the drive test team will know if a mobile is performingabnormally poor. The drive team should be trained to notify a system engineer if amobile is having a high number of failures.

http://mcsc.cig.mot.com/Search/

http://scwww.cig.mot.com/SC/sw/BuildGroup/www_sablime/sabfaq/sabfaq.html#a5-3


180

There are several ways to determine if there is a “bad mobile”, one of the most effectiveways is to use the CDL’s and the CAT. This process should be done even if the statisticsappear to be within a normal range. It is important to know that all mobiles areperforming within a similar statistical range.

1. Run the CAT on CDLs from the mobiles used in the optimization drive tests. Reviewthe output files esn.t20, esn_cfc.dst, and call_dur.dst to determine if the problem is asubscriber unit issue.

A. The esn.t20 (ESN Top 20) looks at CFCs 3, 4, 5, 6, 7, 9, 13, 27, 61, 62, and 255for each ESN. It also produces a Top 20 list for all access failures. For each CFCranked statistics are provided in two distribution categories, ”Highest raw totals”and “Highest percent”. Figure 9.6.5-1 is an excerpt from esn.t20. This exampledemonstrates how the two rankings, “Highest raw totals” and “Highest percent”are split up.

Unique ESNs = 32Top 20 list for CFC dist on ESNESN RAW PERCENTHighest raw totals for CFC= 363e60c83 2 16.6721300c97 2 2043b0c81 2 10b5de0c83 2 109c9b0c83 2 18.188be20c97 2 7.6927f1d0c97 1 33.337c020c97 1 20Highest percent for CFC= 3431d0c83 1 1002abe0c83 1 100bbf70c83 1 10080ca0c97 1 100359f0c97 1 50b1520c83 1 507f1d0c97 1 33.33

Figure 9.6.5-1: Excerpt from esn.t20 from CAT


181

B. The esn.t20 file has the above format for CFCs 3, 4, 5, 6, 7, 9, 13, 27, 61, 62, and255. A poor performing mobile can be found by reading through this file andpaying attention to its CFC distribution. In the following example, Figure 9.6.5-2,note the statistic for ESN=77a00c97. This mobile has approximately 70% of itscalls resulting in an access failure or drop call. The mobile should not be used forcall statistic testing until its performance is investigated. The “Highest percent”sections were left out of this example, due to number of call attempts for eachESN sometimes the mobile may appear in “Highest raw totals” but not in“Highest percent”. If the mobile was used for continuous call testing where thecall is left on traffic for very long periods of time or until dropped, there may bean unusually high percentage of drops (CFC 4).

Highest raw totals for CFC= 477a00c97 11 23.333c000c97 10 29.41269d0c97 9 32.1477420c97 8 42.1151390c97 7 11.297190c81 7 35Highest raw totals for CFC= 573020c82 53 20.2377a00c97 14 25.485ae3e0c81 11 45.8338cb0c81 10 15.62403a0c97 10 6.09844b90c81 9 11.69Highest raw totals for CFC= 969300c83 9 52.9477a00c97 8 21.861e4b0c97 6 256fae0c83 5 20403a0c97 5 14.2973020c83 4 57.14

Figure 9.6.5-2: Excerpt from esn.t20 for “bad mobile”

C. The esn_cfc.dst (ESN CFC distribution) gives a total break down for each mobilein the system. The –e option should be exercised when running the CAT tocreate this file.

D. The call_dur.dst (call duration distribution) breaks the call duration for good calls,dropped calls, setup failures, hard handoff calls, and all calls into eight time bins.It is useful to compare good call duration with drop call duration to see if thedrops are consistently happening in one time frame. Use the –p option whenrunning CAT to create this file. For more information on these reports, please seethe CDL Analysis Tool Users Guide, available for downloading fromhttp://www.cig.mot.com/~wheelrts.

http://www.cig.mot.com/~wheelrts


182

Call Duration Distribution (s is seconds)

Call Duration Distribution for CBSC/MMADDR = e1

All Good Drop Setup HHO Range

1499 1274 38 187 0 0 - 15 s

867 802 33 0 32 15 - 30 s

573 565 8 0 0 30 - 45 s

400 368 7 0 25 45 - 60 s

375 370 5 0 0 60 - 90 s

204 202 2 0 0 90 - 120 s

574 560 12 0 2 120+ s

68.381 71.805 60.581 5.353 41.712 Average Duration

RFloss / Minute = 2.077

FWD_QUALITY ave = 0.0083

RVS_QUALITY ave = 0.0330

Figure 9.6.5-3: Excerpt from call_dur.dst from CAT

2. If a bad mobile is identified, notify and escalate the problem to the lead systemengineer responsible for drive test logistics. A comparison test should be done usingthe suspected bad mobile and a mobile that is known to be void of performanceproblems. If the mobile has call origination or drop statistics more than 7 to 10percent worse than the control mobile, the bad mobile should not be used for drivetesting and investigated. A new software flash or hard reset can sometimes repair themobile performance. After the mobile has been fixed or reset the system engineershould perform an additional comparison test to verify the mobile is performingwithin normal statistical ranges. Mobile problems that have been identified indifferent markets include incorrect message sequences, messaging not beingincremented, and service option negotiation issues. These are only a few examples ofmobile failures.


183

9.6.6 Data Collection/Processing Troubleshooting

There are two main types of data collected during a drive test: mobile files (or DM files)and CBSC files (SMAP, CDLs, Event Logs, etc.). Upon occasion, the collected data setsmay be incomplete or be corrupted. This section identifies the most common causes ofincomplete or corrupted DM or CBSC data, and provides guidelines to troubleshoot andprevent these data collection problems.

9.6.6.1 Mobile Data Problems

9.6.6.1.1 Identifying Mobile Data ProblemsMobile data problems may be suspected if any or all of the following are seen:

1. Data Processing Errors. Figure 9.6.6.1.1-1 below shows an example of the errorwindow in Compas. For the example shown, no error were encountered. However, ifthere is a problem with the data, the processing run usually aborts and indicates thetype of error encountered. If a different post-processing tool is used, check the user’sguide to see if error logs are generated, where they are stored, and the name of thelogs.

2. Corrupt Files. Compas generates a file called <datestamp>.FIL which lists all filesprocessed. If a file is corrupt, the file will be listed as an unknown type of file.

3. File Size Differences. The mobile files are different sizes after transferring themfrom the DM onto the processing computer. For example, a mobile log file is 6,495KB on the DM but only 4,950 KB after being transferred onto the target computer.

4. Number of Files Differences. The number of mobile files transferred from the DMdo not match the number listed on the mobile logs.

5. Missing Data. The data processes, but upon examination of the data, the engineerdiscovers there is missing data from a particular ESN, or entirely missing ESNs. SeeFigure 9.6.6.1.1-2 below for an example of missing data.

6. Data Processing Crashes. The post-processing tool crashes or will not process thedata.


184

Figure 9.6.6.1.1-1: Example of Error Window in Compas

Missing Data

Figure 9.6.6.1.1-2: Example of Missing Data


185

9.6.6.1.2 Preventing Mobile Data ProblemsTypical problems seen in the field with mobile data are grouped into four classes asfollows:

• GPS Problems• DM Problems• File Transfer Problems• Field Operator Error Problems

Each of these is discussed below.

GPS Problems1. The GPS was not connected properly during the test.2. The GPS had no power or was not turned on.3. The GPS used was not compatible with the DM software, or4. The GPS was broken.

The GPS should always be checked before any metric route or test to make sure it ispowered up, receiving the satellite signal, and working properly; see the checklist inAppendix B-1. Chapter 7, Single Cell Functional Test has a basic diagram showing howthe DM and GPS should be connected.

Some GPS manufactures include a script or program with their GPS for the user to checkthat the GPS is receiving the satellite signal. This program usually can also set the baudrate and other parameters for the GPS to operate correctly. Check with the GPSmanufacture/reseller (see Chapter 6) for more information.

DM ProblemsThere are numerous reasons the DM can have problems. As with any computer, theremay be conflicts with different programs loaded which may cause spontaneous crashes orlock-ups. This should be tested as much as possible in the office prior to field datacollection. Since the DM operates in a rugged field environment, it will be subjected tovarying temperature, humidity, vibration and shock conditions over its lifetime. As aresult, problems with connections, hard drives, and displays may occur more frequently,especially with more use. Care should be taken to secure the DM, GPS, and powerequipment, along with the attached power and signal (serial data and RF) cables to reduceimpacts of road testing so that DM “lock-ups” or “crashes” are minimized. Despite theseprecautions, the data files should be saved at regularly scheduled intervals to minimizeany re-drive activities in the case of a computer failure.


186

File Transfer IssuesIf the files are transferred from the DM onto a networked computer, care should be takento transfer the files correctly. For example, when FTP’ing DM files across a network,they should be transferred in binary mode.

Before transferring the DM logs, the hard drive space on the processing computer shouldbe checked to make sure there is enough room to transfer all the DM logs. This may bedone using the UNIX command “df -k” or by looking at the space available on a DOS orWindows machine. See the computer user’s guide for specific instructions.

If there is not enough space to transfer the files, space must be created. This can be doneon a UNIX system, by using the tar, compress and/or gzip commands. On a DOS orWindows based machine, space can be created by compressing or deleting older files ormoving them off the machine onto a backup source such as tape or Zip disks.

Operator ErrorsThe items below are the most common operator errors that should be avoided during thedata collection process.

1. Operator does not save the logs at the recommended intervals.2. The drive space is not checked on the DM and there is not enough room on the hard

drive to save all the mobile logs.3. The logs are not saved properly.4. If there are problems with the DM, such as crashes or lock-ups, they are not noted on

the mobile log sheets.5. The operational status of the GPS was not checked before the test began.6. Any problems with other equipment (i.e. electrical problems, antennas broken, etc.)

were not noted on the mobile log sheets.7. Log sheets were not kept accurately (i.e. different number of mobile files on DM than

on log sheet).

Checklists, such as the one in Appendix B-1 of this document should be generated andused before each test to develop good data collection habits. Mobile log sheets should becompared with the land operator sheets (if applicable). Also log sheets should beinspected at random intervals by overseeing engineers to ensure that the data collectioncrews are keeping accurate records.

9.6.6.2 CBSC Data

The data gathered at the CBSC should be transferred over a network onto a postprocessing machine. Only the SMAP files contribute to the generation of RFperformance plots, specifically, the reverse FER. Other data, such as CDLs, event logsand PM data, will be used for more detailed troubleshooting and to generate statistics thatcan be used to track improvements in system performance. Because the data collected atthe CBSC plays such an important role in system optimization it is critical that this databe error free.


187

SMAP operation requires configuration files which identify the data the tool is to collectwhen it is turned on. SMAP must also be invoked and shut down properly. Take care tofollow the specific SMAP operation procedures user’s guide to collect valuable data.SMAP should also be monitored while it is running to ensure that the file sizes areincreasing while it is running.

The two primary causes of corrupted CDLs, event logs, and/or PM Data are:

- not transferring the files correctly (i.e. Binary mode for FTP), and- not having enough hard drive space for the files on the target machine.

Since these data sets can get very large, it is recommended that one or two persons bedesignated to perform daily management of this data. This task would include thetransfer of the data, checks of the hard drive space where the data will be transferred, andcorrective actions to provide disk space as necessary. Those corrective actions couldinclude deletion of older, unneeded data, or data archiving onto other devices.

9.6.7 Integration of Each Cluster into the Overall Network

A checklist like the following one should be used to ensure each cluster is integrated intothe overall network by implementing Inter CBSC Soft Handoffs (ICSHO). This shouldinclude checks for each level of equipment; CBSC, XC, and EMX.

9.6.7.1 CBSC Level

The implementation will be different depending on if this is a new system with multipleCBSCs, and existing system adding another CBSC or if this is an existing multiple CBSCsystem. The main items in the CBSC to be checked are:

• IC Trunk Groups are created• Neighbor lists (XC Sectors) are correct• Correct or additional equipment is installed (e.g. MSI, KSW, and FEP cards)• IC Spans are equipped• IC Links are installed and equipped• The OMC groups are established and correct• The CBSC ID is correct

9.6.7.2 XC Level

This feature impacts several MMI commands required to establish the XC database.These commands are:

• Target System Number – A source CBSC must have knowledge of a SCAPSystem field in order to be able to route SCAP messages to the target CBSC.

• FEP Address – This field appears as the two left-most digits of the FEP SiteConfiguration Flag required for the XC EQUIP_DEVICE FEP command.

• ICLDL Equipage – A new XC device must be equipped to correspond to eachICLINK equipped.

• Inter-CBSC Traffic Channels – The XC command ADD_ICTCH_BY_SPAN isused to add multiple Inter-CBSC traffic channels to a span line.


188

9.6.7.3 EMX Commands

If the anchor handoff method selected is not KEEP_SOFT, then the following EMXcommands are required to allow the anchor handoff to take place.

• BSS BSSRTE – This database entry on the EMX contains the Destination PointCode for A+ messaging and the BSS Trunk Group for the terrestrial circuits to thetarget BSS.

• BSS CELRTE – This entry on the EMX tells the target EMX where to find thetarget BTS.

More information on each of these can be found in the Cellular Application Note forInter-CBSC Soft Handoff. This can be downloaded from the following web address:http://www.pamd.cig.mot.com/nds/cts/rftech/App_Notes/icsho/icsho.html. There is alsoadditional information regarding this feature.

9.7 Exit Criteria1. Problem Resolution Matrix is current and reflects all work completed to date.2. Neighbor list has been optimized.3. Each individual cluster is integrated into the overall network.4. Final parameter recommendations have been implemented.5. RF performance plots show acceptable performance throughout cluster.

http://www.pamd.cig.mot.com/nds/cts/rftech/App_Notes/icsho/icsho.html


189

Appendix 9A Change Request Forms and Change Orders

Date: ________________

PARAMETER CHANGE REQUEST FORM

Name TitleRequestor

MM/DD/YY NotesDateNeeded:DateChanged:

Describe changes wanted

Are these changes Permanent or Temporary? ________________________________________

Why? _______________________________________________________________________

MIB parameter before change: ______________________ Date checked: _____________

MIB parameter after change: ______________________ Date checked: _____________


190

SYSTEM OPTIMIZATION CHANGE ORDERCluster # DateEngineer on DriveData Files

DriveTeamEquipment

Drive Type

Call Type

Comments

Recommended ChangesCust MOT ChangeCust MOT ChangeCust MOT ChangeCust MOT ChangeCust MOT ChangeCust MOT ChangeCust MOT ChangeCust MOT Change

Changes MadeChange Change Order #Change Change Order #Change Change Order #Change Change Order #Change Change Order #Change Change Order #Change Change Order #

SignaturesRFEngineer

Date

RFManager

Date


191

Customer Name

CHANGE ORDER

Cluster # Drivedate

Comments

ChangesRequestedParameter changed: From: To:ChangeChangeChangeChangeChangeChangeChangeChangeChangeChangeChange

Requested by:Date

Completed by:Date

Optimization Procedures and Guidelines, Ver 1.2Final Coverage Survey & Warranty Verification

192

10.0 Final Coverage Survey & Warranty Verification

10.1 DescriptionThe closing step in network optimization is to conduct a drive test to verify that thenetwork meets contractual warranty clauses. Some customers may want to perform thisfinal drive under load, which can be simulated on the forward link, by employing SMAPto generate OCNS. The relationship of this activity to the overall network optimizationprocess is shown in Figure 10.1-1.





(Chapter 3)


(Chapter 4)




(Chapter 9)







System Designvia


(Chapter5)


(Chapter 7)


(Chapter 8)

Figure 10.1-1: Relationship of Final Coverage Survey and Warranty TestingActivity to Entire Optimization Process

After several iterations of drive testing where all hardware and database problems havebeen eliminated and the system parameters have been modified to provide “optimal”network performance, the final drive will document the performance prior to hand over to


193

the customer. Up to this point, the PRM should have the history of network optimizationchanges documented for each cluster in the network.

10.2 Tools RequiredThe tools listed in Table 10.2-1 can support the final coverage survey and warrantyverification activity.

Item DescriptionDM, with phone andGPS

Used to collect data

SMAP Used to collect reverse link messaging and if needed, simulateloading on the forward link using OCNS. User’s Guide andconfiguration notes can be found at:http://www.cig.mot.com/~thakkar/smap.html

Post Processing tool Used to process the collected data, generate plots.

ASSIST Script Run on *.map files created by COMPAS to verify all contractwarranty performance criteria has been met.http://www.rochellepark.pamd.cig.mot.com/~dhelm/

Event logs Used to verify system stability during final drive exercise

CDLs Used to generate call completion and drop rates

Table 10.2-1: Tools Required for Final Coverage Survey/Warranty Verification


Personnel Skills*System Engineer Green BeltDriver Valid drivers licenseDM Operator Computer literateCBSC Operator Knowledge of OCNS and SMAPCFE (on call) Knowledge of BTS hardware and troubleshooting capabilities*See Appendix A for more information.


10.4 Entrance Criteria1. RF optimization team understands contract warranty requirements.2. Problem Resolution Matrix is current and reflects all work completed to date.3. Neighbor list has been optimized.4. Final parameter recommendations have been implemented.5. RF performance plots show acceptable performance throughout cluster, and

engineering team is confident that warranty performance will be met.6. Data collection, processing, and analysis method(s) plus exit criteria have been

discussed and agreed upon with the customer.


http://www.rochellepark.pamd.cig.mot.com/~dhelm/


194

10.5 ProcedureThe final coverage survey and warranty verification consists of the following steps:

- data collection, data processing and generation of reports- special evaluation(s) for contractual warranty certification- final documentation of network configuration and performance

10.5.1 Data Collection and Processing

The data collection and processing procedures will be the same as previously laid out inChapters 8 and 9. Drive routes should be agreed upon with the customer, and may bemore detailed than previous metric routes. The only difference at this point may theaddition of Orthogonal Channel Noise Source (OCNS) to simulate load on the forwardlink. OCNS allows simulation of a load on the forward link. SMAP BTS sessions can beconfigured to provide this forward link loading. SMAP installation and configurationnotes are available at the following URL: http://www.cig.mot.com/~thakkar/smap.html.If OCNS will be used, be sure that the CBSC operator properly inhibits the MCCchannels that will generate OCNS, then start the BTS sessions in SMAP to generateOCNS. The CBSC operator shall monitor the sessions throughout the day to make surethe sessions are still running and there are no problems. Take necessary precautions toturn off OCNS and return the MCC channels back to proper operation after the datacollection is completed.

10.5.2 Contractual Warranty Certification

The customer and Motorola have defined the exiting performance criteria in the customercontract prior to any network optimization. A copy of the contractual requirements canbe obtained from the account team that is handling that market. There are several waysto determine if the system meets the contract warranty performance criteria. One way iswith the “ASSIST” script. This script is run on the *.map files created by COMPAS. Thisscript can be obtained from http://www.rochellepark.pamd.cig.mot.com/~dhelm/ choosethe link titled “RF Warranty Tools Page”.

ASSIST processes bins from all sets of drive data to determine if the system performancemeets all of the RF warranty criteria. Assist creates three reports; drop call report, FERreport and the O/T (origination/termination) report. Examples of each follow.

DROP CALL REPORT:

This data is based on the file/users/dhelm/TOOLS/drive_test/sprint/testbed/sampling/call_state.map

The data has been compare to the following ’Covered AreaInclusion Mask’:/users/dhelm/TOOLS/drive_test/rf_warranty/testbed/include.map



195

******************************************************The following calculations take into account the CAIM******************************************************

Number of Setups: 20 Number of RfLosses: 1

Drop Call: 5.00%

Channel Element Usage = 1.28Soft Handoff Usage = 22.5%

FER REPORT:

The FER is calculated from this file:/users/dhelm/TOOLS/drive_test/sprint/testbed/cont/results.map


*****************************************************The following calculations take into account the CAIM*****************************************************

Number of Bins with both FFER & RFER: eightNumber of Bins with either RFER or FFER over 2%: 3Percent of Bins with both FFER and RFER under 2%: 62.50%

Number of FFER Bins: 8 Number of FFER Bins over 2%:2

Percent of FFER bins under 2%: 75.00%FFER Average per Bin: 0.84%

FFER Average with the worst 10% removed: 0.84%

Number of RFER Bins: 8 Number of RFER Bins over 2%:1

Percent of RFER bins under 2%: 87.50%RFER Average per Bin: 1.30%

RFER Average with the worst 10% removed: 1.30%

OT REPORT:


196

WARNING: only 26.32% of the origination/termination binsmatch CAIMSee section 5.4 of the Users Guide for troubleshootingnotesYou will need to use the following output file:orig_term.binsThis will be stored in the output directory:/users/dhelm/TOOLS/drive_test/rf_warranty/testbedThis data is based on the file/users/dhelm/TOOLS/drive_test/sprint/testbed/ot/call_state.map


***********************************************************The following calculations take into account the CAIM***********************************************************

Setups: 5 Setup Failures: 3

Call Completion Rate: 40.00%

10.5.3 Final Documentation

Prepare a Final Cluster Binder. The binder should contains a summery report of allparameters captured from the CBSC along with all the parameters change requestsubmitted by the analysts during system optimization. The Problem Resolution FinalReport starts with a listing of each drive test and the date on which the drive test wasperformed. The report contains the different areas identified as having RF performanceproblems and gives a description of the area, observations, and conclusions. Finalrecommendations are provided for each area after completing the final drive. It isrecommended to keep an extra copy of the final binder for future references. Appendix10A contains an example of the Final cluster Binder.

10.6 Analysis ConductedBoth Compas and ASSIST run in Unix. The ASSIST user guide has been attached to thischapter as appendix A. Review the results given by the Assist reports. If the data doesnot meet all contract warranty performance criteria, analysis must be done to determinethe cause. It may be necessary to revisit Chapter nine for detailed problem resolution. Ifwarranty criteria are met review the results with the customer and provide them with thefinal binder. The account team should also keep a copy of the final binder for futurereference.


197

10.7 Exit Criteria:1. Final coverage survey is completed.2. The final reports listed in Section 10.5.2 have been generated.3. Special contract warranty tests have been passed.4. An exit review has been conducted with the customer.


198

APPENDIX 10AThis appendix provides examples of the Final cluster binder.

EXAMPLE:1. Problem Resolution Matrix2: System Performance Report

This section of the report will contain drive statistics for the last drive. This shouldinclude CDL breakdown by CFC, and the drive team statistics that include total callattempts, call completion rate, and drop call rate. If the system is commercial, thissection should have System Performance Graphs that include total call attempts, callcompletion rate, and drop call rate. Also for a system that is already commercial, itshould include a CFC summary at the CBSC level and a CFC Summary at the BTS level.

3: Site Database

This section should contain a print out of the "BTS Information”.Make sure that all of the database files, such as the tilts and SIF powers, have beenupdated.

In order to see all your BTS data on this web page, you need the following databases.~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Power: do a "DISP BTS-### PPSGAIN" on the CBSC for all of your BTSs,then call the file "APOWER.ZCT" (where 'A' is the specific unit and 'Z'is the Customer).

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Tilts: Put a file called "Current_Tilt_List" in the followingdirectory:/netplan/cdma/tilts/ZCT/

the format should be as follows:

*** CDMA ANTENNA TILT LIST ***Fri Sep 4 16:22:07 JST 1998

BTS# SEC# CURRENT REQUEST SCHEDULE REQUESTTILT TILT /COMPLETED BTS_Name unit

------------------------------------------------------------------------1 1 -1 -1 o/ Site 1 B_31 2 3 3 / Site 1 B_31 3 4 4 / Site 1 B_31 4 4 4 / Site 1 B_31 5 2 2 6/17 Site 1 B_31 6 5 5 o/o Site 1 B_3~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Antenna height: An export from NetPlan Administration to obtain an "Antenna.unl" file.


199

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~One will also need to get some of the basic system parameters using the following scripton the OMCR at the CLI command prompt.

#!/bin/kshinput=$1bts=‘allstatus cbsc=$input |grep BTS- |cut -c5-8‘for parm in PPSGAIN MAHO SECGEN TCHGEN SECTOP ROUTENUMdoecho "$parm"for CBSC in $btsdodisplayrc bts-$CBSC location |grep $CBSC |grep -v bts |cut -c1-43displayrc bts-0 $parmfor sector in 1 2 3 4 5 6dodisplayrc carrier-$CBSC-$sector-1 $parm |grep CARRIER-doneechodoneechodoneechodisplayrc CBSC-$input XCSECTechoechoechoecho "Task completed."echo "good-bye !!!" This can also be accomplished through use of the Show All Parms Script located athttp://www/rochellepark.pamd.cig.mot.com/~blashkar/bestpractices.html

4: Parameter Change RequestsThis should include all Parameter Change Request forms and Tilt Request forms.

5: System PlotsThis section should include the followingForward FER initial driveRx initial driveTx initial driveEc/Io initial driveDelta initial drive (Optional)Forward FER final drive

http://www/rochellepark.pamd.cig.mot.com/~blashkar/bestpractices.html

http://www/rochellepark.pamd.cig.mot.com/~blashkar/bestpractices.html


200

Rx final driveTx final driveEc/Io final drive

Optimization Procedures and Guidelines, Ver 1.2System Operations

201

11.0 System Operations

11.1 DescriptionPrior to commercial service, the customer often designates a period of friendly user trialson the system. Friendly users are issued registered phones and asked to give feedback ontheir calling experiences (i.e. do they drop calls at a particular area every day, etc.). Achecklist, such as the one in Appendix 11.A, can be given to the friendly users to helpstreamline their problem reporting process. This user information will help determine ifthere are areas that may need further optimization due to the load on the system. It mayidentify areas that the drive teams did not include on the drive route which haveproblems, or identify other problems not previously found during optimization.

The feedback from the friendly users may indicate it is necessary to add a cell site intothe system. Since this site is being added into a “live” system, extra precautions must betaken so there is no down time of the system. A CDMA cell site addition procedure isgiven in section 11.5.2.

During the friendly user stage and commercial service, system monitoring is required atthe CBSC level for several reasons. These include:

• Monitoring system performance as the number of users increase• Continue to isolate and remove bad hardware from the system• Baseline new product releases and privates/patches as they are installed• Separate effects of specific subscriber unit models as they are added to the system

Specific tools and procedures to monitor the system will be discussed later in thischapter. The relationship of these activities to the overall network optimization process isshown in Figure 11.1-1.


202





(Chapter 3)


(Chapter 4)




(Chapter 9)







System Designvia


(Chapter5)


(Chapter 7)


(Chapter 8)

Figure 11.1-1: Relationship of Friendly Users, Commercial Service andPerformance Monitoring Activities to Entire Optimization Process


203

11.2 Tools Required:

Item Description and Vendor RecommendedQuantity

Vehicle Preferably a van with enough room for alldata gathering equipment plus DMoperators. Should be equipped for drivetesting, including power source androuting for external antennas if necessary.

1 per team

Lap Top Computer Which can be used as a DM containinglarge hard drive (e.g. 2 GB), compatiblewith DM and GPS H/W & S/W, phoneinterface


DM Software Capable of collecting IS-95 messages indifferent modes of operation (e.g.Markov, various rate sets)

1 per Laptop

GPS Position locating receiver compatible withDM software and laptop computer.

1 per DM

CDMA Phone with extrabatteries or power adapter

Phone must have valid ESN and phone #for the current system.

1 Per DM

Analog or other non-testphone

Used for coordinating activities with testleader and contacting MTSO personnel orCFEs as needed, or for emergencypurposes.

1 per vehicle

SMAP Used for collecting messaging andReverse Link FER at the BTS/CBSC.

1 per MM

RF Performance AnalysisPost Processing Tool

COMPAS, OPAS or equivalent that willenable plotting of RF performancecharacteristics

Dependent onnumber ofengineers.

CDL Analysis Tools Used to verify system stability as part ofpost-processing and analysis.

1

PM Reports Network performance statistics that aredisplayed from the CBSC

1 per CBSC

Event Logs Used to verify system stability duringsystem optimization

1 per CBSC

Unix capable terminal on theLAN with the OMC-R

Various (examples: PC with Exceed, X-term, Sun Sparc, etc.)

Dependent onnumber ofengineers.


204

11.3 Personnel Required:

Type Skill Level

DM Operator Good computer background, capable of operating DM andCDMA phone. (See Appendix A.4)

Driver Valid drivers license. Must keep safety and comfort of datacollectors in mind at all times. (See Appendix A.6)

CBSC Engineer Strong in Unix operations and experienced in Motorolainfrastructure equipment. (See Appendix A.8)

Cellular Field Engineer See Appendix A.9

Simulation Engineer Green Belt through Blue Belt as appropriate (See Appendix A.2– A.3)

System Engineer White Belt through Blue Belt as appropriate (See Appendix A.1– A.3)

11.4 Entrance Criteria:1. A system is set up to take friendly user feedback and pass information to the engineer

responsible for coordinating drive team activities.2. Friendly users have been briefed on how to give feedback and are issued a registered

phone.3. Drive teams are available for real-time troubleshooting and/or maintenance window

support.4. CFEs are available as needed.5. There are at least three friendly users per set of antennas to have a statistically valid

sample.

11.5 Procedure:This chapter covers three activities that are happening simultaneously. Each has it’s ownprocedures to follow. Each is discussed below.

11.5.1 Friendly Users Trial Period Procedure

A checklist may be used to insure all logistics are in place for the friendly user trialperiod. Some items to include are:

• Determine users (number and who).• Determine what areas to put friendly users in (e.g. downtown only, an entire county,

etc.).• Obtain phones and program correctly, and distribute to users.• Ensure questionable areas have adequate loading to see if problems arise during user

trials.


205

11.5.2 Cell Site Addition Procedure

11.5.2.1 Design, Installation and Component ATP

• Identify PN assignments for the new cell site. Design Engineer responsible.• Identify Initial Power outputs. This can be accomplished using either predictive

methods like NetPlan/CSSS or by predriving the area. Power output changes mayneed to be made to both the new site and surrounding sites. Design Engineer andSystem Performance responsible.

• Identify Topology. Create neighbor lists for new site(s) and surrounding sites. Seechapter 9 for a discussion on neighbor lists. Design Engineer responsible.

• Build the site into CBSC. Write database scripts. Load database and verify databaseloaded properly by displaying all parameters entered.

• Put all devices into PRECUT state to differentiate this site from sites that are incommercial service. If devices are put into OOS state, operations personnel may tryto bring the site into service prematurely and interfere with commercial service. Inaddition, PRECUT sites are not included in CEM availability calculations.Operations group responsible.

• Physically install the BTS and ancillary equipment. This includes installing andtesting spans, antenna systems and BTS. Cell Techs and Motorola CFEs willtypically be responsible for these tasks.

• Conduct the Single Cell Functional Test. Verify cell site functionality. Verify powerouts, signal strengths, clockwise, counter-clockwise softer handoffs, and checkoriginations/terminations on all sectors and channel elements. Drive teams or CFEsresponsible.

11.5.2.2 Site Integration, Field Optimization (Maintenance window activity)

• Make sure optimization tools are available. SMAP, DM with GPS navigation, postprocessing tools (COMPAS, OPAS, etc.).

• Create drive routes for new site and the surrounding sites that may be impacted by thenew site.

• Conduct initial coverage survey along drive route (see chapter 8 of this document).• Conduct metric drive along drive route (access completions, dropped calls).• Process and analyze data to determine problem areas. Collect forward link data

(Ec/Io, FFER, and Mobile receive power). Turn on SMAP to collect reverse link data(RFER, Mobile transmit power at BTS) if desired. SMAP should not be turned on ina heavily loaded system. Use in lightly loaded maintenance window.

• Troubleshoot problem areas. Look for breakage in performance in the coverage areaof the new site as well as the surrounding areas due to pilot pollution. If three activepilots or less, make sure pilots are in neighbor list. If four or more pilots in active setat any one time, try to adjust pilot powers or downtilt antennas to control interference.If mobile transmit power is near maximum examine terrain for shadowing and reverselink path limitations that cannot be overcome. See chapter 9 for completetroubleshooting and analysis procedures.

• Make database changes as necessary.


206

11.5.3 System Monitoring Procedure

Detailed information can be found in the System Performance Monitoring Document.The basic procedure for performing system monitoring will be as follows:• View the Worst 15 Cells report from pmsum for a list of worst performers.• Check RF losses and accesses failures for the worst performers.• Check the cem report for any outages and alarms for hardware failures. Check the

worst performing cells for BBX Reverse Noise Rise Alarms.• Check the output of pmtraf for traffic blocking.• Check the output of pmmcc for channel element failures for the worst performing

sectors.• If the PMSUM reports are displayed on a web server, check the trending graphs for

any degredations in performance (unusual rises in RF losses, access failures, CPUutilization).

• If the PMSUM reports are displayed on a web server, check the HTML list of Worst15 Cells and click on an individual sector to get trending graphs on a per sector basis.

11.6 Analysis Conducted:Analysis of problem areas will be treated the same way as outlined in Chapter 9 of thisdocument.

After the addition of a cell site into a live system, the preliminary analysis should be thesame as shown in Chapter 7 “Single Cell Functional Test” of this document. Theanalysis thereafter would follow the normal guidelines set out in chapter 9 of thisdocument.

Analysis procedures for the system monitoring done at the CBSC level can be found inthe “Guide to CDMA System Monitoring” document found athttp://www.rochellepark.pamd.cig.mot.com/~blashkar/bestpractices.html, chose theOperations button.

11.7 Exit Criteria:1. The system is functioning at a high level (e.g. 99% call completion rate, 2% drop rate,

no major problem areas, etc.).2. The PRM has no open issues that can be resolved. (There may be open issues that

cannot be resolved. These should be documented, the reports given to the customerand the information entered into the PRM.)

3. The system is ready for commercial use.



207

Appendix 11.A Friendly Users Checklist1. Be aware of the CDMA service boundaries. Digital to analog hand-downs are not

drops and should not be categorized as a trouble incident.

2. Tell the customer of any known problem areas and what they may experience. Also,suggest that they don’t send trouble tickets for known problem areas since you havealready identified it.

3. Ensure the call is a digital call, not an analog call. If there is cross talk, static, or noisethat sounds like the paging channel, the call is on analog. Look for the digital D onthe phone display prior to the end of the call. If the call was on analog, the D still mayappear immediately after the call has terminated.

4. Changes in volume are usually associated with the speaker of the Qualcomm phone.It has only one hole in the ear piece. The alignment of the ear piece and the ear is verycritical. A subtle change in this alignment will result in a decrease in volume to theuser.

5. Make some mobile to mobile calls and calls to analog mobiles. The majority of callsshould be land to mobile and mobile to land calls. On mobile to mobile calls, if thereis a problem, there may be a question of which leg is faulty.

6. Avoid the use of a speakerphone on the land side and the mobile side. Reportedmutes, echoes and clips can be caused by the speakerphone.

7. Set all the phones to alarm on a drop or a fail to originate, then they will definitelyknow if they accidentally hung-up vs. a drop/fail. (Fails/Drops will sound an alarm -hang-ups will be silent.)

8. On access failures check that the correct number of digits were dialed.

9. Report audio problems accurately. The audio problems associated with digitalsystems consist of warbling and muting. Static, continuous noise, crosstalk are analogrelated impairments. The audio problems generally associated with digital handsetsare echo, noise bursts (screeches), and one way audio.

10. Create a list of the mobile user names and their mobile numbers to help track userperformance.

11. Accurately record the time of the call so we can trace it to a Call Detail Log record.Time tags at the instant the drop or problem occurred are important so we can reviewthe CDL’s and alarm/event messages for information that may lead us to the source ofthe problem, especially if it is hardware related.

12. Complete all the data fields on the Trouble Ticket forms.


208

13. If a problem occurs, especially drops and access failures please try to reproduce theproblem. In addition, if a dropped call occurs, the subscriber should attempt anorigination at the spot they dropped. That would provide us information about theavailability of a strong pilot in the area where they dropped. Please report if anorigination was successfully or unsuccessfully completed after a drop.

14. Be cognizant of the location of your competitor’s cell sites and your cell sites that areanalog only. The digital phone (this also applies to analog phones) can get overloadedby strong out of band signals and affect your service.

15. Document the software release of each handset. There should not be any old softwareversions because of associated problems.


209

This page intentionally left blank.

Optimization Procedures and Guidelines, Ver 1.2APPENDIX A Roles and Responsibilities

210

APPENDIX A Roles and Responsibilities

Several functions have been identified to support the processes that lead to systemcommercialization. Though there are many roles mentioned, it is possible that more thanone role could be performed by an engineer. The role and a brief description ofresponsibility of each responsibility are as follows:

A.1 White Belt (System Engineer –Entry Level)

A.1.1 Pre-Requisites

• General Knowledge of Cellular Technology and Deployment ProcessTechnical Degree

• Basic Computer Skills (Unix, MS office, etc.)• Programming Skills a Plus (i.e. Perl, C)

A.1.2 Recommended Training (Motorola training courses)

• NES109: Propagation Fundamentals, LMPS – 3 days• SYS300: CDMA System Optimization- 5days• GNL070: SC Product Family Overview – 2 days• GNL 170: Digital Technology Overview - 1day• GNL 180: CDMA IS-95 Implementation and Operations – 2 days• GNL 190: CDMA Call Processing – 2 days• PER350: NetPlan + CDMA 1 – 4 days• PER310 : COMPAS – 1 day• ENG722 – UNIX Fundamentals – 3 days• Introduction to Perl• Self Study – NSS Optimization Process• Self Study – Best Practices Documentation available on the Web

A.1.3 OJT/Experience

Participate in small scale RF Optimization activity with Level 3 engineer. Activities mayinclude:• Drive test and Analyze data• File Transfers• Directory Structures• Parameter Modifications/Database awareness• BTS integration awareness• Identify RF Problems• Generate/review Neighbor Lists• Interpret Performance Management Reports• Drop Call, FTO, FTT analysis


211

• Utilize NetPlan-COMPAS• Generate Drive Test Plots• Utilize available scripts/tools• Awareness of contract requirements• 0 - 6 months experience

A.1.5 Competencies

Understands RF propagation characteristics, Familiar with digital technologies (TDMA,GSA,CDMA), understands RF optimization process, familiar with RF optimization toolsavailable, familiar with CDMA SC product family and all network elements, understandspath loss models, link budgets, antenna characteristics, interference sources, frequencyplanning and able to utilize basic Unix commands, able to follow basic script logic inUnix, Perl or “C”

A.2 Green Belt (System Engineer)


• White Belt RF Optimization Achievement• Knowledgeable of overall RF Optimization process• Knowledge of RF optimization tools and RF analysis techniques• Able to utilize and troubleshoot tools without mentoring

A.2.2 Recommended Training

The above courses plus one or more of the following courses:• SMR120: Motorola’s Implementation of IS-95 – 1 day• GNL210: CDMA Network Optimization – 2 days• GNL220: CDMA Field Performance Optimization – 1 day• GNL230: CDMA Network Optimization – 2 day• (SYS300): CDMA system Optimization – 5 days• SYS610: (MU)Risk Analysis of Network Arch.• SYS800: (MU) Network Reliability Objectives• SAO010: SC Product Family, System Administration & Operation – 10 days• SAO200: CBSC Operations Lab – 2 days• Advanced Scenario Workshop - Internal NDS group• CBSC Database – Internal NDS group• Need Course #:Advanced UNIX• Need Course #:Advanced Perl• CTD131: Time management – 1 day• Self-Study – Development documentation on new features/parameterization/system

impacts• Self Study – CFC resolution document• Self-Study – IS-95 specifications


212


Participate in medium to large scale RF Optimization activity. Champion one or more ofthe following activities with Blue Belt engineer Supervision:• NetPlan Simulation (review)• Contract requirements review• Identify optimization exit criteria• Evaluate availability of input criteria• RF Optimization Project Planning• BTS integration• Plan metric drive routes• Lead drive test team• Database and neighbor list review/modification• Monitor system performance and benchmarking, utilizing CDLs, PMSUM, and CAT

output.• System Analysis of Call Processing using COMPAS and/or SMAP• Utilize available optimization scripts/tools• Identify RF Problem Areas• Troubleshoot problems related to feature implementation• Help train account team personnel on RF optimization tools/processes• Participate in FOA or development integration/testing of new features or special

applications (microcell, etc)• 6 - 12 months experience

A.2.4 Competencies

Knowledgeable of all White Belt competencies, able to plan RF optimization events, ableto follow script logic in Unix, Perl or “C” and modify per application if necessary.Understanding of Motorola’s implementation of IS-95, able to deploy/optimize newfeatures, understands CBSC database and able to review/modify as necessary, able totroubleshoot RF or feature related problems, able to monitor system and evaluateperformance, able to identify new tools which may be used to further aid the RFoptimization process. Train account team on RF optimization methodology. Have goodwritten, verbal and time management skills.


213

A.3 Blue Belt (System Engineer)


• Green Belt RF Optimization Achievement• Expert in RF optimization• Knowledgeable in Motorola Product Line and RF optimization tools• Experienced in troubleshooting• Willingness to adapt new troubleshooting techniques


• SAO100• Adv. Perl• CTD131: Time Management• SYS840: (MU) TMN Architecture & Standards• SYS850: (MU) Network Rel. Measurement & Control• MGT842: (MU) Project planning, analysis and control


• Champion small to large scale RF optimization project.• Build and manage team of RF optimization engineers throughout system optimization• Provide mentoring and training opportunities to Level I and Level II engineers to

continuously upgrade their skills• Lead in training account team personnel on RF Optimization tools/processes• Serve as Customer/Internal management contact• Prioritize events to meet contractual requirements and exit criteria• Anticipate problems and plan accordingly to prevent them• Know when to escalate problems• Serve as RF optimization technical focal point• Analysis and evaluation of new feature integration• 2 - 3 years experience

A.3.4 Competencies

• All of the above Level II competencies• Capable of championing any of the RF optimization activities required• Able to effectively communicate with NDS project management , product

management, and development/FOA organizations• Very good written, verbal, time management and negotiation skills• Very good troubleshooting skills• Able to build a team• Good conflict management skills• Able to write senior management/customer reports


214

A.3 Black Belt (System Engineer)


Blue Belt RF Optimization Achievement• Management Training


• MGT843 : Project Management, Leadership, and Communication Time Management• MGT908: Adaptive Management- 2 days


• Build and manage team of RF optimization engineers throughout system optimization• Prioritize events to meet contractual requirements and exit criteria• Anticipate problems and plan accordingly to prevent them• Know when to escalate problems• Serve as RF optimization technical focal point• Analysis and evaluation of new feature integration

A.3.4 Competencies

• All of the above Blue Belt competencies• Capable of championing any of the RF optimization activities required• Able to effectively communicate with NDS project management , product

management, and development/FOA organizations• Very good written, verbal, time management and negotiation skills• Very good troubleshooting skills• Able to build a team• Good conflict management skills• Able to write senior management/customer reports

A.4 Diagnostic Monitor (DM) Operator

A.4.1 Role of the DM Operator

The objective of the DM operator is to collect the required data to benchmark the system.This is accomplished by driving specific routes with a Mobile DM in Markov mode andby making M-L and L-M calls. The DM operator can be a technician or an entry levelengineer.

A.4.2 Responsibilities of the DM Operator

• Operate the DM• Log test calls (location, quality, etc.)• Mark maps with dropped calls and poor performance areas• Ensure call operation• This person will be required to learn how to operate the DM.


215

A.5 Landline Operator

A.5.1 Role of the Landline Operator

The main role for the Landline Operator is to participate in any calls. This position mayalso make copies of completed tests and coordinate the upkeep of the Cluster Books.

A.5.2 Responsibilities of the Landline Operator

• Participate in L - M and M - L calls• Rate quality of calls• Mark maps with locations of drops, poor audio quality, anomalies, etc.

A.6 Driver

A.6.1 Role of the Driver

The role of the driver is to safely drive a predetermined route based on general maps forthe area and to assist the DM Operator or RF Optimizing Engineer. The driver could be asummer intern, contractor, technician or entry level engineer.

A.6.2 Responsibilities of the Driver

• Review the drive routes prior to the drive to become familiar with the route• Assist with coordinating logistics• Assist in providing feedback on locations of dropped calls or poor coverage• Drive the test routes safely• Flexibility to adapt to changing schedules

A.7 Bridge Operator

The role of the Bridge Operator is to be the point of contact between Motorola personneland any temporary workers. For smaller systems, with a few temporary workers thisfunction is not required.

A.8 CBSC/Switch Engineer

A.8.1 Role of the CBSC/Switch Engineer

The primary objective of this engineer is to ensure CBSC performance.

A.8.2 Responsibilities of the CBSC/Switch Engineer

• Pull stats and call detail logs (CDLs) and produce a daily report including:


216

Usage Minutes

RF Loss/Usage Minutes

Origination Access Attempts and Failure Percentages

Termination Access Attempts and Failure Percentages

D/A HHO Attempts and Failure Percentages

Soft HO Attempts and Failure Percentages

Source and Target Soft HO Attempts and Failure Percentages

Blocking percentage broken down by cell, sector and system

• Maintenance of call statistics scripts.• System Maintenance parameter display and optimization (changes)• Evaluate how any modifications made by the DM team affect the system.• Maintain a log book of changes made and why. This will serve as a record of all of

the parameters that have been changed if a new software load is loaded with genericvalues.

• General Maintenance of the CBSC, AP, OMC, and SMAP• Software and hardware upgrades of the above listed platforms.• Assist the various team members in troubleshooting issues to be resolved.

A.9 CFEThis team will be needed on a periodic basis for performing the Noise Floor Test,verifying calibration data, ensuring hardware/antenna integrity, and any other BTSverification required by the other teams. Two different levels of field support can beenvisioned. The first level of support can be viewed as a BTS Technician whose mainresponsibility is to reseat boards and perform minor field work. The second level ofsupport capable of calibrating the cell sites (ATP) and being able to perform moresophisticated testing.

A.10 Database EngineerThe role of the Database Engineer is to generate the initial MIB and CLI files to beloaded into the Mobility Managers and Transcoders. This engineer is responsible forrecreating these files, if required, when a new CBSC release is sent to the field. Thisengineer is to support the optimization team if issues relating to commands andparameters arise.

A.11 Development SupportThe role of Development Support is as the name implies. Since CDMA is still a fairlynew technology, many things are still being learned throughout all aspects of deploying aCDMA system. Therefore, development support will be required for all areas from timeto time. Such areas may include, but are not limited to: simulation questions, softwareissues, hardware issues, BTS, Mobility Manager, transcoder, OMC-R, and data collectiontools.

Optimization Procedures and Guidelines, Ver 1.2Appendix B Hardware/Software

217

Appendix B Hardware/Software

This appendix lists additional Hardware & Software equipment, which is requiredfor data collection.

• PCMIA card for PC to mobile connection.• ELPAC power supply or drive van’s 12V terminals, (a mobile cable with a 5-pin DIN

is needed for the ELPAC or power inverter.• Externally mountable antenna(800 MHz or 1.9 GHz) with mini-UHF male connector• Assorted cable. If GPS is desired, the following are also required:• 1 Serial port for GPS connection

A PS/2 mouse or internal pointing device must be used.PCMICA serial I/O card and adapter cable for system with PCMCIA slots.GPS

• 9 pin null modem cable (supplied with GPS)

Optimization Procedures and Guidelines, Ver 1.2Appendix B Hardware/Software

218

Appendix B-1: Check list for Metric Operators

Pre-Departure: CHECK

Inside Facility: CHECK

Test Phone Sign InExtra Batteries & ChargerDMDM cables Put phones on chargers & plug inClipboards Compose tally & summary sheetsLog Sheets & extras Create file folder for data sheetsPencils (min. 2) Information to appropriate PeopleRoute sheets & maps Store equipmentAnalog Phone File informationphone list Clean up any extraneous paperworkGas Card/ Money (Driver) Transfer dataGPS unit & AntennaSign out on board showing all equipment,etc.

Equipment Check:Make test callLog onto DM check mode check GPS check hard drive spaceCheck gas level in van, (Driver)Check air pressure in tire, (Driver)

Returning to Facility *EQUIPMENTVerify directory structure & set up ifneededRemove DM’s, cable & phones from vanRemove log sheets and equipment fromvans *MAINTENANCEClean out all trash from vansFill vans with gas.

Optimization Procedures and Guidelines, Ver 1.2Glossary

219

GlossaryACH - Access ChannelA/D – Analog to DigitalAP - Application ProcessorBandwidth – A relative range of frequencies that can carry a signal without distortion ona transmission mediumBBX – Broadband Transceiver or Baseband TransceiverBDC – Broadband Distribution and Combiner CardBHCA – Busy Hour Call AttemptsBase Station – A radio transceiver that is located near the center of each cell in a cellulartelephone network and which communicates with all of the active cellular telephones inthe call and provides them with a connection to the switched telephone network.BSC – Base Site ControllerBSS – Base Station SystemBTS – Base Transceiver (Sub)SystemCAMPS - CDMA Advanced Mobile Phone SimulatorCBSC - Centralized Base Station ControllerCCP – CDMA Channel ProcessorCDF – Configuration Data File or Cell-Site Data FileCDL - Call Detail LogCDMA - Code Division Multiple AccessCE - Channel ElementCEP – Channel Element ProcessorCFC - Call Final ClassCFE - Cellular Field EngineerCLI - Command Line InterfaceCLMF – CDMA LMFCM – Configuration ManagementCP - Call ProcessingCP – Call Processing ProcessorCSM – Clock Synchronization Module or ManagerCSSS – CDMA Static System SimulatorD/A - Digital to AnalogDAHO - Database Assisted HandoffdB – DecibelDelay Spread – The time lag due to multipathDM - Diagnostic MonitorDRAM – Digital Random Access MemoryDSU – Digital Service UnitEb/No - Energy per Bit/NoiseELPA - Expandable LPAEMI – Electromagnetic InterferenceEMX - Electronic Mobile ExchangeERP – Effective Radiated PowerESN – Electronic Serial Number


220

FDMA – Frequency Division Multiple AccessFEP - Front End ProcessorFER - Frame Error Rate or Frame Erasure RateFM – Fault ManagementFRU – Field Replaceable UnitFTP - File Transfer ProtocolGCLK – Generic ClockGLI - Group Line InterfaceGPROC – Generic ProcessorGPS - Global Positioning SystemGSM – Global Standard for MobileGUI – Graphical User InterfaceHATA – Propagation Loss Model based on empirical data gathered from cities in JapanHHO - Hard HandoffHLR – Home Location RegisterIM - IntermodulationINS - In ServiceIo – Inter-cell InterferenceISDN – Integrated Services Digital NetworkISI - Inter System InterferenceIS-41 – US Mobile ArchitectureIS-95 – US CDMA StandardIS-136 – US TDMA StandardIt – Total Cell InterferenceJTC – US Joint Technical CommitteeKSW - Kiloport Switch cardLAN – Local Area NetworkLAPD - Link Access Protocol, D channelLFR – Low Frequency Receiver or ReferenceLMF - Local Maintenance FacilityLPA - Linear Power AmplifierMAHO - Mobile Assisted HandoffMCAP – Motorola Cellular Advanced ProcessorMCC - Multi-Channel CDMA or Carrier CardMCCCE - MCC Channel ElementMGLI - Master Group Line InterfaceMHz – Megahertz (106 Hz)MIB - Management Information DatabaseMIN - Mobile Identification NumberMM – Mobility ManagerMMI - Man Machine InterfaceMS - Mobile StationMSA – Mobile Service AreaMSC - Mobile Switching CenterMSI - Multiple Serial or Spanline Interface CardMSN – Mobile Station Number


221

MTBF - Mean Time Between FailuresMTSO - Mobile Telephone Switching OfficeNID – Network IDO&M - Operations and MaintenanceOCNS - Other Channel Noise SourceOMC - Operations and Maintenance CenterOMC-R – Operations and Maintenance Center – RadioOMC-S – Operations and Maintenance Center - SwitchOOS - Out Of ServiceOOS_AUTO - Out of Service, AutomaticOOS_MAN - Out of Service, ManualOUNS – Other User Noise SourcePA - Power AmplifierPAD - Power Attenuator DevicePCH - Paging ChannelPDC – Japanese Personal Digital CellularPHS – Personal Handyphone SystemPM - Performance ManagementPN Code - Psuedonoise CodePN Sequence - Psuedonoise SequencePRM – Problem Resolution MatrixPSTN - Public Switched Telephone or Telecommunications NetworkQCELP – Qualcomm Code Excited Linear PredictiveRF - Radio FrequencyRFDS - Radio Frequency Diagnostic SubsystemRFMF – RF Modem FrameRGLI - RFDS Group Line InterfaceRSSI - Received Signal Strength IndicationRX - Receive or ReceiverSALT – System-Wide Audio Loopback TestSCAP - SC Application ProtocolSCH - Sync ChannelSector – An RF coverage area segmentSHO - Soft HandoffSID – System IDSIF - Site Interface FrameSMAP - System Monitoring Application ProcessorSP – Service ProcessorSQL - Structured Query LanguageSS7 - Signaling System #7STRAU - SC Transcoder Rate Adaptation UnitTACS – Total Access Communications SystemsTCH - Traffic ChannelTDMA – Time Division Multiple AccessTERCKT - Terrestrial CircuitTX - Transmit or Transmitter


222

VAF – Voice Activity FactorVLR – Visitor Location RegisterVocoder - Voice encoder/decoderWLL – Wireless Local LoopXASECT - External Analog SectorXC - Transcoder Subsystem or the frame or shelfXCLINK - Transcoder LinkXCDR - Transcoder cardXCSECT - External CDMA SectorXCVR- Transceiver card