CDMA RF Optimization Guide Issue 0 8

CDMA RF Optimisation Guidelines
Issue 0.8
July 10, 1998 Martin Kendall Technology Applications Group Dept.: 7455
PROPRIETARY INFORMATION: The information contained in this document is the property of Nortel Wireless Networks. Except as specifically authorized in writing, the holder of this document shall keep all information contained herein confidential and shall protect same in whole or in part from disclosure and dissemination to third parties.
Nortel Wireless Networks 1998 All Rights Reserved
CDMA RF Optimisation
1. 2. About Issue 0.8 Introduction 2.1. CDMA Optimisation Overview 2.1.1. Pre-Commercial 2.1.2. Commercial 2.1.3. System Expansion 2.2. Related Documents 2.3. Scope of this Document 2.4. Revision History 2.4. Contributors 2.5. Audience 3. Optimisation Procedure 3.1. Entrance Criteria 3.2. Sequence of Events 3.2.1. Pre-Commercial 3.2.1.1. First Pass: Unloaded 3.2.1.2. Second Pass: Loaded 3.2.2. Commercial 3.3. Exit Criteria 4. Initial System Parameters 4.1. Datafill Example 4.2. Types of Parameters 4.2.1. IS-95/J-STD-008 vs. Nortel Specific 4.2.2. Global/Sector Specific/BSC/BTS 4.2.3. Setting Parameters 4.2. PN Planning 4.2.1. Co-PN 4.2.2. Adjacent PN 4.3. Initial Neighbour List Generation 4.4. BTS Calibration
Technology Applications Group

6 7 7 7 7 7 8 8 8 9 9 10 10 10 10 10 11 12 12 13 13 13 13 13 15 15 15 16 16 17 18 19 20 20 20 23 23 23 23
4.5. Search Windows 4.5.1. SRCH_WIN_A, AccessChannelDemodulationSearchWidth, TrafficChannelDemodulationSearchWidth 4.5.2. SRCH_WIN_N, SRCH_WIN_R 4.5.3. AccessChannelAcquisitionSearchWidth, TrafficChannelAcquisitionSearchWidth 4.6. Neighbor Configuration File, Setneighbor and Checkneighbor 5. Data Collection 5.1. Tools 5.1.1. Mobile Data Collection 5.1.2. Test Van RF Configuration
Issue 0.8
July 10, 1998
Page 2
5.1.3. The Base Station Manager (BSM) 5.2. Simulating Loading 5.2.1. Forward Link 5.2.2. Reverse Link 5.3. Data Required 5.3.1. Selector Log Mask 5.3.2. Mobile Log Mask 5.4. Drive Testing 5.4.1. Shakedown 5.4.2. Drive Routes 5.4.2.1 Drive Route Selection 5.4.2.2. Benchmark Route 5.4.2.3. Driving with only one cluster of cells on air 5.4.3. Test Calls 5.4.4. Logging 5.4.4.1. Data Collection Restrictions 5.4.4.2. Logging Strategy 5.5. Data Management 5.5.1 Data Transfer and Tracking 6. Data Analysis Procedures 6.1. Tools 6.2. Datafill Audit and Shakedown 6.2.1. Datafill Audit 6.2.2. Shakedown Data Analysis 6.3. System Access 6.3.1. Access Failure Analysis 6.3.2. Access Success Rate 6.3.3. Access Parameter Tuning 6.4. Dropped Calls 6.4.1. Link Supervision 6.4.1.1 Mobile 6.4.1.2 SBS 6.4.2. Analysis 6.4.3. Dropped Call Rate 6.5. RF Coverage/Handoff Control

24 24 24 25 26 26 28 29 29 29 29 30 30 30 30 30 31 32 32 33 33 33 33 33 33 33 34 34 34 34 34 35 35 36 36 39 40 42 42 42 43 45 46 48 48 48
6.6. Search Windows 6.6.1. SRCH_WIN_A 6.6.2. SRCH_WIN_N 6.6.3. SRCH_WIN_R 6.6.4. BTS AccessChannelDemodulationSearchWidth, TrafficChannelDemodulationSearchWidth 6.7. Neighbour Lists 6.8. Performance/Trend Analysis 6.9. Per-Site Analysis 6.10. Capacity 6.10.1. Capacity Equations 6.10.1.1. Reverse Link
Issue 0.8
July 10, 1998
Page 3

49 49 51 51 52 52 53 54 55 56 57 57 57 58 58 58 59 62 64 64 64 65 65 65 65 65 65 65 65 66 66 66 66 66 66 66 66 66 66 66 66 67 67 67 67 67 67
6.10.1.2. Forward Link 6.10.1.2.1. From Drive Test Data 6.10.1.2.2. From BTSPerformanceData 6.10.1.2.3. Interpreting the Equations 6.10.2. BTS Operation 6.10.2.1. BTS Calibration 6.10.2.2. The Digital Domain, Forward Power Control and the Forward Blocking Thresholds 6.10.2.3. The Analogue Domain, Power Sensor and Power Limiting 6.10.3. Optimising for Forward Link Capacity 6.11. Power Control
6.12. Hard Handoff 6.12.1. Round Trip Delay (RTD) Calculations 6.13. 7. Other
Dropped Call and Access Failure Reasons and Solutions 7.1. Successful Call 7.1.1 Symptoms in Mobile Data 7.1.2 Analysis with Selector Logs 7.2. Access Fail and Dropped Call Reasons in Single Frequency System 7.3. Hard Handoff 7.4. External Interference (Fix this section) 7.3.1 Symptoms in Mobile Data 7.3.2 Analysis with Selector Logs 7.3.3. Further Analysis 7.3.4 Corrective Action 7.7. Site Not In Service 7.7.1 Symptoms in Mobile Data 7.7.2 Analysis with Selector Logs 7.7.3. Further Analysis 7.7.4 Corrective Action 7.8. Interference From Non Co-located AMPS Cellsite 7.8.1 Symptoms in Mobile Data 7.8.2 Analysis with Selector Logs 7.8.3. Further Analysis 7.8.4 Corrective Action 7.11. Handoff Boundary Balance 7.11.1 Symptoms in Mobile Data 7.11.2 Analysis with Selector Logs 7.11.3. Further Analysis 7.11.4 Corrective Action 7.12. Interference from Microwave Link (1900) 7.12.1 Symptoms in Mobile Data 7.12.2 Analysis with Selector Logs 7.12.3. Further Analysis 7.12.4 Corrective Action 7.13. Interference From Foregin System Mobiles into CDMA BTS 7.13.1 Symptoms in Mobile Data 7.13.2 Analysis with Selector Logs
Issue 0.8
July 10, 1998
Page 4
7.13.3. Further Analysis 7.13.4 Corrective Action 7.14. AMPS A/B Band Coordination 7.14.1 Symptoms in Mobile Data 8. Other Optimisation Procedures and Special Cases 8.1. Adding New Sites 8.2. Other Special Cases 9. Appendices 9.1. Sample Mobile Data Log Sheets 9.2. Importing Files into Planet 9.3. QCP Tech Mode Screen 9.4. Sample Rundesc.txt 9.5. Calculating Required Power Reduction for Unwanted PN

67 67 67 67 68 68 68 69 69 74 74 75 76
Issue 0.8
July 10, 1998
Page 5
1.
About Issue 0.8
To be added to future issues: hard handoff (both normal and f1/f2) - triggers, 2-sectors/one site issue, idle mode options flow diag balancing traffic across sectors BTS PerfData capacity parm tradeoffs determing RTD thresh by logging NLTA and finding RTDs for one way handoff or dominant pilot. Guard zone spreads HOD QuickRepeat by sector SHOR algorithm application FER border issues Access Channel Remote Opt
Issue 0.8
July 10, 1998
Page 6
2.
2.1.
Introduction
CDMA Optimisation Overview
The RF optimisation process will necessarily happen in several stages as a network evolves: 2.1.1. Pre-Commercial
Efforts will concentrate on: System/cluster shakedown/de-bugging/datafill audit RF coverage/handoff control Neighbour lists Dropped call rate Access success rate Search window settings Hard handoff success rate
A simulated load will likely be applied to the system/cluster for some stages of the optimisation. 2.1.2. Commercial
Efforts will concentrate on: RF coverage/handoff control Dropped call rate Access success rate Hard handoff success rate Capacity 2.1.3. System Expansion
Efforts will concentrate on: Introduction of new sites RF coverage/handoff control Capacity Dropped call rate Access success rate Hard handoff success rate
Issue 0.8
July 10, 1998
Page 7
CDMA RF Optimisation 2.2. Related Documents
CDMA RF System Parameter Guideline for 800 and 1900 MHz, Prasanna Satarasinghe/Brian troup, (Nortel) 1 RF Datafill Spreadsheets 1 IS95A+TSB74 (800MHz)1 J-STD-008 (1900MHz)1 (above two documents to be combined in IS95B) 1 NOIS 2 PN Offset Planning Guide, Chu Rui Chang/Jane Wan, (Nortel) Grayson Surveyor Installation and Operation, Lynne Patterson (Nortel) 1 Nortel RF Optimizer Manual 1 Hard Handoff Deployment Tips, Datafill Verification, and Troubleshooting. David Boettger (Nortel) 4 Neighbour List Tuning Using the NeighborListTuningArray, Martin Kendall (Nortel) 1 SBS Diagnostic Logging in Commercial Networks, Martin Kendall (Nortel) 1 (BTS PeformanceData) The numbers indicate the locations at which Nortel employees may find the latest soft copies of these documents: 1.
http://47.143.131.92/groups/techapps/
(this document can also be found on this server)
2. ftp to 47.65.105.47, id: anonymous, dir: dist/80.docs 3. http://47.164.163.96:4000/root/bnr/mtx/www/homepages/2n70/2n70.html
2.3.
Scope of this Document
This document provides technical reference material to aid in the RF optimisation of CDMA systems. It also describes some tools and useful methods that have been employed by the Technology Applications Group. This document does not attempt to cover such topics as scheduling, logistics, interaction with other groups etc. 2.4. Revision History
Issue 0.1 0.2
Date 96Aug03 96Aug30
Reason for up-issue First issue, whole of document created. Extensive modifications, first release to field
Issue 0.8
July 10, 1998
Page 8
CDMA RF Optimisation 0.3 0.4 0.5 0.6 0.7 0.8 96Nov18 97April24 97April31 97Jul14 97Jul22 98June26 Minor editorial (no content change)
Remove tool dependencies. Many updates based on field experience. Correct minor mistakes Major updates on overall strategy. Capacity optimisation, initial search windows, many revisions SRCH_WIN_A/N rules, some cleanup
2.4.
Contributors
The following are the key contributors to the processes contained in this document and/or to the document itself: Remo Agostino Bill Book David Curtis Rod Djurkovic Joe Heikes Chris Jedrzycki Martin Kendall Robert Keppeler Paul Kibukamusoke Corey Krieger Mike Maragoudakis Andrew Morrison Lynne Patterson Mark Prasse Prasanna Satarasinghe 2.5. Audience
This document is intended as a guide to technical personnel wishing to write and implement CDMA RF optimisation procedures. The reader is expected to have prior knowledge of the CDMA system and RF engineering principles.
Issue 0.8
July 10, 1998
Page 9
3.
Optimisation Procedure
3.1.
Entrance Criteria
The following items represent the minimum entrance criteria for an optimisation exercise: All BTSs should have been correctly installed and calibrated. The calibration values should be entered in the datafill. The spectrum should be clear down to a level of -110dBm (800MHz) or -111dBm (1900MHz) (total power per 1.25MHz) at all locations in the service area. The network should be stable i.e. all required sectors are on the air, able to originate calls and make handoffs into and out of the sector. BSC support: Personnel should be available to carry out selector logging, parameter changes, enabling/disabling OCNS, wilting/blossoming of sectors. An up to date site database should be available in the prediction tool (e.g. Planet). All test vehicles/tools/maps etc. should be available. Data collection tools installed, GPS installed/calibrated. A PN plan should have been created and entered in datafill. Preliminary neighbour lists should have been created and entered in datafill. The optimisation exit criteria should have been defined.
3.2.
Sequence of Events Pre-Commercial
3.2.1.
The following is a basic list of items that should be addressed during an optimisation exercise on a precommercial system. Details for analysis methods will be found in later sections of the document. 3.2.1.1. First Pass: Unloaded 1. Perform datafill audit and shakedown 2. Simulated load is NOT applied at this stage (since we want to expose stray sectors) 3. Perform a full network/cluster drive while running 2 minute Markov calls and collecting mobile and selector logs 4. Optimise SRCH_WIN_A and BTS demodulation windows based on rake finger offset analysis. 5. Optimise SRCH_WIN_N/R based on offsets in Pilot Strength Measurement Messages 6. Perform the RF coverage analysis (plot: handoff state (by sectors), mobile TX, mobile RX, best finger Ec/Io, per-PN plots as necessary (best finger/any finger/PSMM occurrence))
Issue 0.8
July 10, 1998
Page 10
CDMA RF Optimisation Technology Applications Group 7. Perform dropped call analysis. Plot locations in the data analysis tool. 8. Perform failed access analysis. Plot locations in the data analysis tool. 9. Tune the neighbour lists (using automated neighbour list audit tool, dropped call/failed access analysis and candidates that came from the Remaining Set) 10. Generate the per-site Transmit Gain Adjust averages to pinpoint site problems 11. Create baseline data for the performance/trend analysis 12. Make all the necessary changes to the network 13. Use spot check drives to re-create problems and validate changes 14. If changes are minor, go directly to the loaded stage. Otherwise, perform a full network/cluster drive while running 2 minute Markov calls and collecting mobile and selector logs 15. Re-generate the RF coverage analysis plots (plot: handoff state (by sectors), mobile TX, mobile RX, best finger Ec/Io, per-PN plots as necessary (best finger/any finger/PSMM occurrence)) 16. Perform dropped call analysis. Plot locations on the coverage analysis plots. 17. Perform failed access analysis. Plot locations on the coverage analysis plots. 18. Create new dataset for the performance/trend analysis 19. If the coverage control changes have proved effective and the dropped call/access fail rates and/or reasons are acceptable then move on to the loaded stage. Otherwise, repeat from item 12. 3.2.1.2. Second Pass: Loaded 1. Apply simulated load and perform full network/cluster drive while running 2 minute Markov calls and collecting mobile and selector logs 2. Re-generate the RF coverage analysis plots (plot: handoff state (by sectors), mobile TX, mobile RX, best finger Ec/Io, per-PN plots as necessary(best finger/any finger/PSMM occurrence)). 3. Perform dropped call analysis. Plot locations in the data analysis tool. Pay particular attention to coverage related issues. 4. Perform failed access analysis. Plot locations in the data analysis tool. Pay particular attention to coverage related issues. 5. Create new dataset for the performance/trend analysis 6. Perform analysis of special cases that are peculiar to the system (e.g. geographic, traffic hotspots) 7. If the coverage control changes still look good, the average number of sectors per user is not excessive (2.3 or lower is a good target (soft handoff reduction algorithm will be in release 6.2 - will need to re-assess this target)) and the dropped call/access fail rates and/or reasons are acceptable then initial optimisation is complete. Otherwise, make all the necessary changes to the network and repeat from item 1. 8. Complete the performance/trend analysis
Issue 0.8
July 10, 1998
Page 11
CDMA RF Optimisation Technology Applications Group In addition, many special cases will be encountered during optimisation. Procedures for some these will be added to this document in due course. However, there will always be specific issues that can only be solved through a thorough knowledge of the product, IS-95/J-Std-008, the air interface etc. 3.2.2. Commercial
This topic will be covered in a separate System Performance Maintenance Guide but the key points are: Use the MTX OMs and BTSPerformanceData as trend analysis data to pinpoint problem areas. Enable unconditional SBS logging of RTD, NeighborListTuningArray and VitalData (see section 6 for analysis methods). Use unconditional SBS and BTS Diagnostic logging If particular MINs are suspect, enable a full SBS optimisation conditional logmask for those mobiles. Use drive testing as a last resort means of characterising a problem area. Use drive testing to complete the integration of new sites. 3.3. Exit Criteria
Some possible exit criteria for an optimisation exercise are: Achieving a target dropped call rate. Achieving a target access success rate. Achieving coverage over a specified geographical area. Achieving a target capacity.
Issue 0.8
July 10, 1998
Page 12
4.
4.1.
Initial System Parameters

Datafill Example
Since a significant portion of an optimisation effort is devoted to system parameters, every effort should be made to begin with a datafill that incorporates the experiences gained in other markets. The datafill given in the spreadsheets available from the Technology Applications Department will provide a solid starting point for an optimisation effort for a new system. 4.2. Types of Parameters IS-95/J-STD-008 vs. Nortel Specific
4.2.1.
It is worth noting that some parameters are defined by the standards and can be found in IS-95 or J-STD008 while others are Nortel specific and can be found in the NMIS documents. All RF related datafill parameters are explained in the CDMA RF System Parameter Guideline for 800 and 1900 MHz. 4.2.2. Global/Sector Specific/BSC/BTS
The distinction between these definitions is important and not necessarily obvious: Global parameters apply to the whole system (one BSC/MTX) Sector specific parameters apply to specific sectors. If a mobile is in soft handoff with two sectors containing different values for a given parameter, there are parameter-specific rules for which value will be used: 1. 2. 3. 4. 5. 6. For SRCH_WIN_A the SBS will send the widest value. For SRCH_WIN_N the SBS will send the widest value. For SRCH_WIN_R the SBS will send the widest value. For T_ADD, T_DROP the SBS will send the lowest (most negative, e.g. -12 and -13 will result in -13). For T_TDROP, the SBS will send the maximum value. For T_COMP, the SBS will send the minimum value.
See below for current limitations on per-sector parameters. Some values are repeated at the BTS and BSC: Values in the BTS datafill appear on the paging channel so when the mobile starts a new call, it will have the settings that it acquired from the last sector on which it was idle.
Issue 0.8
July 10, 1998
Page 13
CDMA RF Optimisation Technology Applications Group Values at the BSC apply to the traffic channel. SRCH_WIN_A, T_ADD, T_DROP, T_TDROP and T_COMP will all be sent on the Extended Handoff Direction Message according to the above rules if the SBS detects that the mobile does not have the current values (i.e. every time a handoff occurs, the SBS works out the new values according to the new active set and, if these values dont match what it last sent to the mobile, it sets the Search Included flag and sends the new values on the Extended Handoff Direction Message). Unfortunately, until the In Traffic System Parameters Message is implemented, it is not possible to update the mobiles settings for SRCH_WIN_N/R during a call. Therefore, while these may be set per sector at the BSC, the mobile will currently only use the values it gets from the paging channel. For example, a call originated in a rural cell with a large SRCH_WIN_N that is subsequently carried into a downtown cell with a smaller window setting will not update its search window until the call is released and the mobile monitors the paging channel again. Note that, since setting SRCH_WIN_A and handoff parameters at the SBS is far simpler than downloading them to the BTSs, this provides a quick means of testing new settings. For example, if there is a need to experiment with T_ADD settings on a few sectors, the following strategy can be used: 1. Use a script to update T_ADD on the required sectors at the SBS only (all shelves). 2. Assess the change (e.g. by drive testing). Note that, since the BTSs have not yet been changed, the first handoff in every call will use the old settings but every subsequent handoff will use the new setting from the SBS. This is a minor drawback when the speed of making the changes is considered. 3. Try new settings at the SBS as required. 4. When the desired settings have been established, download the BTSs with the new values. In NBSS7.0, the search windows and handoff parameters become settable at the BTS (see RF Parameter Guide). Neighbour lists are somewhat of a special case. As with other parameters, the settings at the BTS are used on the paging channel. Since the mobile is only locked to one sector at a time during idle, its neighbour search procedure will only use the neighbour list from that sector. Once on a traffic channel, the BTS neighbour list will continue to be used to until the first handoff has been completed. From that point on, the mobile will generate a composite neighbour list (up to a maximum of 20 entries) with the following priorities: 1. Any pilots that have recently been dropped from the active list but have not yet exceeded NGHBR_MAX_AGE. 2. The neighbour list as received on the most recent Neighbour List Update Message from the BSC (although any pilots from 1. above will not be repeated). Note that, even if the Neighbour List Update Message contains 20 entries, the mobile will give priority to pilots defined in 1. above so all 20 might not be used. These rules are defined in the IS95 standard. The neighbour list received from the SBS is itself a composite (up to a maximum of 20 entries) of the neighbour lists of the sectors named in the most recent Handoff Completion Message (check for the corresponding Msg/Ack sequence numbers). The following priorities are used: 1. The neighbour list of the reference pilot from the PSMM. 2. Remaining pilots are then ranked by strength as reported in the PSMM.
Issue 0.8
July 10, 1998
Page 14
CDMA RF Optimisation Technology Applications Group 3. The neighbour list of the strongest pilot in this list is then included (although any pilots from 1. above will not be repeated). 4. The neighbour list of the next strongest pilot in the list(although any pilots from 1. or 2. above will not be repeated). 5. and so on until all the pilots have been used or the list has the maximum of 20 entries. These rules are Nortel proprietary. For a neighbour list entry to be considered the same, both the PN and the extended baseid have to be the same. Therefore, it is perfectly possible to have repeated PNs as long as the baseid is different. As the neighbour list for each PSMM entry is being added, the order in which the neighbours are datafilled in the Pilot Database is preserved. Processing a PSMM: Each PN with a keep flag of 1 will be matched to a baseid by looking it up in the following order: 1. current active set 2. maintained neighbour set (i.e. limited to 20) in order it was built. 3. untruncated neighbor set (will be created "on the fly" using the NL build rules above but not stopping at 20) The first PN match will halt the lookup. 4.2.3. Setting Parameters
All SBS parameters can be changed quickly using edit commands (which may be scripted). Some BTS parameter changes may be made online from the BSM while others require a download (see RF Parameter Guide and RF datafill Spreadsheets). 4.2. PN Planning
The entrance criteria to RF optimisation include the requirement that a PN plan has already been established. Therefore, a full description of how to set to set up a PN plan for a system is outside the scope of this document. The symptoms in the diagnostic data will be explained in a later section. However, the following illustrates the possibilities for PN interference: 4.2.1. Co-PN
To avoid "Co-PN" interference with the serving cell, the minimum cellsite spacing (in km) should be: min spacing = (SRCH_WIN_A)/(2 x 3.3 x 1.2288) + 2R where R is average cell radius in region of interest and SRCH_WIN_A is expressed in chips.
Issue 0.8
July 10, 1998
Page 15
CDMA RF Optimisation Technology Applications Group Another possibility for "Co-PN" interference is if PN1 is in the mobile's neighbour list but some energy from a distant re-use of PN1 falls inside the neighbour search window. The "correct" local PN1 will be put in the active list. If the "false" PN1 subsequently becomes one of the 3 strongest multipaths, the mobile will center an active search window on it and try to demodulate it resulting in forward link interference. A third "Co-PN" possibility is if "false" PN energy arrives at the mobile that matches an active set PN that is not currently being demodulated. If the "false" PN subsequently becomes one of the 3 strongest multipaths, the mobile will center an active search window on it and try to demodulate it resulting in forward link interference. A fourth "Co-PN" possibility is if "false" PN energy arrives at the mobile that matches an active set PN that is currently being demodulated. This will only cause interference if the "false" PN energy falls inside the active window for that PN. 4.2.2. Adjacent PN
The adjacent PN is the next earliest PN in the sequence i.e. PN-PILOT_INC. Problems first occur with cellsite spacings in the "ring" defined by the following: outer radius = ((PILOT_INC x 64)/(3.3 x 1.2288)) + ((SRCH_WIN_N)/(2 x 3.3 x 1.2288)) + 2R inner radius = ((PILOT_INC x 64)/(3.3 x 1.2288)) - ((SRCH_WIN_N)/(2 x 3.3 x 1.2288)) distances (in km). If any distant pilot is interpreted as one of the pilots in the mobile's neighbour list, the local site will be added to the active list, even if not required. However, this will not cause demodulation problems unless the "false" PN becomes one the strongest three multipaths and a rake finger is assigned to it (note that, unless the mobile has already assigned a finger to that PN from the (correct) local PN, it will center it's active window on the "false" PN. Therefore, the equations above are correct in having the SRCH_WIN_N and not SRCH_WIN_A). For the mobile to actually try and demodulate a distant "false PN" that is already being demodulated correctly from a local site, that site would have to fall inside the active search window. When considering the serving cell, the distances become: outer radius = ((PILOT_INC x 64)/(3.3 x 1.2288)) + ((SRCH_WIN_A)/(2 x 3.3 x 1.2288)) + 2R inner radius = ((PILOT_INC x 64)/(3.3 x 1.2288)) - ((SRCH_WIN_A)/(2 x 3.3 x 1.2288)) Another possibility for "Adjacent-PN" interference is if PN1 is in the mobile's neighbour list but some energy from a distant site using PN1-PILOT_INC falls inside the neighbour search window. The "correct" local PN1 will be put in the active list. If the "false" PN1 subsequently becomes one of the 3 strongest multipaths, the mobile will center an active search window on it and try to demodulate it resulting in forward link interference. 4.3. Initial Neighbour List Generation
The Nortel RF Optimizer contains a feature (the Natural Neighbors) to generate an initial neighbour list based on latitude/longitude/azimuth.
Issue 0.8
July 10, 1998
Page 16
CDMA RF Optimisation Technology Applications Group Alternatively, the initial neighbour lists for a new system or portion of a system can be generated as follows: 1. In the prediction tool, generate a best server Ec/Io plot. 2. For each sector, create a neighbour list consisting of the sectors with which it shares a common boundary. 3. Prioritise the list according to the boundary length and traffic patterns such that the most likely transitions are earlier in the list. Do not be tempted to add more distant sites to the neighbour list just in case. The objective is to keep the neighbour lists to the minimum length and hence reduce search times (see section 6.7. on neighbour list data analysis) 4.4. BTS Calibration
Some of the datafill values are outputs from the BTS calibration process (e.g. TXAttenNormal, BTS to RFFE cable losses). Ensure that these are present in the datafill before optimisation commences.
Issue 0.8
July 10, 1998
Page 17
CDMA RF Optimisation 4.5. Search Windows
Initial search window settings for both the BTSs and mobiles can be estimated based on cell site radii in a given area. The following table gives the datafill, maximum delay and corresponding distance for various window sizes: Window size (chips) 14 (+7) 20 (+10) 28 (+14) 40 (+20) 60 (+30) 80 (+40) 100 (+50) 130 (+65) 160 (+80) 226 (+113) Datafill Value 4 5 6 7 8 9 a b c d Max Delay (uS) 5.7 8.1 11.4 16.3 24.4 32.6 40.7 52.9 65.1 92.0 Distance (km) 1.71 2.44 3.42 4.88 7.32 9.76 12.20 15.86 19.52 27.57
Issue 0.8
July 10, 1998
Page 18
However, the chip sets commonly used in current handsets cannot search infinitely fast. Setting the search windows too small will not result in a worthwhile speed improvement and may risk missing some important signal energy or a new neighbour. The following table gives the acceptable search window combinations:
Active/Candidate Search Window (SRCH_WIN_A) (chips) 10 Neighbour Search Window (SRCH_WIN_N) (chips) 20 28 40 60 80 100 130 160 226 No No No No No No Yes Yes Yes No No No No No Yes Yes Yes Yes No No No No No Yes Yes Yes Yes No No No Yes Yes Yes Yes Yes Yes No No Yes Yes Yes Yes Yes Yes Yes No No No Yes Yes Yes Yes Yes Yes 14 20 28 40 60
4.5.1. SRCH_WIN_A, AccessChannelDemodulationSearchWidth, TrafficChannelDemodulationSearchWidth SRCH_WIN A only has to allow for the difference in arrival time of multipaths from the same sector. Assume we want to capture multipath components that are within 10dB of the main path and assume a propagation exponent of 3.5. If the cell radius is R then a multipath component will be 10dB down when it travels a distance D such that: 35 * log10(D/R) = 10 or D/R = 1.93 The extra distance the signal must travel is therefore 0.93R. Therefore, the system can be divided into two or three groups of similar cell sizes and a representative cell radius chosen for each group. For example, for R = 2km, the multipaths must travel 1.86km extra and since 1 chip represents 0.244km, the half-width of the window should be 1.86/0.244 = 7.6 chips and hence the full window width should be at least 15.2 chips.
Issue 0.8
July 10, 1998
Page 19
CDMA RF Optimisation Technology Applications Group The setting for SRCH_WIN_A can be obtained from the table above. The next highest setting above the one calculated is 20 chips. The BTS demodulation windows are set in 1/8th chip units i.e 15.2 * 8 = 121.6. However, the smallest increment that the CSM searches is 125 1/8th chip units so the settings should always be multiples of 125 i.e. 125 (for this example), 250,375, 500, 625 etc. 4.5.2. SRCH_WIN_N, SRCH_WIN_R
Since SRCH_WIN_N has to allow for the difference in arrival time from different BTSs, the setting for a given sector can be established by measuring the distance to the most distant cell in the neighbour list. E.g. for a cell to cell distance of 8km, the half-window is 8/0.244 = 32.8 chips, the full window would be 65.6 chips so the next highest setting of 80 chips would be required. Remember, though that SRCH_WIN_N cannot be updated during a call so allowance should be made for mobiles establishing a call with a particular setting and then moving to an area of larger cell spacings (i.e. if in doubt, use a higher setting on smaller cells that are adjacent to an area of larger cells). The remaining set search is used to find stray pilots and missing neighbours so a good setting for SRCH_WIN_R is to use the next setting above the SRCH_WIN_N. 4.5.3. AccessChannelAcquisitionSearchWidth, TrafficChannelAcquisitionSearchWidth
The AccessChannelAcquisitionSearchWidth sets the greatest distance at which an origination can be made from a sector. It is the only window that is not centered but it, in a similar manner to the Round Trip Delay calculations, it does need to allow for the out plus return time. E.g. if access attempts are expected up to a 15km radius, the pilot channel takes 15/0.244 = 61.5 chips so the mobiles timing will be set accordingly. When it sends in an access probe, there will be a further 61.4 chip delay coming back to the BTS so the total window needs to be 122.8 chips or 983 1/8th chip units (likely rounded up to 1000). Until further notice, TrafficChannelAcquisitionSearchWidth should be set equal to the AccessChannelAcquisitionSearchWidth. 4.6. Neighbor Configuration File, Setneighbor and Checkneighbor
RF datafill that needs to be consistent between SBS shelves or between SBS and BTS can be held in the Neighbor Configuration File (NCF). The Setneighbor and Checkneighbor commands at the BSM will then apply or verify the datafill end ensure consistency between subsystems. Some RF Optimizer features make use of the NCF file. The following datafill can be held in the NCF file: PILOT: Number between 0 and 511. MANDATORY NEIGHBORS: Comma list of keys describing each of the neighbors. BTS_NEIGHBORS: Comma list of keys describing each of the neighbors of the BTS. If this is column is not defined, the BTS neighbors are set by the NEIGHBORS field. This list has three items for each neighbor: key, neighbor config value, and priority. It appears as the following with KEY1 having a config value of 1 and priority of 2: KEY1, 1,2,KEY2,3,4
Issue 0.8
July 10, 1998
Page 20
CDMA RF Optimisation Technology Applications Group The BTS neighbor list will use the NEIGHBORS column if either this column is not present or this list is empty for this entry. This field is optional. BORDERTARGET: Comma list of target cells for Border handoffs. BEACONTARGET: Comma list of pairs target cells and pilot pns for Pilot Beacon handoffs. This following example has 3 targets, 2 with the PILOT_PN of 251, 251,KEY1, 200, KEY2, 251, KEY3 EHHOTARGETCELL: Comma list of target cells for EHHO. CELLTYPE: Enumeration Standard, Pilot_Beacon, EHHO, and Border. QUICKREPEAT: True or False for quick repeat. FORWARDGAIN: Numeric value describing the forward gain. BorderRefPilotRTDThresh: RTD delay to trigger border handoff. EHHOFERMAXFWD: Trigger for EHHO. EHHOFERMAXRVS: Trigger for EHHO. EHHOFERMODFWD: Trigger for EHHO. EHHOFERMODRVS: Trigger for EHHO. EHHOTCGMAX: Trigger for EHHO. EHHOEBNOMAX: Trigger for EHHO. EHHOWINDOWSIZE: Size of EHHO Window. CAPACITYTHRESHOLD: Numeric value for capacity threshold. FREQUENCYPRIORITY: Numeric value for frequency priority. T_ADD: Numeric value for adding pilots. T_DROP: Numeric value for dropping pilots. T_TDROP: Numeric value for drop timer value. T_COMP: Numeric value for comparing pilots. T_ADD_OFFSET_A: Numeric value of add offset. T_ADD_OFFSET_B: Numeric value of add offset. T_DROP_OFFSET_A: Numeric value of drop offset. T_DROP_OFFSET_B: Numeric value of drop offset. T_TDROP_OFFSET_B: Numeric value of tdrop offset. DELTA_3: Numeric value for difference between strongest and third pilot. DELTA_4: Numeric value for difference between strongest and the fourth pilot. DELTA_5: Numeric value for difference between strongest and the fifth pilot. DELTA_6: Numeric value for difference betweeb strongest and the sixth pilot.
Issue 0.8
July 10, 1998
Page 21
CDMA RF Optimisation SRCH_WIN_A: Numeric value for search window of active set. SRCH_WIN_N: Numeric value for search window of neighbor set. SRCH_WIN_R: Numeric value for search window of remaining set. BTS_CRM_ACNAddr: Numeric value for the CRM ACN address. NGHBR_CONFIG: BTS Neighbor configuration numeric value. SEARCHPRIORITY: BTS Neighbor search priority numeric value. MultiPilotHHOEnabled: Enable multi-pilot targets, TRUE or FALSE.
PILOTINCR: Numeric value for the pilot increment in the neighbors list.
Issue 0.8
July 10, 1998
Page 22
5.
Data Collection
5.1.
Tools Mobile Data Collection
5.1.1.
Each test van should be equipped with equipment to collect data from the test mobile(s), a compatible GPS receiver. 5.1.2. Test Van RF Configuration
Phones may simply be placed inside the vehicle or, for more repeatable results, an external antenna may be used. If external antennas are to be used, the most convenient way to configure the RF connections in the test van is to use either a car kit or a direct connection to the phone along with the external antenna. In order to produce in-car signal levels with an external antenna, attenuation must be added to the antenna connection in order to achieve the customer-specified vehicle or building penetration loss. The following table is an example of the budget that should be calculated to correctly determine the attenuator required:
Losses/Gains (dB) Antenna Gain Cable and connectors Car Kit Loss Test Van Antenna Height Attenuator Penetration Loss Total Difference
Test Van + 3.0 - 3.0 -6.0 +3.0 -7.0 0 -10.0
Real Car 0 0 0 0 0 10 -10 0dB
Ideally, the received power reading and transmit power indication of the phones used in the test vans should be calibrated. The HP8924 CDMA Mobile Tester will allow this type of measurement. Even if an exact calibration is not carried out, the various phones used in the test vehicles should be tested for consistency from unit to unit.
Issue 0.8
July 10, 1998
Page 23
CDMA RF Optimisation 5.1.3. The Base Station Manager (BSM)
The BSM runs on a UNIX platform and forms part of the BSC. Its functions include parameter setting for the BSC and BTSs, BTS software downloads and diagnostic logging. A full description of the BSM is outside the scope of this document. The assumption will be made that trained personnel are available to take SBS and BTS Diagnostic logs, change parameters and download cell-sites. 5.2. Simulating Loading
Many customers will require that any optimisation be carried out at the planned traffic loading. Beware that this may actually mask stray pilots since the Ec/Io may be less than T_ADD when loading is applied. For this reason, at least one pass through the network without loading is preferred. The following methods will allow a simulated loading to be applied approximates an even distribution of real users. 5.2.1. Forward Link
Forward link loading is achieved through OCNS (Orthogonal Channel Noise Source). The standard datafill reserves 2 channel elements per sector for OCNS. A gain setting of 120 allows 9 users per CE (18 total). Assuming the channel elements have been reserved, a script can be used to turn on OCNS very quickly (if not, a full BTS download is required). The script defines the following: Number of simulated users required. Traffic channel gain per user (this should be the gain for full rate frames - do not try and account for voice activity in this number, the OCNS algorithm will do this automatically if the OCNS gain mode has been set to Variable). Gains of 90 to 125 are commonly used.
A sample calculation for OCNS is as follows: For a particular capacity test using 1900MHz equipment, when 13 users were achieved, the average digital gain was 106 with a soft handoff overhead of 2.4 sectors per user. However, even if we want to simulate full load, this is definitely not how OCNS should be set up since this completely fills the HPA and guarantees 100% blocking. At 1% blocking, there can only be 13 users on a sector 1% of the time so, while individual sectors in a system instantaneously have 13 users, on average the number will be much lower. 13 channels is 6.6 erlangs so on average, there will be 6.6 users per sector throughout the system and this is what we should multiply by the soft handoff overhead and set with OCNS (i.e. the average number of "links" or "connections" to a sector is 6.6 x 2.4 = 16). Finally, allowance should be made for the 2 phones in the drive test vehicle and since it will add 2 "links" to the sectors in the drive test area, the final calculation would be: Number of OCNS users = (6.6 x 2.4) - 2 ~= 14 users at a gain of 106 For a sector that is running at 1% blocking, the total output power (including overhead channels) should be approximately 65% of the total HPA power. We can therefore check the above settings generate the correct power as follows: Assuming a calibration of 254 = 4 Watts and standard overhead channel gains of pilot = 186, sync = 60, paging = 156 and PRAT=0, the power in the overhead channels is: (186/254)2x4 + (60/254)2x4 + (156/254)2x4 = 3.88W
Issue 0.8
July 10, 1998
Page 24
CDMA RF Optimisation Technology Applications Group When using variable mode, the OCNS algorithm has a built in voice activity of 0.45 (0.4 for normal voice activity plus a 0.05 factor for the power control bits - see the capacity section for an explanation). Therefore, the OCNS power is: (106/254)2 x 4 x 0.45 x 14 = 4.39W Since the full HPA power is 12.5W, the percentage is (3.88 + 4.39) x 100/12.5 = 66%. The corresponding numbers for 800MHz equipment would be: OCNS gain = 123, OCNS users = 14, pilot gain = 216, sync = 68, paging = 182, HPA = 16.8W, calibration is 254 = 4W. This also gives a percentage of 66%. Sectors requiring a lower load (either because of morphology classifications or based on existing AMPS traffic distributions) should be scaled using the number of OCNS users. 5.2.2. Reverse Link
A reverse link load can be crudely simulated by degrading the reverse link according to the following equation: Degradation (dB) = log10(1 - load) where load is the fraction of pole capacity that the system is carrying (e.g. for 50% load, the required attenuation is 3dB total). Remember to allow for the load that the test phones will generate i.e. the actual attenuation applied would be less than 3dB. Reverse link loading can be achieved by one of four methods: 1. Attenuate at the mobile (TX path only - requires that uplink and downlink are separated using duplexers). This is the Nortel preferred method and shielded boxes with attenuators for both reverse link loading and in-building penetration have been built for the purpose. 2. Attenuate at the BTS (beware that, if the attenuator cannot easily be placed ahead of the first active element, the attenuation value required will have to calculated such that the overall system noise figure is increased by the required degradation). 3. Use the internal attenuator (the wilting attenuator) at the BTS (not very accurate). 4. Do not actually degrade the reverse link but apply an offset during the data processing (not recommended since an optimistic dropped call rate will be obtained).
Issue 0.8
July 10, 1998
Page 25
CDMA RF Optimisation 5.3. Drive Test Data Required
The following sections define the log masks that should be used for the selector and mobile logging during drive testing. 5.3.1. Selector Log Mask
The following table illustrates SBS log masks that will cover most aspects of RF optimisation. Log masks with this many attributes should only be enabled conditionally (i.e. for specific mobiles as entered in the CDMA ICC table at the MTX): Attribute Name Logged on Voice/Markov calls Both Both Markov only Markov only Markov Only Both Both Both Both Both Both Both Both Both Required for Optimisation Yes Yes Yes No No Yes No No Yes No No No Yes Yes Required for Detailed Network Debugging Yes Yes Yes No No Yes Yes Yes Yes No No Yes Yes Yes Links ESN/IMSI to callid All rate FER summary for 1 call All rate FER summary for 1 call Indicates which BTS each frame was taken from Received frame rates/types Transmitted frame rates/types What
LogSBSNOISMessages LogSBSIS95Messages LogSBSMarkovData LogSBSForwardMarkov Data LogSBSReverseMarkov Data LogSBSPowerControl Data LogSBSActiveSetChang e LogSBSResourceUsage LogSBSCallAssociation LogSBSForwardLinkFE R LogSBSReverseLinkFE R LogSBSFrameSelection Data LogSBSReceivedMuxDe cision LogSBSTransmitMuxOp tion
Internal NOIS messaging Air interface messaging Expected and received rvs frame rates/types Cumulative Full and All rate Fwd FER every 20 seconds Cumulative Full and All rate Rvs FER every 10 seconds Ew/No setpoint and fwd traffic chan gain per frame New active set with baseids
Issue 0.8
July 10, 1998
Page 26
CDMA RF Optimisation LogSBSRound TripDelay LogSBSForwardTrafficF rameData LogSBSReverseTrafficFr ameData LogSBSNeighborListTu ningArray LogConfigData LogSBSForwardFrameE rasureIndicatorBit LogSBSVitalData Both Both Both Both Both Both Both Yes No No Yes Yes No Yes
Technology Applications Group Yes Only for voice quality issues Only for voice quality issues Yes Yes Yes Yes RTD from each sector logged every 10 secs Full bit content of every frame (large) Full bit content of every frame (large) PSMM content with baseids SBS parameters Fwd EIB for every frame logged every 16 secs Error strings (very useful)
Issue 0.8
July 10, 1998
Page 27
CDMA RF Optimisation 5.3.2. Mobile Log Mask
The following table should be used as a guide when setting up the log mask at the mobile data collection equipment. For a full description for using the Grayson equipment, including details on tradeoffs incurred when logging the high volume attributes, see the separate documentation available from the Technology Applications Department:
1=log 0=no log 0 0 0 0 1 1 1 1 1 0 0 1 0 0 1 0
Field
Description
Not used AGC Val and Closed Loop Pwr Ctrl Not used Rev Link Frame Rates and Types Access Channel Msgs Rev Link Traffic Chnl Msgs Sync Channel Msg Entry Paging Channel Msg Entry Fwd Link Traffic Chnl Entry Fwd Link Frame Data Rev Link Frame Data Temporal Analyzer Finger Obsolete TA Searcher Data ETAK Position and Speed Markov Frame Rate Data TA Searcher Data Reverse link data transmitted. All access channel messages sent. All rvs Traffic Channel messages sent. All Sync Channel messages sent. All Paging Channel messages recd. Fwd Traffic Channel messages recd. Vocoder rate and data, forward link. Vocoder rate and data, reverse link. Searcher finger offset and power. Searcher data (not used). Lat, long and speed from ETAK. Markov rate and error data. Searcher data (window size and position, pilot offset, signal energy measured, etc.). Power control data for CD3000
0 0 1 1
Not used Vocoder Err Mask FM Data Access Probe Data Vocoder rate/data with bit errors detected. Analog mode data. Access probe information (seq number, probe number, RX AGC, TXGA, etc.)
Issue 0.8
July 10, 1998
Page 28
CDMA RF Optimisation 1 0 1 0 GPS Info Not used Sparse AGC Not used
Technology Applications Group Latitude, longitude, speed, heading, time from the GPS receiver.
AGC and Closed Loop Power Control for QCP800/1900
5.4.
Drive Testing Shakedown
5.4.1.
Drive to each cell in the system and perform the following: Phone 1: Keep Markov call up (or start as the site is approached if its the first site youre testing) 1. as site approached, confirm handoff into site 2. if sectored, drive a complete circuit around the site and confirm handoff to all sectors 3. check that that the TX gain adjust is approx -10 to -20 when close to each sector 4. as you leave the site, confirm radius (RX power is sensible). Phone 2: On each sector, power down the phone, power up again, confirm a call can be originated and then release that call. Since the log is active (see below), this will capture sync, paging, call origination and tear down (make sure some idle time is captured on all sectors of a sectored site). Mobile Logging: As you leave one site and head for another, stop the van somewhere in the soft handoff region and save the logs for both. Start new logs for both phones and continue to next site (i.e. For each phone, there will be one log per site). See section 6.2.2. for shakedown data analysis. 5.4.2. 5.4.2.1 Drive Routes Drive Route Selection
Using the coverage area predicted by the design tools, drive routes should be established throughout the area with emphasis placed on main streets and highways where customer traffic is expected to be high. The coverage area can be divided into regions and for each region the drive routes specified and written down. Each time a route is driven, it should be driven in exactly the same direction, from the same start point to the same end point. Each route should be given a name or number which was recorded on the mobile log sheet when the route is driven and the written log is included in the log book for easy reference during data analysis. During the drives, deviations from the routes such as detours and street closures should be noted on the log sheets by the drivers.
Issue 0.8
July 10, 1998
Page 29
CDMA RF Optimisation 5.4.2.2. Benchmark Route
A Benchmark Route can be a useful means of assessing network performance and consistency without the need for a full network drive. It should take the form of a single loop that is selected to stay well within the coverage area and to pass through the various clutter types available in the network. The Benchmark Route should take about one to two hours to drive under normal driving conditions. It should be driven each time a change is made to the network. The data from the Benchmark Route can be compiled and analysed to look for trends in network performance. 5.4.2.3. Driving with only one cluster of cells on air Should be used with care - need all the neighbours of the cells you are driving to be active and probably at least one more tier of cells beyond that - even then will miss some interference problems. If data has been collected on a small cluster, the following analysis can be performed: Datafill audit/shakedown Per-site TX gain adjust SRCH_WIN_A
If conducted on a cluster, the following will have to be repeated when surrounding cells are active: Coverage/handoff control Neighbour list analysis SRCH_WIN_N/R Detailed dropped call analysis 5.4.3. Test Calls
With the exception of hard handoff borders, aAll testing should be conducted using Markov calls. If two phones are used one phone can carry calls for approximately 10 mins duration but at least one phone should make short calls (e.g. 2 mins). Do not attempt to re-establish a call immediately following a dropped call. A wait period of, say, 1 minute should be used. 5.4.4. Logging
See "SBS Diagnostic Logging in Commercial Networks" for additional information. 5.4.4.1. Data Collection Restrictions Selector logfiles are collected on the cards (not on the BSM) and are restricted to 0.5Mbytes. Also, if there are, say, two selector shelves (twelve cards each for a total of 24) and only a single phone making many calls, each time a call was originated, it would be assigned to the next available selector card and the assignments would alternate between the two shelves. A single phone operating on a particular selector card with the SBS log mask given earlier will fill the data buffer with information in about 16 minutes. If the data logging buffer becomes full on a selector card, the behaviour depends on how the log was initiated, but in any case, some data loss guaranteed (even with continuous mode).
Issue 0.8
July 10, 1998
Page 30
CDMA RF Optimisation 5.4.4.2. Logging Strategy
To avoid overflowing the data buffer, mobile calls should be limited to around 12 to15 minutes. After this time, the call would be terminated and another call originated (but the same logs should be kept open), this second call would occupy a different selector card and 15 more minutes of data can be collected. Obviously, this only applies to the phone making the long Markov calls, the other phone is already making short Markov calls so its logging load will be spread among the selector cards. Also, to avoid losing large amounts of data due to logging failures, a 30 minute logging period should be imposed on the data collection process. The following is an example of a strategy that will reduce the risk of filling selector buffers: At the BSC: 1. Start logging on the hour 2. Stop log at 25 minutes after the hour 3. Upload logs and put in the appropriate date/run directory 4. Start logging at half past the hour 5. Stop logging at 55 minute past the hour 6. Upload logs and put in the appropriate date/run directory 7. (and so on...) In the test vans: 1. Start logging on the hour 2. Start long Markov call on one phone 3. Start making short Markov calls on second phone 4. At 12 minutes past the hour, terminate the long call and re-establish (do not stop the log) 5. At 24 minutes past the hour, terminate calls on both phones 6. Stop log at 25 minutes after the hour 7. Save logs, tidy up written logs and prepare to re-start logging 8. Start logging at half past the hour 9. Start long Markov call on one phone 10. Start making short Markov calls on second phone 11. At 42 minutes past the hour, terminate the long call and re-establish (do not stop the log) 12. At 54 minutes past the hour, terminate calls on both phones 13. Stop log at 55 minutes after the hour 14. Save logs, tidy up written logs and prepare to re-start logging 15. (and so on...)
Issue 0.8
July 10, 1998
Page 31
CDMA RF Optimisation Technology Applications Group Note, while every effort should be made coordinate with the SBS logs, it is not critical if the mobile logs are shorter or longer by a few minutes. 5.5. Drive Test Data Management
Abbreviations used in this section. The abbreviations used in the file names in this section should be interpreted as follows. yy: the year mm: the month dd: the day nn: the run number MMMM: the MIN number of the phone tttt: the time (GMT) in minutes and seconds cc: the cluster RUN: the word "run" appears explicitly in the file name 5.5.1 Data Transfer and Tracking Due to the large amount of data that will be accumulated during optimisation, logging and tracking each data file is crucial. An example naming convention is as follows: Selector logs: MMMMccrr.sbs Mobile logs: MMMMccrr.mbl Additionally, a directory structure that includes the date should be considered mandatory. Text description files of the test conditions, purpose etc. should also be placed in the relevant directories.
5.6.
Unconditional SBS Logging of Live Users
5.7.
BTS PerformanceData
Issue 0.8
July 10, 1998
Page 32
6.
Data Analysis Procedures
The following sections cover general data analysis procedures for the majority of the network. Analysis of special case areas may reveal a need for slightly different settings than these overall procedures indicate. Also, bear in mind that data analysis can be divided into two major levels: 1. Macro view: This is where either plots of parameters over large portions of the network are generated or averages and trends of various parameters are considered. 2. Micro view: This includes analysis of specific events e.g. access fail/dropped call analysis as well as problems at specific locations. 6.1. Tools
(This section under major re-construction due to recent tools evolution - transition to RF Optimizer within Nortel). 6.2. Datafill Audit and Shakedown Datafill Audit
6.2.1.
Examine the configuration files for all BTSs and the BSC and make sure the expected RF parameters are in place correctly. 6.2.2. Shakedown Data Analysis
Generate mobile message text files from the shakedown runs and, for each sector, examine the parameter settings in the Sync Channel Message, System Parameters Message, Extended System Parameters Message, Access Parameters Message and make sure the expected parameters are in place correctly. Also, examine the Neighbour List Message and confirm that the neighbour list is correct (remembering that this is only used for idle handoff). The Nortel RF Optimizer automatically generates Shakedown reports. 6.3. System Access Access Failure Analysis
6.3.1.
Since at least one of the phones in the test vehicle is making many short calls, useful data on access attempts is available. If the radio link fails prior to the mobile sending the Service Connect Complete Message then it is considered a failed access attempt. Tools such as RF Optimizer will automatically identify the timestamps of access failures. Using the mobile message text files, message flow files and parametric files, classify the failures into one of the following categories: 1. Access probes exhausted (not received by system) 2. Access probes exhausted (seen by system but ack not reaching mobile) Issue 0.8 July 10, 1998 Page 33
CDMA RF Optimisation Technology Applications Group 3. Ack received by mobile but Channel Assignment Message not seen 4. Channel Assignment Message seen at mobile but mobile does not acquire forward traffic channel 5. Mobile acquires forward traffic channel but system does not acquire reverse tch 6. System acquires reverse traffic channel but forward ack does not reach mobile 7. Forward ack reaches mobile but reverse ack does not reach system 6. System receives reverse ack but Service Connect Message is not seen at mobile. Reverse link message failures are likely due to coverage problems. Forward link message failures are likely due to the mobile being restricted to one pilot during access (any other pilots are effectively interferers). RF Optimizer will map the locations of access failures. Check that reverse link failures are not happening in areas of solid coverage (suspect a problem at one of the sites if this appears to be the case). Forward link access failures are likely to happen in areas where multiple pilots are seen. If it seems to be happening in isolated coverage, suspect a problem at the site. 6.3.2. Access Success Rate
Once the relevant OMs are in place and a system is carrying live traffic, the access success rate reports can be produces as required. However, measuring the access success rate on a precommercial system can only be done using drive test data. Use the total call attempts from data for all phones for an entire network/cluster drive. Eliminate any access failures that should not count in the total (e.g. drive routes that are clearly out of coverage, sites not in service due to datafill error etc.) Use the remaining failures and the total call attempts to calculate the access failure rate.
6.3.3.
Access Parameter Tuning
(INIT_PWR, NOM_PWR, MAX_REQ_SEQ, MAX_RSP_SEQ, PWR_STEP, NUM_STEP, MAX_CAP_SZ, PROBE BKOFF, BKOFF) (Set INIT_PWR to be consistent with average TXGA - others should be at baseline datafill for now but need to be subject of a detailed test) 6.4. Dropped Calls Link Supervision
6.4.1.
The link supervision algorithms define the criteria for dropping a call. 6.4.1.1 Mobile The mobile will autonomously release the call if 250 frames are received without 2 consecutive good frames (i.e. every 2 consecutive good frames resets a 5 second fade timer).
Issue 0.8
July 10, 1998
Page 34
CDMA RF Optimisation Technology Applications Group Additionally, the mobile will disable its transmitter if 12 consecutive erasures are received and will reenable it when 2 consecutive good frames are received. 6.4.1.2 SBS The SBS will autonomously release the call if 250 frames are received without 2 consecutive good frames (i.e. every 2 consecutive good frames resets a 5 second fade timer). The SBS will autonomously release the call if no acknowledgement (either an Ack or a Handoff Completion Message) is received to a Handoff Direction Message within 5 seconds. The Handoff Direction Message will be re-tried 6 times. Additionally, if QuickRepeat is enabled, each of these re-tries is composed of 3 repeats i.e. a grand total of 18 repeats of the same message. 6.4.2. Analysis
Dropped call analysis can consume a considerable amount of time. Custom scripts or tools such as Nortels RF Optimizer will identify and timestamp calls which ended prematurely. Through inspection of the mobile message logs and parametric data, the root cause of some of the drops can be determined without the need to use the selector logs. However, most of them will need deeper investigation involving the SBS message files, the message flow files and parametric files (possibly after re-processing at 20mS resolution). While chapter 7 of this document attempts to provide a step-by-step approach to dropped call root cause analysis, there is no substitute for thorough knowledge of the air interface and IS-95. If the radio link fails after the mobile sends the Service Connect Complete Message then it is considered a dropped call. Using the symptoms described in chapter 7, separate the dropped calls into the following categories: 1. Coverage related 2. Optimisable e.g. slow handoff, search window, coverage control, PN plan related. 3. Equipment problems (e.g. hardware failures, backhaul interruptions). 4. Hardware or software design related problems. Examine the location for all of the category 1. failures. Check that this type of dropped call is not happening in areas of solid coverage (suspect a problem at one of the sites if this appears to be the case). If service is required in an area not currently covered, it may be possible to extend the range of existing sites through antenna orientation or type changes, otherwise, an additional site will be required. For category 2., apply the solutions described in chapter 7 for the different types of dropped calls. The message flow file containing messages logged at both the mobile and SBS is particularly useful here. Category 3. problems should be referred to the appropriate maintenance team. Category 4. problems should be communicated to the development teams through the SR (Service Request) process.
Issue 0.8
July 10, 1998
Page 35
CDMA RF Optimisation 6.4.3. Dropped Call Rate
Tools such as Nortels RF Optimizer will automatically generate dropped call statistics based on the actual number of test calls. If the long calls are to be used, the following method can be used to avoid skewing the data: In conjunction with the customer, decide on an average call duration (e.g. 100 secs) that will be used in the calculations. Use the total call time output from the data analysis tool and calculate the number of equivalent calls using the average call duration. Data for all phones for an entire network/cluster drive should be used. Eliminate any dropped calls that should not count in the total (e.g. drive routes that are clearly out of coverage, sites not in service due to datafill error etc.) Use the remaining drops and the total equivalent calls to calculates dropped call rate. RF Coverage/Handoff Control
6.5.
Controlling the coverage area of individual cells is the single most important aspect of CDMA RF optimisation and is crucial to good CDMA performance. Much has been written about the elimination of frequency planning in CDMA. All this really means is the loss of one degree of freedom for interference control. Antenna patterns, orientations and tilts are the main tools used to confine cells to their intended coverage area and create a dominant server wherever possible. Very careful thought should be given to the choice of antenna type in terms of beamwidth and built-in electrical downtilt. Downtown (and probably suburban) areas will often need downtilts well in excess of 6 deg so this would be a good choice of electrical downtilt in many instances. The beamwidth should be consistent with maintaining a good coverage pattern at these tilt levels. This will be especially true for sites designed to give in-building coverage. Note, however, that over-covering an area, either to achieve in-building coverage or because of capacity reasons does not by itself cause pilot pollution. If these steps are not taken, the system will be prone to the following Pilot Pollution related problems: Slow handoff dropped calls: Since, for a given SRCH_WIN_A setting, the number of active pilots has a big influence on search time, there is an increased chance of a new, strong pilot not being detected quickly enough. This is made worse by the fact that, in high handoff areas, the pilot Ec/Io values are typically very low (because of the high Io). For example, if the mobile is in 4-way handoff in a loaded system, the active pilot Ec/Io values could all be around -13dB. When a new pilot crosses T_ADD at, say, -14dB, it is already nearly equal to the active set pilots. By the time the phone has filtered the measurement, sent a Pilot Strength Measurement Message and the SBS has queried the BTS for resources, the new pilot may be causing so much forward link interference that the Handoff Direction Message fails to reach the mobile.
Issue 0.8
July 10, 1998
Page 36
CDMA RF Optimisation Technology Applications Group Window related dropped calls: If pilots are being seen some distance outside their intended coverage area, dropped calls may results for two reasons. 1) If that pilot is strong enough to cause interference to a call in progress, but the mobiles timing reference is from a local cell, the distant pilot will be outside SRCH_WIN_N and hence it will not be added to the active set and the call may drop. 2) If the mobile originates on the distant site and hence uses it as its timing reference, the local sites will be invisible if they are outside SRCH_WIN_N and the call will drop as soon as one of the local sites becomes strong. Note that it is unlikely that the mobile will switch its timing to the distant site while on a call since this would require that no rake fingers be assigned to any of the local sites. Poor Capacity: 4, 5 and 6 way handoff can be beneficial in many instances where there are many pilots with no dominant server or in a rapidly changing environment. In these cases, the pilots not currently being demodulated serve as hot standbys to which rake fingers can be assigned very quickly. This can be very important in maintaining a call in a difficult environment. However, in order not to compromise capacity (both forward and reverse link), every effort should be made to ensure that this is the exception rather than the rule. Also, since the mobile only has three rake fingers, if there are, say, 4 equal pilots, the mobile will assign 3 fingers to 3 of them, leaving the 4th as an interferer. This will require a higher forward power allocation to overcome this interference and hence lower capacity.
The following three sections describe how to load survey data into a mapping tool to generate plots that will indicate which sites are candidates for antenna changes. The source data used should represent one entire drive of the system/cluster: 1. Generate files containing lat/long and handoff state (by number of sectors - not channel elements). Use 6 colours to identify the number of sectors involved and generate one plot for the entire system/cluster. (The Nortel RF Optimizer can generate these plots automatically). 2. Generate files containing lat/long and the Ec/Io of the best finger. Suggested settings are -16 to -8 with a step of 2. Generate one plot for the entire system/cluster. (The Nortel RF Optimizer can generate these plots automatically). 3. After studying the above plots, create a list of sectors which are possible contributors to the high handoff or poor Ec/Io areas. For each of these sectors, the idea is to generate a plot for that sector alone showing where that pilot is appearing. Three types of per-pilot plots can be used; strongest rake finger, any rake finger, any occurrence in a PSMM. The value to be plotted is the Ec/Io. Suggested settings are -16 to -8 with a step of 2. Generate plots for one sector at a time. (The Nortel RF Optimizer can generate these plots automatically). 4. Generate files containing lat./long and mobile transmit power. Suggested colour settings are: less than 13dBm = green, 13 to 18dBm = orange, 18 to 23 dBm = red. Generate one plot for the entire system/cluster. (The Nortel RF Optimizer can generate these plots automatically).. Analysis of these plots is somewhat subjective but the general procedure is as follows: The handoff state and overall Ec/Io plots should be used as an indicator of the worst case areas for excessive handoff and interference. In areas of high handoff (4, 5 and 6 way), examine the perpilot plot for each sector in that area and determine whether each pilot is intended to provide coverage in that area. The three types of per-pilot plot (strongest rake finger, any rake finger, any occurrence in a PSMM) will show progressively greater coverage area for a given pilot so some experimentation will be required to find the clearest picture.
Issue 0.8
July 10, 1998
Page 37
CDMA RF Optimisation Technology Applications Group If the problems occur along the main beam of the antenna, a downtilt alone should be sufficient. If there are problems along the edge of the antenna beam, also consider a narrower beamwidth antenna and/or a re-orientation. Do not try to remove signal from areas where the mobile transmit power is above 18dBm (red) since these are the areas where high handoff is actually helping to maintain the call. To help decide on the exact changes, use single cell signal plots in Planet and experiment with antenna changes. A signal level reduction that will get the offending pilot below T_ADD should be calculated and applied before re-driving the area (see appendix 9.5 for an example calculation). Beware that, as unwanted pilots are removed from an area, the Io is being reduced and so the next drive of the area may reveal new problem pilots, making this somewhat of an iterative process. The data for these plots is best taken without any forward link loading since this will raise the Ec/Io levels throughout the system and expose pilots that might not otherwise be seen. After the coverage of the individual sites has been correctly adjusted using the procedures in the above section, further reduction of handoff should only be contemplated in very unusual circumstances. 4, 5 and 6 way handoff can be beneficial in many instances where there are many pilots with no dominant server or in a rapidly changing environment. In these cases, the pilots not currently being demodulated serve as hot standbys to which rake fingers can be assigned very quickly. This can be very important in maintaining a call in a difficult environment. A majority of 2-way mixed with some 1-way (no handoff) and some 3-way handoff should be considered normal. An overall figure of 2 sectors per user can be considered a good target. T_ADD/T_DROP settings of -14/-16 are the recommended settings at this time for the following reasons: These values have given good results in simulations and field testing to date, particularly with respect to dropped call rate. In pilot polution areas, the Ec/Io levels of the active set pilots can be as low as -12 or -13 dB. Even with T_ADD at -14dB, a new pilot will not be detected until it is almost equal in strength with the current pilots. By the time the mobile has measured it, sent a Pilot Strength Measurement Message, the system has set up resources and sent back an Extended Handoff Direction Message, the forward link is often to poor for this to reach the mobile and he call drops. Rasing T_ADD will make this problem worse. Dropping a pilot above -16dB represents a loss of useful signal. There are other reasons to avoid arbitrary reductions in soft handoff. For example, given that the reverse link coverage has been designed assuming 4dB soft handoff gain, we can calculate (for a propagation slope of 3.5) that the last 4dB of the cell radius represents an area of 42%. Therefore, 42% of the cell area needs to be in soft handoff to ensure complete reverse link coverage. Restricting it to, say, 35% using the handoff threshold(s) (which are forward link parameters and hence somewhat independent of reverse link coverage) would be a very bad thing to do. This is a very simplistic calculation and also the cell overlap that you will always get in a real design will help a lot with the reverse link coverage but it indicates the need to think very carefully about this. More intelligent handoff algorithms are currently the subject of much discussion and field test (soft handoff reduction algorithm will be in release 6.2 - will need to re-write this section).
Issue 0.8
July 10, 1998
Page 38
CDMA RF Optimisation 6.6. Search Windows
The search sequence for mobile that has two active pilots and a neighbour list of three PNs is roughly as follows (the actual algorithm will be specific to individual handset manufacturers but this will illustrate the principle): A1, A2, N1, A1, A2, N2, A1, A2, N3, R, A1, A2, N1, The worst case search time to find a new neighbour can therefore be generalised as: Search Time = (NN x (TN + (NA x TA))) + TR Where NA, NN are the number of actives and neighbours respectively. TA, TN and TR are the search times for the SRCH_WIN_A/N/R windows. Minimising the search time is crucial to CDMA performance, both to avoid dropped calls (due to a new pilot increasing very rapidly) and to maximise capacity (any delay in adding a new neighbour into the active set means it is effectively an interferer and hence more power is required to maintain the desired FER). However, the chip sets commonly used in current handsets cannot search infinitely fast. Setting the search windows too small will not result in a worthwhile speed improvement and may risk missing some important signal energy or a new neighbour. The following table gives the acceptable search window combinations:
Active/Candidate Search Window (SRCH_WIN_A) (chips) 10 Neighbour Search Window (SRCH_WIN_N) (chips) 20 28 40 60 80 100 130 160 226 No No No No No No Yes Yes Yes No No No No No Yes Yes Yes Yes No No No No No Yes Yes Yes Yes No No No Yes Yes Yes Yes Yes Yes No No Yes Yes Yes Yes Yes Yes Yes No No No Yes Yes Yes Yes Yes Yes 14 20 28 40 60
Issue 0.8
July 10, 1998
Page 39
CDMA RF Optimisation Technology Applications Group The following table gives the datafill, maximum delay and corresponding distance for various window sizes: Window size (chips) 14 (+7) 20 (+10) 28 (+14) 40 (+20) 60 (+30) 80 (+40) 100 (+50) 130 (+65) 160 (+80) 226 (+113) Datafill Value 4 5 6 7 8 9 a b c d Max Delay (uS) 5.7 8.1 11.4 16.3 24.4 32.6 40.7 52.9 65.1 92.0 Distance (km) 1.71 2.44 3.42 4.88 7.32 9.76 12.20 15.86 19.52 27.57
The following three sections explain how to establish a search window settings that are consistent with the propagation environment within the system/cluster. 6.6.1. SRCH_WIN_A
Generate histograms of the maximum mobile finger separation for fingers locked to one pilot only. This is the basis for setting the optimum value for SRCH_WIN_A. Finger Packet Packet Size: 15 Pilot 312 312 320 Offset 0.00 1.32 0.10 EcI0 -10.61 Locked -14.38 Locked -14.28 Locked
E.g. In the above finger packet, 2 fingers are locked to PN 312 so the 1.32uS offset would contribute to the histogram.
Issue 0.8
July 10, 1998
Page 40
CDMA RF Optimisation Technology Applications Group Gather all the histogram files for one entire network/cluster run. Classify the areas by average cell size (two or three regions should be sufficient e.g. small (dense) urban cells and large suburban/rural cells) and generate an overall combined histogram for each region. Evaluate the histogram against the Max Delay column in the above table and choose a window size that will capture 95% of the finger separations. Check the shape of the histogram to ensure that the existing window setting is not already too small (i.e. is there a sharp cutoff at the current window setting). In this case, more data will have to be collected with a wider window setting before a proper judgment can be made. The Nortel RF Optimizer will perform this analysis automatically. To get an idea of the tradeoffs involved for different active search window settings, the following calculations can be performed: For an active window setting of 60 chips and assuming the window is centered on the main ray from the cellsite, a multipath component that just falls inside the window will have traveled an extra 7.3km (30 chips @ 0.244km/chip = 7.3km). For a nominal 2km radius and assuming a best case of free space path loss and no reflection loss, the multipath will be 20log(9.3/2) = 13dB lower than the main path. At the cell edge, even for an unloaded system, the Ec/Io of the main ray is unlikely to be better than -5dB which puts the multipath at -18dB i.e. marginal benefit. For a more realistic path loss exponent of 3.5, the multipath will be 35log(9.3/2) = 23.3dB lower (approx. -28.8dB Ec/Io). When we consider the larger cells and rework the numbers for, say, a 5km radius, assuming free space the multipath will be 7.8dB lower (-12.8dB Ec/Io if we continue with the 5dB Ec/Io main ray assumption) while assuming a 3.5 exponent the multipath will be 13.7dB down (-18.7dB Ec/Io). The free space value represents a useful benefit to demodulation but the 3.5 exponent value is still marginal. The corresponding numbers for a 28 chip window are as follows: 14 chips represents 3.4km so, for the 2km case, the free space multipath component will be 8.6dB down (13.6dB Ec/Io) while the 3.5 exponent multipath will be 15.1dB down (-20.1dB Ec/Io). For the 5km case, the free space multipath component will be 4.5dB down (-9.5dB Ec/Io) while the 3.5 exponent multipath will be 7.9dB down (-12.9dB Ec/Io). Clearly the 5km case could benefit from a larger active search window since components falling just outside the window would be appreciable interferers. For the 2km case, the 3.5 exponent still gives only a marginal benefit. However, the free space case would be of value but how realistic is a free space assumption? Two more aspects need to be considered before any conclusions can be drawn: 1. Search time will be substantially increased. If we take an example of 3 active pilots, 10 neighbours with a neighbour window setting of 100 chips. With an active window of 28 chips, the search time will be 0.42 secs. With an active window of 60 chips, the search time will be 0.64 secs i.e. a 52% penalty. 2. All Ec/Io values will decrease as loading increases.
Issue 0.8
July 10, 1998
Page 41
CDMA RF Optimisation 6.6.2. SRCH_WIN_N
In the Pilot Strength Measurement Messages, the mobile reports the phase of the pilots to the nearest chip resolution. Unless this pilot comes from another sector of the reference cell, there will likely be some offset from an exact PN (multiple of 64 chips). For example, in a system with Pilot_Inc = 4, a phase of 4874 is actually PN 76 + 10 chip offset and a phase of 25338 is PN 396 6 chip offset. The general formulas for converting PN_PHASE to a PN and an OFFSET are: PN = INT((PN_PHASE/(PILOT_INC * 64)) + 0.5) * PILOT_INC OFFSET = PN_PHASE - (PN * 64) Generate histograms of the offsets as described above. This is the basis for setting the optimum value for SRCH_WIN_N. Gather all the histogram files for one entire network/cluster run. Classify the areas by average cell size (two or three regions should be sufficient e.g. small (dense) urban cells and large suburban/rural cells) and generate an overall combined histogram for each region. Evaluate the histogram against the possible window settings in IS-95/J-STD 008. The histogram should be biased to the positive side (i.e. pilots delayed from the reference are more common than early arriving pilots). Remembering that the window is centered around the reference, choose a window setting that covers 99% of the offsets. E.g. if 99% of offsets corresponds to, say, 47 chips, the next highest half window is 50 chips so a window setting of 100 chips (datafill of 10) would be appropriate. Check the shape of the histogram to ensure that the existing window setting is not already too small (i.e. is there a sharp cutoff at the current window setting). In this case, more data will have to be collected with a wider window setting before a proper judgment can be made. The Nortel RF Optimizer will perform this analysis automatically. 6.6.3. SRCH_WIN_R
SRCH_WIN_R is typically set one step higher than SRCH_WIN_N. This ensures that pilots missing from the neighbour list will be captured but also allows slightly more distant stray pilots to be detected. 6.6.4. BTS AccessChannelDemodulationSearchWidth, TrafficChannelDemodulationSearchWidth Since these windows perform the same function for the BTS as SRCH_WIN_A does for the mobile, the same analysis result can be used. Say the 95% point on the histogram was 12.4uS or 15.2 chips. The BTS demodulation windows are set in 1/8th chip units i.e 15.2 * 8 = 121.6. However, the smallest increment that the CSM searches is 125 1/8th chip units so the settings should always be multiples of 125 i.e. 125 (for this example), 250,375, 500, 625 etc.
Issue 0.8
July 10, 1998
Page 42
CDMA RF Optimisation 6.7. Neighbour Lists
Remembering that every Pilot Strength Measurement Message contains a pilot which is designated as the reference pilot, the basic rules of neighbour list adjustment based on live data are: 1. Any pilot that is requested to be added in a Pilot Strength Measurement Message should be in the neighbour list of the reference pilot in that PSMM. 2. Any pilots that are currently in the reference cells neighbour list but never occur in a PilotStrengthMeasurementMessage should be removed from that neighbour list. For example, consider the following NeighborListTuningArray (the NeighborListTuningArray is simply a repeat of the PilotStrengthMeasurementMessage with extended baseid included):
Base ID ------28 221 28 28 Sector Band Class ------ ---------3 2 1 2 1 1 1 1 CDMA Freq --------50 50 50 50 Pilot Strength --------------8.50 -11.50 -17.00 -21.50 Keep Bit -------1 1 1 0 Pilot_PN -------220 192 212 216
PN 220 is the reference (since it ocurrs first in the message) so we are working on the neighbour list for that sector. PN 216 is being dropped so we do not consider it in this analysis. PNs 192 and 212 should both be in the neighbour list for PN 220. Neighbour list tuning data comes from three possible sources: 1. Dropped call/failed access analysis. 2. Pilot Strength Measurement Messages (PSMMs) from drive test data. 3. NeighborListTuningArray data logged at the selector. Item 3 is very powerful since the quantity of data far exceeds anything that could be attained through normal drive testing. Also, since the data represents actual traffic patterns, there is far less risk of making bad neighbour list decisions because of the drive test routes chosen. Finally, since the extended base id is included, PN re-use does not cause problems in the data analysis. If the conclusion reached while analysing any of the above sources is that a neighbour list entry was missing, first refer to the predictions and determine whether that pilot is intended to cover that area. If not, the problem should be remedied with antenna adjustments. Only if it is determined that a genuine neighbour list omission has been found should the pilot be added to the reference cells neighbour list.
Issue 0.8
July 10, 1998
Page 43
CDMA RF Optimisation Technology Applications Group For cases 2 and 3, generate a per-site histogram of all the handoff transitions requested by the drive test mobiles over a complete drive of the system/cluster. The reference cell determines which sectors neighbour list is being examined. Further refinement can be added by including the max, min and average Ec/Io for each entry. This is particularly useful for pilots found by a Remaining Set search since the frequency of occurrence may be low yet the strength may be high. Tuning tool sample output: KC104x, 6036: KC104y,2335,21,-8; KC104z,2705,26,-9;...; KC68y,536,5,-10; KC96z,34,0.3,11; KC208x,41,0.4,-9 The above represents the output for one sector (KC104x in this example) and that 6036 NLTA records were logged with this sector as the reference. There is one entry for every PN that occurs when KC104x is the reference pilot (it is shown here with sector designations but the tool could be made to display PNs or baseids). Each entry contains the number of times that sector is requested, the percentage that represents and the average Ec/Io. Underlined sectors are those not in the currently datafilled NL. In the above example, the first two entries are the adjacent sectors of the same BTS so they are normal entries. KC68y is likely being found through the composite NL (high hits and good Ec/Io) but should be added to KC104xs NL. KC96z should be probably removed (unless it is an immediate neighbour and it is just low traffic that is causing this characteristic). KC208x is probably being found through the Remaining Set search (low hits but good Ec/Io) and should be added if it is determined that it does not need removing from the area through RF coverage control. For each sector, examine the statistics in conjunction with the Planet equal power boundaries plot. Make sure there is adequate data for the sector. 1000 NLTA records should be regarded as the minimum for that sector to be analysed. Consider removing any pilots that are currently in the neighbour list but have been requested less than 1% of the time. If drive test data is being used, make sure that it is not a consequence of the drive routes (for example, do not remove adjacent sectors of a sectored site). Consider adding pilots that are not currently in the neighbour list but have been requested greater than 1% of the time. The above rules lead to very safe neighbour lists and will result in a system that is robust in dropped calls. Remember, though, that long neighbour lists result in longer search times to find new pilots. During these delays, a new pilot that has not yet been searched is an interferer and this will result in a higher forward power allocation from the BTS to overcome the interference. If this occurs regularly, capacity will suffer. The goal, therefore, is to keep neighbour lists to a minimum (see below) so avoid adding sites that are obviously not immediate neighbours of the serving cell (i.e. try to make use of the composite neighbour list as much as possible). The Nortel RF Optimizer contains tools to provide a much more sophisticated analysis of NeighborListTuningArray data.
Issue 0.8
July 10, 1998
Page 44
Figure 2.: Neighbour List Example Referring to the figure above, even if cell C appears as a handoff candidate in the right half of cell A (shaded), it might not be put in As neighbour list. The assumption is that, if C is a handoff candidate then B certainly will be (if this is not true, there are likely bigger problems to be addressed first). C will be in Bs neighbour list and hence the composite neighbour list sent to the mobile while in the right half of A will contain C. The advantage occurs when the mobile is in the left half of cell A since the mobile will not waste search time looking for cell C. Obviously the above diagram is very idealistic. Due to site selection issues and the topology of a real environment, many unusual cell arrangements will be found in the field. However, it illustrates the principle that, in order to reduce the search time to find new pilots, the aim should be to minimise neighbour lists. Only in exceptional circumstances (e.g. hard handoff border cells) should the BTS neighbour list be different from the pilot database at the SBS. 6.8. Performance/Trend Analysis
If multiple drives of the same drive routes are planned, or if a benchmark route is being used, the following parameters should be tracked: Average forward traffic channel gain and percent time at maximum Handoff overhead by sectors Average mobile transmit power and percent time within 5dB of maximum Dropped call rate The values of all of these measurements should reduce as the optimisation process progresses. Note that FER is NOT included as a metric. This is because we are confident that power control works and that if all other issues are addressed, good FER performance will naturally follow. Issue 0.8 July 10, 1998 Page 45
CDMA RF Optimisation 6.9. Per-Site Analysis
Analysis of data for when the mobile is locked to a single pilot can reveal configuration or performance issues related to a particular site or sector. Generate the following: 1. A file containing the average transmit gain adjust on a per-site basis for all sites in a run. This will highlight any sites having a significantly different link balance. A site with a high transmit gain adjust may be suffering from a poor receiver noise figure or may be in a location where forward link interference is prevalent. A site with an abnormally low transmit gain adjust may have a low transmit power. 2. A file containing all lines from the parametric flat file for which the number of pilots locked = 1. A column containing the PN is needed. This will allow additional performance analysis on a per-site basis e.g. FER, traffic channel gain, Ew/No setpoint, finger separation. The following table is an example output of a per-site transmit gain adjust analysis. We know from other analysis that the Whiterock (WROC) site is subject to interference from an adjacent CDMA system (hence higher TXGA). The Burnaby (BURN) site has the CDMA BTS running from the CDPD multicouplers and likely has a higher noise figure (hence higher TXGA). Subsequent investigation revealed that the transmit power was 7dB low on the GILDZ sector (hence low TXGA). All other sectors are normal (the data was collected with no load on the system, hence the low overall values).
Issue 0.8
July 10, 1998
Page 46
Pilot PN 8 60 68 76 80 84 88 92 104 116 128 136 144 148 152 220 228 248 276 308 380 388 408 412 436 468
Site LGLY WROCY NWSTY HCTR SURR KNDY PANY POCO CLOV GILDY MURR LHED PMAN BURNY HANY WROCZ NWSTZ PANZ GILDZ BURNZ WROCX NWSTX PANX COLE GILDX BURNX
Average TXGA -14.411692 -10.224532 -15.800661 -16.165448 -15.964134 -16.857579 -13.542665 -16.432903 -16.466863 -15.796377 -14.556199 -16.48573 -14.431992 -10.874728 -14.361585 -16.575031 -14.310556 -11.875561 -22.511815 -9.3749509 -10.456281 -13.104353 -12.938774 -17.127062 -14.196346 -9.9643809
The Nortel RF Optimizer will perform this analysis over many mobile logs automatically.
Issue 0.8
July 10, 1998
Page 47
CDMA RF Optimisation 6.10. Capacity
The main requirement for obtaining good CDMA capacity is to eliminate unnecessary handoff and minimise the transmit power requirements on both forward and reverse links through the following: good RF coverage control (no unnecessary handoff and interference) effective handoff ( good neighbour lists, optimum search windows) optimum power control settings maximise paging channel effectiveness maximise access channel effectiveness
6.10.1.
Capacity Equations
6.10.1.1. Reverse Link

(W / R ) fS (Eb / No ) v
N=
Where: N = theoretical number of users per sector (Pole Capacity) W/R = the ratio of spreading bandwidth to information bandwidth (i.e. the processing gain) Eb/No = the energy per bit / noise density v = the voice activity factor (VAF) f = the ratio of power received from users in this sector to power received from all users S = the sectorisation gain All values expressed in linear terms (not dB). This equation takes no account of thermal noise and so is for a sector of zero radius (100% of the processing gain is used to fight the noise of other users). To design real cells, we need to allocate some of the processing gain to fighting thermal noise. We typically allocate half (i.e. we design for 50% loading). If we measure the noise floor of a BTS receiver with no load and then apply 50% load, the noise floor will double (since we are allocating half the noise to each). This is the 3dB noise rise for 50% load. A more general equation linking noise rise and load is:
Load (%) = 100 x (1 - 10(-NR/10))

Therefore, if we can measure the noise rise that a certain number of users causes, we can calculate either pole capacity or 50% load.
Issue 0.8
July 10, 1998
Page 48
The only terms we can influence easily are f and S and since these will also be improved when we optimise the forward link capacity, all remaining discussion will concentrate on the forward link.
6.10.1.2. Forward Link Slightly different equations are used, depending on whether the data source is drive test data or BTSPerformanceData
6.10.1.2.1. From Drive Test Data
The following equation gives the potential loaded capacity of a sector in terms of the number of users with average forward traffic channel gain and typical soft handoff percentage for a system/cluster.
N=
1 - ( fPilot + fPage + fSynch ) f traff hrf v
Definitions: N = the number of average users a sector can support assuming the above conditions. fPilot = the fraction of total HPA power allocated for the pilot channel fPage = the fraction of total HPA power allocated for the paging channel fSynch = the fraction of total HPA power allocated for the synch channel ftraff = the average fraction of total HPA power allocated for one traffic channel hrf = handoff reduction factor, a calculated value which takes into account the required RF power due to different types of handoff v = the voice activity factor (VAF)
Handoff Reduction Factor (hrf): this term adjusts the average power per user based on the collected handoff statistics for the system under test where:
Issue 0.8
July 10, 1998
Page 49
CDMA RF Optimisation hrf = ( 1,1) + 2 ( 1, 2 ) + 3 ( 1, 3) +
(2 (3 (4

( 2 ,2 )
+ 3 ( 2, 3) + 4 ( 2 ,4 ) + 5 ( 2 ,5) + 6 ( 2, 6 ) 2 + 4 ( 3,4 ) + 5 ( 3,5) + 6 ( 3, 6 ) 3
( 3, 3)
( 4 ,4 )
+ 5 ( 4 ,5) + 6 ( 4 ,6 ) + 5 ( 5,5) + 6 ( 5,6 ) + 6 ( 6 ,6 ) 4
x (,) is defined as follows: = number of sources of power control bits the system is having to send to the one mobile (,) = the percentage of time the one mobile experienced this type of handoff, and = the number of cells with which the mobile is communicating = the number of sectors with which the mobile is communicating x = voice activity factor for x number of cells in soft handoff (i.e., the adjusted voice activity to account for variations in power gain of the power control bit due handoff involving x cells. = the average Markov voice activity factor for single sector coverage x = [ P( full ) 1 + P(half )0.5623 P(quarter )0.4467 1 + 2
Voice Activity Factor (VAF)
1 1 23 1 + P(eighth)0.3162 ] + p 4 8 24 24 x
= the average Markov voice activity factor for single sector coverage P(full) = the probability of a full rate frame occurring = 0.291 P(half) = the probability of a half rate frame occurring = 0.039 P(quarter) = the probability of quarter rate frame occurring = 0.072 P(eighth) = the probability of an eighth rate frame occurring = 0.598 1/2, 1/4, 1/8 = the relative power (to a full rate frame) associated to each corresponding frame 23/24 = the portion of a frame for which the relative power levels apply
Issue 0.8
July 10, 1998
Page 50
CDMA RF Optimisation Technology Applications Group 1/24 = the portion of a frame for which the power control power level applies
6.10.1.2.2.
px2 = the relative power (relative to a no handoff power control bit) given to a power control bit for the appropriate type handoff: for x=2 (for handoffs involving 2 cells), p22 = 2 for x=3 (for handoffs involving 3 cells), p32 = 3 for x=4 (for handoffs involving 4 or more cells), p42 = 4 the constants for 1/2, 1/4, & 1/8 rate frames are hard coded numbers in our loads that further reduce the power of these frame rates.
From BTSPerformanceData
The following equation gives the potential loaded capacity of a sector in terms of the number of users with average per-link power and typical soft handoff percentage for a system/cluster.
Definitions:
N=
PCallBlock - (PPilot + PPage + PSync ) PLink * SPU
N = the peak number of unique average users a sector can support assuming the above conditions. PCallBlock = the power at which new calls are blocked PPilot = the pilot channel power PPage = the paging channel power PSynch = the synch channel power Plink = the average power that one link consumes (a link is defined as every user who is either in isolated coverage of this sector or who is in handoff with this sector) SPU (Sectors Per User) = the average number of sectors that one user is in handoff with (could think of this as links per user).
6.10.1.2.3. Interpreting the Equations
The average traffic channel power gives us the average power that one link or connection to a sector will require. The handoff statistics allow us to calculate the capacity penalty due to the fact that one user will generate links to several sectors (or, equivalently, one sector will serve the actual users in its own sector as well as other users in other sectors). Finally, therefore, the equation calculates how many of these average users can be fitted into one HPA. Therefore, when we say that the capacity is, say, 13 users based on this equation, we are saying that is the peak load on the sector at 100% blocking (equivalent to all radios being used in an AMPS sector). When the system is running at 1% blocking, individual sectors will occasionally peak at 13 users but the average will be 6.6 users.
Issue 0.8
July 10, 1998
Page 51
CDMA RF Optimisation Technology Applications Group Note that, unlike a wireline application, the 13 users are not independent channels and this number is influenced by the average load on the system, in this case 6.6 users (Erlangs). Therefore, it would be erroneous to decide to run a system at 5% blocking and use the Erlang B table to establish that 8.8 Erlangs could be carried. If there are, on average, 8.8 users on each sector then, due to the extra interference in the system, the peak available will be less than 13. Therefore, 8.8 Erlangs/5% blocking is not a valid combination. Likewise, as the average load decreases below 6.6 Erlangs, the blocking will reduce faster than the Erlang B table would suggest.
6.10.2.
BTS Operation
Before explaining some of the adjustments that can be made to optimise capacity, it is necessary to understand some aspects of BTS operation. Refer to the table at the end of this section (1900MHz BTS illustrated - Nortel employees can retrieve this spreadsheet from the Technology Applications webpage server and experiment with different settings). The BTS forward link has two domains; the digital domain and the analogue domain. The digital domain refers to algorithms involving the digital gains that control the output level of each Channel Element. The analogue domain refers to the total BTS output power as measured at the RFFE Antenna 0 on the 1900MHz equipment or the Demarc panel on 800MHz equipment and controlled by an attenuator in the upconverter. The fully blossomed value of this attenuator is controlled by a datafillable parameter TxAttenNormal. (Need a diagram here to illustrate above) 6.10.2.1. BTS Calibration The two domains are linked at calibration time by enabling a single channel element at full gain of 254 (not 255 since the CEs can only take even values because the LSB is fixed at 0). The output power is then adjusted using TxAttenNormal until an output power of 4 Watts is obtained (note that this is NOT the pilot setting since the pilot is actually run at a lower gain i.e. we are NOT calibrating for a 4W pilot). Once this relationship has been established, we can calculate the power equivalent to any gain or combination of gains. Example; what is the output power for a) the pilot and b) the pilot + sync + paging if the digital gains are pilot = 186, sync = 60 and paging = 156. Answer; Since the digital gains are voltage gains, most calculations are in terms of bits squared to convert to power. Therefore, if 2542 = 4 Watts, the power corresponding to 186 is: power = (1862/2542) x 4 = 2.14 Watts and the power for all three channels is: power = ((1862 + 602 + 1562)/2542) x 4 = 3.88 Watts
Issue 0.8
July 10, 1998
Page 52
CDMA RF Optimisation Technology Applications Group The Transmit Power Tracking Loop (TPTL) is provides a guaranteed linkage between the analogue and digital domains since it constantly maintains the 2542 4Watts relationship. This is achieved using a feed back loop that sums up the current digital gains for all overhead, traffic and OCNS channels, calculates the expected output power and compares it to the analogue sensor reading. If the two do not match, an offset (TPTLOffset) is applied to the upconverter attenuator. Note that accurate calibration is still required since the TPTL will not apply more than +/-6dB of correction. However, great emphasis must be placed on confirming the sensor accuracy since TPTL relies on its readings. TPTL is in release 6.1.1 for 1900MHz and 6.3 for 800MHz.
6.10.2.2. The Digital Domain, Forward Power Control and the Forward Blocking Thresholds The power output of any channel element is controlled by a digital gain. The overhead channels are fixed values datafilled at the BTS on a per-sector basis. The traffic channels vary within a defined range as required by forward link power control. The range for the traffic channel gains is datafilled relative to pilot power. For example, with a pilot gain of 216, an upper limit of -1dB pilot and a lower limit of -15dB pilot, the selector will send digital gains in the range 192 to 38. Note that the pilot gain is datafilled both per-sector at the BTS and as a global parameter at the SBS. It is the SBS value that is used to calculate the digital gains for the traffic channel. Therefore, even if the pilot gain at one sector of a BTS is lowered by, say, 1dB to 192, the SBS will continue to send digital gains in the range 192 to 38. I.e., for this sector alone, the traffic channels are now effectively 0dB pilot to -14dB pilot. The forward link Call and HandoffBlockingThresholds are datafilled in terms of ExcessForwardLinkCapacity which is a bits-squared value. ExcessForwardLinkCapacity is calculated as follows: 1. Square the pilot gain (e.g. 1862 is 34596) 2. Divide by MinPilotToTotalPowerRatio (e.g. 34596 divided by -7.5dB (in linear terms) is 194547). Call this number the blocking threshold reference. 3. Sum up the bits-squared over all channel elements 4. Subtract item 3. from item 2. The result is the ExcessForwardLinkCapacity. If the ExcessForwardLinkCapacity is less than the FwdCallBlockingThreshold, then block new calls. If the ExcessForwardLinkCapacity is less than the FwdHandoffBlockingThreshold, then block handoffs. The table shows how these numbers translate to actual powers in Watts. Note that there is no action if the blocking threshold reference is crossed although ExcessForwardLinkCapacity will never be reported as a negative number.
Issue 0.8
July 10, 1998
Page 53
6.10.2.3. The Analogue Domain, Power Sensor and Power Limiting Immediately following the High Power Amplifier (HPA), there is a power sensor that is calibrated to report the total power at the demarc panel (800MHz) or the RFFE output (1900MHz). The report from this sensor is in units of 1/16th dBm. Beware that this sensor is not immune to the waveform of the transmitted signal and since the sensor has been deliberately calibrated for the most likely situations, an offset needs to be applied in some cases: 1. Single walsh code, low power (i.e. during calibration): sensor reads correctly. 2. Three walsh codes, low power (i.e. overhead channels only): sensor reads correctly 3. Multiple walsh codes, low power (i.e. few low power users): sensor reads 0.75dB low (12/16th dB). 4. Multiple walsh codes, medium to high power (i.e. carrying traffic): sensor reads correctly. The sensor reading is compared against a datafillable upper limit TxPowerMax. If this threshold is exceeded, the BTS will wilt the sector by one step and re-compare the reading with TxPowerMax. This is the Power Limiting algorithm and it repeats until the power no longer exceeds TxPowerMax. This limits the output power to TxPowerMax. However, forward link power control will act in opposition to the power limiting, possibly causing an unstable situation. For this reason, this algorithm should be viewed as an HPA protection mechanism only and the blocking thresholds should be set such that Power Limiting is a rare occurrence. The FwdHandoffBlockingThreshold should be at a higher power than the FwdCallBlockingThreshold (give priority to existing calls). Using TxAttenNormal to permanently reduce the transmit power is not recommended for two reasons: 1. The Transmit Power Tracking Loop that is soon to be introduced (6.1.1) will null out small changes or cause a fault to be reported for larger changes (> 6dB). 2. For every 1dB that the forward link is reduced, the reverse link noise figure should be increased 1dB. Although there is another parameter that can accomplish this, it is not datafillable (requires an action) and so the change is very hard to maintain. The (crude but) effective way to achieve an equal reduction in coverage on both links (which is vital to system performance) is to use attenuators in the antenna cables.
Table ?: BTS Forward Link Power and Blocking Calculations
Power Key Pilot Sync Paging (Half Rate) Total Overhead Typical User Traff Chan Gain a b c d e a+b+c (97^2)*VAF*1.15 Calculation Datafil Bits l square 186 60 156 34596 3600 12168 50364 3895
Power Sector-
Percentag dB relative Notes e to pilot 0.00 -9.83 -4.54 1.63 -9.48 5)
(Watts) (dBm) TxPower of pilot 2.14 0.22 0.75 3.12 0.242 33.31 23.49 28.78 34.95 23.83 559 100.00 10.41 35.17
Issue 0.8
July 10, 1998
Page 54
MinPilotToTotalPowerRatio f -135

1)
Blocking Threshold Reference g
a / 10^(f/160)
241421
14.97
41.75
668
1), 4)
CallBlockingThreshold HandoffBlockingThreshold
h i
61000 0
61000 0
3.78 0.00 % of TXPowerMax
Calls will block at: Handoffs will block at:
j k
g-h g-i
180421 241421
11.19 14.97
40.49 41.75
647 668
90.1
3)
120.6 Beware > TXPowerMax
Capacity Stuff Number of connections Sectors per user Sector Capacity n o q (j - d)/e 2.2 n/o 13.2 Pilot % TXPowerMax s 655 12.41 40.94 655 17.28 Pilot dB down -7.62 29.0
Notes 1) Remember the calculation STARTS from the pilot power - MinPilotToTotalPowerRatio does NOT set pilot power. 3) Calls should be blocked at 90% of TXPowerMax. Handoffs should not be blocked. 4) This number by itself has no meaning, it is just the level that the blocking thresholds are referenced to. 5) 1.15 factor allows for increased power of power control bits during handoff
6.10.3.
Optimising for Forward Link Capacity
The procedures covered in the RF coverage control section are aimed at giving good capacity throughout the network. However, sometimes there will be a requirement to improve capacity still further over a small area (up to, say, 4 sectors), possibly at the expense of capacity in the surrounding sectors. Referring to the forward link capacity equation, we can see that reductions in traffic channel power and unnecessary handoff will both lead to higher capacity. It is important to stress the unnecessary handoff since, taken too far, handoff reduction will result in poor performance of the forward link in terms of dropped calls, FER and capacity. The following strategies should be considered for improving capacity over a small area (the hotspot):
Issue 0.8
July 10, 1998
Page 55
CDMA RF Optimisation Technology Applications Group Removing interfering handoff from other sectors: If the mobile is going into handoff with sectors outside the hotspot area and this is causing handoff in excess of 3-way, those sectors should be removed by downtilting/antenna change/orientation change/power reduction (remember to reduce the reverse link as well). Since the mobile has only three rake fingers, consistent handoff above 3-way requires more traffic channel power to overcome the interference from the active set members that are not being demodulated. Removing interfering power from other sectors: If sectors outside the hotspot are transmitting power into the hotspot but the Ec/Io is too low for the mobile to go into handoff, those sectors should be removed by downtilting/antenna change/orientation change/power reduction (remember to reduce the reverse link as well). These interfering sectors result in a need for more traffic channel power to overcome the interference and maintain FER. Reducing handoff within the hotspot: If pilot quality is good throughout the hotspot, a reduction in pilot gain by 1 or 2dB on the hotspot sectors can be very effective. Since the traffic channels will remain at the same absolute level as before, this has the effect of lowering the Ec/Io of the hotspot sectors and hence reducing handoff. This is much more effective than increasing T_ADD and T_DROP for three reasons: 1. Raising T_ADD and T_DROP must be done on the surrounding sectors as well as the hotspot sectors since the mobile needs to have the new values before approaching the hotspot sectors. This causes a general lowering of handoff throughout the region. Reducing the pilot gain, on the other hand, targets the hotspot sectors very specifically and will also allow surrounding sectors to pick up some of the traffic since it actually shifts the handoff boundaries rather than just reducing handoff. 2. Because of the rules for updating T_ADD and T_DROP (most negative value for any of the active set), many more sectors need to be changed than are really required. This may cause problems elsewhere where the higher T_ADD and T_DROP cannot be tolerated. 3. Reducing the pilot power frees up some HPA power for traffic channels.
6.11. Power Control The power control parameters given in the Technology Applications datafill spreadsheets are the result of much simulation and field testing effort (reference power control report). Target frame error rates may be adjusted if the average frame error rates are not meeting customer expectations (changes to the reverse link should be done by scaling all 5 targets). Changes to the step sizes or the upper/lower/start values should not be contemplated unless a specific set of carefully designed tests are carried out solely for this purpose. The forward link power control parameters for rate set 1 (PWR_REP_THRESH, PWR_REP_FRAMES) should not need to be adjusted. (Explain why reverse link looks like set to 0.5% but is really 1% because of the way the algorithm works with non-equal per-rate target FERs)
Issue 0.8
July 10, 1998
Page 56
CDMA RF Optimisation 6.12. Hard Handoff
(This section under construction - main aim is to achieve trigger conditions that result in the transition to a clear, unambiguous pilot on the target frequency. Talk about two types of Inter-System Hard Handoff; double BTS and RTD. Talk about pros/cons of defining other sectors as borders. Also talk about idle mode hard handoff options and all the tricks for idle mode, such as empty BTS neighbour lists). 6.12.1. Round Trip Delay (RTD) Calculations
The BTS is able to measure the Round Trip Delay as follows: Remembering that 1 chip is 0.814uS, 1 chip represents a 1-way propagation distance of 244m. Say a mobile is 2km from its reference cell. The propagation delay in terms of chips for 2km is 2/0.244 = 8.2 chips. The mobile will use this signal for its timing reference so its timing is now 8.2 chips late relative to system time. When the mobile now transmits to the BTS, a further 8.2 chip delay is incurred. The BTS expects the signal to arrive as if the mobile were at zero distance from the BTS. In this example therefore, the signal arrives 8.2 + 8.2 = 16.4 chips late. This is would be the RTD measurement if the BTS were making all its measurements right at the antenna. In reality, there is some processing delay on both the transmit and receive paths internal to the BTS. Two parameters, FwdDistributionDelay and RvsDistributionDelay, are available to effectively zero out this internal delay. If these have been datafilled correctly then all RTD calculations only need to take the over the air delay into account. Otherwise, the sum of these two parameters will effectively be added to all RTD measurements. The DistributionDelays are datafilled in 1/8th chip units. RTD is also reported by the system in 1/8th chip units. A report is generated every time the RTD changes by 2 chips.
Example: What is the required datafill value for an RTD triggered hard handoff to occur at 1km from a cell a) if the DistributionDelays have been set correctly and b) if the DistributionDelays have been left at 0 on a 1900MHz BTS. Answer: 1km represents a 1-way delay of 1/0.244 = 4.1 chips and hence a Round Trip Delay of 8.2 chips. Since the datafill is in 1/8th chip units, the datafill for answer a) is 66. On a 1900MHz BTS, the sum of the DistributionDelays is in 1/8th chip units and is 79 + 212 = 291. Therefore, the datafill required for b) is 291 + 66 = 357. 6.13. Other Future revisions of this document will contain sections on the following: registration paging, SMS traffic management (blocking thresholds, breathing, multi-carrier) (more)
Issue 0.8
July 10, 1998
Page 57
7.
Dropped Call and Access Failure Reasons and Solutions
(This section under re-construction) This section details the characteristics that will be observed in the diagnostic logs for various field issues that will be encountered throughout the network. Section 8 will cover issues specific to special cases. 7.1. Successful Call
This section explains the characteristics in the data for a phone that originates succesfully, remains in the service area, completes a handoff and makes a normal release. 7.1.1 Symptoms in Mobile Data
If only mobile data is available, the parametric files will show: Receive power > -100dBm Transmit power < +18dBm Normal Transmit Gain Adjust (actual value depends on site configurations, loading, NOM_PWR setting) Low forward FER Good Ec/Io (> -12dB) on at least one pilot
Under these conditions, messaging will be reliable. In message file output, a basic call (originated and released from the mobile) will contain the following elements : Origination message (sent to MTX on Access Channel). BTS Acknowledgement (received from BTS on Paging Channel) Channel Assignment (received from MTX on Paging Channel). (Mobile now acquires the forward traffic channel, then starts its own transmitter, then the BTS acquires the reverse traffic channel. All transmissions are 1/8 rate null frames) Forward Acknowledgement (received from SBS on traffic channel - acknowledges acquisition of reverse tch - this is ack requires an acknowledgement) Reverse Acknowledgemnt (sent to SBS - acknowledges receipt of forward acknowledgemnt) Service Connect Message (received from SBS on traffic channel - all remaining messaging is on the traffic channel). Service Connect Complete Message (sent to SBS - we consider a successful origination to have been made if this message is sent). Pilot Strength Measurement Message (sent to SBS - initiates handoff). Extended Handoff Direction Message (from SBS - directs handoff - if all is well, will contain same PNs requested by the mobile).
Issue 0.8
July 10, 1998
Page 58
CDMA RF Optimisation Technology Applications Group Handoff Completion Message (sent to SBS - confirms receipt of Extended Handoff Direction Message). Neighbour List Update Message (from SBS - contains new composite Neigbour List) Release Order (sent to SBS) Release Order (from SBS)
7.1.2
Analysis with Selector Logs
Using the parametric files, the following can be established:

MM MM MM MM MM MM SS MM MM SS SS SS MM MM MM SS MM SS SS MM
Receive power > -100dBm Transmit power < +18dBm Normal Transmit Gain Adjust (actual value depends on site configurations, loading, NOM_PWR setting) Ew/No setpoint below maximum Traffic Channel gain below maximum Low forward FER (either full or all rate) Low reverse FER (either full or all rate) Good Ec/Io (> -12dB) on at least one pilot
01:12:02.5850 01:12:02.7287 01:12:02.8475 01:12:03.1475 01:12:03.1688 01:12:03.6687 01:12:03.7400 01:12:03.8087 01:12:03.8863 01:12:03.9200 01:12:03.9400 01:12:03.9600 01:12:04.0075 01:12:04.0288 01:12:04.0675 01:12:04.1000 01:12:04.1075 01:12:04.1400 01:12:04.2200 01:12:04.2887 I95_AChanOriginationMsgType I95_PChanCDMAChannelListMsgType I95_PChanOrderMsgType I95_PChanExtendedSystemParametersMsgType I95_PChanGeneralPageMsgType I95_PChanChannelAssignmentMsgType I95_FTChanOrderMsgType I95_FTChanOrderMsgType I95_RTChanOrderMsgType I95_RTChanOrderMsgType I95_FTChanPowerControlParametersMsgType I95_FTChanServiceConnectMsgType I95_FTChanPowerControlParametersMsgType I95_FTChanServiceConnectMsgType I95_RTChanServiceConnectCompletionMsgTyp I95_RTChanServiceConnectCompletionMsgTyp I95_RTChanOrderMsgType I95_RTChanOrderMsgType I95_FTChanOrderMsgType I95_FTChanOrderMsgType AS:7 AS:1 AS:1 AS:2 AS:2 AS:0 AS:0 MS:2 MS:0 MS:0 MS:1 MS:1 MS:0 MS:0 AR:1 AR:1 AR:1 AR:0 AR:0 AR:0 AR:0 OR:16 OR:16 OR:16 OR:16 AS:7 MS:2 AR:1 AS:7 AS:7 AS:0 AS:0 MS:0 MS:0 MS:0 MS:0 AR:1 AR:1 AR:0 AR:0 OR:16 OR:16 OR:16 OR:16 PPN:320 AS:7 PPN:320 MS:5 AR:1
A message flow file for the same basic call will contain the following IS-95 messages:
Issue 0.8
July 10, 1998
Page 59
MM SS SS SS SS MM MM MM SS MM MM SS MM 01:12:05.2075 I95_RTChanPilotStrengthMeasurementMsgType PPNs:320R:( -7.00)K 312:(-12.50)K 01:12:05.2400 I95_RTChanPilotStrengthMeasurementMsgType PPNs:320R:( -7.00)K 312:(-12.50)K 01:12:05.3000 I95_FTChanExtendedHandoffDirectionMsgType PPNs:320 (0) 312 (1) SrchWin A:6 TA:28 TD:32 TC: 5 TTD: 3 01:12:05.3200 I95_FTChanExtendedHandoffDirectionMsgType PPNs:320 (0) 312 (1) SrchWin A:6 TA:28 TD:32 TC: 5 TTD: 3 01:12:05.3600 I95_FTChanExtendedHandoffDirectionMsgType PPNs:320 (0) 312 (1) SrchWin A:6 TA:28 TD:32 TC: 5 TTD: 3 01:12:05.3688 I95_FTChanExtendedHandoffDirectionMsgType PPNs:320 (0) 312 (1) SrchWin A:6 TA:28 TD:32 TC: 5 TTD: 3 01:12:05.4075 I95_RTChanOrderMsgType

AS:2 AS:2 AS:1 AS:1 AS:1 AS:1 AS:3 AS:1 AS:3 AS:3 AS:1 AS:3 AS:3 MS:1 MS:1 MS:3 MS:3 MS:3 MS:3 MS:2 MS:3 MS:2 MS:2 MS:3 MS:2 MS:3 AR:1 AR:1 AR:1 AR:1 AR:1 AR:1 AR:0 AR:1 AR:0 AR:1 AR:1 AR:1 AR:0 OR:16 PPN OR:16 OR:16 OR:16 PPN OR:16 OR:16 OR:16
01:12:05.4100 I95_FTChanExtendedHandoffDirectionMsgType PPNs:320 (0) 312 (1) SrchWin A:6 TA:28 TD:32 TC: 5 TTD: 3 01:12:05.4400 01:12:05.4475 PPNs:320 312 I95_RTChanOrderMsgType I95_RTChanHandoffCompletionMsgType
01:12:05.4500 I95_FTChanExtendedHandoffDirectionMsgType PPNs:320 (0) 312 (1) SrchWin A:6 TA:28 TD:32 TC: 5 TTD: 3 01:12:05.4800 PPNs:320 312 01:12:05.4875 I95_RTChanHandoffCompletionMsgType I95_RTChanOrderMsgType
SS 01:12:05.5000 I95_FTChanNeighborListUpdateMsgType AS:2 MS:4 AR:1 Inc: 4 NPNs:316 60 300 288 428 304 292 176 420 364 56 284 172 276 200 188 184 296 424 428 SS MM SS 01:12:05.5200 01:12:05.5275 01:12:05.5600 I95_RTChanOrderMsgType I95_RTChanOrderMsgType I95_RTChanOrderMsgType AS:3 AS:3 AS:3 MS:3 MS:4 MS:4 AR:0 AR:0 AR:0
MM 01:12:05.5700 I95_FTChanNeighborListUpdateMsgType AS:2 MS:4 AR:1 Inc: 4 NPNs:316 60 300 288 428 304 292 176 420 364 56 284 172 276 200 188 184 296 424 428 SS SS MM MM SS SS MM MM SS MM MM SS MM SS SS MM MM 01:12:05.6800 01:12:12.9400 01:12:13.0287 01:12:13.1075 01:12:13.1400 01:13:45.1000 01:13:45.1888 01:13:45.2288 01:13:45.5200 01:13:45.6100 01:13:45.6875 01:13:45.7200 01:13:52.3275 01:13:52.3600 01:13:52.4400 01:13:52.5087 01:13:52.9725 I95_RTChanOrderMsgType I95_FTChanServiceOptionControlMsgType I95_FTChanServiceOptionControlMsgType I95_RTChanOrderMsgType I95_RTChanOrderMsgType I95_FTChanServiceOptionControlMsgType I95_FTChanServiceOptionControlMsgType I95_RTChanServiceOptionControlMsgType I95_FTChanServiceOptionControlMsgType I95_FTChanServiceOptionControlMsgType I95_RTChanOrderMsgType I95_RTChanOrderMsgType I95_RTChanOrderMsgType I95_RTChanOrderMsgType I95_FTChanOrderMsgType I95_FTChanOrderMsgType I95_SChanSyncMsgType AS:4 AS:2 AS:2 AS:5 AS:5 AS:4 AS:4 AS:0 AS:4 AS:4 AS:0 AS:0 AS:0 AS:0 AS:5 AS:5 PPN:312 MS:5 MS:5 MS:5 MS:6 MS:6 MS:0 MS:0 MS:3 MS:0 MS:0 MS:4 MS:4 MS:5 MS:5 MS:1 MS:1 AR:0 AR:1 AR:1 AR:0 AR:0 AR:1 AR:1 AR:0 AR:1 AR:1 AR:0 AR:0 AR:1 AR:1 AR:0 AR:0
OR:16 OR:16
OR:16 OR:16 OR:21 OR:21 OR:21 OR:21
Issue 0.8
July 10, 1998
Page 60
CDMA RF Optimisation Technology Applications Group Note how the message sequence and acknowledge sequence numbers work e.g. if a Pilot Strength Measurement Message is sent with msg seq 3, the Extended Handoff Direction Message will have an ack seq of 3 (confirming that it is the acknowledgment to that particular PSMM). The MM and SS indicate messages logged at the mobile and SBS respectively (i.e. if all is proceeding normally, every traffic channel message will appear twice, once at each logging point). Order type 21 is a release message.
Issue 0.8
July 10, 1998
Page 61
CDMA RF Optimisation 7.2.
Access Fail and Dropped Call Reasons in Single Frequency System
i.e. no hard handoff
Description
Symptoms in data
Solution
Comments
Access Failures Bad pilot choice - drops paging channel 1 or more probes (have seen up Control RF to reduce to 5), no Ack or CA at mobile, cases of multiple pilots then immediately back to SYNC. with no dominant server. Poor Ec/Io. Lots of Bad Paging Channel CRCs. Mobile receives P-channel order and stops probing but no CA seen. Selector logs will have NOIS msgs setting up resources etc. Mobile receives channel asignment but goes to SYNC within 1 second. Selector power control setpoints at selector frozen at starting values. Mobile never enables its transmitter. Control RF to reduce cases of multiple pilots with no dominant server. Does pilot selection algorithm need improving?
Bad pilot choice - missed Channel Assignment Msg
Does pilot selection algorithm need improving?
Bad pilot choice - fails to acquire fwd tch
Control RF to reduce cases of multiple pilots with no dominant server. Increase PTX start to 1dB.
Does pilot selection algorithm need improving? Also, fix introduced in 2.4.5 that temporarily increases fwd TCH gain by 5.5dB during acquisition phase. Mobile algorithm only looks for first adequate PN rather than the best PN. Does pilot selection algorithm need improving?
Bad pilot choice - distant PN
At the end of a call, mobile Downtilt distant PN if chooses to Sync to a distant PN possible. even though better local PNs are apparently available. Next origination fails because Neighbour List of distant PN does not contain any of the local PNs. Forward link dies before first Control RF to reduce handoff can be completed (and cases of multiple pilots still before Service Connect with no dominant server. (Complete) messages). Usually see multiple EHODs and Service Connects from selector but not arriving at mobile.
Bad pilot choice - before SVC
Does pilot selection algorithm need improving?
Issue 0.8
July 10, 1998
Page 62
Dropped Calls Slow handoff Mobile requests handoff to new pilot (which was in NL), selector sees PSMM, starts sending EHODs but none arrive at mobile because new PN is interferer (stays as candidate). Mobile will likely SYNC to pilot it was requesting. Poor Ec/Io, high fwd erasures Minimise search time by optimsing SRCH_WINs (especially A but don't go below 28 chips), trimming neighbour lists and reducing the number of way HO by controlling RF. If new pilot increases in strength suddenly, look at alternative antenna arrangements. If you really need coverage here and none of the existing cellsites can be "persuaded" to cover it then you need a new cellsite. Inspection of the Pilot Database neighbour list reveals that the PN actually refers to a re-use of that PN and not the one the mobile is heading towards. PN re-tune required. Mobile fix required. Mobile has NOT acted on the EHOD (has not updated its Active Set). Currently highest reason for dropped calls. Do N and A window analysis asap in the optimisation process. Don't forget to trim your neighbour lists after doing downtilts. Selector selnt05aa has quickrepeat and higher gain on EHOD to mitigate this problem.
Coverage
Mobile RX close to or below 100dBm. Mobile TX above +18dBm. Bad erasures both ways, poor Ec/Io. High selector power control setpoints. Mobile sees and requests handoff to a PN in the neighbour list but call continues to degrade and dies with all symptoms of fwd link interference (good RX, poor Ec/Io, high erasures).
PN Aliasing
Mobile fails to send Handoff Completion Message
Mobile sends Ack to Extended Handoff Direction Message but doesn't follow up with HOC. Selector times-out waiting for HOC. Good mobile RX power but poor Ec/Io and erasures. Usual cause of death is messaging failure on fwd link. After drop, mobile SYNCs to a pilot that wasn't in last neighbour list update. PSMMs unlikely (although may be picked up on Remaining Set search). Good mobile RX power but poor Ec/Io and erasures. Usual cause of death is messaging failure on fwd link. After drop, mobile SYNCs to a pilot that was in last neighbour list update but no PSMMs sent.
Pilot not in neighbour list
First see if the pilot that Don't forget to re-assess your caused the drop is neighbour lists after doing intended to serve that downtilts - can any be removed? area. If not, control the coverage (downtilt etc.). If it is (or it can't be removed from that area) then a neighbour list change is reqd. Essentially a neighbour list problem as above but interference has gone away by time mobile syncs so hard to tell who it is. Driving area very slowly can often reveal the interfering PN. Easier to see with OCNS off.
Un-identified Interferer
Issue 0.8
July 10, 1998
Page 63
Pilot outside SRCH_WIN_N Good mobile RX power but poor Ec/Io and erasures. Usual cause of death is messaging failure on fwd link. After drop, mobile SYNCs to a pilot that was in last neighbour list update but no PSMMs sent.

First see if the pilot that caused the drop is intended to serve that area. If not, control the coverage (downtilt etc.). If it is (or it can't be removed from that area) then need wider SRCH_WIN_N on sites in that area. Beware, SRCH_WIN_N cannot currently be updated during a call so mobiles originating in other parts of network will not have the wider window. Likewise, mobiles originating in this area will carry the wider window for duration of call.
7.3.
Hard Handoff
7.4.
External Interference (Fix this section)
This section explains the characteristics in the data for a phone that experiences forward link interference from a source outside the CDMA system being optimised. Some likely sources of interference are: intermodulation from an AMPS-only BTS, co-channel interference from an AMPS BTS that has not been cleared from the CDMA channel, an adjacent CDMA operator using the same channel (this will remain until inter-system soft handoff is available), a microwave link, raised noise floor due to the transmitter spectrum of another CDMA operator in the same market but on a different channel. 7.3.1 Symptoms in Mobile Data
If only mobile data is available, the parametric files will show: Good receive power (> -100dBm) Normal transmit power (< +20dBm) Higher than normal Transmit Gain Adjust (actual value depends on site configurations, loading, NOM_PWR setting) High forward FER Low best server Ec/Io (< -12dB)
Under these conditions, forwad link messaging will be unreliable at best and may be the actual cause of the drop. The message file output may show some or all of the following: Repeats of the same message (check that the msg seq and ack seq numbers are the same to ensure it is the same mesage).
Issue 0.8
July 10, 1998
Page 64
CDMA RF Optimisation Technology Applications Group If a reverse message is repeated because an ack is not received, either it is not getting to the selector (reverse link is worse) or the fwd ack is not reaching the mobile (fwd link is worse). The parametric files may indicate which is happening but ideally selector logs are required. If a fwd message is repeated then the rvs ack is not reaching the selector (reverse link is worse). If the mobile repeats a message 3 times without seeing the ack, it will tear the call down and will go to the sync channel. If the selector repeats a message 5 times without seeing the ack, it will send a forward release and the call will be torn down. If the mobile sees the release, it will respond with a reverse release and stop transmitting.Otherwise, it will timeout when no good frames are received for TBD secs.
7.3.2
Using the full parametric files, the following can be established:
7.3.3.
Further Analysis
7.3.4 7.7.
Corrective Action
Site Not In Service
i.e. pilot/paging/sync are being broadcast but cant handoff/originate 7.7.1 Symptoms in Mobile Data
looks like fwd interference (good RX, poor Ec/Io, poor FER, high TXGA), will see PSMMs requesting site and see site go to candidate on data collection tool but never active 7.7.2 Analysis with Selector Logs
NOIS will show failure to setup resources at new site 7.7.3. Further Analysis
Repeat shakedown at the site 7.7.4 Corrective Action
Issue 0.8
July 10, 1998
Page 65
CDMA RF Optimisation 7.8. Interference From Non Co-located AMPS Cellsite 7.8.1 Symptoms in Mobile Data
Looks like fwd interference (good RX, poor Ec/Io, poor FER, high TXGA) 7.8.2 Analysis with Selector Logs
7.8.3.
Further Analysis
7.8.4
Corrective Action
Need either more CDMA power or less AMPS - likely neither are practical so will have to live with problem 7.11. Handoff Boundary Balance 7.11.1 Symptoms in Mobile Data
7.11.2
7.11.3.
Further Analysis
7.11.4
Corrective Action
7.12. Interference from Microwave Link (1900) Could be forward or reverse link interference 7.12.1 Symptoms in Mobile Data
Fwd: (good RX, poor Ec/Io, poor FER, high TXGA), mobile will sync to the problem site after call drops Rvs: (high TXGA, high TX)
Issue 0.8
July 10, 1998
Page 66
CDMA RF Optimisation 7.12.2 Analysis with Selector Logs
7.12.3.
Further Analysis
7.12.4
Corrective Action
7.13. Interference From Foregin System Mobiles into CDMA BTS 7.13.1 Symptoms in Mobile Data
reverse link interference (high TXGA, high TX) 7.13.2 Analysis with Selector Logs
7.13.3.
Further Analysis
7.13.4
Corrective Action
7.14. AMPS A/B Band Coordination i.e. when competitor cellsite is at edge of CDMA cellsites - competitiors TX noise floor will interfere with fwd link 7.14.1 Symptoms in Mobile Data
Looks like fwd interference (good RX, poor Ec/Io, poor FER, high TXGA)
Issue 0.8
July 10, 1998
Page 67
8.
8.1.
Other Optimisation Procedures and Special Cases

Adding New Sites
Adding a new site to an existing (optimised) system, either for capacity (embedded cell) or for coverage (edge cell) consists of the following steps: Create new neighbour lists for the new cell and the surrounding cells using the method in section 4.3. Estimate suitable antenna downtilts using Ec/Io plots in Planet Create the datafill for the new cell (parameters such as search windows, access channel settings, can be copied from surrounding cells) Blossom the cell during a low traffic period and perform shakedown Cell is now available for carrying traffic Enable the NeighborListTuningArray and tune the neighbour lists. Perform full optimisation of the area at the next opportunity (e.g. after several new cells have been put in service)
8.2.
Other Special Cases
Future revisions of this document will contain sections covering the following: microcells highways geographic related inter-system soft handoff (others)
Issue 0.8
July 10, 1998
Page 68
9.
9.1.
Appendices
Sample Mobile Data Log Sheets
DATE: (YYMMDD)
VAN CREW:
RUN #:
T EST: ROUTE: VEHICLE B B N N Q Q MIN CALL T YPE M M V V RATE 13 8 13 8 SBS LOGS Y Y N N 2ND PHONE Y Y N N LOGFILE
M M
DATA COLLECTION SOFTWARE: NETWORK SOFTWARE: # SITES ACTIVE: START T IME KEY T IME MIN
HANDSET SOFTWARE: LOGMASK: SITES NOT AVAILABLE: STOP T IME COMMENTS LOCATION
BRNX BRNY BRNZ CLOV COLE GLDX GLDY GLDZ HCTR KNDY LGLY LHED MURR NWSX NWSY NWSZ PANX PANY PANZ PMAN POCO SURR WRCX WRCY WRCZ FLWD HANY
The top portion of a mobile log file appears above, a complete set of log sheets can be found in Appendix xxx. The engineer monitoring the data collection tool was required to keep this detailed log throughout the data collection process. The first following information was recorded on the log sheet. Date: The format for the date was yymmdd and this format was maintained throughout the data collection process. The data was placed in subdirectories on all the computers under this date. Van Crew: A record of the members of the van crew on the day the data was collected is necessary in case there are any questions about the logs after they are collected. Run Number: The run number is always prefixed by a letter to indicate the van that was used for data collection. This information is vital in the event that a problem is subsequently identified with the data collection tools in the van. Test: A description of the test being done and the parameter or situation being investigated. Route: The drive route used for the data collection. Vehicle: The appropriate letter is circles to indicate the van being used where N indicated the Nortel van, Q indicated the Qualcomm van, and B indicated the BCTel van. MIN: The mobile identification number used for the data collection. Issue 0.8 July 10, 1998 Page 69
CDMA RF Optimisation Technology Applications Group Call Type: The appropriate letter was circled to indicate the type of call being used for the testing. M indicated Markov calls and V indicates Voice calls. Rate: The vocoder rate used by the mobile handset, 13 for 13k vocoder and 8 for 8k vocoder. SBS logs: Circling Y indicates that SBS logs were being collected in conjunction with the mobile logs, circling N indicated that no SBS logs were collected. Second Phone: Y was circled to indicate that a second mobile was logging in the same van during testing, N was circles to indicate that only one mobile was being logged during testing. Log File: The log file name provided by the data collection tool at the end of the logging period. These log file names always begin with an M. Date Collection Software: The software version of the data collection tool on the day of the test. Network Software: The version of the software being used on the network. # of Sites Active: Number of sites on the air on the day of the test. Handset Software: The software version being used in the handsets on the day of the testing. Logmask: The logmask being used on the data collection tool during the testing. Sites not available: A list of sites that were not on the air during the test. Start Time and Stop Time: The start time and stop time of the mobile log. All times recorded use the GPS time of the system in order to reference the data logs being collected by the data collection tools. Key: The key is contained in a footer on the log sheet. Events of note are recorded using the key to quickly code the event. As Vancouver has many bridges and bridges had been identified as potential problem areas, a code was required to track data collected on bridges.
KEY: D - DROPPED CALL F - ACCESS FAILURE U - CALL UP B1 - ON BRIDGE B0 - OFF BRIDGE S - VEHICLE STOPPED M - VEHICLE MOVING T - NORMAL CALL TERMINATION X - CROSS STREET OR INTERSECTION
Time: The GPS system time of the event being logged. MIN: Used when two MINs are being logged on the same log sheet. Comments: This field is used to record any comments about events that occurred during the logging. Each of the sites (and sectors when appropriate) are listed in this section. Active set members are circled as handoffs occur. Location: The street and direction being traveled is entered at the beginning of each run, then all cross streets are recorded as they are crossed. When the vehicle turns, the street and the new direction is entered. This information is especially useful when trying to determine if a drop occurred in an area where there was no coverage.
Last Modified: 04/22/99 09:26 AM Issue 0.8 July 10, 1998 Page 70
DATE: (YYMMDD) VAN CREW:

RUN #:
T EST: ROUTE: VEHICLE B B N N Q Q MIN CALL T YPE M V M V RATE 13 8 13 8 SBS LOGS Y Y N N 2ND PHONE Y Y N N LOGFILE
M M
DATA COLLECTION SOFTWARE: NETWORK SOFTWARE: # SITES ACTIVE: START T IME KEY T IME MIN
HANDSET SOFTWARE: LOGMASK: SITES NOT AVAILABLE: STOP T IME COMMENTS LOCATION
Issue 0.8
July 10, 1998
Page 71
DATE: (YYMMDD)

CONTINUATION SHEET: ___ OF ____ RUN #:
T EST: KEY T IME MIN COMMENTS

LOCATION
Issue 0.8
July 10, 1998
Page 72
DATE: (YYMMDD)

CONTINUATION SHEET: ___ OF ____ RUN #:
T EST: NUMBER OF DROPPPED CALLS FOR THIS RUN:
NUMBER OF CALL ORIGINATION FOR THIS RUN:
NUMBER OF ACCESS FAILURES FOR THIS RUN:
PROBLEM AREAS: (GIVE CROSS STREETS WHEN POSSIBLE)
IS FURTHER INVESTIGATION REQUIRED: YES NO IF YES, WHY?
Issue 0.8
July 10, 1998
Page 73
9.2.
Importing Files into Planet
Since a survey loader specific to the data analysis tool output file formats does not yet exist, the following method allows survey data of various types to be displayed in Planet. Use scripts (such as those presented in chapter 6.1.) to obtain files of the form: Decimal Latitude, Decimal Longitude, Value to be displayed. The separator between the 3 columns can be multiple spaces and/or tabs. File length is not limited by Planet but a maximum of 50 files can be loaded at any one time (true at release 2.5.12). The files should be place in the results directory. For every survey file, a corresponding header file needs to be created in the head directory (the contents are not critical for merely displaying data). Use a script such as the following to create the header files: #!/bin/csh #Martin Kendall, Nov 95 #Expects to be run from results directory. #Will create a header file for every file found using #head_temp as a template rm ../head/*.hd foreach sfile ( * ) echo $sfile set headfile = $sfile".hd" echo $headfile cp ../head/head_temp ../head/$headfile end
Use the Tools/Surveys function to load the survey data and Draw/Signal to display it. Remember to adjust the cutoff limits (e.g. when displaying Ec/Io, the default upper limit of -30 will have to be raised) and the contour settings to values appropriate to the data.
9.3.
QCP Tech Mode Screen
Handset Monitor Mode Found on the handset by choosing menu - 7 - 0, a display appears with two rows of three values. Moving from left to right across the rows, the following items appear.
Issue 0.8
July 10, 1998
Page 74
CDMA RF Optimisation First row PN Offset: in decimal 0: Pilot Channel Acquisition 1: Sync Channel Acquisition 2: Idle 3: Access 4: Traffic Channel Receive State: uses the following codes:
Receive Power: in coded hex, can be translated by converting the hex number to decimal, subtracting 256 from the decimal value, divide result by three, and then subtract 63.25 (800MHz) or 66.25 (1900MHz). This final result is in dBm. Second row First value unsupported Second value unsupported Transmit Gain Adjust: in coded hex, can be translated by converting value to decimal and dividing by -2 (a alue of 7F means the transmitter is inactive).
9.4.
Sample Rundesc.txt
15-cell "Expanded Trial" at BCTel Run descriptions for date: General Notes/System Status: 16-Cells on air BTS/BSC S/W is 2.2 with the following revisions:Integration Lab version 6, selector controller 18A, selector 21, SCI 13, BTS controller 7C CSM 4a, rfc.lip 9, MTX05AM 960727
Network survey after bringing up Haney.
Run N01 N01 Note:
MIN 8580 8598
S/W 1.61 1.61
Call M13 M13
Configuration NPG/CKT/7db NPG/CKT/7db
Route/Loc SURR General SURR General
Purpose of Run Network Survey Network Survey
8580 performed the long calls. 8598 performed the short calls. 8580 dropped call 152nd X 34th.
N02 N02 Note:
8580 8598
1.61 1.61
M13 M13
NPG/CKT/7db NPG/CKT/7db
SURR General SURR General
Network Survey Network Survey
8598 MDM locked up. 2 access failures for 8580.
Issue 0.8
July 10, 1998
Page 75
Q01 Q01 Note: 4289 8568 1.61 1.61 M13 M13 NPG/CKT/7db NPG/CKT/7db COQ/POCO Gen COQ/POCO Gen

4289 drops on Westwood X LHED & Mariner X Hickey. 8568 MDM crashed.
Q02 Q02 Note:
4289 8568
1.61 1.61
M13 M13
COQ/POCO Gen COQ/POCO Gen
4289 problems on Como Lake Rd: X Wasco & X Seymore & X Barker. Mariner X Woodward. 8568 power cycle->Q03.8586
Q03 Q03 Note:
4289 4243
1.61 1.61
M13 M13
Pit Mdw/Mpl Rdg Pit Mdw/Mpl Rdg
4289 3 drops. 10 access failures. LHED X Indian Res. North on 287. Poor coverage for entire run, both phones.
B01 B01 Note: B02 B02 Note:
8572 8574
1.61 1.61
M13 M13
BRN/NWEST BRN/NWEST
8572 power cycle 142 st X 24 av->b118572.err 8572 8574 1.61 1.61 M13 M13 NPG/CKT/7db NPG/CKT/7db BRN/NWEST BRN/NWEST Network Survey Network Survey
US West Interference on Marine Drive from Magdalene to Maple St.
9.5.
Calculating Required Power Reduction for Unwanted PN
Assume 4 pilots are being received at strengths as follows: -7dB -7dB -10dB -11dB and we want to get the last one below T_ADD (-14dB). A simple reduction of 3dB will not achieve the required results since the Io will also reduce when this pilot is lowered. A quick way to find out the Io reduction is to assign weightings to the pilots, starting with 1 for thie strongest: -7 = 1 -7 = 1 -10 = 0.5 -11 = 0.4 for a grand total of 2.9. When we remove the last, we will have an Io reduction of 2.5/2.9 = -0.64dB. Therefore, the pilot needs to lowered by 3 + 0.64 = 3.64dB.
Issue 0.8
July 10, 1998
Page 76

CDMA RF Optimization Guide Issue 0 8

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

CDMA RF Optimization Guide Issue 0 8

Hochgeladen von

Copyright:

Verfügbare Formate

CDMA RF Optimisation Guidelines

Nortel Wireless Networks 1998 All Rights Reserved

Technology Applications Group

July 10, 1998

Technology Applications Group

July 10, 1998

Technology Applications Group

July 10, 1998

Technology Applications Group

July 10, 1998

Technology Applications Group

About Issue 0.8

July 10, 1998

Technology Applications Group

July 10, 1998

CDMA RF Optimisation 2.2. Related Documents

Technology Applications Group

(this document can also be found on this server)

2. ftp to 47.65.105.47, id: anonymous, dir: dist/80.docs 3. http://47.164.163.96:4000/root/bnr/mtx/www/homepages/2n70/2n70.html

Scope of this Document

Issue 0.1 0.2

Date 96Aug03 96Aug30

July 10, 1998

Technology Applications Group

July 10, 1998

Technology Applications Group

Sequence of Events Pre-Commercial

July 10, 1998

July 10, 1998

July 10, 1998

Technology Applications Group

Initial System Parameters

July 10, 1998

July 10, 1998

July 10, 1998

July 10, 1998

July 10, 1998

CDMA RF Optimisation 4.5. Search Windows

Technology Applications Group

July 10, 1998

Technology Applications Group

July 10, 1998

July 10, 1998

July 10, 1998

Technology Applications Group

July 10, 1998

Technology Applications Group

Tools Mobile Data Collection

Test Van + 3.0 - 3.0 -6.0 +3.0 -7.0 0 -10.0

Real Car 0 0 0 0 0 10 -10 0dB

July 10, 1998

CDMA RF Optimisation 5.1.3. The Base Station Manager (BSM)

Technology Applications Group

July 10, 1998

July 10, 1998

CDMA RF Optimisation 5.3. Drive Test Data Required

Technology Applications Group

July 10, 1998

July 10, 1998

CDMA RF Optimisation 5.3.2. Mobile Log Mask

Technology Applications Group

1=log 0=no log 0 0 0 0 1 1 1 1 1 0 0 1 0 0 1 0

July 10, 1998