You are on page 1of 83

Technical Memorandum

subject:

1xEV RF Optimization Guidelines

date: from:

06/03/2005 Vladan Jovanovic, Devesh Patel, Anu Sandhu, Amit Shah Wireless Service Creation And Performance Dept., LWS, Lucent Technologies

Version 4.0 (applicable for deployments on R24.0 and prior)

1xEV Technology

RF Optimization Guidelines

TABLE OF CONTENTS
INTRODUCTION.......................................................................................................................4 1 1.1 1.2 1.3 1.4 1.5 1.6 1.7 1.8 1.9 1.10 2 3 3.1 3.2 4 4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9 5 5.1 5.2 5.3 5.4 5.5 5.6 OVERVIEW OF 1XEV SYSTEM OPERATION ..................................................................5 Forward Link Reverse Link 1xEV Intra-System Handoffs Inter-System Handoffs (3G-1X / 1xEV Hybrid Mode) Mobile IP Loading Issues 1xEV Lower Layers Higher Layers Expected 1xEV System Performance Exit Criteria and Expected Results for RF Optimization work 5 6 7 7 9 10 12 14 17 19

1XEV DEPLOYMENT SCENARIOS ................................................................................23 OVERVIEW OF 1XEV RF OPTIMIZATION......................................................................25 Optimization Process Optimization Methodologies 25 26

RF OPTIMIZATION TOOLS.............................................................................................27 RF Data Collection Toolkits 1xEV Test Terminal CDMA Air Interface Tester (CAIT) Data Application Laptop and Software Air Interface Performance Monitoring Network Data Collection Tools Lucent Data Analysis Tool (LDAT3G) Friendly Viewer (FV) GeoBin Data Server 27 29 29 30 31 32 35 35 35

TEST DATA LOAD GENERATION ..................................................................................36 Test Application Test Mode UDP Transfers FTP Transfers Ping Origination Testing 36 36 36 38 44 46

LUCENT TECHNOLOGIES - PROPRIETARY

Page 2

1xEV Technology

RF Optimization Guidelines

5.7 5.8 5.9 5.10 6 6.1 6.2 6.3 6.4 6.5 7 7.1 7.2 7.3 7.4 7.5 8 8.1 8.2 8.3 8.4 8.5 9 9.1 9.2 9.3

Drop connection and Throughput Testing Forward Link Loading Reverse Loading Test Carrier Feature

48 50 51 51

DATA COLLECTION PROCEDURES .............................................................................53 Procedures at the beginning of drive testing: Procedures to capture UATI information in CAIT log Procedures to collect data: Data Processing Procedures Data Archiving 53 54 54 55 56

PRE-RF OPTIMIZATION .................................................................................................58 Spectrum Clearing Verification Underlay System Baselining Drive Routes Planning Neighbor List Preparations Translations Check 58 58 59 61 61

RF OPTIMIZATION..........................................................................................................63 Close Loop Test (Optional) Sector Testing Cluster Testing Inter-System Handout Testing System Testing 64 65 67 70 72

RF TROUBLESHOOTING ...............................................................................................74 Coverage Hole No Dominant Server Weak Pilots 74 75 79

10 APPENDIX - CLOSE LOOP TEST .................................................................................81

LUCENT TECHNOLOGIES - PROPRIETARY

Page 3

1xEV Technology

RF Optimization Guidelines

Introduction
This document presents set of procedures and guidelines for optimizing a 1xEV network. RF Optimization considered here are the activities involved in first characterizing and then improving the system performance so that it meets contractual, technical or other objectives as defined by Lucent and our customers. The focus is on the drive test based RF optimization techniques utilized at various stages prior to commercial launch in order to tune various aspects of over-the-air performance of a system. Pre-commercial stages when RF optimization is needed usually include testing and optimization associated with: early technology evaluation trials, FOA activities, technical or marketing field trials of the technology, network optimization during initial system deployment, prior to launch final acceptance (warranty) testing, etc. Similar techniques can be used in a commercial operation, supplemented with the data coming from Service Measurements to identify the problem areas. In practice, RF Optimization often ends up being a continuous process extending long beyond the first commercial cut-over, due to changes in configuration of the network due to additions of new cells and/or carriers to a network, traffic volume/pattern changes with increasing subscriber base, etc. These guidelines address RF optimization for 1xEV systems deployed on top of an existing 2G or 3G CDMA network (Overlay), or built from scratch (Cold Start scenario). It is expected that this will be a living document and that more specifics will be added in future versions, as more experience is gathered, especially as related to the Cold Start scenarios. Additional chapters dealing with RF optimization in multi-carrier 1xEV systems deployed after the commercial launch and other topics are also envisioned. The primary target audience for this document is the Lucent RF personnel who will be responsible for the preparation and execution of the RF optimization tasks for various trials, FOA, or commercial launches of 1xEV systems. Besides RF optimization teams, it is expected that document might be useful for Lucent personnel involved in planning, project management or contractual negotiations as related to any of these stages of 1xEV development, deployment and commercialization. Readers from the ranks of RF optimization teams are expected to be familiar with the corresponding suite of M&P documents on CDMA RF Optimization for 2G systems, and 3G-1X RF Optimization1. General philosophy and most of the processes are very similar to those documented there, with natural extensions to deal with different technology, different test equipment, and several 1xEV specifics. In addition, two presently available test reports might be of interest for the readers, dealing with the early technology field trials2. These will be especially useful in terms of understanding the results expected with 1xEV technology in the field, and can provide additional insight into the main metrics considered, expected results, past known problems, etc.

1 2

http://globalrfmandp.wh.lucent.com 1xEV-DO Trials (Spring/Summer 2001), com/~cdmabloc/hdr/index.html 1xEV Trials (2001/2002) http://nwswww.wh.Lucent.

LUCENT TECHNOLOGIES - PROPRIETARY

Page 4

1xEV Technology

RF Optimization Guidelines

1 Overview of 1xEV System Operation


Several excellent overviews of the air-interface standard3 and 1xEV system architecture exist in other Lucent internal documents4, and a special document summarizing the expected system performance is available5. Here we will cover some elementary topics in a way that would make this document reasonably readable and self-contained. For more details and deeper understanding of the 1xEV technology, quoted references should be studied. 1xEV is a data-only system, developed to provide very high-speed data services (up to 2.4Mbps on the downlink and 153kbps on uplink). It is described in the IS-856 standard. IS-856 is a derivative of IS-95, which utilizes a dedicated 1.25MHz carrier for data services. In addition to the frequency plan, 1xEV has the same chip rate, and the waveforms that are either the same, or compatible with the IS-95/IS-2000. IS-856 compatible systems are also often called 1xEV-DO (data only), to distinguish from the eventual next generation of 1xEV systems that might support both voice and data (1xEV-DV). Except for the compatibility on the physical layer, 1xEV reuses many proven concepts from IS-95 and IS-2000 systems, especially on the reverse link: soft handoff, fast power control, modulation, coding schemes, access protocol, etc. However, it also incorporates some radical departures from its predecessors, especially on the forward link. These changes have been made possible by removing the QOS constraints required for voice traffic, most notably low (and largely constant) delay requirements, as well as the symmetry constraints (most Internet applications require much larger downlink than uplink bandwidth). 1.1 Forward Link

All the transmissions on the forward (down) link in 1xEV technology are at the constant power, and they are time-multiplexed. Time is allocated in units of slots, which are 1.66msec long. Rates on the forward link range from 2.4Mbps to 38.4kbps; depending on the rate selected, the transmission can take between 1 and 16 slots. Highest rates utilize 16-QAM or 8-PSK modulation, and the lower rates employ conventional QPSK signaling. Pilot signal is provided, but also on the time-shared basis, within a portion of the slot. Pilot signals are sent synchronously in all sectors, even if the slot itself is empty (i.e. no data available in the queue for any of the active mobiles). Constant transmit power means that there is no power control mechanism on the forward link of 1xEV. While the transmit power in IS-95 is adjusted to keep the error rate constant under fixed data rate constraint, 1xEV can be viewed as a system where the power is kept constant and transmit rate adjusted so as to maintain the constant error rate. Rate adjustments are made based on measurements of the signal-to-noise ratio (SNR) and other relevant RF parameters that 1xEV mobiles make continuously (exact details are proprietary for phone manufacturers). Based on the measurements, each mobile makes an estimate of the maximum data rate it can support at the internally set target packet error rate of 1% (which cannot be changed). These estimates are sent continuously back to the network over a Data Rate Channel (DRC), a dedicated Physical Layer channel on the reverse (up) link, at the rate up to 600 estimates per second. At the base

Gabriela Abramovici, Stan Vitebski, Frances Jiang, 1xEV-DO Technology Overview, http:// nwswww.wh.lucent.com/~gaby/ Gabriela Abramovici, Lucent 1xEV-DO Systems Architecture ~gaby/ http://nwswww.wh.lucent.com/

R.Sinha, 1xEVDO Performance Expectations, http://rfcoresupport.wh.lucent.com/RFCoreSupportWebPage/ guidelines.htm

LUCENT TECHNOLOGIES - PROPRIETARY

Page 5

1xEV Technology

RF Optimization Guidelines

station, all the DRC estimates are collected at the scheduler. Scheduler is a software algorithm, which decides on a slot-by-slot basis which mobile should receive the transmission, and at which rate. The scheduler for the initial releases of 1xEV system employs a so-called "proportional fair" scheduler, which allocates slots in such a manner that the aggregate sector throughput is maximized under certain delay constraints for disadvantaged users. From the perspective of longer term averages, "proportional fair" scheduler looks like an equal-time assignment algorithm each mobile receives roughly the same number of slots ("fair" part), but the throughput for users in good RF environment can be substantially larger (average data rate is proportional to the assigned rate). On the short-term basis, this would take advantage of the fading, i.e. data would be sent to those mobiles that are in the up-fade, and held for those which are in the down-fade. Another exceptional feature of the 1xEV forward link is the so-called Incremental Redundancy (aka Physical Layer ARQ) scheme, which enters into play when the requested rate is such that more than one slot on the forward link is required to transmit the whole coded packet (all rates but the highest few require at least 2 slots, up to 16 for the lowest rate). In these cases, the transmitter can send data first, and then the incremental amounts of redundancy (FEC) bits in following slots. Due to the iterative nature of the applied turbo-coding scheme, receiver stands a very good chance to correctly decode the transmitted packet with much less than all the redundancy usually sent (all the redundancy is needed to achieve the desired low packet error rates in the tails of the distribution). This Incremental Redundancy mechanism is implemented via special ACK channel on the reverse link, which acknowledges positively or negatively every slot in multi-slot transmissions. To allow for processing, these are actually staggered (interlaced), so that the content of multi-slot packets is sent every 4-th slot, which allows enough time for decoding and acknowledgment. 1.2 Reverse Link

Transmissions on the reverse link are always one frame long (16 slots, or 26.6msec, frame in 2G/3G is 20msec). Other than that, the reverse link is very similar to the 3G-1X: it can support rates from 9.6kbps up to the 153kbps, modulation is conventional QPSK, with a code-multiplexed pilot signal, the transmissions are power controlled, etc. Mobile terminals autonomously make decisions as to what is the maximum rate that can be supported on the reverse link, and send that information in parallel with the transmitted frames, via a separate Reverse Rate Indication (RRI) channel on the Physical Layer on the frame-by-frame basis. Each time there is some data to transfer over reverse link, mobiles start at the lowest possible rate of 9.6kbps, and then ramp up the transmission rate probabilistically if there is enough data in the input data queue. If there is not, mobiles normally choose the lowest possible rate that would empty the queue (instead of sending frames at higher rates with unnecessary padding) to reduce interference and improve capacity of the reverse link. Since the mobiles do not know the actual loading on the reverse link as seen at the base station, network has several mechanism to control the maximum rate at which the mobiles can transmit: this can be done via messaging (network can send a broadcast or unicast Rate Limit message to the mobiles in the sector); when quicker congestion control is required, network can also set a Reverse Activity Bit (RAB) over a dedicated Physical Layer channel. If the RAB bit indication is on, some of the mobiles would end up halving the data rate within one frame interval. Mobiles decide on whether the rates should be halved based on a probabilistic algorithm, and the percentage of those that would actually go down can be controlled via translations, for fine tuning. Analogously, if the RAB indication is not on, mobiles can use the probabilistic algorithm to double the rate from the previous frame. RAB-based rate control is implemented in Release 2. First release utilized the Rate Limit approach based on the number of active users and their handoff state only.

LUCENT TECHNOLOGIES - PROPRIETARY

Page 6

1xEV Technology

RF Optimization Guidelines

Probabilistic ramping up and down of the transmission rates on the reverse link are controlled by the set of system parameters called transition probabilities. These were changed in Rel.20.1 to allow for more aggressive rate increase. This does not make much of the difference during normal uploads, but can speed up transfer in the situation when relatively small amount of data has to be sent over the reverse link, such as in the case of PING6. 1.3 1xEV Intra-System Handoffs

Except for defining the rates requested by mobiles on the forward link, DRC channel also provides means for mobile to identify the best sector presently in the Active Set (DRC Cover, indexed from 1 to 6 based on the contents of the latest Traffic Channel Allocation message defining the Active Set). This is the one and only sector from which the forward link data is to be transmitted, which means that 1xEV system does not have soft handoff on the forward link in the IS-95 sense. Since the SNR measurements are arriving at the very fast rate (up to 600Hz), this enables a fast serving sector selection on the forward link (of the order of 100msec), in general much faster than what would be possible in any other access technology that utilizes messaging to convey the results of the mobile SNR measurements to the network. This fast serving sector selection algorithm is often called "virtual soft handoff", and can take advantage of the diversity available from handoff process in many fading scenarios, without causing any extra-interference on the forward link. On the reverse link, 1xEV system employs classical IS-95 soft hand-off several base stations at any given time, depending on the soft handoff state, can demodulate signals from one mobile. Soft handoff algorithm is the same as in IS-95, with Neighbor, Candidate and Active Sets of pilots. Standard handoff thresholds analogous to TADD and TDROP determine movement of the pilots between the Sets. Variable thresholds first introduced in the IS-95B version of the standard are supported by the standard, and will be implemented in the future. It should be noted that first release did not support inter-FMS handoffs (handoffs between cells homed at different base station controllers, also known as Inter-PCF handoffs), but they are supported now. From the RF perspective, these handoffs are completely transparent, because as long as the session is up, it remains controlled by the old anchor FMS, and AT has no ability to distinguish between the pilots belonging to the cells that are homed on old and new FMS. Control of the AT is transferred to the new FMS only once the session is down (Idle Inter-PCF handoff), transparently for the ATs. If two different FMSs are configured to be on two different PDSNs, then the session will not be automatically continued if Simple IP protocol is used, but will be continued if Mobile IP is supported in the backbone data network. Again, inter-PDSN handoffs do not require any special optimization work from the RF perspective. 1.4 Inter-System Handoffs (3G-1X / 1xEV Hybrid Mode)

The primary responsibility for all 1xEV interoperability issues is placed into the dual-mode (hybrid) terminals that support both 1xEV and 3G-1X. Due to system similarities, first generation of mobile ASICs for 1xEV already supported dual mode operation, and this is expected to be the case for most future terminals as well.

Default size PING results (32B) take about 15msec shorter in Release 20.1 than before, because the PING response is sent in 2 frames more often than in 3 frames in Release 1 PING responses required 3 frames in majority of cases. See Sect. 1.8 and 5.5 for more details.

LUCENT TECHNOLOGIES - PROPRIETARY

Page 7

1xEV Technology

RF Optimization Guidelines

After initial power-up, dual-mode mobile terminal would initialize with 3G-1X system, and would then look for 1xEV system, both based on the preferences from the PRL list7 (note that dual-mode terminal would never find 1xEV service if 3G-1X system is unavailable!). If the 1xEV system is found, dualmode terminal will end up in the idle/dormant state, where they monitor the paging/control channel intermittently on both technologies (possible during the slotted mode of operation). By toggling between the carriers, they would ultimately end up being idle on both systems, i.e. in the state where they are completely set-up to establish calls or connections on either of the networks. When in the idle mode, terminal can receive requests for 3G voice service, or 1xEV data. If the 3G voice call is originated or terminated, terminal would leave the slotted mode, acquire traffic channel on 3G system, complete a call, and return to the idle mode. Any requests for 1xEV service during the 3G call would be ignored. If the connection request is received for 1xEV service, dual-mode terminals would establish the 1xEV connection, and then periodically jump to the 3G-1X frequency to check for pages8 in the assigned slots (no data has to be lost itself, terminal can send a zero-DRC value to indicate that it does not want to receive data on the forward link and simply buffer the reverse link data, similar to what it does when in a deep fade). When a page is received, or user decides to originate a voice call during a 1xEV connection, the existing connection could theoretically be ported to 3G-1X, which could then simultaneously support both voice and data service. However, it appears that no terminal vendors have plans to support this option at this time, and neither does Lucent. Instead, application running on 1xEV would be simply frozen during the voice call, and it might time out (if user decided to make a voice call during a long ftp), or continue without any user perceived problem (e.g. if the user was web browsing). Another scenario to consider is when the terminal loses one of the systems, most probably because it is reached the coverage boundary of the present system. If 1xEV system is lost, and the terminal is dormant, upon detection of the system loss the terminal would switch to 3G-1X, and send an Origination Msg. with the Data Ready to Send (DRS) indication set to 0. This would initiate the inter Packet Controller handoff procedure with the PDSN (or new PDSN for 3G-1X system) without setting up the traffic channel. PDSN would establish an A10 connection with 1X Packet Controller, and release the A10 with 1xEV. Subsequent data connection attempts would be handled by the 3G-1X system. If Mobile IP is supported in the operators data network, mobile will not have to re-establish the session, and would keep the same IP address. If the 1xEV connection was established and the system is lost, the same procedure would be followed, except that the traffic channel would be established. If the Mobile IP is supported, the session would continue on 3G-1X system, but the data already in the 1xEV Packet Controller will be lost (no buffer retrieval). Eventual recovery of the lost data would be the responsibility of the application layer itself. In the RF sense, this means that there are no hand-offs between the 1xEV and 3G-1X systems, i.e. there is no direct transfer from one traffic channel to another one system gets lost first, and then the other gets acquired instead (this process is often called Session Handoff, in part to indicate this difference). When in idle mode on 3G-1X, dual mode terminals would periodically check for 1xEV, and upon acquiring the system it would send the Location Notification Msg., which would initiate the Packet

7 8

The exact procedure for this is specified in the PRL standard (IS-863A). This operation is not standardized in parent IS-856 standard for 1xEV-DO, but rather in the IS-878 Interoperability standard.

LUCENT TECHNOLOGIES - PROPRIETARY

Page 8

1xEV Technology

RF Optimization Guidelines

Controller handoff with the PDSN. Again, the 3G-1X to 1xEV transitions would occur only in the idle/dormant mode, not during voice or data calls. Qualcomm had recently submitted a proposal for DDTM Dedicated Data Transfer Mode, whereby the mobiles might not be able to receive voice pages on 3G-1X during 1xEV data transfers. Main driver for this appears to be a wish to minimize throughput loss due to frequent jumps to 3G-1X systems to check for pages, but at this time no further details about this mode are known. From the optimization perspective, mobiles operating in the Hybrid mode pose at least two difficulties. First is that the jumps to 3G-1X while in the middle of 1xEV data transfer would lower the measured throughputs. Throughput performance deterioration depends on the Slot Cycle Index, i.e. a 3G-1X and not the 1xEV system translation that defines how often the jumps are made (usual values in the field are 0, 1 and 2, meaning that a jump would be executed every 1.28, 2.56 or 5.12 seconds respectively). Operators usually insist on keeping their present settings for 3G-1X intact, and these various setting could cause a degradation of anywhere from 10 to 30%9, depending on the Slot Cycle Index used. Second issue with Hybrid terminals is that the system reselection criteria for abandoning 1xEV and switching to 3G-1X are not defined in any standards, which means that each potential vendor can come with a proprietary solution. At this time, Chester and all other terminals based on MSM5500 chip seem to be programmed to abandon the 1xEV service once the aggregate Ec/Io falls bellow 7dB for a period of 4 seconds (equal to the system defaults for TADD and TTDROP, but hard-coded in the mobile). In many instances this implementation would cause the 1xEV calls to be redirected to 3G-1X long before there is any real RF problem with the 1xEV call (in the case of only one pilot calls can be held down to TTDROP, which is set to 9 by default, and Lucent translations settings at this time recommend even lower value of -11dB). During drive testing in Hybrid mode, special attention to be paid to recognize such unexpected switches to the 3G-1X service, which would cause serious throughput loss. In addition, at least in some implementations the mobiles seem to be programmed to originate a data connection on 3G-1X system if the attempt on 1xEV system fails, which can cause troubles during the origination testing. For field-testing, especially in the case of Exit Criteria testing, every effort should be made to do all the measurements with mobiles programmed to work in 1xEV-only mode, i.e. not in the Hybrid mode. It should be noted that mobiles themselves can be programmed to work in the 1xEV mode only, independent of any network settings. 1.5 Mobile IP

Besides inter PDSN handoffs and seamless handoffs at the borders of 1xEV coverage (seamless from the Application Layer perspective as described in the previous section), for end users Mobile IP provides some additional networking benefits (i.e. ability to utilize a static IP address), but should have no impact upon the RF optimization all the processes and procedures should be the same for systems no matter whether they support Simple of Mobile IP. Big problem (independent of Lucent 1xEV system and the backbone network), however, is that Chesters and all other terminals based on MSM5500 chips cannot support as high data rates when operating under Mobile IP as they can when in Simple IP. Under Mobile IP, terminals do much more packet processing (they terminate two PPP protocol stacks, one between the 1xEV system and the Chester, and another one

Present estimate. Qualcomm have changed a few details about the Hybrid mode implementation recently, and experimental data for various Slot Cycle Index values from the filed is still not available.

LUCENT TECHNOLOGIES - PROPRIETARY

Page 9

1xEV Technology

RF Optimization Guidelines

between Chester and the laptop, in order to make application laptop fully unaware of the Mobile IP), and this overhead consumes so much processing power that highest throughputs cannot be maintained. MSM5500-based ATs use two different mechanisms to limit throughput when operating in the Mobile IP mode. If the offered traffic is UDP-based, and the incoming packet rate exceeds the processing power capabilities, they start lowering the arriving data rate to the AT by sending valid DRCs, but with the DRC Cover set to zero (in essence, this indicates to the network that AT is ready to receive for instance a 2.4Mbps packet if DRC=12, but does not want any sector to send the actual packet). This is tricky because normal CAIT screens do not show the DRC cover information, nor it can be displayed in LDAT. Such instances can be detected by reviewing the DRC Channel ACQ Buffer entries from the CAIT logs, which is not straightforward. If the input traffic is TCP based, then in general ATs that use the MSM5500 chips do not send the DRC Cover of zero (although they do this occasionally). In between the DRC Cover=0 events, terminals simply rely on additional delay created in their processing queue to effectively increase the round trip time and lower the throughput (TCP acknowledgments end up coming much later, which is another effective method to provide flow control, see Section 1.8 for further details). Due to these processor limitations, with FTP ATs with MSM5500 chips cannot achieve more than about 1.3Mbps throughput even in best RF conditions, which represents a throughput loss of about 30%. Loss becomes gradually smaller with deteriorating RF conditions, and is practically negligible when the throughput is about 700kbps. Situation further deteriorates when CAIT logging is activated, throughput loss reaching 50% at the high end. However, since the rates above 1.5Mbps are rarely requested during the mobile drive tests, typical throughput loss under Mobile IP conditions in the field seems to be around 10-15% without CAIT, and is estimated to be at least 30-35% with CAIT logging turned on. The newer generation of MSM6500 chipset based ATs appear to show marked improvement practically no loss in throughput in the MIP mode even with the CAIT logging enabled. Several commercial-grade ATs based on the MSM6500 chipset are being evaluated at this time for use in the RF optimization toolkit; however, at this time the recommendation is to continue using MSM5500 based Chester for RF optimization. The loss in throughput in MIP mode does pose some serious problems with network measurements. For example, peak throughput capabilities of 1xEVDO cannot be validated. It does not impact the optimization work itself that much, but definitely impacts Exit Criteria testing. Unlike the Hybrid Mode, where the default network settings can be reprogrammed at the mobile to ensure 1xEV-only mode of operation, nothing can be done from the mobile side to avoid Mobile IP operation if the network is set-up for Mobile IP mode only. Thus, every effort should be made to ensure that at least Exit Criteria testing would be performed under Simple IP. If this seems impossible, optimization teams should alert the Management about it as soon as possible, and new, less stringent Exit Criteria need to be renegotiated. 1.6 Loading Issues

Due to the conceptual differences, the effects of fading on the forward link are very different than in 2G and 3G systems, which changes the philosophy of 1xEV optimization to some extent. On the forward link, all call processing functions in all CDMA systems are ultimately based on terminals Ec/Io measurements for various pilots. In previous CDMA technologies, forward link pilot power is essentially constant (Ec), while the presence or absence of other users changed the total power (Io) often by as much as 10dB, so that quite elaborate OCNS10 was needed to model that kind of loading

10

RF M&P document RF-E125

LUCENT TECHNOLOGIES - PROPRIETARY

Page 10

1xEV Technology

RF Optimization Guidelines

for test purposes (for the reverse link, the passive interference modeling via attenuators10 was usually sufficient). Contrary to previous CDMA technologies, in 1xEV the pilot signal is sent at full sector power during a portion of every slot (including the idle ones), and all these instances are synchronous in all the sectors in the system. This means that all Ec/Io measurements are done while all the sectors are transmitting signals at full power, i.e. the measurements would be the same no matter whether all the sectors are fully loaded in the sense that all forward link slots are occupied, or unloaded (all forward slots idle). All call processing functions related to these measurements such as access, handoffs, determination of the rates to be requested for forward11 or reverse link, all these will be occurring essentially the same way in the fully loaded and a completely unloaded system (more precisely, one can say that to a very large degree 1xEV system behaves as if all the slots are always fully loaded). In terms of the performance, some differences between loaded and unloaded situation exist. On the forward link, if the actual loading is less than full (in terms of slot occupancy, not necessarily the data throughputs), this means that some forward link slots would actually have less interference than mobile terminal predicted that channel will occasionally be too good (have too low packet-error rate) for the data rate selected. In some cases, the Incremental Redundancy would be able to exploit this and terminate the transmission in fewer than maximum number of slots, thus increasing the effective throughput. Otherwise the decoded packet error rate might be lower than the target (typ. 1%), so the terminal might decide to be more aggressive with rate determinations (exact details of this algorithms are proprietary to the phone manufacturers). To model the interference, commercial 1xEV system would have the FLUS (Forward Link Users Simulator feature) as an equivalent to OCNS. Among other things, FLUS can be used to model the impact of various scenarios with partially of fully filled data slots, but this impact in 1xEV is in general much smaller than full forward link loading in 2G or 3G systems. At this time FLUS have not been field tested, and the procedures how to use it would have to be developed separately12. An alternative method to create loading interference is to use the per-sector Idle_Channel_Gain parameter, which defines the relative power to be used for forward link transmissions during the idle slots13 (signal transmitted during the idle slots is a waveform that cannot be confused for valid transmission by the mobiles in the field). By setting the Idle_Channel_Gain to 0dB, one can model the situation in which all the sectors transmit as if there is enough data in all the queues to transmit 100% of the time. By setting the Gain to smaller values (e.g. 3dB), various loading scenarios can be approximated. Actual settings will have to be discussed and agreed with the operators, in part due to the difficulties when trying to model the pulsed on-off interference with the constant amplitude signals. Either way, several tests performed so far showed a rather small difference (less than 10%) between

11

Note that forward link rate requests are determined by signal-to-noise ratio SNR, which is related to the traditional Ec/Io measurements via SNR=(Ec/Io)/(1-Ec/Io). FLUS can be turned on and off, but this has to be done manually. The use of FLUS is fairly straightforward for single sector throughput tests when all the test mobiles will be served by one sector and FLUS can be turned on in all the surrounding ones to create inter-cell interference, but such tests are usually limited to stationary or pedestrian traffic cases (finding routes that would remain within one sector while driving at 30-70mph is usually impossible). For the sector throughput measurements in the vehicular mobility case, FLUS will have to be turned on in all the sectors with appropriate settings for several mobile users (which need to be defined), and the sector throughput would have to be calculated based on the sum of artificial FLUS and real test mobile throughput. This parameter was originally introduced to alleviate certain issues related to on-off operation of the power amplifiers. Normally, it is set to a very low value, such as 10dB, so that the interference from the idle slots is negligible.

12

13

LUCENT TECHNOLOGIES - PROPRIETARY

Page 11

1xEV Technology

RF Optimization Guidelines

throughputs measured in the fully loaded system (all cells with Idle Channel Gain set to 0dB) and unloaded (Idle Channel Gain at 10dB). Further field tests, as well as some additional simulation work is needed before we can claim that such results are typical. Reverse link loading, if modeled via attenuators similar to what is usually done in 2G and 3G, would yield very similar results. It is important to emphasize that the recommendation at this time is to do all the optimization work without any simulated loading. It will eventually be included in the system exit tests, based upon the contractual agreements with the operators. 1.7 1xEV Lower Layers

1xEV standard has a very complex layering scheme. After the Physical Layer, the first layer of interest for optimization work is the RLP layer. Radio Link Protocol (RLP) exists on both forward and reverse link, and is introduced to reduce the packet error rate from around 1% on the physical layer to something like 0.02% to 0.03% on the RLP layer, which is acceptable for the application layer. On the transmit side of the forward link, RLP Layer numerates all the bytes coming from the Application Layer, and associates an RLP sequence number with each one. It then partitions the input stream into 976 bit long packets, and appends the sequence number of the first byte in the header, to form an RLP packet with a length of 976+22=998 bits. Additional 4 bits are added to each RLP packet as headers in several layers not of interest here, to create a 1002 bits long MAC Layer packet. Additional 22 bits of padding (or CRC check) are added to each MAC Layer packet, for a 1,024 bits total, and from 1 to 4 MAC packets are then packaged within one Physical Layer packet, depending on the data rate selected. Note that CRC bits are added only in the last MAC packet in the PL packet. Thus, one bad CRC on the Physical Layer packet could represent an erasure of 1024, 2048, 3072 or 4096 bits. This is illustrated in Figure 1 for the forward link case. Reverse link follows the same principle, with different packet sizes.

LUCENT TECHNOLOGIES - PROPRIETARY

Page 12

1xEV Technology

RF Optimization Guidelines

up to 12,000 bits

Link Layer Packet

sequence number of the first byte

RLP Layer Packet


22 MAC + Stream Layer Headers 976 bits

MAC Layer Packet


4 998 bits

pad

CRC

Physical Layer Packet


1,002 bits 22 1,002 bits 22 1,002 bits 22

1-4 MAC Layer Packets

Figure 1: Layering Structure for 1xEV Forward Link Traffic Channel

Physical layer at the receive side of either of the links collects the received packets, performs CRC checks, and discards those packets that are in error. After several intermediate steps where additional headers are removed, good packets are delivered to the RLP layer. In a nut-shell, RLP at the mobile side looks into the sequence numbers of the RLP packets when a gap in the sequence is detected (normally because Physical Layer discarded a packet with bad CRC), RLP sends a special reverse link traffic message called NAK (negative acknowledgment), requesting the retransmission of all the bytes it has not received. Simultaneously, it initiates a 0.5 sec timer, and if the timer expires before the requested data is received (RLP Time-Out), the RLP layer declares an uncorrectable error, and delivers data (with a gap) to the Application Layer. Further recovery of the data missing in the gap becomes a responsibility of the Application Layer protocols (1xEV RLP supports just one retry). Note that the overheads associated with Physical, MAC, Stream and RLP layer on the forward link add to about 5% of the Physical Layer rate, and additional about 5% are expected to be lost due to control channel signaling, in traffic messaging, RLP retransmissions, etc. Another up to about 10% of the forward link throughput can be lost in the single user per sector tests due to DRC erasures. These are introduced to minimize the chance that that the DRC requests from the mobile are incorrectly decoded wrong DRC received by the base station would produce a forward link transmission at a rate that mobile cannot decode. This would cause a loss of that forward link packet, and a waste of capacity. Much better strategy that base stations follow is to declare a DRC erasure whenever the demodulator decides that the received DRC is likely to be in error.

LUCENT TECHNOLOGIES - PROPRIETARY

Page 13

1xEV Technology

RF Optimization Guidelines

The impact of DRC erasures on forward link is rather small if there are several users in the sector. In case of an erasure, data will be directed to those mobiles that had no erasures, with very small hit in capacity, i.e. aggregate sector throughput (even with 10% individual erasure rate, the probability that no correct DRC is received with only 3 terminals is negligible). If there is just one mobile in the sector, erased DRC in an empty slot mean that the terminal will not receive any data in that slot. If that single terminal happens to be in very good RF environment where the requested rates are 1.8Mbps or 2.4Mpbs, erasure percentage maps directly into the percentage of throughput loss, because these transmissions require one slot. When the single mobile is requesting rates that require 8 or 16 slots, DRC erasure would effectively delay the transmission by 1 slot, which would represent a relatively small loss (1/8 or 1/16 of 10%). On the reverse link, overheads associated with Physical, MAC, Stream and RLP layer are fixed and amount to 48 bits. Due to different packet sizes for different rates, however, this loss amounts to between 18% (at lowest data rate of 9.6kbps) and 1.2% (at highest data rate of 153kbps). About 1% is once again lost for RLP retransmissions, and about 1% for in-traffic messaging (there is no loss for control channel overhead on reverse link, nor due to DRC erasures). 1.8 Higher Layers

Above the RLP layer, data applications such as HTTP, FTP, video/audio streaming, e-mails, etc. in 1xEV use PPP, IP and TCP or UDP protocols. Although all these protocols are terminated strictly speaking outside of the Lucents 1xEV system (at server, PDSN or client), they impact the performance and have to be understood to some extent. More detailed discussion and summary of the various recommended settings for higher layer protocols is available in a separate document14. The default value for the packet size (aka as Maximum Transmission Unit MTU) for most modern terminal equipment is 1,500 bytes. Other values can be negotiated during the TCP set-up, and can also be used for UDP transfers. Out of the actual packet size, headers for the upper layers normally occupy 45 bytes (5 bytes for PPP, 20 bytes for IP, and 20 bytes TCP), or 33 bytes (5 bytes for PPP, 20 bytes for IP, and 8 bytes UDP), as depicted in Figure 2. Note that these are the most often-encountered header sizes, both TCP and UDP have options that can extend them beyond the numbers quoted. The only exception from the layering structure in Figure 2 likely to be encountered during the RF optimization is when PING application is run for system sanity check, or access testing (see Section 5.5 for more details). PING uses ICMP protocol and has an 8-byte header, so that the total overhead amounts to 33bytes (5 for PPP, 20 for IP, and 8 for ICMP). Default size PING of 32 bytes would thus require 32+33=65bytes over the air. It should be noticed that the PPP headers and trailers normally amount to 5 bytes total, but the header can be extended in some implementations. Also, on the PPP layer there is usually a small (normally around 0.3%) overhead due to the escaping of characters 0x7E and 0x7d, in order to avoid confusion with the PPP header 0x7E15.

14

Translation Application Note # 5, High level Protocol Stack Parameter Optimization for 1xEV-DO, available from http://rfcoresupport.wh.lucent.com/RFCoreSupportWebPage/rf_trans_appl_1xev.htm Note that most PDSN per default escape all the ASCII control characters (bytes with values less than 0x20), which can cause some extra overheads. During the measurements, PDSN should be set not to escape those characters.

15

LUCENT TECHNOLOGIES - PROPRIETARY

Page 14

1xEV Technology

RF Optimization Guidelines

Application Data
up to 1460 byts IP Layer Header

IP Layer Packet
20 UDP or TCP Header

UDP/TCP Layer Packet


8-20 PPP Header Up to 1480 bytes

PPP Trailer

PPP Layer Packet


2 up to 1500 bytes 3

Figure 2: Upper Layers Structure for 1xEV

The higher layers thus introduce about 3% overhead in the default size packets. It should be noted, however, that a packet can be substantially shorter than the MTU if there is not enough data to transmit in the queue for instance, the acknowledgments on the other link during an FTP file download which uses TCP contain no data (i.e. only the protocol overhead is transmitted on the uplink). Option to reduce this overhead is invoked by the IP Header Compression, often called Van Jacobson or VJ compression, in which the headers are typically compressed to 11-12 bytes only, giving under 1% total loss due to overhead. Unfortunately, VJ compression scheme is much more sensitive to packet losses, which occasionally occur in spite of the RLP re-transmissions (and sometimes due to packet drops on the network side, from the FMS to the data server), and is not recommended. Another option associated with the upper layers is to use the so-called PPP Software Compression. This is a file-compression executed before the transmission, and decompression after the reception (similar to other file compressing techniques such as WinZip) that is completely transparent to the user. Depending on the content of the file, this can give a dramatic improvement in the perceived throughput (typically by a factor of 2 with HTTP downloads, from nothing to 10 times with FTP, depending on the compressibility of the file). Recommendation for PPP Software Compression is presently to turn it ON, but in order to avoid ambiguous results during the tests any FTP transfers have to use uncompressible files only (see Sect 5.4 for further details)16.

16

Since PPP compression works on the PPP layer, TCP and IP headers are normally compressed when it is invoked. This compression can reduce the round-trip time (RTT), especially because fewer reverse link frames are needed

LUCENT TECHNOLOGIES - PROPRIETARY

Page 15

1xEV Technology

RF Optimization Guidelines

Another important parameter for application layer testing is the TCP Window Size, which defines how much data can sender transmit before receiving an acknowledgment from the receiver. The maximum theoretical throughput with TCP is given by:

Maximum Throughput =

TCP Window Size , Round Trip Time

where Round Trip Time (RTT) defines the time needed for a TCP acknowledgment to arrive for a full TCP segment (normally 1500 bytes). With VJ compression OFF and PPP compression OFF, RTT to the server connected to PDSN17 is theoretically in the 110-120msec range (normal TCP acknowledgments cannot fit in the single reverse link frame; with compression ON they always fit into one frame, giving the results in the 80-90msec range). Note that some mobile terminals have larger RTT than what the theoretical calculations assume18. With Windows 2000 default TCP Window Setting of 16kB (actually 17,520kB), the RTT limits the maximum possible throughput well below the limitations of the Physical Layer in all but the very challenging RF environments. To avoid this situation, any tests using TCP that are run to demonstrate the throughput performance should be executed with the TCP Window Size altered from default value of 16kB to 64kB. The maximum theoretical throughput based on the Window Size and RTT cannot be reached in practice with some TCP based applications. Most important one is probably the HTTP, where the structure of the typical web pages (many embedded, only a few kB large objects which are retrieved serially) usually prevents the transmitter from filling the TCP Window with the data. Most common application that can exploit the full benefit of the larger window size is the FTP, provided that the downloaded file is large enough (say, larger than 1MB). However, even in that case the maximum limit cannot be achieved because of the remaining errors after the RLP re-transmissions, which have to be corrected by the TCP layer itself (Fast Retransmit mechanism). Exact analysis of this loss is very involved, but with random errors and 1% target packet error rate, they should amount to about 10% throughput loss19. In mobile testing where signals could go through longer periods of fading, losses can be larger (TCP time-out and Slow Start mechanism). TCP protocol being so sensitive to RTT and packet losses, Lucent must ensure that in any testing with TCP-based applications (FTP, HTTP) there are no additional delays or packet drops between the client laptop and the server. Given the unpredictability of the Internet traffic performance, and that the operators internal data networks (from PDSN to the ISP contact point) at this stage often show quite poor performance, it is essential that all applications testing is executed using a dedicated server

for short TCP acknowledgments or ICMP messages. This would effectively reduce the RTT as seen by FTP, and improve the throughput even with the uncompressible files.
17 18

Remote servers can have significantly larger RTT, if they are accessed through Internet. Chester ver.3.1 has an additional delay of one frame (26.7msec), giving the results in 140msec range without compression. Chester ver.3.2 does not have that additional delay, and neither did Hornet. With 1% packet error frame, the RLP error probability is at best 2(0.01)2, or about 0.02%, but can be somewhat larger (up to typ. 2 times because retransmitted packet may need two Physical Layer packets to go through). One 1,500 byte packet on the forward link requires between 4 and 13 physical layer packets, depending on the actual data rate, so the packet error rate on the TCP layer is expected to be between roughly 0.1% (highest) and 0.5% (lowest data rate). TCP throughput loss due to Fast Retransmits and Congestion Avoidance is expected to be between 5 and 20%. Since the lowest rates are quite rarely invoked, and have larger RTT that makes effective TCP window smaller, the high-end numbers are rarely seen in the field.

19

LUCENT TECHNOLOGIES - PROPRIETARY

Page 16

1xEV Technology

RF Optimization Guidelines

connected directly to PDSN. This dedicated server should be used for all testing, but is absolutely essential for any warranty related throughput measurements. 1.9 Expected 1xEV System Performance

Coverage of 1xEV is expected to be practically equal to that of IS-95. From the reverse link perspective, 2G and 3G systems do not have some of the 1xEV overheads (e.g. power needed to transmit DRCs or Physical Layer ACQ), but require more Eb/No due to less powerful coding scheme. The overall performances assuming the same terminal transmit power are expected to be within a dB or so from each other, which is almost the same from field testing standpoint. The forward link coverage of 1xEV for the data rate of 76.8 kbps20 is expected to be somewhat larger than that of 2G or 3G terminals at 9.6kbps. This is due in part to the almost 10dB gain between transmit powers (a traffic channel in IS-95 when at maximum power is about 2dB below pilot signal, which is in turn about 8dB below the nominal transmit power that 1xEV regularly uses for transmission). Out of this 10dB advantage, 9dB is immediately lost due to the 8-fold rate difference. Beyond this 1dB gain, quite different sets of numbers can be created giving additional gains of 0-6dB to 1xEV, depending on whether dual or single antenna terminals are considered (about 2dB difference), different assumptions about Eb/No requirements for various fading scenarios, whether control channel or traffic channel coverage is considered, various soft handoff assumptions for edge of coverage, and various assumptions as to what a fair comparison is in terms of the power and throughput allocated and received. From the system deployment perspective, evaluating the exact forward link budget advantage is largely an academic exercise, because 1xEV coverage is limited and determined by the weaker (reverse) link, and reverse link is practically equivalent to 2G/3G. Any forward link advantage is a consequence of the asymmetric data rate requirements that 1xEV is designed for, and cannot be exploited for rangeextension purposes (i.e. to reduce the number of sites deployed as compared to underlying IS-95 in Overlay scenarios, plan fewer sites to cover highways, etc.). From the 1xEV field-testing perspective, the forward link advantage in terms of the link budget seems to be within a few dBs in most unloaded scenarios, and is not obviously detectable in most runs. Present link budgets assume that the reverse link loading equivalent to the noise rise at the base station of around 5dB, which should be detectable in most coverage runs (i.e. the reverse link would break first). Reverse link data (packet error rates and throughputs) thus need to be collected in all such tests. For more detailed discussion of the 1xEV link budgets, Lucent 1xEV Design Guidelines should be consulted21. In terms of the connection set-up (origination and termination) performance, ineffective attempts for 1xEV are expected to be at par or better than IS-95B (which includes a series of access improvements compared to IS-95), with expected failure rates around 2%. This is due to the essentially the same access mechanisms on the reverse link for both systems (1xEV can complete the access in somewhat shorter time, which is expected to give some improvement in the failure rates). Dropped call performance is in general very difficult to predict theoretically. Again, from the reverse link perspective very similar performance is to be expected. From the forward, most theoretical expectations are that the link budget advantage would mean fewer dropped calls, but it was not clear what this might mean for the overall drop call rate. When the number of drops is normalized to 90100sec duration of the call for easier comparisons with data from voice world, the field tests executed

20

Minimum data rate is 38.4 kbps, but the Control Channel is presently transmitted at 76.8kbps. Mobile drops the connection if the overhead messages over Control Channel cannot be received for about 5 sec.
files/rfelib/ guidelines/guidelines.html

21

Ron

Brown,

1xEV

RF

Engineering

Guidelines,

http://nwswww.wh.lucent.com/~seamps/

LUCENT TECHNOLOGIES - PROPRIETARY

Page 17

1xEV Technology

RF Optimization Guidelines

so far suggest that the drop call rates below 2% are easily achieved. . Similar results of under 2% are achievable for access failures (ineffective attempts). Regarding the ineffective attempts and drop call rates, it is important to realize the difference between voice and data calls. In the voice world, ineffective attempt is a failure to establish the call, and the drop is the release not initiated by either of the calling parties22. Data calls, on the other hand, actually get established and released as the application dictates (1xEV incorporates a dormancy timer, which releases the connections after about 10 seconds of inactivity). End users are normally not aware of any of these processes going on in the background (for instance, during web browsing in most instances the connection will be released while users are reading the page, and reestablished when the new page is requested). If the call fails to establish, or drops, call will be automatically reattempted if the application has any data that needs to be sent. In usual scenario, call will quickly reconnect, and the application would continue, with only a few seconds extra delay perceived by the end user. For that reason the drop call rates also cannot be always measured from the application layer perspective (by looking at the FTP output for instance), but have to be identified from mobile logs as connection releases that were not initiated by the application. Expected throughput results are very difficult to specify, because of the numerous caveats associated with them. Present Lucent simulations for 1-antenna terminal suggest that forward link throughput in a single user per sector case when averaged over the whole sector area should be in the 500-600kbps range under mobile conditions (pedestrian and vehicular traffic), and about 650-700 kbps when stationary. These results apply to the situation when the application keeps the data queue full all the time (in practical tests, this would mean using the UDP application with offered throughput in excess of 2Mbps), and all the surrounding sectors being fully loaded on the forward link. FTP throughput in such cases should be about 10-20% less, i.e. in the 400-500 kbps range. If the tests are executed with 2-antenna terminals, theoretical analyses and the field results obtained so far suggest an improvement of 50%. At present, there are a few simulations targeted specifically to the reverse link throughput evaluation (not that there is no difference between 1 and 2 antenna terminals on the reverse link 2 antenna mobiles do not support the transmit diversity, and base station antenna diversity gain is accounted for in all link budget and capacity evaluations). Relatively small amount of field data in the single user environment suggests that maximum throughputs of the order of 135kbps with UDP and around 120kbps with FTP are achievable in large areas of the cell. So far all the users have been very interested in the maximum forward throughput results that can be obtained in the best possible environment23. With UDP application, in such scenario we would expect forward throughput to be about 20% lower than the requested rate (10% going to overheads up to RLP layer, 3% for overheads on PPP, IP and UDP layer, and about 5-10% lost due to DRC erasures), i.e. the UDP throughput should be in the 1.8-2.0Mbps range. If the tests are executed with the FTP protocol, we would expect 1.8-1.9Mbps, since the additional loss should be in the 10% range (assuming the 64kB TCP Window Size). On the reverse link, maximum throughputs of around 144kbps are attainable with either UDP or FTP, the difference to maximum 153kbps rate being eaten up by overheads (1.2%), RLP retransmissions (1%), in-traffic signaling (1%), and TCP/IP overheads (3%). Note that the FTP losses due to RLP layer errors tend to have much smaller impact on reverse link, due to larger RTT delay and smaller effective window sizes.

22

Silent retry for originations and repeated paging strategies sometimes blurs the perception about ineffective call attempts, because the failures are hidden from the end users they perceive extra call set-up delay rather than a failure, which makes them more similar to the experience with data call. Near the cell, in the area covered by just one sector, with mobile receive power in 60dB to 80dB range, SNR>11dB and requested rate at 2.4Mbps more than 95% of the time

23

LUCENT TECHNOLOGIES - PROPRIETARY

Page 18

1xEV Technology

RF Optimization Guidelines

In multi-user scenario, present simulation suggests that the average forward UDP throughput for stationary users increases by close to 10% when the number of users exceeds 5 (this seems to be due to lower losses due to DRC erasures, as there is no scheduling gain for the non-fading case). Similarly, there would be about 10% throughput increase in the vehicular traffic case (DRC reports are not fast enough to keep up with the fast fading at speeds above 20-30mph, making scheduler less effective). Average pedestrian throughput with 8 users active within one sector, however, increases from 500600kbps to about 800-1,000kbps (results become more sensitive to the actual multipath scenario; in addition, typically 8-10 simultaneous users are required to achieve full scheduling gain benefit). If FTP is used instead of UDP for multi-user tests, loss is expected to be in the 10-20% range (effect of DRC erasures is drastically reduced with several simultaneous users in the sector). Aggregate reverse link throughput in multi-user scenario was much less tested so far. Results with 4 terminals in good RF conditions suggest that aggregate throughputs over 250kbps can be supported, but more tests will be needed to refine this estimate under various RF conditions. It should be mentioned that customers often ask and want to measure the capacity in terms of the number of simultaneous users that can be supported in the sector. Lucent position is to give guidelines and eventually guarantee the aggregate sector throughput (which will probably be measured on the RLP layer). As Lucent, we are trying to stay away from discussing how that throughput can be split among how many users, because the throughput requirements for individual users depend on the number of the traffic model assumptions about which at present we have only some more or less educated guesses (for instance, distribution of applications among users: how many of them will be downloading large files, using streaming audio or video, browsing the web, reading e-mails, etc.; how often they will be doing that, and how much time they will spend in between reading the web pages, or reading and answering emails, etc.). Every effort should be made that no such tests are negotiated during any trial, and they are clearly out of scope of any optimization work. Systems Engineering should be consulted in all such cases they can provide estimates based on the measured aggregate sector throughputs for various traffic models of interest. 1.10 Exit Criteria and Expected Results for RF Optimization work This section presents a proposed set of internal exit criteria for the RF optimization work, in the absence of a contract. If the RF optimization work is performed under any contract agreement with customer that includes performance guarantees, those should be used instead of the criteria proposed here. Pre-commercial optimization work would be based on vehicular tests in a single-user environment. In routine optimization work, data to be evaluated against the Exit Criteria is to be collected along Cluster Control routes (roughly 1 hour per cluster of about 20 cells, covering most primary roads), and System Control routes (spanning multiple clusters at the end of market optimization, roughly 1 hour per each of the encompassed cluster, see Sections 8.3 and 8.5. Exit Criteria are also expected to be met along the Cluster Optimization route in each cluster that is optimized (all primary and most secondary roads within the cluster of typically 20 cells, about 8 hours of driving, see Section 8.3), but this data is normally not collected at the end of the optimization procedure and included into the deliverables. In some special cases, especially involving performance or marketing trials with the customers, Optimization teams might be asked to measure and ensure meeting the Exit Criteria over Cluster Optimization routes as well. On any of the routes, typical vehicle speeds along the selected routes should be used. 1xEV-only terminals should be used (no Hybrid Mode). Simple IP or Mobile IP configuration will depend on customers preferred method of operating the network, so Lucent will not have much control over it. All the expected results in this section for Mobile IP mode assume MSM5500 chipset based AT. The newer chipset MSM6500 show significant improvements in MIP mode over the predecessor, but such terminals are being evaluated and not deemed ready at this time for exit criteria testing.

LUCENT TECHNOLOGIES - PROPRIETARY

Page 19

1xEV Technology

RF Optimization Guidelines

Neither Idle Channel Gain, nor FLUS will be used in these measurements. Results are given for the FTP application only, and assume that TCP Window size of 64kB is used. UDP based application (such as WINDS, see section 5.3) are expected to give throughput results larger by about 10% than in Table 1, and it would be in Lucents best interest to execute all the optimization related tests with UDP application. Unfortunately, at this time UDP application still cannot be universally recommended, because of some backbone networking issues and possibly due to some issue with the WINDS tool itself (see Section 5.3 for further details). Note that presently available throughput measurements suggest that the expected results are quite conservative, especially without interference from surrounding sectors. Also, expected results are given both for terminals with single and dual antennas. Given the choice, Lucent should always opt for tests with 2 antenna terminals, in order to present better results to the customer. Metric Connection Origination failure rate Drop connection rate per 90 sec Average Forward Throughput, 1-antenna terminal with FTP Average Forward Throughput, 2-antenna terminal with FTP Average Reverse Throughput, 1-antenna terminal with FTP Average Reverse Throughput, 2-antenna terminal with FTP Simple IP vs Mobile Expected IP Result SIP/MIP SIP/MIP SIP MIP (MSM5500) SIP MIP (MSM5500) SIP/MIP SIP/MIP 1.5-2.5% 1.5-2% 500kbps 350kbps 700kbps 400kbps 70kbps 70kbps Exit Criteria <3% <3% >400kbps >300kbps >500kbps >350 kbps 50kbps 50kbps

Table 1: Exit Criteria for Optimization, FTP (64kB window), typical mobile speeds, 1xEV-only mode

Note that Lucent recommendations for cell backhaul specify that each cell should be provisioned with two T1 links, but in some situations operators can opt to deploy only one T1 (at least initially, to save some expenses). If the optimization is to be performed in such cells, the maximum forward throughput results will be lower, typ. around 1.2Mbps (it cannot reach the raw 1.54Mbps T1 rate because of various overheads over T1 link, and the need to operate at less than 100% utilization to avoid excessive queuing). One T1 limitation has no impact upon the reverse link performance. In mobile conditions, throughputs above 1.3Mbps are experienced less than 10% of the time with 2 antenna terminals, and hardly ever with one antenna terminal. Given that maximum throughputs practically do not exceed 1.6Mbps even with 2 antenna terminals, results from Table 1 are readily achievable in deployments with both one and two T1 backhaul configuration. However, if the operator is deploying cells in one T1 configuration only, good practice is to try to reduce the Exit Criteria by 10% compared to whatever is agreed for two T1s configuration. For Table 1 results, no data points other than from coverage holes should be excluded from the metrics calculations (for more details regarding the criteria for the whole, see Section 9.1; in any case, no data points with Mobile Receive power above 105dBm should be excluded. If such areas exist along the routes, optimization team is expected to document the findings, and modify the test routes accordingly, in agreement with the customer. In flat areas, this normally means that no data point should be excluded

LUCENT TECHNOLOGIES - PROPRIETARY

Page 20

1xEV Technology

RF Optimization Guidelines

from within at least 1.5 miles from the nearest cell in urban environment, and at least 3 miles in suburban and open areas. Distances up to 3 miles in urban, and 5 miles in suburban and open flat areas should be routinely covered24. Results from Table 1 should be also met in any optimization work that leads to the customer performance trials, FOA, customers friendly users and marketing trials, etc. In addition, customers during trials often require that the maximum possible throughput be measured, which seems to be important mostly for marketing reasons, i.e. to establish the maximum throughput that can be advertised. Expected results for such tests, which are to be executed at locations near the cell where highest data rate of 2.4Mbps will be requested in stationary conditions at least 95% of the time, are presented in Table 2. Note that in such stationary conditions there is virtually no difference between 1 and 2 antenna terminals. Results assume that there are no other active terminals in the sector where the test is done. The requirements from Table 2 are also expected to be met for each sector in Cabled Throughput Test (Close Loop Test) executed during cell installation, and during the stationary portion of the Functional Tests (Sector Tests). The maximum throughput requirements in that case ensure that base station hardware is operating correctly, and that the backhaul performance is adequate. Metric Best 25Forward Throughput, two-T1 cell Best Forward Throughput, one T1 cell Best Reverse Throughput Simple IP Mobile IP SIP MIP (MSM5500) SIP MIP (MSM5500) SIP/MIP vs Expected Result 1.8-1.9Mbps 700 kbps 1.2-1.3Mbps 700 kbps 140kbps Exit Criteria >1.7Mbps > 500 kbps >1Mbps > 500 kbps >120kbps

Table 2: Best stationary FTP throughputs requirements (single AT in the sector, 1xEV-only mode)

Given that during cluster optimization the number of sectors to be tested can easily be in the 50-100 range, it is conceivable that test teams will not have enough time to find a location where the maximum requested rate of 2.4Mbps can be supported in each sector. If the average requested rate is below 2.4Mbps, then criteria from Table 3 should be used. If locations where the average requested rate is above 1.2Mbps cannot be found with little effort, this would normally suggest some kind of a cell problem (there are no intermediate rates between 1.2 and 1.8Mbps).

24

Note that formal Warranty Tests executed to meet Exit Criteria usually allow certain percentage of worst bins to be discarded, independent of whether they satisfy the conditions for coverage hole. Locations immediately underneath the cell are not favorable, because they are often out of the main vertical lobe of the sector antennas chosen for the test, and the other two sectors are likely to interfere. Tests should be done at some distance from the cell ( to of the cell radius, MRx in 60 to 80dBm range), in the main horizontal antenna lobe of one sector, preferably under the line-of-sight conditions. No additional pilots should be detectable. Requested rate should be 2.4Mbps at least 95% of the time at the chosen location.

25

LUCENT TECHNOLOGIES - PROPRIETARY

Page 21

1xEV Technology

RF Optimization Guidelines

Metric FTP Forward Throughput, single stationary terminal FTP Reverse Throughput, single stationary terminal

Simple IP vs Mobile IP Simple IP Mobile IP (MSM5500)

Expected Result Req.Rate 35% 700 kbps 130kbps

Exit Criteria > Req,Rate 45% > 500 kbps >110kbps

Table 3: Stationary throughput requirements for Functional Tests (Requested Rate > 1.5Mbps)

As for the reverse link rates, they are much less sensitive to location and RF conditions, and the same result as in the best case should be achieved with little or no effort. Another often requested set of tests during trials involves various aggregate sector throughput tests in multi-user environment, mostly under stationary and pedestrian conditions. Although Section 1.9 covers some of the expected results for such cases, these tests are too specialized and as such are beyond the scope of this document, which deals with more routine RF optimization procedures. Additional results on expected system performance, which go beyond the conditions of interest during optimization (non-controlled environment, other applications such as HTTP, etc.) can be found in the corresponding Performance Expectation document26.

26

R.Sinha: 3G1x-EVDO Performance Expectations, available on http://rfcoresupport.wh.lucent.com/ RFCoreSupportWebPage/guidelines.htm

LUCENT TECHNOLOGIES - PROPRIETARY

Page 22

1xEV Technology

RF Optimization Guidelines

2 1xEV Deployment Scenarios


At the highest level, 1xEV deployment can be classified as: Cold Start (no underlying 2G or 3G CDMA network) Overlay on top of an existing 2G/3G network o Ubiquitous (1xEV added in all areas that operator covers) Complete 1:1 overlay (cells overlaid 100%, no cells missed) Incomplete, or near 1:1 overlay (overlay on more than 95% cells) Limited (1xEV added in core cells, no 1xEV outside the core) Complete 1:1 overlay (cells overlaid 100%, no cells missed) Incomplete, or near 1:1 overlay (overlay on more than 95% cells)

Based on the information available so far, it seems safe to assume that all deployments planned for the next 1-2 years assume overlay scenario. Thus, more specifics related to the Cold Start scenario might be added at the later date, when more experience becomes available.

 [ ( 9 ' 2

**

Figure 3: Limited Incomplete Overlay of 1xEV

Limited overlay indicates that there is a border between 1xEV coverage area and underlying 2G/3G CDMA system. Due to economic constraints, the probability that operators would choose to go with ubiquitous 1xEV coverage throughout all cells is very small much more likely deployment scenario for years to come would be that operators would deploy 1xEV in major urban areas, and rely on either 2G or 3G underlay system to provide for data services. In what follows, we will thus consider mainly the Limited overlay27.

27

It can be argued that a Complete overlay is the Limited overlay with no intra-system border issues to address, so that this covers all cases. In reality, assuming that the proper guard band are ensured, inter-system borders issues for a Complete 1xEV overlay are the same as for 2G/3G, i.e. usual frequency coordination rules would

LUCENT TECHNOLOGIES - PROPRIETARY

8 76!5 4 9   $ ( % " $ 0 ( & % #3 '21'10 )'


Page 23

$#! ""#! $     

1xEV Technology

RF Optimization Guidelines

Within the covered area, for the reasons that will become obvious later on Lucent recommendation is that operators should deploy the 1xEV technology in all cells and all sectors within the core area, and have all eventual repeaters repeating the 1xEV frequency as well. In other words, Lucent recommendation is that operators go with Complete 1:1 overlay of 1xEV technology. However, real life constraints might create a situation where operators cannot deploy 1xEV in all the cells in the core coverage area. One such example would be a scenario where the available cell footprint does not allow for the deployment of new cabinet to accommodate for 1xEV carrier. In other cases operators might decide to skip some cells because of the interference concerns, or because of the repeaters that do not support new carrier (or were deployed to address specific coverage issues not relevant for 1xEV users), etc. Incomplete deployments are expected to be limited to the situations where individual cells within the core area had to be skipped while 1xEV was deployed. If marketing reasons suggest that 1xEV should not be deployed in an area, the assumption is that the 1xEV 2G/3G transition borders would be identified and engineered following the principles similar to those for deployment of higher CDMA carriers (i.e.. limited traffic capacity, no long concave borders), and then tested and optimized as in the Limited deployment scenario. Ad hoc skipping of the cells and/or sectors in the core 1xEV coverage area can create adverse effects to both the 1xEV systems and the underlying 2G/3G system, and is therefore strongly discouraged. In the rest of this document we will assume that the 1xEV deployment to be optimized is not only Limited, but also Incomplete. If the overlay ends up being Complete, i.e. true 1:1 deployment of the 1xEV cells can be achieved, then the sections dealing with skipped sites should be skipped as well.

ensure that the inter-system interferences are avoided, and the inter-system handoffs for such cases are at present not supported.

LUCENT TECHNOLOGIES - PROPRIETARY

Page 24

1xEV Technology

RF Optimization Guidelines

3 Overview of 1xEV RF Optimization


The basic goals of RF optimization are similar to those of 2G or 3G systems, namely to improve the system performance so that it meets contractual or other objectives defined jointly by Lucent and the operators. In optimization efforts prior to the various trials and FOA, internal exit criteria as discussed in Section 1.10 should be used. The first step in any successful optimization is good design. The design guidelines for 1xEV are covered in a separate document28. Although there are a lot of similarities between designs for 2G and 3G systems on one side, and 1xEV on the other (e.g. general lay-out, pointing of the antennas, PN offset reuse planning, many translation parameters, etc), it is conceivable that some elements could be quite different, especially because of the forward link differences. In particular, optimum antenna radiation beamwidths and rolloffs could prove to be very different, as well as the handoff parameters, but this can make a difference only in some cold start scenarios. Good default translation parameters are another indispensable tool for any useful RF optimization. Recommended values for those that are RF-related are maintained in separate document suite29. 3.1 Optimization Process

Optimization process can be divided into 3 stages, encompassing the following activities: 1) Pre-Optimization Preparations a) Spectrum Clearing (optional, for further details see Section 7.1) b) Underline System Baselining (optional, in overlay scenarios, see Section 7.2) c) Drive Routes Planning d) Neighbor List Preparations e) Translations Verifications 2) Optimization a) Cabled Test (aka Closed Loop, optional, see Appendix, Section 10for further details) b) Sector Test (aka Functional Test, performed in each sector) c) Cluster Test (performed on the clusters with target size of about 20 cells) d) System Test (performed on the whole system level, encompassing multiple clusters) 3) Report Preparation Formal deliverables are discussed within this report for activities 1a), 2a), 2b) and 2c). Deliverables for 2d) are subject to the contractual agreements between Lucent and the operators, and will be defined at the later date (often these have to be defined on the case-by-case basis, because of the differences between different contracts.

28

guidelines/guidelines.html
29

1xEV-DO RF Engineering Guidelines, http://nwswww.wh.lucent.com/~seamps/files/rfelib/ 1xEV Translations Application Notes, http://rfcoresupport.wh.lucent.com/RFCoreSupport

WebPage/ rf_trans_appl_1xev.htm

LUCENT TECHNOLOGIES - PROPRIETARY

Page 25

1xEV Technology

RF Optimization Guidelines

3.2

Optimization Methodologies

Bulk of the optimization work is performed during the Cluster Testing stage. Typically it involves drive test surveys, identification of the problem areas, adjustments, verification drives in the problem area, and final drives along the control routes to demonstrate that Exit Criteria were met. Tools, methodologies and procedure for data collection are discussed in Sections 4, 5, and 6. Methods to determine various problem categories, and the troubleshooting procedures themselves, are discusses in Section 9. Besides data collection and reporting, the core optimization work includes adjusting the antenna configurations (e.g. down-tilts, azimuths, patterns/types or heights), fine-tuning the transmit power, fine tuning of some RF translation parameters, changing the cells layouts (e.g. deploying new or moving existing cells), etc. Corrective actions related to antennas are most frequent in the Cold Start deployments. They are more rare in overlays; firstly because the systems have already been Cold Start optimized before, secondly because of the concerns about potential performance issues that could be created for underlay system; fine-tuning of the transmit powers is usually the most effective tool in such scenarios. Cell layout changes, on the other hand, are long-term changes that are usually not performed by Lucent, but by the operators who will bear the associated extra costs after the optimization work is done.

LUCENT TECHNOLOGIES - PROPRIETARY

Page 26

1xEV Technology

RF Optimization Guidelines

4 RF Optimization Tools
This section presents various hardware and software tools required for 1xEV data collection. An RF toolkit is utilized to collect RF air interface messages and performance data from a 1xEV mobile or access terminal (AT). This toolkit is similar to that used during 2G or 3G optimization, with some changes to accommodate 1xEV AT and associated components. While the laptop within the toolkit acts as a client, a Windows 2000 based laptop or PC is also needed to act as a server for 1xEV data sessions. In addition to collecting data at RF toolkit end, RF performance data is also collected at the access network via Packrat or Air Interface Performance Monitoring Tool (AIPMON). These GUI based tools provide functionality similar to RF Call Trace. It should be noted that the bulk of the routine optimization work could be done without the AIPMON, because the RF data collected at the AT side provides enough information to quantify the first-order performance of the reverse link (most notably an estimate of the reverse link packet error rates). It is still recommended that either of the tools is deployed in the field, if more precise reverse link evaluation is needed (esp. for troubleshooting). Various data collection and processing tools are discussed in this section. 4.1 RF Data Collection Toolkits

The data collection toolkit requirements for 1xEV optimization depend on the deployment scenario adopted by customer. For cold start deployments, toolkits will be used to collect data only on 1xEV carrier. For overlay deployments, additional toolkit may be needed to collect data for underlying 2G or 3G carrier. This section describes toolkit components for 1xEV data collection. A typical 1xEV drive test toolkit consists of the components listed in Table 4.

Part

1 Laptop with CD-RW 2 Access Terminal with accessories (power cable) 3 USB connection cable 4 GPS unit 5 Attenuation boxes 6 Power supply 7 GPS antenna 8 RF antenna 9 Shipping case 10 Cable parts 11 Splitters

Description QTY/Kit Panasonic CF-48 with 2 USB ports, running CAIT and Data application software 1 Characterized Qualcomms MSM5500 based Chester 2 and components Provides connection between Chester and laptop for 2 both data application and CAIT Trimble V Eight GPS interfaces with CAIT to log position 1 JFW Attenuators for forward and reverse link losses and/or loading 4 Allcom power box for toolkit components 1 Magmount Trimble 1 Antenna with known gain, mounted on top of drive test van 2 Starcase bluebox to package various toolkit components, except antennas 1 Miscellaneous (cables and connector adaptors) Mini-Circuits ZPD-2-1 or equivalent 2

Table 4: 1xEV RF Toolkit Component list single laptop configuration

LUCENT TECHNOLOGIES - PROPRIETARY

Page 27

1xEV Technology

RF Optimization Guidelines

Figure 4 illustrates 1xEV toolkit components and connectivity within a drive test vehicle. In the initial deployments, toolkits consisting of 2 laptops one for each of the two ATs were utilized. Current practice is to utilize single laptop toolkits. This saves the cost of a laptop as well as a CAIT license. CAIT as well as data application (FTP, ping, etc.) for both the ATs is controlled via the same laptop. This requires the use of WINDS tool to run FTP and ping. WINDS modifies the network settings in the client laptop to properly route and bind data traffic to the respective ATs something the native DOS applications cant automatically perform. WINDS supports FTP download (similar to DOS FTPs getT command), FTP upload (similar to DOS FTPs put command) and ping (similar to DOS ping command) applications.
GPS Antenna Mag-Mount Antennas

GPS Receiver

CAIT Laptop 1
USB Connection 1

Attenuation Box 1

Isolation Box

Attenuation Box 3

Power Supply

To power adapter

Attenuation Box 4
USB Connection 2

Attenuation Box 2
RF Toolkit

Figure 4: 1xEV RF Toolkit Components single laptop configuration

LUCENT TECHNOLOGIES - PROPRIETARY

Page 28

1xEV Technology

RF Optimization Guidelines

Since most 1xEV terminals appear to be two antenna devices so far, care must be exercised when MagMount antennas are placed on the roof of the vehicle to ensure that spacing between them replicates that on the terminals as much as possible. In some cases this might not be possible, because of the antenna pedestals. Antennas should be moved as close as possible in such situations spacing in excess of 4-5 inches would usually produce too optimistic results.

4.2

1xEV Test Terminal

Qualcomms test phone QTP-5500, also referred to as Chester, will be used for all optimization work. Certain commercial terminals based on the newer Qualcomm MSM6500 chipset are being evaluated, but at this time no test terminals other than Chesters are recommended for the optimization.. From the RF perspective, novel feature of the Chester terminals is that they support dual diversity. At this time, two ATs are provided in a toolkit. A single USB connection between AT and laptop supports data application, as well as CAIT software. The latest approved version of the USB driver version should be used. For the information about the latest drivers, as well as for instructions about setting up of the 1xEV terminal the corresponding M&P document30 should be consulted. In particular, this document covers the following steps that need to be executed prior to any optimization work: 4.3 installation of the USB driver, programming of the PRL list (to enable terminal to find the right 1xEV operating frequencies), hybrid mode programming (1xEV only or 1xEV/3G-1X hybrid, normally the 1xEV only mode should be used exclusively, unless the contract with the customer specifies otherwise) setting up dual or single diversity (normally only dual diversity should be used, unless specified otherwise in the contract) setting of the Simple IP/Mobile IP mode CDMA Air Interface Tester (CAIT)

CAIT provides display and logging capability of technology performance information and over the air (OTA) messages. There are various screens available in CAIT to support 1xEV air interface data collection. These are: 1xEV AT Status Finger Information Pilot Sets Forward Link Statistics Reverse Link Statistics RLP Statistics Protocol Summary

Latest approved version of the CAIT should be used, and compatibility between the corresponding versions of CAIT and LDAT ensured30. Same reference should be also consulted for CAIT setup, as well as Logmask selection. The logmask should be set based on the AT firmware and the desired mode of testing 1xEV-only or Hybrid mode.

30

1xEV-DO Optimization Procedures, M&P document (layer E), RF-E151

LUCENT TECHNOLOGIES - PROPRIETARY

Page 29

1xEV Technology

RF Optimization Guidelines

Note that CAIT logging was found to reduce the achievable application layer data throughput, by from 10% to as much as 30% in the early releases. It was therefore essential that all throughput measurements to be presented to the customer were executed without CAIT logging, which posed considerable challenges for the optimization process. Present recommended versions of the Chester and CAIT software loads show negligible degradation (under Simple IP, under Mobile IP conditions loss up to 30% can be still measured, see Section 1.5 for more details). If the optimization work is executed with Simple IP, as recommended, such restrictions are not required anymore. In recent years use of pilot scanners in optimization has become very popular, because of the relative ease with which a number of problems related to neighbor list, search windows, etc. might be solved. Due to the time-gated pilot, pilot scanners developed and used in 2G/3G networks cannot be used in 1xEV. It is very probable that scanners would appear which would synchronize with pilot transmissions in 1xEV and do their measurements during these intervals only, but they seem not to be available as yet. Although 1xEV pilot scanners might not exist for some time, 2G/3G pilot scanners can still be used for optimization, at the expense of some of the speed and convenience. For instance, problems in Overlay scenario can be analyzed by using the pilot scanner on the Underlying system. In Cold Starts, scanners could be used if the sectors in the areas are switched to the Constant Pilot test mode of operation, developed primarily for maintenance purposes (cell power calibration). Given some of these difficulties, use of pilot scanners in RF optimization is expected to be limited initially, until real 1xEV scanners arrive they would probably be used for data collection in areas with extremely difficult RF problems only. When this happens, however, the methodology would be exactly the same as in 2G/3G case31. 4.4 Data Application Laptop and Software

A Windows2000 based laptop is needed to interface with 1xEV AT for making calls. Current toolkit configuration needs one laptop to support both the ATs within the toolkit. Note that this laptop is the same as CAIT laptop discussed in Section 4.3, i.e. same laptop is used to run the application and collect the logging data for both the ATs. In order to make 1xEV calls via this laptop, the following steps are initially required: Setup the dial-up networking Setup the PPP parameters Setup the TCP/IP parameters

Dial-up networking setup is straightforward and should be done following the procedure described in the corresponding M&P document30. TCP/IP and PPP parameters are set up in the similar manner, except that the PPP Compression settings have to be accounted for based on what the agreement with the customer is (Lucent default recommendations is to turn the PPP Compression ON for FTP transfers and use uncompressible files for testing; for ping testing or with any UDP testing with WINDS, it has to be turned OFF). The VJ Header Compression should be turned off. In addition, the TCP/IP options have to be set. These include setting the TCP Window Size to 64kB, and disabling the TCP Timestamps. This can be done through registry editing, but more convenient method is to doubleclick on s-w2k-65k.reg icon to set the parameters, or u-w2k-65k.reg to reset them to defaults. These two can be downloaded from http://rfcoresupport.wh.lucent.com/ RFCoreSupportWebPage/toolspage.htm. Note that some applications seem to be changing the TCP Window size autonomously, without any indication. Good field practice would be to set the window to 64kB by invoking the s-w2k-65k.reg script prior to any significant data collection run.

31

RF M&P Document RF-E040.

LUCENT TECHNOLOGIES - PROPRIETARY

Page 30

1xEV Technology

RF Optimization Guidelines

To initiate a connection, login name and password have to be obtained from the network installation team (or the customer), who pre-populated them in the PDSN/AAA. Each test laptop should preferably have a separate user name. Otherwise, the usage of smaller pull of user names has to be coordinated so that no two terminals will be attempting to use the same one. Important step in the setup of Data Application laptop is to ensure that there will be no background applications stealing throughput. These could be Windows automatic updates (check through Add/Remove Programs), Lucent tunneling software, Real Player updates (check in RealPlayer settings and dont run start center), in some cases downloads of various advertisements could occur in background windows after web browsing, etc. (might be useful to install a pop-up blocker, such as PopUp Stopper freeware). As a check, good practice is to run netstat e at the DOS command prompt, and record the numbers of bytes sent and received (netstat reports cumulative numbers). After a few minutes, run "netstat -e" again and compare the numbers of bytes sent and received with the earlier numbers. They shouldn'increase. Otherwise, further troubleshooting of the laptop may be necessary. t A number of data applications can be used during RF optimization, for example WINDS, FTP, various scripts, etc. For further details see Section 5. Based on the test scenarios agreed with the operator, some applications will need to be loaded on the Data Application Laptop as well (WINDS, FTP server software, etc). 4.5 Air Interface Performance Monitoring Network Data Collection Tools

Air Interface Performance Monitoring tool (AIPMON) is needed in RF optimization to collect relevant reverse link data, most notably the reverse packet error rates that have to be monitored routinely because of the link budget advantage in favor of the forward link. In routine optimization work, however, close approximation to the reverse packet error rate can be obtained through LDAT tool, from the Pre-RLP OER (Octet Error Rate) Reverse metric, which gives the ratio of the number of bytes whose retransmission was requested by the RLP protocol at the network side (presumably because of the bad frames received over the air), versus the number of total bytes sent by the AT within the 4sec interval. Under normal system operation, this parameter is for all practical purposes numerically equivalent to the physical layer reverse packet error rates as would be measured by AIPMON. If the application sends enough reverse link packets for statistics to be relevant (the FTP download on forward link creates enough reverse link frames carrying TCP acknowledgments, but some UDP applications might not, as well as periodic PING with default 1sec interval), this metric would normally oscillate between 0%, and, say, 3%, with longer term average very close to the target packet error rate of 1% for the reverse link. The problems with the use of RLP based metric to approximate the reverse link physical layer error rates arise if RLP protocol has bugs either at the AT or at the network side (not unusual in early releases, especially with new AT models which often have various RLP problems), and probably more critical if the received packets are lost on the backhaul links between the cell and the FMS. A fairly good indication about the losses on the backhaul link, however, can be obtained by monitoring the Physical Layer Packet Error Rate and Pre-RLP Octet Error Rate metrics for the forward link as long as these two metrics follow each other closely on the forward link, the backhaul losses are not significant in the downlink to the base station, and thus with high probability they are not an issue on the uplink (reverse link) either. In routine everyday optimization work, recommendation is thus to relay on PreRLP OER Reverse metric to monitor the reverse link status, but to have AIPMON deployed in the case that some more detailed troubleshooting is required. The format of collected data from AIPMON is Binary Data Exchange Format (BDEF). This data can then be processed, along with other AT data files, using LDAT. LDAT provides an option to select the test mobile for which the data is going to be post-processed, which is important if more than one test mobile

LUCENT TECHNOLOGIES - PROPRIETARY

Page 31

1xEV Technology

RF Optimization Guidelines

is operational simultaneously. The choice of the appropriate data has to be done based on the mobile identity (UATI) assigned at the session setup, so operators must ensure that the UATI will be collected in the mobile (CAIT) logs, following the procedure outlined in Section 6.2. In addition to AIPMON, the Packrat tool will also be available for more detailed analyses of the BTS operation. While AIPMON is roughly similar to the RF Call Trace, Packrat is closer to the Cell DM, and would not be routinely used during optimization, but more for equipment troubleshooting. In the future, AIPMON will be provided to the customer as a feature, and, therefore, can be shared with the customer. Packrat can generate some data that is considered Lucent proprietary, and should not be run by the customers. AIPMON software client resides on a PC, and comes with automatic install procedure. Details about the installation can be found elsewhere32. In most field situations, this PC is expected to be connected to the internal router within the 1xEV system, and would often be the central post-processing and data analysis workstation as well. PC deployed for running AIPMON would in most cases act as the central data archiving, post processing and data analysis workstation. LDAT tool can be installed on this PC. Recommendation is to have the AIPMON server configured to act as a FTP server and to have the Telnet enabled, which could simplify remote logging at later stages, data archiving and sharing (this server is not the same as the Data Server attached to the PDSN which is used as server for FTP and WINDS). Note that in many instances it might be impractical to use the LDAT computer to run AIPMON. One such example is when the FMS is located tens and tens of miles away from the actual area where the optimization is performed. A separate PC should be provided in such cases.

4.6

Lucent Data Analysis Tool (LDAT3G)

LDAT3G is used to post process the drive test data to aid in performance analysis by providing several metrics. LDAT3G allows the user to create and plot performance metrics from CAIT data as well as AIPMON. It provides the ability to display and print RF performance metrics in geographical, time or statistical plots (histograms). For setting up the LDAT, procedures described in the corresponding M&P document30 should be used. Attention should be also paid to the compatibility between LDAT and CAIT versions, because not all combinations work together. Following metrics have been added to LDAT3G menu for 1xEV performance analysis: 1xEV Overlay Events Origination Success Origination Failure Dropped Connection AN Connection Release AT Connection Release Connection Release (Other) Finger Info Ec/Io Max Finger Ec/Io Aggregate Finger Max Finger SINR

32

Using 1xEV-DO Air Interface Performance Monitoring Tool (RF-E188)

LUCENT TECHNOLOGIES - PROPRIETARY

Page 32

1xEV Technology

RF Optimization Guidelines

Searcher Info Best ASP Ec/Io Ec/Io Specific Pilot Total to Best ASP Ec/Io Ratio Best ASP PN Offset Best Server Coverage of Specific Pilot Number of Pilots above Threshold Forward Packet Statistics Physical Layer Throughput Packet Error Rate Forward Slots Statistics DRC Rate Requested Max DRC Rate Slot Distribution DRC Rate Requested Average Best ASP SINR AIPMON Packet Statistics (Reverse Link) AIPMON Physical Layer Throughput AIPMON Packet Error Rate Power Measurements AT Receive Power AT Transmit Power (Total, Pilot, Open loop, Closed loop adjust) Reverse Rate Indicator Predicted RRI Average Predicted RRI Packet Distribution Reverse Packet Statistics Offered Data Rate Average Offered Physical Layer Throughput Packet Rate Distribution Network Loading Number of Active Users % of Slots utilized Reverse Activity Bit (RAB) Reverse Rate Limit (RRL) RLP Statistics RLP Throughput Forward RLP Throughput Reverse Pre-RLP OER - Forward Pre-RLP OER - Reverse Post-RLP OER Forward Average RLP bytes Requested per NAK Forward Average RLP bytes Requested per NAK Reverse

LUCENT TECHNOLOGIES - PROPRIETARY

Page 33

1xEV Technology

RF Optimization Guidelines

In addition, LDAT3G provides the following metrics/events from WINDS data. Current use of single laptop RF toolkits necessitate the use of WINDS for FTP and ping tests. Hence, some of the LDAT metrics below have become all the more important for analysis: WINDS UDP Application Layer Throughput Downlink WINDS UDP Application Layer Throughput Uplink WINDS UDP Application Layer Error Rate Downlink WINDS UDP Application Layer Error Rate Uplink WINDS UDP Missed Packet Rate Downlink WINDS UDP Missed Packet Rate Uplink WINDS UDP Number Missed Packets Downlink WINDS UDP Number Missed Packets Uplink WINDS Data Transfer Start WINDS Data Transfer End WINDS Data Transfer Timeout WINDS FTP Application Layer Throughput Downlink WINDS FTP Application Layer Throughput Uplink WINDS FTP Application Layer Session Throughput Downlink WINDS FTP Application Layer Session Throughput Uplink WINDS Ping Packet Delay (average) binned and unbinned WINDS Ping Packet Delay min and max Users should exercise caution when reviewing the dropped call metric, because it classifies all abnormal releases (releases without AT receiving the regular Connection Close message) as dropped connections. However, per IS-856 standard Connection Close message is sent as a best effort message only (no repetitions if not acknowledged by the mobile), which means that approximately 1% (target FER) of these messages will be lost over the air between the base station and the mobile. This does not represent any problem during normal drop call tests, because no Connection Close messages are expected to be sent when these are executed with WINDS, nor via FTP scripts (see Section 5.7 for more details), but would give misleading results for any test drives which rely on frequent connection establishments and closures (e.g., drop call statistics should not be considered for the origination test runs with PING script from Section 5.6, where connection is closed every 15 seconds). Initial release of LDAT also had problems with several throughput reports, which were underestimated due to the fact that CAIT occasionally misses to log the corresponding entries. Improvements have been incorporated in the LDAT since the release 3.4 beta, and the results are now expected to be correct within 99% or so. Any eventual discrepancy between the application layer, RLP layer and Physical Layer results which do not follow the expectations as explained in Sections 1.7 and 1.8 within a few percentage points should be reported to the LDAT development team33.

33

It should be also noted that LDAT at present does not provide an option to calculate averages on the defined portions of the data set, so periods with little or no throughput before and after the data transfer will normally be included in the averages. At the beginning of the logging usually a few seconds need to be wasted to ensure that the UATI is captured, following the procedure from Section 6.2, and sometimes the end of the data transmission might not be noticed by the operators and zero entries could be included in the average. When throughput averages are collected for Exit Criteria and similar drives, this is usually not a problem, because these drives are expected to last 1-2 hours, and the error due to this would be small. For shorter runs, operators might want to review the data and exclude from the data set the first few and as many CAIT files as appropriate at the end of the run. In addition, caution must be paid to the averaging method for FTP results (see Section 5.7 for further details).

LUCENT TECHNOLOGIES - PROPRIETARY

Page 34

1xEV Technology

RF Optimization Guidelines

4.7

Friendly Viewer (FV)

Qualcomms Friendly Viewer is a software tool to parse and view CAIT log files. To run this tool: Select File Open From the Dialog box, browse to the folder where CAIT log files are stored and select the desired file, click OK FV will parse the log file and display the contents using its own text browser. FV is most often used to debug suspected Layer 3 problems with equipment, or in-depth analysis of the failure scenarios it is not routinely used during the RF optimization. 4.8 GeoBin

Geobin is a tool used for system exit testing. It bins the collected data, e.g., FER, into geographical bins of a certain size, input by the user. The data points per bin are averaged and then a percentage of bins (as agreed upon in the contract) are used to compare against the exit criteria. Binning is in general not needed during optimization work where contractual agreements do not exist, and even when they do, binning is often not needed in the bulk of the optimization work (e.g. in cluster optimization stage, binned data is normally provided for System Test routes only, unless specified otherwise in the contract). Geobin feature is now available within LDAT3G. For procedures on how to use LDAT3G to create Geobin reports, refer to the RF M&P document RF-E052 LDAT3G M&P Guide. 4.9 Data Server

Data Server is a PC with static IP address, which is connected directly to the PDSN (router next to PDSN). It has to be set up by the installation team, and enabled to act as an FTP server. In most instances it will be used as a server for WINDS application, which generates UDP traffic. Installation of WINDS is covered in Section 5.3. In addition, in some cases the Data Server would have to be configured as an HTTP server, especially during various customer trials (HTTP downloads are normally not used during RF optimization). Besides Windows 2000 FTP Server, HTTP server software has to be installed in such cases (Linux based servers could also be used, but are not mandatory). Further information about setting the servers, especially in Linux case, can be obtained from the Voice and Data Quality Group (RF Core Support Department) in Whippany.

LUCENT TECHNOLOGIES - PROPRIETARY

Page 35

1xEV Technology

RF Optimization Guidelines

5 Test Data Load Generation


1xEV technology is a data-only system, which does not have an equivalent to Markov calls. Other means to load the link to be tested are therefore required. In addition, 1xEV system has several features that can be used to create artificial forward link loading (analogous to some extent to OCNS), i.e. traffic that is introduced to interfere with the data traffic generated for actual measurements. 5.1 Test Application

Test Application (TA) is the closest equivalent to the Markov Call used for optimization purposes in the past. It is similar in the sense that artificial data traffic can be generated using fixed (preset), or variable data rates in either of the links, and then the data packet error rates can be calculated based on the information collected on the other end. In addition, TA has several features that can be used for specific lab tests, especially those required for compliance with the Minimum Performance Standards for Access Terminals and for Network equipment. It can be also used in a loop-back mode. Test Application has been available for a while, but not fully tested. At this point in time, all optimization procedures are developed without the Test Application, but it might be used in some trials for some specific test cases requested by the customer, and might be used in some Exit Criteria testing, depending on the actual contractual agreement with the customer. 5.2 Test Mode

Test Mode was a special mode of operation supported during the technology trials on Qualcomms service node, which is not supported in the commercial system. When this mode was set, network would start generating artificial traffic packets for all terminals that are registered on the network. This was used both as test traffic generator, and in some cases as artificial traffic load in the surrounding sectors2. Test Mode also stamped each MAC layer packet with a sequence number, which permitted very simple evaluation of the throughputs and packet error rates. This mode is mentioned because customers might have seen some of the Test Mode results in the past, either from Lucent, or Qualcomms own testing, and might have questions about using it. 5.3 UDP Transfers

UDP is preferred Application Layer protocol for test load generation in all RF optimization testing. It is a clear favorite because it is the least sensitive to most of the throughput limiting factors discussed in Section 1.8. It is in Lucent best interest to utilize UDP application for testing whenever possible, because the UDP throughput will in general be higher than with any other application. UDP is also more convenient for optimization work, because both forward and reverse throughputs can be measured in the single run (other options require either two test terminals to be run in parallel, or the routes to be driven twice, once with forward and then with reverse link traffic). In spite of all these advantages, at this time the UDP-based load generation cannot be generally recommended for optimization work, although the UDP packet generator tool itself (WINDS) have been successfully tested in many environments controlled by Lucent. First, Chester terminals seem to overcompensate to the UDP traffic flow in MIP mode by sending long spells of null DRC cover. Since most new major networks are adopting MIP mode for smooth transition of end user applications at technology and possibly inter-vendor boundaries, UDP traffic cannot be used for RF optimization at this time. The MSM6500 chipset based ATs show marked improvement, but the use of such ATs has not been finalized for various reasons.

LUCENT TECHNOLOGIES - PROPRIETARY

Page 36

1xEV Technology

RF Optimization Guidelines

Second, it appears in some network implementations, operators are disabling, or severely limiting throughput that UDP-based applications are allowed to have. This is done in data backbone network (beyond PDSN) and is outside Lucents control. Third, even when UDP traffic flow is properly handled both in the backhaul and the AT, in some network deployments the cell routers are set up in such a way that severe packet drops are experienced between FMS and cell. This was documented in cases when cells are deployed in one T1 configuration, but can occur in situations with more than one T1 if there are several users in the cell (not just in the sector where the test AT is used). Lucent so far provided recommendations for router setup to avoid these drops for some router types (which involve providing enough buffer space on the router for storing the incoming data and enabling proper set of priority rules for different types of data streams), but these recommendations were not followed by the operators in some major deployments so far. Until various backhaul configurations are properly groomed, such technical issues would likely limit the scope of UDP-based test load generators. In parallel to this, as a separate effort Lucents UDP test tool WINDS is being upgraded to possibly alleviate some of these problems, by providing a sort of feedback control which would prevent queue overflows, but in a manner which does not have some of the drawbacks of the full TCP-based flow control. This modification is presently under development, and if tests show satisfactory results the recommendations will be revised accordingly. The capability has been dubbed WINDS Flow Control. In addition to these networking and AT problems, some operators were quite reluctant so far to accept any testing, especially as related to the exit criteria, which relayed on UDP traffic, arguing that TCP based application such as FTP are more illustrative for the normal subscriber usage of the 1xEV network. In most technical trials so far, however, measurements of UDP throughputs were requested (on top of FTP throughput results). If UDP traffic load is to be used, preferred test tool is WINDS, which is a Lucent developed application running on the Data Server connected to the PDSN. Client is running on the test laptop used for measurements. One server can support a number of clients. At present, tests with up to 8 clients were successfully executed, with the total generated throughput exceeding 4Mbps34. Note that the achievable rates might be constrained by the characteristics of the Data Server, and the available bandwidth between Data Server, PDSN and FMS, which has to be checked with the installation team Once the WINDS application is set up and launched on the Data Server side, both uplink and downlink transfers can be initiated from the mobile side, without the operator at the server end. Uplink and downlink data streams can be defined independently, both in terms of the throughput and the packet sizes (again, offered throughput is presently constant, future revisions might incorporate an adaptive algorithm, which would ensure that the data queues at the cells are never empty, without overflows on the other network components). In case of a call drop, WINDS recovers gracefully, even if the IP address of the mobile terminal gets reassigned. WINDS also provides for fairly extensive on-line performance monitoring, and comprehensive logging, which can be correlated with the GPS timestamps and latitude/longitude information for mapping and other post-processing activities, either directly (WINDS can log the actual GPS data too), or through LDAT3G.

34

Exact limits are currently under investigation.

LUCENT TECHNOLOGIES - PROPRIETARY

Page 37

1xEV Technology

RF Optimization Guidelines

WINDS comes packaged with an installer, and has to be installed on all laptops that will be used with the access terminals, and on the Data Server. Complete setup procedure is described in the M&P documentation30. Additional details may be also found in the WINDS user guide35. Once the set-up is completed, the actual data transfers can be initiated via a user-friendly GUI from the mobile side for downlink (Data Request) and uplink (Data Send). For each transfer, several numeric parameters need to be configured. Recommended set of values that should be populated in most tests is given in Table 5.
Parameter Target Duration Rate Payload Feedback Init Req Retry Interval Loss of Data Timeout Loss Request Retry Intvl Downlink (Request) IP address of the Server Length of the test in HH:MM:SS 2,000 kbps 500 bytes 5 1 2 1 Uplink (Send) IP address of the Server Length of the test in HH:MM:SS 160 kbps 500 bytes 0 N/A N/A N/A Table 5: Recommended WINDS Set-Up

Throughputs measured via a UDP application are largely independent of the actual packet size used for measurements (longer packets have slightly larger probability of erroneous reception, but the differences for normal sizes are in the 0.1% range and have no noticeable impact upon the measured throughputs). As indicated before, WINDS was tested so far in the lab and in the field environment, and proved to be reliable for optimization work as long as the data backbone network was set up to meet the requirements or the system was configured in SIP mode. One known problem with WINDS so far is associated with adverse impact of other applications that might be running in parallel either on the server or on the client side (all such process should be turned off, WINDS should be the only process running on the Data Server, and on the mobile side operators should ensure the same prior to the run; in particular, the throughput measuring software such as VitalAgent was found to interact adversely with WINDS). 5.4 FTP Transfers

In general, FTP sessions are presently recommended for all optimization work. FTP is a file transfer protocol, well recognized as a good way to generate consistent upload/download traffic. FTP is often simpler to use in the sense that no physical or remote presence is ever needed from the network side, neither for uploads nor downloads (provided that the Data Server off PDSN is set up as a FTP server). However, given that FTP is based on TCP, it tends to show lower throughput results in the case of noisy RF link because of the slow start and other congestion avoidance mechanisms that are meaningful for wired network, but are not necessarily optimized for RF links subject to fading and other errors. If FTP

35

http://rfcoresupport.wh.lucent.com/RFCoreSupportWebPage/toolspage.htm

LUCENT TECHNOLOGIES - PROPRIETARY

Page 38

1xEV Technology

RF Optimization Guidelines

transfers are to be used, optimization work can normally be done with the downloads of large files only, as the TCP/IP acknowledgments in general provide enough data to calculate all the performance metrics of the reverse link other than the throughput, and reverse link throughput in 1xEV is normally of secondary importance (given that the forward link throughput is much larger). If the customers are interested in the reverse link throughput results, and UDP is not applicable for whatever reason, two terminals should be used in parallel, one to do forward FTP (download) and the other to do the reverse FTP (upload). Present experience shows that both throughputs are adversely impacted if both processes are run from a single terminal36. Normal optimization work does not require the upload testing, except if agreed otherwise with the customer through the contract, or statement of work for the optimization service. Essential for any FTP-based testing is to ensure that the TCP and PPP parameters are set correctly at the laptop and at the PDSN, as per Section 4.4. Except for the appropriate permissions at the FTP server, another prerequisite for FTP testing is to have large enough data files available at the network side for downloads, and at the laptop for uploads. On the server side, an uncompressible file of around 10Mbytes should be prepared (LARGE_FILE_AN, can be made for instance by appending several logging output files). On the laptop, a file of around 1Mbytes should be prepared in the similar manner (LARGE_FILE_AT). While 10MB and 1MB files cover most drive testing needs during optimization, in practice it is often convenient to prepare a series of files on both sides with different sizes, say 1MB, 3MB, and 10MB on the server side (AN), and 100kB, 300kB, and 1MB on the terminal side (AT). As a rule of thumb, file size should be chosen in such a manner as to ensure that the downloads last for at least one minute, but not more than 5. Several examples of the uncompressible files to be used in FTP tests will be delivered with the Toolkit (they are to large for normal web download, and other sizes as needed can be obtained by concatenating the smaller sizes (DOS copy command copy A + B C to combine files A and B into C), or by editing the existing binary files (deleting segments) until the right size is achieved. In case of an emergency requiring improvisation, required files can be always quickly created by zipping any convenient size binary file (CAIT log files would do) couple of times. One example where larger file will be normally needed are cabled (close loop) tests, and best sector throughput tests during Functional (Sector) Tests (see Sect. 8.2 and Appendix, Sect.10), as the average throughput in such conditions is at least twice the throughput that would be obtained during mobile tests. Situation when the smaller files would be needed is most often encountered in multi-user tests, when several terminals are sharing the bandwidth. As a general guidance, the file sizes should be scaled down proportional to the number of users, so that download times between 1 and 3 minutes are achieved. Note that attempt by several terminals to access and download the same file on the Data Server often results in a file sharing violation report. A simple practice for multi-user test is to generate a series of Large File AN files with suffixes corresponding to the numbers assigned to each test laptop, and invoke different files from each one, based on the laptop number. There are several tools available to perform FTP. Prior to the availability of single laptop toolkit, the recommendation was to use DOS FTP. However, the single laptop configuration necessitates the use of WINDS FTP feature. WINDS manipulates the internal routing tables in the laptop such that it allows the two data streams (one on each of the ATs connected to the single laptop) to flow through the respective ATs. The DOS FTP does not offer such routing capability (one can only specify the target address and port, but not the source IP address/port that should locally receive/transmit data). Note that in the single

36

It has something to do with multiplexing of the two different the data streams, but the process is still not well enough understood.

LUCENT TECHNOLOGIES - PROPRIETARY

Page 39

1xEV Technology

RF Optimization Guidelines

laptop configuration, 2 different IP addresses are assigned to respective hardware interfaces in the laptop one for each AT. The procedure to invoke DOS FTP and WINDS FTP is provided in the sections below. The one for DOS FTP is retained here just for reference in case customer demands its use for optimization. In such a case, testing should be conducted with only one AT connected to the laptop. This will also mean iterative testing say first set of drives with DOS FTP Get, second with DOS FTP Put to collect download and upload data respectively. 5.4.1 DOS FTP Both uplink and downlink FTP transfers can be initiated via a user-friendly GUI interface, or from a DOS window, by entering
ftp IP_address_of_Data_Server user_name (when prompted, obtained from Data administrator) password (when prompted, obtained from Data administrator) bi (binary transfer) ha (print hash marks to monitor progress) (if applicable) cd FTP_FILE_DIRECTORY get LARGE FILE AN put LARGE FILE AT Server Server

or

Present experience suggests that it is more convenient to create batch files for uploads and downloads, with shortcuts put on the desktop. For the download, the text file FTP_GET.BAT should contain:
FTP_GET.BAT ftp -n -s:c:\Path for COMMD GET.DAT\commd_get.dat IP_address_of_Data_Server

where COMMD_GET.DAT is a text file in the directory C:\Path for COMMF_GET.DAT (full path to the directory containing the COMMD_GET.DAT has to be specified), with the following contents:
COMMD_GET.DAT user user_name password (if applicable) bi (binary transfer) ha (print hash marks to monitor progress) cd FTP_FILE_DIRECTORY (if applicable) get LARGE_FILE_AN get LARGE_FILE_AN get LARGE_FILE_AN (last line repeated enough times for a run, >100 entries recommended)

Underlined entries have to be adjusted as appropriate for the client and server in question. Several shortcuts for FTP-ing of the different files sizes, if the terminal is to be used for various tests in different RF conditions. Similarly, for FTP uploads the following files should be prepared:
FTP_PUT.BAT ftp -n -s:c:\Path for COMMD PUT.DAT\commd_put.dat IP_address_of_FTP_Server

where COMMD_PUT.DAT is a text file in the directory C:\Path for COMMD_PUT.DAT (full path to the directory containing the COMMD_PUT.DAT has to be specified), with the following contents:
COMMD_PUT.DAT user

LUCENT TECHNOLOGIES - PROPRIETARY

Page 40

1xEV Technology

RF Optimization Guidelines

user_name password (if applicable) bi (binary transfer) ha (print hash marks to monitor progress) cd FTP_FILE_DIRECTORY (if applicable) put LARGE_FILE_AT put LARGE_FILE_AT put LARGE_FILE_AT (last line repeated enough times for a run, >100 entries recommended)

In normal conditions, both scripts would create a sequence of downloads or uploads, which would be terminated by user intervention (closing the DOS window that the batch file will open). Process can also end abnormally, if the FTP application times out. This can happen if the terminal is driven through areas with no coverage for an extended period of time (FTP would normally reconnect after a short connection drop, which users often cannot detect). FTP time-out timer can be quite variable (from a few seconds to several minutes), and would be followed by a message Connection Closed by Remote Host message on the screen. Subsequent FTP get or put commands would generate a rapid barrage of Not Connected messages. Several system bugs could also terminate the FTP script, with similar symptoms, but at this time these are not likely to be encountered in the field, except may be when new terminal models are to be used (again, most frequent are the RLP bugs, which would cause a stop of TCP/IP data flow, and subsequent timeout). Same thing would happen if the USB cable gets disconnected, or if the USB driver freezes (frequent bug in the early Chester versions, could be expected with other terminals). If the dial-up connection is lost (accidental disconnect by the operator, or due to any Chester or laptop software issue), but the message on the screen will read Connection Reset by Peer). On-line monitoring of the progress of hash marks (and intermediate FTP results) in the DOS window brought up by the batch file is needed to avoid extended driving with no data flow. At the end of each FTP download or upload, FTP process prints on the screen the size of the file transferred (in bytes), the elapsed time, and the calculated throughput (in kilobytes per second). These results are normally accurate and can be used for throughput calculations and verification on the forward link. On the reverse, some laptops running Windows 2000 occasionally seem to over-estimate the throughput by a few percentage points (for instance, during close loop or functional tests in best RF, FTP sometimes reports throughput of e.g. 148kbps, while the maximum as per Section 1.9 is around 145kbps). Problem seems to be due to Windows 2000 underestimating the elapsed time by 2-3 seconds, possibly due to larger queuing delays on the reverse link transfers. For all practical purposes, using large enough files so that transfers last for a few minutes can alleviate this problem up to the point where the difference is negligible. 5.4.2 WINDS FTP WINDS FTP is menu driven GUI-based capability offered by the WINDS tool. It is easy to configure and run. It also provides logging capability to collect application layer statistics, which can be parsed directly by LDAT3G. It invokes the TCP protocol layer stack of the WINDOWS operating system, in a similar manner as DOS FTP. In addition to providing an application layer throughput value at the end of each file transfer, it allows recording periodic values of throughput (say every 1 sec). The latter is very useful in plotting application layer throughput on a map using LDAT3G (Note: WINDS also has the ability to log GPS data); such a granularity is not available with the DOS FTP. The throughput performance obtained with DOS FTP and WINDS FTP are comparable37. Prior to the RF optimization

37

There is one exception. On the reverse link, DOS FTP does not include the item taken to receive the last TCP message (FIN ACK) from the target side. This often inflates the reverse link throughput more pronounced for

LUCENT TECHNOLOGIES - PROPRIETARY

Page 41

1xEV Technology

RF Optimization Guidelines

testing, a trial comparison run may be performed with single AT first with DOS FTP and then with WINDS FTP to demonstrate similar performance and erase any concerns, if customer objects to the use of WINDS FTP. Prior to invoking WINDS FTP, it is important to configure basic WINDS attributes properly. This requires defining the aliases for the available network adaptors for the two ATs (see Figure 5), specifying the logging options (see Figure 6) and configuring the GPS option (see Figure 7).

Figure 5: Defining Adaptor for each AT name them, for example, AT1 and AT2

Figure 6: Logging options Must check Enable Logging, Periodic and Event selections.

short file transfers. WINDS FTP correctly waits for the entire transfer to be over, thereby providing a more accurate view.

LUCENT TECHNOLOGIES - PROPRIETARY

Page 42

1xEV Technology

RF Optimization Guidelines

Figure 7: Enabling GPS logging. Must select Use GPS Server. GPS server feeds data both to CAIT and WINDS applications

In terms of usage, WINDS FTP can be invoked from Transfer -> FTP menu. A snapshot of the screen window is shown in Figure 8 below.

Figure 8: WINDS FTP control menu

The various screen inputs are: Adapter: One of the two adaptors created earlier. Server: IP address of the data server (target) Port: Port 21 is the FTP port. Timeout: This is the amount of time WINDS FTP waits for a particular Task (defined below) to start. 20 sec is a reasonable value. For example, if there is no response from the remote server for a GET command within 20 seconds, WINDS FTP aborts it and goes on to the next Task.

LUCENT TECHNOLOGIES - PROPRIETARY

Page 43

1xEV Technology

RF Optimization Guidelines

Duration: 2 hours (or long enough to cover the entire drive route) System information: Username, Password, and Remote Dir are all customer specific. Local Dir: The location on the client laptop where the data is to be downloaded to (for GET) or uploaded from (for PUT) Action: Position the cursor on the open screen below Action and right click. From the pop up menu, create a GET task followed by the REDO, PAUSE, CONNECT and RESTART tasks. Once the GET task is created, double click on the (invisible) cell on the GET row under the File column. A text box appears enter the remote file name to be downloaded (LARGE_FILE_AN). Similarly, edit the Timer field and set it to 0. Any non-zero value will abort each file transfer after that specified interval this is not desirable. The REDO task repeats the GET action, that is, the same file is transferred over and over again. The test can be prematurely aborted by hitting the Stop button. The PAUSE (recommend 3 sec wait), CONNECT and RESTART tasks allow the GET to restart if FTP were to stop or time out. Similar to GET, PUT task can be entered for reverse link transfer; in this case, the local file to be uploaded (LARGE_FILE_AT) needs to be specified (not the remote file).

WINDS FTP generates a single log file over all FTP iterations and stores it at the specified logging directory (Figure 6). The data is logged in ASCII format and the logfile is named with .ftp extension. The file can be fed to LDAT3G for analysis. The average throughput obtained from LDAT3Gs Histogram function for the WINDS FTP Application Layer Throughput Downlink (or Uplink) metric is of most interest. 5.5 Ping

Ping is used to verify basic end-to-end connectivity between the client and the server as well as to measure the average latency and the amount of packet drops encountered. An ICMP echo request message is sent to the server and reverted back to the client. Ping can be invoked from the DOS command, but with the single laptop configuration and assuming both the ATs are connected, WINDS Ping is preferred. 5.5.1 DOS Ping Simple, yet very useful command to test data connections is to invoke
ping IP_address_of_Data_Server -t

through command line, from a batch file with a shortcut, or any other manner convenient. Ping with t option would keep on sending the ICMP echo request message continuously, which can test both the connectivity, packet error rate and the round-trip-time to the pinged server. Instead of -t option, a -n option with a number can be used to generate a required number of pings and stop. Default pings are 32 bytes long (can be changed with the l option to specify number of bytes to be sent, larger pings are often useful when the backbone network connectivity is tested). ICMP requests are sent once per second (no option to change the period in Windows 2000, but can be changed in most Unix implementations). Another useful option is -w, which specifies the wait time for ICMP echo to return in milliseconds. Note that in most versions of Windows the options can be specified before or after, but in some versions they must be specified only after the IP address. To pause ping with t option in effect, one can do Cntrl+Break, in which case ping shows statistics for number of packets sent and received, percentage of packets in error, and average, min and max roundtrip-time. Cntl+C shows the same statistics, but after stopping the pinging process altogether.

LUCENT TECHNOLOGIES - PROPRIETARY

Page 44

1xEV Technology

RF Optimization Guidelines

Special script PINGAPP.BAT to run the ping command, write the output into the file and on the screen, as well as a post-processing script PINGAPP_OUT.EXE which calculates the average, minimum and maximum response time, as well as the failure rate. With default ping size and 1-second repetition period, the equivalent throughput is rather low (~500 bps), so that the process can be ran in parallel to any UDP or TCP/IP application, with negligible throughput impact38. It was useful in early testing to show quickly if there are any problems with RF links or with the equipment (various bugs could cause FTP to halt given that FTP time-out could take long time to occur, pings were useful to detect what was going on). As the equipment (esp. terminals) is more mature now, it is expected that this will not be needed. 5.5.2 WINDS Ping To mimic DOS Ping, WINDS ping can be configured from the Transfer -> Ping pop up box as shown in Figure 9. Before running a ping test, WINDS should be configured as specified in section 5.4.2

Figure 9: Verifying basic data connectivity using WINDS Ping

The various inputs are: Adapter: Select the one of the adapters (AT1) Target: IP address of the data server Duration: 4 seconds (ping will be sent continuously until the Duration expires) Interval: 1000 milliseconds Size: 32 bytes WINDS Ping will continuously send a ping every Interval msec regardless of whether/when the response was received. Unlike DOS ping, it is not fixed at 1 sec. If a response comes after this specified value, it is still considered a valid response and the latency measured. Similar to WINDS FTP, WINDS Ping generates a logfile (ASCII file with .ping extension) which can be analyzed through LDAT3G. The main

38

PING results themselves in this case would show rather large round trip times, because the PING probes have to compete with other application to be scheduled for transmissions over the air, which would cause larger delays, especially because of the reverse link scheduling inside the terminals.

LUCENT TECHNOLOGIES - PROPRIETARY

Page 45

1xEV Technology

RF Optimization Guidelines

metrics of interest are Avg/Min/Max Latency and packet loss rate; these can also be read off the WINDS Ping screen real-time.

5.6

Origination Testing

Originations tests are based on the use of PING script. There are two ways to run it. Initial practice was to use it via scripts configured to run DOS ping. With the advent of single laptop toolkit, WINDS Ping is necessary. 5.6.1 1) Go DOS Ping scripts to site http://rfcoresupport.wh.lucent.com/RFCoreSupportWebPage/ toolspage.htm and download the files gdate.exe, tee.exe and sleep.exe that are required

for the scripts, put them into c:\winnt\system32 directory on the laptop to be used in the testing. 2) Create a text ORIG.BAT file with the following content:
ORIG.BAT @echo off set i=1 :REPEAT gdate >> c:\Path_for_results\PING_RES.TXT echo %i% ping IP AddressofDataServer n 1 w 10000 >>c:\Path_for_results\ PING_RES.TXT ping IP address of Data Server n 1 sleep 15s set/A i=i+1 goto REPEAT

3) Synchronize the computer time with CAIT time as described in Section 5.3. This script will create one origination and record if the traffic channel was established within 10 seconds, and record the time and ping result into the PING_RES.TXT file. It will then execute one additional ping while the traffic channel is up, showing the results on the screen, for on-line monitoring purposes (normally the output will show the reply showing that the packet was sent and received, with the approximate round trip time calculated; if the origination fails, Request timed out message will be displayed)39. After that script would wait for 15 seconds for the dormancy timer to expire (ensuring that the new ping will have to indeed establish the traffic channel), and repeat the whole procedure. Script would also show the progress in terms of the origination number on the screen. The ORIG.BAT file will normally add a time-stamp and ping output into the file PING_RES.TXT. If the script needs to be run repeatedly, a shortcut can be created (note that the repeated runs would append the results to the original file, i.e. no data will be lost). Depending on the organization of the data archives, other solutions could be used instead. For instance, if the results need to be organized per day or per run, or in any other way, the ORIG.BAT can be edited to include different path names for each individual run. Alternatively, it can be edited to exclude path, but then place copies of the ORIG.BAT into each directory where results are to be archived (the script could

39

In early testing the mobiles occasionally went into mode when originations repeatedly failed, and the terminal had to be reset. Recent experience shows that such problems are largely resolved, but the option to monitor the results on-line is still useful.

LUCENT TECHNOLOGIES - PROPRIETARY

Page 46

1xEV Technology

RF Optimization Guidelines

then be started by double clicking on the ORIG.BAT icon in the directory where the results are to reside), etc. The origination success rates can be calculated based on the results in the PING_RES.TXT. A script 40 ping_orig.exe can be used for this calculation . If the internal clock on the laptop that was running the script is synchronized with the CAIT time, time stamps of the successful attempts and failures (ping time outs) can be extracted and correlated with lat/long data from CAIT to produce the maps, but the process is somewhat tedious. 5.6.2 WINDS Ping The same procedure specified for checking data connectivity using WINDS Ping in section 5.5.2 can be used for origination testing as well. The only difference is that the Interval parameter should be set to 15000 milliseconds to allow the connection to go dormant (assuming the Dormancy Timer is set to 10 sec in the EMS). The subsequent ping causes an origination or access attempt. This process of send a ping and wait for 15 sec is conveniently iterated using WINDS without requiring any scripts to collect or process the data. As specified in section 5.5.2, the .ping logfile can be collected. LDAT3G currently does not have any statistics on WINDS Ping timeouts. Note, however, that WINDS records the total number of missed and received packets that can be used to compute the ping packet loss or timeout rate. This information is stored in the last record of the .ping file (record marked with F for Final). No other post-processing needs to be applied unlike the case of DOS ping. IMPORTANT NOTE: The access success statistics calculation and mapping of the attempts is also available in LDAT3G41. It should be noted that LDAT does not produce identical results as PING timeouts obtained either via DOS ping scripts or WINDS Ping. One reason for this is that laptops sometimes do not go dormant in-between two pings, resulting in less access attempts reported in LDAT than via PING42. Other reason for discrepancy is that in the case of some failures the terminal would autonomously try to re-originate, and PING might go through with any reasonable waiting period option w. Such instances would cause a failure to be pegged in LDAT, but not in PING. Situation is quite similar to the issues with silent reorigination in voice world, and might be resolved at a later date, when either contractual requirements specify how to handle such cases, or we gain more experience as to what numbers are closer to the enduser experience. Unless otherwise specified in the contract, present recommendation is to report access success and failure rates based on the PING script or WINDS .ping file, and use LDAT3G metrics for mapping and crosschecking. It is worth remembering that some hybrid mode terminals automatically retry the origination on underlay 3G-1X system if the attempt on 1xEV fails. Use of terminals in hybrid mode is not recommended, but if

40

Available at http://rfcoresupport.wh.lucent.com/RFCoreSupportWebPage/toolspage.htm. Script should be used as follows: ping_orig PING_RES.TXT > PING_SUMMARY.TXT, where PING_SUMMARY. TXT will be the output file containing the origination test statistics. LDAT access success and failure metrics have been recently added. Tests in the filed so far were successful, but due to the limited amount of test time some anomalies may still exist. Any perceived problems beyond what is described in the text should be reported to the LDAT development team. Present understanding is that mobiles do not go dormant because of the spurious transmissions (see Sect.4.4), but it has not been verified yet. In any case, mobiles appear not to go dormant once in a few hundred attempts, which is negligible for field-testing.

41

42

LUCENT TECHNOLOGIES - PROPRIETARY

Page 47

1xEV Technology

RF Optimization Guidelines

they must be used then these events have to be filtered out manually from the PING results, based on the analysis of CAIT logs. 5.7 Drop connection and Throughput Testing

Drop connections will in general be measured in parallel with the origination tests, with two terminals running in parallel, each with the CAIT. As with prior sections, the information for drop connection test methodology is split into DOS FTP and WINDS FTP sections below. 5.7.1 DOS FTP If WINDS is used, then the drops from the application layer perspective will be available from the corresponding WINDS logs, but in most test scenarios periodic FTP downloads will be used instead (uploads are not needed for drop call rate evaluation). Periodic FTP downloads can be created using a batch file similar to what is used in Section 5.4.1:
FTP_GET.BAT ftp -n -s: c:\Path for COMMD_GET.DAT\COMMD_GET.DAT IP_address_of_Data_ Server |tee c:\Path for Results\FTPGETOUT.TXT

where the FTPGETOUT.TXT would store the FTP results, Path for Results can be adjusted following the same principles as for the Origination script, and the COMMD_GET.DAT is similar to the command file from Section 5.4, except that the time stamps obtained via gdate.exe are added, for easier correlation of FTP results with CAIT data
COMMD_COMMD.DAT user user_name password (if applicable) bi (binary transfer) ha (print hash marks to monitor progress) cd FTP_FILE_DIRECTORY (if applicable) !gdate get LARGE_FILE_AN !gdate get LARGE_FILE_AN !gdate get LARGE_FILE_AN (last 2 lines repeated enough times for a run, >100 entries recommended)

As opposed to the earlier versions of the scripts, this script does give the results on the screen (in a new DOS screen that it opens), which should be used for progress monitoring. It should be further noted that for some reason Windows 2000 displays the Connection Closed by Remote Host and Connection Reset by Peer messages on the screen in spite of the redirection, so major crashes of the FTP script should be observable from the DOS window in which the batch file is running. 5.7.2 WINDS FTP Refer to for information on running WINDS FTP. Same method is used for data collection regardless of the purpose of the test throughput or drop connection. IMPORTANT NOTES: In normal operation, either the DOS FTP script or WINDS FTP should never cause a connection to close, i.e. the series of FTP would continue one after another. Many connection closes, however, will not be detectable from the FTPGETOUT.TXT or WINDS FTP log (.FTP), as the connections would often reconnect after the drop. Instead, Connection Close messages should be enumerated from CAIT logs.
LUCENT TECHNOLOGIES - PROPRIETARY Page 48

1xEV Technology

RF Optimization Guidelines

LDAT3G provides support for this when either Winds or FTP script are ran, and also provides option for drops to be mapped. It is important to remember that LDAT3G maps all unexpected connection closes as failures, including the case when connection in effect terminated regularly, but mobile failed to detect the Connection Close message. As explained in Sect. 4.6, this message is sent once as a best effort message, and fails to reach mobiles about 1% of the time. This would inflate the drop call rates if the LDAT metrics are calculated for files with a lot of normal connection closes (such as PING tests). LDAT metrics should be used only for continuous transmissions, such as via WINDS FTP or DOS FTPs. It is also important to ensure that no spurious Connection Close messages are generated while doing the tests if it looks as if the application stopped or crashed, and operators want to execute a PING or contact any server with any other application, CAIT logging should be stopped first. In terms of reporting of the drop call rates from the field, present practice is to normalize the number of drops to the number of connections equivalent to the average voice call length, for easier comparisons43. LDAT presently provides the drop call rate normalized to 60 seconds, and results for any other average connection duration (90-110sec values are often required) can be calculated via a proportion: number of drops during test average_connection_length [sec] drop_rate = test_duration [minutes] 60 In parallel to the drop rate test, WINDS FTP and DOS FTP scripts are normally used for average throughput calculations. If the FTP script is used for throughput calculations, straight average of the individual throughput results always gives too optimistic results. To understand this, consider a hypothetical run where FTP throughput was 1Mbps in the first half of the run, and then dropped to 500kbps in the second half, as depicted in Figure 10.
BQPH@ G E C A G E A S BQCDTU TR ` W aY XV G E C A S HFDTU TR
Page 49

Figure 10: Averaging of FTP throughput results

The problem with FTP outputs is that we will have twice as many results recorded in the first half of the run as in the second, so the straight averaging of the throughput results will give (41+20.5)/6= 833kbps, instead of the correct result of 750kbps. To resolve this, the averaging of the FTP results has to be done based on the weighted averages (which corresponds to the total number of bits transmitted divided by the total elapsed time during the FTP script run). A script ftpstat.exe that can post-process the

43

Other metrics are also possible, such as number of drops per hour of connection. Note that drop rate cannot be normalized to the number of connection attempts in tests with one long connection, it will ultimately drop with a probability of 1 if the run is long enough.

LUCENT TECHNOLOGIES - PROPRIETARY

G QQ FQTBT FxvwvtFs G y E x y t u

HFDB@ G E C A

G E C A @ BQPHIHEFDB@ G C A iippiipp fq fq fq ir ghghghgh efefefef bcd

1xEV Technology

RF Optimization Guidelines

text file FTPGETOUT.TXT obtained as the output of the FTP script and calculate the correct averages is available44. It also gives the straight average for comparison. In normal mobile runs straight average was found to give about 10% larger results than what is realistic, and in runs with great variability of rates (stop & go traffic), the difference can be even larger. If WINDS FTP is used, average WINDS FTP Application Layer throughput can directly be obtained from LDAT3G histogram output. While it is not the ratio of total bytes over total time, it comes close it is the average of periodically binned throughputs (say 2 sec samples). The other output is average WINDS FTP Application Layer Session throughput this is a straight average over individual throughputs and should not be used. If outputs from several WINDS or FTP individual runs have to be combined for whatever reason (long cluster testing, or if applications stopped unexpectedly), the average throughput has to be calculated as a weighted average, i.e. the individual results obtained as described above have to be multiplied by respective run times in seconds summed, and then this sum has to be divided by the sum of the elapsed times expressed in seconds once again. Finally, LDAT3G directly supports mapping of application layer throughput results if WINDS is being used, but does not provide such option for FTP. Individual FTP throughput results can be plotted based on the time stamps and GPS files through any mapping application (e.g. Mapinfo), but these outputs are fairly sparse (typically one is generated every minute of two) and do not look great on maps. At this time, recommendation is to map the average RLP throughput through LDAT3G instead esp. if DOS scripts are used, which will end up being very close to the application layer throughput results (larger by about 3% for application layer overheads). Physical layer throughputs can be also plotted, but these tend to be further inflated, as explained in Sections 1.7 and 1.8. 5.8 Forward Link Loading

Forward link loading for 1xEV-DO is simulated with Idle_Channel_Gain or Forward Link User Simulator (FLUS) feature, instead of Orthogonal Channel Noise Simulator (OCNS). The former is presently a preferred option, and it is expected that in most cases where contracts call for artificial loading (routine optimization work does not need loading) it will be set to values between 3dB and 0dB. Although Idle_Channel_Gain can perfectly model the interference on the forward link coming from other users in the surrounding sectors, it does not create competition for the airlink resources in the sector where the mobile is presently active. To achieve this, FLUS would need to be invoked, but the process to demonstrate to the customer that the offered FLUS load make sense in terms of adequately representing the load will be very tedious. It is expected that FLUS might be run in some trials on a very limited basis, and special test plans would be prepared in such situations. Either way, the instructions for setting up any desired level of loading are described in the corresponding M&P document30, and should be followed if the contract specifies any artificial forward link loading. Somewhat limited amount of testing has been executed in the field so far with the Idle_Channel_Gain loading, and results with setting as high as 0dB show quite small throughput loss, less than 10%. This seems well aligned with the expectations based on the discussion from Section 1.6, and further confirms that optimization work can be done without any additional forward link loading.

44

Available at http://rfcoresupport.wh.lucent.com/RFCoreSupportWebPage/toolspage.htm. Script should be used as follows: ftpstats FTP_RES.TXT > FTP_SUMMARY.TXT, where FTP_SUMMARY. TXT will be the output file containing the average throughput statistics

LUCENT TECHNOLOGIES - PROPRIETARY

Page 50

1xEV Technology

RF Optimization Guidelines

Some field tests were also executed with FLUS loading, and showed reasonable results. However, testing with any FLUS load is beyond the scope of the normal optimization work, and is limited to the technical trial deployments. Use of FLUS in any routine optimization would have to be covered by a specially developed statement of work. System Engineering and RF Core Support groups must be involved in any discussions or negotiations with the customers as related to the use of FLUS in the field. 5.9 Reverse Loading

Unless specified otherwise in customer contract, use 5.5 dB attenuation to simulate reverse link loading. This value corresponds to 72% loading. The attenuator settings for the toolkit are then calculated with this 5.5 dB penetration value, as in 3G case45. 5.10 Test Carrier Feature When optimizing a network or performing exit criteria drive runs, it is important to execute the testing under controlled conditions. Only test users should be allowed access. If some parts of the 1xEV network have already started offering commercial service and have 1xEV subscribers, it is possible some of these subscribers try to access 1xEV in the area which has not gone commercial yet. This happens readily given most commercially sold 1xEV terminals are configured to operate in hybrid mode. By design, a hybrid mode AT after acquiring 3G1x system, attempts the find and idle on the 1xEV system. So, even if a subscriber wishes to use 3G1x Data in the pre-commercial 1xEV area, as long as the terminal finds 1xEV signal, it will end up requesting connection on the 1xEV network. There is no way to selectively prevent non-test users from idling on a 1xEV system. There is a redirect capability available in 1xEV to force AT in idle as well as traffic mode to the underlying 3G1x system; however, it does not discriminate between ATs. Hence, the need for Test Carrier feature. It was introduced in R23. The Test Carrier capability restricts service to a certain class of mobiles. The key word is access. Any idling hybrid mode users can still camp on the 1xEV network. But only the test mobiles get to transmit their connection requests to the 1xEV network. All other fail the so-called Access Persistence tests and are not allowed access to the 1x EV network. If ATs are configured to operate in hybrid mode, by design they will then attempt an access on the underlying 3G1x system. To a common user, this may appear misleading the AT shows 1xEVDO in idle mode on the terminal display, but gets assigned traffic on 3G1x. There is no way to prevent this. This is in any event a temporary phase until the test area is turned over for commercial service. In 1xEV, there are up to four mobile classes. By default, all ATs are programmed with the class of ' . 0' The test mobiles can be assigned any other class (1-3). The programming can be done via Qualcomm CDMA Air Interface Tester (CAIT) or via appropriate menu of the configuration application provided with the 1xEVDO terminal. The Access Persistence tests are probabilistic computations performed by AT depending on the value of Access Persistence field in the Access Parameters message AN broadcasts periodically. There is a field for each of the four classes. When the Test Carrier is off, all four fields are set to 0. This means any AT will pass the probability tests and will be allowed to access the 1xEVDO system. When the Test Carrier

45

guidelines/guidelines.html

1xEV

RF

Engineering

Gudielines,

http://nwswww.wh.lucent.com/~seamps/files/rfelib/

LUCENT TECHNOLOGIES - PROPRIETARY

Page 51

1xEV Technology

RF Optimization Guidelines

is enabled, the field is set to 0x3F for class 0, while the rest set to 0. This causes only the Test AT to fail the probability tests and hence denied access. Note that the Test Carrier feature only controls the access, not active mode handoffs. Any non-test mode AT will be allowed active mode handoff to a test carrier enabled sector. The test carrier feature is controlled via the translation parameter Test Carrier in the EMS on a per Service Node or per sector basis. The default value of this parameter is No. It is recommended to set it to Yes any time a cell is expected to be over the air prior to commercial cut-over.

LUCENT TECHNOLOGIES - PROPRIETARY

Page 52

1xEV Technology

RF Optimization Guidelines

6 Data Collection Procedures


This section summarizes the procedures that are used to collect raw data, and post-process it to get the information into a humanly readable form useful for further optimization work. Data is collected from the AT (mobile) side using CAIT, and from the network side using the AIPMON tool. The collected files are then post-processed and merged via LDAT. One time set-up of the tools to account for IP addresses, log and parsing masks, FLUS or Idle_Channel_Gain scenarios, etc., is assumed to be performed per procedures described in Sections 4 and 5. A step-by-step summary of the data collection procedure is also described in detail in the corresponding M&P document on optimization, which is in general updated more regularly than these Guidelines. A good practice would be to check for the latest version of the M&P document RF-E151. 6.1 Procedures at the beginning of drive testing: Identify drive route on the map, define driving speeds Ensure Test Carrier feature is activated and the test mobiles are programmed with access class higher than 0. Ensure the ATs are configured to operate in 1xEV only mode (disable Hybrid mode) and the proper choice of Simple/Mobile IP (based on the configuration of customer data backbone). Check for any background applications on the client and server computers that can steal throughput, and turn them off Powering up the CAIT laptops, run CAIT on Com 4 port of each laptop Make sure that both CAIT instances can log GPS data Set up the desirable settings/configurations and save the profile Under Options, on Logging Tab choose the File size e.g. to 5 Mbytes Duration of logging Display windows (i.e., Airlink Summary, RLP Statistics, etc.) Set logging mask for 1xEV ATs46 used in the test Now you are ready to log data on mobile phone (naming convention of log file, e.g. DDHHMMN.NNN where DD is the date, HH is the hour, MM is the minute of GPS time and NNNN is the last four digits of the mobile number) On the Packrat PC, double-click the AIPMON icon (if needed) From the File menu load the appropriate Log Mask47 (if needed)

46

Logmasks typically change with releases of CAIT, Chester, and in some cases LDAT. Latest version of the Logmask is normally specified in the M&P documents. Alternatively, users can go under View, choose Logging Mask or by pressing F5 and check the following (latest log mask in M&P document RF-E151): Searcher Data. Reverse Link Packet Summary. Reverse Traffic Rate Count. Finger Data. Air Link Summary. Power. Connection Attempt. Connection Release. RLP Statistics. State Info. Forward Rate Statistics.

LUCENT TECHNOLOGIES - PROPRIETARY

Page 53

1xEV Technology

RF Optimization Guidelines

From the DMIP list, choose the IP addresses of the TP processor (if needed)

It is very important that UATI information is recorded in the CAIT log. UATI information is needed for accurate post-processing of Packrat data together with CAIT data using LDAT. To ensure that UATI information is captured in the CAIT log, please follow the steps below. 6.2 Procedures to capture UATI information in CAIT log Enable CAIT logging. It is assumed that 1xEV session is already in progress. Initiate a new 1xEV data connection. If a connection is already established, then go to the next step. Disconnect the 1xEV data connection. At this point, the AT status window will display the current UATI. This information is captured in the CAIT log. Initiate 1xEV data connection again. If the average throughput is to be calculated from these files (normally throughput is not measured with CAIT on during optimization), then LDAT will assume zero values during this process, somewhat lowering the average. If the run is not long enough for this to be neglected, best practice is to exclude the first one or two CAIT logs from the data set when calculating averages. Procedures to collect data: Initiate a FLUS session or set the Idle_Channel_Gain according to what is agreed upon with the customer, if performing loaded testing Initiate a 1xEV session by powering up the AT if it was not registered with the network, note the UATI assigned to the session If reverse link metrics are required, start AIPMON by clicking the Start Logging at bottom left; optional prefix for the default log file name can be entered at this stage as well48 Start logging on CAIT for phone(s) in the kit under Options, then Toggle Logging, or by Alt+L Start Data transfer in both directions on two laptops initiate the UDP transfer through the GUI on Winds (or Packet Generator/Receiver), or WINDS FTP GET, or WINDS Ping for origination. CAIT should start displaying packet transfers in Airlink summary Start the drive test route At the end of the route, stop AIPMON by clicking Stop Logging in AIPMON window, bottom left Stop UDP/FTP/Ping tools. 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 Stop logging on CAIT for mobile(s) Stop the FLUS session if applicable

6.3

47

AIPMON log mask should be set up by choosing File, New Mask, and checking the following: HDRC_RECEIVED_FRAME_STATUS HDRC_RECEIVED_FRAME_RATE HDRC_RLINK_FRAME_ERR_CNT_PER_AT HDRC_TOTAL_RLINK_FRAME_CNT_PER_AT Option to initiate logging only for the UATIs selected in the previous bullet is also possible (conditional logging), but not recommended at this stage.

48

LUCENT TECHNOLOGIES - PROPRIETARY

Page 54

1xEV Technology

RF Optimization Guidelines

Transfer the saved AIPMON and log files on each CAIT to the Data Analysis computer for post processing Transfer the saved application layer files (WINDS log file, Orig_res.txt or FTP_Res.txt) to the Data Analysis computer for post processing To parse the AIPMON files prior to importing into the LDAT, choose Parse and Table menu, then select the file to be parsed, select All Attributes and under UATI select the UATI that was recorded at the beginning of the drive.

You dont need to parse the AIPMON files if they are to be post processed in LDAT (last step). 6.4 Data Processing Procedures

This section presents the changes in tools and steps required for processing the drive test data via LDAT. Creating a Dataset Copy all CAIT, WINDS and AIPMON/Packrat 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 Data File window, now click on Add Files, choose the CAIT and Packrat files and click Next. This will open the Cells File window. If needed, click on Browse, choose the cell file and click next. This brings up the Map Files window. If needed, click Add Files and add the required street maps. Then click Next. The next window is Metrics, check the required metric(s) and click Next. 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. In Scenario window, select the Bin size (generally 2 seconds) and click Finish. This will start the dataset creation process. After the dataset is created, use the Map, Histogram or Scatter menus to select a metric to be plotted.

Creating a new scenario: In LDAT, 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.

LUCENT TECHNOLOGIES - PROPRIETARY

Page 55

1xEV Technology

RF Optimization Guidelines

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. Data Archiving

6.5

In general, the same data archiving principles as in 2G/3G testing can be followed. An example of the recommended directory structure for data is shown below.
C:\CDMA |--MKTA | |-- CELLS | |-- DOWNLOAD | |-- MAP | | |-- DRIVE ROUTES | | |-- MAPINFO TABLES | |-- OMP_DATA | |-- TMP | |-- SECTORS | | |--- CELL001 | | | |-- yymmdd | | | |-- Fi

| | |

| | |

| | |

|-- Packrat/AIPMON files |-- WINDS data files (xL-Servername-mmyy-hhss.udp/.ftp/.ping) |-- FTP and ORIG results files (*.txt)
|-- LDAT3G dataset (data.SET) |-- Data files (mddhhmmx.xxx)

| | | | | | | | |

| | |

| | | | |-- Fn | |--- CELL002 | |--- | |--- CELLnnn |-- CLSTR_c | |-- RTrrr | |-- yymmdd | |-- Fi

| | |

| | |

|-- Packrat/AIPMON files |-- WINDS data files (xL-Servername-mmyy-hhss.udp/.ftp/.ping) |-- FTP and ORIG results files (*.txt)
|-- LDAT3G dataset (data.SET) |-- Data files (mddhhmmx.xxx)

| | | | |

| | |

| | |-- Fn |-- CRT (control route) | |-- yymmdd | |-- Fi

| | |

| | |

|-- Packrat/AIPMON files |-- WINDS data files (xL-Servername-mmyy-hhss.udp/.ftp/.ping) |-- FTP and ORIG results files (*.txt)
|-- Data files (mddhhmmx.xxx) |-- LDAT3G dataset (data.SET)

| | | | | |-- Exit Package| |-- MKTB | CDMA = main data directory

|-- Fn

LUCENT TECHNOLOGIES - PROPRIETARY

Page 56

1xEV Technology

RF Optimization Guidelines

c = cluster designation (letter or number ) rrr = route number (1a, 1b, 2a, ) yymmdd = date MKTA (B) = Market A (B)

LUCENT TECHNOLOGIES - PROPRIETARY

Page 57

1xEV Technology

RF Optimization Guidelines

7 Pre-RF Optimization
There are several tasks that have to be performed prior to RF optimization work. Some can be done well before any actual fieldwork starts, and most can be completed before the actual 1xEV equipment installation starts. 7.1 Spectrum Clearing Verification

Spectral clearance means a clear spectrum with sufficient guard band and guard zone. In general, it is the responsibility of the operators, not Lucent. However, if strong in-band interference is present, even intermittently, then radio performance can be significantly degraded and adequate performance of 1xEV (or any other CDMA system) will not be achievable. Detection of the interferences can be a very time consuming and difficult task once the 1xEV system is up and running. It is desirable therefore to have a very high degree of confidence that the spectrum is really cleared prior to any testing. In some cases it makes sense to have Lucent personnel verify the spectrum prior to the actual deployment. In general, spectral testing is applicable for any trial, FOA or any commercial deployment falling into the Cold Start category, especially in 1.9GHz and other bands previously occupied by microwave data services. In general, it should not to be planned if 1xEV is deployed as an overlay, because the CDMA operators with systems that operated for several years in the same band would typically have the spectrum cleared. However, it can be planned if the frequency band was acquired recently and has a fairly new 2G/3G system as an underlay. In either case, as a first step documentation related to the relocation of incumbents should be reviewed with Microwave Clearing personnel. Judgment call has to be made at that point as to whether further spectrum clearing tests need to be performed. The decision would often depend on who did the microwave relocation, availability of the documentation, importance of that particular deployment, etc. If a decision is made to execute the tests, clearing on forward link can be verified via drive testing, by using spectrum analyzer with adequate pre-amplifier49 as in 2G and 3G systems. Clearing on the reverse link can be verified by similar spectrum analyzer configuration once the base station antennas are up, or by base station received power measurements after antenna installation (but prior to optimization). In both cases it is essential to ensure that strong signals outside of the band of interest do not overload the spectrum analyzer input. If interferences are observed in the surveyed band, input attenuation has to be decreased if the observed components get attenuated by more than the extra attenuation factor introduced, this would suggest the inter-modulation problems. Although the eventual reverse link interference is in general easier to detect in a live system, removing it might be equally difficult process, so both forward and reverse tests should be performed as soon as possible. 7.2 Underlay System Baselining

This activity assumes overlay deployment scenario. In most cases this and spectrum clearing verification are mutually exclusive, i.e. if clearing has to be verified then there is no underlying system to baseline, and vice versa. System baselining should preferably be done by the RF optimization lead. The primary goal is to acquire all the information that would normally be available in design documentation at the beginning of Cold Start deployments, plus the operational information that could help identify possible optimization

49

RF M&P document RF-E088

LUCENT TECHNOLOGIES - PROPRIETARY

Page 58

1xEV Technology

RF Optimization Guidelines

problems, without actually drive testing the area. This activity would normally start by contacting the operators RF lead for the area in question, and besides discussions should include reviewing the available design, deployment, maintenance and performance documentation. In particular, the desired information should include the following: Cell sites locations (lat/longs and heights) for trial area and 1-2 tiers of cells around it (relevant area) Repeaters (location, type) in the relevant area (if any) Antennas (azimuths, down-tilts, types, cabling info, last sweep results) for all cells and repeaters Power settings for all cells and repeaters Carriers deployed in all cells and repeaters in the area of interest PN offsets and Neighbor Lists for the sectors in relevant area Operators own drive test data Any translations that depart from Lucent recommended defaults50 (including all CBR attenuation settings) Service Measurements for the underlying system in the relevant area The idea with last three bullets is to understand the overall performance and existing problems in the underlying system, so that expectations for RF optimization outcome can be properly set, potential problem areas identified up-front, etc. Much of this information can be obtained during the interviews with knowledgeable operators local RF personnel. This should be done especially in the cases when operator has constraints on what kind of information can be shared (some Service Measurements results appear to be treated as sensitive information lately by some service providers). While some level of compromise can be made on the spot regarding what information from the switch will be actually retrieved and what would be obtained through discussions, Lucent RF lead should absolutely insist on obtaining the present Neighbor Lists for the underlay systems in well designed and maintained systems, they contain information that can never be collected during several weeks of optimization work. 7.3 Drive Routes Planning

Besides planning of the drive routes themselves, their timely preparation in large optimization tasks ensures that the RF team is well acquainted with the test area from the topographic and demographic perspective, i.e. that areas deserving special consideration can be identified. These areas might cause concern because of the peculiarities of terrain (e.g. tunnels, causeways, canyons, large rivers, sea shore) that might impact the RF propagation, or the commercial importance of the area (primary and secondary roads, densely populated areas, big commercial or residential areas, major stadium, shopping malls, etc.). Population distribution maps, road traffic count maps, and other information that can often be obtained from the operators Marketing department might prove useful at this stage. For smaller clusters of cells typical for technical trials and FOA activities, this is usually a much simpler task. Once the team is familiar with the test area, the test routes planning can commence. The principles are very similar to those for 2G/3G optimization testing51: Sector Test and Cluster Optimization routes should be identified for all deployments (including various trials and FOAs); Cluster and System Control routes should be identified if the marker-wide optimization is done prior to commercial deployment.

50 51

Could be done by Lucents SPAT tool. RF-E149

LUCENT TECHNOLOGIES - PROPRIETARY

Page 59

1xEV Technology

RF Optimization Guidelines

Compared to previous 2G/3G cases, it is conceivable that somewhat larger percentage of future users of the system under optimization would be either in low mobility or stationary conditions. Because of that, customer sometimes request data to be collected with pedestrian speeds, or in a multitude of stationary locations. Such requests in general cannot be entertained in normal optimization work, because they would extend the required data collection time enormously. However, some of these cannot be avoided in the early technical trials, in which case special routes need to be selected that will permit driving at very low (pedestrian) speeds, or in the stop and go mode. If the test area does not offer enough roads where low mobility conditions can be tested safely, police escort might be sought, by contacting the local police department as soon as the need is recognized. If the system is a Limited Overlay deployment, and the Statement of Work or Contract calls for the optimization of 1xEV to 3G-1X handoff areas, Border Handoff routes have to be identified as well. If the 1xEV is deployed on a carrier adjacent to present 2G/3G carrier (almost always the case in Limited deployment), and the deployment is especially critical (technical trials, first cluster or first market deployment, for a major carrier, etc), a decision to do tests along Border Handoff routes might be reached even without the special SOW or contract, to ensure that no interference will be generated by 1xEV system into the underlay 3G-1X system. In order to do this, border cells within the 1xEV coverage need to be recognized first. Then, approximate contours with mobile receive power of -80dBm around each site in the first tier of neighbors around the 1xEV area have to be drawn on the map (coverage prediction plots would usually do, in some cases a series of quick experimental runs might be executed too). Border Handoff routes in either case are approximately radial routes leading from the 1xEV coverage until the 1xEV call drops. In general, a Border Handoff route has to be selected along each highway or street with significant outbound traffic flow, which may result in a considerable number of routes. Good news is that in most cases these will be quite short (of the order of 5 minutes, probably less than 10 always). In the case of incomplete overlay, analogous Border Handoff routes leading towards the skipped site (or repeater) from all major expected traffic flow directions need to be identified too. In summary, normal optimization work usually requires the following routes to be selected: For all commercial deployments, and trials, FOAs, etc. Sector Test routes (circular route around each cell, 15-30 min) Cluster Optimization routes (8-15 hours depending on the size of the cluster, covering all primary and some secondary roads, typ. hour per cell) Cluster Control routes (1-3 hours per cluster, major roads, typ. 1hr per 10 cells) Border Handoff routes (optional, could be required in Limited Overlay deployments; routes start at the edge of 1xEV coverage with 2G/3G system, 5-10 minutes routes along all major streets going out of 1xEV coverage until call drops). In the case of Incomplete Overlay, Border Handoff routes to all skipped sites or repeaters For commercial deployments (market wide optimization for hundreds of cells) only System Control routes (per contract, typ. 1 hour per each cluster, usually 6-8 hours) In general, all the routes should be identified in advance. For the Cluster Control routes (and possibly for System Control routes, if needed), every effort should be made to exclude any problem areas from the drive routes these problem areas refer to the problems found during the optimization work that can be resolved by longer-term measures only (e.g. coverage holes, requiring sites or repeaters to be added at a later date). Although the contracts usually allow for some bad data points to be excluded from the drive test data through post-processing, adjusting the routes to avoid such spots if done interactively with the customer is usually a preferred method.

LUCENT TECHNOLOGIES - PROPRIETARY

Page 60

1xEV Technology

RF Optimization Guidelines

During the optimization work, every effort should be made to ensure that RF Engineers do not act as drivers of the test vehicles. While this cannot be avoided occasionally, test teams should normally hire local drivers for this task, who are well acquainted with the area. In such cases, it is usually very helpful to provide both maps and driving directions for each route (start at location X, turn right/West into Y Rd., stay on Y Rd. for a mile, turn left/South into Z Rd.), etc. 7.4 Neighbor List Preparations

Biggest issues with the initial translation preparations are associated with the Neighbor Lists. The complexity of this task varies dramatically with circumstances. In particular, Cold Start versus Overlay and limited cluster optimization (for trials, FOAs) versus citywide system optimization prior to commercial deployment would make a huge difference. For Cold Starts of 1xEV, one would normally choose the PN plan and then follow exactly the same procedures described in analogous documents for 2G/3G systems52 (again, soft handoff algorithms are almost identical). Absolutely the same guidelines as to the contents, priorities of the entries53, and size of the list should be followed. In a nutshell, optimization should start with adjacent sectors of the same sell and sectors facing the sponsoring one from the neighboring cells having highest priority, second priority will be assigned to the sectors form first tier of cells facing away and second tier facing the sponsoring sector, etc. Coverage prediction maps should be further used to refine these initial estimates, both in terms of content and priority. For overlays, a judgment call has to be made before the Neighbor Lists are ported to the 1xEV system. Operators practices as related to the maintenance of the Neighbor Lists vary drastically. If there are enough reasons to believe that they are reasonable and up-to date, 1xEV optimization should start from them. This would save a lot of optimization time, especially in the cases where propagation anomalies might be expected. If, on the contrary, lists do not appear to be well maintained, dont look up to date, or look unreasonably long, the RF lead might want to have new Neighbor Lists built (especially for smaller deployments like trial or FOA, with limited number of sites and potential neighbors), or at least have an extensive review and scrub of the existing lists performed. At present, population and maintenance of the Neighbor Lists through EMS is a very cumbersome process, which requires considerable time. Several activities are presently underway to simplify and speed up this activity. 7.5 Translations Check

Other than the Neighbor List and the Test Carrier setting, other translation parameters should be kept at Lucent recommended values at this stage, defined in the 1xEV RF Translation Application Notes54. Possible exceptions are the sector size parameters for border cells, as well as both the sector sizes and search window sizes if the deployment plans assume unusually large or unusually small cell radii54. In addition to the translation parameter verification through EMS, tunable parameters, addressed in the 1xEV translation application note titled Introduction (Lucent internal version), also need to be checked and verified. The tunable parameters can be checked and updated via CLI (command line interface). CLI can be accessed after logging into OMP and then into AP.

52 53 54

RF-E145 Priority of the entries are currently not supported, but will become available in one of the forthcoming releases. http://rfcoresupport.wh.lucent.com/RFCoreSupportWebPage/rf_trans_appl_1xev.htm

LUCENT TECHNOLOGIES - PROPRIETARY

Page 61

1xEV Technology

RF Optimization Guidelines

Another thing to be checked are the PDSN translations, which have to be populated for each test terminal. Apart form user name and password to authenticate the users, these include several parameters that can impact the test results (e.g. various compression settings, character escaping, default packet size, etc.). As PDSN is formally not a part of 1xEV system delivered by Lucent (customers can use any PDSN they deem appropriate), universally recommended set of these translations might not be available. At present, the best solution seems to be for RF Test Lead to get in touch with the Network Installation team and obtain a list of translations recommended for the particular deployment, and then work with the Fixed Network support personnel to ensure that these are correctly populated for each user. In addition, the TCP and PPP settings have to be verified on each laptop that will be used in testing, as per Section 4.4. Background applications that can steal throughput have to be turned off.

LUCENT TECHNOLOGIES - PROPRIETARY

Page 62

1xEV Technology

RF Optimization Guidelines

8 RF Optimization
Optimization tests are those performed once the equipment is installed, connected and operational. The following represents the usual entrance criteria for this stage: Spectrum clearing is verified RF Antennas are expected to have been swept by measuring reflection losses and any cabling or connection issues resolved; cable and insertion losses are measured or catalogued; antenna azimuths and down-tilts are verified; sectors powers calibrated; any alarms suggesting bad cell or network hardware investigated and cleared; default translation entered for the whole system; preliminary Neighbor Lists populated in each sector; test-terminals tested, passed the inter-operability testing in Lucent labs and found to be compliant with the Minimum Performance Requirements standards,55 test terminals programmed for correct frequencies to be used, correct hybrid mode of operation (normally 1xEV only) and IP mode (normally Simple IP) as agreed with the customer test van set-up is agreed upon (reverse attenuation to model loading) and verified test van and test tools are operational mechanically, in terms of terminals, logging tools, parsing tools, scripts, etc (GPS, CAIT, LDAT and WINDS; PING and FTP scripts if used; etc.) PDSN and laptop settings set up correctly for each user AIPMON platform is installed, connectivity to FMS verified, logging and parsing tools tested and operational Data Server connected to PSDN in available, configured as FTP server with known user names and passwords (and WINDS server installed on the same server, if UDP used) drive-routes are identified and agreed with the customers functionality and connectivity of the base stations, data server and the whole backbone data network verified by the Cabled Throughput test56. Note that first 4 bullets are really applicable for Cold start deployments. In case of an overlay, documentation about these activities is usually not available, or is outdated. In such situations the RF teams will have to start by assuming that these are correct, and try to spot the potential problems based on the information gathered during base-lining (Section 7.2).

55

In the trial and other early tests not all compliance and interoperability testing is typically performed prior to the start optimization. Close-loop testing from Section 10 is intended to provide an additional level of verification in such cases. Cabled Throughput test is a quick FTP throughput test executed at the cell site with an AT cabled directly to the base station antenna port. It ensures proper functionality of all the network components, as well as the adequate performance of the backbone network in terms of the packet drops and delays. As of January 2004, it is still not decided whether this procedure will be implemented as a part of the normal cell installation/integration procedure, or will be offered as a special service, and whether it would cover all the cells or a subset of the cells.

56

LUCENT TECHNOLOGIES - PROPRIETARY

Page 63

1xEV Technology

RF Optimization Guidelines

It is ABSOLUTELY ESSENTIAL that no RF Optimization work is started until the Cabled Throughput test from the last bullet in the list above is executed at least in the few cells first. Failure to follow this requirement caused enormous problems in the field so far. Given that the execution of the Cabled Throughput Test is presently still discussed, if the RF optimization is supposed to start before the Cabled Throughput Test is successfully completed, an overthe-air stationary FTP throughput test in best RF (required data rate 2.4Mbps >95% of the time) needs to be executed by the RF optimization team prior to any drive testing activities. The procedure will be the same as for the stationary part of the Sector Test described in Section 8.2, and the measured throughput should meet the requirements from Table 257. If these requirements are not met, cell integration and network support teams should be alerted immediately. RF team should try to execute the Close Loop Test as described in Sect. 8.1 to help the troubleshooting process, but should refrain from collecting any 1xEV performance data until the problems are resolved (RF teams can only do RF surveys for identification of the coverage holes, pilot pollution areas etc. in such a case). 8.1 Close Loop Test (Optional)

This test is applicable in technical trial stages, early deployments, etc. Test is essentially a quick verification of the system performance in cabled environment (see Appendix for more details). Objectives of the test are to verify correct operation of the cell site, network and mobile terminals. It is an important step in the very first deployments, when new versions of hardware and software are frequently arriving for both infrastructure and terminals, and is frequently explicitly requested by customers in the early technology trials. Note that present CDMA optimization procedures assume mature equipment and do not have this test specified, nor described. Some additional details about Close Loop Test are therefore given in the Appendix. Close Loop Test ensures interoperability, quick end-to-end verification of system functionality and performance in controlled environment, and can help identify sub-performing base station or terminal equipment, which should be eliminated from further testing and replaced. It can also help detect the subperforming terminals, especially in the case of the new models that must be used for testing, which often did not go through complete interoperability and minimum performance testing cycles. It is also highly recommended in the cases when a completely new base station model (or a major hardware or software revision) is deployed in the field for the first time (but not for the normal new software releases on the existing, well tested platforms). For the first technology trials with a few sites (say up to 5), such tests should be planned on more than one sector (preferably all), and should be phased-out completely as the infrastructure and terminals mature. When the stage of really massive deployments is reached (simultaneous optimization in dozens of markets), these tests are not required, except may be once for each new optimization team, as a training exercise, when a new base station type is deployed in the field for the first time, when the eventual new type of test mobile is to be used, or as a part of a troubleshooting exercise (i.e. Cabled Throughput Test on the cell gave satisfactory results, but stationary on the air test cannot replicate the minimum acceptable results).

57

Good practice here would be to try to run periodic FTP tests described in Sect. 5.4 for a period of the order of 24 hours, to ensure that no sporadic problems exist in the backbone data network when it gets loaded (parts of the backbone network sometimes share resources with operators inter-office data traffic and other data services, and can experience issues during peak traffic times that otherwise cannot be easily caught). It is highly recommended that such long test be done whenever a convenient indoor location can be found (hotel room, local Lucent office, operators office, etc). Log files from the FTP test should be inspected for any intervals showing inferior performance, and network installation and support teams alerted if any are found.

LUCENT TECHNOLOGIES - PROPRIETARY

Page 64

1xEV Technology

RF Optimization Guidelines

8.2

Sector Testing

Objectives and methodology of Sector testing are very similar to the usual Sector Tests in 2G/3G58, i.e. it is a sanity check designed to ensure that the sectors are radiating at the common sense power levels and in the common sense directions, with correct PN offset, that elementary 1xEV connection processing functions work (call establishment, data transfer, softer handoffs), and that reasonable performance is reached in good RF conditions. Sector test should be executed with one single mobile active in all the sectors to be tested. This has to be ensured by direct communication with all team members, or preferably by checking and accounting for the locations of all active mobiles from the PDSN (unaccounted mobiles should be disconnected from PDSN side at this stage). If in doubt, RF teams can also check the number of users in the sector by looking at the number of Forward Traffic Valid bits in the Quick Config. Message received over the control channel, where each entry corresponds to one active AT (i.e. more than one Forward Traffic Valid entry would indicate presence of additional mobiles in the sector tested). rooftop antennas
4-5

1:2 splitter

1:2 splitter

AT1

AT2

1xEV Toolkit

Figure 11: Setup for Functional Tests

Recommended set up for the functional tests is depicted in Figure 11. Two sets of antennas, a pair for each terminal without the splitters, is also a viable option, at RF teams discretion. Use of internal AT antennas in any of these measurements is not recommended, because of the significant variations depending on the near field environment (movements of the operators, equipment near by, etc.). External antennas in general ensure much better repeatability and reliability of the results. CAIT should be initiated at the beginning of the test on both terminals, and kept running during the whole test59. One AT should run the originations test (WINDS Ping), and the other should run the download (WINDS FTP). AIPMON logging is in general not required for Sector Tests, except during the eventual troubleshooting later on.

58 59

PCS CDMA RF Optimization Handbook 602, Lucent Technologies, Section 601-609 If the terminals used for testing end up being impacted by CAIT logging, as was the case with early Chesters, and can still happen with Chesters in the Mobile IP mode, than CAIT should be ran on the AT running the Origination scripts only.

LUCENT TECHNOLOGIES - PROPRIETARY

Page 65

1xEV Technology

RF Optimization Guidelines

lkH jihf d' lHdddddddd eeeeeeee ' jjjjlkH jiddddhggggf eeeed' jlH ihg e' jlH ihg e' lkH jihf d' lkH jihf d' j kkkk jjjj i dddd h g ffff e dddd jlH ihg e'

Figure 12: Typical Sector Test route (X marks locations where vans are to be stopped for stationary throughput tests)

If possible, sector test should start underneath the cell site, where levels in the 40 to 50dBm range should be seen from respective sectors, unless there is a serious problem with power amplifier, jumpers and cables, or antenna itself60, as depicted in Figure 12. Origination testing as defined in Section 5.6 should be initiated on one AT, and kept on during the whole test. If the ping responses are not received, the whole setup has to be verified. If the pings are going through, expected failure rate during the functional test stage should be in 1-2%. If more than 3% failures are recorded during the functional test, the site will have to be revisited. It is important to remember that NO MAXIMUM RATE VERIFICATIONS SHOULD BE ATTEMPTED IN THE CLOSE PROXIMITY OF THE CELL SITE61. Failure to follow this guideline caused frequent false alarms from the field about problems with the deployed 1xEV systems, and should be avoided. Drive testing should then proceed to the previously identified circular Sector Test route, which should be far enough from the cell (at to of the designed cell radius, mobile receive power typ. around -70 to -80dBm). In the bore-sight of the first sector antenna to be tested, test vehicle should be stopped. For this purpose, bore-sight is defined as area along the geographical bore-sight under line-of-sight condition if possible, with no softer handoffs (which should be verified from CAIT screens upon stopping, by looking at SNRs per PN, RPC per PN, number of Active Pilots, or any other suitable metric). Average requested rate at that location should be above 1.5Mbps. At this location, stationary FTP transfer results should be collected for several minutes. The minimum downlink results for the conditions as specified in Section 1.10 (Table 3Table 3) should be observed. If the download FTP throughput results do not meet the expectations, RF conditions should be rechecked. If

60

This is almost always possible with sites built on the stand-alone towers. In many cases when the sites are on the buildings in urban areas, this step has to be omitted. Directly underneath the site terminals can often see 2, if not all 3 pilots. This is because they are not in the main vertical lobe of any antenna sector., so they end up interfering with each other. All maximum throughput tests should be executed in the areas with one dominant serving sector only.

61

LUCENT TECHNOLOGIES - PROPRIETARY

trp n u q#XsqT#om

# 
Page 66

##  ##  ##  ##  ##  ##  ##  ##  ##  ##  ##  ## 

1xEV Technology

RF Optimization Guidelines

they meet the expectations, and the expected FTP download throughput is still not reached, FTP upload throughputs should be recorded for a few minutes to aid further troubleshooting, and the cell and network installation and support personnel alerted about the problem with the sector tested. Once the throughputs are verified, vehicle should continue along the Sector Test route with FTP downloads, and softer handoff execution verified. When position in the bore-sight of the second sector is reached (and no softer handoff state verified again), the verification of the stationary throughputs should be repeated, and the whole process continued until the whole Sector Test route is completed, after going through all the sectors. By observing the CAIT screens during the run, as well as from LDAT screens after the log files are postprocessed, the common sense received power and PN offsets should be verified (and the Transmit Gain Adjust values). Although the verification of the maximum rates is an important part of the Sector Test, it should be emphasized that is is not the most important objective if the Cabled Throughput Tests were executed first. Just like in 2G/3G, Sector Tests provide sanity check for some elementary translations, for power calibration, for antenna and cabling installation, elementary call processing on the cell, etc. They can help detect problems which are otherwise very difficult to recognize during cluster and system tests (such as missing receive diversity antenna, or cross-connected diversity antennas, which could easily be missed even during Cabled Throughput Tests; criteria to detect those by looking at the Mobile Receive Power, Pilot Ec/Io and Transmit Gain Adjust values are the same as for 2G/3G58). Because of this, Sector Tests must be executed under all circumstances. Once enough sector tests are performed for the RF team to become reasonably comfortable about general system performance, test can be simplified by eliminating the AT doing originations testing. The set up from Figure 11 can then be also simplified to avoid the splitters. The use of rooftop antennas is recommended even in that case, however, because of the better repeatability of the results. 8.3 Cluster Testing

Cluster is a set of neighboring cells that is large enough for meaningful multi-cell optimization to be performed, which basically means that several tiers of cells are up to create interferences, yet small enough for one optimization team to handle. Optimization team normally includes drivers, data collectors, and RF data analysts62; it can be as small as 3 persons, in which case the RF Optimization lead acts as data analyst himself, or can have several driver/data collector/data analyst teams, with the Optimization lead. Clusters typically range from as small as 5 cells for initial technology trials and FOA, to as many as 25-30 cells in the later stage of optimization. Within a large MTA, several clusters can be optimized simultaneously as well, again similar to Cluster Testing in 2G/3G scenarios63. Major difference between previous CDMA technologies and 1xEV in terms of RF optimization is that cluster level testing does not have to be split into separate Pilot Survey/Unloaded Coverage Testing and Loaded Coverage Testing stages. As explained in Section 1.6, Pilot Survey would give essentially the same results independent of loading, so that it in 1xEV it should be combined with other tests. The fact that no loading is needed for optimization represents a quite significant time saving.

62

In the early optimization, one person would likely be needed at the FMS, to monitor all network components, support and monitor AIPMON and the data server, etc. Data Analyst can perform some of these tasks, unless he/she is acting as a data collector as well. PCS CDMA RF Optimization Handbook 602, Lucent Technologies, Section 212.

63

LUCENT TECHNOLOGIES - PROPRIETARY

Page 67

1xEV Technology

RF Optimization Guidelines

Cluster Testing is typically done in three phases. The objective of the first phase is to locate the trouble spots, and is essentially a survey of the whole Cluster Optimization route. In second phase the trouble spots are identified, and various optimization techniques applied to resolve or alleviate problems. It normally includes repeated drive testing of the problems areas. Last phase is another survey of the Cluster Optimization routes, after all the fixes have been applied. The objective of the third phase is to provide verification of the optimization work, and generate the performance metrics to demonstrate that Exit Criteria are met.

Cluster Optimization (CO), typ. hour per cell Cluster Control (CC), typ. 1 hour per 10 cells

Figure 13: Cluster Optimization and Cluster Control routes

The first phase of the Cluster Testing can use the same set-up as depicted in Figure 13 for Sector Testing, but can use two pairs of separate antennas without splitters as well, depending on what is more convenient for the drive team. The use of terminal antennas is not recommended. CAIT logging should be turned on for both ATs. AIPMON logging for reverse link data is optional. In terms of the data generation, one AT should be executing the origination test (WINDS Ping), and the other should be doing the WINDS FTP downloads. This means that no reverse link throughputs will be measured in this phase present experience suggests that forward link downloads in combination with the origination data gives enough information about RF that uploads are not required. If the exit criteria for the optimization specify the reverse link throughput and not the origination success, then the field crews can decide to run the WINDS PUT test on the first AT, to proactively check the low reverse link throughput areas. If the exit criteria specify both origination success and the throughputs in both directions, then double surveys might be needed: first with origination and WINDS FTP GET, second with origination and WINDS FTP PUT. For first stage of Cluster Test surveys, the following data should be mapped via LDAT at minimum: Mobile Receive Power Mobile Transmit Power Forward SNR (or Best Ec/Io) Forward Physical Layer Requested Rate Forward RLP throughput Forward Physical Layer Packet Error Rate Reverse Pre-RLP Octet Error Rate
LUCENT TECHNOLOGIES - PROPRIETARY Page 68

1xEV Technology

RF Optimization Guidelines

Reverse Physical Layer Packet Error Rate This data can be mapped for both ATs, but one would normally suffice. In addition, the following should be mapped using LDAT3G for each of the ATs: Drop call locations (from AT doing WINDS FTP GET ) Failed Originations locations (from AT doing WINDS Ping for origination) If the problems are experienced with LDAT3G, failed originations can be determined by correlating the time stamps from WINDS PING logfile with the respective CAIT data. For the drops, outputs of the WINDS FTP log have to be reviewed first, and correlated against CAIT data. In addition, CAIT message logs have to be parsed for all Connection Close messages and the results correlated against the WINDS logfile. Drop call rates is evaluated as the number of unexpected Connection Releases divided by the number of hours the test lasted (drop per hour rate), which then has to be divided by 40 to normalize to the 90 second call. Once the data from the first phase is collected, problem spots have to be identified and optimized. Methods to identify the problems and possible corrective actions that can be undertaken depending on the problem type are discussed in Section 9. After each corrective step, the area should be re-driven and the corresponding maps recreated. In general, optimization binder with hard copies of the various interim and final plots should be maintained for reference. Soft copy archiving of the data also has to be maintained. General policies outlined in CDMA Optimization Handbooks can be followed for both. In general, the set-up in the second phase of the optimization will be the same as for the initial surveys. Depending on the nature of the problem that is being resolved, however, often a single AT with either WINDS FTP or WINDS Ping based origination can be sufficient. In second phase of the Cluster Testing important thing to remember is that the optimization work can never be completed no matter how much work has been done, there are always areas that can be further improved (that is one of the reasons why operators keep the RF Performance engineers on the payroll). It is the responsibility of the Test Lead to make a judgment call as to when enough optimization is done to meet the objectives. The objectives are specified by the Exit Criteria, but in some cases it might make sense to do as much optimization work as the time permits, even though the criteria will be exceeded (in general, for any performance or marketing oriented trial, it is in Lucents best interest to optimize as much as possible, in order to demonstrate the best possible performance). Once the optimization is finished, the final cluster testing (Cluster Exit Criteria test) has to be executed. In general, the exact set up for this test is specified in the contracts, or in the statement of work. In particular, these usually specify the in-vehicle penetration losses and reverse link loading attenuations that have to be used. Single or two pairs of antennas can usually be used even in that case, except that in the former scenario the 3dB splitter loss has to be taken into account when setting the attenuator levels. So far, Exit Criteria have been defined in such a manner that only forward link throughput (besides origination success and drop call metrics) was required. In such cases, two ATs set up with one terminal running origination (WINDS Ping) and the other running the FTP download (WINDS FTP GET) have been sufficient. If in the future contracts end up specifying the reverse throughput too, and WINDS tool cannot be used to create simultaneous data flows on both links, two passes along the Cluster Control routes will be needed. However, this is not a major burden, because Cluster Control routes are usually of the order of 1-2 hours per each cluster (much shorter than the Cluster Optimization routes), and the tests are performed hopefully just once. We would like to emphasize that, although the data from major, relatively short Cluster Control routes are included in the final testing and checked against Exit Criteria, full set of test results from the extensive Cluster Optimization routes (from the first phase of Cluster Optimization effort) is normally

LUCENT TECHNOLOGIES - PROPRIETARY

Page 69

1xEV Technology

RF Optimization Guidelines

included in the final package, along with the pre and post optimization runs results in the identified problem areas. A punch list, enumerating problem areas that could not be resolved by optimization but need additional long-term solutions (new sites, antenna work that could not be completed in time, etc., see Sect. 9 for more details) is usually also included (it is often used for justification of the Cluster Control routes selections or adjustments as well). This whole package will provide a very comprehensive view of the results obtainable in the whole cluster area. Exact format of the outputs for the Exit Criteria testing over Cluster Control routes is normally specified by the contract. Except the drop call and failed origination attempts maps, they usually include the RLP throughput maps for the links specified, as well as the high level summary of the averages for access success and drop call rate metrics, RLP throughputs, and also the application layer throughput results. RF optimization is completed if these averages meet the contractual requirements. It should be noticed that the contracts usually allow for certain percentage of the bad data points to be excluded from the statistical averages (or at least that data from coverage holes can be excluded). Every effort should be made to achieve this by proper selection of the Cluster Control routes proactively, rather than by post-processing of the collected data after the fact. 8.4 Inter-System Handout Testing

Principles of 1xEV handoffs were summarized in Sections 1.3 and 1.4. Virtual handoffs on the forward and normal soft and softer handoffs on the reverse link dont need any special optimization beyond the usual troubleshooting. In terms of handoffs from 1xEV to 3G-1X system in Limited Deployments, and associated session handoffs in the case when Mobile IP is supported (see Sections 1.4 and 1.5), it is expected that their optimization will not be the part of activities in most RF optimization tasks. Lucents justification for this is that the inter-system handoffs are executed between mobile AT terminal and the PDSN, without any support from Lucent provided infrastructure, and thus do not fall into the scope of the normal optimization work performed by Lucent. However, in some cases inter-system handoff optimization might be specified either in the statement of work for normal optimization, or under a separate statement of work. Even when not explicitly specified in any document, these tests usually cannot be avoided in some technical trials and first market deployments for any major operator, where the operators are often keen to have the functionality and reasonable performance demonstrated in the field. In any case, Lucent teams should limit the scope of this work to the hybrid operation only (i.e. ensuring that the AT at the edge of 1xEV coverage indeed drops the 1xEV service, and successively finds the underlay 3G-1X service). The execution of the Mobile IP based session handoff after that is in reality a function of the PDSNs and Home Agent, and the terminal itself. They are in no way dependant on the Lucent 1xEV system, or the actual RF situation on the ground. Some system parameters on the network side beyond FMS can be tweaked to optimize the data flow interruption time in this scenario, but that is definitely beyond the scope of the RF optimization work. If the inter-system handoff optimization happens to be included in the scope of RF work, in first phase of the optimization all major routes along which the handoffs are expected (Border Handoff routes) to occur need to be surveyed. One terminal with FTP downloads and active CAIT will suffice. Note that the RF toolkit will have to bypass the circulators/attenuators/magmount antenna assembly (basically use the native antennas of the AT) if the1xEV and the 3G1x carriers are on different bands (PCS and Cellular). This is because the circulators used inside the toolkit for separating & re-combining the transmit and receive paths of the AT are specific for each band (do not have flat frequency response across both the bands).

LUCENT TECHNOLOGIES - PROPRIETARY

Page 70

1xEV Technology

RF Optimization Guidelines

Handoffs would be detected by a stop of 1xEV data flow. Subsequent acquisitions of the 3G-1X system have to be monitored from the 3G-1X message logs in CAIT. The logmask will have to be modified to ensure both 1xEV and 3G1x messaging is logged. If the Mobile IP is supported, from the application layer perspective the FTP will then resume, after a pause of 10 seconds or so. If in Mobile IP scenario the pause during the inter-system handoff is considerably larger (say, 15-20 seconds), and the CAIT files show that 3G-1X connection was successively set-up at first attempt, this is normally a sign that further optimization on the network side parameters might be needed, and the network support personnel should be alerted about this extra delay. However, from the RF perspective, once the 1xEV service is abandoned and the 3G-1X connection successively established, the RF optimization is done. Major difficulty with border handoffs and the associated routes is that 1xEV signals from the border cells tend to propagate far. Theoretically, reason for this is that border cells have very little out-of-cell interference. In practice, overlay systems often have much smaller cell radii than what is dictated by the link budget it is not uncommon in such systems for the handoffs to occur well beyond the first tier of 3G-1X cells, often in the second or even third tier of cells The crux of the inter-system handoff optimization is to ensure that the RF conditions on 3G-1X system is good enough in the general area where 1xEV service is abandoned. The difficulty here is that the terminal itself defines the conditions when the 1xEV system would actually be abandoned, i.e. different terminals with different in-car or in-building penetration losses will have different handoff locations (this is one of the major reasons why inter-system handoff optimization should not be specified within the normal optimization work). If it is specified, however, the RF optimization team should limit the scope of survey testing to the contractually agreed terminals and attenuation set-ups. Once the general area where 1xEV service is abandoned is determined, underlay 3G-1X system should be surveyed for any possible RF problems, such as coverage holes or areas with excessive pilot pollution, which could impact the success of the subsequent 3G-1X originations. If the areas happen to be problematic on 3G-1X system, then the optimization boils down to an effort to move the areas where 1xEV service is abandoned to the area where 3G-1X service is good, or at least better. Normally, the tool to achieve this is the CBR attenuation, i.e. optimization teams would keep on increasing the attenuation to move the 1xEV drop area closer to the serving 1xEV site and out of the 3G1X problem area. Moving the 1xEV drop area reasonably close to the first tier of 3G-1X neighbors would often require the attenuation levels which will severely restrict the border 1xEV cells coverage. Customers should be consulted in such cases, because the data throughput on 1xEV is usually significantly better than what will be achieved after switching to 3G-1X. In addition, there is a theoretical possibility that the AT operating on 1xEV system can get close enough to the 3G-1X cell to create some adjacent channel interference64, provided of course that the 1xEV carrier is adjacent to the 3G-1X carrier (which is usually the case in the field, but not always). This situation would manifest itself as a noise rise alarm on the underlay 3G-1X carrier, i.e. service on the 3G-1X system will be temporarily impaired, not the service on 1xEV. Adjacent channel interference could also happen on the forward link, in which case the requested data rates on 1xEV will go down and ultimately the service will be lost, in spite of the large measured mobile receive power on 1xEV. This can normally be detected if the mobiles are in 1xEV only mode if they

64

V. Jovanovic, M. Callander, 1xEV and 2G3G border issues, Lucent Technical Memo, 12/16/2002 V. Jovanovic. Redirect Criterion for Overlay Borders in CDMA Systems, Lucent Technical Memo, 04/01/2003

LUCENT TECHNOLOGIES - PROPRIETARY

Page 71

1xEV Technology

RF Optimization Guidelines

are in hybrid mode, the fact that forward link is deteriorating will just speed up the abandonment of 1xEV system and switching to the underlay 3G-1X. If the operator is launching 1xEV service with hybrid 1xEV/3G-1X mode terminals only, the criterion for switching to the 3G-1X service is conservative enough (see Section 1.4 for further details) that no adjacent channel interference is normally expected. It could happen extremely rarely, and it is expected that such situations will be dealt with as a troubleshooting exercise by a special team, not as a part of the routine optimization work. In Incomplete Deployments, possibility for the adjacent cell interference is a bit larger, especially if the site where 1xEV is skipped is located in the dense urban environment with extremely small inter-cell spacing. Eventual optimization in these cases would require driving on the Border Handoff routes from the combined 1xEV/3G1X coverage towards the 3G-1X only cell along all major routes, and ensuring that the 1xEV service is abandoned and 3G-1X service reselected before the mobile receive power on 3G-1X service exceeds 80dBm (see document referenced in the footnote 64 for justification of this methodology, basically if the 1xEV connection is dropped before the underlay 3G-1X signal reaches about 80dBm by the reciprocity principle the adjacent channel interference into the 3G-1X cell in question would be also negligible), but that scenario would not be expected in the course of the normal optimization work either. If the system to be optimized is Limited 1xEV-only deployment, but overlaid on top of a 3G-1X system on an adjacent carrier (highly unlikely based on the present deployment scenarios adopted by all major operators, they all seem to want limited 1xEV deployment in the urban busy areas, and to rely on 3G-1X service around this major core), adjacent channel problem might be a bit more frequent problem, because of the 1xEV coverage overshoots. Theoretical calculations, however, show that even in these cases the adjacent channel interference can have an impact only in the the situations where inter-cell distance between the 1xEV/3G-1X cell and the 3G-1X only neighbor is very small (say, less than 1 mile), and the propagation conditions correspond to a relatively open, uncluttered area. These are quire rare, because inter-cell distance in open areas (i.e. sparsely populated suburban and rural areas are usually much larger than 1 mile). In such cases this optimization would probably be executed as a part of a special troubleshooting effort. Analogously, the island cells with 3G-1X only system surrounded by the multimode 1xEV/3G-1X cells in incomplete deployments can be impacted. Based on the discussion above, handout testing should be planned if 1xEV mode only terminals are deployed, but this should be limited to the cells in urban areas with small radii. If the interference possibility is detected, the only possible optimization solution would involve pulling back the coverage of the combined 1xEV/3G-1X cell by reducing the transmit power so that 1xEV call is dropped before the power received by the mobile on 3G-1X system is below 80dBm. If that effort fails, or if some very unusual propagation conditions can occur (for instance, mobile in the high rise in the border areas so that the path towards the 1xEV cell is heavily shadowed, but not enough to drop the connection, and the path to 3G-1X cell essentially unobstructed), then the Global Redirect in the border 1xEV sector might need to be applied, which would instruct all the mobiles to abandon the 1xEV system unconditionally. This option should be used as a last resort, because it essentially kills the coverage of the border sector. 8.5 System Testing

System testing involves fusion of the previously optimized clusters, and System Testing required to demonstrate the Exit Criteria negotiated in the contracts. At present no contracts are available the exact System Test will have to be defined once those requirements are known, and are likely to be customer specific

LUCENT TECHNOLOGIES - PROPRIETARY

Page 72

1xEV Technology

RF Optimization Guidelines

As for the merger of the previously optimized clusters, optimization teams would have to worry about the clusters borders. If all the cells were brought up before start of the optimization (i.e. if the individual clusters are just administrative boundaries to partition the optimization work into more easily manageable chunks), it is possible that additional work will include just driving a few routes along the borders and fixing any problems that might arise65. Every effort should be made to try to do the original cluster optimization work with at least one tier of cells active beyond the cluster boundary, in which case virtually no optimization of the seems will be necessary. Although the set-ups, metrics, and data generators for System Testing are to be defined, all System Testing is normally done on major primary roads (roughly one hour per cluster). Although the exact details of the tests are not known, it should be fairly easy to identify the potential parts of the System Test routes within each cluster up front (these would often be a sum of parts of the individual Cluster Control Routes). If a special attention during the Cluster Optimization was devoted to those areas, it would generally simplify the System Testing phase a lot.

65

Since most early deployments are expected to be overlays, it is conceivable that large numbers of cells can have 1xEV installed in a very short time. In cold starts, site development process is much longer, and clusters are most often optimized as the reasonably sized groups of cells become available.

LUCENT TECHNOLOGIES - PROPRIETARY

Page 73

1xEV Technology

RF Optimization Guidelines

9 RF Troubleshooting
In general, the troubleshooting will be simpler in the Overlay than in the Cold Start scenarios. Due to the similarities in fundamental principles, problem areas in 2G/3G are likely to create problems in 1xEV overlay. Recognizing the existing problems in the underlying system is an important part of preparatory work for such deployment scenario. It is important for customers to realize that many optimization techniques would improve performance on 1xEV would actually improve performance on both systems. In some cases, customers have been requesting that the overlay systems are deployed and optimized without impacting the underlay system in any way. Such requests are especially common in the initial trial deployments. These requests should be followed, but the implications would have to be explained to the customers as well. In the cases when the underlying system is very badly optimized, Lucent might not be able to guarantee the warranted level of 1xEV performance under such constraints (badly optimized areas could be due to poor original optimization, but more often happens when the operators added many sites within the original footprint since launch). In addition to the existing post-processing and troubleshooting tools, it is always a good practice for the RF optimization teams to utilize a common sense approach, where they would look at the maps and try to identify the problem areas based on first tier parameters such as: ineffective connection attempts dropped connections forward link Physical Layer rate 150kbps Physical Layer Packet Error Rate > 3% on any link Once problem areas are determined, RF optimization team should try to classify problems based on the second tier RF metrics as well, such as mobile receive and transmit power, number of pilots, SNR and best Ec/Io values, etc. Three most often used problem categories are: Coverage Hole No Dominant Server Weak Pilots Each of these is discussed below. 9.1 Coverage Hole

Because of the advantage in terms of the forward link budget, recognizing the Coverage Hole areas can often be somewhat deceiving, because that has to be done from the reverse link standpoint. Criteria for the Coverage Hole are: Predicted reverse Physical Layer data rate 9.6kbps Mobile transmit power > 20dBm Reverse Physical Layer packet error rate 5% (these 3 are effectively criteria for the border of coverage hole, deep enough in the hole, we would normally have a No Service situation). In general, all 3 conditions have to be fulfilled to declare an area to be Coverage Hole. Note that due to the link budget advantage of the forward link, criteria for hole are defined from the reverse link perspective. From the forward link side, no coverage hole should exist as long as the Mobile Receive power is above 105dBm. We note that in the field environment operators can easily fail to recognize the hole in coverage, or even the No Service situation, if they are simply monitoring the usual forward link screens from the diagnostic monitor. In particular, mobile receive power saturates at around 105dBm due to thermal noise limit,

LUCENT TECHNOLOGIES - PROPRIETARY

Page 74

1xEV Technology

RF Optimization Guidelines

and cannot be used for monitoring because the coverage boundary is well below that level (can go down to -118dBm); even more deceiving, the Forward Requested Physical Layer data rates tend to indicate non-zero values long after the connection is dropped due to the breakdown of the reverse link, because of the link budget advantage of the former. In the field environment, probably the easiest way to detect and verify the No Service situation is from the application layer, by using periodic Ping. Once the coverage hole area is recognized, several things have to be checked and attempted: in Overlay deployment, check the CBR attenuation and down-tilt for sectors facing the hole if CBR attenuation is not nominal, or if down-tilts are excessive, try to rectify be reverting to normal values change antenna replace with the higher gain model reorient antenna adjust azimuth so that present hole is nearer to antenna bore-sight (small gain) move antenna elevate on present structure if possible, or move (elevation does not bring much, e.g. 20ft on top of 150 ft bring around 1dB only, works if nearby obstructions need to be avoided) deploy a repeater bi-directional amplifier to rebroadcast the signal into the area of the hole (this is a possibility normally not recommended by Lucent optimization teams) move site especially if it became blocked since original design and optimization (e.g. by large buildings built in the vicinity) add a new site to fill the hole instead of a repeater, if there is a capacity driver Most items on this list (basically all but the first one) are associated with capital or expense costs for the operators that are often beyond the allocated RF Optimization budget. Except for the first one and eventually the 2nd and 3rd (antenna replacement or reorientation), these can seldom be done within the time frame allocated for optimization work. If the problem cannot be resolved within the time allocated, then the RF optimization team needs to document the problem, and recommend the solution to the operators, who will take steps at a later date, based on commercial importance of the area, budget constraints, etc. (this is often included in the punch list for the cluster). Although the remedies can come later, every effort should be made to adjust the Cluster Optimization, Cluster Control and System Test routes, to avoid the documented coverage hole areas. This has to be done in agreement with the customer, and a push back can be often expected, especially if the holes are in the middle of the cluster. Exit Criteria are in general lax enough to accommodate for a hole or two, but excessive areas of inadequate coverage would preclude successful optimization. In the RF optimization work that is a subject to the final warranty testing, such problems can have business implications to Lucent as well, and management has to be alerted about all detected coverage holes as soon as possible. 9.2 No Dominant Server

In general, No Dominant Server scenario corresponds to the problems with low data rates, access success and dropped calls due to the forward link problems. In particular, it relates to the situations when problems exist in areas with high mobile receive power, yet low SNR (and Ec/Io) values. Numerically, criteria for No Dominant Server scenario is Mobile receive power >-100dBm Mobile transmit power < 10dBm Mobile SNR<-5dB (Best Active pilot Ec/Io < -6dB) Signal-to-noise ratio SNR is a ratio of the power of the largest signal correctly detected and put into the Active Set, and the sum of the thermal noise and powers of all other signals that mobile receiver can

LUCENT TECHNOLOGIES - PROPRIETARY

Page 75

1xEV Technology

RF Optimization Guidelines

detect, but which act as interferences on forward link since neither of them is the best signal that will be demodulated. For SNR to be relatively low with high mobile receive power, one of the following 3 scenarios has to happen: some of the signals that mobile receives are large non-1xEV signals (external interference) some of the signals that mobile receives are large 1xEV signals, which for some reason have not been put into the Active Set; these reasons include: Incomplete Neighbor List Inadequate Search Window Rapidly Rising Pilot PN Offset Reuse Problem Cell resource blocking at Candidate cell (normally not encountered in unloaded tests) Active Set contains 4 or more pilots of similar magnitude (often called Pilot pollution) 9.2.1 External Interferences Detection of external interferences during optimization can be very difficult, especially if they are intermittent. Detection of interferences in live network, when cells cannot be quickly brought down to explore for the interferences, is progressively even more difficult. Detection of broadband interferences in a live network can be extremely difficult. The whole idea of Spectrum Clearing verification task in preparatory stages of the RF optimization is to avoid dealing with some of these problems. Even when the due diligence is exercised, it is still possible to encounter an interfering signal in the 1xEV band. The key indicator of the probable interference problem would be a big asymmetry between forward and reverse link in terms of performance and RF conditions, due to the fact that the external interference is practically always impacting just one of the links (forward and reverse link are spaced tens of MHz apart, depending on the band class). If the external interference is suspected, system should be shut down in the area under investigation, and measurements executed the same way as in the initial Spectrum Clearing verification survey from Section 7.1 is done. If the interference is detected, operator should be alerted. Further steps are in general theirs, and often require some time to be resolved Lucent optimization personnel in most such cases should document the findings in the area, alert the upper management, and move to do further testing elsewhere. 9.2.2 Neighbor List Omissions Relatively high mobile receive power with relatively low SNR and Ec/Io when there are no external interferences suggests that strong 1xEV signal might exist in the area, but for some reasons we are not using it for transmission. By far the most common such case is due to the pilot being missed in the Neighbor Lists even with the Remaining Set Search Window equal to that of the Neighbor Set, terminals have a rather small chance to detect the pilots that are not on the Neighbor List (if the Search Window for Remaining Set is closed to zero after optimization is completed, this becomes an impossibility). The easiest way to detect the missing neighbor is to observe the PN offset of the pilot that terminal would detect after initialization (terminals normally go through it after each dropped call, but it can be provoked by powering down the terminal, and then powering up). This is the quickest technique to find a missing Neighbor, but will work only if it happens to be the strongest pilot available. If it is not the strongest, other methods would be often needed. In Cold Start scenarios while no pilot scanners for 1xEV are available, this might involve some trial and error procedure. One way is to expand the Neighbor List with prime suspects and re-drive. Other is to turn all the cells in the area off, and then back on in the Constant Pilot mode (normally used for sector RF calibration), and re-drive with a pilot scanner.

LUCENT TECHNOLOGIES - PROPRIETARY

Page 76

1xEV Technology

RF Optimization Guidelines

In the overlay scenario, the optimization team might want to recheck the Neighbor Lists of the original system first. If the Lists are identical for both systems, the quickest way to detect a pilot might be by using the pilot scanner on the underlay system. In addition, the Remaining Set Search Window Size can be increased from zero to the value used for Neighbor Set, and either the missing neighbors searched for through driving via CAIT and LDAT3G Alerts, or by using the Undeclared Neighbor List software feature. It should be remembered that in the multi-way soft handoff, the Neighbor Lists are combined to a maximum of 20 or 24, so that some valid pilots that might exist on the individual neighbor lists might get truncated in the ones that are sent to the mobiles. In the field this usually happens if a serious error in assigning neighbor priorities was made. Detecting this would use the same methods as for the truly missing neighbor; truncation would have to be verified by monitoring the handoff messaging. 9.2.3 Inadequate Search Window Size Inadequate Search Window Size is similar to undeclared neighbor pilot that should take part in carrying the connection is acting as an interferer instead. However, it is not missed because the terminals were not looking for it due to Neighbor List omissions. Rather, this pilot might not be detected because it arrives outside of the normal window of expected delays. In normal deployments these cases are very rare, but can exist if largely dissimilar cell sizes are used (micro-cells and repeaters, in some cases with repeaters further aggravated by additional delays through them). Theoretically, one could have some problems with the Search Window Size for the Active Set as well, but extreme multipath conditions that could cause them are almost never seen in the field. Either case, exactly the same methodology as for the missing neighbor case would be used to optimize and fix this problem. 9.2.4 Rapidly Rising Pilot It is another fairly rare propagation scenario where the pilot that terminal should be demodulating is not helping the transmission, but rather acting as interference. In this case, neighboring pilot is properly entered into the Neighbor Lists and Search Windows are properly adjusted for its expected delays expected, but this new pilot rises so quickly that as the interferer it breaks the connection before the system can complete the set-up necessary for this pilot to be used as a main pilot for the transmission. When averaged for short-term fading, normal rate of change for pilots in cellular system is less than 1dB per second, which any CDMA system handles without any problem. In extremely unfavorable scenarios, such as turning around a corner of a city block into a street with line-of-site conditions, this rate of change can go up to 10dB/sec. At such rates, what would happen with the call depends on the speed of executing handoffs, defined from the moment when RouteUpdate or PilotStrengthMeasurement messages are issued, until Handoff Direction or Traffic Channel Assignment message arrive back to the mobile indicating that the pilot in question should be put into the Active Set. As long as this requires less than 0.5sec, calls would handoff properly, with eventual errors lasting for 100 or 200msec, which is negligible impairment in most cases. A number of call problems, and even dropped calls were recorded in the field due to rapidly rising pilots with about 10dB/sec rate of change, but that was mostly in the early periods while the size of the Active Set was restricted to 3 pilots only. At that time, comparatively much slower pilot swapping procedures were often in progress when a new pilot arrived, and these could often take several times more time than normal pilot add or drop to complete. With a maximum of 4 or 5 pilots in the Active Set, such instances seem to have been extremely rare. It should be remembered that pilot rises can be fast enough theoretically that the link will be broken even with the fastest system response times, but such cases proved to be extremely rare in real life. The worst

LUCENT TECHNOLOGIES - PROPRIETARY

Page 77

1xEV Technology

RF Optimization Guidelines

documented example appears to be the one with rate of change of about 60dB/sec66, but such cases almost always involve man-made obstacles, and some serious problem either in the design, or the installation of antennas. Resolution of the rapidly rising pilot problem in such cases usually entails the site visit, and ensuring that the common sense practices were followed in the design and/or installation. While resolution might be simpler, detection of the rapidly rising pilot problems is becoming tricky because it is becoming somewhat less frequent and does not make the list of the first few usual suspects. First indication about rapidly rising pilot is non-symmetric field problem repeatable drop or bad call period when driving in one direction, and not in the other. After that, usual procedures for missing pilot cases would do, and in most cases the simplest one observing the PN the terminal comes up on after drop or power down and comparing to the one that was dominant before the problem occurred would be sufficient. Another way to detect this is to see whether the first Route Update Message that reports a new strong pilot never gets acknowledged, implying that the link broke down before the information could be communicated. 9.2.5 PN Offset Reuse Problem If Pilot_Inc parameter is selected following Lucent recommendations from the Application Notes, and the PN offset reuse patterns planned following the Lucent Design Guidelines, chances of having two signals with the same PN Offset interfering with each other are practically negligible; and in small deployments with a cluster or two only, the problem might be theoretically impossible as well67. Extensive cell additions within the camp after the original design and PN assignment could cause some problems with PN offsets, especially after several rounds of ad-hoc PN assignments, but even in such cases problems were fairly easy to recognize and rectify, even in the largest systems. One problem with PN offset reuse, which was observed in large fielded systems, was not related to direct interference from one sector to another with the same PN offset, but rather to the possibility that two sectors with the same PN offset might be detectable from different areas in some third sector. If too aggressive Neighbor List build is used in such a case, one sector could end up having two different sectors with the same PN offset in the Neighbor List. When the RouteUpdate or PilotStrength Measurement messages are issued indicating a specific PN, network would pick one of the two randomly from the RF standpoint, and would cause occasional bad calls and drops. Note that such problematic Neighbor List entries can be detected by Lucents database scrubbing tools, once they become available for 1xEV. 9.2.6 Pilot Pollution Pilot Pollution refers to the situation where mobile receive power is high, SNR and Ec/Io of the best pilot are low, and there are no problems due to external interference and missed pilots instead, area in question simply has 4 or more pilots of comparable strengths. Most often, the root cause for pilot pollution problems can be traced directly to the poor RF design even on the highest level, i.e. to the adherence to the theoretical grid, initial antenna azimuth layout, etc. However, even with the best possible initial designs, zoning and other constraints related to the actual cell positions create some irregularities likely to create Pilot Pollution.

66

This particular example was a cell with low height antenna on a cell next to the highway, which was mounted low on the on the building wall perpendicular to the highway, causing enormous round the corner effect at 60mph speed. In this case, the problem was resolved by simply moving the antenna to the other building wall adjacent to the highway, thus eliminating the corner effect and enormous rate of change of pilot strength. With Pilot_Inc=6, there are 85 distinct PN offsets possible, for 28 sites. With Pilot_Inc=3, total of 56 cells can be deployed without a single PN reuse.

67

LUCENT TECHNOLOGIES - PROPRIETARY

Page 78

1xEV Technology

RF Optimization Guidelines

When usual RF propagation anomalies are added, some pilot pollution is to be expected in any system it is probably the most frequently encountered problem in CDMA deployment. In markets with areas known to create RF anomalies, such as large bodies of water, instances will naturally be numerous and pilot pollution problem might become extremely serious, especially if the original RF design left a lot to be desired. Pilot pollution can be diagnosed with the aid of Pilot Scanner or by using the Alert tools based on PSMM messages on the underlying system. For Cold Start of 1xEV no specific tools are available yet, so common sense approach in combination with some manual work would be required right now (based on the number of pilots plots). Since we defined the No Dominant Server areas as those having mobile receive power above 100dBm, this meant that when such a problem is due to Pilot Pollution (and no missing neighbor or some other cause), we still have almost 20dB more on the ground than what is necessary for good transmission. Contrary to the conventional wisdom, the solution for Pilot Pollution problems is to start removing the signals from the area in question. Removal can go only so far before problems start to open on other sides, but is still the most efficient way to deal with Pilot Pollution. In particular, if the interferers to be removed come from the second tier of cells, the techniques are (roughly in order of chances to be successful): Down-tilt Power-down (CBR attenuation) Lower gain antennas Lowering antenna heights Antenna azimuth readjustments When some signals need to be removed from the 1st tier of neighbors, we are usually dealing with a ring of sites roughly equidistant from the problem area, always related to some kind of a grid problem. The techniques to be attempted are: Adjust azimuths Power down Down-tilt As opposed to the case with 2nd tier of cells, down-tilt adjustments in 1st tier cannot bring much improvement without hurting the coverage. Azimuth adjustments (rotation of antenna constellation), can be very effective in that case, at lease while the number of sites in the ring is reasonable (say, 4). If the ring of sites around the Pilot Pollution area has 5 or more cells, these techniques are usually not likely to completely remove the problem. If the problem happens to be in the important area, some additional investments are likely to be required. Solutions most likely to succeed, but most often beyond of the scope of RF optimization, are: Move the site (usually to align better with the grid) Deploy repeater to create dominant server (normally not recommended to the customers by Lucent personnel) Deploy additional site (if there is a capacity driver as well) Since the lead-time for any of these is quite long, it is essential that the problem is well documented, and upper management alerted about it. 9.3 Weak Pilots

Weak Pilot areas are very similar to the No Dominant Server, but are characterized by mobile receive power being lower than 105dBm, probably in 110dBm range and below (again, mobile receive power that test tools can report saturate at around 105dBm because of the thermal noise).

LUCENT TECHNOLOGIES - PROPRIETARY

Page 79

1xEV Technology

RF Optimization Guidelines

Weak pilot problems should be treated essentially the same way as No Dominant Server, i.e. area should be checked for possible interferences, missing pilots due to neighbor list omissions or inadequate window sizes, rapidly rising pilots, etc. Given that the received power is low in such areas, these scenarios are not very likely, but due diligence has to be exercised nevertheless. After that, one is usually facing a problem with too many pilots, similar to Pilot Pollution, but without enough power on the ground to remove excess signals. These areas are in general least likely to be successfully optimized even with the best due diligence, and should be identified as early as possible during the optimization. If the initial checkouts show limited success, the operators should be approached to discuss other options, such as site moves or addition of repeaters/sites, which require much longer lead-time. All weak pilot problems need to be well documented, and brought to the attention of the upper management. Once again, the Exit Criteria provide reasonable cushion to accommodate for several problems due to coverage holes, exceptionally bad pilot pollution that cannot be successfully resolved, as well as weak pilots, but excessive amount of these problems can preclude the system from meeting the contractual obligations.

LUCENT TECHNOLOGIES - PROPRIETARY

Page 80

1xEV Technology

RF Optimization Guidelines

10 Appendix - Close Loop Test


Block diagram of the set-up is depicted in the Figure 14 below. First set of attenuators need to be standard high power (JFW Industries, models 50FH-010, -020, -030) or equivalent, variable attenuator can be JFW 50DR-061 or equivalent, and Micro_Cicutis ZPD-2-1 or equivalent can be used for combiners/dividers. Attenuators and isolation box from the Tool kit are expected to ensure enough attenuation to break the link (around 160dB), but isolation exceeding 130dB would usually be sufficient for elementary sanity test. If the conditions permit, use of a long cable and placement of the access terminal outside of the base station room would be helpful.

~50dB

Isolation Box
0-80dB
20dB ATT
Tx1/Rx1

Tx/Rx1

ATT

power supply

BTS
~50dB

combiner r

ATT

divider

AT
Rx2

Rx2

ATT CAIT Laptop

Figure 14: Cabled Pre-Test Set-up Block Diagram

Test is initiated by making a connection with either FTP or UDP application at the mobile received power level of around 80dBm. After that, attenuation should be gradually increased in 1dB steps; mobile received power, signal-to-noise ratio, requested data rates on forward link and forward packet error rates should be monitored at minimum (additional forward or reverse link metrics can be also monitored or logged at this stage). Expected behavior is that at mobile receive levels above and around 80dBm the SNR is above 12dB, and the requested forward data rate at 2.4Mbps. When this is achieved, first checkout will be to ping the PDSN, Data Server (ftp server, also computer where network part of the UDP tool resides), and AIPMON server. Expected results should be around 110msec with PPP compression OFF, or around 90msec with PPP compression ON, with no time-outs68. Data Server (and AIPMON server if outside of the local 1xEV network) can have somewhat larger delays if they are going through the operators local network, but not by much. Values above 130msec (or 110msec with compression ON) would impair measurements, and have to be reported to network installation personnel to get resolved. If possible, it is strongly recommended that at least one location the ping test directed to the Data Server is executed for at least a couple of hours, to verify that packet drop rates within the backhaul network are reasonable. After ping, a quick test involving UDP or FTP throughput should be executed (about 5 minutes). Expected results are given in Table 2 (Section 1.10).

68

For 40 bytes ping, quick estimate of the expected round-trip packet error rate is around 22 (1%)2. With one ping per second, expected time-out rate is about once per 40 minutes. Note that round-trip-time can have some spread due to longer times in case of RLP re-transmissions; averaging needs to last longer (e.g. ten minutes for statistically valid results). Note that 150msec applies to Chester terminals, future terminals might have lower values by 20-30msec.

LUCENT TECHNOLOGIES - PROPRIETARY

Page 81

1xEV Technology

RF Optimization Guidelines

After that, attenuation should be increased in 1dB steps. Requested rate should fall to 1.8Mbps when mobile receive levels of around 90dBm are reached (exact value depends on the base station and the mobile itself). If the rate of 2.4Mbps cannot be supported at levels above 85dBm, new mobile terminal should be tested. If the same results are obtained with 3 terminals, sector in question did not pass the close loop test, and installation team should be alerted. Otherwise the mobile that failed should be set aside, and not used for subsequent testing. After switching to 1.8MBps, terminal should step the rate down to next lower rate every 2-4dB. Mobile receive power would decrease down to approximately 105dBm, after which it would saturate and not go any further (thermal noise level reached). Forward link Physical Layer packet error rate at each step should be either around 1%, or below 1%69. If 1% error rate cannot be maintained at any rate before minimum, the test failed and should be repeated with other mobiles. If 3 mobiles fail, installation crew has to be alerted. If some mobiles fail, they should be eliminated from further testing too. Depending on the actual isolation values, this process normally cannot be continued all the way to the lowest rate of 38.4kbps, because the required isolation might be too large. This is most easily recognized by SNR and rates remaining essentially constant with further attenuation increase. If this happens when the forward link requested rats is at or below 600kbp, the Cabled Pre-Test can be stopped and the test passed. If the rate cannot be reduced below 900kbps, isolation between base station and mobile is not sufficient and the set-up has to be rechecked. For completeness, the following is the summary of the equipment required for Closed Loop testing: # 1 Laptop Part Description Panasonic CF-48 with USB port, running CAIT and Data application software QTY/Kit 1 1 1 1 1 2 2 1

2 Access Terminal Characterized Qualcomms MSM5500 based Chester w/accessories (power cable) and components 3 USB connection cable 4 AT Isolation box 5 Power supply 6 Cable parts 8 High Power Attenuators 9 Attenuator 10 Variable Attenuators Provides connection between Chester and laptop for both data application and CAIT Customized by DTG to provide RF isolation AC power supply for all components Miscellaneous (long cables and connector adaptors) JFW 50FH-010, -020, -030 or equivalent Additional 20dB attenuator JFW 50DR-061 or equivalent

7 Splitters (combiner/divider) Micro_Cicutis ZPD-2-1 or equivalent

69

Mobile is supposed to select the highest data rate that the SNR can support. In some cases, the difference in the required SNR could be several dB. By increasing attenuation in 1dB steps, we would occasionally have SNR which is to good for one rate, but too bad for the next higher one. Mobile would have to keep on requesting the lower rate in such a case, and packet error rate would fall below 1%. This is most notable when the rate is switched from 1.8Mbps to 1.2Mbps, where the SNR requirements differ by about 4dB.

LUCENT TECHNOLOGIES - PROPRIETARY

Page 82

1xEV Technology

RF Optimization Guidelines

LUCENT TECHNOLOGIES - PROPRIETARY

Page 83

You might also like