CDMA 1.9 GHz Optimization Procedures

CDMA RF Optimization Proceduresfor 1.9 GHz PCS Systems

Version 1.53

November 6, 1996

Prepared byV. DaSilva, M. Feuerstein, J. McElroy, S. Shio, X. Wang

CDMA RF Optimization and Applications GroupLucent Technologies, Bell Laboratories

Whippany, New Jersey

Lucent Technologies ProprietaryUse Pursuant to Company Instructions

ABSTRACT

The RF optimization procedure defines field tests intended to tune all as-pects of CDMA air-interface network performance. As proposed, the opti-mization procedure is to be conducted in two phases: cluster testing and complete system-wide optimization. In other words, the initial pass of the RF optimization will be performed as a part of the cluster tests; the second, more detailed tuning phase, will occur after completion of all cluster tests, once all cell sites in the CDMA network are activated. The primary reason for breaking the optimization work into two phases is to reduce the time and resources required to complete the cluster test cycles.

The most significant objectives of the optimization testing are the following: first, to ensure that acceptable coverage is achieved for the pilot, paging, synchronization, access, and traffic channels; second, to minimize the num-ber of dropped calls, missed pages, and failed access attempts; third, to control the overall percentages of 1, 2, and 3-way soft/softer handoff; and fourth, to provide reliable hard handoffs for CDMA f1-to-f2.

During the RF optimization process, CDMA parameters will be adjusted us-ing simulated traffic loading, due to the extreme cost and logistical obsta-cles associated with employing live traffic. In all cases, forward link loading will be implemented using Orthogonal Channel Noise Simulator (OCNS). Reverse link loading will be achieved through the use of an attenuator and circulator at the mobile.

The CDMA RF optimization procedure defined here covers 1.9 GHz PCS sys-tems; due to the differing hardware configurations and deployment scenar-ios, a separate document addresses methods appropriate for 800 MHz cel-lular systems. Because of the predominance of 13 kbps systems being de-ployed, the document is primarily intended for use with 13 kbps (Rate Set 2) voice coder systems; however, only minor changes to the procedures are required to accommodate 8 kbps (Rate Set 1) voice coder systems.

CONTENTS

1. INTRODUCTION................................................................................................................................................

2. RESOURCE REQUIREMENTS.......................................................................................................................

2.1 STAFF.................................................................................................................................................................2.2 TEST EQUIPMENT................................................................................................................................................2.3 CELL CLUSTER....................................................................................................................................................2.4 DATA ANALYSIS.................................................................................................................................................

3. CDMA SYSTEM PARAMETERS....................................................................................................................

3.1 FIRST PASS OPTIMIZATION PARAMETERS............................................................................................................3.2 SECOND PASS OPTIMIZATION PARAMETERS.........................................................................................................3.3 FIXED PARAMETERS............................................................................................................................................

4. INITIAL CLUSTER CONFIGURATION........................................................................................................

5. SELECTION OF DRIVE ROUTES..................................................................................................................

6. SIMULATION OF TRAFFIC LOADING........................................................................................................

6.1 FORWARD LINK LOADING...................................................................................................................................6.2 REVERSE LINK LOADING.....................................................................................................................................

7. NOMINAL PARAMETER SETTINGS............................................................................................................

8. OPTIONAL PRELIMINARY TESTS...............................................................................................................

8.1 IN-VEHICLE PENETRATION LOSS MEASUREMENT.................................................................................................8.1.1 Test Equipment...........................................................................................................................................8.1.2 Test Conditions...........................................................................................................................................8.1.3 Test Procedures..........................................................................................................................................8.1.4 Data Analysis.............................................................................................................................................

9. CDMA PERFORMANCE TESTS.....................................................................................................................

9.1 SPECTRAL MONITORING TEST.............................................................................................................................9.1.1 Entrance Criteria........................................................................................................................................9.1.2 Test Conditions...........................................................................................................................................

9.1.2.1 Reverse Link Measurements.................................................................................................................................9.1.2.2 Forward Link Measurements................................................................................................................................

9.1.3 Test Procedures..........................................................................................................................................9.1.3.1 Reverse Link Measurements.................................................................................................................................9.1.3.2 Forward Link Measurements................................................................................................................................

9.1.4 Data Analysis.............................................................................................................................................9.1.5 Exit Criteria...............................................................................................................................................

9.2 UNLOADED COVERAGE TEST...............................................................................................................................9.2.1 Entrance Criteria........................................................................................................................................9.2.2 Test Conditions...........................................................................................................................................9.2.3 Test Procedures..........................................................................................................................................9.2.4 Data Analysis.............................................................................................................................................9.2.5 Exit Criteria...............................................................................................................................................

9.3 LOADED COVERAGE TEST...................................................................................................................................9.3.1 Entrance Criteria........................................................................................................................................9.3.2 Test Conditions...........................................................................................................................................9.3.3 Test Procedures..........................................................................................................................................9.3.4 Data Analysis.............................................................................................................................................9.3.5 Exit Criteria...............................................................................................................................................

9.4 SYSTEM-WIDE OPTIMIZATION TEST......................................................................................................................9.4.1 Entrance Criteria........................................................................................................................................9.4.2 Test Conditions...........................................................................................................................................9.4.3 Test Procedures..........................................................................................................................................9.4.4 Data Analysis.............................................................................................................................................9.4.5 Exit Criteria...............................................................................................................................................

9.5 DROPPED CALL TEST..........................................................................................................................................9.5.1 Entrance Criteria........................................................................................................................................9.5.2 Test Conditions...........................................................................................................................................9.5.3 Test Procedures..........................................................................................................................................9.5.4 Data Analysis.............................................................................................................................................9.5.5 Exit Criteria...............................................................................................................................................

10. SPECIALIZED CDMA OPTIMIZATION TECHNIQUES...........................................................................

10.1 NO SERVICE......................................................................................................................................................10.1.1 Inadequate Pilot Signal Strength from Serving Sector...............................................................................10.1.2 Reverse Overload Control False Alarm.....................................................................................................10.1.3 Paging or Access Channel Message Failure.............................................................................................

10.2 HANDOFF FAILURE............................................................................................................................................10.2.1 Excessive Number of Strong Pilot Signals.................................................................................................10.2.2 Unrecognized Neighbor Sector.................................................................................................................

10.3 POOR VOICE QUALITY FORWARD LINK.............................................................................................................10.3.1 Inadequate Traffic Channel Signal Strength..............................................................................................10.3.2 Intermodulation Interference....................................................................................................................

10.4 POOR VOICE QUALITY REVERSE LINK...............................................................................................................

11. SPECIALIZED CDMA OPTIMIZATION TOOLS.......................................................................................

11.1 ALERT PROGRAM............................................................................................................................................11.1.1 Data collection procedures.......................................................................................................................11.1.2 Running ALERT........................................................................................................................................

11.2 LABEL PROGRAM............................................................................................................................................11.3 BUILD PROGRAM.............................................................................................................................................

11.3.1 Building Neighbor Lists............................................................................................................................11.3.2 Optimizing window sizes...........................................................................................................................

11.4 ORIG/TERM PROGRAMS FOR TROUBLESHOOTING ORIGINATION/TERMINATION FAILURES.................................11.4.1 Sample Orig Output..................................................................................................................................11.4.2 Causes for Origination and Termination Failures.....................................................................................

12. ANTENNA DOWNTILT PROCEDURES......................................................................................................

12.1 ENTRANCE CRITERIA.........................................................................................................................................12.2 IDENTIFICATION OF CANDIDATE SECTORS..........................................................................................................12.3 CALCULATION OF DOWNTILT ANGLE................................................................................................................12.4 EXIT CRITERIA..................................................................................................................................................

13. RISKS AND CONTINGENCIES.....................................................................................................................

14. SCHEDULE.....................................................................................................................................................

15. ACKNOWLEDGMENTS................................................................................................................................

16. REFERENCES.................................................................................................................................................

Lucent Technologies Proprietary ivUse Pursuant to Company Instructions

CDMA RF Optimization Procedures for 1.9 GHz PCS Systems

1. IntroductionThe RF optimization procedure defines field tests intended to tune all as-pects of CDMA air-interface network performance. As proposed, the opti-mization procedure is to be conducted in two phases: cluster testing and complete system-wide optimization. In other words, the initial pass of the RF optimization will be performed as a part of the cluster tests; the second, more detailed tuning phase, will occur after completion of all cluster tests, once all cell sites in the CDMA network are activated. The primary reason for breaking the optimization work into two phases is to reduce the time and resources required to complete the cluster test cycles.

The most significant objectives of the optimization testing are the following: first, to ensure that acceptable coverage is achieved for the pilot, paging, synchronization, access, and traffic channels; second, to minimize the num-ber of dropped calls, missed pages, and failed access attempts; third, to control the overall percentages of 1, 2, and 3-way soft/softer handoff; and fourth, to provide reliable hard handoffs for CDMA-to-AMPS or CDMA f1-to-f2.

During the RF optimization process, CDMA parameters will be adjusted us-ing simulated traffic loading, due to the extreme cost and logistical obsta-cles associated with employing live traffic. In all cases, forward link loading will be implemented using Orthogonal Channel Noise Simulator (OCNS). Reverse link loading will be achieved through the use of an attenuator and circulator at the mobile.

The CDMA RF optimization procedure defined here covers 1.9 GHz PCS sys-tems; due to the differing hardware configurations and deployment scenar-ios, a separate document addresses methods appropriate for 800 MHz cel-lular systems. Because of the predominance of 13 kbps systems being de-ployed, the document is primarily intended for use with 13 kbps (Rate Set 2) voice coder systems; however, only minor changes to the procedures are required to accommodate 8 kbps (Rate Set 1) voice coder systems.

Cluster testing consists of a series of procedures to be performed on geo-graphical groupings of approximately 19 cells each; roughly, the clusters are selected to provide a center cell with two rings of surrounding cells. The number of cells in each cluster is relatively large to provide enough for-ward link interference to generate realistic handoff boundaries in the vicin-ity of the center cell and the first ring of cells a cluster of fewer cells would provide acceptable results over too small of a geographic area. Ap-proximately one tier of cell overlap is provided between each cluster and the next to afford continuity across the boundaries. The goal is to complete all tests for a given cell cluster, while minimizing the utilization of test equipment, personnel, and time. For this reason, cluster testing is intended

Lucent Technologies Proprietary 0Use Pursuant to Company Instructions


to coarsely tune basic CDMA parameters and to identify, categorize, and catalog coverage problems areas. No attempt will be made to resolve com-plex time-intensive performance problems during the cluster test phase; such location-specific, detailed refinements will be deferred until the sys-tem-wide optimization phase.

The first preliminary step in the cluster testing involves monitoring uplink and downlink interference in the CDMA band to verify that the spectrum is clear enough for CDMA operation. For the CDMA system to properly func-tion, spectrum must be cleared in a sufficient guard band and guard zone. If strong in-band interference is present, even intermittently, then radio performance can be significantly degraded for the CDMA system. In ex-treme cases, it can be a time consuming, difficult task to identify and miti-gate the sources of external interference (e.g. microwave data transmis-sions, externally generated intermodulation products, wideband noise from arc welders and other machinery, etc.); therefore, it is important to begin spectrum monitoring as early as possible. These spectral monitoring tests also provide a baseline dataset of measured background interference levels that can be used to optimize reverse overload control thresholds and jam-mer detection algorithms for specific environmental conditions.

The next stage of the cluster testing prior to optimization is to exercise ba-sic call processing functions, including origination, termination, and hand-off, to assure that these rudimentary telephony capabilities are operational. Quick measurements are then made of CDMA signal levels to verify that each cell site is transmitting the appropriate power levels. These basic functional tests are intended to detect hardware, software, configuration, and translation errors for each cell site in the cluster prior to drive testing. This sector testing phase will involve driving in the coverage area of each sector to assure that installation has been completed correctly. At this stage, it is common to detect bad coaxial cables/connectors, misoriented an-tennas, and other similar defects.

After basic cell operation has been verified, surveys of forward link pilot channel coverage are performed with light traffic load on the system. Dur-ing the unloaded survey measurements, all cells in the cluster are simulta-neously transmitting forward link overhead channels (i.e. pilot, sync, and paging), with only a single Markov call active. The drive routes used in the measurements are to be jointly selected by Lucent and the wireless service provider. In general, the drive routes will include major freeways and road-ways within the designed coverage area of the cluster where high levels of wireless traffic are to be expected. Drive routes may also be selected to ex-plore weak coverage areas and regions with multiple serving cells, as pre-dicted by propagation modeling software (e.g. CE4), or based on knowledge of the surrounding terrain topography.



The unloaded pilot survey results identify coverage holes, handoff regions, and multiple pilot coverage areas. The pilot survey information highlights fundamental flaws in the RF design of the cluster under best-case, lightly loaded conditions. The pilot survey provides coverage maps for each sector in the cluster; these coverage maps are used during the optimization phase to adjust system parameters. Finally, measuring the pilots levels without load serves as a baseline for comparison with measurements from subse-quent cluster tests under loaded conditions. Characteristics of cell shrink-age can be compared under the extremes of light and heavy traffic load.

During the unloaded coverage tests, two iterative passes of optimization are conducted. The first pass optimization entails correction of neighbor lists and adjustments to the fundamental RF environment (transmit power, an-tenna azimuth, height, downtilt, antenna type). The second pass at opti-mization involves fine adjustment of handoff thresholds, search windows, overhead channel transmit powers, and access parameters. These two iter-ative optimization passes are focused on resolving problems observed by the field teams from the coverage plots and from analysis of dropped call mechanisms.

The final measurements to be performed as a part of the cluster testing are coverage drive runs conducted under loaded conditions. Drive routes for the loaded coverage testing will be exactly the same routes as those used for the unloaded coverage surveys. The objectives are to provide coarse system tuning and to identify, categorize, and catalog coverage deficiencies so the more difficult problems can be resolved during later system-wide op-timization tests. During the loaded testing, both first pass and second pass tuning parameters are adjusted to fix problems observed by the field teams. At the conclusion of the loaded coverage tests, a performance validation procedure is conducted to measure system performance against the cluster exit criteria.

The field test teams have expressed a strong desire to keep the actual clus-ter testing as quick and simple as possible, by deferring much of the de-tailed system tuning to the subsequent system-wide optimization phase. Once the coverage deficiencies have been identified for a particular cluster, if a specific problem cannot be resolved in approximately one-half hour, then the field team will note the situation and proceed with the drive test-ing.

After all clusters in the CDMA network have been tested, system-wide opti-mization will begin with all cells activated. Optimization teams will drive test each of the problem areas identified during the cluster testing, using the same test conditions under which the problem was previously observed. Iterative tuning procedures will be used to fix coverage problems by adjust-ing transmit powers and neighbor list entries. In extreme situations, hand-



off thresholds, search window sizes, or other low-level tuning parameters may have to be modified. If coverage problems cannot be resolved by the field team in one hour, then the team will flag the problem area for further investigation by other RF support personnel.

After attempts have been made by the site team to resolve the individual coverage problem areas, the system-wide optimization will proceed to the fi-nal phase. The final optimization step will be a comprehensive drive test covering the major highways and primary roads in the defined coverage area for the CDMA network. During the system-wide drive run, simulated loading will be used to model traffic on the network. Performance data will be collected as a small number of active CDMA subscriber unit traverse the system-wide drive route. Statistics will be collected to characterize pilot, paging, traffic, and access channel coverage over the entire drive route. Specific problem areas identified by the system-wide drive run will be ad-dressed on a case-by-case basis, after the entire drive has been completed. Comprehensive statistics from the system-wide drive will be used to assess the overall performance quality of the network, including dropped call rates, handoff probabilities, and frame erasure statistics.

At the conclusion of the comprehensive, system-wide drive phase, the RF optimization procedure will be considered complete and the CDMA network ready for live traffic testing and market trials leading into commercial ser-vice. Once significant loading with live traffic is present on the CDMA net-work, additional tuning of the system parameters will be required to accom-modate uneven traffic conditions (e.g. traffic hot spots, unusual traffic pat-terns, etc.) and other dynamic effects which cannot be easily predicted or modeled with simulated traffic loading.

2. Resource Requirements

2.1 StaffThe cluster testing will require the following personnel to conduct the tests:


CLUSTER TESTTASK

TECHNICALHEADCOUNT

DURATIONPER CLUS-

TERCell Site Configuration daysSpectral Monitoring

Measurement daysData Analysis days

Pilot Channel CoverageMeasurement daysData Analysis days


The system-wide optimization testing will require the following personnel to conduct the tests:

2.2 Test EquipmentIn order to conduct the cluster tests and system-wide optimization, the fol-lowing test equipment will be required. Typical quantities required for each test team are indicated within square brackets ([]) before each item.1. [3] Spectrum analyzer, low noise pre-amplifier, logging computer with

IEEE-488 interface card, software for automated logging control2. [3] CDMA mobile or portable diagnostic monitors (QUALCOMM QCP-800

or QCP-1900 phones, portable computer, GPS receiver, mobile diagnos-tic monitor software)

3. [2] Attenuators for generating artificial traffic loading

The following test equipment is optional, but would be beneficial for trou-bleshooting during the field testing:

1. [1] Calibrated 800 MHz or 1.9 GHz RF power meter and power splitter or directional coupler

2.3 Cell ClusterThe cluster of cells to be tested must meet the following objectives:1. Cluster of approximately 19 cells installed, configured, and operational.

Cells must be capable of transmitting pilot, page, and synchronization channels on the forward link. Test cluster should provide geographical overlapping coverage regions between the cells. The outermost ring of cells in the cluster will be primarily used as forward link loading to pro-vide realistic handoff boundaries and interference levels for the interior cells.

2.4 Data AnalysisThe following data analysis software will be necessary to process and present the results of the pre-cluster tests:1. Post-processing data analysis software, such as Lucent Data Analysis

Tool (DAT), to generate summary results and convert Mobile Diagnostic Monitor (MDM) binary log files to ASCII or EXCEL format


SYSTEM-WIDE OPTI-MIZATION TASK

TECHNICALHEADCOUNT

DURATION

Cell Site Configuration daysCase-by-Case Optimiza-tion

Measurement daysData Analysis days


2. Post-processing data analysis software, such as Lucent Data Analysis Tool (DAT), to generate summary results and convert Cell Diagnostic Monitor (CDM) or Call Trace log files to ASCII or EXCEL format

3. Message parsing tool, such as QUALCOMM NPAR, to display over-the-air messaging information

4. MAPINFO software to display graphical results from coverage surveys overlaid on street maps

5. Plotting and statistical analysis software package, such as Microsoft Ex-cel, to process and display spectrum monitoring data

6. Scripts, such as ALERT and BUILD, used to automate the analysis of message logging files

3. CDMA System ParametersThe translation database for the CDMA system contains a great number of parameters which impact the RF performance of the network. Many of these parameters have complex interactions involving system-wide influ-ences upon capacity, coverage, and quality. For this reason, the main CDMA parameters have been divided into three categories: first pass, sec-ond pass, and fixed parameters. First pass optimization parameters are the primary ‘tuning knobs’ which can be used to optimize the CDMA perfor-mance. Second pass optimization parameters should be changed in un-usual cases where problems cannot be resolved during the first pass opti-mization. Fixed parameters should not be changed under any circum-stances during the field optimization process.

The following sections categorize the primary CDMA parameters. The ref-erences [1-4] listed after each translation parameter refer to application notes that provide detailed techniques for selecting appropriate values, pa-rameter interactions, range limitations, and default settings.

3.1 First Pass Optimization ParametersThe following CDMA system parameters should be used as the primary tun-ing controls for the RF optimization procedure during the first pass at opti-mization:1. Neighbor list entries [4]2. BCR attenuation (total forward link transmit power) [1]3. Changes to antenna configurations (azimuth orientation, antenna height,

downtilt angle, antenna type)4. Hard handoff thresholds (CDMA-to-AMPS or CDMA f1-to-f2) [4]

The first pass optimization parameters are the primary translations to be used to fix coverage deficiencies. Cell site transmit powers can be adjusted with BCR attenuation to address coverage spillover, overshoot problems, and multiple pilot coverage regions. In some cases, transmit powers can be adjusted to provide fill-in coverage for weak signal strength areas. Addi-tional alternatives, such as antenna azimuth, downtilting or changing an-



tenna patterns, can be used in problem cases where transmit power adjust-ments are insufficient to resolve a deficiency. During adjustment of BCR at-tenuation, care must be taken to assure that the forward and reverse links are approximately in balance (i.e. the tolerable path loss link margin is the same for uplink and downlink).

The optimization of neighbor lists will be less of a problem during cluster tests, where only a small number of cells are active, than with system-wide tests, where many more sectors are simultaneously active. Due to the lim-ited neighbor list size for each sector, tradeoffs are required to select en-tries which minimize dropped calls because of missed handoffs or handoff sequencing problems.

3.2 Second Pass Optimization ParametersThe following CDMA system parameters should only be changed to correct performance problems at specific trouble spots during the second pass at optimization:1. Soft handoff thresholds [4]2. Active set and neighbor set search window sizes [4]3. Access channel nominal and initial power settings4. Digital gain settings for pilot, page, and sync channels [1]

The second pass optimization parameters can have system-wide perfor-mance impacts, and therefore should be adjusted with caution, in cases were the adjusted parameters do not fully resolve a problem. For example, even small changes in soft handoff thresholds can impact overall system ca-pacity and channel element utilization. In general, attempts should be made to keep a consistent set of handoff thresholds for the entire CDMA network. It is not advisable or practical to alter soft handoff thresholds on a sector-by-sector basis, particularly since handoff thresholds are determined by the primary cell in a multiway handoff; however, in local areas handoff parameters for a group of sectors covering a region can be changed to re-flect small-scale differences.

Search window sizes for the active and neighbor sets should be set initially based on expected cell sizes and multipath propagation delay spreads, as discussed in [4]. If the CDMA deployment contains a mixture of small cells and large cells, then window sizes may have to be adjusted on a case-by-case basis to accommodate all handoff scenarios. For example, if there is a large variation in the antenna heights for CDMA cells in the network, situa-tions may occur where the mobile enters soft handoff with a distant cell. If the mobile uses the distant base station to obtain a timing reference, then the mobile’s reference clock will be retarded by the large propagation delay between the mobile and the distant cell site. When scanning for neighbor list pilots, the mobile will center its search window around the expected time delay of the neighbor’s pilot PN offset, as calculated based on the mo-



bile’s reference timing. Since the mobile’s reference time is retarded by the propagation delay from the distant cell to the mobile, the location of the search window will be skewed by the propagation delay time. In such a sit-uation, if the search window size is not large enough, the mobile may fail to detect pilots from close-in neighbors due to the retarded timing reference.

3.3 Fixed ParametersThe following CDMA system parameters should not be adjusted during the RF optimization procedure:1. Forward power control thresholds [3]2. Reverse power control thresholds [3]3. Remaining set search window size [4]4. Forward overload control setpoints [1]5. Reverse overload control setpoints [2]6. Minimum, maximum, and nominal traffic channel digital gains

The fixed parameters involve quantities which should not be adjusted dur-ing field optimization. These include power control thresholds, overload control setpoints, and some search window sizes. Since power control plays such a critical role in both reverse link and forward link performance for the CDMA system, related thresholds and step sizes should only be adjusted based on simulations or lab measurements. For the optimization tests it is recommended that reverse overload control thresholds be set to their maxi-mum values allowed in the translations to avoid false alarms during the loaded drive testing.

Due to the forward overload control algorithm’s role as the sole overdrive protection mechanism for the linear power amplifier, the forward overload control parameters should be adjusted based on lab tests and computer simulations.

4. Initial Cluster ConfigurationThe cluster under test should be loaded with the default values for CDMA translation parameters, or customized values provided by the RF system de-sign team. Cell site transmit powers should be set to values determined by the customer or the RF system design team; these transmit power levels should be verified and logged at each cell site using a CDMA base station test set.

The cell site and ECP software loads should be functional and stable enough to support originations, terminations, handoffs, and other basic call process-ing capabilities. The RF Call Trace feature should be enabled during the drive testing to monitor both forward and reverse link statistics.



5. Selection of Drive RoutesThe following procedure should be used to select drive routes for optimiza-tion. These steps must be followed as outlined below, because selection of drive routes can seriously impact overall system performance as measured during the cluster exit tests. Steps for proper drive route selection:1. Obtain propagation prediction tool plots for the test cluster from Lucent

CE4 prediction tool and if possible from the customer’s CDMA prediction tool.

2. Choose drive routes that are completely contained within the predicted coverage area of the test cluster (i.e. within the designed coverage area of the cluster).

3. Under no circumstances should the drive routes exit the designed cover-age area of the cluster as determined from the prediction tool plots.

4. Jointly with the customer, choose a combination of primary and sec-ondary roads that provide representative coverage of the interior of the cluster.

5. Avoid drive routes that border between the test cluster and adjacent clusters which have not yet been optimized, as inaccurate performance results will be obtained in these border areas until both clusters can be simultaneously operated.

6. Select drive routes primarily in the interior of the test cluster where for-ward link interference can be accurately modeled.

If some of the drive routes cover areas outside of the designed coverage area of the cluster, these route segments outside the predict coverage area should be removed from performance test results for the cluster. The data from these “out of coverage” route segments should be manually removed from the statistics collected for FER, dropped calls, originations, and termi-nations as a part of the drive test reports, cluster exit tests, and perfor-mance validation tests. At the time of the drive route selection, appropriate notation should be made to indicate which routes and segments are outside of the predicted coverage of the cluster. Both the Lucent and customer rep-resentative should agree on which portions of the drive routes are “out of coverage”, and the joint decisions should be well documented before drive testing begins. Any coverage plots (e.g. FER, pilot Ec/Io, mobile receive power, mobile transmit power) created for the “out of coverage” route seg-ments should explicitly and clearly indicate that these routes are not in the designed coverage of the cluster.

6. Simulation of Traffic LoadingBecause all CDMA users share the same carrier frequency, the performance of the network is highly dependent on local interference levels, and hence on the traffic load of the system. The coverage areas and handoff regions will be strongly influenced by the amount of traffic on the network on a per sector basis. With a typical AMPS system deployment, it is standard prac-tice to drive test and optimize the system under light loading conditions; such a light loading approach is not sufficient to fully exercise a CDMA sys-



tem. For the CDMA system’s coverage, capacity, and quality to be evalu-ated under real-world conditions, the network must be tested under loaded conditions that match those expected for actual operation. Simulated load-ing must be applied to both the forward and reverse links to fully model the effects of traffic upon system performance.

6.1 Forward Link LoadingOrthogonal Channel Noise Simulators (OCNS) are available in all of the CDMA sectors to simulate forward link interference [6]. No additional hardware or software is required to support the operation of OCNS the feature is a standard part of the CDMA equipment. Commands can be is-sued to activate forward link interference at the desired level to emulate a specified number of users [6]; the number of equivalent users and a root mean square (RMS) forward link digital gain settings can be specified on a per sector basis. OCNS will be used for all forward link loading simulation during the RF optimization testing. Loading levels will be determined based on estimated Erlang traffic to be served by the network.

6.2 Reverse Link LoadingOne simple method of emulating reverse link loading is to place an attenua-tor in the transmit path at the CDMA subscriber unit. Unfortunately, if the attenuator is located external to the transceiver, then the transmit-receive duplexor cannot be bypassed, causing the attenuator to affect both the for-ward and reverse link signals. For the reverse link, the influence of the at-tenuator is equivalent, at least in a static sense, to the interference ob-served during actual system loading.

The mobile attenuator is used to simulate the median interference rise ob-served by the cell site during specified Erlang loading conditions. The at-tenuation simulates a static interference condition on the reverse link no attempt is made to model the statistical variations caused by other mobiles in the system. Shadow fading effects are included for the one live mobile that is involved in the test, while the effects from other mobiles are lumped into the single, static attenuation value.

For reverse link loading during the RF optimization procedures, the main objective is to assure that acceptable uplink coverage is maintained under loaded conditions (i.e. to check for coverage holes); for this reason, the at-tenuator is a simple and effective method of measuring cell shrinkage for a specified traffic load. The use of an attenuator to simulate loading is there-fore proposed as a method of checking for coverage holes that might de-velop at the CDMA system is loaded. The attenuator is not meant to stress the base station infrastructure equipment in a manner comparable to live traffic loading. In addition, the attenuator is not proposed to simulate ex-treme conditions as might exist due to jamming, external interference, or other abnormal conditions.



Unfortunately, the impact on the forward link of placing an attenuator at the mobile unit does not mimic the effects observed under actual loading of the CDMA system. Actual traffic loading on the forward link increases the amount of interference on the forward link, while not affecting the absolute received power of the pilot signals. In other words, as the loading is in-creased the measured pilot-to-interference ratios are reduce by the pres-ence of the additional forward traffic channels. An attenuator in the receive path in the mobile reduces the level of both the pilot channel and the inter-ference, not just the pilot channel. As such, the attenuator distorts the pi-lot-to-interference levels observed by the mobile; the result is forward link performance that is not representative of the behavior observed under true loaded conditions.

One can compensate for the unintended forward link changes by using OCNS and increasing each sector’s transmit power an amount equal to the attenuation placed at the mobile. The disadvantage of using extra cell site transmit power to compensate for the attenuation loss is that additional transmit power must be available at the each and every cell site (e.g. for typical loading situations 2 to 3 dB of extra transmit power must be avail-able).

Another method of reducing undesired impacts of the attenuator on forward link performance is based on using microwave hardware to separate the forward and reverse link paths at the mobile. A back-to-back circulator ar-rangement will allow attenuation to be placed only in the reverse link path, while the forward link path will only incur the circulator losses (typically less than 0.5 dB). Such an approach allows attenuators to be used at the CDMA mobiles, without the requirement for increased forward link transmit powers. For the loaded RF optimization tests, mobile attenuators with cir-culators will be used to simulated ‘blanket’ background loading levels on the reverse link. For the loaded tests proposed in this document, reverse link loading will make use of an attenuator combined with a circulator.

7. Nominal Parameter SettingsBased on field experience, lab measurements, and simulations, nominal val-ues have been developed for the most important CDMA parameters. These nominal parameter values differ in some cases from the default values used in the translations database. Depending upon the local environment (ter-rain, clutter, cell layout, etc.), it may be appropriate to adjust the nominal values listed here, within the typical tuning ranges as noted.

Parameter Nominal Value Tuning Range

T_ADD -13 dB -12 to -14 dB



T_DROP -15 dB -14 to -16 dBT_COMP 2.5 dB 2 to 3 dBT_TDROP 2 sec 1 to 4 secActive Search Win 40 chips 10 to 40 chipsNeighbor Search Win 80 chips 40 to 160 chipsPilot Digital Gain 108 dgu 108 dguPage Digital Gain 64 dgu 64 to 96 dguSync Digital Gain 34 dgu 34 dgu

8. Optional Preliminary TestsThe following section describes several tests which may be performed prior to the actual cluster testing. The first test is designed to estimate the in-ve-hicle penetration loss and antenna gain differences between a roof mounted reference antenna and a handheld antenna inside the test vehicle. The pen-etration loss measurement is useful for setting the initial attenuation value between the CDMA handheld and the roof-mounted reference antenna used for the cluster tests. If the in-vehicle penetration loss of the measurement setup has been previously characterized, then there is no need to re-mea-sure the loss for each cluster. In addition, if a specific in-vehicle loss has been assumed in the link budget design for the market being optimized, then the loss from the link budget can be used to directly set the attenua-tion value. If Lucent Technologies and the wireless service provider have previously agreed upon an acceptable attenuation value for in-vehicle loss, then there is no need to perform the experimental characterization.

The second test described in this section is to characterize the forward link RMS digital gain value for a typical CDMA user under nominal loading con-ditions in a particular environment. The RMS digital gain value basically estimates the average transmit power required for each CDMA user; there-fore, RMS digital gain value is useful for setting the Orthogonal Channel Noise Simulation (OCNS) levels for use in forward link loading. In many cases, reasonable RMS digital gain values can be estimated prior to the cluster testing based on simulations or previous field experience. If neces-sary, the forward digital gain test procedure can be used to verify the esti-mated values prior to simulated load testing.

8.1 In-Vehicle Penetration Loss MeasurementThe following section describes a procedure for measuring the difference in propagation path loss between a handheld using an external roof mounted antenna and an identical handheld using a built-in whip antenna inside of the test vehicle. The primary goal is to estimate the difference in perfor-mance between the two antenna configurations, including the effects of both antenna gain differences and in-vehicle penetration losses.



The basic approach is to drive test a section of the CDMA system while si-multaneously logging data with two Mobile Diagnostic Monitors (MDMs): one MDM is connected to a calibrated CDMA phone using an external roof mounted antenna; the other MDM is connected to a calibrated CDMA phone using a built-in whip antenna inside of the test van. During the drive run, full rate Markov calls are initiated with MDMs that are configured to log to-tal received power, pilot channel Ec/Io, and mobile transmit power. After the drive run, the MDM data files are used to compare the mean mobile transmit power difference for the two antenna configurations. Since the two calibrated phones are identical except for the antenna configurations, the measured difference in transmitted power corresponds to the combined effects of in-vehicle penetration and antenna gain differences. It is also possible to use the mobile received power to estimate the in-vehicle pene-tration and antenna gain differences; however, using mobile received power will make the measurement susceptible to the effects of receiver overload and intermodulation interference if the mobile is subjected to high signal levels.

8.1.1 Test EquipmentThe following list of equipment is required to conduct the test, where quan-tities of each item are shown within square brackets ([]).1. [1] Off-the-shelf (unmodified) CDMA portable cellular transceiver2. [1] Modified CDMA portable cellular transceiver with antenna connector

(alternatively a car kit can be used to derive the antenna interface con-nection)

3. [1] Coaxial interface cable with SMA male to SMA male connectors 4. [1] Coaxial adapter SMA female to TNC female5. [1] Magnetic mount ground plane reference antenna with male TNC con-

nector 6. [2] Serial interface cable to connect between CDMA portable and MDM

logging computer 7. [2] MDM logging computers 8. [2] GPS receivers for MDM logging 9. [1] QUALCOMM MDM software10. [1] Lucent Data Analysis Tool (DAT) software11. [1] Microsoft Excel or similar spreadsheet program for data analysis Both of the CDMA test portables should be calibrated in the lab prior to use in the field testing. Specifically, the logged received and transmitted power values should be verified from bench measurements. If necessary, a correc-tion factor can be applied the logged measurements to improve the accu-racy of the drive test results.

8.1.2 Test ConditionsRigidly mount the CDMA portable with the built-in whip antenna at a conve-nient location in the test vehicle. Orient the CDMA portable in a vertical position with the whip antenna fully extended. When selecting a location to



place the phone, find a position free and clear of blockages or obstacles. Mount the phone at approximately head height to simulate a typical in-vehi-cle usage scenario. Velcro tape or nylon tie-wraps can be used to secure the phone to a suitable mounting structure. Another option is to fabricate a mounting fixture from a large block of Styrofoam packing material. Avoid placing any large metal objects within approximately 2 feet of the whip an-tenna on the handheld. Connect the modified CDMA portable with the antenna connector to the magnetic mount antenna on the roof of the test vehicle. In the test vehicle, set up the two MDMs to log data with the following log mask FFD049F0. The log mask will enable the MDM to record messaging information, total received power, mobile transmit power, pilot channel Ec/Io, and GPS data.

Set the CDMA translations parameters such that a single CDMA sector is transmitting; disable all other sectors. A single active sector is used during the in-vehicle penetration tests to avoid complications arising if the roof-mounted antenna phone and in-vehicle whip antenna phone are in different handoff states. The test results are more repeatable if the test conditions are reduced to having a single active sector.

8.1.3 Test ProceduresSelect a drive route that includes a variety of typical terrain conditions and distances from the CDMA cell sites. Post processing and analysis of the col-lected data will be easier if the drive route is kept relatively short (e.g. ap-proximately 30 minutes of driving); however, longer drive routes can be ac-commodated if necessary. Avoid extended periods of driving in areas where the portable is likely to be transmitting at the absolute minimum or maxi-mum powers, such as locations in immediate proximity to cell sites or in ex-treme coverage holes. At the start of the drive test, check to be certain the both MDMs are operational and ready to log data. Start a full rate Markov mode call. Begin logging simultaneously on both MDMs and drive the test vehicle on the chosen drive route. Watch the <F9> screen on the MDM to observe when either mobile drops the CDMA call. When a call drops, reini-tiate a Markov mode call as rapidly as possible. At the conclusion of the drive, stop logging and save the log files from both MDMs.

8.1.4 Data AnalysisThe data processing steps required to obtain an estimate of the path loss differences between the two phones can be summarized as follows: 1. Process the MDM binary log files through the Lucent Data Analysis Tool

(DAT). 2. Extract the ASCII text output files containing the mobile transmit power

data. 3. Load the two ASCII output files from Lucent DAT into an Excel spread-

sheet.



4. Use the timestamps to align the two files, such that both sets of the posi-tions and times match.

5. Prune the data to remove segments where the mobile transmit power is saturated or clipped.

6. Further prune the data to remove segments where one phone or the other does not report valid transmit power data (i.e. call dropped, trans-mitter turned off, etc.).

7. Create a new data column in the spreadsheet consisting of the difference in transmit power.

8. Calculate the mean and standard deviation for the difference in transmit power.

9. The mean difference in transmit power corresponds to the path loss dif-ference.

Detailed instructions for each step are outlined below.

Process each MDM log file individually through the Lucent Data Analysis Tool (DAT). After each log file is processed through the DAT software, the "out" directory should contain a file named "mtx.amp". The "mtx.amp" file contains ASCII text in column format which can be read into any spread-sheet program for further analysis. Each row of text in the "mtx.amp" file contains the GPS latitude, GPS longitude, GPS timestamp, and the mobile transmit power in dBm units. Rename the two "mtx.amp" files giving them unique filenames, such as "roofmnt.dat" and "builtin.dat". Read the two ASCII data files into a spreadsheet program. Use the time-stamps from the two files to align the columns such that the GPS times and positions align. Delete any rows of data where the data file from either mo-bile did not contain a data report from the mobile. For example, several sit-uations may occur where the MDM data will not contain a mobile transmit power reading every second. If the serial data link between the phone and MDM is overloaded, then some messages can be missing. If the mobile turns off its transmitter due to poor forward link FER, then the MDM log file will not contain valid transmit power values during those time periods. If one of the mobiles experienced a dropped call, the there will be no corre-sponding transmit power until the call is reinitiated. The CDMA portables are able to transmit over a dynamic range extending from approximately -53 dBm to +23 dBm. When the transmit power of the mobile is near either the upper or lower extreme, clipping can occur. A comparison of the transmit powers will not be meaningful in intervals where either phone was close to these clipping levels. For this reason, prune the dataset to remove any rows of data where the transmit power of the either phone is greater than +17 dBm or less than -47 dBm. Once the dataset has been time aligned and pruned, create a new column in the spreadsheet representing the difference in transmit power. The trans-mit power difference column should be created by subtracting the transmit power of the roof mounted antenna mobile (roofmnt.dat) from the built-in



whip antenna mobile (builtin.dat). The resulting data column will be the transmit power difference in decibels. Use the spreadsheet to compute the mean and standard deviation of the transmit power difference column of data. The mean of transmit power dif-ference is an estimate of the path loss difference between the roof mounted antenna mobile and the built-in whip antenna mobile. The standard devia-tion of the transmit power difference should be less than approximately 3 dB. If the measured standard deviation is greater than 3 dB then carefully inspect the equipment setup for malfunctions.Create several data plots to visually validate the data. First, plot the trans-mit powers of the two mobiles as a function of time. The transit powers should roughly track one another as the test vehicle traverses the drive route. The transmit power of the handheld with the built-in whip antenna should be consistently higher than for the portable with the external roof mounted antenna. Observe that neither mobile transmit power is clipped or abnormal in any way. Second, plot the difference in mobile transmit power as a function of time along with a straight line marking the mean value. Observe that the differ-ence in transmit power is distributed symmetrically about the mean value. A histogram of the transmit power difference can also be used to validate the distribution of transmit power differences. Note any extreme outlier points or unusual biases in the data. If the plots indicate that the data are well behaved and no anomalies are noted, then the mean difference in transmit power between the handheld with the built-in whip antenna and the handheld with the external ground plane antenna estimates the path loss difference for the two configurations. The path loss difference is due to the antenna gain difference and the in-ve-hicle penetration loss.

9. CDMA Performance Tests

9.1 Spectral Monitoring TestThe objective of the Spectral Monitoring Test is to observe the received in-terference and background noise levels in both the CDMA uplink and down-link bands. Measured interference levels should be compared against thresholds defined in the CDMA RF Engineering Guidelines.

A spectrum analyzer can be used to make swept measurements of the CDMA forward and reverse link bands. With a computer to control the recording operation, the entire measurement system can be automated. The main disadvantage of using a spectrum analyzer is the relatively poor noise figure for most commercial units. The high thermal noise levels present in the spectrum analyzer place a lower limit on the signal level which can be measured with the instrument. Since the interference levels which must be observed are typically in the -95 to -105 dBm range, it is nec-essary to reduce the noise floor of the measurement instrument to this



level. The poor noise performance of the spectrum analyzer can be over-come to a certain degree by placing a Low Noise Amplifier (LNA) at the in-put to the spectrum analyzer. The pre-amplifier LNA will reduce the noise floor of the analyzer while at the same time reducing the front end overload point (third order intermodulation intercept).

9.1.1 Entrance Criteria1. The CDMA band and guard band must be cleared of other traffic and po-

tential interference sources during the time spectrum measurement in-terval.

9.1.2 Test Conditions

9.1.2.1 Reverse Link MeasurementsFor the reverse link spectral monitoring test, connect the spectrum ana-lyzer to one of the cell site’s receive antennas through the 4:1 splitter lo-cated prior to the BCR input in the receiver chain. Connect an IEEE-488 ca-ble between the spectrum analyzer and the control computer’s IEEE-488 in-terface card. Run the spectrum analyzer control program on the control computer. Set the span and center frequency of the spectrum analyzer to cover the entire CDMA uplink band and the associated guard band (span = 1.77 MHz, center frequency = CDMA carrier frequency). Set the resolution bandwidth of the spectrum analyzer to 30 kHz.

9.1.2.2 Forward Link MeasurementsFor the forward link spectral monitoring the spectrum analyzer and control computer will be installed in a test van. The spectrum analyzer will be con-nected to a magnetic mount antenna on the roof of the test van. Set the span and center frequency of the spectrum analyzer to cover the entire CDMA downlink band and the associated guard band (span > 1.7 MHz, cen-ter frequency = CDMA carrier frequency). Set the resolution bandwidth of the spectrum analyzer to 30 kHz.

9.1.3 Test Procedures

9.1.3.1 Reverse Link MeasurementsFor the reverse link measurements, the spectrum analyzer will be installed for measurements in the cell site. The following steps are used to make the interference measurements with the spectrum analyzer:1. Couple the spectrum analyzer into the sector’s receive antenna using a

power splitter. The spectrum analyzer should be connected at a point with at most (TBD) dB of loss to the receive antenna.

2. Connect the spectrum analyzer to the IEEE-488 interface card on the control computer.

3. Run the control program and set the parameters for automated logging of the CDMA reverse link frequency band. The logging should be con-



ducted at night during the same time periods that the CDMA optimiza-tion testing will be performed.

4. Start logging spectrum analyzer data and continue logging for a period of at least 1 hour.

5. Stop logging and save the log files. 6. Repeat the spectrum analyzer logging during at least 2 one-hour periods.

The spectrum analyzer logs will be processed by observing probability den-sity function (PDF) of the interference levels over the monitoring periods. The interference levels will be compared against minimum acceptable lev-els as stated in the CDMA Engineering Guidelines.

9.1.3.2 Forward Link MeasurementsFor the forward link measurements, the spectrum analyzer will be installed for measurements in the roving test van. The following steps are used to make the interference measurements with the spectrum analyzer:1. Couple the spectrum analyzer into a magnetic mount whip antenna

mounted on the roof of the test van. The spectrum analyzer should be connected at a point with at most 5 dB of loss to the receive antenna.

2. Connect the spectrum analyzer to the IEEE-488 interface card on the control computer.

3. Run the control program and set the parameters for automated logging of the CDMA forward link frequency band. The logging should be con-ducted at night during the same time periods that the CDMA optimiza-tion testing will be performed.

4. Start logging spectrum analyzer data. Drive the test van to areas where the highest levels of forward link interference are expected to be ob-served. For example, ridges, hills, or other terrain features where a mo-bile is likely to be line-of-sight to a number of cells. Propagation predic-tion plots and terrain elevation plots can be used to select appropriate drive routes. RF engineers for the local system may also be able to sug-gest appropriate drive locations.

5. After the selected drive routes have been completed, stop logging and save the log files.

6. Repeat the spectrum analyzer logging during at least 3 one-hour periods.

9.1.4 Data AnalysisThe spectrum analyzer logs will be processed by observing peak interfer-ence levels over the monitoring periods. The interference levels will be compared against minimum acceptable levels as stated in the CDMA Engi-neering Guidelines.



9.1.5 Exit Criteria1. Spectral measurements should record in-band interference levels which

are below the recommended levels as specified in the CDMA RF Engi-neering Guidelines. Areas where interference exceeds the recom-mended thresholds will be addressed jointly by Lucent Technologies and the customer on a case-by-case basis.

9.2 Unloaded Coverage TestThe objective of the Unloaded Coverage Test is to measure the forward channel pilot coverage for unloaded conditions, with all sectors in the clus-ter transmitting pilot, page, and sync channels, while a single Markov call is active. For these tests, a CDMA Mobile Diagnostic Monitor (MDM) will be placed in a roving test vehicle and driven over selected drive routes. The drive routes should include the most heavily traveled highways and primary roadways in the designed coverage area of the cluster. The drive routes should also cover areas with substantial handoff activity.

9.2.1 Entrance Criteria1. Coverage prediction plots from planning tools, such as CE4, must be pre-

pared for the coverage area of the test cluster. 2. CDMA equipment for the test cluster must be installed, configured, and

operational. Rudimentary tests of call originations, terminations, and sector-to-sector softer handoffs should be performed on each cell prior to the drive testing phase.

3. Translations parameters for the sectors in the cluster should have been entered and verified using the Recent Change Verification (RCV) proce-dures.

4. Transmit powers of pilot, page, sync, and traffic channels should be cali-brated at each sector in the cluster as described in the Forward Link Translation Applications Note [1].

5. RF Call Trace capability must be functional in order to monitor forward and reverse link activity from the cell’s perspective. An alternative op-tion is to have Cell Diagnostic Monitors (CDMs) installed for the cells in the cluster.

6. CDMA mobiles used in the testing should be measured for compliance with IS-95A and the IS-98 Mobile Station Performance Specification.

9.2.2 Test ConditionsEach sector should be transmitting pilot, page, and sync channels at the nominal levels. No other CDMA traffic should be on the test cluster other than the test phones. With the current version of CDMA subscriber units, it is possible to log pilot searcher data while simultaneously logging data with a Markov call; therefore, the recommended approach is to perform un-loaded pilot survey measurement with a single Markov call running.



9.2.3 Test ProceduresThe procedure to be used for the pilot channel coverage surveys is as fol-lows:1. Install the diagnostic monitor in the test vehicle. Connect the CDMA test

phone and the GPS receiver to the logging computer. Run the diagnostic monitor software; be particularly careful that the initialization file for the diagnostic monitor software (‘dm.ini’) includes settings which exactly match the CDMA test phone. Set the log mask on the diagnostic monitor to the appropriate value, by using the <F5> function. Check to be cer-tain that the diagnostic monitor is logging GPS position data by observ-ing the speed display on the <F2> screen; if the speed is shown as ‘N/A’, then GPS data is not being recorded, otherwise the speed display should indicate the approximate speed of the test vehicle.

2. At the beginning of each drive run, initiate a full-rate Markov mode call. Assure that the call is successful by checking that an acceptable FER is displayed on the CDMA mobile’s LCD. Use the diagnostic monitor to dis-able sleep mode in the phone.

3. At the beginning of each drive run, initiate the Call Trace feature at the cell site to log performance statistics.

4. At the beginning of each drive route, place the diagnostic monitor into the <F9> summary display mode. Do not use the <F2> temporal ana-lyzer display mode as it may interfere with proper file logging. Initiate logging on the mobile diagnostic monitor by typing <ALT><L>. During the drive testing, monitor the percentage of Random Access Memory (RAM) for the logged data; if the logged data exceeds 50% of the com-puter’s memory, then stop logging by hitting <ALT><L>, save the log file by typing <CTRL><F10>, and then restart the diagnostic monitor software.

5. At the conclusion of each drive route, save the log files as previously de-scribed in Step 2.

9.2.4 Data AnalysisThe first step of data analysis involves the use of script tools to process the mobile messaging files. These automated scripts are described in detail in Chapter 11 of this document.

Data analysis of the pilot channel survey data will primarily consist of pro-cessing the data through the post-processing software. The resulting ASCII files can be used to display pilot channel Ec/Io in decibels as a function of location. Using MAPINFO, the field data can be overlaid upon a street map. The resulting pilot coverage maps can be compared against predicted levels from RF planning tools. Handoff areas can be observed by mapping the handoff state (0, 1, 2, or 3-way) for each geographic location.



Other summary statistics are useful for assessing the overall performance of the CDMA system; for example, Cumulative Distribution Functions (CDFs) of pilot Ec/Io can be used to determine the percentage of the drive route where pilot levels exceeded a particular value. Similar statistics are useful for determining the percentages of 1, 2, and 3-way handoff.

The pilot coverage maps should be used to validate the RF design for the test cluster. Because the measurements were made under unloaded condi-tions, they represent an ideal, best-case condition. Under full loading con-ditions, observed pilot Ec/Io levels would be as much as 5 dB lower than the unloaded measurement values. Any coverage holes which exist for the un-loaded measurements will be enlarged once the system matures and be-comes loaded. If substantial areas of poor pilot coverage exist in the mea-sured coverage area for the test cluster, then RF design alternatives should be considered to remedy the problem areas. Possible solutions include changing pilot powers, changing antennas patterns, reorienting antenna boresights, and adding additional cells or repeaters.

The maps of handoff activity can be useful for setting handoff thresholds, creating neighbor lists, and identifying trouble spots. For an unloaded sys-tem, one can expect to observe significantly higher handoff percentages than for a fully loaded system. Because handoff activity is based on pilot Ec/Io levels, the handoff areas will tend to shrink as the CDMA system be-comes loaded and Ec/Io levels decrease due to increased interference. For the current generation of CDMA subscriber units, the CDMA mobile unit can simultaneously receive voice channel signals from at most 3 sectors, for this reason it is important to reduce the number of areas where 4 or more strong pilot signals are present.

9.2.5 Exit CriteriaThe overall performance of the CDMA network depends upon the area cov-erage probability for which the system was designed. For example, a sys-tem designed for 90% area coverage would be expected to incur a higher outage probability than a system designed for 97% area coverage. For this reason, specific numerical exit criteria cannot be provided in a general guidelines document such as this one. The exact exit criteria used in the RF optimization tests will be customer and market specific. Ranges of typical values will be provided here. It is expected that prior to the actual RF opti-mization testing, final values will be assigned based on the design criteria for the test market.

The following exit criteria apply for the unloaded pilot survey results:1. Best server pilot Ec/Io measurements should be greater than -11 dB for

the designed area coverage probability of the system (typically 85 to 97%).



As is typical with large-scale network deployments, cluster exit criteria will have to be adjusted on an exception basis to account for anomalies. For ex-ample, all cells in the cluster may not be operational at the time of the clus-ter testing. Cells may not be operational due to backhaul transport out-ages. Coverage holes may exist that will be filled when adjacent clusters are brought on line. The engineering teams should jointly address areas where the cluster performance does not meet exit criteria targets.

9.3 Loaded Coverage TestThe objective of the Loaded Coverage Test is to measure the performance of the CDMA system with actual or simulated loading conditions. During the testing with traffic loading, traffic will be simulated using one of the methods discussed in Section 6. For these tests, a CDMA Mobile Diagnostic Monitor (MDM) will be placed in a roving test vehicle and driven over the same drive routes used for the Unloaded Pilot Channel Coverage Survey Test. During the cluster testing, the objective is to identify, categorize, and catalog the coverage problems observed during the drive testing. Any cov-erage problems which cannot be solved with basic parameter changes, re-quiring less than 30 minutes of work, will be deferred until the system-wide optimization phase. Parameter adjustments during the cluster testing will be limited to the Adjusted Parameters listed in Section 5.1.

9.3.1 Entrance CriteriaThe unloaded coverage test must have been successfully completed.

9.3.2 Test ConditionsLoad the forward link with OCNS levels set to the designed Erlang load of the CDMA network. Set the mobile attenuation value to model the nominal reverse link load.

9.3.3 Test ProceduresThe procedure to be used for the loaded coverage tests is as follows:1. Install the diagnostic monitor in the test vehicle. Connect the CDMA test

phone and the GPS receiver to the logging computer. Run the diagnostic monitor software; be particularly careful that the initialization file for the diagnostic monitor software (‘dm.ini’) includes settings which exactly match the CDMA test phone. Set the log mask on the diagnostic monitor to the appropriate value, by using the <F5> function. Check to be cer-tain that the diagnostic monitor is logging GPS position data by observ-ing the speed display on the <F2> screen; if the speed is shown as ‘N/A’, then GPS data is not being recorded, otherwise the speed display should indicate the approximate speed of the test vehicle.



2. At the beginning of each drive run, initiate a full-rate Markov mode call. Assure that the call is successful by checking the display of acceptable FER on the CDMA mobile’s LCD. Use the diagnostic monitor to disable sleep mode in the phone.

3. At the beginning of each drive run, initiate the Call Trace feature at the cell site to log performance statistics.

4. At the beginning of each drive route, place the diagnostic monitor into the <F9> summary display mode. Do not use the <F2> temporal ana-lyzer display mode as it may interfere with proper file logging. Initiate logging on the mobile diagnostic monitor by typing <ALT><L>. During the drive testing, monitor the percentage of Random Access Memory (RAM) for the logged data; if the logged data exceeds 50% of the com-puter’s memory, then stop logging by hitting <ALT><L>, save the log file by typing <CTRL><F10>, and then restart the diagnostic monitor software.

5. At the conclusion of each drive route, save the log files as previously de-scribed in Step 2.

9.3.4 Data AnalysisThe first step of data analysis involves the use of script tools to process the mobile messaging files. These automated scripts are described in detail in Chapter 11 of this document.

Data analysis of the loaded coverage test data will primarily consist of pro-cessing the data through the post-processing software. The resulting ASCII files can be used to display pilot channel Ec/Io in decibels as a function of location. Using MAPINFO, the field data can be overlaid upon a street map. The resulting pilot coverage maps can be compared against predicted levels from RF planning tools. Handoff areas can be observed by mapping the handoff state (0, 1, 2, or 3-way) for each geographic location.

Other summary statistics are useful for assessing the overall performance of the CDMA system; for example, Cumulative Distribution Functions (CDFs) of pilot Ec/Io can be used to determine the percentage of the drive route where pilot levels exceeded a particular value. Similar statistics are useful for determining the percentages of 1, 2, and 3-way handoff.

The forward and reverse link coverage maps should be used to validate the RF design for the test cluster. Because the measurements were made un-der unloaded conditions, they represent an ideal, best-case condition. Un-der full loading conditions, observed pilot Ec/Io levels would be as much as 5 dB lower than the unloaded measurement values. Any coverage holes which exist for the unloaded measurements will be enlarged once the sys-tem matures and becomes loaded. If substantial areas of poor pilot cover-age exist in the measured coverage area for the test cluster, then RF design



alternatives should be considered to remedy the problem areas. Possible solutions include changing pilot powers, changing antennas patterns, reori-enting antenna boresights, and adding additional cells or repeaters.

The maps of handoff activity can be useful for setting handoff thresholds, creating neighbor lists, and identifying trouble spots. For an unloaded sys-tem, one can expect to observe significantly higher handoff percentages than for a fully loaded system. Because handoff activity is based on pilot Ec/Io levels, the handoff areas will tend to shrink as the CDMA system be-comes loaded and Ec/Io levels decrease due to increased interference. The CDMA mobile unit can simultaneously receive voice channel signals from at most 3 sectors, for this reason it is important to reduce the number of areas where 4 or more strong pilot signals are present.


The following exit criteria apply for the loaded pilot survey results:1. Best server pilot Ec/Io measurements should be greater than -15 dB for


2. Forward FER measurements should be less than the outage threshold of 10% for the designed area coverage probability of the system (typically 85 to 97%).

3. Reverse FER measurements should be less than the outage threshold of 10% for the designed area coverage probability of the system (typically 85 to 97%).

4. Mobile transmit power measurements should be less than 20 dBm for the designed area coverage probability of the system (typically 85 to 97%).

As is typical with large-scale network deployments, cluster exit criteria will have to be adjusted on an exception basis to account for anomalies. For ex-ample, all cells in the cluster may not be operational at the time of the clus-ter testing. Cells may not be operational due to backhaul transport out-ages. Coverage holes may exist that will be filled when adjacent clusters



are brought on line. The engineering teams should jointly address areas where the cluster performance does not meet exit criteria targets.

9.4 System-wide Optimization TestThe System-wide Optimization Tests will be performed after the cluster tests have been completed for all clusters in the network. After the cluster testing, a reasonably comprehensive list of coverage problems should have been cataloged. The system-wide optimization will focus on adjusting CDMA parameters to optimize coverage in the problem areas.

9.4.1 Entrance Criteria1. A sufficient number of cells in the CDMA market must be installed, inte-

grated, and operational to allow RF testing of a majority of the geograph-ical area of the market.

2. Exit criteria for cluster test phase must be successfully completed for the majority of cells in the CDMA market (exceptions will be handled on a case-by-case basis).

9.4.2 Test ConditionsThe first step in the system-wide optimization is to adjust the BCR attenua-tions of the cells based on loaded pilot channel surveys from cluster testing. Initial transmit power settings should be selected to control overshoot and reduce the number of pilots present in multiple coverage areas, where more than 3 strong pilots exist. BCR attenuations can also be adjusted to provide fill-in coverage for weak signal areas that were observed during the pilot surveys.

If geographical areas exist where more than 3 pilot signals are consistently observed, attempts can be made to provide dominant coverage by one or more sectors. The first step in adjusting the BCR attenuations should be to reduce the signal strengths of the weakest sectors in the multiple coverage area in steps of approximately 2 dB. Re-drive the problem area after each adjustment and check for FER quality and handoff performance. If decreas-ing the weakest pilot signals by 4 dB from the initial setting does not re-solve the problem, attempts can be made to increase the levels of the domi-nant servers. If possible, increase the one or two strongest pilots in the area by setting BCR attenuations to provide 2 dB more transmit power. Re-drive the problem area to check for performance.

The next step is to refine the neighbor lists based on the unloaded pilot sur-vey runs. By examining the pilot PN offsets of the serving sectors on the drive routes, add or delete neighbor list entries for each sector. In other words, in the general coverage area of a given sector, check to be certain



that all pilot PN offsets recorded by the test mobile are represented in the neighbor list. In cases where more than 12 potential neighbor list entries exist, tradeoffs will have to be made to select the most frequently used neighbor list entries. If the neighbor list size becomes a problem in a geo-graphical area, it may also be possible to reduce the transmit powers on one or more of the surrounding cells to minimize their signal strengths in the problem area.

9.4.3 Test ProceduresAfter the initial adjustment of tuning parameters, drive testing is performed in the coverage problem areas cataloged during the cluster tests. Iterative adjustments are used to rectify coverage or handoff problems. At each cov-erage problem area, the problem resolution will be broken down into three categories:1. Simple Problem (involving First Pass Parameters only) resolvable in 30

minutes2. Complex Problem (involving First and Second Pass Parameters) resolv-

able in 1 hour3. Unsolved Problem (refer to CDMA RF support team for resolution).

After attacking each of the problem coverage areas identified during the cluster testing, a system-wide drive run should be completed. The system drive run should include the main highways and primary roads which carry the most airtime traffic for the wireless market. Drive routes should cover highway interchanges, exit/entrance ramps to arterial roads, over water bridges, raised highways, and other areas where reliable CDMA coverage is mandatory. The objective of the system-wide drive test is to collect overall performance statistics with the entire CDMA network activated. A sec-ondary goal is to identify additional trouble spots that were not discovered during the cluster testing.

For the system-wide drive run, all CDMA cells in the network should be on the air, with translations parameters updated based on the most recent cluster test results. The drive testing should be performed using the same procedures described for the cluster tests in Sections 7.2 and 7.3. The en-tire system drive can be conducted in sections or as a single drive run. The full rate Markov mode test call will have to be restarted and mobile diag-nostic monitor logging reinitiated after every call drop that is encountered during the driving.

9.4.4 Data AnalysisAt the conclusion of the system-wide drive, the aggregate statistics should be processed to obtain an estimate of the overall CDMA performance. Pri-mary results would include Cumulative Distribution Functions (CDFs) of pi-lot channel Ec/Io, forward and reverse FER, and mobile transmit power.




The following exit criteria apply for the system-wide optimization phase:1. Best server pilot Ec/Io measurements should be greater than -15 dB for


2. Forward FER measurements should be less than the outage threshold of 10% for the designed area coverage probability of the system (typically 85 to 97%).

3. Reverse FER measurements should be less than the outage threshold of 10% for the designed area coverage probability of the system (typically 85 to 97%).

4. Mobile transmit power measurements should be less than 20 dBm for the designed area coverage probability of the system (typically 85 to 97%).

As is typical with large-scale network deployments, cluster exit criteria will have to be adjusted on an exception basis to account for anomalies. For ex-ample, all cells in the cluster may not be operational at the time of the clus-ter testing. Cells may not be operational due to backhaul transport out-ages. Coverage holes may exist that will be filled when adjacent clusters are brought on line. The engineering teams should jointly address areas where the cluster performance does not meet exit criteria targets.

9.5 Dropped Call TestThe object of the dropped call test is to use un-intended call interruptions (dropped calls) to characterized the state of optimized clusters or systems. The number and types of dropped calls will be used as metrics for the qual-ity of the system.

9.5.1 Entrance CriteriaThe cluster or system to be tested should be optimized to the degree possi-ble as described in Section 7.4. The system configuration, design parame-ters including link budget and traffic capacity, and the optimized neighbor lists will be used along with predicted coverage plots and plots of data taken in the optimization tests . Known areas of poor coverage and in-ade-



quate neighbor lists should be noted. The average digital gain per user un-der load should be determined.

The CDMA spectrum will have been cleared according to the criteria of the CDMA RF Design Guide. Remaining interference on the forward and re-verse link should be characterized for in-band and wide band sources. Ar-eas that support generation of intermodulation products in CDMA mobiles should be noted as well as areas with low path loss between other interfer-ence sources and CDMA base stations.

The mobiles used in tests for dropped calls should be compliant with the IS-98 standard. Each mobile should be equipped with a mobile diagnostic monitor of the appropriate version. If attenuator loading is to be used for the reverse link, the mobile should be equipped for attenuation in the re-verse link.

The mobile diagnostic monitor will be the key tool for measurements of the forward link. The QUALCOMM NPAR tool will be used to provide mobile message data for the data analysis tools developed by Lucent Technologies. Measurements on the reverse link will be made using RF Call Trace and, in certain instances, by the cell diagnostic monitor. The data collected by these tools will be analyzed by the Lucent data analysis tools, as well. Call processing information will be provided by CP Call Trace and the Cpfail messages.

9.5.2 Test ConditionsDropped calls will be characterized on a drive route through a portion of the cluster that reflects full operation of the CDMA system. Areas without the full complement of designed hand-off neighbors are to be excluded from the drive route. Areas with known problems are to be identified. The drive route, selected to reflect the interests of the customer, must be well charac-terized over the expected range of speeds. The coverage, interference, pi-lot, and hand-off environments must be understood before the dropped call test begins. The time of day of the drive test must be selected to reflect lev-els of usage, interference, and other time-dependent factors that are appro-priate for the design of the system.

The system will be loaded to the contractually specified traffic handling ca-pacity. Two calls will be used to determine drops, one voice call and one full-rate Markov call. The remainder of the forward link loading will be pro-vided with OCNS; each sector will be loaded to its specified traffic capacity (Erlang loading) with allowance for hand-off overhead. The digital gain per user for OCNS will be set to the value determined during cluster optimiza-tion. The reverse link loading will be achieved by inserting an attenuator in the reverse link of the mobile. The attenuator value will correspond to the remainder of the average traffic loading of the sectors, including neighbors,



that serve the drive route. Procedures for loading are provided in Transla-tion Application Note 5.

9.5.3 Test ProceduresMeasurements taken on the drive route will include mobile diagnostic moni-tor logs, spectrum analyzer traces of the entire cellular band, GPS position and time data, and operator narrative that describes specifically the loca-tion and position of each drop. Measurements taken at the switch will in-clude RF Call Trace for the Markov call, CP Call Trace, and Cpfail logs. If interference conditions are known or suspected to exist at a particular base station, appropriate spectrum analyzer measures will be logged on the ap-propriate sectors of the base station. Cell diagnostic monitor data may be recorded at selected base stations for diagnostic purposes.

9.5.4 Data AnalysisMobile diagnostic monitor data will be analyzed using the QUALCOMM NPAR tool; the NPAR output will be used by the Lucent data reduction tool to generate plots and message analyses. RF Call Trace data will be used to generate plots as well. Plots and histograms of forward and reverse FER, hand-off activity, mobile received and transmitted power, mobile Ec/Io, base station Eb/No and digital gain can be used. Message sequences preceding each call drop will be analyzed to determine pilot state, hand-off state, er-ror, and signal strength conditions leading to the drop. As needed to sup-port the analysis, CP Call Trace and Cpfail logs for the corresponding time intervals will be examined.

Spectrum analyzer data will be reduced using the Lucent SA4 tool; Inte-grated power and frequency plots will be provided for ten seconds prior to each drop or for other conditions as indicated.

Analysis will lead to classification of the call drops into categories; where possible, the cause of each classified drop will be provided. The dropped calls will be attributed either to system RF performance, mobile operation or malfunction, operation of the system infra-structure, and unknown causes. The metrics to be used in reporting the results of the dropped call test may vary from customer to customer. However, a minimum set will in-clude the number of drops in each category and the number that can be cor-rected in subsequent optimizations.

When a cause can be identified for a dropped call, root cause analysis will be carried out and reported as a part of the quality record. Fault analysis tables, software aids, and experts may be used.

9.5.5 Exit CriteriaThe dropped call test will be deemed to be complete when the drive test is completed, the dropped calls encountered have been analyzed, corrective



action taken, and results reported. Corrective action can include altering system conditions and re-driving to demonstrate improvement. It can in-clude also referring results of data and root-cause analyses to experts for further determination. Corrective action involving changes in system per-formance or configuration may be deferred until a later stage of system op-timization with the agreement of the customer.

Two important parts of the report of results are the metrics for dropped calls and the results of the root cause analysis. These results will be used to continually update the fault analysis trees and the performance criteria.

Numerical exit criteria for the dropped call test will be based upon the spe-cific terms and conditions of the contracts for each customer. Typically dropped call rates in the range of 2 to 5% will be appropriate as exit crite-ria, depending upon whether the tests are designed for cluster acceptance, marketing trial entrance, or warranty testing.

10. Specialized CDMA Optimization TechniquesThe following section attempts to provide insight into the most frequently occurring performance problems for the CDMA system. Remedial actions are presented for each type of RF optimization problem. Tradeoffs in pa-rameter selection are described, as fixing a problem in one geographical area may lead to the creation of problems in other areas. Obviously, the en-tire optimization process is iterative in nature.

The intent is for this section to grow, evolve, and become more valuable as CDMA field experience broadens. The RF optimization problems listed be-low represent typical situations encountered with recent software releases. Attempts have been made to cover only problems which are due to funda-mental CDMA problems or problems with the Lucent Technologies CDMA implementation. Software bugs and quirks relevant to a particular software release have been intentionally disregarded.

10.1 No Service

10.1.1 Inadequate Pilot Signal Strength from Serving Sector

If CDMA calls cannot be originated because of inadequate pilot signal strength from a serving sector, the problem is most likely due to a coverage hole created by excessive path loss. The excessive path loss could be due to blockages from terrain, buildings, trees, or any other radio obstacle. For CDMA systems, the maximum allowable path loss will shrink as a function of system load; therefore, coverage holes which were not evident during light load conditions may suddenly appear under heavy traffic load.



The primary CDMA tuning parameter which can be used to address cover-age holes is the BCR attenuation. By increasing the transmit power from the best serving sector in steps of approximately 2 dB, it should be possible to determine if the coverage hole can be adequately filled. Unfortunately, in many cases increasing transmit power will not be able to solve the prob-lem; for example, due to the limited power output from CDMA minicells, very little transmit power margin is available for use in RF optimization.

Other more cumbersome techniques can be used to fix coverage holes. Cell site antennas can be changed to higher gain varieties (narrower vertical or horizontal beamwidth) provide more signal strength in the desired area. Of course, increasing the antenna gain may fix one coverage problem, while at the same time creating many others. In some cases, re-orienting the an-tenna pointing azimuth may be useful for filling coverage holes in particular areas. Adjusting antenna downtilts at the serving sector may also allow more energy to be radiated in the vicinity of the coverage hole.

As a last resort, for PCS deployments an entirely new CDMA cell may be re-quired. Another option that is currently under investigation involves the use of low-cost CDMA repeaters to rebroadcast signals from existing cell sites, as is done today to fill in AMPS coverage holes.

10.1.2 Reverse Overload Control False AlarmUnder some operating conditions, the current reverse overload control algo-rithm can generate false alarms which inhibit call originations or soft hand-offs. The reverse overload algorithm uses estimates of the received signal strength relative to the background noise. In a real-world environment, the background noise will contain interference from many sources, including the following: in-band signals from other services; sidebands and spurious emissions from many sources (AMPS, TDMA, ESMR, paging, etc.); interfer-ence from industrial sources, machinery, microwave ovens, etc.; jamming sources and unauthorized transmitters.

Because of the difficulty of accurately measuring both the total received power and the background noise levels, it is possible for the reverse over-load control algorithm to be fooled into concluding the reverse link is over-loaded, when in fact there may be only light loading present. For the pur-poses of RF optimization testing, it is recommended that the reverse over-load control algorithm thresholds be set to their highest allowable transla-tion values. Setting high reverse overload thresholds will essentially dis-able the overload control algorithm for the purposes of field testing.

10.1.3 Paging or Access Channel Message FailureIn some cases, the paging and access channel performance of the CDMA system may not exactly match the traffic channel coverage. For example, the paging channel does not benefit from forward power control or from



soft handoff combining gain. If paging channel transmit powers are not set correctly, mobiles may be able to receive acceptable pilot and sync chan-nels, but may fail because of excessive paging message failures. In this case the paging channel digital gain setting can be adjusted upwards to al-low pages to be received.

A similar situation is present for the access channel on the reverse link. When a CDMA mobile transmits on the access channel, reverse closed-loop power control is not active; therefore the mobile must ‘guess’ at the appro-priate transmit power to use for access. The transmit power estimate made by the mobile is based on the received power combined with offset adjust-ments transmitted by the cell site. In some cases, if the offset adjustments are not adjusted properly, mobiles may not be able to access on the reverse link. In a more likely situation, the mobile may require a large number of access probes before being acknowledged by the base station.

Appropriate methods of testing paging and access channel performance during the RF optimization tests are being investigated. Automated call generators may be used to originated calls at periodic intervals to verify coverage of access and paging attempts.

10.2 Handoff FailureDue to the complexity of the handoff messaging process combined with the large number of handoffs per CDMA call, handoff failures are probably the most common reason for dropped calls. In order to understand the mecha-nisms responsible for CDMA call failures, it is necessary to be aware of Lu-cent Technologies’ implementation of the handoff call processing. Certain situations encountered in the field may cause the call processing responses to be too slow for mobiles to complete the required handoffs. As the base station processors become more heavily burdened, either due to traffic load or overhead functions, the response to soft handoff requests will be slowed.

Another important aspect of the handoff call processing is the method used to swap pilot signals into and out of the mobile’s active set. If a mobile in 3-way soft/softer handoff receives another strong pilot, with signal strength greater than one of the active pilots, then the mobile will request a swap operation. In the ideal case, the mobile would simultaneously be allowed to drop the weakest active pilot and add the new stronger pilot. The handoff call processing does not perform a swap operation in the manner just de-scribed. In fact, the handoff call processing does not perform a swap at all.

The current soft handoff algorithm responds as follows when a mobile re-quests a pilot swap while in 3-way handoff. First, the base station has the mobile drop the weakest pilot from the active set by going into 2-way hand-off. After the pilot drop operation is acknowledged, confirmed, and the neighbor list updated, the mobile is requested to make a new pilot strength



measurement. If the pilot strength measurement still requires that the mo-bile add the new pilot, the base station will process the add request and put the mobile into a 3-way connection. By performing the swap operation as a sequential drop then add, the entire process can take time to complete. During the waiting period before the operation is completed, it is possible for RF conditions to degrade to the point where the call may drop due to ex-cessive FER.

10.2.1 Excessive Number of Strong Pilot SignalsIn the current implementation, the CDMA mobile is capable of demodulat-ing signals from at most 3 serving sectors. If strong signals from more than 3 serving sectors are present, the additional signals will act as interference sources. Another consequence of a large number of strong pilots is an in-crease in the fraction of time the mobiles spend in 3-way soft/softer handoff. As mentioned in the introduction to this section, if the mobile is in 3-way handoff and requests a pilot swap, the current call processing algorithm will not directly perform the swap operation. Any geographical area where 3 or more strong pilots are present, may create situations where calls drop due to delayed handoff processing.

Another problem with geographical areas were many strong pilots exist in-volves the creation of extra interference. The quality of the signals received by the CDMA mobile are measured based on the pilot-to-interference ratios, where in this case the interference includes everything received by the mo-bile (i.e. signals plus noise). The more strong pilots there are in a given area, the higher the interference level will become. In other words, if many strong pilots exist in an area, the pilot-to-interference ratios for all of the pi-lots will be reduced. Therefore, it is always best to have one or two domi-nant servers in a given area, rather than three or more servers of equal strengths.

The first method of reducing pilot signal congestion is to reduce the trans-mit powers at the weaker serving sectors in the area. The idea is to create one or two dominant servers to cover the problem area, or at least to shift the problem area out of major traffic locations. Try reducing the transmit powers in 2 dB steps at the weakest sectors, checking to be certain that the coverage area of those sectors has not degraded to an unacceptable level. If sufficient transmit power margin is available, it may be possible to in-crease the transmit power at the desired dominant serving sectors. Other options include changing antenna azimuths, heights, downtilts and beamwidths to control the pilot coverage.

10.2.2 Unrecognized Neighbor SectorIf a CDMA mobile drops calls in an area where a strong server exists, the cause will often be attributable to omissions in the neighbor list. In some cases the problem could be due to search window sizes that are too narrow.



The current call processing algorithm allows 12 neighbor entries in the neighbor list for each sector. Because of the fact that CDMA systems oper-ate with unity frequency reuse, it is important that the neighbor list include all strong pilots the mobile is likely to encounter in a given area. With fre-quency reuse of one, there is very little margin for delayed handoffs, as might be typical in an AMPS system. Unfortunately, with a limit of 12 en-tries in the neighbor list for each sector, it may not be possible to list all likely servers.

In the current implementation, for the mobile to enter soft handoff with a particular sector, the candidate sector must be in the neighbor list. The CDMA mobile may occasionally report pilot signals not in the neighbor list, but these handoff requests will be ignored by the base station. Tuning of neighbor lists will be an iterative, trial-and-error approach based on mobile messaging log files as describedin Chapter 11. The basic approach is to ob-serve which strong pilots are being reported by the mobile based on the temporal analyzer screen on the mobile diagnostic monitor and based on the log files.

The traffic loading on the CDMA network will impact the observance of neighbor list related call drops. As the network load becomes light, inter-ference levels will be reduced, resulting in more soft/softer handoff activity. The result is that neighbor list problems may be more evident under light loading conditions.

10.3 Poor Voice Quality Forward Link

10.3.1 Inadequate Traffic Channel Signal StrengthThere are several reasons that forward link traffic channel performance could cause degraded voice quality. One important aspect of the forward link performance is the tremendous variability in signal-to-interference ra-tios required for a specific forward link FER (typically 1%). The required signal-to-noise ratio is a strong function of the mobile speed, multipath channel conditions, and soft handoff state. The required target signal-to-noise ratios can change by over 16 dB (factor of 40 times), based on the mo-bile’s conditions. The distribution of speeds of the mobiles can have a large effect on forward link performance; for example, during rush hour when many mobiles are moving at low speeds (5-15 km/hr), the forward link can be put under great stress. The relative performance of the forward link is an even greater issue with the 13.3 kbps vocoder than with the 8 kbps vocoder.

The operation of forward overload control can be responsible for perfor-mance degradations observed on the forward link. If the forward overload control threshold is exceeded, the algorithm will cap the forward transmit power to the mobile (i.e. allow them to power down but not power up). In



such a situation, particular mobiles may not be able to get enough transmit power to achieve the desired FER.

10.3.2 Intermodulation InterferenceIntermodulation interference is another source of potential problems. The most severe problem observed to date involves forward link interference from AMPS-only cells to CDMA mobiles, and similar problems may exist for PCS deployments when several service providers become operational. Techniques for alleviating this type of interference are currently being in-vestigated [7].

10.4 Poor Voice Quality Reverse LinkThere are a number of possible sources of reverse link voice quality degra-dations. The most frequent cause is improper balance between the forward and reverse links. If the forward link has more path loss margin than the reverse link, it is possible to get into situations where the mobile may not be able to complete the reverse link. The situation can be diagnosed by monitoring the mobile transmit power in the problem area; if the mobile transmits at or near the maximum value (+23 dBm = 200 mW for CDMA portables), then the problem could be due to imbalance.

Other reasons for reverse link quality problems can be tied to corruption of the reverse closed-loop power control. If the forward link is degraded, is possible for the mobile to misinterpret the power control information sent by the base station. In the worst case, the mobile would power down, when actually being requested to power up by the base station. In these condi-tions, the reverse link may degrade or drop altogether.

Another connection between forward and reverse link performance is through the mobile’s forward link fade detection mechanism. If the mobile detects 12 consecutive bad frames on the forward link, the mobile will cease transmission until 2 consecutive good frames are received. In this situation, bad forward link performance can cause muting of the reverse link.

11. Specialized CDMA Optimization Tools

This section describes several computer programs, ALERT, LABEL, BUILD, ORIG, and TERM that are designed to help speed up the process of CDMA RF optimization. ALERT generates alerts and is used to help identify trouble spots in the system and BUILD builds neighbor lists based on the pilots the mobile reports. LABEL is an ALERT companion tool and it is used to plot the location of the alerts generated by ALERT on maps generated by the DA Tool. ORIG and TERM will analyze origination and termination failures and will plot their locations.



ALERT analyzes npar files and issues a report, characterized by a list of alerts which identify problems that need to be resolved, such as neighbor list violations and weak pilots. When optimizing a system, the objective is to vary parameters such that the number of alerts is minimized. The most im-portant translations parameters that should be varied are BCR attenuation values and neighbor lists. In PCS markets, rather than in cellular markets, antenna orientations and downtilt angles are also important degrees of freedom. BUILD may be used to construct neighbor lists, and at the last stage of optimization, to reduce window sizes. Optimization of window sizes is especially important in CMI applications where window sizes tend to be very large.

11.1 ALERT Program

The following alerts are generated by the ALERT program:

1) weak pilot alert (WPA) 2) neighbor list alert (NLA)

The following warnings are generated by the ALERT program:

3) unexpected t_comp, t_add, t_drop, t_tdrop received by mobile 4) unexpected active, neighbor, and remaining set window sizes 5) a list of sectors that were never active 6) a neighbor or active search window size is too small7) undefined PN offset detected by mobile8) dropped call

When optimizing a system, the approach is to tackle the most significant alerts first (for example, very weak pilots or obvious neighbor list omis-sions). After BCR values are changed and neighbor lists are updated, the process is repeated again and further changes are made. The process is it-erative, and the goal is to reduce the total number of alerts at each step.

The figure of merit that should be minimized is the total number of alerts. Trying to optimize a system by only counting the number of dropped calls is not recommended because the number of dropped calls varies so much. By optimizing parameters such that the number of alerts is minimized, the drop call rate will reduce automatically. The DA Tool is used in conjunction with the ALERT program output to help identify what course of action needs to be taken. Plotting Ec/Io for only those pilots associated with alerts, rather than for all the pilots in the clus-



ter, allows one to quickly identify and diagnose the problem areas. Overall, the approach discussed in this section is consistent with the optimization procedure discussed in the other sections of this document.

11.1.1 Data collection proceduresBefore data is collected, verify that the non-volatile memory location N1m in the mobile is set to 12, or 9 if the customer prefers, using the nv_read command. Some mobiles come from the factory with this parameter set to 3. Increasing it from 3 to 12 will allow the mobile to be able to retransmit a message requiring an acknowledgment up to 12 times before aborting the call. With N1m=3 the mobile will retransmit a message only 3 times, result-ing in a higher drop call rate.

For the ALERT output to be as useful as possible, the Request for Pilot Mea-surement Interval field on the RC/V ECP form should be set to 5 seconds. A pilot measurement request order is issued and the mobile responds with a pilot strength measurement message every 5 sec. It is these measurements, along with those generated autonomously by the mobile, that the program uses to check for weak active pilots and neighbor list violations. Because setting this field to a nonzero value affects call processing, it is recom-mended that this field be set to 0 to turn off measurement requests for con-tract compliance testing and when the system is handed over to the cus-tomer after optimization.

During optimization, a full rate Markov call should be used for all data col-lection and the mobile DM log mask should be 0050C9F0 to log access channel messages, reverse link traffic channel messages, sync channel mes-sages, paging channel messages, forward link traffic channel messages, TA finger data, Markov frame rate data, TA searcher data, GPS data, and sparse AGC and closed loop power control data. When operating the mobile DM, Alt-L should never be used to toggle off data logging because this will result in gaps in the log file as far as the messaging between the base sta-tion and the mobile is concerned. Note that there is nothing detrimental about collecting data over the same stretch of road twice, and Alt-L should not be used to toggle data logging off simply because data has already been collected along a certain stretch of roadway.

Because optimization of a single area can lead to problems elsewhere, it is important to collect enough data so that a large enough area can be opti-mized. For example, if two highways intersect, one should collect data along both highways within several miles of the intersection and optimize that area rather than optimize one highway at a time.

Several mobiles can be used to log data simultaneously to speed up the data gathering process. The npar files should be concatenated to form a single input file for ALERT. The current version of the DA Tool does not allow mo-



bile DM log files from different mobiles to be processed simultaneously, but this restriction can be circumvented by copying mobile files to new files with a .999 extension, for example.

It is strongly recommended that ALERT and BUILD are run on files col-lected during unloaded conditions. Under unloaded conditions, the mobile will report more pilots. This will result in more neighbor list alerts. Also, it will be easier to diagnose multiple pilot problem areas because the sectors responsible for the interference in these areas, especially under loaded con-ditions, will be more apparent. If optimization is done under fully loaded conditions, the BUILD tool will generate neighbor lists that will be too short for semi-loaded conditions, because less pilots will have Ec/Io above t_add. Note also that optimizing an unloaded system will automatically lead to a system which is optimized for full even load.

For illustration purposes, a sample cluster is shown in Figure 1. Examples of alerts generated by ALERT are given below and the locations of these alerts are indicated in the figure.

1) Weak pilot alert ALERT issues a weak pilot alert whenever the strongest serving sector Ec/Io falls below a threshold, for example, -10 dB. If the unloaded system is op-timized to the point where the Ec/Io of the strongest serving sector is above -10 dB over most of the area, then the system will perform well under fully loaded conditions. Note that at the first stage of optimization, the threshold should be set to a value of -12 dB rather than a more aggressive threshold such as -10 dB because too many alerts will be generated if a threshold of -10 dB is used. This allows one to concentrate on the worst areas first. As the system is optimized, the threshold can be moved to a value of -10 dB.

There are two conditions which may lead to a weak pilot alert: i) there are one, two, or three weak pilots, and no other pilots , ii) there are four or more weak pilots (multiple pilot or self-interference problem).

i) One, two, or three weak pilots, and no other pilots

This condition points to an RF coverage hole if the mobile receive power is low or to external interference if the receive power is high. (In PCS bands, interference is typically from microwave transmissions and in cellular bands, interference is normally from cellular transmissions.) The power of the serving sectors should be increased by reducing BCR attenuation, if possible, while at the same time considering the effect of increased interfer-ence in another part of the system. It may be necessary to make additions



to neighbor lists after power is increased. Note that the program will flag the need for a new neighbor if it is needed during the following drive run. It is preferable to increase the power of a pilot which will not appear as inter-ference somewhere else in the system, if this option is available. In some cases, PCS antennas are not placed at the top of a tower and improved cov-erage may also be obtained by placing the antennas higher up on the tower. Antenna orientation is also an important degree of freedom, especially in PCS markets, and the orientation of antennas can be set so as to fill in cov-erage holes not predicted during the RF planning stage.

Example 1 (see Figure 1)[-13.0] WPA A66g(438)[-13.0] A73a(120)[-17.5] 20:26:38.207

This weak pilot alert (WPA) was generated because the mobile’s strongest server Ec/Io, -13.0 dB, was less than the threshold of -12 dB at time 20:26:38.207. Ec/Io values are enclosed in [] brackets and PN offsets are enclosed in () brackets. The first field in a WPA line corresponds to the largest Ec/Io of the pilots in the active set, and in this case it is -13.0 dB. The mobile was in two-way handoff with the gamma sector of cell 66 and the alpha sector of cell 73. The “A” indicates that both the pilots are active at the time stamp given. Check the location of the mobile using the DA Tool by opening a browser window in MapInfo to view the file named “ecio”, and click on the square which corresponds to the time stamp of the alert, and the corresponding location will be highlighted on the map. Figure 1 shows the location of this alert. View the individual Ec/Io of these two pilots and verify that the power of 66g can be increased by reducing BCR attenuation without creating interference somewhere else. ii) Four or more weak pilots

This condition is referred to as a multiple pilot problem. It is better to have two strong pilots rather than three or four weak pilots due to problems with slow swapping and self-interference. The solution to this problem is to power down less dominant sectors while powering up more significant pi-lots through the use of BCR attenuation. A dominant sector may also be cre-ated by pointing the main beam of one sector such that it serves the multi-ple pilot area more effectively. Note that reducing and increasing the digital gain of several pilots can solve the multiple pilot problem when there is no load but that the problem will still be present under loaded conditions be-cause the interference associated with interfering traffic signals will not be attenuated. Although there are several degrees of freedom here, it is impor-tant that the power of a sector which resulted in a weak pilot alert satisfy-ing condition i) above is not decreased because this will lead to a coverage hole. Note that neighbor lists will have to be changed, but that the program will flag this after these BCR changes are made on the RC/V terminal and the drive is re-run.



Example 2 (see Figure 1)[-11.5] WPA A55a(126)[-13.5] A55g(462)[-12.5] A65a(24)[-11.5] 54b(204)[-10.5]/200b 53b(282)[-15.0] 53g(450)[-12.5] 00:12:27.807

The mobile is in three-way handoff with sectors 55a, 55g, and 65a. “/” indi-cates that 54b and 200b both have the same PN offset. As far as the mobile is concerned, it reports the Ec/Io for PN offset 204, and pilots which use the same offset are not distinguished. In some systems, a PN offset may be used more than once as long as the sectors that use the same offset are sepa-rated far apart. From Figure 1, the mobile is clearly reporting 54b. Ec/Io for each of the six sectors should be viewed using the DA Tool. The power of the dominant servers should be increased while the power of the less domi-nant pilots should be decreased. If a pilot appears intermittently along a highway, then the BCR for this sector should be reduced because this sec-tor will not act like an ideal server and will thus be a interference source, especially if the mobile is in 3-way handoff with three other pilots. An ideal server along a stretch of highway is one that has strong and contiguous Ec/Io, not one with intermittently strong Ec/Io. 2) Neighbor list alert A neighbor list alert is issued whenever the mobile detects a pilot that is not in the neighbor list sent to it by the base station. There are three conditions which may lead to a neighbor list alert: i) accidental neighbor list omission, ii) a non-neighbor pilot appears at a weak level, iii) a pilot appears unex-pectedly.

i) Accidental neighbor list omission

This condition is easily solved by updating neighbor lists. The program re-ports all of the active pilots at the time that a remaining set pilot is re-ported. This pilot should be added to the neighbor lists of each of these ac-tive pilots.

Example 3 (see Figure 1)68a(78) [-3.0] NLA A95g(432)[-13.5]/57g A95b(264)[-19.0]/57b 00:30:06.147

The program generated a neighbor list alert (NLA) because the mobile re-ported seeing 68a with Ec/Io of -3.0 dB at time stamp 00:30:06.147 and this sector was not in the neighbor list of the active set. Because cell 57 is much closer to cell 68 than cell 95 is, it is obvious that the two serving sectors are 57g and 57b, rather than 95g and 95b. Normally, the mobile would handoff from 57g to 56g and then to 68a with no problem but it turns out that the antenna for 56g was defective, so that the mobile never handed off from



57g to 56g, resulting in the neighbor list alert. Because 56g is essentially not present, this alert is an example of a neighbor list omission. This prob-lem can be solved by adding 68a to the neighbor list of 57g because the neighbor list that gets sent to the mobile when it is in two-way handoff with 57g and 57b is the concatenation of the individual neighbor lists for 57g and 57b. Because neighbor lists should satisfy reciprocity, 57g should also be added to the neighbor list of 68a so that a neighbor list alert will not be generated if the mobile drives in the opposite direction. 68a should not be added to the neighbor list of 57b because the Ec/Io for 57b is low. Note that a WPA will also be generated for this time stamp, assuming a threshold of -12 dB.

ii) Weak non-neighbor pilot

If a NLA is issued under unloaded conditions and the Ec/Io of the non-neighbor pilot is very weak, the alert should be ignored because under loaded conditions, this pilot would not be added to the active set anyway.

Example 4 (see Figure 1)53g(450) [-14.5] NLA A54g(372)[-5.5] A41a(90)[-9.0] 23:42:45.552

This is an example of when a NLA is issued but no neighbor list changes should be made. Although the mobile reports seeing 53g at Ec/Io=-14.5 dB while it is in two-way handoff with 54g and 41a, the signal level is so weak that 53g should not be added to the neighbor list of either 54g or 41a. Un-der loaded conditions, the pilot Ec/Io for 53g will likely not even be re-ported by the mobile.

iii) A pilot appears unexpectedly

This condition may occur if the output power of a pilot is too high and it is extending beyond the first tier of cells. The solution to this problem is to de-crease power by changing the BCR attenuation. A drawback with reducing power is that you may be creating RF coverage holes within this cell. If this happens, antenna downtilting is required to improve coverage within the cell. Example 5 (see Figure 1)66a(102) [-12.0] NLA A67a(42)[-9.0] A55g(462)[-5.0] 23:36:13.252

The plot of Ec/Io for 66a indicates that this pilot shows up unexpectedly two tiers away. The alert was generated because 66a was not in the neighbor list for 67a or 55g. The BCR attenuation for 66a should be increased or the antennas should be downtilted.

Example 6 (see Figure 1)



57a(96) [-9.0] NLA A41g(426)[-11.5] 23:43:51.952

This is an example of when a NLA is issued but no neighbor list changes should be made. This neighbor list alert was generated because the BBA for 41b was offline during the drive test. Normally, 41b would be in the active set when the mobile is in the location corresponding to this time stamp and the NLA would not be generated because 57a is in the neighbor list of 41b.

Example 7 (see Figure 1)68g(414) [-9.0] NLA A56b(180)[-8.0] 00:12:15.788

This neighbor list alert was generated because the antennas for 68g were accidentally pointing in the wrong direction. A similar example would be one where the antenna cables are accidentally switched. A plot of the Ec/Io for 68a, 68b, and 68g would indicate these errors. Although a plot of Ec/Io for all the individual pilots should be the first step during optimization, and these types of errors would be found out at that time, antennas may be re-oriented or replaced during optimization by the service provider and neigh-bor list alerts may be generated after these changes.

3) Neighbor or active search window size is too small

Making window sizes too large slows down the search speed of the mobile as it looks for pilots. However, making them too small can have detrimental effects on performance. ALERT can check if window sizes may be too small. This function is especially important in CMI, or distributed antenna, appli-cations where window sizes have to be made large.

If the mobile reports a pilot in a pilot strength measurement message with a time offset that places the pilot within 10% of the edge of the mobile neigh-bor list search window, the program will issue a warning that the neighbor search window size may be too small. The danger in having a neighbor win-dow size that is too small is that the mobile will not be able to detect pilots for handoff.

The default value for the neighbor search window size is 7, or 40 chips, and this is normally large enough. However, in CMI or distributed antenna ap-plications, the neighbor search window size must normally be increased to around 9, or 80 chips.

Example 8 (see Figure 1)Warning D=39.6 chips 113b(144)/113b/113b, use srch_win_n>9 A113b(144)/113b/113b A53b(282) 19:28:41.040

In this example, sectors 113b and 53b are active. 113b has three distrib-uted antennas, or CMI’s, connected to it. The mobile measures 113b offset 39.6 chips from where it expects to measure it, and this offset is due both to



propagation delay through the air and through cable TV fiber and cable. The neighbor search window size being used by the mobile is 9, and 80 chips is only slightly larger than 2*39.6 chips, resulting in the warning. To be sure that the mobile detects the pilot soon enough, the neighbor search window size should be increased to 10.

If finger data is available in the npar file (available with npar ver. 5.058 and higher), the ALERT program will compute the multipath delay spread for each pilot in the active set. If multipath energy for any pilot in the active set falls within 10% of the edge of the mobile active search window, the pro-gram will issue a warning that the active search window size may be too small. The danger in having an active window size that is too small is that the mobile will not be able to use its RAKE receiver to collect all the avail-able multipath energy.

The default value for the active search window size is 7, or 40 chips, and this is normally large enough. However, in CMI or distributed antenna ap-plications, the active search window size normally has to be increased to around 9 or 10.

Example 9Warning D=45.75 chips (144), use srch_win_a>10 A113b(144)/113b/113b A53b(282) 19:28:17.435

In this example, the multipath delay spread for PN offset 144, correspond-ing to sector 113b, is 45.75 chips. The active window size is only 10, or 100 chips, and this delay spread is large relative to the window size. Therefore, the active window size should be increased to 11.

The following table of window sizes shows the relation between window size parameters sent to the mobile for active (win_a), neighbor (win_n), and re-maining set pilots (win_r) and their corresponding size in chips.

win_a/n/r 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15width(chips)

4 6 8 10 14 20 28 40 60 80 10 13 16 22 32 45

Table 1: window sizes

4) Unexpected t_comp, t_add, t_drop, t_tdrop These sector-specific parameters are sometimes changed to values other than the recommended values for testing purposes. During optimization, these values should be set to the recommended values. Data entry errors are flagged because the program issues a warning whenever non-recom-



mended values are sent to the mobile. These parameters are user-definable in the program. This error detection can be turned off if the parameters are not identical for all the sectors in the drive route.

Example 10Warning t_add 26, t_drop 30, t_comp 5, t_tdrop 2 not defaults 08:24:49.201

This warning was generated because checking for these handoff parame-ters was enabled (checktcomp=1 in the program header) and t_comp=2.5 dB (=5/2) was sent to the mobile rather than the expected value of 3 dB at time 08:24:49.201. A script should be run to make these parameters same sys-tem wide, rather than updating them one by one using the RC/V terminal. If these parameters are to be sector-specific, then checking should be dis-abled by setting checktcomp=0 in the program header.

5) Unexpected active, neighbor, and remaining set window sizes

During the initial stages of optimization, the remaining window size should not be set to the recommended value of 0. To increase the odds that the mo-bile identifies interfering pilots which are not in the neighbor list, the re-maining search window should be set to 7. After all of the neighbor lists have been updated and the interfering powers have been reduced at the end of the optimization, the remaining set window size should be set to the recommended value of 0. Data entry errors are flagged because the pro-gram verifies that the values sent to the mobile are expected values, and these parameters are user-definable in the program. This error detection can be turned off if the parameters are not identical for all the sectors in the drive route.

Example 11Warning srch_win_a 7, srch_win_n 7, srch_win_r 0 not defaults 08:20:59.921

This warning was generated because checking for window sizes was en-abled (checkwin=1 in the program header) and the search window size for the remaining set sent to the mobile was 0 rather than 7, the expected value. A script should be run to make all the window sizes the same system wide, rather than updating them one by one using the RC/V terminal. If these pa-rameters are to be sector-specific, then checking should be disabled by set-ting checkwin=0 in the program header.

6) List of sectors that were never active

The program outputs a list of sectors that were that never served the call. If one drove right by a sector on this list, then this points to a hardware prob-lem at this cell (for example, packet pipe, data link, BBA, GPS faults). Hard-ware may also be unexpectedly taken offline by the service provider. Weak



pilot alerts or neighbor list alerts may be due to offline sectors. Because the mobile logs only PN offsets, rather than actual sectors, there is no guaran-tee that all inactive sectors will be on this list if PN offsets are reused be-cause the program searches through the npar file for offsets that are never in the active set.

Example 12

The following sectors were never active.66b 68b 71b 95a 38a 38b 38g 41a 41g 52a 52b 52g 57a 96a 96b 96g

7) Undefined PN offset detected by mobile

For every alert that is generated, ALERT tries to identify the PN offsets that are reported by the mobile by looking in cells.txt and matching PN offsets with cell number and face. If ALERT cannot find a particular PN offset in cells.txt, a warning will be issued. The usual cause for this warning is an in-complete cells.txt file. The cells.txt file should contain a complete list of all the cells and PN offsets that the mobile is expected to measure. Also, make sure that every row in the cells.txt file has the correct number of fields. Note that the mobile DM file dm_cell.nam should not be in the same directory as npar.exe, because the npar output file will contain the sector names specified in this file rather than the PN offsets as ALERT expects.

Example 13

Can't find sector 126 in cells.txt. Verify cells.txt has this PN offset. Ver-ify dm_cell.nam is not in same directory as npar.exe.

8) Dropped call

If a call is dropped without a release order having been sent on either the forward or reverse link, for example, by pressing the “end” key on the mo-bile or hanging up a landline phone, a drop call warning will be issued by ALERT. In some cases, drop calls may occur repeatedly in certain areas and keeping track of them is needed to troubleshoot these problem areas. Note that if a drop call occurs because of a weak RF forward link, WPA’s will be generated just prior to the drop call warning. For more detailed drop call analysis, the npar file should be examined.

Example 14

DROP call 21:10:45.002



Figure 1: Location of Alerts

2

4

6

8

5

7

3

1

56

65

66

67

68

70

71

73 78

95

41

52

53 113 113 11354

5557

11.1.2 Running ALERT

The program header is shown below. The alert.awk file can be edited to change the user-definable parameters. ########## user-definable parameters ##############################pilotinc=6; # each market has its own pilot PN increment, eg. 6,10tcomp=6; tadd=24; tdrop=30; ttdrop=2; #defaults to check, can be disabled below with checktcomp=0wina=7; winn=7; winr=7; #defaults to check, can be disabled below with checkwin=0weakvalue=-12; # weak pilot Ec/Io alert thresholdchecktcomp=1; #either 0 or 1, 0 if don't want this checking for defaults donecheckwin=1; #either 0 or 1, 0 if don't want this checking for defaults donecheckwinna=1; #either 0 or 1, 0 if don't want this checking donewinthresh=0.9; #range [0,1]; if checkwinna=1, then issue warning if neighbor or active window size margin is less than (1-winthresh)*100 percent###################################################################

ALERT Output Summary

The ALERT program outputs the total number of the alerts generated, the list of parameters checked, and a list of the mobile files analyzed.

Example



ALERT SUMMARY-------------Weak pilot alerts[-10.0]: 47Neighbor list alerts : 6Total alerts : 43

HO parameters, checking enabled: t_comp=6, t_add=24, t_drop=30, t_tdrop=2Window sizes, checking enabled: win_a=7, win_n=9, win_r=0Active and neighbor window sizes, checking for sufficient widths enabled.

Mobile files: m1706079.737, m1706349.737, m1706555.736

To run the ALERT program on a PC, have the path set to where awkl.exe ex-ists. The files cells.txt, the same file that is used by the DA Tool, and alert.awk must reside in the directory from which you run the alert.awk program. From the DOS prompt type:

>awkl -f alert.awk mtotal.par > mtotal.alr

The input npar file is mtotal.par and the output file mtotal.alr contains the list of alerts. The input file is created by concatenating several npar files using the >> DOS operator. Although ALERT does not require time stamps to be in chronological order, it is convenient to concatenate files in order. The DOS dir /on command will display the mobile files in order.

Note that the newest versions of npar output finger and searcher data. Be-cause npar output files tend to be large when finger and searcher data is present, it is recommended that the “nmta” and “nmfing” options in the npar command line are used to turn off finger and searcher data output. If active search window sizes are being optimized, that is, they are being re-duced, then finger data output should not be turned off because ALERT uses this finger data to verify that the active search window size is large enough. In this case only the “nmta” command line option should be used.

Example

>npar nmta nmfing m1706079.737 >> mtotal.par>npar nmta nmfing m1706349.737 >> mtotal.par>npar nmta nmfing m1706555.736 >> mtotal.par

Note that files from several different mobiles may be concatenated. In the above example, two different mobiles were used to collect three files. Note that old versions of npar do not require the “nmta” and “nmfing” command line options because they do not output finger and searcher data.

11.2 LABEL ProgramLabel is an awk program that is used to plot the locations of the alerts and warnings generated by ALERT on the DA Tool Ec/Io plot. LABEL associates each alert or warning generated by ALERT with a geographical point in the



ecio.amp file using the time stamp issued for each alert or warning. The alerts and warnings are all individually numbered and it is this identifier that gets plotted beside the corresponding dot in the Ec/Io plot. LABEL is used to generate a new ecio.amp file which is identical to that generated by the DA Tool except that a column, consisting of alert numbers, is added. This col-umn is then added as a separate layer to the usual Ec/Io plot.

To run LABEL, go to the \out directory and rename the ecio.amp file to ecioold.amp. Then copy mtotal.alr and label.awk into this directory. From this direc-tory, execute the following command,

\awkl -f label.awk ecioold.amp > ecio.amp

The ecio.amp file that gets created is identical to ecioold.amp except that it has an extra column. Bring up the Ec/Io plot in MapInfo by opening a workspace which opens the ecio.amp file or by choosing the Ec/Io plot from within the DA Tool. The alert number is added as a layer to the Ec/Io plot from within MapInfo by choosing the Map menu option, then the Layer Control menu option, checking the label column for the ecio layer, then hitting the Layer button, selecting ALERTNUM as the label, and then choosing top right cor-ner anchoring and bold letter style. The alert number layer can be turned off if Ec/Io plots without alert numbers are to be given to the customer.

Note that in order for LABEL to function properly, the same ordering of mo-bile files should be used when specifying mobile files in the DA Tool and when creating mtotal.alr. Mobile files that are collected earlier in time should be processed by npar first, so that all of the data in mtotal.par and mto-tal.alr is in chronological order. This same ordering of files should be used when specifying files for the DA Tool. That is, when creating a new data set, add mobile files to be processed by the DA Tool in chronological order. Note that the DA Tool shows the mobile files available for adding in alphabetical order and not in chronological order. These two orderings will be different if the files belong to different months.

11.3 BUILD Program

11.3.1 Building Neighbor ListsBUILD can be used to generate the neighbor lists for all the sectors. These neighbor lists should be compared to those in the RC/V FCI forms and addi-tions should be made if necessary.

During optimization, because BCR values are changed and antennas down-tilted or reoriented, neighbor lists should be updated to reflect the new con-ditions using ALERT. After the system has been optimized, the system can



be driven extensively and the BUILD program can be used to trim neighbor lists.

The BUILD program goes through the input npar file and for a given pilot strength measurement message (PSMM), each pilot reported is added to the neighbor list of every other pilot in that message. The process is re-peated for all the PSMM’s in the mobile file and the program outputs neigh-bor lists for all the sectors after it has finished going through the input npar file. Note that this algorithm generates neighbor lists which are reciprocal, for example, if A is a neighbor of B, then B is a neighbor of A.

Whenever making neighbor list changes, using BUILD or ALERT, it is im-portant to verify the validity of these changes by consulting the Ec/Io by off-set plots for the sectors involved in the neighbor list change. For example, BUILD will report that A should be a neighbor of B if both are reported in a PSMM but if the PN by offset plots for sectors A and B show that they over-lap for very short instances only, then these should not be neighbors, espe-cially in multiple-pilot areas. If the mobile is in three-way handoff, and if a pilot that is not in the active set appears T_comp dB above a pilot in the ac-tive set, the mobile will be directed into two-way handoff before it is di-rected to add the new pilot into the active set and there will be performance degradation due to the loss of a third leg of diversity. This performance loss is not justified if the new pilot is added to the active set for only a brief time.

The BUILD program is executed from the DOS prompt as follows:

>awkl -f build.awk mtotal.par > mtotal.bld

The mtotal.par file is created by concatenating individual npar files, as dis-cussed above.

Example

The following is sample output from the BUILD program. For a given row, all of the entries corresponding to the first column are the neighbors of that pilot. For example, the neighbors of 78g are 66b, 73b, 78a, and 73a. Be-cause the mobile logs PN offsets rather than uniquely identifying a pilot, if PN offsets are reused, one needs to look at a map of the cell site locations to decide how to interpret these suggested lists. For instance, 95g has the same PN offset as 57g, but from looking at a map, one can tell that 71g, 71a, 65a, and 65b are neighbors of 95g, and 52b is a neighbor of 57g.

78g(366) 66b(270) 73b(288) 78a(30) 73a(120) 66b(270) 78g(366) 73b(288) 78a(30) 73a(120) 71b(174) 66a(102) 71g(342) 65b(192) 67b(210) 73b(288) 78g(366) 66b(270) 78a(30) 73a(120) 71b(174) 78a(30) 78g(366) 66b(270) 73b(288) 73a(120) 71b(174) 66a(102) 71g(342) 65b(192) 73a(120) 73b(288) 78g(366) 66b(270) 78a(30) 71b(174) 66a(102) 71g(342) 66g(438) 73g(456) 71b(174) 66b(270) 73a(120) 73b(288) 78a(30) 66a(102) 71g(342) 65b(192) 66a(102) 66b(270) 71b(174) 78a(30) 73a(120) 71g(342) 65b(192) 65a(24) 53b(282) 65g(360)



71g(342) 71b(174) 73a(120) 66a(102) 66b(270) 78a(30) 65b(192) 71a(6) 65a(24) 95g(432)/57g65b(192) 71b(174) 71g(342) 66b(270) 66a(102) 71a(6) 65a(24) 53b(282) 67a(42) 95g(432)/57g71a(6) 71g(342) 65a(24) 65b(192) 66a(102) 67a(42) 53b(282) 95g(432)/57g65a(24) 71g(342) 71a(6) 65b(192) 66a(102) 53b(282) 67a(42) 55b(294) 65g(360) 95g(432)/57g53b(282) 65a(24) 65b(192) 67a(42) 71g(342) 71a(6) 66a(102) 113b(144)67a(42) 65a(24) 65b(192) 71g(342) 65g(360) 67b(210) 65g(360) 65a(24) 65b(192) 67a(42) 67b(210) 71g(342) 67b(210) 67a(42) 65g(360) 65b(192) 71g(342) 66b(270) 66a(102) 66g(438) 66a(102) 73a(120) 66b(270) 95g(432)/57g 71g(342) 71a(6) 65a(24) 65b(192) 52b(282) 113b(144) 53b(282)

11.3.2 Optimizing window sizes

The default active and neighbor set search window size is 7, or 40 chips. This is normally adequate. However, in CMI applications, the active search window size usually has to be much larger for the mobile’s RAKE receiver to be able to combine all available multipath energy and the neighbor search window size for the CMI sectors and the sectors surrounding the CMI’s usually have to be much larger so that the mobile can handoff be-tween sectors properly. The drawback with having window sizes that are too large is that the mobile wastes time searching for pilots to handoff to and for multipath energy to combine.

BUILD can be used to optimize window sizes. We would like to use window sizes which are just large enough for the mobile to be able to collect all available multipath energy and to be able to detect pilots for handoff. Be-fore drive testing, the window sizes are made larger than one expects the mobile to need. In CMI applications, search window sizes are normally set between 9 and 11, depending on cell radii and on the roundtrip delay mea-surements obtained from RF call trace. The active window size for a sector with CMI’s should be set to the maximum differential delay of the CMI’s, obtained from RF call trace roundtrip measurements, because an approxi-mate upper bound on the number of multipath components that the mobile will combine is the number of CMI’s. From the npar file obtained, BUILD will find the maximum window sizes needed for every sector. The window sizes should then be reduced so that they are just larger than the maximum delays reported by BUILD.

Example

ref PN=113b(144)/113b/113b, offset=45 chips 19:28:16.800, suggest win_n>90 chips, srch_win_n=11

In this example, the neighbor search window is 11, the mobile derives its timing reference from PN offset 144, the maximum pilot offset observed is 45 chips, and it occurs at time 19:28:16.800.The neighbor search window size should be at least 2*45=90 chips. Therefore, srch_win_n should be re-duced from 11 to 10, using Table 1.

Example



113b(144)/113b/113b D=60 chips 19:26:49.583, suggest win_a > 120 chips, srch_win_a=12

In this example, the active search window size is 12, the maximum delay spread for PN offset 144 occurs at 19:26:49.583, and it is 60 chips. The ac-tive window size should be at least 2*60=120 chips. Therefore, srch_win_a should be reduced from 12 to 11, using Table 1.

11.4 ORIG/TERM Programs for Troubleshooting Origination/Termination Failures

Two tools have been developed to help troubleshoot origination and termi-nation failures. ORIG204.AWK flags origination failures, and plots the loca-tion of the failures, and TERM204.AWK flags termination failures, and plots their location. The location of origination and termination successes can also be plotted by selecting the appropriate option in the program headers.

The two tools are similar. They are AWK programs and the syntax for execu-tion is identical to that for ALERT, BUILD, and LABEL. To execute ORIG, for example, issue the following DOS command:

>awkl -f orig204.awk mfile.par > mfile.org

Below is sample, abbreviated, output for ORIG.

11.4.1 Sample Orig Output

Successful orig 00:05:17.545, probes=1, 95g(432)/57g Unsuccessful orig 00:05:48.665, probes=3, msom=1, cass=1, forw=0, scm=0,

sccm=0, 71a(6) Unsuccessful orig 00:05:58.025, probes=4, msom=1, cass=0, forw=0, scm=0,

sccm=0, 22a(12) Successful orig 00:06:21.945, probes=5, 71a(6)

Total orig attempts=4, total successes=2, total failures=2, total reorder=0Origination failure rate=50.0 percent.

lon, lat, origresult, time, timeoffail-82.18816 , 28.02763 , 1, 00:05:17.545, -82.22634 , 28.02662 , 0, 00:05:48.665, 00:05:48-82.22933 , 28.02614 , 0, 00:05:58.025, 00:05:58-82.23793 , 28.01632 , 1, 00:06:21.945,



If ecio.amp generated by DAT (old version only for now) exists in the cur-rent directory as the concatenated npar’d file mfile.par, ORIG will find the longitude and latitude for each origination failure. It will also find the longi-tude and latitude for each origination success if the plotorigsuccess parame-ter in the program header is set to 1. The timeoffail column should be used as a layer within MapInfo to label the origination failures. The longitude and latitude information should be cut and pasted within Word and saved as a text file to be imported into MapInfo.

When an origination attempt is made, ORIG will identify which sector the mobile attempted to originate on as well as the total number of probes needed by the mobile. If the attempt fails, ORIG will identify the point in the origination process at which the failure occurred. For the first origination failure in the example above, the mobile received a Mobile Station Order Message (msom=1) and a Channel Assignment Message (cass=1), but it did not demodulate a forward link message (forw=0), nor did it receive a Ser-vice Connect Message (scm=0) on the forward link, nor did it send out a Service Connect Complete Message (sccm=0).

If SEND is pressed too quickly after pressing END, the mobile will get a fast busy, or a reorder order. ORIG filters these out and does not flag these orig-ination attempts as failures.

Note that not all origination or termination failures get logged by the mo-bile. In particular, if SEND is pressed while the mobile is receiving bad pag-ing messages, the origination attempt will not get logged. Also, if the mobile is in a coverage hole and it does not receive a page, this termination failure will not be logged by the mobile.

11.4.2 Causes for Origination and Termination Fail-ures

A very common reason for origination or termination failures is that the mo-bile loses lock on the pilot belonging to the sector it attempted to originate or terminate on halfway through the origination or termination setup process. The mobile will often abort the probe sequence before reaching the maximum allowable number of probes for this reason. This usually hap-pens in RF coverage limited areas or areas with severe multiple-pilot prob-lems.

It is very important that neighbor lists are complete to improve the chances that the mobile is attempting to originate or terminate on the best possible



sector. If neighbor lists are incomplete, the mobile may not be locked to the best pilot available. Neighbor lists may be incomplete even though no NLA’s are reported by ALERT because a mobile is usually in two or three-way handoff when a call is up and the resulting extended neighbor list may be complete, yet when the mobile is in idle mode it uses the neighbor list that corresponds to a single pilot and it is this shorter neighbor list which may be incomplete. When an origination or termination failure occurs, check that the neighbor lists of the sectors that the mobile attempted to originate or terminate on at the time of failure are complete. In the above example, you would check that 95g(432)/57g, 71a, and 22a are on each others neigh-bor lists. If the maximum number of probe sequences is set to 2 and the number of probes per sequence is set to 5 in the translations, the maximum number of probes that will be sent by the mobile is 10. Therefore, if origination fail-ures occur and the mobile sent 10 probes, the number of probes per se-quence should be increased from 5 to 10 in the translations.

12. Antenna Downtilt ProceduresAntenna downtilting is one of the performance tuning tools for use in CDMA optimization. For several reasons, antenna downtilting must be considered separately from the other parameter adjustments made during the intera-tive optimization process. First, antenna downtilting is dependent upon the antenna type and cell layouts specific to each cluster. Second, downtilting involves physical changes to the antenna as performed by a tower crew; the additional costs and delays associated with downtilting warrant special at-tention. Third, downtilting involves complex tradeoffs to balance interfer-ence and coverage; for downtilting to be effective, it must be applied appro-priately. This section defines the procedures to be used for antenna down-tilting, along with providing examples from an actual cluster.

When applied judiciously, antenna downtilt is a valuable optimization tool. The objective of downtilting is to reduce interference far from the sector, without compromising close-in performance. Downtilting controls over-shoot by directing main beam of antenna slightly downward, rather than at the horizon; it also concentrates energy from the downtilted sector into the desired coverage area close-in to the cell.

12.1 Entrance CriteriaPerform a baseline drive of the coverage area in the cluster with BCR atten-uation set at 8 without OCNS loading. Plot the following:1. Ec/Io of strongest server for all drive test routes.



2. Number of pilots above -15 dB for all drive test routes.3. Ec/Io by PN offset for each sector in the cluster for all drive test routes.4. Mobile received power for all drive test routes.5. Mobile transmit power for all drive test routes.

Identify the following:1. All areas where Ec/Io of strongest server is less than -11 dB. If in an area

Ec/Io of the strongest server when unloaded is less than -11 dB, it’s likely to be a drop call area when the system is loaded.

2. All areas where number of pilots above -15 dB is more than 3. The mo-bile uses up to three different pilots to serve the call at a time. If more than three strong pilots are present at the same time, the ones that are not used to serve the call become interference and will degrade the per-formance.

3. All the pilots (sectors) that appear in areas identified in steps 1 & 2 and record their Ec/Io level. If a pilot appears in the area for a short period of time and there are other pilots that cover the area, removing the pilot from the area will reduce interference and improve performance.

4. All areas where mobile received power is less than:If # of Pilots is Then: Mobile received power

(dBm)1 -1002 -973 -954 -945 -93

5. All areas where mobile transmit power are higher than 20 dBm.

The purpose is to identify the weak coverage areas on the forward and re-verse links, and the multiple pilots areas that exist in the cluster. Multiple pilot areas are areas where 4 or more signals are present with nearly equal strength, and aggregate interference levels cause signal-to-interference ra-tios of all servers to be reduced. In some cases, no dominant server exists. Rapid shadow fading can cause the best set of pilots to change quickly, therefore causing call drops.

Use combination of neighbor list adjustment, BCR attenuation, antenna az-imuth orientation, and handoff parameters tuning to optimize the system. For detailed optimization procedures, please refer to the other sections of this document.

For each multiple pilots area identified above, adjust the BCR of the sectors involved to create a dominant server. Load the system with OCNS and at-tenuators and re-drive the areas involved after each adjustment to verify if the goals are achieved and no new coverage problems are created.



If a particular pilot appears for only a short period of time, it cannot be used for handoff but causes interference. Increase the BCR attenuation of the associated sector in 2 dB steps may remove the interference caused by the pilot.

Choose BCR adjustment candidate based on distance between the cover-age area and the cell and handoff considerations.

Reiterate the BCR adjustments until all values are stabilized. At this stage, the problems are either fixed or cannot be solved by BCR adjustments alone.

12.2 Identification of Candidate SectorsThe following factors are considered in determining if the sector needs to be downtilted:1. BCR attenuation. Examine the pilot coverage map of the sector. If the

BCR attenuation of a particular sector must be increased by 4 dB or more to reduce or eliminate the interference caused by the sector, the sector is identified as a possible candidate for antenna downtilt.

2. Cell antenna height and terrain height. If the cell antenna is high and can cause overshoot into tier two neighbor cells, the sector is identified as a possible candidate for antenna downtilt.

3. Terrain data. If a sector is covering a low elevation region near the cell, downtilt its antenna may both eliminate the interference in areas far from the cell and increase the coverage in areas near the cell.

4. Separation between cells. If a sector is close to the next cell, downtilting its antenna may both eliminate the interference in areas far from the cell and increase the coverage in areas near the cell.

The purpose of downtilt is to control internal interference. As a rule, try to avoid downtilting the sectors that point to fringes of the cluster.

A check list that was used to compile all information for downtilt sector se-lection is included as an example:

Cluster Antenna Downtilt Checklist(08/07/96)

Cell-Sector

BCR(1)

Att.(dB)

Ant./Ter.Height (feet)

Terrain Feature

(2)

2R(miles)

SecondCurve

(degree)

FirstCurve

(degree)

ProposedDown-tilt(degree)

Remarks

139-B 12 150/45 --- 3.3 2.0 3.2 2 High cell, overshoots tier 1 neighbor, poor coverage near cell.

139-G 12 150/45 -^^ 3.5 0 Facing outside of cluster.240-B 12 140/45 -- 3.5 0 No overshooting problem.241-B 14 120/45 --^ 3.2 1.6 3.2 2 Overshoots Farley and 102.152-B 12 100/45 -^- 2.1 TBD Possible cell transmit path problem. Needs checking.353-G 16 140/45 -- 1.8 4.1 3.9 3 Neighbor cell extremely close, cell location off grid, high

cell antenna, BCR attenuation at 16.



355-B 16 117/30 -^ 2.5 TBD Overshoots I40, BCR attenuation 16. Sector coverage map suggests possible transmit path problem.

256-A 12 130/30 --^ 2.1 0 No overshooting problem.256-B 12 130/30 -- 3.0 2.3 3.3 3 Needs it to cover 102, but overshoots on I40. Will benefit

from downtilt + transmit power increase.357-A 16 120/60 - 3.2 2.0 3.3 3 BCR at 16. Covering depressed terrain357-B 16 120/60 - 2.5 2.6 3.4 3 Overshoots on 102 with BCR set 16.165-G 16 150/75 -- 2.5 3.4 3.6 4 Overshoots on I40 & I80. Very high cell, BCR at 16.266-A 12 140/75 - 3.4 3.1 3.5 4 Very high cell, overshoots way into the second tier neigh-

bor.167-A 12 150/45 -- 2.7 2.9 3.5 4 High cell, overshoots onto 102 & I80, I40 & McBryde.

Covering depressed terrain nearby.167-B 14 150/45 --^ 2.4 3.3 3.6 3 High cell, overshoots onto I40 & McBryde. BCR at 14368-A 14 120/30 -^ 2.1 3.1 3.5 3 BCR at 14. Overshoots on I40. Neighbor cell close.368-B 14 120/30 - 3.4 1.9 3.2 2 BCR at 14. Overshoot on I40.370-A 16 140/15 --^ 3.4 1.8 3.2 3 Overshoots onto elevated portion of I40 with BCR 16.370-G 12 140/15 --- 0 Facing outside of cluster.173-A 14 140/90 -- 2.3 2.6 3.4 2 BCR at 14. Overshoots on Malcolm, close to cell 368.

(1) BCR = 8 dB is full power (8W), and BCR = 12 dB is 4 dB below full power.(2) Terrain elevation of the area facing the sector relative to the elevation of the cell location in the near-mid-far regions. (- = level ; ^= elevated; = de-pressed)

12.3 Calculation of Downtilt AngleAfter the downtilting candidate sectors are identified, degree of downtilt on each sector should be determined jointly the engineering teams. The fol-lowing factors should be considered when determining the degree of down-tilt:1. Sector BCR attenuation;2. Sector pilot coverage plot;3. Cell antenna height and cell site terrain elevation;4. Terrain topology in the sector coverage area;5. Distance to the neighbor cell in the sector face;6. Antenna pattern.

The last four factors can be combined into a pair of simple formulas to guide downtilt selection. Using different engineering considerations, two different downtilts can be derived. The first one reduces the interference at the base of the neighbor cell (r= 2R) by 3 dB. The antenna downtilt is:

(FIRST FORMULA)

where is the downtilt angle in degree, R is the radius of the cell, h is the antenna height, and VBW is the vertical beam width of the antenna.

To preserve the coverage in the fringe of the cell (r = R), the second down-tilt angle formula is:

(SECOND FORMULA)

A simple Excel spread sheet is written to calculate the downtilts obtained from the two formulas. An example is included in the following figure.



The following chart plots the downtilt angle as a function of the R/h ratio us-ing either formula.

In the plot, the solid line is the first downtilt formula and the dashed line is the second formula. The triangles represent the example downtilts shown in the previous table. As the plots show, for small R/h (small cell radius and/or high antenna), the second formula predicts larger downtilt angle; while for large R/h (large cell radius and/or low antenna), the second for-mula predicts smaller downtilt angle. The first formula for downtilt angle prediction shows less dependence on the R/h ratio. The two curves inter-sect at approximately R/h = 30.

For an example cluster, average cell radii are 1.5 km in urban area and 3 km in suburban area, average cell antenna height is 140 ft. Typical R/h ra-tio is 35 in urban area and 70 in suburban area. As shown by the chart, the



first formula predicts downtilt angle slightly higher than 3 degrees, while the second formula predicts around 3 degrees tilt for urban cells and around 2 degrees tilt for suburban cells.

Downtilt angles are typically specified in whole degrees increments; the current quality control procedure for antenna downtilt specifies that the tilt angle to be measured to within 0.1 degree. If required, it will be possible to specify the tilt angle in increments of 0.5 degree to provide a finer adjust-ment. With the narrow vertical beamwidth antennas typically associated with PCS deployments, it is appropriate to affort greater accuracy in the downtilt adjustment than would usually be the case for cellular systems with lower gain antennas.

Notice that if the sector is covering depressed terrain, the effective antenna height needs to take the terrain elevation difference into account, and should be the antenna height plus the difference in the terrain elevation of the cell location and the coverage area. This tends to reduce the R/h ratio and bring downtilt angles predicted by the two formulae closer to each other.

If specified by the field engineers, the proposed downtilt angles can be checked by a propagation simulation tool to insure that the interference is reduced and no coverage is lost.

12.4 Exit CriteriaAfter the required down-tilts are performed, re-drive the system.1. Perform a baseline drive with BCR at 8 and no OCNS, to compare with

the baseline measurement without down-tilt.2. Set the BCRs to the immediate pre-downtilt values and re-drive the sys-

tem. Compare with the pre-downtilt drive data to observe the effect of downtilt.

3. Increase the cell transmit power by decreasing the BCR attenuation of the sectors that were downtilted, and verify that the interference from them are still under control. Decrease the BCR attenuation by 2-4 dB de-pending on the down-tilt angle used. The following table lists the reduc-tion of antenna gain on the horizon as a function of downtilt. It can be used as a guide for BCR attenuation adjustments.

Downtilt Angle (de-gree)

Gain Reduction (dB)

0 01 0.32 1.43 3.24 5.0



Adjustments in BCR should maximize the transmit power that can be al-lowed, for specific interference considerations. Transmit power should be made as large as possible to maximize near cell coverage.

13. Risks and ContingenciesTo be defined on a per-customer basis.



14. Schedule

ESTIMATED TIME DURATIONS FOR CLUSTER TESTING PER CLUSTER:

Cell Site Configurations and Transla-tions

days

Spectral Monitoring TestMeasurement daysData Analysis days

Unloaded Coverage TestMeasurement daysData Analysis days

TOTAL DURATION PER CLUSTER days

ESTIMATED TIME DURATION FOR SYSTEM-WIDE OPTIMIZATION TESTS:

Cell Site Configurations and Transla-tions

days

Pilot Channel Coverage TestMeasurement daysData Analysis days

TOTAL DURATION PER CLUSTER days

15. AcknowledgmentsThe optimization procedure was developed and revised based on numerous discussions with Pat Patankar, Steve Schuette, Wei Chung Peng, Neil Bern-stein, Victor DaSilva, Tom Linnemeyer, Yingjie Li, and Joe Kurtz. Neil Bern-stein, Frank Slojkowski, and Terry Stevens provided detailed reviews of early drafts and suggested a number of important additions to the optimiza-tion procedures. Tien Hou, John Marione, Martin Meyers, and Wei Chung Peng provided valuable comments on the pre-cluster test plan.

The FOA/CTSO field teams have significantly improved the optimization plan by contributing their real world implementation expertise; the contri-butions of Chuck Rehor, Melvin Harrison, Gina Shih, Jim Sayles, Joe Clemente, Scott Semon, Ron Kapchak, and Loi Vu are particularly appreci-ated. Many people in Whippany, including Bill Clegg, Joel Williams, Steven Shio, and George Elmore provided outstanding support for the field test ef-forts used to refine the procedures. Michael Craig and Suren Talla pro-vided round-the-clock software development expertise for the Lucent Data Analysis Tool during the field tests. Susan Bernstein and Hsien-ho Lee cre-ated CE4 prediction plots for the test clusters. In addition, Susan Bernstein



performed an extremely useful analysis of the attenuator loading method. Victor DaSilva developed, tested, and refined the ALERT and BUILD scripts which automate the optimization process, greatly speeding up iterative drive testing.

16. References[1] A Translation Application Note for CDMA Forward Link Transmit

Path, Y. Li, Lucent Technologies Engineering Memo, February 22, 1996.

[2] A Translation Application Note for CDMA Reverse Link Overload Control, Y. Li, Lucent Technologies Engineering Memo, February 22, 1996.

[3] A Translation Application Note for CDMA Power Control, Y. Li and R. K. Lam, Lucent Technologies Engineering Memo, February 8, 1996.

[4] A Translation Application Note for CDMA Handoff, Y. Li, Lucent Technologies Engineering Memo, February 8, 1996.

[6] Operation Notes for CDMA Forward Link Orthogonal Channel Noise Simulator (OCNS), M. J. Feuerstein, Lucent Technologies Engi-neering Memo, December 10, 1995.

[7] On CDMA Mobile Intermodulation: Preliminary Field Test Re-sults, M. J. Feuerstein, J. Kurtz, Y. Li, X. Wang, J. Williams, Lucent Tech-nologies Engineering Memo, October 6, 1995.

[8] Lucent Technologies CDMA RF Engineering Guidelines, Revision 2, August 1995.

[9] CDMA Cluster Optimization Procedures for Antenna Downtilt Re-port, M. J. Feuerstein and T. A. Stevens, Lucent Technologies, June 18, 1996.


Date post:	18-Apr-2015
Category:	Documents
Upload:	merlene-perry
View:	112 times
Download:	0 times

CDMA 1.9 GHz Optimization Procedures

Documents