Vous êtes sur la page 1sur 85

3G1x RF Optimization Procedures and Guidelines for PCS and Cellular CDMA Systems

Version 1.0

Dec 2001

Prepared by
Devesh Patel CDMA RF Optimization and Applications Group Lucent Technologies, Bell Laboratories Whippany, New Jersey

Version 1.0

Lucent Technologies Proprietary Do not distribute outside the company

Chapter 1: RF Optimization ........................................................................................................................ 4 1-1 Introduction..................................................................................................................................... 4 1-2 A high-level view of 3G1x optimization procedures ...................................................................... 4 1-2.1 System Preparation Phases...................................................................................................... 5 1-2.1.1 Spectral Testing............................................................................................................... 5 1-2.1.2 System Pre-Test .............................................................................................................. 5 1-2.1.3 Sector Testing ................................................................................................................. 5 1-2.2 RF Optimization Test phases .................................................................................................. 6 1-2.2.1 Cluster Testing Unloaded and Loaded coverage tests.................................................. 6 1-2.2.2 System-wide Testing....................................................................................................... 7 Chapter 2: Cold Start of a 3G1x System..................................................................................................... 8 2-1 Optimization objectives .................................................................................................................. 8 2-1.1 3G1x Voice only network ....................................................................................................... 8 2-1.2 Combined 3G1x Voice/Data system ....................................................................................... 9 2-2 3G1x CDMA System Parameters ................................................................................................... 9 2-2.1 3G1x Voice only network ....................................................................................................... 9 2-2.1.1 Primary Parameters ......................................................................................................... 9 2-2.1.2 Secondary Parameters ................................................................................................... 11 2-2.1.3 Fixed Parameters........................................................................................................... 12 2-2.2 Combined 3G1x Voice/Data network ................................................................................... 13 2-2.2.1 Primary Parameters ....................................................................................................... 13 2-2.2.2 Secondary Parameters ................................................................................................... 13 2-2.2.3 Fixed Parameters........................................................................................................... 14 2-3 Optimization Cluster Selection ..................................................................................................... 14 2-4 Optimization Procedures............................................................................................................... 15 2-4.1 RF Optimization for Voice only Cold Start .......................................................................... 15 2-4.1.1 Loading Procedures....................................................................................................... 15 2-4.1.2 Data Collection Tools ................................................................................................... 16 2-4.1.3 Data Analysis Tools ...................................................................................................... 18 2-4.1.4 Personnel requirements ................................................................................................. 21 2-4.1.5 Performance Tests......................................................................................................... 21 2-4.2 RF Optimization for a Combined 3G1x Voice/Data network............................................... 33 2-4.2.1 Loading Procedures....................................................................................................... 35 2-4.2.2 Data Collection Tools ................................................................................................... 36 2-4.2.3 Data Analysis Tools ...................................................................................................... 43 2-4.2.4 Personnel Requirements................................................................................................ 46 2-4.2.5 Performance Tests......................................................................................................... 47 2-5 Techniques for mitigating Common RF Optimization Problems.................................................. 57 2-5.1 Common set of RF optimization problems for 3G1x Voice only or combined 3G1x Voice/Data optimization ....................................................................................................................... 57 2-5.1.1 No Service..................................................................................................................... 57 2-5.1.2 Dropped Calls ............................................................................................................... 58 2-5.1.3 Poor Voice Quality........................................................................................................ 60 2-5.2 Additional RF optimization problems specific to combined 3G1x Voice/Data system........ 61 2-5.2.1 Poor Data Throughput/SCH Assigned Rate/SCH FER in an unloaded system ............ 61 2-6 Post commercial monitoring parameters....................................................................................... 63 Chapter 3: Migration Scenarios ................................................................................................................ 64 3-1 Introduction................................................................................................................................... 64 3-2 Migration Scenarios Configuration and Optimization considerations ....................................... 65 3-2.1 Introducing 3G1x Voice in a 2G system on an existing carrier throughout the network ...... 65 3-2.1.1 Configuration ................................................................................................................ 65 3-2.1.2 Optimization Considerations......................................................................................... 65 3-2.2 Introducing 3G1x Voice partially in a 2G system on an existing carrier .............................. 66 3-2.2.1 Configuration ................................................................................................................ 66 3-2.2.2 Optimization Considerations......................................................................................... 67 Version 1.0 Lucent Technologies Proprietary Do not distribute outside the company 2

3-2.3 Introducing 3G1x Voice in a 2G system on a new carrier throughout the network .............. 68 3-2.3.1 Configuration ................................................................................................................ 68 3-2.3.2 Optimization Considerations......................................................................................... 69 3-2.4 Introducing 3G1x Voice partially in a 2G system on a new carrier ...................................... 70 3-2.4.1 Configuration ................................................................................................................ 70 3-2.4.2 Optimization Considerations......................................................................................... 70 3-2.5 Introducing 3G1x Voice/Data in a 2G system on an existing carrier throughout the network . .............................................................................................................................................. 71 3-2.5.1 Configuration ................................................................................................................ 71 3-2.5.2 Optimization Considerations......................................................................................... 72 3-2.6 Introducing 3G1x Voice/Data partially in a 2G system on an existing carrier ..................... 73 3-2.6.1 Configuration ................................................................................................................ 73 3-2.6.2 Optimization Considerations......................................................................................... 73 3-2.7 Introducing 3G1x Voice/Data in a 2G system on a new carrier throughout the network ..... 74 3-2.7.1 Configuration ................................................................................................................ 74 3-2.7.2 Optimization Considerations......................................................................................... 74 3-2.8 Introducing 3G1x Voice/Data partially in a 2G system on a new carrier ............................. 75 3-2.8.1 Configuration ................................................................................................................ 75 3-2.8.2 Optimization Considerations......................................................................................... 76 3-2.9 Introducing 3G1x Data in a 3G1x Voice only system .......................................................... 76 3-2.9.1 Configuration ................................................................................................................ 76 3-2.9.2 Optimization considerations.......................................................................................... 77 Chapter 4: Special Topics .......................................................................................................................... 79 4-1 3G1x to 2G handoffs..................................................................................................................... 79 4-1.1 3G1x to 2G same frequency handoffs (Voice calls only) ..................................................... 79 4-1.2 3G1x to 2G inter-frequency handoffs (Voice calls only) ...................................................... 80 4-2 3G1x to 3G1x inter-frequency handoffs ....................................................................................... 82 4-3 RF load balance across carriers and across technologies .............................................................. 82 4-3.1 Idle mode hashing ................................................................................................................. 82 4-3.2 Allow 3G1x Carrier sharing.................................................................................................. 82 4-3.3 Traffic channel mode load management ............................................................................... 82 4-3.3.1 RF Loading Option ....................................................................................................... 82 4-3.3.2 CCC option ................................................................................................................... 84 4-3.3.3 Origination carrier option.............................................................................................. 84 Chapter 5: Acknowledgements .................................................................................................................. 85 Chapter 6: References ................................................................................................................................ 85

Version 1.0

Lucent Technologies Proprietary Do not distribute outside the company

Chapter 1: RF Optimization
1-1 Introduction

This document presents set of procedures and guidelines for optimizing a 3G1x network. The term RF optimization used in this document refers to a drive test measurement based process utilized to tune all aspects of over-the-air performance of a system. In the past, it has played an integral role in preparing a second generation (2G) CDMA system for commercial operation. Often, it has also served as a continual process extending beyond the first commercial cut-over, such as, fine-tuning performance, when new cells/carriers are added to a network, or as traffic volume/pattern changes with increasing subscriber base. Voice service has been the primary emphasis for the 2G CDMA deployments. The third generation (3G1x) CDMA systems cater to both Voice and Data1 needs. This document presents a set of guidelines and procedures to perform RF optimization for a 3G1x CDMA system. Different markets may present different deployment configurations to optimize. Some special considerations may be required for each. Towards that end, this document first discusses the procedures for a Cold Start of a 3G1x system. These are addressed in Chapter 2. A Cold Start system is further classified into 3G1x Voice only or combined 3G1x Voice/Data system. Any potential migration scenarios such as 2G to 3G1x Voice only, or 2G to 3G1x Voice/Data, or 3G1x Voice only to 3G1x Data are covered next in Chapter 3, with discussions on specific optimization needs. Chapter 4 covers some special topics such as discussion on inter-frequency/inter-technology handoffs and carrier/technology load balancing. Note that the optimization procedures for a 3G1x Voice only network are consistent with those for a 2G system (Voice and/or circuit switch low-speed Data). There are some minor changes such as using a 3G1x phone instead of 2G for data collection, using updated version of CAIT software for data collection, using LDAT3G instead of LDAT for analysis; but the various test phases, data analysis and troubleshooting methods remain the same. Optimizing for Data poses some additional requirements on the procedures. It impacts data collection toolkits, data collection and analysis process, and troubleshooting. It is also worthwhile to point out that this document assumes any new service is introduced on a single carrier. It does not discuss scenarios where multiple carriers are introduced. Second, it does not address optimization methods for inter-frequency handoffs where required as in the case of certain 2G to 3G1x migration scenarios. It simply refers to [1], a document available on RFEC web site (http://rfec.wh.lucent.com) that contains detailed information on design and optimization of a pure 2G multi-carrier system. Note that the 2G inter-frequency handoff methods and optimization techniques also apply in case of a pure 3G1x multi-carrier system, or for a mixed 2G/3G1x system where 3G1x to 2G inter-frequency handoff borders are formed. Therefore, the reader is encouraged to familiarize with [1] in order to develop a more comprehensive understanding of all types of optimization methods. This document, however, discusses optimization techniques for newly developed 3G1x to 2G same-carrier handoffs as they set in some differences compared to the existing handoff techniques.

1-2

A high-level view of 3G1x optimization procedures

Below we outline the optimization procedures needed for a 3G1x system. Since there are many common elements between optimizing a 3G1x Voice only or a combined 3G1x Voice/Data network, we mainly present a common view, but highlight any considerations when optimizing for Data.

The term Data or 3G1x Data in this document refers to the High-speed packet-data capability of 3G1x. This is primarily achieved via the use of Fundamental and Supplemental channels on either link. Lucent Technologies Proprietary Do not distribute outside the company 4

Version 1.0

The CDMA RF optimization procedures defined here cover any IS2000 based terrestrial system 800 MHz cellular, 1.9GHz PCS or any other spectrum as in case of international deployments. Because of the predominance of Radio Configuration 3 (RC3) based systems likely to be deployed, the procedures are mainly written for a RC3 configuration. However, only minor changes to the procedures are required to accommodate other radio configurations. Before proceeding to the actual optimization testing, it is necessary to prepare the system for optimization. The preparation phases include Spectral clearance testing, System Pre-Test and Sector testing. These are very similar to those for 2G optimization, as discussed below.

1-2.1 System Preparation Phases


Spectral clearance testing can be performed as early as during the RF planning stages. The cells do not even have to be installed. The rest of the preparation phases can only begin after installing the cells. Since cells will be installed and integrated gradually not all cells will be ready at the same time this should be such that at the conclusion of the preparation phases, optimization testing can be performed. The latter consists of cluster tests, so it is desirable to install cells in geographical contiguous areas.

1-2.1.1

Spectral Testing

The Spectral clearance tests entail ensuring a clear spectrum with 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 extreme cases, it can be a time consuming, difficult task to identify and mitigate the sources of external interference (e.g. microwave data transmissions, externally generated intermodulation products, wideband noise from arc welders and other machinery, etc.); therefore, it is important to ensure clear spectrum 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 jammer detection algorithms for given environmental conditions.

1-2.1.2

System Pre-Test

Following the Spectral clearance tests, System Pre-Test is initiated. This mainly includes troubleshooting and verifying cell hardware operation and configuration, translation scrub and preparing initial neighbor lists. RF Antennas are swept to detect any cabling/connection issues by measuring reflection losses. Cable and insertion losses are catalogued. Antenna downtilts are verified. Next any alarms suggesting bad cell hardware such as LAC, GPS, Packet Pipe trouble notifications are investigated and cleared. Any island cell issues are investigated. A thorough translation scrub is performed to set them per recommendations. The recommendations for RF parameters can be found from RF Translation Application Notes. Finally, a first cut of neighbor lists are programmed in the FCI forms (for softer/er handoffs) as well as CDHNL forms (for multi-carrier handoffs). General guidelines are maintained to keep neighbor lists small and maintain neighbor list integrity. A typical initial neighbor list for a sector includes cross-face sectors of the same cell as well as any inward facing sectors of the first tier neighboring cells. Bi-directional neighbor lists are also ensured.

1-2.1.3

Sector Testing

Following the System Pre-test, the first step of the Sector test is to exercise basic call processing functions, including origination, termination and handoff, to assure that these rudimentary telephony capabilities are operational. Quick measurements are then made of CDMA signal levels, either over-the-air or with a power meter, 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. In case of optimizing for a Voice/Data network, the tests will expand to ensure a high-speed Data call can be made. Under no load, system should be able to support highest configured rate (such as, 16x, i.e., 153.6 kbps)2 close to a sector, assuming there is minimal other sector/cell interference. This verifies proper translation parameter configuration and backhaul provisioning. Following Sector testing, the cells are ready for RF optimization.
2

Note that some commercial mobiles may only be able to support a maximum rate of 8x (i.e., 76.8 kbps) on the reverse supplemental channel. Lucent Technologies Proprietary Do not distribute outside the company 5

Version 1.0

1-2.2 RF Optimization Test phases


As proposed, the optimization procedures whether for a 3G1x Voice only network, or a combined 3G1x Voice/Data, are to be conducted in two phases: cluster testing and complete system-wide optimization. The phases are similar to those for 2G optimization, especially for 3G1x Voice, where as 3G1x Data requires additional data collection equipment and fine-tuning. 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 for completing the cluster test cycles. For 3G1x Data, there is an additional requirement to ensure RF coverage to achieve good Data performance in terms of assigned rate, SCH FER as well as throughputs in as large an area of a network as possible. During the RF optimization process, CDMA parameters will be adjusted using simulated traffic loading, due to the extreme cost and logistical obstacles 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.

1-2.2.1

Cluster Testing Unloaded and Loaded coverage tests

Cluster testing consists of a series of procedures to be performed on geographical groupings of cells. The number of cells in each cluster is relatively large to characterize the effect of a parameter change. Secondly, it provides enough forward link interference to generate realistic handoff boundaries in the vicinity 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. Approximately 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 to coarsely tune basic CDMA parameters and to identify, categorize, and catalog coverage problem areas. No attempt will be made to resolve complicated coverage problems during the cluster test phase; such location-specific, detailed refinements will be deferred until the system-wide optimization phase. After basic cell operation has been verified, surveys of forward link pilot channel coverage are performed with light traffic load on the system. During the unloaded survey measurements, all cells in the cluster are simultaneously transmitting forward link overhead channels (i.e. Pilot, Sync, QPCH and Paging), with a minimal number of Fundamental traffic channels active (typically 0 to 2). In case of Data, in addition to the Fundamental traffic channels, there may not be more than one high-speed Supplemental channel (max rate of 16x) on each link. 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, at a minimum, major freeways and roadways where high levels of wireless traffic are to be expected. Drive routes may also be selected to explore weak coverage areas and regions with multiple serving cells, as predicted 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, multiple pilot and non-dominant 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 transmit powers and neighbor lists. Finally, measuring the pilot levels without load serves as a baseline for comparison with measurements from subsequent cluster tests under loaded conditions. Characteristics of cell shrinkage can be compared under the extremes of light and heavy traffic load. 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 Version 1.0 Lucent Technologies Proprietary Do not distribute outside the company 6

during later optimization tests. Simulated traffic loading will be accomplished primarily using OCNS and mobile attenuators. Although the loading mechanisms will be the same, there will likely be difference in levels of loading utilized when optimizing a Voice only system versus a combined Voice/Data system.

1-2.2.2

System-wide Testing

After all clusters in the CDMA network have been tested, system-wide optimization 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 adjusting transmit powers, antenna configurations and neighbor list entries and Neighbor Set search windows. In extreme situations, handoff thresholds, Active Set search window sizes, cell search window size, or other low-level tuning parameters may have to be modified. If the field team cannot resolve coverage problems 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 final 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 addressed 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, frame erasure statistics. When optimizing for Data, additional metrics will include throughputs at the RLP and physical layers. Following the system wide optimization test, dropped call, origination and termination tests are executed to sample the dropped call and access performance in the network. Note that these are typically optional tests, performed only if specified in the contract. For 3G1x Voice only optimization, additional physical layer parameters can also be measured to preview potential performance during the Acceptance criteria testing. In addition when optimizing for 3G1x Data, metrics, especially, RLP and physical layer throughputs can also be measured via the Data call. A concurrent 3G1x Voice phone can provide the dropped call and access performance statistics. At the conclusion of the above tests, the RF optimization procedure will be considered complete and the CDMA network ready for live traffic testing and market trials leading into commercial service. Once significant loading with live traffic is present on the CDMA network, additional tuning of the system parameters will be required to accommodate uneven traffic conditions (e.g. traffic hot spots, unusual traffic patterns, etc.) and other dynamic effects which cannot be easily predicted or modeled with simulated traffic loading.

Version 1.0

Lucent Technologies Proprietary Do not distribute outside the company

Chapter 2: Cold Start of a 3G1x System


Cold start refers to a brand new deployment. Cold start could be for various scenarios such as 3G1x Voice only, 3G1x Data only or combined 3G1x Voice/Data system. To simplify and address most common configurations, this document focuses mainly the 3G1x Voice only and combined 3G1x Voice/Data systems. Cold start of a 3G1x Voice only system is straightforward configuration much like a brand new 2G network. The similarities in basic configuration and performance metrics between 2G and 3G1x Voice call also lead to very similar optimization methods and procedures. Since Data is likely to co-exist with Voice in most networks where maintaining quality of service for Voice will be critical, we consider Cold Start of a combined Voice/Data system rather than a Data only system. This is particularly important since at this point, Voice and Data services can not be fully separated across carriers, therefore, for combined systems, it will mean both services will co-exist on the same carrier. This chapter first introduces optimization objectives for the two Cold Start configurations. In section 2-1, it provides an overview of optimization procedures where many similarities exist between the two configurations. Any differences are highlighted. Next in section 2-2, it specifies several CDMA parameters categorizing them per their use during RF optimization. Section 2-3 presents considerations for selecting optimization cluster. These are the same regardless of the configuration. Next, section 2-4 presents actual set of optimization procedures for each configuration. There is a detailed discussion on optimization tests, loading methods, data collection and analysis tools, performance tests, data collection procedures and data analysis methods. In section 2-5, typical set of optimization problems as well as potential remedies are outlined. Finally, there is a discussion on fine-tuning performance during commercial operation. Several system level metrics are identified such as dropped call, access failures, FER rate, Erlang usage, etc. It also provides some information on balancing RF load as well as achieving some Voice/Data separation across carriers. These will likely be adjusted based on customer expectations and as subscriber usage grows.

2-1

Optimization objectives

Before discussing the procedures, it is important to understand the objectives behind optimizing a 3G1x system. These are listed below for each of the two main configurations.

2-1.1 3G1x Voice only network


The optimization objectives for a 3G1x Voice only network are similar to that of a 2G system. The most significant objectives are as follows. - Ensure that acceptable coverage is achieved for the pilot, paging, quick paging, synchronization, access, and traffic channels. These objectives are measured based on metrics such as FER, Pilot Ec/Io, mobile transmit power and mobile receive power. Ensuring good coverage helps minimizing dropped calls. - Minimize the number of dropped calls, missed pages, and failed access attempts. The performance is measured from dropped call and origination/termination attempts. - Control the overall percentages of 1, 2, and 3-way soft/softer handoff. The performance is measured via overall handoff statistics with and without loading. Usually the soft/softer handoff thresholds are sparingly adjusted. Attempt is to maintain consistent thresholds across the network. Note that CDMA release 17.1 introduces IS95B SHO algorithm. IS95B algorithm if enabled also applies to 3G calls. Further study is needed to understand the performance impact as well as recommend values for the associated thresholds. Until such time, it is recommended to continue to utilize the existing IS95A algorithm. - Provide reliable intra-technology (2G to 2G, or 3G to 3G) and inter-technology (3G to 2G) handoffs. The performance is measured from dropped call tests in the handoff region.

Version 1.0

Lucent Technologies Proprietary Do not distribute outside the company

2-1.2 Combined 3G1x Voice/Data system


All the objectives described for 3G1x Voice only optimization also apply to 3G1x Voice/Data optimization. In addition, it is important to ensure acceptable assigned Supplemental (SCH) rates as well as SCH FER on both the links in as larger an area of the network as the cell design permits. This in turn helps ensure acceptable Data throughputs for a given Data application. On the forward link, leg carrying the SCH of a Data call is called an anchor leg. Per the current Lucent implementation, there is only one leg transmitting SCH at any time for a Data call even if the fundamental channel (FCH) is in soft/softer handoff. Whenever another Pilot in the FCH Active Set becomes stronger relative to the current anchor by a certain threshold, SCH transmission is stopped and a new anchor is established on the stronger Pilot before resuming SCH. This process is called an anchor transfer. In order to achieve good throughputs on the forward link, it is desirable to minimize interference to the anchor Pilot from other FCH Active Set Pilots as well as minimize the SCH interruptions stemming from frequent anchor transfers. To meet these objectives require a conscious effort to create dominant Pilot regions. While doing so, careful emphasis is needed to ensure basic call integrity such as soft handoff, FER and dropped call performance for a Voice call, especially, under loaded conditions. This is because optimization to achieve dominant coverage regions should be performed based on unloaded system conditions when most number of Pilots are detected. With loading, cell coverage shrinks and may expose weak coverage areas if sufficient overlap is not maintained.

2-2

3G1x CDMA System Parameters

RF optimization requires adjusting several parameters that influence the performance of a network. There are a vast number of parameters available for optimizing a CDMA system. Most of these parameters are controlled via translations. Some of the parameters have complex interactions with one another affecting system attributes such as coverage, capacity and call quality. Therefore, it is important to prioritize the parameters depending on their ability to improve performance with minimal complexity and trade-offs. The other factor to consider when prioritizing the parameters is the frequency of usage. This is closely tied to the scope of performance impact. Some parameters require frequent tuning depending on the local RF environment, and may also considerably vary in their final values across the system. Certain parameters need very sparing adjustments to influence performance on a system wide basis. Below we classify the RF optimization parameters depending on the frequency/scope of their usage as well as interaction complexity they generate. The three classes are Primary, Secondary and Fixed parameters. We present these parameters first assuming optimization is performed for a 3G1x Voice only and then for a combined Voice/Data system. As it will be evident, the latter adds only a small number of new parameters to the list of Primary and Secondary Parameters.

2-2.1 3G1x Voice only network 2-2.1.1 Primary Parameters

These parameters require frequent adjustments, often from one cell site to another. They are the primary knobs to control the network performance. These include: - BCR/CBR attenuation (affects total Forward Link power [3]) - Antenna adjustments (azimuth orientation, antenna height, downtilt angle, antenna type) - Neighbor List Entries and associated Priorities [5] includes both FCI and CDHNL forms - Hard Handoff and Semi-soft handoff Thresholds [5] The Primary optimization parameters are the primary translations to be used to fix coverage deficiencies. Cell site transmit powers can be adjusted with BCR/CBR 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. Additional alternatives, such as changing antenna Version 1.0 Lucent Technologies Proprietary Do not distribute outside the company 9

downtilt or antenna pattern, can mitigate problem areas where transmit power adjustments are insufficient to resolve a deficiency. During adjustment of BCR/CBR attenuation, care must be taken to ensure 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). Adjusting coverage via Antenna adjustments tends to better preserve the link balance once established via BCR/CBR adjustments. Note that when adjusting the BCR/CBR values, it is important to also size the max_power translation to maintain uniform Pilot fraction at Full load across all cells. Refer to [3] App Note for a detailed discussion on this subject. Also note that BCR/CBR as well as max_power are per sector per carrier translation parameters. In general, these values should be set the same across all carriers of a given sector unless in the inter-frequency border zone where the last or the second-last tier of outward facing sectors may require more attenuation on the discontinuing carrier. The optimization of neighbor lists may be less of a problem during cluster tests, where typically only a small number of cells are active, than with system-wide tests, where many more sectors are simultaneously active. Note that there are two types of neighbor lists one are provisioned on the FCI form, other on the CDHNL form on the inter-frequency handoff border sectors configured for Directed Handoffs. Due to the limited neighbor list size for each sector, tradeoffs are required to select entries, which minimize dropped calls because of missed handoffs or handoff sequencing problems. For the FCI neighbor lists, specifying proper priorities is also an essential step when optimizing neighbor lists. While different mobile manufacturers may implement priority based Pilot searching differently, simple rules can be followed. As a rule of thumb, the adjacent sectors of the same cell as well as facing sectors from the first tier of immediate neighbors can be afforded highest priority. Second priority neighbors may include the sectors of the first tier cells facing away from, as well as the sectors of the second tier cells facing towards, the sponsoring sector. Remaining sectors in the neighbor list can be given the lowest priority. The above rules can be deviated selectively depending on the coverage of a particular neighbor. For the CDHNL neighbor lists formation, refer to the guidelines presented in [1] for multicarrier optimization. The Neighbor Set Search window size, utilized on the forward link, should be set initially based on expected cell sizes and multipath propagation delay spreads, as discussed in [5]. If the CDMA deployment contains a mixture of small cells and large cells, then window sizes may have to be adjusted on a case-bycase basis to accommodate all handoff scenarios. For example, if there is a large variation in the antenna heights for CDMA cells in the network, situations 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 mobiles 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 neighbors pilot PN offset, as calculated based on the mobiles reference timing. Since the mobiles 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 situation, if the neighbor search window size is not large enough, the mobile may fail to detect pilots from close-in neighbors due to the retarded timing reference. This could result in dropped call on account of strong interference to the mobile Active Set. The Hard-handoff and semi-soft handoff thresholds apply to handoffs in the same frequency or interfrequency border regions. Refer to App Notes [5] for a discussion on different types of handoff techniques and their configuration, and to [1] for a discussion on optimizing these thresholds.

Version 1.0

Lucent Technologies Proprietary Do not distribute outside the company

10

2-2.1.2

Secondary Parameters

While most of the RF optimization is performed using the Primary parameters, the secondary parameters can be used for further fine-tuning, especially in specific problem areas. The parameters include: - Soft handoff thresholds including IS95B soft-handoff thresholds - Active Set Search Window and Cell Site Search Window Sizes - Access probe nom and init power levels - Sector size and Access preamble size - Pilot, Page, Sync and Quick Paging channel levels - Forward link Traffic channel power settings - RF Load Weighting Factor The secondary optimization parameters can have system-wide performance impacts, and therefore should be adjusted with caution, in cases where the adjusted parameters do not fully resolve a problem. For example, even small changes in soft handoff thresholds can impact overall system capacity and channel element utilization. In general, attempts should be made to keep a single set of handoff thresholds for the entire CDMA network. For a call in handoff, the effective thresholds are not always predictable if the handoff legs are configured with different parameter settings. For example, highest Tadd value is chosen from among the legs. As long as the call is in handoff with the leg sponsoring the highest Tadd value, this value will be used. This may be necessary to improve performance in a specific problem area, but could hurt performance on a route, where, for instance, a fast rising neighbor needs to be added quickly to minimize the interference. For this reason, it is not advisable or practical to alter soft handoff thresholds on a sector-by-sector basis. The Active Set search window size parameter on the forward link and the cell site search window size parameter on the reverse link parameter will generally be sized equal [5]. In general, they will be sized based on the multipath environment. However, exceptions may be necessary, especially in an area with a mixture of small and large cells. When the mobile is driving among cells with different radii, it constantly slews its reference to tune to the earliest arriving cell. This creates an ambiguity for a newly added soft handoff leg in estimating the center position of the search window. The problem becomes more apparent in case of a hard handoff where an inadequately small search window could result in a dropped call. This is because the mobile has already broken RF connection with the old cell site while the target cell is attempting to acquire the mobile. In case of soft-handoff adds, the older legs can still carry the call making the problem less obvious. Increasing the cell site search window can alleviate the problem. Following the general guideline of keeping consistent Active Set and Cell site search window sizes, both should be adjusted although the problem is more of a reverse link phenomenon. The init and nom access probe level parameters are adjusted only in areas where it regularly takes more than one probe to complete an access attempt. While poor RF coverage conditions may lead to this condition, this could also happen in areas of excessive interference in the forward link. Higher received power in the forward link reduces the open loop turnaround used by the mobile to transmit on the reverse link. This often results in an inadequate probe level to close the reverse link at the first attempt. It may take several access probe attempts at increasingly higher power before cell site hears the mobile. These probe repetitions cause undesirable interference to the reverse link of other users. A higher nom or init setting provides a boost for the first access attempt to improve its likelihood of getting through to the cell site. Care must be taken to increase these parameters only where required, as the increased power level is also a source of interference to other users. The Sector Size parameter applies to the reverse link and is set initially based on the designed extent of the cell coverage. The cell site uses this to size its access channel window when searching for access probes from the mobile. Some difficult terrains may cause the signal to be heard from larger than the designed range. In order to maintain reliable access channel performance, the Sector Size parameter will have to be increased accordingly. The Sector Size also has impact on the Access Preamble Size parameter. Mobile sends an access preamble at the beginning of a probe to assist cell site with the detection. Preamble is a series of symbols known a-

Version 1.0

Lucent Technologies Proprietary Do not distribute outside the company

11

priori to the receiver. If the Sector Size is large, it will take the cell site longer to finish searching all the delay hypotheses tests within the access search window. Mobile must continue to send preamble until the search is complete. Therefore, increasing Sector Size may require increasing the Access preamble size. Refer to the App Note [6] for proportional relationship between the two parameters. The power for overhead channels (Pilot, Paging, Sync and Quick Paging) expressed in terms of Digital Gain Units (DGUs) is usually set uniformly across the system. In general it is recommended not altering them due to their impact on traffic carrying capacity of the network. In some specific areas of concerns, these may be adjusted, for example, for improving coverage at the sacrifice of capacity. Larger overhead channel power levels may help mobile overcome any forward link coverage limitations. Another example is to elevate Quick Paging and Paging channel power levels to improve termination success rate. Again this will come at the expense of the traffic channel capacity of the network and/or of the quality of service of the individual traffic channels due to increased overall interference. Similar to the overhead channel settings, the traffic channel power levels expressed relative to the Pilot power levels are typically set uniformly across the system. In specific cases, some deviations are possible. For example, max_gain, the upper constraint on the cell site traffic channel power for a given user can be increased to overcome forward link coverage limitation, especially, for cells at the edge of the system or in low traffic regions. The parameter may also be adjusted differently for different handoff states depending to fit specific needs. Init_gain, the power level at which a 3G1x Voice call enters traffic state, can be adjusted higher to potentially improve call set-up failures. In stationary environments, min_gain, the lower constraint on the cell site traffic channel power can be adjusted to achieve desired frame error rate distribution. These parameters have impact on traffic capacity of the network, so careful contemplation is necessary to consider the trade-offs. The RF loading weight factor is typically not optimized during the drive test optimization process of a new network. This parameter can be adjusted during commercial operation to balance the objectives of achieving desired load balance across carriers as well as reliable origination/termination performance. This is described in more detail in section 4-3.3.1 as well as App Note [6].

2-2.1.3

Fixed Parameters

The fixed parameters involve quantities that should not be adjusted during field optimization. Changing these parameters can create complex interactions among key system performance attributes such as coverage, capacity, voice quality, data throughput, etc. The impact is not easy to characterize or predict, and can vary widely from market to market, or within a market. These parameters should be adjusted only after consulting the subject matter experts. The parameters include: - Forward and Reverse link power control parameters - Forward and Reverse link overload control parameters - Remaining set search window parameters - Reverse Pilot to FCH offset These include forward and reverse link power control Eb/No set points, power control step size, FER targets and overload control thresholds, 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 maximum values allowed in the translations to avoid false alarms during the loaded drive testing. Due to the forward overload control algorithms 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. The Remaining Set search window parameter can be set to at least as big as the Neighbor Set search window size during optimization itself. This could facilitate detection of any incomplete Neighbor Lists.

Version 1.0

Lucent Technologies Proprietary Do not distribute outside the company

12

However, once the optimization is complete, it should be set to 0, unless further fine-tuning is performed during the commercial phase via the Undeclared Neighbor List feature. 3G1x introduces a Pilot channel on the reverse link. Each mobile transmits it while in a call. The purpose is to assist with coherent demodulation of the reverse FCH at the cell site, to carry Forward link power control up/down commands sent by the mobile as well as to allow better tracking of the reverse Eb/No at the cell site. Similar to the reverse FCH, the Pilot channel itself is also power controlled by the cell site. The ratio of Pilot to FCH, however, remains constant and can be adjusted by a translation. This ratio is called reverse Pilot fraction. An optimum value for the parameter balances the need to achieve acceptable traffic channel quality and overall capacity on the reverse link. Since the parameter impact needs to be evaluated on a larger number of real users, it should not be adjusted during RF optimization where typically there one or two fundamental channel users active. Refer to the RF Translation Application Notes to obtain recommended values for the various Fixed Parameters.

2-2.2 Combined 3G1x Voice/Data network 2-2.2.1 Primary Parameters

There are no additional Primary parameters compared to a 3G1x Voice only system. However, optimizing for 3G1x Data requires a more conscious emphasis on creating dominant Pilot regions. This will be attempted using antenna adjustments as well as CBR/BCR adjustments. Once the coverage is adjusted, it may require further fine-tuning of neighbor lists and/or Neighbor Search Window size parameters.

2-2.2.2

Secondary Parameters

In addition to the Secondary Parameters for 3G1x Voice optimization, additional parameters include - Anchor hysterisis threshold - Load preference delta for Data As explained earlier, Anchor is the member of the FCH Active set that carries SCH transmission for a highspeed Data call. An anchor is chosen based on the Pilot strength reporting by the mobile. Cell site periodically assesses the Pilot strengths to assist with burst rate allocation in the forward link as well as need to change an anchor. When another FCH Active Set member becomes stronger than the current anchor by a given margin, the SCH transmission is transferred to the stronger leg. This process is called Anchor transfer. The margin is called Anchor hysterisis threshold. The actual Anchor transfer process involves sending a message to the mobile to stop processing the current SCH burst (via Extended Supplemental Channel Assignment Message), stopping the SCH transmission, establishing a new anchor, sending another message to mobile to resume SCH processing at a fixed time in the near future (via another Extended Supplemental Channel Assignment Message specifying new PN offset, burst rate and duration), and finally resuming the transmission on the new anchor at the given time. More the number of anchor transfers, larger the number of interruptions in Data transfer. The anchor hysterisis threshold can be adjusted to minimize anchor transfers in areas suffering from excess ping-ponging of Pilot strengths. While it is desirable to minimize this thrashing by adjusting coverage first (creating dominant Pilot regions), some locations may pose tough RF environment difficult to optimize. Larger value of the threshold can be chosen only after exhausting coverage improvement alternatives. The trade-off is that current anchor will face stronger interference for potentially much larger amount of time due to delayed Anchor transfer. Therefore, it needs a careful evaluation of overall performance impact in the nearby region before making any changes. Load preference delta for Data is a per-sector-per-alternate-carrier parameter applied at the time of assigning an initial FCH channel for a Data call. A non-zero value for one or more carriers allows biasing Version 1.0 Lucent Technologies Proprietary Do not distribute outside the company 13

Data calls to these carriers. This may be desirable from a customer perspective to try to minimize Voice and Data interaction on a given carrier. Note, however, that currently there is no way to preclude Voice call assignments to this carrier, so strict separation is not possible. Similar to the RF Loading Weight Factor, this parameter is not optimized prior to commercial operation. Section 4-3.3.1 provides more detail on possible fine-tuning during commercial mode.

2-2.2.3

Fixed Parameters

3G1x Data introduces several new RF translation parameters. Most of them fall into the Fixed Parameters category. These include: - Forward and reverse power control parameters for Data FCH - Forward and reverse power control parameters for Data SCH - Anchor monitoring interval - Forward and Reverse link Supplemental allocation parameters For the FCH, there are separate set of power control parameters between Voice and Data. There are also a new set of parameters for SCH power control such as forward and reverse Eb/No set points, step size, and SCH gain constraints, rate offsets that also help make SCH burst rate, duration and power allocation decisions. These should be adjusted only based on simulations, lab testing or extensive performance validation in field. They are not changed during RF optimization. This in fact applies to all parameters listed above. Anchor monitoring interval sets the frequency at which cell site evaluates Forward link Pilot Ec/Io levels for making anchor transfer decisions. There are certain supplemental channel allocation parameters on either link designed to optimize resource allocation, capacity and performance when assigning SCH rates to a Data user. The recommended values are chosen after careful lab testing, simulations and performance testing in field. These also have complex interactions with power control and capacity and hence are not adjusted during RF optimization. Refer to RF Translation Application Notes for recommended settings of various Fixed parameters for highspeed Data.

2-3

Optimization Cluster Selection

The cluster selection methodology remains the same as 2G when optimizing a 3G1x Voice network or a combined 3G1x Voice/Data network. Several factors make it worthwhile to optimize the system in manageable sized clusters. First, it leads to a better focus on the area being optimized. The lesser the number of sectors, the easier it is to track the parameter changes and their performance impact. Second, it allows for multiple teams to optimize different clusters simultaneously. Each team is able to maintain focus on its cluster with minimal impact from other teams. Third, it could also help prepare the system for commercial operation quicker. Optimization in equipped clusters can go on at the same time as the cell site equipment in other clusters is being installed. A cluster consisting of 12-20 cells is a reasonable size to select. It allows a more complete characterization of a parameter change as the impact generally carries over to one or two surrounding tier of cells. Having a cluster consisting of roughly two tier of cells will also generate sufficient forward link interference for proper evaluation of performance at the center cell and the first tier. It is important to have some overlap of cells between a pair of adjacent clusters. It will simplify the system wide optimization performed after the individual clusters are optimized. It may be worthwhile to utilize natural barriers such as hills, water bodies, etc. for cluster separation to minimize the need for overlap. Once the clusters are finalized, each optimization team will be assigned a cluster. The team will carry out optimization per the procedures listed in the following section.

Version 1.0

Lucent Technologies Proprietary Do not distribute outside the company

14

2-4

Optimization Procedures

This section presents optimization procedures for a Cold Start of a 3G1x Voice only network as well as a combined 3G1x Voice/Data network. The optimization procedures for some common migration scenarios are discussed later in the document. The primary optimization techniques are the same for both configurations. These include developing proper neighbor lists; antenna and BCR adjustments to improve coverage and reduce Pilot pollution; adjusting search windows based on propagation and cell design; fine-tuning handoff thresholds to meet exit criteria based on drop calls, FER and access performance. The difference in the procedures results from several sources, such as, data collection equipment used, metrics evaluated and optimization problems encountered.

2-4.1 RF Optimization for Voice only Cold Start


There are various steps involved in optimizing a network. It mainly consists of a series of drive tests to collect physical layer and over-the-air messaging information. The data is analyzed to improve performance by arriving at proper parameter values. Some of the parameter adjustments may require iterations to attain acceptable performance. The data is collected under unloaded and loaded RF loading conditions. The loading procedures are described in the following sub-section along with the tools utilized to simulate loading. In subsequent subsections, we specify Test equipment required for data collection and a list of software aids used for analysis. Using these tools and methods, sub-section 2-4.1.5 specifies the actual set of procedures utilized for drive test optimization. The procedures consist of a series of performance tests conducted to optimize the performance of the network.

2-4.1.1

Loading Procedures

While it is the first right step to optimize a network under unloaded conditions, a follow-on testing is needed to evaluate the impact of loading and to fine-tune performance as necessary. This helps prepare network for commercial operation when it will be loaded with actual users. Note that loading here refers to RF stress testing, not hardware or software testing of the infrastructure. One way to load is to employ real users. However, this could become very expensive and logistically intensive. Further, it would not be trivial to attain desired loading levels in a consistent manner. As proposed here, the loading is attempted using simulated techniques. There are different methods employed on the forward and reverse links as stated below.

2-4.1.1.1

Forward Link

The forward link loading is simulated using Orthogonal Channel Noise Source (OCNS). As the name suggests, it keys up transmission on orthogonal Walsh Codes to generate interference. It only operates on the forward link. It is similar to a forward link of a voice channel, except that there is no power control feedback mechanism from a phone. The flexibility of OCNS is its ability to generate consistent interference based on a specified number of users and dgu level per user. OCNS can be configured either in constant gain mode or variable gain mode. In the constant gain mode, the gain is held constant throughout OCNS transmission. In the variable gain mode, the gain is scaled based on an assumed voice activity factor. Further the gain is also varied to generate a distribution around the voice activity factor. RF Engineers typically use OCNS in a variable gain mode to capture some dynamics of a real user. OCNS is activated by typing following commands on the TIpdunix prompt of the ECP RTR shell: To start

Version 1.0

Lucent Technologies Proprietary Do not distribute outside the company

15

OCNS:CELL <cell #>;START To add users OCNS:CELL <cell #>, SECTOR <1-3>, CARRIER <1-12>; USERS <#> , DGAIN <1-119>, PCV <on|off> To stop STOP:OCNS;CELL <cell #> The input fields need to activate OCNS are cell #, sector #, carrier #, number of users and digital gain units (DGU). The PCV on/off setting sets the variable gain mode on or off. When it is off, the constant gain mode is activated. By default, that is, if PCV option is not specified, variable gain mode is assumed. The amount of loading to be used during loaded testing is usually specified in the contract. It is derived based on total Erlang loading the system is designed to handle as well as assuming average power consumed by a user. Any loading generated by the actual test user(s) is subtracted. Since different systems may utilize different link budget, Erlang loading and average power consumption assumptions, the loading levels may vary and are not specified here.

2-4.1.1.2

Reverse Link

On the reverse link, there is no concept of orthogonal loading. As the number of users in the vicinity of a cell increases, so does its total received power on the reverse link. One way to simulate this loading is to insert attenuation on the mobiles transmit path. This attempts to account for a fixed static increase in mobile transmit power, as it may happen with real users where cell site commands them to increase their transmit power to overcome loading. Standard RF kits provided by the Tools Group have a separate attenuator on the mobile reverse transmit path (known as Mobile Tx attenuator) to simulate loading. It is a variable attenuator with step size of 1 dB and typically ranging from 0-60 dB. Similar to the forward link, the actual loading value is specified in the contract and is based on several assumptions such as designed Erlang loading relative to reverse link pole capacity. Note that for a given RF kit and a given phone, it is necessary to compute proper attenuation value for an unloaded case after accounting for various losses in the assembly as well as sensitivity of the phone. For the loaded tests, the attenuator should then be increased to account for the loading per the contract.

2-4.1.2

Data Collection Tools

There are two main tools utilized to collect data. At the mobile end, an RF data collection kit is utilized to collect RF parameters as well as messages from the phone. This kit is described in section 2-4.1.2.1. The other tool is RF Call Trace (RFCT). It is completely based on software. It is run to collect RF parameters from the cell. It is a simple command line tool described in section 2-4.1.2.2.

2-4.1.2.1

Mobile data collection toolkit

The test set-up for 3G1x Voice optimization is very similar to that for 2G. Figure 1 shows a schematic diagram of standard components in a RF kit. The tool kit provides efficient and reliable collection of mobile data. A standard RF tool kit provided by Tools Group includes: - A reference antenna with known gain magnetically mounted to roof of test vehicle - A characterized 3G1x capable test mobile with connector to provide interface to separate roofmount antennas - An attenuator (MRx) placed between phone and antenna to account for antenna gain, cable loss and in-vehicle penetration loss in the forward liink - An attenuator (MTx) placed between phone and antenna to account for antenna gain, cable loss, in-vehicle penetration loss, and loading on the reverse link. Version 1.0 Lucent Technologies Proprietary Do not distribute outside the company 16

Two 4-port circulators to insert the attenuators (MTx and MRx) on respective links Isolation box to provide convenient test fixture to hold phone and to ensure test phone is well shielded Laptop for CAIT mobile data collection software along with necessary hardware interfaces to the mobile CAIT allows display and logging of mobile RF parameters and messaging. CAIT stands for CDMA Air Interface Tester and is provided by Qualcomm Inc. GPS Unit including magmount antenna with interface to CAIT laptop to log position information Mag mount MTx MRx

CAIT laptop Mobile phone Isolation box

GPS Unit Circulator

Attenuator Box

Circulators

Figure 1: Sketch of RF Data collection Tool kit Although not necessary, a mini-van is used typically as the drive test vehicle to house the RF kit. CAIT configuration and logging Following steps are needed to log mobile data via CAIT: - Launch CAIT application in Windows - Configure CAIT to look for the phone on proper COM port via Options Configure CAIT Phone menu selections. - Hit F5 key to bring Logmask section. Set it to 23E00001841F0 - From the Logging Status window, select proper logging directory - Launch the Call Monitor dialog box and configure it as follows: o Enter the number to dial for the Markov call o Set the Call type to 8K Markov o Set all call timers and call count to 0 o Check the Autolog During Calls option off o Enable the Redial on Drop selection o In order to start a call, click on the Begin calls. If the call drops, CAIT will automatically redial. At the end of the test, press Stop Calls on the Call Monitor to end the current call and stop automatic redial. - In order to turn the logging On, press Alt+L. Pressing Alt+L again toggles the logging Off. Mobile configuration - Ensure that the phone is programmed with proper Preferred Roaming List, MIN, SID and NID - Phone has two UARTs (COM Ports). Ensure that the its Serial I/O configuration is such that UART1 represents Data (DS) and the UART2 represents Diagnostics interface. This can be verified from the handset by pressing Menu 7 9 1 (Port Map). The handset display should show U1 U2 . - Set the baud rate of the phones diagnostic UART to 115200. This can be accessed from the handset via Menu 7 9 3 (Diag Baud) and cycling through the various available speeds until 115200 is seen. Hit OK to select it.

Version 1.0

Lucent Technologies Proprietary Do not distribute outside the company

17

2-4.1.2.2
To start:

RF Call Trace

RFCT tool is invoked/stopped from OMP prompt using followed set of commands.

nohup FTrftrace d <1-14 digit DN> -p <interval> -i <duration> -t <tag> & where, -d option is to allow specifying the Directory number of the phone (usually its MIN) to be traced -p for polling interval (2 sec recommended) -i for total duration (max 240 sec) -t is to allow specifying a text string to identify the data set To provide status: FTrftrace -s Shows one or more DNs being traced along with remaining time duration. To stop: FTrfstop d <DN being traced>, OR, The A option allows stopping all RFCT sessions. Ftrftrace A

To dump: nohup FTrfdump d <DN that was traced> -t <same tag as the dataset> -r -o <outfile> The dump process is necessary to generate output file from logged data. Further r option (stands for raw output) is required to create output compatible with LDAT3G. Note that the RFCT trace can run for a maximum of 4 hours. Ensure that the run does not exceed 4 hours. Else, stop RFCT and CAIT data collection, run FTrfdump process and resume testing. Also, it is conceivable multiple drive test teams may be collecting data concurrently. The above commands can be run separately for each DN. Use separate tags for easy identification of data sets. Also, ensure when stopping RFCT trace for a specific team, not to use -A option, else traces for all DNs will be stopped. The status feature helps identify active DN trace sessions.

2-4.1.3

Data Analysis Tools

There are several tools employed for data analysis. These include LDAT 3G, 3gtool, Geobin and NPAR5108/WPAR/Friendlyviewer. LDAT 3G LDAT 3G supports analysis of 3G1x mobile data. This tool allows the user to create performance metrics from mobile data (CAIT) as well as RF Call Trace (RFCT). It is designed to allow the user to access the data through the GUI interface. It provides ability to display/print metrics in three different ways geographical mapping, time series plot, and histogram/cdf distribution. Several metrics can be combined in one map or a plot to facilitate correlation. Some key data analysis metrics provided by LDAT 3G for 3G1x Voice: Based on CAIT Data: Pilot Ec/Io Max Finger FCH, Aggregate FCH, Dominant Pilot Ec/Io, Number of Pilots above threshold, Ec/Io of Specific Pilot (no time series) Power measurements Mobile transmit Pilot, Mobile transmit FCH, Mobile receive Access Probes (no time series) Number of Probes and Final Access Power (mobile receive power at the time of sending the probe) Forward FER FCH Based on RFCT Data: Reverse FER FCH Power Measurement RFCT Cell Transmit Gain RFCT number of legs in SHO Version 1.0 Lucent Technologies Proprietary Do not distribute outside the company 18

RFCT number of CEs

Setting up LDAT 3G Before creating any datasets, LDAT 3G should be setup for the specific needs of the market using the procedure below. Select Defaults menu item from the Configure menus, and Defaults window will show up. On the Dataset tab, update the dataset name and browse to the default-working directory. It is suggested to use C:\DATA as the working directory. This window does not allow the user to create a new directory, the working directory must be created using Windows Explorer. On the Cells tab, select the cells.mdb file to be used for this market. To create a cells.mdb file, see section Creating a Cells Database On the Scenario tab, update the default Scenario Name, Pilots Above Threshold and Bin Size fields as needed. On the Map Files tab, select the MapInfo street files for the market. On the Metrics tab, select default metrics that should be calculated during dataset creation. During new dataset creation, these metrics will be selected as default, but the user will have a chance to update the list before the creation of the dataset. LDAT 3G only calculates the metrics requested by the user during database creation. However, the other metrics can also be requested after the dataset is created. In this case LDAT will go through the calculations first, then show the desired plot. To save time, user should select metrics that are used the most during the dataset creation. On the Themes tab, the ranges and the color codes for the ranges are defined for each metric. The user can update these values. However, having different colors in different markets can cause confusion as the engineers move from market to market. Therefore, these setting should not be changed unless there is specific customer need. Creating a Cells Database for LDAT 3G Run Cells Database tool from Start->Programs->LCAT->Lucent CellsDB Analysis Tool Select New from the File menu Enter a file name. Click Save, and a new Cells Database will be created. Add ECPs, Cells and sectors using the GUI of the Cells Tool. Creating a Cells Database for LDAT 3G using the cells.txt file Run Cells Database tool from Start->Programs->LCAT->Lucent CellsDB Analysis Tool Select Cells.txt from the Import menu Select the cells.txt file you would like to import, and click OPEN A cells.mdb file in the same directory as the cells.txt file will be created.

Creating a Dataset in LDAT 3G Copy all CAIT and RF Call Trace files, if applicable, to appropriate folder under the working directory. Open LDAT 3G, click on File, then New Dataset, this brings up the Dataset Creation window Under Dataset Name enter dataset name. Click on Browse and select the folder where the data is as the working directory. Click Next This will open the Select Data File window, now click on Add Files, choose the files and click Next. This will open the Select Cell data window. If needed, click on Browse, choose the cell file and click next. This will open the Enter Scenario Name and Select Parameters window, now enter a new Scenario name, Change the Pilots above Threshold if required, set the Bin Size to 100 Frames. Click next. This brings up the Select Map File window. If needed, click Add Files and add the required street maps. Then click next

Version 1.0

Lucent Technologies Proprietary Do not distribute outside the company

19

The next window is Select Metric to Generate, check the required metric/s and click Finish. LDAT 3G only calculates the selected metrics initially, however this does not mean the other metrics can not be plotted. When an uncalculated metric is selected the first time, LDAT 3G will go through the original data files and update the database with the needed information before plotting the metric. Therefore the original data files should not be moved after the creation of a dataset. This will start the dataset creation process. After the dataset is creation, use the Map, Histogram or Scatter menus to select a metric to be plotted.

Creating a new scenario in LDAT 3G: In LDAT 3G, a dataset can have different scenarios. A dataset is a collection of data files, a scenario is different bin size on a dataset. To create a new scenario on an existing dataset follow the instructions below: Open the dataset of interest from File->Open Dataset Once loaded, select File->New Scenario, this will open the Scenario Creation wizard Enter a Scenario Name, select the Pilots Above Threshold and select the bin size. Click Next If needed, click Add to select the street file. Each scenario can have a different set of street files. Click Next Select the metrics to be created initially. Click Finish. The new Scenario will be created, and it will be added to the Scenario Name pull down box in the tools bar. Make sure you select the correct Scenario when a dataset has more than one scenario. NPAR/WPAR/Friendly Viewer Use NPAR5108 or greater to parse the mobile file(s) for special problem investigation. The parsing command is: Npar5108 <CAIT logfile> > <output file> If the windows version of NPAR, called WPAR, is available to the RF Engineer, follow the steps below to parse the mobile file instead of using NPAR5108: Click on WPAR icon to invoke the application Click on File -> Open, this brings a window to choose mobile file, select the desired file and hit OK. WPAR will parse the mobile file into a readable format

Note: WPAR does not save the parsed file, so before you exit WPAR, you have to save the parsed file e.g. mtotal.par. Qualcomm will eventually stop supporting NPAR5108/WPAR and Friendly Viewer will be the alternative. This is a windows based application. To run it, exercise the following steps: - From the File menu, Select Logfiles - From the dialog box, browse to the folder where logfiles are stored and choose appropriate logfiles. Click OK. - The Friendly Viewer will parse the logfile and display the contents using its own text browser. 3gtool 3gtool is another data analysis tool that provides several outputs to aid in the analysis. The key outputs include: Dropped location alert Location and time stamp Weak Pilot alert Location and time stamp Missing Neighbor List alert Location and time stamp Origination success rate Termination success rate Potential reason, Latitude, Longitude and time stamp for Origination and Termination attempt failures Dropped call rate

Version 1.0

Lucent Technologies Proprietary Do not distribute outside the company

20

3gtool will automatically determine if the file is an origination file or a termination file and output necessary information such as mappable information about drop calls, if any. To use 3gtool, type the following in the directory where the mtotal.par file is (e.g. 3Gtest): C:\>3Gtest\3gtool mtotal.par > mtotal.out The output file, mtotal.out, contains the information about each individual origination or termination, summary and failure mode statistics. Note: A batch file can be used to combine the commands for NPAR and 3gtool in one step. 3gtool will be integrated in LDAT 3G 1.3 such that the statistics can be directly produced from CAIT logfiles without the intermediate NPAR/WPAR parsing steps. Geobin Geobin is a tool typically utilized for warranty testing. It slices the data into geographical bins of user specifiable size (X by Y meters). The data is merged per bin and a statistic such as average is computed. Certain number of worst bins are typically discarded and the rest of bins are utilized to compare against a given set of criteria. For running GeoBin on 3G-1X handset data, before LDAT version 1.3 is available, data processors should use the old (2G based) tool. Here is a high level procedure: Open the database created by LDAT 3G Export the data of interest from BinnedData table to a text file Run Geobin on the text file For more details on this step, visit the web page http://rf-optimization.wh.lucent.com/geobin For LDAT 1.3 and later, Geobin tool will be available from the "Tools" menu of LDAT 3G, which will generate the report.

2-4.1.4

Personnel requirements

The human resource requirements can be segregated per the work function. The drive test optimization consists of two main functions Drive test data collection and analysis. Accordingly, the minimum personnel requirements can be identified as follows: 1. Driver: As the name suggests, the person will be responsible for driving the test vehicle. He can take on additional responsibilities such as set up/disassembly of the data collection equipment in the van. He is also responsible for navigation. Data collector: The person rides in the test van collecting the data from various tools in the van. He may be responsible for setting up any tools at the infrastructure such as OCNS, RF call trace, etc. Additional responsibilities include transferring data to the data analysis person, maintenance of the drive test equipment, and depending on the skills participate in the analysis. Data Analysis/Leader: The person is responsible for analyzing the data and ensuring parameter adjustments. This person also plays a key role in the entire optimization process as the Test Leader. Additional duties include: ensure proper selection of drive routes with the customer, hire/manage data collection personnel, schedule data collection, lead problem area troubleshooting and apprise customer/upper management of progress.

2.

3.

2-4.1.5

Performance Tests

Optimizing a CDMA system mainly consists of executing a series of tests to evaluate performance of the clusters/network while making necessary parameter adjustments at each step. The tests can be construed to consist of sequential phases with each leading to better levels of performance. Some tests may need iterations to attain acceptable performance, especially, in certain challenging problem areas. Version 1.0 Lucent Technologies Proprietary Do not distribute outside the company 21

There are three major tests for optimizing a 3G1x Voice Cold Start system. The first two tests are executed on individual clusters while the third is performed after integrating the entire system. Additional tests may be executed optionally based on contractual agreements with the customer. These may include dropped call, origination and termination tests. When the tests are concluded, the system is ready for commercial operation. Below we detail procedures associated with each of these tests.

2-4.1.5.1

Unloaded Pilot Channel Coverage Test

The objective of the Unloaded Pilot Channel Coverage Survey Test is to measure the forward channel pilot coverage for unloaded conditions, with all sectors in the cluster transmitting pilot, page, quick paging, and sync channels. Based on the measured performance, some parameter adjustments can be made to improve coverage, fix neighbor lists and fine tune performance in local areas. The parameters to be adjusted include the Primary and Secondary parameters. For these tests, a RF Kit for 3G1x Voice testing is placed in a roving test vehicle and driven over selected drive routes. The CDMA phone will be maintained in a continuous traffic state as much as possible. The drive routes should include the most heavily traveled highways and primary roadways in the coverage area of the cluster. The drive routes should also cover areas with substantial handoff activity. The routes should include areas where signal strengths may be weakest due to obstructions; for example, coverage in valleys, underpasses, tunnels, urban corridors, etc. Particular emphasis will be placed on marginal coverage areas and places with multiple pilot coverage as predicted by CDMA planning software (CE4).

2-4.1.5.1.1
1. 2. 3.

Entrance Criteria

4.

5. 6. 7.

Necessary steps have been taken to ascertain clear spectrum in/around the cluster before transmitting CDMA signal. Coverage prediction plots from planning tools, such as CE4, must be prepared for the coverage area of the test cluster. CDMA equipment for the test cluster must be installed, configured, and operational. Sectors tests verifying rudimentary call originations, terminations, and sector-to-sector softer handoffs should have bern performed on each cell prior to this phase. Translations parameters for the sectors in the cluster should have been entered and verified using the Recent Change Verification (RCV) procedures. The RF translation parameters should be configured per recommended values in the various Forward Link Translation Applications Notes. A best guess Neighbor List configuration is entered into the translations. The section on Primary parameters specifies some simple results for neighbor list construction. Transmit powers of pilot, page, quick paging, sync, and traffic channels should be calibrated at each sector in the cluster as described in the Forward Link Translation Applications Note [3]. CDMA mobiles used in the testing should be tested for compliance with IS2000 and the IS-98 Mobile Station Performance Specification.

2-4.1.5.1.2

Test Conditions

Each sector should be transmitting pilot, page, quick paging and sync channels at the nominal levels. No other CDMA traffic should be on the test cluster other than the test phones. The drive routes will be representative of typical usage in the system. As a minimum, they will consist of all primary and secondary highways as well as major streets. 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 drive test will utilize a phone making a continuous Full rate Markov call in RC3 mode. If the call drops during the drive test, it will be re-originated (make appropriate selections in CAIT for automatic re-dial on drop).

2-4.1.5.1.3
Version 1.0

Test Procedures
Lucent Technologies Proprietary Do not distribute outside the company 22

The procedure to be used for the unloaded pilot channel coverage surveys is listed below. Follow the instructions in section 2-4.1.2 for CAIT configuration as well as CAIT and RFCT logging. 1. Install the 3G1x Voice RF Kit in the test vehicle. Ensure that CAITs Logmask is set correctly. Check to be certain that the CAIT is logging GPS position data by observing the output information from the GPS server. 2. At the beginning of each drive run, initiate RF Call Trace at the cell site to log performance statistics for the test phone. 3. Start CAIT logging by pressing Alt+L. 4. Click on Begin Calls of CAITs Call Monitor dialog box to start making 8K Full Rate Markov calls (RC3). 5. Begin drive testing. 6. At the end of the run, stop RFCT logs. Ensure that the run does not exceed 4 hours. Else, stop RFCT, run FTrfdump process and restart RFCT. 7. Also, at the conclusion of the drive route, press Stop Calls on CAITs Call Monitor dialog box and toggle CAIT logging off by pressing Alt+L. 8. Save the log files and transfer them to the data analysis computer.

2-4.1.5.1.4

Data Analysis

Data analysis of the unloaded pilot channel survey data will primarily consist of processing the data through the post-processing software LDAT 3G. The resulting files can be used to display information such as Max Finger FCH Pilot Ec/Io as a function of location. The software allows overlaying the field data on a street map. The resulting pilot coverage maps can be compared against predicted levels from RF planning tools. The pilot coverage maps should be used to validate the RF design for the test cluster. Because the measurements were made under unloaded conditions, they represent an ideal, best-case condition. Under full loading conditions, observed pilot Ec/Io levels would be much lower than the unloaded measurement values. Any coverage holes, which exist for the unloaded measurements will be enlarged once the system matures and becomes loaded. If substantial areas of poor pilot coverage 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 antenna patterns, reorienting antenna boresights, and adding additional cells or repeaters. 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 decreasing the weakest pilot signals by 4 dB from the initial setting does not resolve the problem, attempts can be made to increase the levels of the dominant 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. Antenna adjustments may be required to minimize the number of Pilots and improve coverage in pocket areas. It is also important to control Pilot overshoot where possible using BCR and antenna changes. The next step is to refine the neighbor lists. To assist in this process, utilize the unloaded pilot channel survey data provided by CAIT and analyze it through a specialized tool such as 3gtool. The tool attempts to flag neighbor list omissions by locating Pilots reported on a Pilot Strength Measurment Message above certain Ec/Io threshold that are neither in the mobiles Active Set nor in its Neighbor Set at the time. It is important to set the Remaining Set search window size to a larger number, at least same as the Neighbor Set search window, to assist mobile with Remaining Set detection. The 3gtool also locates neighbor lists problems by detecting instances where the mobile, following a dropped call, acquires Sync channel on a Pilot, that was not present in its Active or Neighbor Sets prior to the dropped call. Proper neighbor list prioritization is also important when adjusting the neighbor lists. In cases where more than 20 potential neighbor list entries exist, tradeoffs will have to be made to select the most frequently used neighbor list entries. If the limited neighbor list size becomes a problem in a geographical area, it may Version 1.0 Lucent Technologies Proprietary Do not distribute outside the company 23

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. Besides neighbor lists omissions, the 3gtool can be utilized to detect weak coverage areas as well as sectors that may require wider Neighbor Set search windows. Attempts should be made to adjust parameters with a goal to reduce the number of alerts. The maps of handoff activity, obtained from mobile data, can be useful for setting handoff thresholds, refining neighbor lists, and identifying trouble spots. For an unloaded system, 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 becomes loaded and Ec/Io levels decrease due to increased interference. Typical CDMA Voice networks operate at a maximum of 3way SHO. This provides the best trade-off between resource utilization and performance. Therefore, it is important to reduce the number of areas where 4, or more, strong pilot signals are present. Information obtained from the mobile data such as FER and dropped calls can also be utilized to home in on the problem area. The root cause analysis will help identify the next steps depending on the nature of the problem low coverage, excessive pilots, around-the-corner interference, etc. 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. Note that it may be worthwhile to avoid excessive parameter adjustments until the loaded coverage test. In some cases, values that provide better performance under loaded conditions may need to be selected even if it sacrifices performance under light loads.

2-4.1.5.1.5

Exit Criteria

The overall performance of the CDMA network depends upon the area coverage probability for which the system was designed. For example, a system designed for 90% area coverage would be expected to incur a higher outage probability than a system designed for 95% area coverage. For this reason, specific numeral 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 optimization 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 a given threshold (say -11 or -12 dB) for the designed area coverage probability of the system (typically 85 to 95%). 2. Primary and Secondary parameters have been optimized as required. Specifically, incomplete neighbor lists, inadequate search window sizes, RF problem areas have been addressed.

2-4.1.5.2

Loaded Coverage Test

The objective of the Loaded Coverage Test is to measure the performance of the CDMA system with actual or simulated loading conditions. The test is used to evaluate physical layer performance such as FER, dropped call and mobile transmit power. The test may also be required per the contractual agreements with the customer. During the testing with traffic loading, traffic will be simulated using the methods discussed in Section 24.1.1. For these tests, the RF kit used for the Unloaded Pilot Channel Coverage Survey Test will be placed in a roving test vehicle and driven over the same drive routes used for the unloaded coverage test. During the cluster testing, the objective is to identify, categorize, and fix any remaining coverage problems observed during the drive testing. Iterative testing may be necessary to solve the problem areas. Complex problems requiring not solved within a day will be deferred until the system-wide optimization phase.

Version 1.0

Lucent Technologies Proprietary Do not distribute outside the company

24

2-4.1.5.2.1 2-4.1.5.2.2

Entrance Criteria Test Conditions

The unloaded coverage test must have been successfully completed.

Load 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. The drive routes will be the same as covered in the unloaded coverage test. The drive routes will representative of typical usage in the system. As a minimum, they will consist of all major and secondary highways. Any major streets will also be covered. The drive test will utilize a phone making a continuous Full rate Markov call in RC3 mode. If the call drops during the drive test, CAIT will be configured to re-originate it.

2-4.1.5.2.3

Test Procedures

The procedure to be used for the loaded coverage tests is as follows: 1. Load each cell in the cluster to appropriate levels of OCNS in the forward link. 2. Install the 3G1x Voice RF Kit in the test vehicle. Ensure that CAITs Logmask is set correctly. Check to be certain that the CAIT is logging GPS position data by observing the output information from the GPS server. 3. Also set the attenuator (MTx) in the RF kit to a pre-agreed value to simulate reverse link loading. 4. At the beginning of each drive run, initiate RF Call Trace at the cell site to log performance statistics for the test phone. 5. Start CAIT logging by pressing Alt+L. 6. Click on Begin Calls of CAITs Call Monitor dialog box to start making 8K Full Rate Markov calls (RC3). 7. Begin drive testing. 8. At the end of the run, stop RFCT logs. Ensure that the run does not exceed 4 hours. Else, stop RFCT, run FTrfdump process and restart RFCT. 9. Also, at the conclusion of the drive route, press Stop Calls on CAITs Call Monitor dialog box and toggle CAIT logging off by pressing Alt+L. 10. Save the log files and transfer them to the data analysis computer.

2-4.1.5.2.4

Data Analysis

The procedure to analyze data for the loaded coverage test data is similar to that for the unloaded conditions. The loaded conditions are more likely to expose low coverage areas as cells shrink with loading. There may be higher instances of dropped calls as a result. Some cell site power and/or antenna adjustments may be necessary to improve coverage. Problems such as incomplete neighbor lists and search window size issues are less likely to appear since the number of visible pilots reduce with loading and also because many of these problems were fixed in the unloaded phase. Testing will be iterated until satisfactory performance is achieved. Certain complex problems requiring additional time/effort can be differed to System-wide optimization tests. Some of the key performance metrics to evaluate include average Full Rate FER on each link, extent of coverage, mobile transmit power requirements and dropped call statistics. These performance indicators can be validated against the contractual agreements. This will help identify the trouble spots that may need further fine-tuning.

2-4.1.5.2.5

Exit Criteria

The overall performance of the CDMA network depends upon the area coverage probability for which the system was designed. For example, a system designed for 90% area coverage would be expected to incur a higher outage probability than a system designed for 95% area coverage. For this reason, specific numeral

Version 1.0

Lucent Technologies Proprietary Do not distribute outside the company

25

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 optimization testing, final values will be assigned based on the design criteria for the test market. 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 the designed area coverage probability of the system (typically 85 to 95%). 2. Forward FER (Full rate) measurements should be less than the outage threshold of 10% for the designed area coverage probability of the system (typically 85 to 95%). 3. Reverse FER (Full rate) measurements should be less than the outage threshold of 10% for the designed area coverage probability of the system (typically 85 to 95%). 4. Mobile transmit power measurements should be less than 20 dBm for the designed area coverage probability of the system (typically 85 to 95%).

2-4.1.5.3

System-wide Optimization Test

The System-wide Optimization Tests will be performed after the cluster tests have been completed for all clusters in the network. After the cluster testing, most of the problems requiring Primary and Secondary pass parameter optimization should have been resolved. The system-wide optimization will focus on adjusting CDMA parameters to optimize coverage in the remaining problem areas, especially those existing in the cluster overlap regions.

2-4.1.5.3.1
1. 2.

Entrance Criteria

A sufficient number of cells in the CDMA market must be installed, integrated, operational and optimized to allow RF testing of a majority of the geographical area of the market. 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).

2-4.1.5.3.2

Test Conditions

For the system-wide drive run, all CDMA cells in the network should be on the air, with transmit powers and neighbor lists updated based on the most recent cluster test results. The test is executed under loaded conditions. Loading will be provided using OCNS in the forward link and attenuator in the mobile transmit path for the reverse link. Appropriate loading levels will be utilized based on agreements with the customer. These typically are the same as for the Loaded Coverage test. The drive routes will be a subset of those traversed in the first two phases. They should emphasize the major arteries in the entire system as well as the overlap areas between clusters. The entire system drive can be conducted in sections or as a single drive run. The drive test will utilize a phone making a continuous Full rate Markov call in RC3 mode. If the call drops during the drive test, CAIT will be configured to re-originate it.

2-4.1.5.3.3

Test Procedures

The procedure to be used for the system wide optimization tests is similar to that for the Loaded Coverage test in section 2-4.1.5.2.3.

2-4.1.5.3.4

Data Analysis

The objective of the system wide optimization drive test is to fix any remaining problem areas and collect overall performance statistics with the entire CDMA network activated. Appropriate parameter adjustments will be made to solve problems discovered during the test. These include both the Primary and Secondary parameters discussed in the first two tests. Tests will be iterated until satisfactory performance is achieved. The field teams should escalate problems too complex to resolve to appropriate CDMA engineering support teams.

Version 1.0

Lucent Technologies Proprietary Do not distribute outside the company

26

At the conclusion of the system wide drive, the aggregate statistics should be processed to obtain an estimate of the overall CDMA performance. Primary results would include Cumulative Distribution Functions (CDFs) of pilot channel Ec/Io, forward and reverse FER, and mobile transmit power.

2-4.1.5.3.5

Exit Criteria

The overall performance of the CDMA network depends upon the area coverage probability for which the system was designed. For example, a system designed for 90% area coverage would be expected to incur a higher outage probability than a system designed for 95% area coverage. For this reason, specific numeral 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 optimization testing, final values will be assigned based on the design criteria for the test market. 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 the designed probability of the system (typically 85 to 95%). 2. Forward FER measurements should be less than the outage threshold of 10% for the coverage probability of the system (typically 85 to 95%). 3. Reverse FER measurements should be less than the outage threshold of 10% for the coverage probability of the system (typically 85 to 95%). 4. Mobile transmit power measurements should be less than 20 dBm for the designed probability of the system (typically 85 to 95%).

area coverage designed area designed area area coverage

2-4.1.5.4

Dropped Call Test

This is an optional test conducted if required by the customer. The objective of the dropped call test is to use un-intended call interruptions (dropped calls) to characterize the state of optimized systems. The number and types of dropped calls will be used as metrics for the quality of the system. One can base this entirely off the Full Rate Markov calls. Note that one can also utilize data for Full Rate Markov call from System wide Optimization Test to derive effective dropped call rate. Total number of calls is first computed by normalizing the total call duration over the run with average call length (say 90 sec). The ratio of number of actual dropped calls and the effective total number of calls gives the dropped call rate. The Dropped call test discussed here is geared towards measuring dropped call performance using shorter length calls (say 90 sec). The exact length of the call can be agreed up with the customer.

2-4.1.5.4.1

Entrance Criteria

The system to be tested should be optimized to the degree possible as described in the previous sections. The system configuration, design parameters 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 inadequate neighbor lists should be noted. The mobiles used in tests for dropped calls should be compliant with the IS-98 standard. If OCNS is to be used for the forward link, it should be activated with proper loading values. If attenuator loading is to be used for the reverse link, the mobile should be equipped for attenuation in the reverse link.

2-4.1.5.4.2

Test Conditions

Dropped 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 characterized over the expected range of speeds. The coverage, interference, pilot, 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 levels of usage, interference, and other time-dependent factors that are appropriate for the design of the system.

Version 1.0

Lucent Technologies Proprietary Do not distribute outside the company

27

The system will be loaded to the contractually specified traffic handling capacity. A continuous Full rate Markov Call will be used to determine drops. The remainder of the forward link loading will be provided 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 optimization using RF Call Trace. The reverse link loading will be achieved by inserting an attenuator in the reverse link of the mobile. CAIT will be the key tool for measurements. RFCT should also be logged to collect data for troubleshooting dropped calls if necessary. For example, if only reverse link FER (from RFCT) goes through the roof before a dropped call but forward link traffic channel power (from RFCT) and forward link FER (from CAIT) are reasonable, this may indicate a reverse link coverage limitation. The Qualcomm NPAR/WPAR/Friendly Viewer tool will be used to provide mobile message data if necessary to debug difficult dropped call problems. The data will be analyzed using 3gtool and LDAT 3G, as well. Any necessary call processing information can also be collected for dropped calls via ROP messages. ROP files are stored on the OMP. ROP provides information on last channel elements as well as CCC/CDM being used for a dropped call. It also shows a reason for each dropped call. For dropped call tests, it may be desirable to make calls of fixed durations, say 90 sec, to reflect average user. This can be worked out with the customer. The Call Monitor dialog box of CAIT allows for an automated way to originate and release calls at specified intervals.

2-4.1.5.4.3

Test Procedures

The procedure to be used for the Dropped Call tests is as follows: 1. Load each cell in the cluster to appropriate levels of OCNS in the forward link. 2. Install the 3G1x Voice RF Kit in the test vehicle. Ensure that CAITs Logmask is set correctly. Check to be certain that the CAIT is logging GPS position data by observing the output information from the GPS server. 3. Also set the attenuator (MTx) in the RF kit to a pre-agreed value to simulate reverse link loading. 4. Ensure that CAIT is configured to make fix length calls. The parameters to adjust on the Call Monitor window include: Call Setup timer (10 sec), Conversation timer (e.g., 90 sec), Call teardown timer (5 sec), and Pause timer (e.g., 10 sec). 5. At the beginning of each drive run, initiate RF Call Trace at the cell site to log performance statistics for the test phone. 6. Start CAIT logging by pressing Alt+L. 7. Click on Begin Calls of CAITs Call Monitor dialog box to start making fixed length 8K Full Rate Markov calls (RC3). 8. Begin drive testing. 9. At the end of the run, stop RFCT logs. Ensure that the run does not exceed 4 hours. Else, stop RFCT, run FTrfdump process and restart RFCT. 10. Also, at the conclusion of the drive route, press Stop Calls on CAITs Call Monitor dialog box and toggle CAIT logging off by pressing Alt+L. 11. Save the log files and transfer them to the data analysis computer.

2-4.1.5.4.4

Data Analysis

3gtool will be utilized to parse CAIT data to provide dropped call locations as well as catalog the dropped call performance. CAIT and RF Call Trace data will be analyzed via LDAT 3G 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 mobile Eb/No set points can be used. Message sequences preceding each call drop will be analyzed to determine Active Set state, Pilot Ec/Io, hand-off state, and signal strength conditions leading to the drop. As needed to support the analysis, ROP logs for the corresponding time intervals will be examined.

Version 1.0

Lucent Technologies Proprietary Do not distribute outside the company

28

Analysis will lead to classification of the call drops into categories; where possible, the cause of each classified drop will be provided. 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, and software aids may be used. The dropped calls will be attributed either to system RF performance, mobile operation or malfunction, operation of the system infrastructure 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 include the number of drops in each category and the number that can be corrected in subsequent optimizations.

2-4.1.5.4.5

Exit Criteria

The dropped call test will be deemed 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 in case the failure rate does meet the previously agreed upon criteria (usually specified in the contract). It can include also referring results of data and root-cause analyses to experts for further determination. 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.

2-4.1.5.5

Originations Test

This is an optional test conducted if required by the customer. The objective of the originations test is to characterize the state of an optimized system in terms of origination success rate. The number and types of origination failures will be used as metrics for the quality of the system. It is OK to make 3G1x Voice calls (RC3) for the test (Full Rate Markov calls not necessary). The test is executed using Call Monitor facility of CAIT to automatically generate a call, typically, every 20-30 seconds separated by 10 sec downtime. The exact call repetition rate can be agreed upon with the customer. The ratio of origination successes divided by total call attempts provides the original success rate. 1 minus this ratio alternatively gives the origination failure rate. 3gtool (integrated in more recent versions of LDAT3G) provides this information along with a potential cause for each failure.

2-4.1.5.5.1

Entrance Criteria

The system to be tested should be optimized to the degree possible as described in the previous sections. The system configuration, design parameters 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 inadequate neighbor lists should be noted. The mobiles used in origination tests should be compliant with the IS-98 standard. If loading value is to be used proper OCNS and attenuator values should be finalized working with the customer to simulate forward and reverse link loading.

2-4.1.5.5.2

Test Conditions

Origination tests will be conducted 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 characterized over the expected range of speeds. The coverage, interference, pilot, and hand-off environments must be understood before the test begins. The time of day of the drive test must be selected to reflect levels of usage, interference, and other time-dependent factors that are appropriate for the design of the system. The system will be loaded to the contractually specified traffic handling capacity. A RC3 voice call will be used to determine origination performance. The remainder of the forward link loading will be provided with OCNS; each sector will be loaded to its specified traffic capacity (Erlang loading) with allowance for

Version 1.0

Lucent Technologies Proprietary Do not distribute outside the company

29

hand-off overhead. The digital gain per user for OCNS will be set to the value determined during cluster optimization using RF Call Trace, and agreed upon with the customer. The reverse link loading will be achieved by inserting an attenuator in the reverse link of the mobile. CAIT will be the key tool for collecting measurements. There is no particular need to collect RF Call Trace data for the test. The data will be analyzed using 3g tool as well as LDAT 3G. The particular output of interest is the origination success/failure rate along with failure reasons provided automatically by 3gtool. Any necessary call processing information can also be collected for origination failures via ROP messages. ROP files are stored on the OMP. ROP provides information on last channel elements as well as CCC/CDM being used for a origination failure. It also shows a reason for each failure. The Call Monitor dialog box of CAIT allows for an automated way to originate and release calls at specified intervals. It can be used to generate calls every 10 second and 20-30 seconds in length, as agreed upon with the custmer.

2-4.1.5.5.3

Test Procedures

The procedure to be used for the Origination tests is as follows: 1. Load each cell in the cluster to appropriate levels of OCNS in the forward link. 2. Install the 3G1x Voice RF Kit in the test vehicle. Ensure that CAITs Logmask is set correctly. Check to be certain that the CAIT is logging GPS position data by observing the output information from the GPS server. 3. Also set the attenuator (MTx) in the RF kit to a pre-agreed value to simulate reverse link loading. 4. Ensure that CAIT is configured to make fix length calls. The parameters to adjust on the Call Monitor window include: Call Setup timer (10 sec), Conversation timer (e.g., 20 sec), Call teardown timer (5 sec), Pause timer (e.g., 10 sec), and the number of call attempts. Catalog the number of call attempts for analysis later. 5. Start CAIT logging by pressing Alt+L. 6. Click on Begin Calls of CAITs Call Monitor dialog box to start making fixed length 8K Full Rate Markov calls (RC3). 7. Begin drive testing. 8. Also, at the conclusion of the drive route, press Stop Calls on CAITs Call Monitor dialog box and toggle CAIT logging off by pressing Alt+L. 9. Save the log files and transfer them to the data analysis computer.

2-4.1.5.5.4

Data Analysis

3gtool (also integrated in more recent versions of LDAT3G) will be utilized to parse CAIT data to provide number of origination failures, their locations, total origination attempts as well as origination failure reason. CAIT data will be analyzed via LDAT 3G to generate other plots useful for analysis as well. Plots and histograms of mobile received, transmitted power and mobile Ec/Io can be used. As needed to support the analysis, ROP logs for the corresponding time intervals will be examined. Note that 3gtool may under-report the total failures as well as the total call attempts. It is possible some of the calls will fail prior to sending the first access probe (i.e. origination message). CAIT will not show any call activity (i.e., origination message) in these cases. Therefore, 3gtool will not detect such failures. In order to obtain true origination failure rate, the total call attempt count from CAITs Call Monitor Dialog box may be used. Origination failure rate will then be 1- [Successful calls from 3g tool/Total attempts from CAITs Call Monitor Dialog box]. Analysis will lead to classification of the call failures. This is facilitated by the use of 3gtool that provides a breakdown based on the last message received prior to the failure during the access process. For example, a failure may be due to no acknowledgement to access probes, channel assignment message not received, etc. Another way of pegging failures is similar to the reasoning employed for dropped calls: system RF performance, mobile operation or malfunction, operation of the system infrastructure and unknown causes. The metrics to be used in reporting the results of the originations test may vary from customer to customer. Version 1.0 Lucent Technologies Proprietary Do not distribute outside the company 30

However, a minimum set will include the number of failures in each category and the number that can be corrected in subsequent optimizations.

2-4.1.5.5.5

Exit Criteria

The originations test will be deemed complete when the drive test is completed, the origination failures encountered have been analyzed, corrective action taken, and results reported. Corrective action can include altering system conditions and re-driving to demonstrate improvement in case the failure rate does meet the previously agreed upon criteria (usually specified in the contract). It can include also referring results of data and root-cause analyses to experts for further determination. Two important parts of the report of results are the metrics for origination failures and the results of the root cause analysis. These results will be used to continually update the fault analysis trees and the performance criteria.

2-4.1.5.6

Terminations Test

This is an optional test conducted if required by the customer. The objective of the terminations test is to characterize the state of an optimized system in terms of terminations success rate. The number and types of termination failures will be used as metrics for the quality of the system. It is OK to make 3G1x Voice calls (RC3) for the test. There is no need to utilize Full Rate Markov calls. The test is executed using a Procomm script to generate periodic land to mobile calls from a laptop connected to POTS line via a regular phone jack. The phone is set to auto-answer mode so that the data collector need to manually answer call requests. The Procomm script is programmed to automatically generate a call, typically, every 20-30 seconds separated by 10 sec downtime. The exact call repetition rate can be agreed upon with the customer. The ratio of termination successes divided by total call attempts provides the termination success rate. 1 minus this ratio alternatively gives the termination failure rate. 3gtool (integrated in more recent versions of LDAT3G) provides this information along with a potential cause for each failure.

2-4.1.5.6.1

Entrance Criteria

The system to be tested should be optimized to the degree possible as described in the previous sections. The system configuration, design parameters 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 inadequate neighbor lists should be noted. The mobiles used in origination tests should be compliant with the IS-98 standard. If loading value is to be used proper OCNS and attenuator values should be finalized working with the customer to simulate forward and reverse link loading.

2-4.1.5.6.2

Test Conditions

Termination tests will be conducted 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 characterized over the expected range of speeds. The coverage, interference, pilot, and hand-off environments must be understood before the test begins. The time of day of the drive test must be selected to reflect levels of usage, interference, and other time-dependent factors that are appropriate for the design of the system. The system will be loaded to the contractually specified traffic handling capacity. A RC3 voice call will be used to determine origination performance. The remainder of the forward link loading will be provided 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 optimization using RF Call Trace, and agreed upon with the customer. The reverse link loading will be achieved by inserting an attenuator in the reverse link of the mobile.

Version 1.0

Lucent Technologies Proprietary Do not distribute outside the company

31

CAIT will be the key tool for collecting measurements. There is no particular need to collect RF Call Trace data for the test. The data will be analyzed using 3g tool as well as LDAT 3G. The particular output of interest is the termination success/failure rate along with failure reasons provided automatically by 3gtool. Any necessary call processing information can also be collected for termination failures via ROP messages. ROP files are stored on the OMP. ROP provides information on last channel elements as well as CCC/CDM being used for a termination failure. It also shows a reason for each failure. A Procomm script can be run on a laptop connected to a landline phone jack to automatically generate land to mobile calls. It can be used to generate calls every 10 seconds, 20-30 seconds in duration, as agreed upon with the customer. On the mobile side, the test phone will be configured to auto-answer mode so no user intervention is required to answer calls.

2-4.1.5.6.3

Test Procedures

The procedure to be used for the Termination tests is as follows: 1. Load each cell in the cluster to appropriate levels of OCNS in the forward link. 2. Install the 3G1x Voice RF Kit in the test vehicle. Ensure that CAITs Logmask is set correctly. Check to be certain that the CAIT is logging GPS position data by observing the output information from the GPS server. 3. Also set the attenuator (MTx) in the RF kit to a pre-agreed value to simulate reverse link loading. 4. Ensure that the test phone is configured to auto-answer mode. It is possible to program this via the handset menu options. Also, it is advisable to test run the Procomm script and ensure successful terminations. Ensure proper script settings for call duration (e.g., 20 sec) and call spacing (e.g., 10 sec). 5. Start CAIT logging by pressing Alt+L. 6. Start the Procomm script at the landline laptop. 7. Begin drive testing. 8. At the conclusion of the drive route, stop the Procomm script. Also, toggle CAIT logging off by pressing Alt+L. 9. Save the log files and transfer them to the data analysis computer.

2-4.1.5.6.4

Data Analysis

3gtool (also integrated in more recent versions of LDAT3G) will be utilized to parse CAIT data to provide number of termination failures, their locations, total termination attempts as well as termination failure reason. CAIT data will be analyzed via LDAT 3G to generate other plots useful for analysis as well. Plots and histograms of mobile received, transmitted power and mobile Ec/Io can be used. As needed to support the analysis, ROP logs for the corresponding time intervals will be examined. Note that 3gtool may under-report the total failures as well as the total call attempts. For some failed attempts, mobile may not receive a page and hence, will not send a page response message. CAIT will not show any call activity (i.e., page response message) in these cases. Therefore, 3gtool will not detect such failures. In order to obtain true termination failure rate, the total call attempt count provided by the output of the Procomm script may be used. Termination failure rate will then be 1- [Successful calls from 3g tool/Total attempts from Procomm script]. Analysis will lead to classification of the call failures. This is facilitated by the use of 3gtool that provides a breakdown based on the last message received prior to the failure during the access process. For example, a failure may be due to no acknowledgement to access probes, channel assignment message not received, etc. Another way of pegging failures is similar to the reasoning employed for dropped calls: system RF performance, mobile operation or malfunction, operation of the system infrastructure and unknown causes. The metrics to be used in reporting the results of the terminations test may vary from customer to customer. However, a minimum set will include the number of failures in each category and the number that can be corrected in subsequent optimizations.

2-4.1.5.6.5
Version 1.0

Exit Criteria
Lucent Technologies Proprietary Do not distribute outside the company 32

The terminations test will be deemed complete when the drive test is completed, the termination failures encountered have been analyzed, corrective action taken, and results reported. Corrective action can include altering system conditions and re-driving to demonstrate improvement in case the failure rate does meet the previously agreed upon criteria (usually specified in the contract). It can include also referring results of data and root-cause analyses to experts for further determination. Two important parts of the report of results are the metrics for termination failures and the results of the root cause analysis. These results will be used to continually update the fault analysis trees and the performance criteria.

2-4.2 RF Optimization for a Combined 3G1x Voice/Data network


3G1x Data introduces many dimensions that require additional optimization considerations relative to a Voice only network. Before discussing the optimization procedures, it is important to understand why additional considerations are necessary. Some of these are identified below: Higher rates: A high Data rate call has essentially two traffic channels. The fundamental channel (FCH) operates similar to the Voice channel (A 20ms Full rate frame transmitted at 9.6kbps for RC3, IS2000 Rev 0). The other component is known as the supplemental channel (SCH). A SCH is assigned to support high data rates. It is dynamically assigned based on the amount of data to be transferred and available resources at the cell site. The supplemental channel operates as data transmission bursts at a particular assigned data rate (maximum of 153.6 kbps for RC3, IS2000 Rev 0). The FCH is maintained continuously throughout the duration of the call. Higher rates tend to require more power. These are likely to uncover more coverage issues compared to lower rates. It is important to try to minimize SCH power requirement. From a forward link perspective, dominant Pilot regions tend to lower overall interference in the system, thereby, allowing the link to operate at lower traffic channel power. Care, however, is needed to maintain enough handoff overlap to minimize handoff failures, especially under loaded conditions. From a reverse link point, adequate soft handoff overheads are needed to mitigate mobile transmit power. Reduced Active Set implementation: There are some differences in the way the two traffic channels of a Data call operate. The biggest difference lies in Lucents choice of handoff implementation on the forward link. The fundamental channel performs soft/softer handoff similar to a Voice channel while the supplemental always operates on a single leg, also known as anchor leg. This single leg implementation is also known as Reduced Active Set. Anchor transfer is performed to switch SCH transmission to another Pilot in the mobiles FCH Active Set as it becomes sufficiently stronger than the current anchor. This is similar to hard handoff for a voice call. The Reduced Active Set has the advantage of minimizing resource utilization (hardware and possibly power) especially if other legs are not strong enough to contribute much to the call. The savings are amplified at higher rates in this case. This is different than for FCH where soft/softer handoffs are needed to maintain smooth call transitions and the additional resource utilization is much smaller compared to a high rate SCH. Besides, soft/softer handoff may not be necessary for SCH. If there is momentary degradation in link quality, then it is possible for upper layers of a data call to recover by re-transmission. On the reverse link, both channels enter into soft/softer handoff much like a regular voice call. From a power utilization point of view, handoffs can only help mitigate mobile transmit power. The reduced Active Set implementation on the forward link again poses further emphasis on optimizing for dominant Pilot coverage. This, of course, has to be balanced with the need for

Version 1.0

Lucent Technologies Proprietary Do not distribute outside the company

33

adequate Pilot overlap to maintain call continuity on the FCH as well as reverse link mobile power mitigation. Application Layer Transport Layer TCP/UDP IP Layer PPP Layer RLP Layer Physical Layer Figure 2: Data protocol Difference in Loading: The loading profile could be much different for Data. Also, when optimizing under loaded conditions for Data, it is necessary to leave enough headroom in power to allow maximum likelihood for higher rate assignments. At a minimum, simulated loading (OCNS and reverse link attenuator) should be reduced by an amount equal to average Erlang and power consumption of the test calls. Since, as proposed for Data optimization, one of the test calls will be a Data call, the reduction will be larger than for a Voice only optimization where Full Rate Markov call consumes much less power. Putting it differently, the simulated loading for optimizing with a Data call will be much smaller. Different Data applications: The actual users in a system may utilize a host of different applications. Each of these can generate varying profiles of power utilization. It will be difficult to optimize with each application. Besides optimization should focus on the RF channel performance independent of application. It will be best suited to utilize an application that constantly pumps data on the link being tested. Many common applications utilize TCP protocol at the transport layer. TCP adjusts data transmission (backlog) based on positive acknowledgements (acks) it receives on the other link. If the acks time out, it throttles its transmissions. Acks may be interrupted for reasons other than RF impairment, such as cell site/mobiles algorithmic implementation of Data burst allocations, resource sharing, etc. Also even if the reason is temporary RF degradation, its impact can be felt much longer. This is because data backlog takes some time to ramp up to full capacity as positive acknowledgements resume one of the characteristics of TCP protocol. In order to keep the focus on RF optimization, constant data backlog generating applications are more desirable (e.g. UDP based applications). These applications may not utilize any ack based throttling. Any data lost will not be re-transmitted. This is, OK, however as long as throughput is measured at lower layers (close to the physical layer). User location/speed profile: An average user may exhibit usage characteristics much different than a voice user in terms of location and mobility. The areas of heavy Data usage may be other than the major highways and streets, and more in-building. In the absence of knowledge of a typical user profile at this time, RF optimization will continue to focus on major highways and roads similar to optimizing for Voice only users. Additional metrics to utilize: Data performance will require characterization via several new metrics in addition to the ones employed for Voice. This may include assigned data rate, SCH FER as well as some type of throughput. Throughput is defined as the amount of data transferred over time. There are different Version 1.0 Lucent Technologies Proprietary Do not distribute outside the company 34

layers in the Data protocol stack where throughput can be measured. See Figure 2 for an illustration of several different layers. From an RF optimization perspective, it is more appropriate to measure it closer to the physical layer, such as, Radio Link Protocol (RLP) layer. RLP is a layer just above the physical layer specifically designed for wireless applications. Its purpose is to recover from physical layer errors by re-transmitting to try to suppress errors passed to the upper layers. Test with a Data call: Data optimization will require drive testing using a Data call. In addition, since it is important to preserve performance of Voice users, it will also require a Full Rate Markov call. Further, Data call will require an application to generate an actual data stream. All this has impact on RF tool kit requirements, configuration and data collection procedures for optimization.

Note that although there are some differences in the optimization procedures between Data and Voice, many of the basic goals of drive test based RF optimization are still the same, namely, to improve coverage, correct neighbor list omissions, adjust search window sizes, minimize dropped calls, etc. Further, the overall methodology behind classifying the performance tests is also the same. The performance tests for optimization of a combined 3G1x Voice/Data network consists of a series of drive tests to collect physical layer data, messaging information and measure Voice and Data performance. It is recommended to test with both a Full Rate Markov call and a high-speed Data call concurrently. The data is collected under unloaded and loaded RF loading conditions. The loading procedures are described in the following sub-section along with the tools utilized to simulate loading. In subsequent sub-sections, we specify Test equipment required for data collection and a list of software aids used for analysis. Using these tools and methods, sub-section 2-4.2.5 specifies the actual set of procedures utilized for drive test optimization. The procedures consist of a series of performance tests conducted to optimize the performance of the network.

2-4.2.1

Loading Procedures

While it is the first right step to optimize a network under unloaded conditions, a follow-on testing is needed to evaluate the impact of loading and to fine-tune performance as necessary. This helps prepare network for commercial operation when it will be loaded with actual users. Note that loading here refers to RF stress testing, not hardware or software testing of the infrastructure. One way to load is to employ real users. However, this could become very expensive and logistically intensive. Further, it would not be trivial to attain desired loading levels in a consistent manner. As proposed here, the loading is attempted using simulated techniques. There are different methods employed on the forward and reverse links as stated below. Although the loading procedures are similar to that for 3G1x Voice only optimization, the amount of simulated loading will be different. This essentially stems from the fact that one of the test calls will employ a Data call. The Data call itself generates much higher loading (both Erlang and power wise) compared to a single Full rate Markov call that is utilized for Voice only optimization. The loading should be reduced to account for this higher utilization.

2-4.2.1.1

Forward Link

The forward link loading is simulated using Orthogonal Channel Noise Source (OCNS). As the name suggests, it keys up transmission on orthogonal Walsh Codes to generate interference. It only operates on the forward link. It is similar to a forward link of a voice channel, except that there is no power control feedback mechanism from a phone. The flexibility of OCNS is its ability to generate consistent interference based on a specified number of users and dgu level per user. OCNS can be configured either in constant gain mode or variable gain mode. In the constant gain mode, the gain is held constant throughout OCNS transmission. In the variable gain mode, the gain is scaled based on an assumed voice activity factor. Further the gain is also varied to Version 1.0 Lucent Technologies Proprietary Do not distribute outside the company 35

generate a distribution around the voice activity factor. RF Engineers typically use OCNS in a variable gain mode to capture some dynamics of a real user. OCNS is activated by typing following commands on the TIpdunix prompt of the ECP RTR shell: To start OCNS:CELL <cell #>;START To add users OCNS:CELL <cell #>, SECTOR <1-3>, CARRIER <1-12>; USERS <#> , DGAIN <1-119>, PCV <on|off> To stop STOP:OCNS;CELL <cell #> The input fields need to activate OCNS are cell #, sector #, carrier #, number of users and digital gain units (DGU). The PCV on/off setting sets the variable gain mode on or off. When it is off, the constant gain mode is activated. By default, that is, if PCV option is not specified, variable gain mode is assumed. The amount of loading to be used during loaded testing is usually specified in the contract. It is derived based on total Erlang loading the system is designed to handle as well as assuming average power consumed by a user. Any loading generated by the actual test user(s) is subtracted. Since different systems may utilize different link budget, Erlang loading and average power consumption assumptions, the loading levels may vary and are not specified here.

2-4.2.1.2

Reverse Link

On the reverse link, there is no concept of orthogonal loading. As the number of users in the vicinity of a cell increases, so does its total received power on the reverse link. One way to simulate this loading is to insert attenuation on the mobiles transmit path. This attempts to account for a fixed static increase in mobile transmit power, as it may happen with real users where cell site commands them to increase their transmit power to overcome loading. Standard RF kits provided by the Tools Group have a separate attenuator on the mobile reverse transmit path (known as Mobile Tx attenuator) to simulate loading. It is a variable attenuator with step size of 1 dB and typically ranging from 0-60 dB. Similar to the forward link, the actual loading value is specified in the contract and is based on several assumptions such as designed Erlang loading relative to reverse link pole capacity. Note that for a given RF kit and a given phone, it is necessary to compute proper attenuation value for an unloaded case after accounting for various losses in the assembly as well as sensitivity of the phone. For the loaded tests, the attenuator should then be increased to account for the loading per the contract.

2-4.2.2

Data Collection Tools

There are various hardware/software tools needed to support data collection. At the mobile end, an RF data collection kit is utilized to collect RF parameters as well as messages from the phone. It also supports client (mobile) side of a Data session. It also supports client side of the application necessary to generate/receive actual data stream transmitted over the Data session. This kit is described in section 2-4.2.2.1. The other important piece of data collection is the application itself. As explained earlier, it is recommended to utilize a UDP based application to generate constant data stream. The other end of data session (server) is supported by a laptop connected locally to the Inter-working function (IWF). It also supports the server side of the application. At this time, it is recommended to utilize a Windows based server.

Version 1.0

Lucent Technologies Proprietary Do not distribute outside the company

36

Another tool is RF Call Trace (RFCT). It is completely based on software. It is run to collect RF parameters from the cell. It is a simple command line tool described in section 2-4.2.2.2. In 17.1, it does not support any SCH metrics. It is still needed to report metrics for 3G1x Full Rate Markov call.

2-4.2.2.1

Mobile data collection toolkit

The mobile data collection toolkit for 3G1x Voice/Data optimization allow concurrent testing with two 3G1x capable test phones one making continuous Data call, other making Full Rate Markov call. Figure 3 shows a schematic diagram of standard components in a combined Voice/Data RF kit.

CAIT and Data Session laptop Mobile phone Isolation box

MTx

MRx

GPS Unit

Attenuator Box
DPA MTx AC Power/charger

Circulators

MRx

Mobile phone Isolation box

Attenuator Box

Circulators

Figure 3: Data collection toolkit for Combined Voice/Data kit

The tool kit provides efficient and reliable collection of mobile data. A standard RF tool kit for combined 3G1x Voice/Data optimization provided by the Tools Group includes: - Two reference antennas with known gain magnetically mounted to roof of test vehicle - Two characterized 3G1x capable test mobiles with connectors to provide interface to separate roof-mount antennas - Two attenuators (MRx) each placed between phone and antenna to account for antenna gain, cable loss and in-vehicle penetration loss in the forward liink - Two attenuators (MTx) each placed between phone and antenna to account for antenna gain, cable loss, in-vehicle penetration loss, and loading on the reverse link. - Four 4-port circulators to insert the attenuators (MTx and MRx) on respective links of each phone - Two isolation boxes to provide convenient test fixture to hold each phone and to ensure the phone is well shielded - One laptop to support both CAIT mobile data collection software as well as Data session with one of the 3G1x phones, along with necessary hardware interfaces to the mobile CAIT allows

Version 1.0

Lucent Technologies Proprietary Do not distribute outside the company

37

display and logging of mobile RF parameters and messaging. CAIT stands for CDMA Air Interface Tester and is provided by Qualcomm Inc. Special hardware interfaces for the CAIT/Data laptop to support Data session includes Sealevel RS232 PCMCIA card, a dual port adaptor (DPA) box provided by Qualcomm, and cables GPS Unit including magmount antenna with interface to CAIT laptop to log position information

Although not necessary, a mini-van is used typically as the drive test vehicle to house the RF kit. CAIT configuration and logging Following steps are needed to log mobile data via CAIT: - Launch CAIT application in Windows - Open two instances of CAIT one for each of the two phones. Configure each CAIT profile to look for the phone on proper COM port via Options Configure CAIT Phone menu selections. For each CAIT session: o Hit F5 key to bring Logmask section. Set it to 23E00001841F0 o From the Logging Status window, select proper logging directory - For logging with the Full Rate Markov call, launch the Call Monitor dialog box of CAIT and configure it as follows: o Enter the number to dial for the Markov call o Set the Call type to 8K Markov o Set all call timers and call count to 0 o Check the Autolog During Calls option off o Enable the Redial on Drop selection o In order to start a call, click on the Begin calls. If the call drops, CAIT will automatically redial. At the end of the test, press Stop Calls on the Call Monitor to end the current call and stop automatic redial. - For logging with the Data call, no configuration is needed for the Call Monitor. - In order to turn the logging On, press Alt+L on each CAIT instance. Pressing Alt+L again toggles the logging Off. Mobile configuration - Ensure that each 3G1x phone is programmed with proper Preferred Roaming List, MIN, SID and NID - Phone has two UARTs (COM Ports). Ensure that the each phone has its Serial I/O configuration such that UART1 represents Data (DS) and the UART2 represents Diagnostics interface. This can be verified from the handset by pressing Menu 7 9 1 (Port Map). The handset display should show U1 U2 . - Set the baud rate of each phones diagnostic UART to 115200. This can be accessed from the handset via Menu 7 9 3 (Diag Baud) and cycling through the various available speeds until 115200 is seen. Hit OK to select it. - Set the baud rate of the Data phones DS port port to 230000 kbps. This can be accessed from the handset via Menu 7 9 2 (DS Baud) and cycling through the various available speeds until 115200 is seen. Hit OK to select it. This configuration is not needed for the Data phone. Data Application Laptop configuration Normally, the laptop used for CAIT will also be employed for Data application. It is important to properly configure this laptop to maximize throughput, especially if TCP application is utilized. Verify that the maximum dial-up speed of the 3G1x Modem is set to 57,600 kbps under Properties -> Modem. Special line drivers in the Sea-level card multiply the internal speeds by 4 to support up to 230,400 kbps. Ensure that proper AT commands are specified under Properties -> Advanced -> Settings of the 3G1x Modem. The 3G1x Modem is usually named <Standard 28800 Modem>. One way to locate the name itself is by right-clicking on the 3G1x Dial-up adaptor icon (under Control Panel -> Network and Dialup Connections) and selecting Properties. The one checked under Connect using box is the modem of interest. Once the name is identified, the modem properties can be accessed via Control Panel ->

Version 1.0

Lucent Technologies Proprietary Do not distribute outside the company

38

System -> Hardware -> Device Manager -> Modems-> <Standard 28800 Modem>. The minimum set of AT commands include: at$qcso=2; at$qcscrm=1; at$qcmdr=3;at$qcqnc=0 Additional commands can be appended for activating dormancy depending on the test needs: at$qcpknd=1; at&c0. Below is some interpretation for the various commands: at$qcmdr=3 3G specific. In this mode the MS will originate with SO33 and will negotiate to MDR or LSPD only if SO33 is not available. at$qcso=2 IS-707. In this mode the MS uses IS707 Service Options. It affects Rate Set 1 Service Option numbers. at$qcqnc=0 In this mode, the MS disables QNC and uses Packet Data Service Option numbers. at$qcpknd=1 In this mode the MS enables Packet No Dial. When enabled Reception of a PPP packet without a prior dial command will not originate a PPP packet or QNC call. at+cta=30 This command is used to set the timeout value for dropping the traffic channel X seconds after data-flow ceases and is used in conjunction with Dormant mode operation. at&c0 Keep the Carrier Detect signal always high. at$qcscrm=1 In this mode the MS enables the Scream message and requests R-SCH burst setup. When there is backlog of data in the Reverse side (upload from PC to network) the MS transfers data on R-SCH channel. Note that there is a limitation on the number of characters on the command string. Also, some of the commands may already have been written in phones NVM memory during initial phone programming (e.g., using Qualcomms PST tool). To avoid the character limitation, the dormancy commands can be entered on the post-dialup terminal screen when placing a 3G1x Data call. The settings can also be verified at the post-dial screen by typing, for example, at$qcs0=?. It is recommended to enable the TCP/IP header compression. Refer to [8]. The compression only applies TCP based applications (such as FTP, HTTP). The setting can be accessed via 3G1x Dial-up -> Properties -> Networking Tab -> Internet Protocol -TCP/IP (under components) -> Properties -> General Tab -> Advanced -> General Tab. Another important configuration parameter is the PPP software compression. Refer to [8]. As opposed to the header compression, this one deals with compressing the actual payload. For the purpose of optimization/exit criteria testing, we recommend turning it off to allow comparison with other baseline test results. It also allows measuring true Application layer performance (loosely packed text files can otherwise show inflated throughputs). In practice, for commercial end-users, the compression should be turned on to achieve higher throughputs. Note that the compression applies to both TCP and UDP based applications. The setting is available under 3G1x Dial-up -> Properties -> Networking Tab -> Settings (for PPP: Windows 95/98/NT4/2000, Internet). It is recommended to set the TCP window size to 16k to obtain optimum throughput. As the name suggests, it is only applicable to TCP based applications. Win2000 by default supports 16k size. The default window size of 8k for Win98 can be increased using custom scripts, such as TCPtune. Refer to [8]. It is recommended to disable TCP Timestamping option (RFC 1323) using custom scripts, such as TCPtune. Refer to [8]. This is a TCP only option. It is recommended to enable Selective Acknowledgment option (RFC 2018) using custom scripts, such as TCPtune. Refer to [8]. This is a TCP only option.

Initiating a 3G1x Data call: - Starting a Data Call is identical to dialing an ISP with Dialup Networking. Click on the Dial-up Networking icon (typically labeled 3G1x) - Will be asked to enter login and password. Obtain this from the customer. The login and password are validated by the IWF during dial-up. Select Dial after entering the login/password.

Version 1.0

Lucent Technologies Proprietary Do not distribute outside the company

39

Hit Continue on the pre-dial terminal, if it pops-up. Before selecting continue it is advisable to type at in the pre-dial terminal. If it returns OK, then this suggests proper communication between the phone and the laptop The Data call should come up and the dial-up icon will appear in the bottom status region of the CAIT/Data session laptop. The call is ready to initiate Data session.

UDP Data Application: At this point, it is recommended to utilize UDP application called TTCP. TTCP is a popular Network Performance Testing application. There are Unix and Windows versions available on the internet. Each have their own share of limitations. TTCP sets up a constant stream of data packets between two machines. There are several advantages to using the TTCP application: - Can implement UDP transfers - Does not bottleneck throughput over noisy radio link - Keeps transmit buffers full Disadvantages include: - Most implementations have no GUI - Generally can only set up an upload but not a download from the client. Typical Syntax for a transmission whether run from the Client or Server: ttcp t s n10000000 u l1000 D20 10.1.2.xxx where xxx is the last decimal part of IP address assigned to a 3G Data call if ttcp run from the server to the phone (forward link high speed transfer), or of the server if TTCP run from the phone (reverse link high speed transfer). Note that for forward link transfer, the command will have to be run from the server side. This will require a person in front of the Windows server to run the commands as needed. The command will be run at the beginning of the test. Typically, the call comes back on its own after a dropped call and with the same IP address. So, it may not require stopping and restarting the session again. However, at times the call may not come back or it may initiate with a different IP address. Therefore, one person is constantly needed. Having this additional resource also facilitates co-ordination if multiple users are drive-testing. One alternative to reducing the human resource requirement at the IWF for forward link testing is to telnet into the server from the test van over a test Data call, schedule a ttcp command, and exit. Only Win2000 has telnet support. Therefore win2000 is recommended at the server. Further, Win2000 only allows maximum of two telnet users at any given time. If multiple drive test teams are testing, there may be contention. Also, Win2000 does not handle call drops gracefully. If the user is logged into the server and running TTCP remotely, if the call drops, Win2000 does not release the connection. It may take only two such dropped calls to run out of maximum telnet sessions before manual intervention is required at the server locally. Therefore, it is recommended to telnet, schedule a command and exit. If the call drops and a different IP is assigned, the user will have to re-telnet into the server, kill the old ttcp process and restart the session. In order to kill the process, a UNIX type capability is needed at the Win2000 server. A special software called MKS toolkit needs to be installed for this purpose. The exact configuration of Win2000 to support telnet, and a sequence of commands to telnet, schedule, display process id of TTCP and kill a previous TTCP command is captured after this section under Using TTCP remotely from the mobile (client) for forward link transfer. For reverse link transfer, the command is initiated at the client side. So, there is not much user intervention needed at the server. However once initially, the server also needs to initiate TTCP to sink all the UDP data, otherwise IWF will send ICMP: Host unreachable messages on the downlink back to the mobile. This will create some additional traffic on the downlink. The syntax for data sink at the server is: ttcp r s u Since, there are no user specific command options, only one command is needed to source data packets from multiple drive test teams. Note that no such command is needed at the mobile when running down link transfer. Version 1.0 Lucent Technologies Proprietary Do not distribute outside the company 40

An in-house UDP based application is being developed to improve user friendliness. Using TTCP remotely from the mobile (client) for forward link transfer: This will require Win2000 operating system for the server. First configure the server to accept telnet sessions from the mobile client. This will need admin priviledges on the server. Follow the steps below once logged in to the PC: - Go to Control Panel -> Administrative Tools -> Computer Management > Service & Apps -> Services -> telnet. Select Automatic and Start. - Go toControl Panel -> Admin Tools -> telnet service admin. Select 3-> 7. Set the NTLM to 1 and exit out of the telnet service admin. The server is now ready to accept telnet. To execute TTCP remotely for forward link transfer, following are the step-by-step instructions: - Telnet into the win2000 machine. telnet <IP address of the server> - Enter login and password - Enter the time command. time. Press enter twice to obtain current time without altering it. - Enter the at command to schedule ttcp for the next minute: at <HH:MM> cmd /c ttcp -t -u -s -n10000000 -D20 -l1500 <IP_assigned_to_Data_mobile> where, <HH:MM> is the time you want to schedule the ttcp command (usually within next one or two minutes from the current time) and note the letter l (el) before 1500. <IP_assigned_to_Data_mobile> is the IP address assigned to the mobile after the Data call was started. This can be obtained by typing the winipcfg command from Start->Run dialog box of Windows. - Next exit out of telnet immediately after running the at command. If the call drops, the session could hang and Win2000 is very unforgiving in handling ungraceful telnet drops as explained earlier. Also if the time is too close to next minute, may want to leave room to allow typing the command and exit (specify next minute + 1). The transfer will start at the schedule time. One can look up on CAITs View Statistics > IS2000 Mux -> SCH0 to observe reception of SCH frames on the forward link - Note that it is necessary to prevent phone from going dormat after exiting from telnet and until the actual TTCP transmission starts. One way to prevent is to initiate a reverse link transfer using say ping command. Type in ping t <IP address of the server> from the Start->Run. When the TTCP transmission starts, ensure to abort the ping application by hitting CTRL+C on the DOS window that was launched when ping was started. May want to start logging CAIT data after aborting the ping application. - If a new IP address is assigned then the one previously specified after a call drop, telnet into the win2000 machine, type "ps A | grep ttcp", and kill the second process associated with your ttcp session. The syntax is "kill -9 <pid>" where pid is the id associated with the second ttcp process returned by the ps command that shows the proper IP address of the last data session. Be wary of not killing the process of some other drive test team. The ps and kill processes are UNIX commands and only available via MKS toolkit. - At the end of the run, ensure to kill the last ttcp session using the ps and kill commands discussed above. TCP Application: Some customers may require using TCP based application instead of UDP. It is recommended to utilize WS_FTP for this purpose. WS_FTP is a Windows based File Transfer Protocol (FTP) application. It opens a 16K TCP/IP window size when downloading files to and from the network to the client. This allows higher data throughput than DOS based FTP. Advantages: - User Friendly GUI - Client initiated uploads and downloads - Alleviates server requirements Disadvantages: Version 1.0 Lucent Technologies Proprietary Do not distribute outside the company 41

TCP/IP based, not optimized around noisy or bursty radio link Does not keep Transmit buffers full

The procedure to invoke data transfer using WS_FTP is very straight-forward: - First launch the application in Windows - Login to the server connected locally to the IWF - Select a file to be transferred under the folder residing on the machine from where the file will be transferred (server side for forward link transfer, client side for reverse link transfer) - Finally select the arrow pointing to the opposing machine (client side for forward link transfer, server side for reverse link transfer) to initiate the transfer. - Keep repeating the transfer at the end of each file transfer throughout the test. One could select a large file for transfer to minimize user intervention. Notes: -

Typically on a call drop, the call comes up on its own and the transfer is re-initiated from that point on. No user intervention is required. It is recommended to select a compress binary file for file transfer. It is recommended to set the IP header compression and software compression ON. These options can be selected from Dial-up Properties.

2-4.2.2.2

RF Call Trace

RFCT tool is invoked/stopped from OMP prompt using followed set of commands. In 17.1, it only supports Voice/Full Rate Markov call metrics. Therefore, it will only be used for the Full Rate Markov call. To start: nohup FTrftrace d <1-14 digit DN> -p <interval> -i <duration> -t <tag> & where, -d option is to allow specifying the Directory number of the phone (usually its MIN) to be traced -p for polling interval (2 sec recommended) -i for total duration (max 240 sec) -t is to allow specifying a text string to identify the data set To provide status: FTrftrace -s Shows one or more DNs being traced along with remaining time duration. To stop: FTrfstop d <DN being traced>, OR, The A option allows stopping all RFCT sessions. Ftrftrace A

To dump: nohup FTrfdump d <DN that was traced> -t <same tag as the dataset> -r -o <outfile> The dump process is necessary to generate output file from logged data. Further r option (stands for raw output) is required to create output compatible with LDAT3G. Note that the RFCT trace can run for a maximum of 4 hours. Ensure that the run does not exceed 4 hours. Else, stop RFCT and CAIT data collection, run FTrfdump process and resume testing. Also, it is conceivable multiple drive test teams may be collecting data concurrently. The above commands can be run separately for each DN. Use separate tags for easy identification of data sets. Also, ensure when stopping RFCT trace for a specific team, not to use -A option, else traces for all DNs will be stopped. The status feature helps identify active DN trace sessions.

Version 1.0

Lucent Technologies Proprietary Do not distribute outside the company

42

2-4.2.3

Data Analysis Tools

There are several tools employed for data analysis. These include LDAT 3G, 3gtool, Geobin and NPAR5108/WPAR/Friendlyviewer. LDAT 3G LDAT 3G supports analysis of performance for a Full Rate Markov call as well as a high-speed Data call. This tool allows the user to create performance metrics from mobile data (CAIT) as well as RF Call Trace (RFCT). It is designed to allow the user to access the data through the GUI interface. It provides ability to display/print metrics in three different ways geographical mapping, time series plot, and histogram/cdf distribution. Several metrics can be combined in one map or a plot to facilitate correlation. Some key data analysis metrics provided by LDAT 3G to support combined 3G1x Voice/Data optimization: Based on the Full Rate Markov call: From CAIT: Pilot Ec/Io Max Finger FCH, Aggregate FCH, Dominant Pilot Ec/Io, Number of Pilots above threshold, Ec/Io of Specific Pilot (no time series), Anchor Pollution Index (version 1.3) Power measurements Mobile transmit Pilot, Mobile transmit FCH, Mobile receive Access Probes (no time series) Number of Probes and Final Access Power (mobile receive power at the time of sending the probe) Forward FER FCH From RFCT: Reverse FER FCH Power Measurement RFCT Cell Transmit Gain RFCT number of legs in SHO RFCT number of CEs Based on the 3G1x High speed Data call: From CAIT (in addition to the above metrics available for a Full Rate Markov Call): RLP throughput on both links Physical layer throughput on the forward link (version 1.3) Asigned SCH rate per burst (kbps) on both links FSCH FER per FSCH rate (FSCH stands for Forward Supplemental Channel) Combined FSCH FER (computed after weighting for various FSCH frame rates. For example, a 16x erasure will have much higher weighting (16 times) than that for a 8x erasure (8 times) ) From RFCT: No additional metrics for Data in 17.1 Setting up LDAT 3G The process is similar regardless of whether using LDAT 3G for 3G1x Full Rate Markov call or Data call. Before creating any datasets, LDAT 3G should be setup for the specific needs of the market using the procedure below. Select Defaults menu item from the Configure menus, and Defaults window will show up. On the Dataset tab, update the dataset name and browse to the default-working directory. It is suggested to use C:\DATA as the working directory. This window does not allow the user to create a new directory, the working directory must be created using Windows Explorer. On the Cells tab, select the cells.mdb file to be used for this market. To create a cells.mdb file, see section Creating a Cells Database On the Scenario tab, update the default Scenario Name, Pilots Above Threshold and Bin Size fields as needed. On the Map Files tab, select the MapInfo street files for the market.

Version 1.0

Lucent Technologies Proprietary Do not distribute outside the company

43

On the Metrics tab, select default metrics that should be calculated during dataset creation. During new dataset creation, these metrics will be selected as default, but the user will have a chance to update the list before the creation of the dataset. LDAT 3G only calculates the metrics requested by the user during database creation. However, the other metrics can also be requested after the dataset is created. In this case LDAT will go through the calculations first, then show the desired plot. To save time, user should select metrics that are used the most during the dataset creation. On the Themes tab, the ranges and the color codes for the ranges are defined for each metric. The user can update these values. However, having different colors in different markets can cause confusion as the engineers move from market to market. Therefore, these setting should not be changed unless there is specific customer need.

Creating a Cells Database for LDAT 3G The process is similar regardless of whether using LDAT 3G for 3G1x Full Rate Markov call or Data call. Run Cells Database tool from Start->Programs->LCAT->Lucent CellsDB Analysis Tool Select New from the File menu Enter a file name. Click Save, and a new Cells Database will be created. Add ECPs, Cells and sectors using the GUI of the Cells Tool. Creating a Cells Database for LDAT 3G using the cells.txt file The process is similar regardless of whether using LDAT 3G for 3G1x Full Rate Markov call or Data call. Run Cells Database tool from Start->Programs->LCAT->Lucent CellsDB Analysis Tool Select Cells.txt from the Import menu Select the cells.txt file you would like to import, and click OPEN A cells.mdb file in the same directory as the cells.txt file will be created.

Creating a Dataset in LDAT 3G The process is similar regardless of whether using LDAT 3G for 3G1x Full Rate Markov call or Data call. Copy all CAIT and RF Call Trace files, if applicable, to appropriate folder under the working directory. Open LDAT 3G, click on File, then New Dataset, this brings up the Dataset Creation window Under Dataset Name enter dataset name. Click on Browse and select the folder where the data is as the working directory. Click Next This will open the Select Data File window, now click on Add Files, choose the files and click Next. This will open the Select Cell data window. If needed, click on Browse, choose the cell file and click next. This will open the Enter Scenario Name and Select Parameters window, now enter a new Scenario name, Change the Pilots above Threshold if required, set the Bin Size to 100 Frames. Click next. This brings up the Select Map File window. If needed, click Add Files and add the required street maps. Then click next The next window is Select Metric to Generate, check the required metric/s and click Finish. LDAT 3G only calculates the selected metrics initially, however this does not mean the other metrics can not be plotted. When an uncalculated metric is selected the first time, LDAT 3G will go through the original data files and update the database with the needed information before plotting the metric. Therefore the original data files should not be moved after the creation of a dataset. This will start the dataset creation process. After the dataset is creation, use the Map, Histogram or Scatter menus to select a metric to be plotted.

Creating a new scenario in LDAT 3G: The process is similar regardless of whether using LDAT 3G for 3G1x Full Rate Markov call or Data call.

Version 1.0

Lucent Technologies Proprietary Do not distribute outside the company

44

In LDAT 3G, a dataset can have different scenarios. A dataset is a collection of data files, a scenario is different bin size on a dataset. To create a new scenario on an existing dataset follow the instructions below: Open the dataset of interest from File->Open Dataset Once loaded, select File->New Scenario, this will open the Scenario Creation wizard Enter a Scenario Name, select the Pilots Above Threshold and select the bin size. Click Next If needed, click Add to select the street file. Each scenario can have a different set of street files. Click Next Select the metrics to be created initially. Click Finish. The new Scenario will be created, and it will be added to the Scenario Name pull down box in the tools bar. Make sure you select the correct Scenario when a dataset has more than one scenario. NPAR/WPAR/Friendly Viewer Typically, one of these parsing tools will be utilized only on the CAIT logfiles collected for the Full Rate Markov call. It is not necessary to run it on the Data call unless some special troubleshooting is required or if performance metric such as Dropped call rate is to be derived from this data and NPAR based 3gtool is to be used. Use NPAR5108 or greater to parse the mobile file(s) for special problem investigation. The parsing command is: Npar5108 <CAIT logfile> > <output file> If the windows version of NPAR, called WPAR, is available to the RF Engineer, follow the steps below to parse the mobile file instead of using NPAR5108: Click on WPAR icon to invoke the application Click on File -> Open, this brings a window to choose mobile file, select the desired file and hit OK. WPAR will parse the mobile file into a readable format

Note: WPAR does not save the parsed file, so before you exit WPAR, you have to save the parsed file e.g. mtotal.par. Qualcomm will eventually stop supporting NPAR5108/WPAR and Friendly Viewer will be the alternative. This is a windows based application. To run it, exercise the following steps: - From the File menu, Select Logfiles - From the dialog box, browse to the folder where logfiles are stored and choose appropriate logfiles. Click OK. - The Friendly Viewer will parse the logfile and display the contents using its own text browser. 3gtool 3gtool is another data analysis tool that provides several outputs to aid in the analysis. The key outputs include: Dropped location alert Location and time stamp Weak Pilot alert Location and time stamp Missing Neighbor List alert Location and time stamp Origination success rate Termination success rate Potential reason, Latitude, Longitude and time stamp for Origination and Termination attempt failures Dropped call rate 3gtool will automatically determine if the file is an origination file or a termination file and output necessary information such as mappable information about drop calls, if any. To use 3gtool, type the following in the directory where the mtotal.par file is (e.g. 3Gtest): C:\>3Gtest\3gtool mtotal.par > mtotal.out Version 1.0 Lucent Technologies Proprietary Do not distribute outside the company 45

The output file, mtotal.out, contains the information about each individual origination or termination, summary and failure mode statistics. Note: A batch file can be used to combine the commands for NPAR and 3gtool in one step. 3gtool will be integrated in LDAT 3G 1.3 such that the statistics can be directly produced from CAIT logfiles without the intermediate NPAR/WPAR parsing steps. Typically, 3gtool will be utilized only on the CAIT logfiles collected for the Full Rate Markov call. It is not necessary to run it on the Data call logfiles unless if performance metric such as Dropped call rate is to be derived from this data. Geobin Geobin is a tool typically utilized for warranty testing. It slices the data into geographical bins of user specifiable size (X by Y meters). The data is merged per bin and a statistic such as average is computed. Certain number of worst bins are typically discarded and the rest of bins are utilized to compare against a given set of criteria. For running GeoBin on 3G-1X handset data, before LDAT version 1.3 is available, data processors should use the old (2G based) tool. Here is a high level procedure: Open the database created by LDAT 3G Export the data of interest from BinnedData table to a text file Run Geobin on the text file For more details on this step, visit the web page http://rf-optimization.wh.lucent.com/geobin For LDAT 1.3 and later, Geobin tool will be available from the "Tools" menu of LDAT 3G, which will generate the report. Geobin can be applied to data collected from both 3G1x Full Rate Markov and Data calls for evaluating against individual warranty criteria.

2-4.2.4

Personnel Requirements

The human resource requirements can be segregated per the work function. The drive test optimization consists of two main functions Drive test data collection and analysis. Accordingly, the minimum personnel requirements can be identified as follows: 1. Driver: As the name suggests, the person will be responsible for driving the test vehicle. He can take on additional responsibilities such as set up/disassembly of the data collection equipment in the van. He is also responsible for navigation. Data collector: The person rides in the test van collecting the data from various tools in the van. He may be responsible for setting up any tools at the infrastructure such as OCNS, RF call trace, etc. Additional responsibilities include transferring data to the data analysis person, maintenance of the drive test equipment, and depending on the skills participate in the analysis. Data Analysis/Leader/Server side support: The person is responsible for analyzing the data and ensuring parameter adjustments. This person also plays a key role in the entire optimization process as the Test Leader. Additional duties include: provide any server side support for running TTCP application if needed, ensure proper selection of drive routes with the customer, hire/manage data collection personnel, schedule data collection, lead problem area troubleshooting and apprise customer/upper management of progress.

2.

3.

Version 1.0

Lucent Technologies Proprietary Do not distribute outside the company

46

2-4.2.5

Performance Tests

Optimizing a CDMA system mainly consists of executing a series of tests to evaluate performance of the clusters/network while making necessary parameter adjustments at each step. The tests can be construed to consist of sequential phases with each leading to better levels of performance. Some tests may need iterations to attain acceptable performance, especially, in certain challenging problem areas. Similar to optimizing a 3G1x Voice only Cold start, there are three major tests for optimizing a combined 3G1x Voice/Data Cold Start. The first two tests are executed on individual clusters while the third is performed after integrating the entire system. Additional tests may be executed optionally based on contractual agreements with the customer. These may include dropped call, origination and termination tests. Similar to 3G1x Voice only network, optimization will primary focus on the forward link. For Data calls, it is likely that most user applications will require higher data transfer on the forward link, thereby, stressing it to a larger extent from RF perspective relative to the reverse link. However, it is possible that optimizing forward link performance for Data could lead to unacceptable performance trade-offs on the reverse link. Therefore, it is also important to monitor the reverse link, especially, for mobile transmit power requirements. Consequently, the performance tests specify data transfer on both the links. It is also important to ensure the voice calls are not impacted adversely when optimizing for Data. Therefore, data will also be collected concurrently with a Full Rate Markov call. Both the test phones will utilize RC3. For the Data call, cell site will assign a particular SCH rate on either link depending on the estimate of channel conditions, available h/w and air resources and amount of data to be transmitted. When the tests are concluded, the system is ready for commercial operation. Below we detail procedures associated with each of these tests.

2-4.2.5.1

Unloaded Pilot Channel Coverage Test

The objective of the Unloaded Pilot Channel Coverage Survey Test is to measure the forward channel pilot coverage under minimal load, with all sectors in the cluster transmitting pilot, page, quick paging, and sync channels. Based on the measured performance, some parameter adjustments can be made to improve coverage, fix neighbor lists, maximize pilot dominant areas, and fine tune performance in local areas. The parameters to be adjusted include the Primary and Secondary parameters. For these tests, a combined 3G1x Voice/Data optimization kit, whose sketch is shown in Figure 3, will be placed in a roving test vehicle to collect data over selected drive routes. The drive routes will be similar to that for 3G1x Voice optimization. They should include the most heavily traveled highways and primary roadways in the coverage area of the cluster. The drive routes should also cover areas with substantial handoff activity. The routes should include areas where signal strengths may be weakest due to obstructions; for example, coverage in valleys, underpasses, tunnels, urban corridors, etc. Particular emphasis will be placed on marginal coverage areas and places with multiple Pilot coverage as predicted by CDMA planning software (CE4). Particular areas of the system may be important from the customers view to maximize Data coverage and throughput. Customer may require these to be included as part of the drive routes. Specific in-building stationary locations may be logistically difficult to optimize. For example, it may not be possible to gain access to the inside of a building where heavy Data subscriber usage is expected. Also, the drive test equipment is designed for use in a drive test vehicle that also has an open view of GPS satellites for position based analysis. This will not work for in-building testing as GPS signal may not penetrate well. Alternative tools need to be researched for in-building data collection. Note that although the purpose of this test is to measure and optimize performance under unloaded conditions, a single high speed Data call can generate considerable amount of loading, especially when assigned the highest data rate (e.g, 153.6 kbps on the F-SCH). As a result, some amount of loading will

Version 1.0

Lucent Technologies Proprietary Do not distribute outside the company

47

already exist per se during the drive test. This should, however, be less than the simulated loading typically utilized for a 3G1x Voice only optimization. At this point, it is not required to collect data for reverse link high-speed transfer. Most of the optimization parameters are forward link based. However, it is necessary to validate reverse link performance. This can be done by evaluating the impact of optimization changes on the mobile transmit power and reverse FER for the Full Rate Markov Call.

2-4.2.5.1.1
1. 2. 3.

Entrance Criteria

4.

5. 6. 7.

Necessary steps have been taken to ascertain clear spectrum in/around the cluster before transmitting CDMA signal. Coverage prediction plots from planning tools, such as CE4, must be prepared for the coverage area of the test cluster. CDMA equipment for the test cluster must be installed, configured, and operational. Rudimentary tests of call originations, terminations, sector-to-sector softer handoffs and high speed Data transfer should be performed on each cell prior to the drive testing phase. Translations parameters for the sectors in the cluster should have been entered and verified using the Recent Change Verification (RCV) procedures. The RF translation parameters should be configured per recommended values in the various Forward Link Translation Applications Notes. A best guess Neighbor List configuration is entered into the translations. The section on Primary parameters specifies some simple results for neighbor list construction. Transmit powers of pilot, page, quick paging, sync, and traffic channels should be calibrated at each sector in the cluster as described in the Forward Link Translation Applications Note [3]. CDMA mobiles used in the testing should be tested for compliance with IS2000 and the IS-98 Mobile Station Performance Specification.

2-4.2.5.1.2

Test Conditions

Each sector should be transmitting pilot, page, quick paging, and sync channels at the nominal levels. No other CDMA traffic should be on the test cluster other than the test phones. The drive routes will be representative of typical usage in the system. As a minimum, they will consist of all primary and secondary highways as well as major streets. 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 drive test will utilize two phones one making a Full Rate Markov call, other making high Speed Data call (both RC3). For the Data call, a UDP application is preferred. The steps for configuration and operation of TTCP application are listed in section 2-4.2.2.1.

2-4.2.5.1.3

Test Procedures

The procedure to be used for the unloaded pilot channel coverage surveys is listed below. Follow the instructions in section 2-4.2.2.1 for configuring CAIT to log with a Full Rate Markov call and a Data call concurrently; for configuring the two test phones; and for procedures to log RFCT for the Full Rate Markov call. It is assumed that the application to utilize for Data transfer is TTCP. 1. Install the combined 3G1x Voice/Data RF Kit in the test vehicle. Ensure that CAIT logmask for each phone is set correctly. Check to be certain that both CAIT instances are logging GPS position data by observing the output information from the GPS server. 2. At the beginning of each drive run, initiate RF Call Trace at the cell site to log performance statistics for the Full Rate Markov call. 3. Make a Data call by clicking on the Dial-up Networking icon. Enter necessary login and password. Ensure that the call is up by verifying the Dial-up icon comes up on the bottom right corner of the screen. 4. Initiate the necessary steps for forward link data transfer on the Data call. Refer to procedures in section 2-4.2.2.1 on steps to run TTCP application.

Version 1.0

Lucent Technologies Proprietary Do not distribute outside the company

48

5.

6. 7. 8. 9.

10. 11.

12. 13.

Wait till the Data transfer starts. Once the actual Data transfer begins on the Data call (CAIT should start displaying IS2000 MUX statistics for SCH0 on the forward link), prepare to start logging for the two phones. Start CAIT logging by pressing Alt+L for each of the two phones. For the CAIT session logging Full Rate Markov call, click on Begin Calls of CAITs Call Monitor dialog box to start making 8K Full Rate Markov calls (RC3). Begin drive testing. If the Data call drops during the drive run, and does not come up within 15 seconds, OR comes up with a different IP than the previous call, the TTCP session will have to be restarted. Release the Data call if it came back up with a different IP address. This can be done by selecting Disconnect after right clicking on the Dial-up networking status icon at the bottom right corner of the screen. Restart the Data call and the TTCP session as before. For the Full Rate Markov call, CAIT automatically redials upon a drop, so user intervention is required. At the end of the run, stop RFCT logging for the Full Rate Markov call. Ensure that the run does not exceed 4 hours. Else, stop RFCT, run FTrfdump process and restart RFCT. Also, at the conclusion of the drive route, press Stop Calls on CAITs Call Monitor dialog box for the Full Rate Markov call. End the Data call by selecting disconnect after right clicking on the Dial up networking status icon at the bottom right corner of the screen. Toggle logging off on each CAIT by pressing Alt+L. Save the log files and transfer them to the data analysis computer.

2-4.2.5.1.4

Data Analysis

Data analysis of the unloaded pilot channel survey data will primarily consist of processing the data through the post-processing software LDAT 3G. The resulting files can be used to display information such as Max Finger FCH Pilot Ec/Io as a function of location. The software allows overlaying the field data on a street map. The resulting pilot coverage maps can be compared against predicted levels from RF planning tools. The pilot coverage maps should be used to validate the RF design for the test cluster. Because the measurements were made under unloaded conditions, they represent an ideal, best-case condition. Under full loading conditions, observed pilot Ec/Io levels would be much lower than the unloaded measurement values. Any coverage holes, which exist for the unloaded measurements will be enlarged once the system matures and becomes loaded. If substantial areas of poor pilot coverage 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 antenna patterns, reorienting antenna boresights, and adding additional cells or repeaters. To improve forward link performance for Data calls, it is important to ensure dominant coverage where possible. When attempting to improve Pilot dominant coverage, the focus should be on locating and fixing wide problem areas. It is understood that Data call cannot achieve very high throughputs everywhere in the system. Correlating several LDAT 3G metrics from both the Full Rate Markov call and the Data call can help isolate the potential problem areas. Some of these metrics with their expected behavior in the problem areas include: - High Anchor Pilot Pollution index: Defined as the difference between the aggregate Pilot Ec/Io of all Pilots captured within a given time bin (say within 2 sec) and the dominant Pilot E/Io. The strengths are obtained from the mobile Searcher element and include multipath components. For example, if there are three Pilots at Ec/Io strengths of -6, -9 and -9 dB respectively, then the aggregate Pilot Ec/Io is -3 dB (convert each Pilot strength to linear (10^(X/10)), sum the linear values, and then convert back to dB (10 * log10(Y)). Dominant Pilot Ec/Io is -6 dB. Therefore, the Anchor Pilot Pollution index will be -3 - (-6) = 3dB. Values of 3.5 dB or higher are potential indicators of the problem area. This parameter can be evaluated based on data from the Full Rate Markov call or the Data call. In LDAT 3G, this metric is labeled Total to Best Active Pilot Ec/Io.

Version 1.0

Lucent Technologies Proprietary Do not distribute outside the company

49

- Low FSCH Assigned Rate: Under unloaded conditions, areas where Data call experiences 4x or lower FSCH rates may indicate a potential problem area. Note that if using a TCP based application, the problem areas will look wider then actual due to congestion avoidance mechanisms of TCP. Any temporary RF impairment could cause TCP to shrink its window and result in lower rate assignments due to not enough backlog until window ramps up fully. This is not an issue for UDP based application. - High FSCH FER: FSCH FER for Data call far exceeding the target levels for the assigned rate. Note that each rate may have different FSCH target value in the translations. - Excessive number of Pilots: Areas with lots of Pilots tend to suffer from non-dominant coverage. Typically more than 3 Pilots should be looked at carefully. This can be obtained from either the Full Rate Markov call or the Data call. - Poor forward link RLP throughput: Under unloaded conditions, areas where Data call experiences RLP throughput of less than 70 kbps (for UDP based application) may potentially represent problem areas. The problem areas should be rank ordered based on the extent and severity as identified by several of the above metrics correlating. The next step is to try to identify the underlying source of the problem areas. Since wider problem areas are being sought, it is unlikely that short-term impairments such as round-thecorner interference areas will emerge at the top of the ranker order lists. The most common reason of Data performance degradation will be non-dominant Pilot coverage. Note that often this happens in areas with low signal strength. It will be difficult to create a strong Pilot here. These areas may have to be left as they are unless new cell is added to improve signal strength. As a general guideline, attempt to focus on problem areas that have sufficient signal strength (> - 90 dBm under unloaded conditions). Note that if poor throughput is accompanied by poor performance on both F-FCH and F-SCH channels, such as high FFER on both, or dropped call, then this is likely to be a general performance issue (e.g., coverage problem, pilot overshoot, neighbor list omission, inadequate search window size, etc.). Such a problem should also be apparent from Ec/Io coverage plots or alert script outputs. Also note that when troubleshooting Data related problems, it is important to ascertain that these are not derived from network related congestion. Using a local server at the IWF for data transfer minimizes such concerns. Where 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 decreasing the weakest pilot signals by 4 dB from the initial setting does not resolve the problem, attempts can be made to increase the levels of the dominant 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. Antenna adjustments may be required to minimize the number of Pilots and improve coverage in pocket areas. It is also important to control Pilot overshoot where possible using BCR and antenna changes. Excessive BCR/CBR changes should be avoided to guard against link imbalance issues. Antenna downtilts are more desirable where possible. The above approach can also be used if there is excessive overlap even though there are only two strong Pilots in the region. As a general rule, attempt to focus on problem areas across cells, not sectors. Excess sector overlap may be difficult to improve unless narrower beam width antennas are used. One point to consider carefully is the adverse impact of creating pilot dominant areas on the reverse link performance. Higher soft handoff state is beneficial to the reverse link. It alleviates mobile transmit power requirement, thereby, improving its battery life as well as reverse link coverage/capacity. Therefore, it is

Version 1.0

Lucent Technologies Proprietary Do not distribute outside the company

50

important to exercise caution when optimizing the forward link to avoid unacceptable sacrifice in performance on the reverse link, especially as soft handoff ratios shrink with loading. Another point to consider is the impact of creating dominant Pilot regions on the soft handoff overlap necessary to maintain smooth handoff transitions for the FCH channel (Full Rate Markov call or FCH of the Data call). The problem could become more apparent under loaded conditions, as Pilot coverage pulls back. Therefore, it is advisable to avoid extreme changes and to validate performance under loaded conditions later. Due to the above concerns, it is recommended to be more aggressive in creating dominant Pilot regions which already have more than 3 visible Pilots compared to 2 or 3 Pilot regions. It is worthwhile to point out that many of the optimization steps for Data should also tend to improve Voice performance. This is especially true on the forward link. For example, too much coverage overlap can reduce the overall forward link Voice capacity of the network due to interference. Cleaning these areas up should have salutary impact on overall Voice performance especially in areas with more than 3 Pilots of sufficient strength. Data call itself provides many metrics for the Voice call. For example, Pilot coverage, signal strength and dropped call rate. However, it is more desirable to evaluate FCH FER from the Full Rate Markov call since the FCH of Data call may consist pre-dominantly of eighth rate frames. This is one of the reasons the procedures call for supplementing Data call with a Full Rate Markov call for various performance tests. The other reason is that issues such as neighbor lists, inadequate search window sizes, dropped calls can be more conveniently analyzed and tests iterated using Full Rate Markov calls. On the reverse link, the size of Active set will be the same on both FCH and SCH. Therefore, it is adequate to characterize reverse link performance based on the Full Rate Markov call. It is necessary to verify that mobile transmit power (FCH + Pilot) and reverse FCH FER are not impacted adversely as a result of optimization changes based on forward link performance. The next step is to refine the neighbor lists. To assist in this process, utilize the unloaded pilot channel survey data provided by CAIT and analyze it through a specialized tool such as 3gtool. The tool attempts to flag neighbor list omissions by locating Pilots reported on a Pilot Strength Measurment Message above certain Ec/Io threshold that are neither in the mobiles Active Set nor in its Neighbor Set at the time. It is important to set the Remaining Set search window size to a larger number, at least same as the Neighbor Set search window, to assist mobile with Remaining Set detection. The 3gtool also locates neighbor lists problems by detecting instances where the mobile, following a dropped call, acquires Sync channel on a Pilot, that was not present in its Active or Neighbor Sets prior to the dropped call. Proper neighbor list prioritization is also important when adjusting the neighbor lists. In cases where more than 20 potential neighbor list entries exist, tradeoffs will have to be made to select the most frequently used neighbor list entries. If the limited neighbor list size becomes a problem in a geographical 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. Besides neighbor lists omissions, the 3gtool can be utilized to detect weak coverage areas as well as sectors that may require wider Neighbor Set search windows. Attempts should be made to adjust parameters with a goal to reduce the number of alerts. Information obtained from the Full Rate Markov call such as FCH FER and dropped calls can also be utilized to home in on the problem areas. The root cause analysis will help identify the next steps depending on the nature of the problem low coverage, excessive pilots, around-the-corner interference, etc. One parameter that could help mitigate Data performance issues on the forward link, especially, in areas where there is excess anchor transfer activity is the anchor hysterisis threshold. Too much anchor transfer activity in an area can interrupt data transmission due to the time taken to set up the new anchor leg Version 1.0 Lucent Technologies Proprietary Do not distribute outside the company 51

adversely affecting the throughput. Excessive anchor transfer can be induced by rapidly changing pilot conditions. Larger values for the threshold will tend to minimize the amount of anchor transfers. Note that an undue increase in this threshold means continuing a Data burst on a weaker anchor leg that could affect performance due to interference from a stronger non-anchor legs. Therefore, appropriate balance needs to be struck to trade off performance impacts. Higher thresholds may have larger adverse impact on stationary users than the mobile users. 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 for the FCH, distribution of RLP throughput, assigned Data rate, on the forward link etc. Information obtained from either phone such as dropped calls can also be utilized to home in on additional problem areas. The root cause analysis will help identify the next steps depending on the nature of the problem low coverage, excessive pilots, around-the-corner interference, etc. As mentioned earlier, it may be worthwhile to avoid excessive parameter adjustments until the loaded coverage test. In some cases, settings that provide better performance under loaded conditions may need to be selected even if it sacrifices performance under light loads.

2-4.2.5.1.5

Exit Criteria

The overall performance of the CDMA network depends upon the area coverage probability for which the system was designed. For example, a system designed for 90% area coverage would be expected to incur a higher outage probability than a system designed for 95% area coverage. For this reason, specific numeral 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 optimization 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 95%). 2. Primary and Secondary parameters have been optimized as required. Specifically, incomplete neighbor lists, inadequate search window sizes, RF coverage problem areas as well as low throughput areas have been addressed.

2-4.2.5.2

Loaded Coverage Test

The objective of the Loaded Coverage Test is to measure the performance of the CDMA system with actual or simulated loading conditions. Particular Data rate assigned to a call and, hence, achievable throughput depends on the amount of loading. Therefore, the test is useful in measuring maximum achievable rates under loading conditions. It also helps evaluate if the steps taken to create pilot dominant areas during the unloaded phase hurt overall performance as the soft-handoff overlap zones reduce further with loading. The test may also be required per contractual binding. During the testing with traffic loading, traffic will be simulated using the methods discussed in section 24.2.1. For these tests, the combined 3G1x Voice/Data kit 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 fix any remaining coverage/throughput problems observed during the drive testing. Iterative testing may be necessary to solve the problem areas. Complex problems requiring not solved within a day will be deferred until the system-wide optimization phase. The tests can again focus on the forward link as far as high speed Data performance is considered. It is not necessary to benchmark/evaluate reverse link Data performance. It is assumed that UDP based application is utilized for the Data call similar to the unloaded test. Version 1.0 Lucent Technologies Proprietary Do not distribute outside the company 52

2-4.2.5.2.1 2-4.2.5.2.2

Entrance Criteria Test Conditions

The unloaded coverage test must have been successfully completed.

The test is executed under loaded conditions. Loading will be provided using OCNS in the forward link and attenuator in the mobile transmit path for the reverse link. Appropriate loading levels will be utilized based on agreements with the customer. The drive routes will be the same as covered in the unloaded coverage test. The drive routes will be representative of typical usage in the system. As a minimum, they will consist of all major and secondary highways. Any major streets will also be covered. The drive test will utilize two phones one making a Full Rate Markov call, other making high Speed Data call (both RC3). For the Data call, a UDP application is preferred and the Data transfer will only be on the forward link. The steps for configuration and operation of TTCP application are listed in section 2-4.2.2.1.

2-4.2.5.2.3
1. 2.

Test Procedures

3. 4. 5.

6. 7.

8. 9. 10. 11.

12. 13.

14. 15.

Load each cell in the cluster to appropriate levels of OCNS in the forward link. Install the 3G1x Voice RF Kit in the test vehicle. Ensure that CAITs Logmask is set correctly. Check to be certain that the CAIT is logging GPS position data by observing the output information from the GPS server. Also set the attenuator (MTx) in the RF kit to a pre-agreed value to simulate reverse link loading. At the beginning of each drive run, initiate RF Call Trace at the cell site to log performance statistics for the Full Rate Markov call. Make a Data call by clicking on the Dial-up Networking icon. Enter necessary login and password. Ensure that the call is up by verifying the Dial-up icon comes up on the bottom right corner of the screen. Initiate the necessary steps for forward link data transfer on the Data call. Refer to procedures in section 2-4.2.2.1 on steps to run TTCP application. Wait till the Data transfer starts. Once the actual Data transfer begins on the Data call (CAIT should start displaying IS2000 MUX statistics for SCH0 on the forward link), prepare to start logging for the two phones. Start CAIT logging by pressing Alt+L for each of the two phones. For the CAIT session logging Full Rate Markov call, click on Begin Calls of CAITs Call Monitor dialog box to start making 8K Full Rate Markov calls (RC3). Begin drive testing. If the Data call drops during the drive run, and does not come up within 15 seconds, OR comes up with a different IP than the previous call, the TTCP session will have to be restarted. Release the Data call if it came back up with a different IP address. This can be done by selecting Disconnect after right clicking on the Dial-up networking status icon at the bottom right corner of the screen. Restart the Data call and the TTCP session as before. For the Full Rate Markov call, CAIT automatically redials upon a drop, so user intervention is required. At the end of the run, stop RFCT logging for the Full Rate Markov call. Ensure that the run does not exceed 4 hours. Else, stop RFCT, run FTrfdump process and restart RFCT. Also, at the conclusion of the drive route, press Stop Calls on CAITs Call Monitor dialog box for the Full Rate Markov call. End the Data call by selecting disconnect after right clicking on the Dial up networking status icon at the bottom right corner of the screen. Toggle logging off on each CAIT by pressing Alt+L. Save the log files and transfer them to the data analysis computer.

2-4.2.5.2.4

Data Analysis

The procedure to analyze data for the loaded coverage test data is similar to that for the unloaded tests. The loaded conditions are more likely to expose low coverage areas as cells shrink with loading. This will help validate coverage adjustments, performed earlier during unloaded tests, under the stresses of RF load. In

Version 1.0

Lucent Technologies Proprietary Do not distribute outside the company

53

the worst case, it may require resetting some of the RF parameters to improve the soft handoff overlap and maintain call reliability. As it was pointed out for the unloaded analysis, adequate caution is necessary to ensure reverse link performance is not impacted by efforts to improve dominant Pilot coverage. The impact may be more evident during the loaded tests. This is because as soft handoff ratios pull back under forward link loading, the reduced handoff diversity may increase mobile transmit power requirement relative to the unloaded tests. Since the loaded tests utilize fixed attenuation on the mobiles reverse link, any increase in mobile transmit power in excess of the attenuation value could be attributed to coverage pull back on the forward link. This method could be a telling indicator of reverse link impact. This requires comparing unloaded and loaded mobile transmit power levels (FCH), especially, in the soft handoff zones using data from the Full Rate Markov call. Note there would be some run to run variation in mobile transmit power levels, and potentially some (nominal) increase in mobile transmit power under loading conditions on account of forward link coverage pullback, so focus should be on wider/severe problem areas, not short-term differences. Problems such as incomplete neighbor lists and search window size issues are less likely to be apparent since the number of visible pilots reduce with loading and also because many of these problems were fixed in the unloaded phase. Note that it is expected that certain Data performance metrics such as throughput (at all layers) and assigned Data rates will worsen under loading. Therefore not too much emphasis will be laid on improving these performance indicators. The analysis efforts should tend to focus on ensuring call reliability and reverse link performance (essentially Voice performance). Testing will be iterated until satisfactory performance is achieved. Certain complex problems requiring additional time/effort can be differed to System-wide optimization tests. Some of the key performance metrics to evaluate include average FCH FER on each link, SCH FER on the forward link, extent of coverage in terms of Max Finger Pilot Ec/Io, mobile transmit power requirements, dropped call statistics, Data throughputs and assigned FSCH rates. These performance indicators can be validated against the contractual agreements. This will help identify the trouble spots that may need further fine-tuning.

2-4.2.5.2.5

Exit Criteria

The overall performance of the CDMA network depends upon the area coverage probability for which the system was designed. For example, a system designed for 90% area coverage would be expected to incur a higher outage probability than a system designed for 95% area coverage. For this reason, specific numeral 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 for metrics based on Full Rate Markov call. It is expected that prior to the actual RF optimization testing, final values will be assigned based on the design criteria for the test market. 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 the designed area coverage probability of the system (typically 85 to 95%). 2. Forward FCH FER (Full rate) measurements (based on Full Rate Markov call) should be less than the outage threshold of 10% for the designed area coverage probability of the system (typically 85 to 95%). 3. Reverse FCH FER (Full rate) measurements (based on Full Rate Markov call) should be less than the outage threshold of 10% for the designed area coverage probability of the system (typically 85 to 95%). 4. Mobile transmit power measurements (based on Full Rate Markov Call) should be much less than 20 dBm for the designed area coverage probability of the system (typically 85 to 95%).

Version 1.0

Lucent Technologies Proprietary Do not distribute outside the company

54

2-4.2.5.3

System-wide Optimization Test

The System-wide Optimization Tests will be performed after the cluster tests have been completed for all clusters in the network. After the cluster testing, most of the problems requiring First and Second pass parameter optimization should have been resolved. The system-wide optimization will focus on adjusting CDMA parameters to optimize coverage in the remaining problem areas, especially, those existing in the cluster overlap regions. In addition to drive testing with a Full Rate Markov call and a Data call with high-speed transfer on the forward link, it is necessary to evaluate performance with high-speed transfer on the reverse link. This is the final opportunity to do so before executing warranty tests. It is recommended first to measure performance with a Full Rate Markov call and a forward link Data session, then re-driving with a Data call involving reverse link transfer. This will minimize the hardware requirements and simplify the data collection set-up.

2-4.2.5.3.1
1. 2.

Entrance Criteria

A sufficient number of cells in the CDMA market must be installed, integrated, operational and optimized to allow RF testing of a majority of the geographical area of the market. 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).

2-4.2.5.3.2

Test Conditions

For the system-wide drive run, all CDMA cells in the network should be on the air, with transmit powers and neighbor lists updated based on the most recent cluster test results. The test is executed under loaded conditions. Loading will be provided using OCNS in the forward link and attenuator in the mobile transmit path for the reverse link. Appropriate loading levels will be utilized based on agreements with the customer. The levels will typically be same as for the Loaded Cluster tests. The drive routes will be a subset of those traversed in the first two phases. They should emphasize the major arteries in the entire system as well as the overlap areas between clusters. The entire system drive can be conducted in sections or as a single drive run. The drive test will utilize a phone making a continuous Full rate Markov call as well as a Data call involving transfer on the forward link. Then re-drive with a Data call involving high-speed transfer on the reverse link.

2-4.2.5.3.3

Test Procedures

The procedure to be used for the system wide optimization tests when collecting data with a concurrent Full Rate Markov call and a Data call involving forward link high speed transfer is similar to that for the Loaded Coverage test in section 2-4.2.5.3.3. Once the data collection is finished, repeat the test with only one Data call and one CAIT instance, this time performing reverse link transfer. Refer to section 2-4.2.2.1 on proper configuration and use of TTCP application for reverse link transfer. There is no need to collect RFCT for the run. The rest of the data collection procedures are same as for the first half of the test. Note that the call is more likely to come back up on its own after a dropped call compared to forward link. This is because the TTCP transfer will supply persistent data backlog to the phone forcing it to re-originate. Even if the call comes up with a different IP address for the phone, this is not a problem since TTCP will utilize servers IP address for the reverse link transfer.

2-4.2.5.3.4

Data Analysis

The objective of the system wide optimization drive test is to fix any remaining problem areas and collect overall performance statistics with the entire CDMA network activated.

Version 1.0

Lucent Technologies Proprietary Do not distribute outside the company

55

Appropriate parameter adjustments will be made to solve problems discovered during the test. These include both the Primary and Secondary parameters discussed in the first two tests. Tests will be iterated until satisfactory performance is achieved. The field teams should escalate problems too complex to resolve to appropriate CDMA engineering support teams. At the conclusion of the system wide drive, the aggregate statistics should be processed to obtain an estimate of the overall CDMA performance. Primary results would include Cumulative Distribution Functions (CDFs) of FCH FER on each link, SCH FER on the forward link, Max Finger Pilot Ec/Io, mobile transmit power, Data throughputs and assigned FSCH rates. Dropped call rates can also be assessed from Full Rate Markov as well as Data calls.

2-4.2.5.3.5

Exit Criteria

The overall performance of the CDMA network depends upon the area coverage probability for which the system was designed. For example, a system designed for 90% area coverage would be expected to incur a higher outage probability than a system designed for 95% area coverage. For this reason, specific numal 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 optimization testing, final values will be assigned based on the design criteria for the test market. 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 the designed probability of the system (typically 85 to 95%). 2. Forward FER measurements should be less than the outage threshold of 10% for the coverage probability of the system (typically 85 to 95%). 3. Reverse FER measurements should be less than the outage threshold of 10% for the coverage probability of the system (typically 85 to 95%). 4. Mobile transmit power measurements should be less than 20 dBm for the designed probability of the system (typically 85 to 95%).

area coverage designed area designed area area coverage

2-4.2.5.4

Dropped Call Test

This is an optional test conducted if required by the customer. The objective of the dropped call test is to use un-intended call interruptions (dropped calls) to characterize the state of optimized systems. The number and types of dropped calls will be used as metrics for the quality of the system. It makes sense to base this test entirely off the Full Rate Markov calls. There is no need to utilize highspeed Data calls. In general, the dropped call rate should be similar to that for Voice calls, but from a enduser perspective, not as important, since upon a drop call, cell site or mobile should automatically restart the call, assuming there is pending to be transferred. Refer to section 2-4.1.5.4 for details on conducting dropped call test utilizing 3G1x Full Rate Markov calls.

2-4.2.5.5

Originations Test

This is an optional test conducted if required by the customer. The objective of the originations test is to characterize the state of an optimized system in terms of origination success rate. The number and types of origination failures will be used as metrics for the quality of the system. One can conduct the originations test using 3G1x Voice calls (RC3) for the test. There is no need to utilize high-speed Data calls or Full Rate Markov calls. There may be some difference in the origination performance rate between Voice and Data calls due to possibility of additional messaging in the call set-up process for Data. In any event, it is less of an issue with Data as the mobile tends to be persistent in making call attempts as long as there is enough data pending at the mobile. Refer to section 2-4.1.5.5 for details on conducting origination test utilizing 3G1x Voice call.

Version 1.0

Lucent Technologies Proprietary Do not distribute outside the company

56

2-4.2.5.6

Terminations Test

This is an optional test conducted if required by the customer. The objective of the terminations test is to characterize the state of an optimized system in terms of termination success rate. The number and types of termination failures will be used as metrics for the quality of the system. One can conduct the terminations test using 3G1x Voice calls (RC3) for the test. There is no need to utilize high-speed Data calls or Full Rate Markov calls. There may be some difference in the termination performance rate between Voice and Data calls due to possibility of additional messaging in the call set-up process for Data. In any event, it is less of an issue with Data as the cell site should see continuous call attempts as long as there is pending data to be transmitted to the mobile. Refer to section 2-4.1.5.6 for details on conducting termination test utilizing 3G1x Voice call.

2-5

Techniques for mitigating Common RF Optimization Problems

This section presents typical RF problems encountered during optimization and methods to mitigate their impact. Many of these problems, if not addressed, will directly impact end user experience. Most of the problems/remedies commonly apply to a 3G1x Voice only network and a combined 3G1x Voice/Data network. We first present these common ones and then review the additional problems encountered during combined 3G1x Voice/Data optimization.

2-5.1 Common set of RF optimization problems for 3G1x Voice only or combined 3G1x Voice/Data optimization
Symptoms for various RF optimization problems are categorized below into No Service, Dropped calls and Poor voice quality. For each, underlying root causes and remedies are also discussed.

2-5.1.1

No Service

This is typically caused by lack of adequate signal from the mobile. This could be due to weak reception for Pilot, Paging or Access channels.

2-5.1.1.1

Inadequate Pilot Signal Strength from Serving Sector Forward link

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 coverage holes, is the BCR/CBR 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. In many cases, there may be not sufficient cell site power available to fill the coverage area. Also, mobile has finite power to close the reverse link. 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. Adjusting antenna downtilts at the serving sector may also allow more energy to be radiated in the vicinity of the coverage hole. In cellular deployment scenarios, any changes in antenna patterns or downtilt angles will also affect the underlying AMPS network, and therefore, limited degrees of freedom may be available. As a more expensive alternative, an entirely new CDMA cell may be required. Another option is to investigate the use of low-cost CDMA repeaters to rebroadcast signals from existing cell sites.

Version 1.0

Lucent Technologies Proprietary Do not distribute outside the company

57

2-5.1.1.2

Paging or Access Channel Message Failure

In 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 channels, but may fail because of excessive paging message failures. In this case the paging channel digital gain setting can be adjusted upwards to allow 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 appropriate transmit power to use for access. The transmit power estimate made by the mobile is based on the received power combined with offset adjustments 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. Automated call generators may be used to originate/terminate calls at periodic intervals to verify coverage of access and paging attempts. For termination calls, the Quick paging channel power may not be adequate in some areas to reliably wake the mobiles up to receive a page. In such environments, the QPCH level may have to be raised. Note that this eats into the total traffic carrying capability of the cell. So, conservative increase in power levels should be attempted.

2-5.1.2
2-5.1.2.1

Dropped Calls
Unrecognized Neighbor Sector Forward link issue

In a new un-optimized system, there are several sources of Dropped call. These are discussed below.

If 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. A maximum of 20 neighbors can be specified in the neighbor list for each sector. It is important that the neighbor list include all strong pilots the mobile is likely to encounter in a given area. Proper prioritized should also be specified to assist mobile in faster detection of more likely neighbors in the area. The missing neighbors can be identified from CAIT logs using 3gtool. Missing neighbors depending on the strength of interference they generate may result in a dropped call. The pilot on which mobile subsequently acquires Sync should be included on the neighbor list. Further, 3gtool also identifies missing neighbors by investigating Pilot Strength Measurement Message sent by mobile that contains a Pilot not present in the Active or Neighbor set at the time. The Remaining set search window should be set non-zero to allow mobile with faster detection of such Pilots. The feature called undeclared neighbor list can also be activated to generate logs of missing neighbors based on actual mobile calls. It requires the Remaining set search window size to be set to non-zero. The size should be set at least equal to that for Neighbor Set search window. Note that the output is derived from the actual traffic calls on the system, so the results will depend on the driven area. The traffic loading on the CDMA network will impact the observance of neighbor list related call drops. At lighter loads, the interference 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. Note that for calls in soft-handoff, the neighbor list is combined for the Active set pilots. The total number of neighbors are still limited to 20. This could lead to neighbor list truncation potentially leading to dropped calls. Such neighbors should be afforded higher priority or included in the neighbor list of additional Active set pilots to improve the chances of their inclusion in the combined neighbor list. Version 1.0 Lucent Technologies Proprietary Do not distribute outside the company 58

2-5.1.2.2

Inadequate Search window size Forward link

Inadequate Neighbor Search window size often leads to dropped calls in a system. The 3gtool can be utilized to generate alerts for this problem. It also recommends an appropriately large size to be translated for the Neighbor Search window of the Active Set Pilots supporting the call. Alternatively, the parsed CAIT logs (using npar/WPAR/FriendlyViewer) can also be processed to detect the problem. The problem often manifests as a drop call where the mobile fails to detect a neighbor early enough for adding it to the Active Set. The Active Set pilots will become very weak although there is sufficient coverage, due to strong interference from this Pilot. In many cases, the mobile never detects this neighbor until after the dropped call. The parsed mobile logs will typically indicate that immediately after the dropped call, the mobile acquires the Sync channel on this neighbor Pilot with a strong Ec/Io. The inadequate size for the Active set Search window is not easily detected, but may become apparent when investigating a dropped call. The particular Active Set Pilot appears weak although sufficient coverage is expected from this Pilot in the area. Depending on the existence and strength of the interfering multipath ray along the drive route, the Ec/Io may alternate between strong and weak levels rapidly before being dropped. If the mobile shows weak strength for a Pilot in the area, but a specialized equipment such as Pilot scanner shows adequate energy for the same Pilot that may be a pointer to the problem. The scanner data also shows the extent of multipath that could be utilized to set the Active set search window size. The problem is confirmed if the dropped call problem is resolved after opening the Active Set search window size. When increasing the Neighbor and Active Set search window sizes, it is important to increase them only by the amount needed to solve the problem. If not apparent, the next bigger size should be selected and increased in steps of 1 only if the subsequent drive test does not show sufficient improvements. Note that the cell site search window should be set at least equal to the Active Set search window. Note that the size of the Cell site search window should be set at least equal to that of the Active set search window.

2-5.1.2.3

Inadequate signal strength

Dropped calls can also be caused by insufficient signal strength on either link. If forward link related, 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. In many cases, there may be not sufficient cell site power available to fill the coverage area. Also, mobile has finite power to close the reverse link. 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. Adjusting antenna downtilts at the serving sector may also allow more energy to be radiated in the vicinity of the coverage hole. In cellular deployment scenarios, any changes in antenna patterns or downtilt angles will also affect the underlying AMPS network, and therefore, limited degrees of freedom may be available. As a more expensive alternative, an entirely new CDMA cell may be required. Another option is to investigate the use of low-cost CDMA repeaters to rebroadcast signals from existing cell sites. These options are especially necessary if the reverse link becomes limited well before the forward link.

2-5.1.2.4

Rapidly rising Pilot conditions Forward link issue

These conditions are created when, for instance, a Pilot suddenly emerges from the shadow of a building and acts as a strong interferer to the Active Set. By the time, mobile reports it as a candidate to the cell site, it is too late for the call to continue on the weakening Active set Pilots, resulting in a handoff failure and hence, a dropped call. Other scenario is where mobile makes a turn around the corner and suddenly faces a strong Pilot covering this street. Version 1.0 Lucent Technologies Proprietary Do not distribute outside the company 59

Both scenarios could result into a dropped call. The problem is exacerbated for high mobility traffic where the impact of suddenly emerging Pilot is felt even quicker Improving the coverage of the rapidly rising Pilot so that the mobile detects it much sooner can mitigate the problem. Alternatively, the coverage of the Active Set Pilot(s) can be pulled back to induce handoff before entering into the problem area. The other option is to reduce the thresholds for adding the pilot, chiefly Tadd, and/or the slope/intercept for handoff add if IS95B soft handoff capability is used. This will facilitate the detection of the rapidly rising Pilot even when it is relatively weak, resulting into its quicker addition to the call.

2-5.1.2.5

Excessive number of Pilots Forward link

Excessive number of Pilots also creates frequent soft-swaps if the number of visible Pilots exceeds the allowed maximum Active Set. In certain rapidly changing Pilot conditions, the call may not able to complete handoffs quick enough resulting into a dropped call. As much as possible, attempts should be made to reduce the number of Pilots in order to minimize the swaps, especially in such drop call environments. Note that the more the number of Pilots in an area, the larger the interference they create. 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 mobile (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 each of the pilots will be reduced. With the six-way handoff feature, the excessive number of Pilots can be taken benefit of by allowing higher handoff diversity. This can improve call reliability, but it also utilizes more power in the forward link and cell site resources. Some customers may simply want to limit the maximum soft handoff state to 3 for this reason. It is optimum to aim for one or two dominant servers in a given area, rather than three or more servers of equal strengths. This will also help achieve better forward link capacity in the system. The first method of reducing pilot signal congestion is to reduce the transmit 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 increase the transmit power at the desired dominant serving sectors. Other options include changing antenna downtilts and beamwidths to control the pilot coverage.

2-5.1.3
2-5.1.3.1

Poor Voice Quality


Inadequate Traffic Channel Signal Strength Forward link

The problem occurs due to lack of sufficient traffic power available in the forward link. This could happen in an area with poor coverage and excessive CDMA interference. One way to solve the problem will be to raise the maximum traffic channel gain translation at the cell site. However, this is a Fixed parameter that Lucent does not recommend adjusting indiscriminately due to its impact on capacity. Every attempt should be made to improve the coverage or reduce the number of Pilots in the area. As a last resort, the subject matter expert should be consulted before increasing the traffic channel gains on a cell site. The operation of forward overload control can be responsible for performance degradations observed on the forward link. If the forward overload control threshold is exceeded, it will try to limit the total transmitted power and stop admitting new users. In such a situation, particular mobiles may not be able to get enough transmit power to achieve the desired FER.

Version 1.0

Lucent Technologies Proprietary Do not distribute outside the company

60

2-5.1.3.2

Inter-modulation Interference Forward link

Intermodulation interference is another source of potential problems in Cellular systems. The problem may exist if there are certain AMPS-only cells to CDMA mobiles. If the problem is severe and unacceptable, a CDMA cell will need to be co-located with the interfering AMPS cell.

2-5.1.3.3

Poor Voice Quality Reverse Link

There are a number of possible sources of reverse link voice quality degradations. 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 conditions, the reverse link may degrade or drop altogether. Another connection between forward and reverse link performance is through the mobiles 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.

2-5.2 Additional RF optimization problems specific to combined 3G1x Voice/Data system


All problems for 3G1x Voice only optimization also apply to a combined 3G1x Voice/Data network. The impact is not only on Voice performance but that of Data as well. For example, not having enough signal strength can result in a dropped call for both. In this section, we discuss problems unique to Data calls. As it will become evident, many of the underlying sources are still the same as that affecting Voice performance.

2-5.2.1 system

Poor Data Throughput/SCH Assigned Rate/SCH FER in an unloaded

Since the discussion is on RF optimization, throughput here is referring to the physical or RLP layers. For upper layers there could be several non-RF reasons such as Internet backbone congestion, choice of application, choice of transport protocol (TCP or UDP), etc. These are not discussed in this section. Also, it is assumed the system is operating under unloaded conditions. This is because lower throughput/assigned rate are expected as the RF load increases in a network.

2-5.2.1.1

Excessive number of Pilots Forward link

Fewer dominant pilots in general are desirable to maintain the call quality and minimize the amount of interference in the forward link. In addition, this is also beneficial in achieving a good throughput in the system. As explained in the optimization procedures for 3G1x Data, the infrastructure allows F-SCH to operate in simplex mode only. Most of the Data payload is carried on the supplemental channel. In order to maximize the throughput, it is ideal to have one dominant pilot at each location that can be used as the anchor. For one, cell site will assign a lower rate in area with two or more comparable Pilot strengths. Second, even if a high data rate is allocated, the interference from the non-anchor Pilots may cause frame error affecting the throughput in the forward link. While maintaining a single dominant pilot coverage is not practical everywhere, a simple strategy to follow may be to reduce the number of Pilots where poor throughput is achieved over a large contiguous area, instead of attempting to fix each and every small isolated spot. This will help avoid making extreme Version 1.0 Lucent Technologies Proprietary Do not distribute outside the company 61

coverage changes that may hurt reverse link performance, as well as handoff performance under loaded conditions. The number of Pilots can be reduced using the same RF optimization techniques, such as CBR attenuation, antenna adjustments, etc. as described in section 2-5.1.2.5.

2-5.2.1.2

Fast changing Pilots Excess anchor transfer activity

Since the F-SCH operates in simplex mode, there is no soft handoff transition when the mobile moves from the coverage of one cell to another. Instead, a hard transition, known as anchor transfer, is performed. Excessive anchor transfer in an area suffering from rapidly changing Pilots could impact throughput due to the additional time taken to perform a transfer and to set up the successive burst. The first method to alleviate the problem may be to control the coverage of the Pilots in the area to minimize the rapidly changing pilot conditions. The other approach is to increase the anchor hysterisis threshold in an attempt to reduce the anchor transitions. Note that excessive increase in the threshold could also adversely affect the throughput since this will force data transfer on a weaker pilot for a longer interval until an anchor transfer takes place. Therefore, care should be taken to increase the threshold only where the rapidly changing Pilot conditions pose severe degradation in the throughput in a large coverage area.

2-5.2.1.3

Inadequate Traffic Channel Signal Strength Forward link

The problem occurs due to lack of sufficient traffic power available in the forward link. This could happen in an area with poor coverage and excessive CDMA interference. One way to solve the problem will be to raise the maximum SCH traffic channel to Pilot gain translation at the cell site. However, this is a Fixed parameter that Lucent does not recommend adjusting indiscriminately due to its impact on capacity and amplifier operation. Every attempt should be made to improve the coverage or reduce the number of Pilots in the area. As a last resort, the subject matter expert should be consulted before increasing the traffic channel gain on a cell site. On the reverse link, this may also happen. But under unloaded conditions, this potentially indicates excess path loss. This is treated below.

2-5.2.1.4

Insufficient signal strength

Poor Data performance can also stem from insufficient signal strength. The low signal strength areas drive up the amount of SCH power need to achieve good throughput, which could exceed available power. This could happen on either link. If the problem happens on the forward link, by increasing the transmit power from the best serving sector in steps of approximately 2 dB, it should be possible to determine if coverage can be improved. In many cases, there may be not sufficient cell site power available to fill the coverage area. Also, mobile has finite power to close the reverse link. 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. Adjusting antenna downtilts at the serving sector may also allow more energy to be radiated in the vicinity of the coverage hole. These techniques can help improve performance on both links. In cellular deployment scenarios, any changes in antenna patterns or downtilt angles will also affect the underlying AMPS network, and therefore, limited degrees of freedom may be available. As a more expensive alternative, an entirely new CDMA cell may be required. Another option is to investigate the use of low-cost CDMA repeaters to rebroadcast signals from existing cell sites. This becomes especially important if the reverse link limits well before the forward link and maintaining good reverse link throughput in the area is critical.

Version 1.0

Lucent Technologies Proprietary Do not distribute outside the company

62

2-6

Post commercial monitoring parameters

RF optimization is often an ongoing tuning process extending into commercial operation. There may be several reasons necessitating this: - New cells may be added to improve coverage in low signal strength areas or add to the capacity in the network. - Additional carriers may be introduced to handle subscriber ramp up. - Real users may generate uneven traffic and load patterns different than the assumptions used for pre-commercial optimization. Some missing neighbors/search window size issues may surface due to entirely different drive pattern of real users. - Design enhancements such as those related to antenna characteristics Service Measurements and ROP logs can be utilized to monitor performance and identify problems. Certain specialized Lucent tools such as System Performance and Troubleshooting (SPAT) tool, Handoff Matrix, Undeclared Neighbor List feature can also aid in the process. SPAT integrates many performance indicators from SM and ROP. Some of the key metrics to monitor via SM/SPAT, segregated by the type of call, include: Voice and Data metrics - Dropped call statistics - Origination and Termination Failures - Soft and Semi-soft Handoff failures - Handoff and CE usage - Handoff and Packet pipe overflows - FCH FER - Voice Erlangs per carrier Data specific metrics - Data Erlangs across carriers Neutral (not call type specific) - Forward and Reverse overload duration - Total Erlangs per carrier - Load balancing across carriers Many of the metrics above have resolution on a per carrier per sector basis to allow for identification of troublesome carriers. Based on the above metrics, cells showing unacceptable performance should be investigated further. Any bad piece of hardware should be isolated and replaced. Translations need to be verified. Many dropped calls may be caused by incomplete or truncated Neighbor lists. Investigating some of the issues may require further drive tests in concentrated problem areas. The tools discussed above should help narrow down the investigation area in terms of the troublesome cell or a group of cells. There are certain Secondary Optimization parameters that can be fine-tuned during commercial operation. Since they are more apt for use in 2G to 3G1x migration scenarios (except the load preference delta parameter for 3G1x Data), we defer the discussion of these parameters to section 4-3.

Version 1.0

Lucent Technologies Proprietary Do not distribute outside the company

63

Chapter 3: Migration Scenarios


3-1 Introduction
The discussion in the previous chapter focused on Cold Start of 3G1x system. The assumption was there is no prior CDMA service offered by the network. This chapter focuses on several migration scenarios where an existing CDMA system evolves to support a 3G1x service. It is assumed that the system has been already optimized for the existing service. With a significant performance history at hand, it could potentially ease the transition to the new service. As the new service is integrated, it may trigger need for RF optimization. Many of the optimization techniques discussed in the previous chapter may apply. While some scenarios may not require any optimization, some may necessitate additional optimization considerations. For example, 3G1x to 2G same-carrier handoffs at 3G1x coverage borders pose slightly different/additional optimization needs. There are several migration scenarios possible, including: 1. The type of prior service: For example, if the prior service was 2G, then potential scenarios are 2G -> 3G1x Voice only, 2G -> 3G1x Voice/Data. If the prior service was 3G1x Voice only, then 3G1x Voice -> 3G Data. 2. The extent of deployment of the new service: Many customers may wish to introduce the new service in a subset of current system. Such concentrated deployments will result in coverage borders beyond which only the old service is available. It is necessary to ensure call integrity at these borders, especially for Voice calls. These will require special optimization considerations. On the other hand, some customers may want to integrate the new service throughout the market. Such ubiquitous deployments tend to be very similar to Cold Start systems from an RF optimization perspective. Same carrier or new carrier deployments: The new service either can be introduced on a new carrier, or share an existing carrier. The two configurations can differ in terms of data collection and optimization techniques.

3.

Based on the above combinations, this chapter will focus on the following key scenarios: - Introducing 3G1x Voice in a 2G system on an existing carrier throughout the network - Introducing 3G1x Voice partially in a 2G system on an existing carrier - Introducing 3G1x Voice in a 2G system on a new carrier throughout the network - Introducing 3G1x Voice partially in a 2G system on a new carrier - Introducing 3G1x Voice/Data in a 2G system on an existing carrier throughout the network - Introducing 3G1x Voice/Data partially in a 2G system on an existing carrier - Introducing 3G1x Voice/Data in a 2G system on a new carrier throughout the network - Introducing 3G1x Voice/Data partially in a 2G system on a new carrier - Introducing 3G1x Data in a 3G1x Voice only system 3 The user is encouraged to attain a thorough understanding of the previous chapter since the migration scenarios discussed here share many similarities with the Cold Start optimization methods. For any common information, this chapter will simply refer back to the appropriate sections.

If high-speed Data is introduced in a small segment of a 3G1x Voice only system, a Data call exiting the last tier of high-speed Data capable cells will simply continue on the fundamental channel in low speed mode. No optimization considerations are necessary at the border. Also, the current implementation does not allow for a strict separation between Voice and Data carriers. For these reasons, the scenario of introducing Data in a 3G1x Voice only system is not classified further based on the extent and carrier deployment scheme. Lucent Technologies Proprietary Do not distribute outside the company 64

Version 1.0

3-2

Migration Scenarios Configuration and Optimization considerations

As stated in the previous section, this chapter will focus on some key migration scenarios. Each of these is discussed in the following sub-sections with information on deployment scheme and associated RF optimization requirements. The assumption is that the new service will be introduced on a single carrier where possible. As the new service is expanded on to additional carriers, the process is no different than adding a carrier in a 2G multicarrier system. By understanding the single carrier integration/optimization methods discussed below and with the prior knowledge of 2G multi-carrier optimization [1], an RF optimization engineer should be able to identify the optimization needs for expanding new service to additional carriers.

3-2.1 Introducing 3G1x Voice in a 2G system on an existing carrier throughout the network 3-2.1.1 Configuration

Figure 4 illustrates a deployment scheme for this migration scenario. The existing system supports 2G services on two carriers - F1 and F2 throughout the system. The second carrier, F2, is converted to support 3G1x Voice throughout the network. Both 2G and 3G1x Voice services will reside on F2. The configuration does not result in any 3G1x to 2G borders. This simplifies the optimization requirements.

F1: 2G F2: 2G

F1: 2G F2: 2G/3G1x V

Figure 4: Introducing 3G1x Voice on a 2G carrier ubiquitously It is recommended to set the Allow Sharing 3G1x Carrier parameter to yes and the 2G Load Preference Delta parameter (applies to 2G calls) to 0% initially when migrating from 2G to 3G1x. This allows preserving the current distribution of 2G users across carriers in both idle and traffic modes. This is essential considering that initially most users on the system will still be 2G. Additionally the 3G Load Preference Delta parameter should be set to 40% to bias 3G1x Voice call assignments to the 3G capable carrier. Refer to discussion in section 4-3 for more details on technology based load management.

3-2.1.2

Optimization Considerations

From an overall call integrity/performance/voice quality perspective, 3G1x Voice performs equal to or better than 2G under similar RF conditions. Based on this, it is not necessary to re-optimize F2 for 3G1x Voice, since per the earlier assumption the system must have been optimized for 2G. Further, since the 3G1x Voice coverage will be ubiquitous, there are no 3G1x to 2G handoff borders to be optimized. Although there is no need for re-optimization, some customers may wish to ask for validation of 3G1x Voice performance. Customer may require this in all their markets, or some markets, or some segments of one or more markets. The validation exercise will simply involve drive testing using two concurrent phones one 2G and 3G. The testing should be performed after installing and integrating 3G1x channel cards on the designated carrier, verifying RF translation parameters for 3G1x Voice per the recommendations in the RF Application Version 1.0 Lucent Technologies Proprietary Do not distribute outside the company 65

Notes ([2] through [7]), verifying basic 2G/3G1x Voice call sanity on the new hardware, and activating 3G1x service on the cell. The drive route will span across an adequately wide region in the market being tested. It should include a minimum of 20 cells to obtain good topological diversity. It will cover major roads and highways as in the case of Cold Start optimization. The drive test kit will be simplified version of the one used for combined 3G1x Voice/Data optimization shown in Figure 3. The only difference is that one phone will be 2G and other 3G1x capable. Further, there is no need for high-speed Data support. Both phones will make continuous Full Rate Markov calls. The data collection laptop will support two instances of CAIT. RFCT will be invoked to trace the two phones. For apples-to-apples comparison, it is necessary to ensure the 2G and 3G calls come up on the carrier where 3G1x service is introduced (e.g., F2 in Figure 4). In order to increase the likelihood of this assignment, the 2G phone should be programmed with a Mobile Identification Number (MIN) to force hashing to this carrier. Unless there are huge load imbalances, the 2G call will tend to come up on this carrier. If the call gets assigned traffic on an undesired carrier, simply end the call and try again until it sets up traffic on the desired carrier. For the 3G1x phone, activating the 3G1x service on a single carrier will ensure it hashes to this carrier. Further, there is also a very good possibility that it gets assigned 3G1x traffic on this mixed 2G/3G1x carrier. Setting the 3G Load preference Delta parameter to a non-zero number, say 40%, can further increase this likelihood. If it gets assigned traffic on a 2G carrier, simply end the call and re-originate until it sets up on 2G/3G1x carrier. It is possible customer may also opt to request data for dropped, origination and termination tests. Refer to section 2-4.1.5.4 through 2-4.1.5.6 for associated data collection procedures. The process will be run simultaneously using two instances of CAIT on the same laptop one for each phone. The RF kit will be similar to the dual 2G/3G1x phone validation kit described above. The validation drive test can be performed during regular system hours. Depending on the schedule, it can allow sampling of both busy and off-peak traffic hours. No additional loading needs to be simulated. Alternatively, drive testing can be conducted during maintenance window during allowing the use of controlled loading. OCNS and reverse link attenuation will serve as means for simulating loading. The loading values can be either computed utilizing the SM indicated actual traffic consumption (Total Walsh Code Erlang and average power per user), or the same as for 2G optimization. In any event, the loading levels will be finalized in agreement with the customer. LDAT 3G and 3gtool will be employed to analyze data and generate metrics for performance comparison between the two phones. Since the validation exercise involves Voice calls only, a report can be compiled using the performance metrics in section 2-4.1.3. These metrics are common to 2G and 3G1x Voice call. The report will be presented to the customer.

3-2.2 Introducing 3G1x Voice partially in a 2G system on an existing carrier 3-2.2.1 Configuration

Figure 5 illustrates a deployment scheme for this migration scenario. The existing system supports 2G services on two carriers - F1 and F2 throughout the system. The second carrier, F2, is converted to support 3G1x Voice in some portions of the network. Both 2G and 3G1x Voice services will reside on F2 wherever 3G1x is introduced. As it is evident, the configuration results in 3G1x to 2G same-frequency handoff borders at the edge of 3G1x footprint. These handoff borders require RF optimization. It is recommended to set the Allow Sharing 3G1x Carrier parameter to yes and the 2G Load Preference Delta parameter (applies to 2G calls) to 0% initially when migrating from 2G to 3G1x on these cells. This allows preserving the current distribution of 2G users across carriers in both idle and traffic modes. This is essential considering that initially most users on the system will still be 2G. Additionally the 3G Load

Version 1.0

Lucent Technologies Proprietary Do not distribute outside the company

66

Preference Delta parameter should be set to 40% to bias 3G1x Voice call assignments to the 3G capable carrier. Refer to discussion in section 4-3 for more details.

F1: 2G F2: 2G F1: 2G F2: 2G F1: 2G F2: 2G / 3G1x V

Figure 5: Introducing 3G1x Voice partially on an existing 2G carrier

3-2.2.2

Optimization Considerations

Similar to the scenario discussed for the ubiquitous deployment on an existing 2G carrier, there is no need for RF optimization in the core 3G1x service area. However, some validation tests may be required to compare performance between 2G and 3G1x Voice services at the behest of the customer. Before executing the comparison tests, it is desirable to optimize the 3G1x to 2G handoff borders. The 3G1x to 2G same-frequency handoff methods as well as associated optimization issues are discussed in section 4-1.1. The drive test procedure will be similar to the 2G/3G1x validation test discussed in the previous section. The drive routes, however, will be limited to the border region and will exit radially away from the 3G1x footprint area towards the 2G only service area. The handoff optimization zone will consist of at least the last tier of 2G/3G1x cells and some overlap with the first tier 2G only cells. This zone is depicted in Figure 6. The 2G and 3G1x phones will make Full Rate Markov calls on the same carrier (F2 in the above example). The 3G1x call will attempt to handoff to 2G on F2. It will be assigned to F1 only if F2 has no resources available (PP/CE/power). The 2G call will stay in 2G mode on the same carrier. Note that currently 2G to 3G1x handoffs are not supported. Performance metrics such as dropped call and FER performance will be compared between the two calls to investigate any troubleshooting needs for the 3G1x call. Some common problems and troubleshooting techniques associated with 3G1x to 2G same-frequency handoffs are discussed in section 4-1.1. The optimization drive test will be performed under actual user load during regular hours or using simulated load during the maintenance window. The simulated loading levels (OCNS and attenuation) will be determined based on agreement with the customer. They can be the same as those used for 2G optimization. The data collection and analysis tools remain the same as in the ubiquitous case (see previous section). Once the border area optimization is completed, the 2G/3G1x Voice validation tests can be conducted if the customer requires it. The drive route will span over the entire 3G1x footprint including the border region to sample performance data. Follow the validation drive test procedures in the previous section for test execution. In addition, if customer requires optional dropped call, origination and termination tests, the test data will be analyzed to include performance results in the report presented to the customer.

Version 1.0

Lucent Technologies Proprietary Do not distribute outside the company

67

3G1x Voice to 2G Handoff optimization area

2G only 2G/3G1x Voice Exit Route

Figure 6: Border area optimization zone for 3G1x Voice to 2G same-carrier handoffs

3-2.3 Introducing 3G1x Voice in a 2G system on a new carrier throughout the network 3-2.3.1 Configuration

Figure 7 illustrates a deployment scheme for this migration scenario. The existing system supports 2G services on two carriers - F1 and F2 throughout the system. A new carrier, F3, is overlaid throughout the network to offer 3G1x Voice service. The configuration does not result in any 3G1x to 2G borders. This simplifies the optimization requirements.

F1: 2G F2: 2G

F1: 2G F2: 2G F3: 3G1x V

Figure 7: Introducing 3G1x Voice on a new carrier ubiquitously Since the deployment scheme suggests the newly added carrier is intended for 3G only, there is no need to enable the Allow Sharing 3G1x Carrier parameter. Setting the parameter to no will allow 2G and 3G mobiles to idle on respective technology specific carriers. Similarly, 2G and 3G traffic calls can be Version 1.0 Lucent Technologies Proprietary Do not distribute outside the company 68

segregated by setting both the 2G Load Preference Delta and 3G Load Preference Delta parameters to non-zero values, say 40%. Refer to discussion in section 4-3 for more details.

3-2.3.2

Optimization Considerations

From an overall call integrity/performance/voice quality perspective, 3G1x Voice performs equal to or better than 2G under similar RF conditions. Hence, there is no need to optimize the new carrier for 3G1x carrier per-se. However, this will be treated similar to a new 2G carrier add the drive test process will be akin to validating 2G/2G performance on F1/F3 except that a 3G call will be used for F3. Also note that since the 3G1x Voice coverage will be ubiquitous, there are no 3G1x to 2G handoff borders to optimize. As stated earlier, the validation exercise will simply involve drive testing using two concurrent phones a 2G phone on F1 and a 3G one on F3. The testing should be performed after installing and integrating 3G1x channel cards on the designated carrier, verifying RF translation parameters for 3G1x Voice per the recommendations in the RF Application Notes ([2] through [7]), verifying basic 2G/3G1x Voice call sanity on the new hardware, and activating 3G1x service on the cell. Similar to a new 2G carrier add, the drive testing may be executed on a system wide basis. There is no specific need to perform cluster tests. The drive route will cover major roads and highways as in the case of Cold Start optimizations system wide drive. The drive test kit will be simplified version of the one used for combined 3G1x Voice/Data optimization shown in Figure 3. The only difference is that one phone will be 2G and other 3G1x capable. Further, there is no need for high-speed Data support. Both phones will make continuous Full Rate Markov calls. The data collection laptop will support two instances of CAIT. RFCT will be invoked to trace the two phones. When drive testing, it is important to ensure 2G/3G test calls come up on the respective carriers (e.g. F1/F3 in Figure 7). The 2G phone should be programmed with a MIN to force hashing to F1. Unless there are huge load imbalances, the 2G call will tend to come up on this carrier. If the call gets assigned traffic on an undesired carrier, simply end the call and try again until it sets up traffic on the desired carrier. For the 3G1x phone, activating the 3G1x service on a single carrier (F3) will ensure it hashes to this carrier. Setting the 3G Load preference Delta parameter to a non-zero number, say 40%, can further increase the likelihood of its call assignment to F3. If it gets assigned traffic on a 2G carrier, simply end the call and reoriginate until it sets up on F3. It is possible customer may also opt to request data for dropped, origination and termination tests. Refer to section 2-4.1.5.4 through 2-4.1.5.6 for associated data collection procedures. The process will be run simultaneously using two instances of CAIT on the same laptop one for each phone. The RF kit will be similar to the dual 2G/3G1x phone kit described above. Since the existing carriers were previously optimized for 2G, it is acceptable to perform 2G/3G validation drives during the regular hours (loaded tests). The F1 2G carrier under test will not need any simulated loading. However, the new F3 3G carrier will be configured with some pre-agreed OCNS and reverse link attenutation to approximate an average load on F1. The loading values can be computed utilizing the SM indicated actual traffic consumption (Total Walsh Code Erlang and average power per user). If a customer contract specifies unloaded test, then the drive tests will be scheduled during low traffic maintenance window hours. Depending on the length of such low activity periods in the market, it may take longer to finish the testing. Note that the maintenance window tests also become a necessity if contract requires controlled and balanced loading on the two carriers. LDAT 3G and 3gtool will be employed to analyze data and generate metrics for performance comparison between the two phones. Since the optimization drive involves Voice calls only, a report can be compiled using the performance metrics in section 2-4.1.3. These metrics are common to 2G and 3G1x Voice calls. The report will be presented to the customer.

Version 1.0

Lucent Technologies Proprietary Do not distribute outside the company

69

Assuming the existing 2G carriers were previously optimized and the fact that this configuration does not result in same/inter-frequency handoff borders, there should not be any need for RF optimization adjustments. The 2G/3G performance will be compared for verification. Any disparity in performance may largely stem from loading variations across the 2 carriers, especially, if the test was executed in the daytime hours. However, if the disparity is too large/severe in magnitude (e.g., persistent drop calls/access failures/poor RF coverage on the new carrier within the footprint of a particular cell/sector), it may be attributed to issues with the hardware (CCU, PP configuration), antenna cabling and translation settings for the 3G carrier. The troubled cell sites should be investigated for an appropriate corrective action (e.g, change hardware, check transmitted power, check antenna cabling, scrub translations, etc.).

3-2.4 Introducing 3G1x Voice partially in a 2G system on a new carrier 3-2.4.1 Configuration

Figure 8 illustrates a deployment scheme for this migration scenario. The existing system supports 2G services on two carriers - F1 and F2 throughout the system. A new carrier, F3, is overlaid on a sub-set of the system (contiguous grouping of cells). As it is evident, the configuration results in 3G1x to 2G interfrequency handoff borders at the edge of 3G1x footprint. The core 3G1x will require a verification drive similar to the ubiquitous deployment (previous section) and the 3G to 2G handoff borders will require RF optimization. Since the deployment scheme suggests the newly added carrier is intended for 3G only, there is no need to enable the Allow Sharing 3G1x Carrier parameter. Setting the parameter to no will allow 2G and 3G mobiles to idle on respective technology specific carriers. Similarly, 2G and 3G traffic calls can be segregated by setting both the 2G Load Preference Delta and 3G Load Preference Delta parameters to non-zero values, say 40%. Refer to discussion in section 4-3 for more details.

F1: 2G F2: 2G F1: 2G F2: 2G F1: 2G F2: 2G F3: 3G V

Figure 8: Introducing 3G1x Voice partially on a new carrier

3-2.4.2

Optimization Considerations

In the core 3G1x service area, only a verification drive is needed similar to the ubiquitous overlay scenario or new carrier add in an existing 2G system. Since the core area RF optimization procedures are discussed in the previous section, they are not repeated here. Once the verification tests are completed in the core 3G1x area, the focus will shift to optimizing 3G to 2G inter-frequency handoff border areas. The procedures are overviewed below. The 3G1x to 2G inter-frequency handoff methods as well as optimization issues are discussed in section 41.1. The drive test procedure will be similar to the 2G/3G1x validation test in the core area. The drive routes, however, will be limited to the border region and will exit radially away from the 3G1x footprint area towards the 2G only service area. The handoff optimization zone will consist of at least the last tier of 3G1x cells and some overlap with the first tier 2G only cells.

Version 1.0

Lucent Technologies Proprietary Do not distribute outside the company

70

Appropriate translation configuration will be necessary to increase the likelihood of the 2G and 3G1x test phones arriving on the respective carriers - 2G phone on F1, 3G on F3. Refer to the previous section for this configuration. Both phones will make Full Rate Markov calls. The 3G1x call will attempt to handoff to 2G on F1 or F2 as soon as the inter-frequency handoff triggers are met. As long as the handoff is successful with reasonable FER performance, it is not important whether the call transitions to F1 or F2. The 2G call will stay on F1. Performance metrics such as inter-frequency handoff success rate, dropped call rate and FER performance will be compared between the two calls to investigate any troubleshooting needs for the 3G1x call. Some common problems and troubleshooting techniques associated with 3G1x to 2G inter-frequency handoffs are discussed in section 4-1.1. The optimization drive test will be performed under actual user load during regular hours or using simulated load during the maintenance window. Regardless the newly added carrier will require simulated loading due to low/negligible real user loading, as discussed in the previous section. The simulated loading levels (OCNS and attenuation) will be determined based on agreement with the customer. They can be the same as those used for 2G optimization. The data collection and analysis tools remain the same as in the ubiquitous case (see previous section). In addition, if customer requires optional dropped call, origination and termination tests, the test data will be analyzed to include performance results in the report presented to the customer.

3-2.5 Introducing 3G1x Voice/Data in a 2G system on an existing carrier throughout the network 3-2.5.1 Configuration

Figure 9 illustrates a deployment scheme for this migration scenario. The existing system supports 2G services on two carriers - F1 and F2 throughout the system. The second carrier, F2, is converted to support 3G1x Voice and Data throughout the network. Both 2G and 3G1x Voice services will reside on F2. The configuration does not result in any 3G1x to 2G borders. This simplifies the optimization requirements.

F1: 2G F2: 2G

F1: 2G F2: 2G/3G1x V/D

Figure 9: Introducing 3G1x Voice/Data on an existing 2G carrier ubiquitously It is recommended to set the Allow Sharing 3G1x Carrier parameter to yes and the 2G Load Preference Delta parameter (applies to 2G calls) to 0% initially when migrating from 2G to 3G1x. This allows preserving the current distribution of 2G users across carriers in both idle and traffic modes. This is essential considering that initially most users on the system will still be 2G. Additionally the 3G Load Preference Delta parameter should be set to 40% to bias 3G1x Voice call assignments to the 3G capable carrier. Refer to discussion in section 4-3 for more details.

Version 1.0

Lucent Technologies Proprietary Do not distribute outside the company

71

3-2.5.2

Optimization Considerations

From an overall call integrity/performance/voice quality perspective, 3G1x Voice performs equal to or better than 2G under similar RF conditions. Based on this, it is not necessary to re-optimize F2 for 3G1x Voice, since per the earlier assumption the system must have been optimized for 2G. Further, since the 3G1x Voice coverage will be ubiquitous, there are no 3G1x to 2G handoff borders to be optimized. However, 3G1x Data service may necessitate some re-optimization depending on how well the 2G system was optimized. The primary optimization focus will be on creating dominant Pilot regions in the network, as detailed in the Optimization methods for a 3G1x Voice/Data cold start. The degree of optimization, however, depends on overall flexibility available to adjust parameters not just for the 3G capable carrier (F2), but underlying carriers as well. For example, change in coverage required to improve multi-Pilot regions may result in increased origination failures, if all carriers are not equally adjusted. True, it may be possible to make small fine-tuning using Data specific parameters (such as Anchor hysterisis threshold), most RF optimization changes will have to be on all carriers. Depending on the available fine-tuning flexibility, one of the two options can be pursued. Option 1: Limited fine-tuning flexibility First option is where customer wants to introduce 3G1x Data without any coverage fine-tuning. This then simply reduces the optimization procedures to validation tests only. These tests will be executed in two phases 2G/3G1x Voice validation tests, exactly as in the introduction of 3G1x Voice on an existing carrier, and 3G1x Data performance characterization tests. Since the former are discussed in section 32.1.2, we will only touch on the Data tests, as follows. The Data performance characterization tests will also be similar to the system wide 2G/3G voice validation tests, with the exception that only one mobile will be used and it will make 3G1x Data calls on F2. Successive runs with downlink and uplink high-speed Data transfers will be made (the runs may be combined if additional data collection equipment available). Some small amount of Data specific fine-tuning, such as that involving anchor hysterisis threshold, may be made. Based on the data obtained from a final run after making all changes, the customer will be presented with plots of various performance metrics as required per the contract. LDAT 3G and 3gtool will be employed to analyze data and generate metrics for performance comparison between the two phones. Since the validation exercise involves Data calls only, a report can be compiled using the performance metrics in section 2-4.2.3. Note that any optional tests (dropped call, origination and termination tests) may only be executed for the 2G/3G voice tests. No need to repeat them during the Data characterization test phase. Option 2: Flexibility to make coverage changes on all carriers Second option is where full flexibility is available to make coverage changes across all carriers. This option can then be executed in two phases first phase where system-wide drive tests are performed with two phones on F2 (2G Full Rate Markov call and 3G1x high speed Data call); and second phase where after finishing Data optimization, a 2G/3G1x Voice validation run is performed using Full Rate Markov calls on F2. For the first phase, many of the optimization techniques will be similar to those used for 3G1x Data cold start. Iterative testing will be performed to improve Data throughput in problem areas. Multiple runs will also be needed to test downlink and uplink high-speed Data performance, unless additional equipment is available for simultaneous data collection. It may be desirable to execute some of the tests, especially coverage changes and subsequent validation, during light loading hours to limit the impact on subscribers.

Version 1.0

Lucent Technologies Proprietary Do not distribute outside the company

72

The second phase of option 2 is similar to the 2G/3G1x Voice validation tests as detailed in section 3-2.1.2; so, it is not discussed here. Using the 2 phases, a comprehensive set of drive test performance data is available for benchmark/archiving purposes for 2G, 3G1x Voice and 3G1x Data. Note that regardless of the option pursued, there is not much need to utilize simulated loading due to the presence of commercial traffic on all carriers. Even when coverage changes are made during lighter loading hours/maintenance window, system wide testing is recommended during day time hours to evaluate performance under load.

3-2.6 Introducing 3G1x Voice/Data partially in a 2G system on an existing carrier 3-2.6.1 Configuration

Figure 10 illustrates a deployment scheme for this migration scenario. The existing system supports 2G services on two carriers F1 and F2 throughout the system. The second carrier, F2, is converted to support 3G1x Voice in some portions of the network. Both 2G and 3G1x Voice services will reside on F2 wherever 3G1x is introduced. As it is evident, the configuration results in 3G1x to 2G same-frequency handoff borders at the edge of 3G1x footprint. The handoff borders require RF optimization. Note that these handoffs apply to 3G1x Voice calls only. 3G1x Data calls are simply released by the system as soon as the border triggers, which are identical to the 3G1x Voice ones, are met. Hence, no separate optimization is needed for 3G1x Data calls at the borders.

F1: 2G F2: 2G F1: 2G F2: 2G F1: 2G F2: 2G/3G1x V/D

Figure 10: Introducing 3G1x Voice/Data partially on an existing 2G carrier It is recommended to set the Allow Sharing 3G1x Carrier parameter to yes and the 2G Load Preference Delta parameter (applies to 2G calls) to 0% initially when migrating from 2G to 3G1x on these cells. This allows preserving the current distribution of 2G users across carriers in both idle and traffic modes. This is essential considering that initially most users on the system will still be 2G. Additionally the 3G Load Preference Delta parameter should be set to 40% to bias 3G1x Voice call assignments to the 3G capable carrier. Refer to discussion in section 4-3 for more details.

3-2.6.2

Optimization Considerations

To help understand optimization considerations, this configuration can be visualized as a combination of two scenarios discussed earlier Introducing 3G1x Voice/Data in a 2G system on an existing carrier throughout the network and Introducing 3G1x Voice partially in a 2G system on an existing carrier. Combining the two sets of procedures, we obtain three main optimization steps: - First optimize 3G to 2G same-frequency handoff borders as in section 3-2.2.2. - Next, if option 1 followed as described in section 3-2.5.2, perform 2G/3G1x Voice validation tests throughout the 3G1x coverage area (including border zones). If option 2 used, then optimize F2 for 3G1x Data; in this case, it will really involve joint F1/F2 coverage adjustments. - Finally, if option 1 pursued in the above step, perform 3G1x Data characterization tests. Otherwise, conduct 2G/3G1x Voice validation runs throughout the 3G1x coverage region (including border zones).

Version 1.0

Lucent Technologies Proprietary Do not distribute outside the company

73

Please refer to sections 3-2.2.2 and 3-2.5.2 for detailed procedures on above steps.

3-2.7 Introducing 3G1x Voice/Data in a 2G system on a new carrier throughout the network 3-2.7.1 Configuration

Figure 11 illustrates a deployment scheme for this migration scenario. The existing system supports 2G services on two carriers - F1 and F2 throughout the system. A new carrier, F3, is overlaid throughout the network to offer 3G1x Voice and Data services. The configuration does not result in any 3G1x to 2G borders. This simplifies the optimization requirements.

F1: 2G F2: 2G

F1: 2G F2: 2G F3: 3G1x V/D

Figure 11: Introducing 3G1x Voice/Data on a new carrier ubiquitously Since the deployment scheme suggests the newly added carrier is intended for 3G only, there is no need to enable the Allow Sharing 3G1x Carrier parameter. Setting the parameter to no will allow 2G and 3G mobiles to idle on respective technology specific carriers. Similarly, 2G and 3G traffic calls can be segregated by setting both the 2G Load Preference Delta and 3G Load Preference Delta parameters to non-zero values, say 40%. Refer to discussion in section 4-3 for more details.

3-2.7.2

Optimization Considerations

From an overall call integrity/performance/voice quality perspective, 3G1x Voice performs equal to or better than 2G under similar RF conditions. Hence, there is no need to optimize the new carrier for 3G1x carrier per-se. However, this will be treated similar to a new 2G carrier add the drive test process will be akin to validating 2G/2G performance on F1/F3 except that a 3G call will be used for F3. Also note that since the 3G1x Voice coverage will be ubiquitous, there are no 3G1x to 2G handoff borders to optimize. However, 3G1x Data service may necessitate some re-optimization depending on how well the 2G system was optimized. The primary optimization focus will be on creating dominant Pilot regions in the network, as detailed in the Optimization methods for a 3G1x Voice/Data cold start. The degree of optimization, however, depends on overall flexibility available to adjust parameters not just for the 3G capable carrier (F3), but underlying carriers as well. For example, change in coverage required to improve multi-Pilot regions may result in increased origination failures, if all carriers are not equally adjusted. True, it may be possible to make small fine-tuning using Data specific parameters (such as Anchor hysterisis threshold), most RF optimization changes will have to be on all carriers. Depending on the available fine-tuning flexibility, one of the two options can be pursued. Option 1: Limited fine-tuning flexibility First option is where customer wants to introduce 3G1x Data without any coverage fine-tuning. This then simply reduces the optimization procedures to those for a new carrier add. These tests will be executed in two phases 2G/3G1x Voice validation tests, exactly as in the introduction of 3G1x Voice on a new

Version 1.0

Lucent Technologies Proprietary Do not distribute outside the company

74

carrier, and 3G1x Data performance characterization tests. Since the former are discussed in section 32.3.2, we will only discuss the Data tests below. The Data performance characterization tests will also be similar to the system wide 2G/3G voice validation tests for new carrier add, with the exception that only one mobile will be used and it will make 3G1x Data calls on F3. Successive runs with downlink and uplink high-speed Data transfers will be made (the runs may be combined if additional data collection equipment available). Some small amount of Data specific fine-tuning, such as that involving anchor hysterisis threshold, may be made. Based on the data obtained from a final run after making all changes, the customer will be presented with plots of various performance metrics as required per the contract. LDAT 3G and 3gtool will be employed to analyze data and generate metrics for performance comparison between the two phones. Since the validation exercise involves Data calls only, a report can be compiled using the performance metrics in section 2-4.2.3. Note that any optional tests (dropped call, origination and termination tests) may only be executed for the 2G/3G voice tests. No need to repeat them during the Data characterization test phase. Option 2: Flexibility to make coverage changes on all carriers Second option is where full flexibility is available to make coverage changes across all carriers. This option can then be executed in two phases first phase where system-wide optimization drive tests are performed with one 2G phone making Full Rate Markov call on F1and another phone making 3G1x high speed Data call on F3; and second phase where after finishing Data optimization, a 2G/3G1x Voice validation run is performed using 2G and 3G Full Rate Markov calls on F1 and F3 respectively. For the first phase, many of the optimization techniques will be similar to those used for 3G1x Data cold start. Iterative testing will be performed to improve Data throughput in problem areas. Multiple runs will also be needed to test downlink and uplink high-speed Data performance, unless additional equipment is available for simultaneous data collection. It may be desirable to execute some of the tests, especially coverage changes and subsequent validation, during light loading hours to limit the impact on subscribers. The second phase of option 2 is similar to the 2G/3G1x Voice validation tests as detailed in section 3-2.3.2; so, it is not discussed here. Using the 2 phases, a comprehensive set of drive test performance data is available for benchmark/archiving purposes for 2G, 3G1x Voice and 3G1x Data. Note that regardless of the option pursued, there is not much need to utilize simulated loading on existing carriers due to the presence of commercial traffic. However, it will be needed on F3 to balance load across carriers, much as it is used in the case of 3G1x Voice only introduction described in section 3-2.3.2.

3-2.8 Introducing 3G1x Voice/Data partially in a 2G system on a new carrier 3-2.8.1 Configuration

Figure 12 illustrates a deployment scheme for this migration scenario. The existing system supports 2G services on two carriers F1 and F2 throughout the system. A new carrier, F3, is overlaid throughout the network to offer 3G1x Voice and Data services in some portions of the network. As it is evident, the configuration results in 3G1x to 2G inter-frequency handoff borders at the edge of 3G1x footprint. The handoff borders require RF optimization. Note that these handoffs apply to 3G1x Voice calls only. 3G1x Data calls are simply released by the system as soon as the border triggers, which are identical to the 3G1x Voice ones, are met. Hence, no separate optimization is needed for 3G1x Data calls at the borders. Since the deployment scheme suggests the newly added carrier is intended for 3G only, there is no need to enable the Allow Sharing 3G1x Carrier parameter. Setting the parameter to no will allow 2G and 3G mobiles to idle on respective technology specific carriers. Similarly, 2G and 3G traffic calls can be segregated by setting both the 2G Load Preference Delta and 3G Load Preference Delta parameters to non-zero values, say 40%. Refer to discussion in section 4-3 for more details.

Version 1.0

Lucent Technologies Proprietary Do not distribute outside the company

75

F1: 2G F2: 2G F1: 2G F2: 2G F1: 2G F2: 2G F3: 3G1x V/D

Figure 12: Introducing 3G1x Voice/Data partially on a new carrier

3-2.8.2

Optimization Considerations

To help understand optimization considerations, this configuration can be visualized as a combination of two scenarios discussed earlier Introducing 3G1x Voice/Data in a 2G system on a new carrier throughout the network and Introducing 3G1x Voice partially in a 2G system on a new carrier. Combining the two sets of procedures, we obtain three main optimization steps: - First optimize 3G1x to 2G inter-frequency handoff borders for 3G1x Voice as mentioned in section 32.4.2. - Next, if option 1 followed as described in section 3-2.7.2, perform 2G/3G1x Voice validation tests throughout the 3G1x coverage area (including border zones). If option 2 used, then optimize F3 for 3G1x Data; in this case, it will really involve joint F1/F2/F3 coverage adjustments and the strategy will require 2G Full Rate Markov on F1, Data call on F3. - Finally, if option 1 pursued in the above step, perform 3G1x Data characterization tests on F3. Otherwise, conduct 2G/3G1x Voice validation runs throughout the 3G1x coverage region (including border zones). Please refer to sections 3-2.4.2 and 3-2.7.2 for detailed procedures on above steps.

3-2.9 Introducing 3G1x Data in a 3G1x Voice only system 3-2.9.1 Configuration

Figure 13 illustrates a deployment scheme for this migration scenario. The existing system supports 3G1x Voice on two carriers F1 and F2 throughout the system. These carriers are then configured to offer 3G1x Data service throughout the network. In this configuration, there are no 3G1x to 2G borders to optimize since the system only supports 3G1x services. This simplifies RF optimization. In a pure 3G1x system, there is no particular benefit of setting the Load Preference delta parameters for 2G and 3G1x voice to any specific value. The same applies to the Allow 3G1x sharing parameter. Although there is a per-sector alternate-per-carrier parameter called 3G1x Load preference delta for Data to allow biasing Data calls to a desired carrier, it is often not effective at segregating 3G1x Voice and Data services to different carriers. This is because 3G1x Voice calls can still be assigned to any carrier and also because Data calls will be assigned to other 3G1x Voice carriers in case of carrier overload. Since a strict 3G1x Voice/Data separation is not feasible at this time, we have not discussed scenarios of introducing 3G1x Data on a new/existing 3G1x Voice carrier. Having said that, even when this capability is available in future, the optimization considerations will not be much more different. One point to note is that although this configuration discusses ubiquitous 3G1x Data deployments only, any optimization requirements apply to partial introductions as well. This is because 3G1x Data calls will simply be released at the edge of 3G1x Data footprint. Since no handoffs are performed, there are no Version 1.0 Lucent Technologies Proprietary Do not distribute outside the company 76

stringent optimization requirements (such as successful handoffs). Drop calls can still happen at unoptimized Data borders, especially if the Data calls face sudden interference from a strong Voice only interfering cell; but these may not be as critical, since the proximity to the Voice only cell suggests the call will otherwise be released soon anyways.

F1: 3G1x V F2: 3G1x V

F1: 3G1x V/D F2: 3G1x V/D

Figure 13: Introducing 3G1x Data on an existing 3G1x Voice system

3-2.9.2

Optimization considerations

In many respects, the RF optimization procedures for this scenario are not much different than those required when introducing 3G1x Voice/Data on a 2G system. 3G1x Data service may necessitate some reoptimization depending on how well the 3G1x Voice system was optimized. The primary optimization focus will be on creating dominant Pilot regions in the network, as detailed in the Optimization methods for a 3G1x Voice/Data cold start. The degree of optimization, however, depends on overall flexibility available to adjust parameters. For example, change in coverage will impact all users, not just Data users. True, it may be possible to make small fine-tuning using Data specific parameters (such as Anchor hysterisis threshold), most RF optimization changes are likely to impact both Voice and Data subscribers. Depending on the available fine-tuning flexibility, one of the two options can be pursued. Option 1: Limited fine-tuning flexibility First option is where customer wants to introduce 3G1x Data without any coverage fine-tuning. This then simply reduces the optimization procedures to performance benchmarking/validation exercise. Data performance characterization tests will utilize one mobile to make 3G1x Data calls on the desired carrier (say, F1). Successive runs with downlink and uplink high-speed Data transfers will be made (the runs may be combined if additional data collection equipment available). Some small amount of Data specific fine-tuning, such as that involving anchor hysterisis threshold, may be made. Based on the data obtained from a final run after making all changes, the customer will be presented with plots of various performance metrics as required per the contract. LDAT 3G and 3gtool will be employed to analyze data and generate metrics for performance comparison between the two phones. Since the validation exercise involves Data calls only, a report can be compiled using the performance metrics in section 2-4.2.3. Unless required by the contract, there is no specific need to conduct tests to sample the dropped call, origination and termination performance for 3G1x Data calls. Option 2: Flexibility to make coverage changes

Version 1.0

Lucent Technologies Proprietary Do not distribute outside the company

77

Second option is where full flexibility is available to make coverage changes. This option will involve system-wide drive tests are performed with one 3G1x phone making Full Rate Markov call and another phone making 3G1x high speed Data call (both on F1). Many of the optimization techniques will be similar to those used for 3G1x Data cold start. Iterative testing will be performed to improve Data throughput in problem areas. Multiple runs will also be needed to test downlink and uplink high-speed Data performance, unless additional equipment is available for simultaneous data collection. It may be desirable to execute some of the tests, especially coverage changes and subsequent validation, during light loading hours to limit the impact on subscribers. Note that regardless of the option pursued, there is not much need to utilize simulated loading on existing carriers due to the presence of commercial traffic, unless tests are executed off-hours. In case of latter, loading values should be lowered to account for prevailing traffic load (supposedly light). Any dropped call, origination and termination tests required by the contract should be performed using 3G1x Full Rate Markov calls. There is no specific need to conduct the tests for Data calls.

Version 1.0

Lucent Technologies Proprietary Do not distribute outside the company

78

Chapter 4: Special Topics


In this chapter, we cover two main aspects related to inter-technology handoffs and various options/ methods for balancing RF load across carriers/technologies. Although some of the discussions apply to 3G1x Cold Start, the material is more relevant to 2G to 3G1x migration scenarios.

4-1

3G1x to 2G handoffs

When introducing 3G1x service in existing 2G networks, customer may wish to do so gradually. This would result in 3G1 coverage borders beyond which only 2G service is available. To carry 3G1x voice calls through the border and beyond, they will need to be transitioned to 2G mode. This will require 3G1x to 2G handoffs. The handoffs are semi-soft in that vocoder is not changed; only the RF connection with the phone is broken and call is re-established in 2G mode. Depending on whether 3G1x is introduced on a new carrier or an existing 2G carrier, it will predominantly result in same-frequency or inter-frequency handoffs. Note that these handoffs only apply to 3G1x Voice service. 3G1x Data calls are simply released as soon as the border handoff triggers are met. If 2G system is configured to support 2G Data, either the mobile or the cell site will automatically establish a fresh call in 2G mode depending on whichever side has pending data to send. Since there are no handoffs for 3G1x Data calls at borders, we only concentrate on 3G1x to 2G handoffs for Voice calls. Below we discuss two such types of handoffs. Note that current infrastructure release does not support for 2G to 3G1x handoffs.

4-1.1 3G1x to 2G same frequency handoffs (Voice calls only)


As the name suggests, a call undergoing this type of handoff retains the frequency after a transition. Such type of handoffs is prevalent when 3G1x is introduced partially on an existing 2G carrier. As the mobile approaches the edge of 3G1x coverage, a 2G only candidate Pilot will trigger a 3G1x to 2G handoff as soon as it is strong enough to be reported on the Pilot Strength Measurement Message (PSMM), unless both the following conditions hold true: The combined Active Set Pilot strength is equal to or better than 10 dB The 2G candidate Pilot is weaker than the dominant Active set Pilot. The above conditions attempt to extend the range of 3G1x Voice call until the mobile has moved sufficiently away from the 3G1x border cell and close to the 2G-only cell. Note that the cell site will attempt to bring the call up in soft handoff mode after the transition to 2G. It uses various Pilots reported on the PSMM, that triggered the handoff. The Active set after the transition may even include 3G capable cells previously supporting the call although obviously they will now transmit in 2G mode. It will work regardless of whether CMPIFHO feature is turned on. It also does not require populating cdhfl/cdhnl forms. The transition directly in soft handoff should help maintain call integrity, thereby, keeping the handoff failures/drop calls to minimum. However, under certain conditions, it is possible to experience unacceptably high drop call rates directly stemming from 3G1x to 2G handoff failures. Improving the drop call performance may require some RF optimization. Assuming the border regions are adequately covered (no low signal strength issues) and the 2G calls do not face similar drop calls in this region, the most likely cause for handoff failures is either the -10 dB aggregate Ec/Io or the strongest candidate Pilot condition. Both conditions can render a 2G only candidate a strong interferer to 3G1x call as they tend to delay the handoff until mobile has moved sufficiently closer to the target 2G only cell. One simple way to optimize this might have been to tune the 10 dB threshold. However, this is a hardcoded parameter. Below we propose some alternative optimization methods to alleviate the drop call problem: Set the Request for Pilot Measurement Interval parameter (Ceqface form) to non-zero (say 2 secs) on the outward facing 3G1x border sector (sector facing high transition failures)/nearby 3G1x cells. As Version 1.0 Lucent Technologies Proprietary Do not distribute outside the company 79

stated earlier, cell site may not attempt a 3G1x to 2G handoff if the aggregate Active Set Pilot strength is 10 dB or better, AND, the 2G only candidate Pilot is weaker than all Active set Pilots. Some of the handoff failures may be prevented if the mobile informs cell site as soon as the strength of the 2G only candidate Pilot equals/exceeds the dominant Active Set Pilot (second condition). The idea is to transition the call just before the candidate Pilot becomes a strong interferer to the Active set. Using periodic PSMMs, cell site can detect a strong candidate Pilot sooner potentially saving some of the handoff failures. Lower TCOMP on the border/nearby 3G1x cells. The mobile may not autonomously generate a PSMM to report the strongest candidate condition until this Pilot has exceeded the strongest Active Pilot by at least TCOMP dB. Similar to the situation above, this may delay the handoff transition enough to result in drop call due to interference from the 2G only candidate Pilot. To trigger TCOMP condition and the associated PSMM sooner, TCOMP can be lowered, thereby, allowing handoff sooner. Adjust the coverage of cells in the border zone. The purpose of coverage adjustments will be to slow down the rate at which the mobile with a 3G1x voice call faces interference as it approaches a 2G only candidate cell. Basically, any RF optimization effort will involve moving the handoff trigger location to a more conducive RF environment where RF impairments (such as shadowing, fast fading) are not as severe. The coverage adjustments may involve changing CBR (cell site transmit power) or antenna attributes (such as height, azimuth, downtilt). Note that any coverage changes should be applied uniformly to all carriers, otherwise it could result in some other performance issues such as access failures due to footprint mismatch. If 3G1x to 2G borders are temporary as 3G1x footprint may be expanded soon, it may not be of much economical value to make coverage adjustments/RF optimization. In this case, customer may be requested to move the 3G1x footprint out/in by a tier of cells in the hope that the new border area may be much more forgiving to allow better handoff success rates.

Other than the 3G1x to 2G handoff failures/associated drop calls discussed above, there are two other issues: 3G1x to 2G handoffs occur too soon. This would be the case if a 2G only cell/sector overhsoots into the interior of 3G1x coverage footprint. The concern is that it will eat into some of the 3G1x capacity as it triggers 3g1x to 2G handoffs prematurely. While this may not be a big issue, if needed, the condition can be improved by moving the handoff border outwards one tier such that the overshooting 2G-only cell is now a 3G cell. Other option will be to reduce the overshoot of this cell through traditional RF optimization means, but the effort may not be desirable since the border configuration may only be temporary. An interior 3G1x cell overshoots too far into the 2G only cell. This raises the possibility of the mobile setting up a 3G1x call in a core 2G only area as it locks on to the overshooting 3G1x cell. This, however, has not much downside as long as the call can still transition to 2G as soon as it leaves this small 3G1x pocket area. The overshoot of the 3G1x cell can be minimized via traditional coverage adjustments if it results in unacceptable3G1x to 2G handoff success rates.

4-1.2 3G1x to 2G inter-frequency handoffs (Voice calls only)


At the edge of 3G1x coverage footprint, this type of handoff results in call transition from 3G1x to 2G mode across carriers. The handoff may occur in two different border scenarios: Primarily at 3G1x coverage borders formed when a 3G1x carrier is partially overlaid on top of an existing 2G system. Occasionally for scenarios where 3G1x service is introduced on an existing 2G carrier4, but cell site could not perform 3G1x to 2G same-frequency handoff (the carrier on the 2G cell may be in overload or experiencing hardware resource shortages).
4

Cell site always prefers 3G1x to 2G same frequency handoffs at 3G coverage borders assuming the candidate 2G only cell that triggered the handoff has 2G resources on this carrier. Lucent Technologies Proprietary Do not distribute outside the company 80

Version 1.0

Scenario 1: 3G1x on new carrier overlaid partially on a 2G system For the first scenario described above, there are two choices for configuring inter-frequency handoffs Directed handoffs and Pilot Assisted Handoffs. Lucent recommends use of Directed Handoff (based on CDMA Interfrequency handoff Trigger Improvement or CIFHOTI) along with shot-gun handoff (CDMA Multiple Pilots Inter-frequency Handoff or CMPIFHO) as it allows for a cost-effective deployment and robust inter-frequency handoff performance at the border cells. This method has been used widely in numerous customer markets. Pilot Assisted Handoff, which uses Pilot only cell, may only be used in certain unique cell layouts/challenging RF environments due to cost/deployment efficiency reasons. Conceptually and configuration wise, Directed or Pilot Assisted handoff for 3G1x to 2G transition is no different than that for 2G to 2G handoff. For example, Directed Handoff requires configuring the Border Sector Loss and Border Pilot vs Interior Pilot thresholds (ceqface form), populating CDHFL and CDHNL forms, and enabling CDMA IFHO TI and CDMA MPIFHO flags (cell2 form). Similarly, Pilot Assisted Handoff only simply triggers off the TCOMP threshold and goes directly into soft handoff upon transition to 2G if CDMA MPIFHO flag is turned on. [1] provides a very comprehensive discussion on multicarrier optimization procedures along with a set of guidelines for border design and selection of handoff methods. All those considerations apply to 3G1x to 2G interfrequency handoffs as well. Therefore, we do not repeat the procedures here. It is very important to note that one must not use separate Directed or Pilot Assisted Handoff configuration at 3G1x coverage borders beyond which 2G-only service is available on the same carrier. In this case, the 2G only cell should be allowed to naturally trigger the 3G1x to 2G same-frequency handoff (or interfrequency handoff under overload/overflow as described below). Scenario 2: Overload/Overflow on a 2G only cell where otherwise same-frequency handoffs occur Normally, a 3G1x call approaching a 2G only cell, which has 2G coverage on the same carrier, will undergo 3G1x to 2G same-frequency handoff. However, if this carrier on the 2G-only cell is undergoing overload/overflow, 3G1x to 2G same-frequency handoff will occur instead. There are no separate optimization considerations since it is a special case of 3G1x to 2G same-frequency handoff, possibly rare and not easy to re-create for controlled optimization testing. The RF optimization engineer will simply optimize the border assuming same frequency handoffs. However, after turning on the commercial service, if there are issues with high drop call rate and overload/overflow on the 2G only cell, certain mitigation strategies can be followed. These will include reducing coverage of the 2G only cell and increasing that of the neighboring last tier 3G1x cell with the hope of reducing the load on 2G cell. Note that in some sense handoff overflow may be desirable to produce a more balanced RF loading across carriers on the target 2G-only cell. For example, if a 2G-only cell is facing hand-in traffic from 3G1x calls on one or more carriers, but not all5, as the major component of its total RF load, the same-frequency handoffs may cause disproportionate loading on these hand-in carriers especially since 2G calls may occupy more capacity (power) than 3G1x. Normally cell will attempt to balance this load using crosscarrier assignments for new call attempts, but if there are not adequate new call attempts, some imbalance may persist. Purposely under-provisioning the hardware on hand-in carrier may tend to correct the load imbalance by causing inter-frequency handoffs before the hand-in carrier goes into RF overload. Drop call performance should not be noticeably worse for these forced inter-frequency handoffs than that for same-frequency handoffs.

For example, this will be the case where 3G1x is provisioned on not all carriers in a multi-carrier system.

Version 1.0

Lucent Technologies Proprietary Do not distribute outside the company

81

4-2

3G1x to 3G1x inter-frequency handoffs

Much like 3G1x to 2G inter-frequency handoffs, these are similar to 2G to 2G inter-frequency handoffs. Two available methods - Directed Handoff or Pilot Assisted Handoff along with associated configuration, border cell design and optimization guidelines are treated in detail in [1]. Therefore, we do not repeat them here.

4-3

RF load balance across carriers and across technologies

There are two different modes of balancing user load across carriers one in idle mode, other in traffic mode. For each there are several options. Below we discuss these load balancing mechanisms along with some guidelines optimizing some of the associated parameters.

4-3.1 Idle mode hashing


For idle mode, users are distributed across carriers via their Mobile Identification Number (MIN) based hashing on the paging channel as specified in IS95/2000 standards. Mobiles simply look up the carriers listed on the Channel List Message (CLM)6 and hash to one of those. Usually there is fair degree of user distribution across sectors assuming sizeable users per sector. Since mobile performs the hashing function autonomously, there are no parameter settings to optimize.

4-3.2 Allow 3G1x Carrier sharing


For systems migrating to support 3G1x, some of the carriers may be configured to support both 2G and 3G1x especially in the initial stages of low 3G1x subscriber population. It is often important to preserve the distribution of 2G users, especially where 3G1x is introduced on an existing carrier. A translation parameter called Allow 3G1x Carrier sharing helps preserve this user distribution. Setting the parameter to yes will result in cell site transmitting CLM with 3G1x capable (that is, mixed 2G/3G1x) and 2G-only carriers. A 2G phone undergoing System acquisition will read CLM and hash to an appropriate 2G-only or 3G-capable carrier. The 3G1x phone will decode ECLM (which always lists 3G1x capable carriers) and hash to only one of those carriers. Once there is a sufficient 3G1x subscriber base in a system configured with one or more mixed 2G/3G1x carriers, or if 3G1x is introduced on a new carrier in an existing 2G system, there is no need to let 2G mobiles idle on 3G capable carriers. Under these situations, the parameter can be turned off. Cell site will transmit mutually exclusive sets of 2G-only and 3G-capable carriers on respective CLM and ECLM messages. This way 2G and 3G1x mobiles in idle mode will be matched to carriers with respective capabilities. As it will be evident in the section on Traffic based load management, this will minimize the number of cross carrier assignments and result in a more effective use of resources (for example, it will increase the likelihood of assigning calls to carriers of respective capabilities).

4-3.3 Traffic channel mode load management


There are various methods to select a particular carrier when assigning traffic channel to a particular call attempt. These together form what is known as Traffic Channel Allocation (TCA) algorithm. The purpose of the algorithm is to: - Allow flexibility in maintaining desirable load balance across carriers, - Offer ability to technology based load management, and - Provide a means of biasing a particular carrier(s) for Data calls. There are three main options for TCA. A parameter call TCA algorithm can be set appropriately to choose among RF loading, CCC balance and origination carrier options. Below we discuss each of these in detail.

4-3.3.1

RF Loading Option

RF Loading weight factor

2G mobiles utilize Channel List Message. 3G1x phones utilize Extended Channel List Message (ECLM), if transmitted by the cell site. Each Paging channel transmits these messages. ECLM will only be transmitted if the System Protocol Revision is set to IS2000. Lucent Technologies Proprietary Do not distribute outside the company 82

Version 1.0

To assign a traffic call, cell site selects a specific carrier based on its RF loading and a translation parameter called, RF loading weight factor. RF loading for a carrier is defined as the ratio of short-term average of cell site transmit power to the maximum available power. The RF load weighting factor is a bias applied at the time of traffic channel assignment. It allows for favoring the carrier on which mobile accessed. By applying the bias, the effective RF loading of this carrier reduces and makes it more likely to assign traffic to this carrier. Same-carrier assignments are preferred up to a certain extent to minimize origination/termination failures due to any coverage mismatch across carriers. However, if excess bias is applied, it can cause huge load swings across carriers and may hurt overall performance. This is especially true on the border sectors where mobiles can only access on the underlying carrier. For this reason, cell site automatically applies half the bias to the discontinuing carriers to attain load balance and hence, border carrier capacity. Refer to [6] for more information on proper setting of the weighting factor. Typically in core traffic area (cells with equal number of carriers and no inter-frequency handoff borders) there should be good balance assuming the RF loading weight factor is set properly (current recommendation is 20%). On inter-frequency border sectors, the underlying carriers may tend to get unduly loaded due to excessive inter-frequency handoffs and soft handoff traffic. This may require lowering the RF load weighting factor on the border sector to favor the discontinuing carrier for fresh call assignments. Careful monitoring is needed, however, to ensure there are no unacceptable trade-offs such as origination/termination failures. Note that RF loading weight factor does not provide any preferential treatment to 2G or 3G1x calls, to Voice or Data calls. In order to allow call segregation based on technology and service type, there are certain additional load delta parameters, as discussed below. Load Preference Delta Parameters In a mixed 2G/3G1x system, there are two parameters called 2G and 3G1x Load Preference Delta, used to administer technology based load management. The idea is to offer ability to preserve 2G traffic call distribution in initial stages of a migration to 3G1x, and then allow technology/hardware-based segregation as the 3G1x usage increases for an efficient use of 3G1x resources. At the time of call request, the cell site applies the respective delta or bias to each set of carriers with available 2G or 3G1x resources depending on the technology of the mobile. This is applied independent of the carrier on which mobile accessed. The load preference deltas are in addition to the RF loading weight factor. Together, they help maintain uniform loading across carriers while minimizing the number of cross-carrier assignments and offering the ability to match technology to respective carriers. To illustrate how cell site applies these, assume there are two carriers F1 and F2. Further, F1 is provisioned as 2G-only and F2 as a mixed 2G/3G1x carrier. RF loading weight factor is set to 20%, 2G and 3G load preference deltas are set to 5% and 25% respectively. Also assume that at the time of a new call request, F1 and F2 are loaded to 45 and 30% respectively (unless noted differently). Below are some possible outcomes: - If the call request is from a 3G mobile on F2, cell site will compute adjusted loading for F1 and F2 as 45% (unadjusted) and -15% (30-20-25). Therefore, 3G call will end up on F2 as its adjusted loading is lower. - If the call request came from a 2G mobile on F2, it will still be assigned to F2 (F1: 45-5 = 40% and F2: 30-20-5 = 5%). - If call request was for a 2G mobile on F1, cell site will cross-assign it to F1 (F1: 45-20-5 =20% and F2: 30-5 = 30%). - If at the time of call request from a 2G mobile on F1, F2 had no 2G CE resources available, then the call gets assigned to F1 (F1: 45-20-5=20% and F2: 30%). - Finally, a 3G call originating on F1 will be retained on F1 if F1 and F2 are loaded to 20 and 30% since in this case their adjusted loadings will be F1: 20-20=0% and F2: 30-25 = 5%. Note, in this case, the 3G mobile will be assigned in 2G mode.

Version 1.0

Lucent Technologies Proprietary Do not distribute outside the company

83

For combined 3G1x Voice/Data systems with multiple carriers, there is an additional parameter allowing a customer to attempt to favor one or more designated sector for High Speed Data calls. This is called 3G1x Data Load Preference Delta. Unlike the rest of the load preference delta parameters or RF loading weight factor, this is a per-sector/alternate-per-carrier parameter which means Data calls can be biased to a 3G1x designated carrier. Note also that it replaces the 3G1x Load Preference delta parameter, the latter applies to 3G1x Voice calls only. The use of 3G1x Data Load Preference Delta is illustrated as follows: Assume there are two 3G1x capable carriers F1 and F2. Customer wishes to assign as many Data calls to F2 as possible; so, sets the Data load preference delta for F2 to 80% and F1 to 0%, and RF load weighting factor to 20%. Also assume that at the time a new Data call request comes up, F1 and F2 are loaded to 30 and 50% respectively. If a Data call request comes on F2, the cell site leaves the F1 loading unadjusted at 30%; and computes that for F2 as 50-20-80 = -50%. Hence, the Data call will be assigned to F2. If the call request comes on F1, F1s adjusted loading will be 30-20 = 10%, that of F2 will be 50-0-80 = -30%. Call will still be assigned to F2, assuming it has necessary CE and PP resources. Note in the above illustration, that at this time there is no way to prevent Voice calls from getting assigned to the F2 carrier. If it gets fully loaded, then both new Voice and Data calls will be directed to F1. Some guidelines on fine-tuning RF load management related Secondary Optimization parameters Using the per-carrier usage via SM/SPAT, any excess or undesired load imbalance across carriers can be spotted and corrected. Some guidelines on optimizing these Secondary Optimization Parameters: - Fine-tune the RF loading weight factor to correct any excess imbalance/under-utilization of a carrier independent of technology. Usually, this will only be required on inter-frequency border cells or nearby non-border cells. On the border sectors, the parameter should only be adjusted after ensuring the inter-frequency handoff triggers have been optimized to obtain desired traffic channel range on the discontinuing carrier. - As it is evident, the two Voice delta parameters discussed above are very important in 2G to 3G1x migration situations. They need to be adjusted from time to time together with the Allow Sharing 3G1x Carrier parameter as 3G1x usage increases. - Finally, the load preference delta parameter for Data may be fine-tuned per customer expectations of Data traffic distribution.

4-3.3.2

CCC option

One of the other options for TCA algorithm is called CCC. CCC based balancing is utilized to assign calls to the most idle CCC available on the sector. As the name suggests, the purpose is to avoid excessive loading of any one CCC.

4-3.3.3

Origination carrier option

The third option available for TCA algorithm is known as Origination carrier. This option is used to assign calls to the same carrier on which MS attempts to access. For non-border cells, this is equivalent to selecting RF load balance option with weight factor set to 100%. This option can be utilized during multicarrier optimization to force call assignments to the originating carrier for each test MS. This allows monitoring traffic channel performance on the carrier that the mobile idles on. It alleviates the need for careful checking of whether the test call came up on the intended carrier.

Version 1.0

Lucent Technologies Proprietary Do not distribute outside the company

84

Chapter 5: Acknowledgements
The ideas and procedures presented in this document were developed based upon important inputs and efforts of several people. Special thanks go to: Murat Berin, Neil Bernstein, Tom Linnemeyer, Eric Nelson, Lendy Ortiz, Patty Ramos, Sanjay Rathi, Anu Sandhu, Ashok Sethu and Amit Shah for their valuable support in the 3G1x Voice and Data optimization trials as well as for valuable inputs to the document.

Chapter 6: References
[1] [2] [3] [4] [5] [6] [7] [8] Multi-Carrier RF Optimization Procedures for PCS and Cellular CDMA Systems, version 5.0, Lucent Technologies CDMA Translation Application Notes: Introduction, Lucent Technologies A Translation Application Note for CDMA Forward Link Transmit Path, App Notes 1 and 1F, Lucent Technologies A Translation Application Note for CDMA Forward/Reverse Overload control and Supplemental Air Resource Allocation, App Notes 3V and 3D, Lucent Technologies A Translation Application Note for CDMA Handoff, App Notes 4 and 4D, Lucent Technologies A Translation Application Note for CDMA Timing, Delay And Access Parameters, App Note 7, Lucent Technologies A Translation Application Note for CDMA Subscriber Access Control, App Note 8, Lucent Technologies A Translation Application Note for High Level Stack Protocol Parameters for 3G1x, App Note 9, Lucent Technologies

Version 1.0

Lucent Technologies Proprietary Do not distribute outside the company

85

Vous aimerez peut-être aussi