CDMA RF Optimisation Technology Applications Group
Issue 0.8 July 10, 1998 Page 4
6.10.1.2. Forward Link 496.10.1.2.1. From Drive Test Data 496.10.1.2.2. From BTSPerformanceData 516.10.1.2.3. Interpreting the Equations 51
6.10.2. BTS Operation 526.10.2.1. BTS Calibration 526.10.2.2. The Digital Domain, Forward Power Control and the Forward Blocking Thresholds 536.10.2.3. The Analogue Domain, Power Sensor and Power Limiting 54
6.10.3. Optimising for Forward Link Capacity 55
6.11. Power Control 56
6.12. Hard Handoff 576.12.1. Round Trip Delay (RTD) Calculations 57
6.13. Other 57
7. Dropped Call and Access Failure Reasons and Solutions 58
7.1. Successful Call 587.1.1 Symptoms in Mobile Data 587.1.2 Analysis with Selector Logs 59
7.2. Access Fail and Dropped Call Reasons in Single Frequency System 62
7.3. Hard Handoff 64
7.4. External Interference (Fix this section) 647.3.1 Symptoms in Mobile Data 647.3.2 Analysis with Selector Logs 657.3.3. Further Analysis 657.3.4 Corrective Action 65
7.7. Site Not In Service 657.7.1 Symptoms in Mobile Data 657.7.2 Analysis with Selector Logs 657.7.3. Further Analysis 657.7.4 Corrective Action 65
7.8. Interference From Non Co-located AMPS Cellsite 667.8.1 Symptoms in Mobile Data 667.8.2 Analysis with Selector Logs 667.8.3. Further Analysis 667.8.4 Corrective Action 66
7.11. Handoff Boundary Balance 667.11.1 Symptoms in Mobile Data 667.11.2 Analysis with Selector Logs 667.11.3. Further Analysis 667.11.4 Corrective Action 66
7.12. Interference from Microwave Link (1900) 667.12.1 Symptoms in Mobile Data 667.12.2 Analysis with Selector Logs 677.12.3. Further Analysis 677.12.4 Corrective Action 67
7.13. Interference From Foregin System Mobiles into CDMA BTS 677.13.1 Symptoms in Mobile Data 677.13.2 Analysis with Selector Logs 67
CDMA RF Optimisation Technology Applications Group
Issue 0.8 July 10, 1998 Page 5
7.13.3. Further Analysis 677.13.4 Corrective Action 67
7.14. AMPS A/B Band Coordination 677.14.1 Symptoms in Mobile Data 67
8. Other Optimisation Procedures and Special Cases 68
8.1. Adding New Sites 68
8.2. Other Special Cases 68
9. Appendices 69
9.1. Sample Mobile Data Log Sheets 69
9.2. Importing Files into Planet 74
9.3. QCP Tech Mode Screen 74
9.4. Sample Rundesc.txt 75
9.5. Calculating Required Power Reduction for Unwanted PN 76
CDMA RF Optimisation Technology Applications Group
Issue 0.8 July 10, 1998 Page 6
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”
CDMA RF Optimisation Technology Applications Group
Issue 0.8 July 10, 1998 Page 7
2. Introduction
2.1. CDMA Optimisation Overview
The RF optimisation process will necessarily happen in several stages as a network evolves:
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 ApplicationsGroup.
This document does not attempt to cover such topics as scheduling, logistics, interaction with othergroups etc.
2.4. Revision History
Issue Date Reason for up-issue
0.1 96Aug03 First issue, whole of document created.
0.2 96Aug30 Extensive modifications, first release to field
CDMA RF Optimisation Technology Applications Group
Issue 0.8 July 10, 1998 Page 9
0.3 96Nov18 Minor editorial (no content change)
0.4 97April24 Remove tool dependencies. Many updates based on field experience.
0.5 97April31 Correct minor mistakes
0.6 97Jul14 Major updates on overall strategy.
0.7 97Jul22 Capacity optimisation, initial search windows, many revisions
0.8 98June26 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 thedocument 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 RFoptimisation procedures.
The reader is expected to have prior knowledge of the CDMA system and RF engineering principles.
CDMA RF Optimisation Technology Applications Group
Issue 0.8 July 10, 1998 Page 10
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 enteredin the datafill.
• The spectrum should be clear down to a level of -110dBm (800MHz) or -111dBm (1900MHz) (totalpower 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 makehandoffs 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, GPSinstalled/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
3.2.1. Pre-Commercial
The following is a basic list of items that should be addressed during an optimisation exercise on a pre-commercial 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 andselector 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 fingerEc/Io, per-PN plots as necessary (best finger/any finger/PSMM occurrence))
CDMA RF Optimisation Technology Applications Group
Issue 0.8 July 10, 1998 Page 11
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 analysisand 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 drivewhile 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/orreasons 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 andcollecting 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 tocoverage related issues.
4. Perform failed access analysis. Plot locations in the data analysis tool. Pay particular attention tocoverage 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 notexcessive (2.3 or lower is a good target (soft handoff reduction algorithm will be in release 6.2 - willneed to re-assess this target)) and the dropped call/access fail rates and/or reasons are acceptable theninitial optimisation is complete. Otherwise, make all the necessary changes to the network and repeatfrom item 1.
8. Complete the performance/trend analysis
CDMA RF Optimisation Technology Applications Group
Issue 0.8 July 10, 1998 Page 12
In addition, many special cases will be encountered during optimisation. Procedures for some these willbe added to this document in due course. However, there will always be specific issues that can only besolved 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 foranalysis 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.
CDMA RF Optimisation Technology Applications Group
Issue 0.8 July 10, 1998 Page 13
4. Initial System Parameters
4.1. Datafill Example
Since a significant portion of an optimisation effort is devoted to system parameters, every effort shouldbe 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 willprovide a solid starting point for an optimisation effort for a new system.
4.2. Types of Parameters
4.2.1. IS-95/J-STD-008 vs. Nortel Specific
It is worth noting that some parameters are defined by the standards and can be found in IS-95 or J-STD-008 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 800and 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 sectorscontaining different values for a given parameter, there are parameter-specific rules for which valuewill be used:
1. For SRCH_WIN_A the SBS will send the widest value.
2. For SRCH_WIN_N the SBS will send the widest value.
3. For SRCH_WIN_R the SBS will send the widest value.
4. For T_ADD, T_DROP the SBS will send the lowest (most negative, e.g. -12 and -13 willresult in -13).
5. For T_TDROP, the SBS will send the maximum value.
6. 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 willhave the settings that it acquired from the last sector on which it was idle.
CDMA RF Optimisation Technology Applications Group
Issue 0.8 July 10, 1998 Page 14
• Values at the BSC apply to the traffic channel. SRCH_WIN_A, T_ADD, T_DROP, T_TDROP andT_COMP will all be sent on the Extended Handoff Direction Message according to the above rules ifthe SBS detects that the mobile does not have the current values (i.e. every time a handoff occurs, theSBS works out the new values according to the new active set and, if these values don’t match whatit last sent to the mobile, it sets the “Search Included” flag and sends the new values on the ExtendedHandoff Direction Message). Unfortunately, until the “In Traffic System Parameters Message” isimplemented, it is not possible to update the mobile’s 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 valuesit gets from the paging channel. For example, a call originated in a rural cell with a largeSRCH_WIN_N that is subsequently carried into a downtown cell with a smaller window setting willnot update its search window until the call is released and the mobile monitors the paging channelagain.
Note that, since setting SRCH_WIN_A and handoff parameters at the SBS is far simpler thandownloading them to the BTSs, this provides a quick means of testing new settings. For example, if thereis 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, thefirst handoff in every call will use the old settings but every subsequent handoff will use the newsetting 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 ParameterGuide).
Neighbour lists are somewhat of a special case. As with other parameters, the settings at the BTS areused on the paging channel. Since the mobile is only locked to one sector at a time during idle, itsneighbour 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 thatpoint on, the mobile will generate a composite neighbour list (up to a maximum of 20 entries) with thefollowing priorities:
1. Any pilots that have recently been dropped from the active list but have not yet exceededNGHBR_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 topilots 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 theneighbour lists of the sectors named in the most recent Handoff Completion Message (check for thecorresponding 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.
CDMA RF Optimisation Technology Applications Group
Issue 0.8 July 10, 1998 Page 15
3. The neighbour list of the strongest pilot in this list is then included (although any pilots from 1. abovewill not be repeated).
4. The neighbour list of the next strongest pilot in the list(although any pilots from 1. or 2. above willnot 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 thesame. Therefore, it is perfectly possible to have repeated PNs as long as the baseid is different. As theneighbour list for each PSMM entry is being added, the order in which the neighbours are datafilled in thePilot 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 stoppingat 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 BTSparameter changes may be made “online” from the BSM while others require a download (see RFParameter Guide and RF datafill Spreadsheets).
4.2. PN Planning
The entrance criteria to RF optimisation include the requirement that a PN plan has already beenestablished. Therefore, a full description of how to set to set up a PN plan for a system is outside thescope of this document.
The symptoms in the diagnostic data will be explained in a later section. However, the followingillustrates 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.
CDMA RF Optimisation Technology Applications Group
Issue 0.8 July 10, 1998 Page 16
Another possibility for "Co-PN" interference is if PN1 is in the mobile's neighbour list but some energyfrom a distant re-use of PN1 falls inside the neighbour search window. The "correct" local PN1 will beput in the active list. If the "false" PN1 subsequently becomes one of the 3 strongest multipaths, themobile will center an active search window on it and try to demodulate it resulting in forward linkinterference.
A third "Co-PN" possibility is if "false" PN energy arrives at the mobile that matches an active set PN thatis not currently being demodulated. If the "false" PN subsequently becomes one of the 3 strongestmultipaths, the mobile will center an active search window on it and try to demodulate it resulting inforward link interference.
A fourth "Co-PN" possibility is if "false" PN energy arrives at the mobile that matches an active set PNthat is currently being demodulated. This will only cause interference if the "false" PN energy falls insidethe 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 beadded to the active list, even if not required. However, this will not cause demodulation problems unlessthe "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'sactive window on the "false" PN. Therefore, the equations above are correct in having theSRCH_WIN_N and not SRCH_WIN_A).
For the mobile to actually try and demodulate a distant "false PN" that is already being demodulatedcorrectly from a local site, that site would have to fall inside the active search window. When consideringthe 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 someenergy 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 3strongest multipaths, the mobile will center an active search window on it and try to demodulate itresulting 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 listbased on latitude/longitude/azimuth.
CDMA RF Optimisation Technology Applications Group
Issue 0.8 July 10, 1998 Page 17
Alternatively, the initial neighbour lists for a new system or portion of a system can be generated asfollows:
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 commonboundary.
3. Prioritise the list according to the boundary length and traffic patterns such that the most likelytransitions 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 keepthe neighbour lists to the minimum length and hence reduce search times (see section 6.7. on neighbourlist data analysis)
4.4. BTS Calibration
Some of the datafill values are outputs from the BTS calibration process (e.g. TXAttenNormal, BTS toRFFE cable losses). Ensure that these are present in the datafill before optimisation commences.
CDMA RF Optimisation Technology Applications Group
Issue 0.8 July 10, 1998 Page 18
4.5. Search Windows
Initial search window settings for both the BTSs and mobiles can be estimated based on cell site radii in agiven area.
The following table gives the datafill, maximum delay and corresponding distance for various windowsizes:
Window size (chips) Datafill Value Max Delay (uS) Distance (km)
14 (+7) 4 5.7 1.71
20 (+10) 5 8.1 2.44
28 (+14) 6 11.4 3.42
40 (+20) 7 16.3 4.88
60 (+30) 8 24.4 7.32
80 (+40) 9 32.6 9.76
100 (+50) a 40.7 12.20
130 (+65) b 52.9 15.86
160 (+80) c 65.1 19.52
226 (+113) d 92.0 27.57
CDMA RF Optimisation Technology Applications Group
Issue 0.8 July 10, 1998 Page 19
However, the chip sets commonly used in current handsets cannot search infinitely fast. Setting the searchwindows too small will not result in a worthwhile speed improvement and may risk missing someimportant signal energy or a new neighbour. The following table gives the acceptable search windowcombinations:
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 apropagation exponent of 3.5. If the cell radius is R then a multipath component will be 10dB down whenit 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 representativecell radius chosen for each group. For example, for R = 2km, the multipaths must travel 1.86km extra andsince 1 chip represents 0.244km, the “half-width” of the window should be 1.86/0.244 = 7.6 chips andhence the full window width should be at least 15.2 chips.
CDMA RF Optimisation Technology Applications Group
Issue 0.8 July 10, 1998 Page 20
The setting for SRCH_WIN_A can be obtained from the table above. The next highest setting above theone calculated is 20 chips.
The BTS demodulation windows are set in 1/8th chip units i.e 15.2 * 8 = 121.6. However, the smallestincrement that the CSM searches is 125 1/8th chip units so the settings should always be multiples of 125i.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 agiven 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 wouldbe 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 formobiles 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 forSRCH_WIN_R is to use the next setting above the SRCH_WIN_N.
The AccessChannelAcquisitionSearchWidth sets the greatest distance at which an origination can bemade from a sector. It is the only window that is not “centered” but it, in a similar manner to the RoundTrip Delay calculations, it does need to allow for the “out plus return” time. E.g. if access attempts areexpected up to a 15km radius, the pilot channel takes 15/0.244 = 61.5 chips so the mobile’s timing will beset accordingly. When it sends in an access probe, there will be a further 61.4 chip delay coming back tothe 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 theAccessChannelAcquisitionSearchWidth.
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 theNeighbor Configuration File (NCF). The Setneighbor and Checkneighbor commands at the BSM willthen apply or verify the datafill end ensure consistency between subsystems. Some RF Optimizer featuresmake 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 isnot defined, the BTS neighbors are set by the NEIGHBORS field. This list has three items for eachneighbor: key, neighbor config value, and priority. It appears as the following with KEY1 having a configvalue of 1 and priority of 2:
KEY1, 1,2,KEY2,3,4
CDMA RF Optimisation Technology Applications Group
Issue 0.8 July 10, 1998 Page 21
The BTS neighbor list will use the NEIGHBORS column if either this column is not present or this list isempty 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. Thisfollowing 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.
CDMA RF Optimisation Technology Applications Group
Issue 0.8 July 10, 1998 Page 22
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.
MultiPilotHHOEnabled: Enable multi-pilot targets, TRUE or FALSE.
PILOTINCR: Numeric value for the pilot increment in the neighbors list.
CDMA RF Optimisation Technology Applications Group
Issue 0.8 July 10, 1998 Page 23
5. Data Collection
5.1. Tools
5.1.1. Mobile Data Collection
Each test van should be equipped with equipment to collect data from the test mobile(s), a compatibleGPS receiver.
5.1.2. Test Van RF Configuration
Phones may simply be placed inside the vehicle or, for more repeatable results, an external antenna maybe used. If external antennas are to be used, the most convenient way to configure the RF connections inthe 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 theantenna 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 theattenuator required:
Losses/Gains (dB) Test Van “Real” Car
Antenna Gain + 3.0 0
Cable and connectors - 3.0 0
Car Kit Loss -6.0 0
Test Van Antenna Height +3.0 0
Attenuator -7.0 0
Penetration Loss 0 10
Total -10.0 -10
Difference 0dB
Ideally, the received power reading and transmit power indication of the phones used in the test vans should becalibrated. The HP8924 CDMA Mobile Tester will allow this type of measurement. Even if an exact calibration isnot carried out, the various phones used in the test vehicles should be tested for consistency from unit to unit.
CDMA RF Optimisation Technology Applications Group
Issue 0.8 July 10, 1998 Page 24
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 theBSC and BTSs, BTS software downloads and diagnostic logging. A full description of the BSM is outside thescope of this document. The assumption will be made that trained personnel are available to take SBS and BTSDiagnostic 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. Bewarethat this may actually mask “stray” pilots since the Ec/Io may be less than T_ADD when loading isapplied. For this reason, at least one pass through the network without loading is preferred. Thefollowing methods will allow a simulated loading to be applied approximates an even distribution of realusers.
5.2.1. Forward Link
Forward link loading is achieved through OCNS (Orthogonal Channel Noise Source). The standarddatafill reserves 2 channel elements per sector for OCNS. A gain setting of 120 allows 9 users per CE (18total). Assuming the channel elements have been reserved, a script can be used to turn on OCNS veryquickly (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 forvoice activity in this number, the OCNS algorithm will do this automatically if the OCNS gain modehas 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 averagedigital gain was 106 with a soft handoff overhead of 2.4 sectors per user. However, even if we want tosimulate full load, this is definitely not how OCNS should be set up since this completely fills the HPAand guarantees 100% blocking. At 1% blocking, there can only be 13 users on a sector 1% of the timeso, while individual sectors in a system instantaneously have 13 users, on average the number will bemuch lower. 13 channels is 6.6 erlangs so on average, there will be 6.6 users per sector throughout thesystem and this is what we should multiply by the soft handoff overhead and set with OCNS (i.e. theaverage number of "links" or "connections" to a sector is 6.6 x 2.4 = 16). Finally, allowance should bemade for the 2 phones in the drive test vehicle and since it will add 2 "links" to the sectors in the drivetest 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) shouldbe approximately 65% of the total HPA power. We can therefore check the above settings generate thecorrect 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
CDMA RF Optimisation Technology Applications Group
Issue 0.8 July 10, 1998 Page 25
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 AMPStraffic 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 followingequation:
Degradation (dB) = log10(1 - load)
where load is the fraction of pole capacity that the system is carrying (e.g. for 50% load, the requiredattenuation is 3dB total). Remember to allow for the load that the test phones will generate i.e. the actualattenuation 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 usingduplexers). This is the Nortel preferred method and shielded boxes with attenuators for both reverselink 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 activeelement, the attenuation value required will have to calculated such that the overall system noisefigure 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 (notrecommended since an optimistic dropped call rate will be obtained).
CDMA RF Optimisation Technology Applications Group
Issue 0.8 July 10, 1998 Page 26
5.3. Drive Test Data Required
The following sections define the log masks that should be used for the selector and mobile loggingduring drive testing.
5.3.1. Selector Log Mask
The following table illustrates SBS log masks that will cover most aspects of RF optimisation. Log maskswith this many attributes should only be enabled conditionally (i.e. for specific mobiles as entered in theCDMA ICC table at the MTX):
Attribute Name Logged onVoice/Markov
calls
Required forOptimisation
Required forDetailed Network
Debugging
What
LogSBSNOISMessages Both Yes Yes Internal NOIS messaging
LogSBSIS95Messages Both Yes Yes Air interface messaging
LogSBSMarkovData Markov only Yes Yes Expected and received rvsframe rates/types
LogSBSForwardMarkovData
Markov only No No Cumulative Full and All rateFwd FER every 20 seconds
LogSBSReverseMarkovData
Markov Only No No Cumulative Full and All rateRvs FER every 10 seconds
LogSBSPowerControlData
Both Yes Yes Ew/No setpoint and fwdtraffic chan gain per frame
LogSBSActiveSetChange
Both No Yes New active set with baseids
LogSBSResourceUsage Both No Yes
LogSBSCallAssociation Both Yes Yes Links ESN/IMSI to callid
LogSBSForwardLinkFER
Both No No All rate FER summary for 1call
LogSBSReverseLinkFER
Both No No All rate FER summary for 1call
LogSBSFrameSelectionData
Both No Yes Indicates which BTS eachframe was taken from
LogSBSReceivedMuxDecision
Both Yes Yes Received frame rates/types
LogSBSTransmitMuxOption
Both Yes Yes Transmitted framerates/types
CDMA RF Optimisation Technology Applications Group
Issue 0.8 July 10, 1998 Page 27
LogSBSRoundTripDelay
Both Yes Yes RTD from each sector –logged every 10 secs
LogSBSForwardTrafficFrameData
Both No Only for voicequality issues
Full bit content of everyframe (large)
LogSBSReverseTrafficFrameData
Both No Only for voicequality issues
Full bit content of everyframe (large)
LogSBSNeighborListTuningArray
Both Yes Yes PSMM content with baseids
LogConfigData Both Yes Yes SBS parameters
LogSBSForwardFrameErasureIndicatorBit
Both No Yes Fwd EIB for every frame –logged every 16 secs
LogSBSVitalData Both Yes Yes Error strings (very useful)
CDMA RF Optimisation Technology Applications Group
Issue 0.8 July 10, 1998 Page 28
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 collectionequipment. For a full description for using the Grayson equipment, including details on tradeoffs incurredwhen logging the high volume attributes, see the separate documentation available from the TechnologyApplications Department:
1=log
0=no log
Field Description
0 Not used
0 AGC Val and Closed Loop PwrCtrl
Power control data for CD3000
0 Not used
0 Rev Link Frame Rates and Types Reverse link data transmitted.
1 Access Channel Msgs All access channel messages sent.
1 Rev Link Traffic Chnl Msgs All rvs Traffic Channel messages sent.
1 Sync Channel Msg Entry All Sync Channel messages sent.
1 Paging Channel Msg Entry All Paging Channel messages recd.
0 Fwd Link Frame Data Vocoder rate and data, forward link.
0 Rev Link Frame Data Vocoder rate and data, reverse link.
1 Temporal Analyzer Finger Searcher finger offset and power.
0 Obsolete TA Searcher Data Searcher data (not used).
0 ETAK Position and Speed Lat, long and speed from ETAK.
1 Markov Frame Rate Data Markov rate and error data.
0 TA Searcher Data Searcher data (window size andposition, pilot offset, signal energymeasured, etc.).
0 Not used
0 Vocoder Err Mask Vocoder rate/data with bit errorsdetected.
1 FM Data Analog mode data.
1 Access Probe Data Access probe information (seq number,probe number, RX AGC, TXGA, etc.)
CDMA RF Optimisation Technology Applications Group
Issue 0.8 July 10, 1998 Page 29
1 GPS Info Latitude, longitude, speed, heading,time from the GPS receiver.
0 Not used
1 Sparse AGC AGC and Closed Loop Power Controlfor QCP800/1900
0 Not used
5.4. Drive Testing
5.4.1. Shakedown
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 it’s the first site you’re 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 andthen release that call. Since the log is active (see below), this will capture sync, paging, call originationand 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 handoffregion and save the logs for both. Start new logs for both phones and continue to next site (i.e. For eachphone, there will be one log per site).
See section 6.2.2. for shakedown data analysis.
5.4.2. Drive Routes
5.4.2.1 Drive Route Selection
Using the coverage area predicted by the design tools, drive routes should be established throughout thearea 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 writtendown. Each time a route is driven, it should be driven in exactly the same direction, from the same startpoint to the same end point. Each route should be given a name or number which was recorded on themobile log sheet when the route is driven and the written log is included in the log book for easyreference during data analysis. During the drives, deviations from the routes such as detours and streetclosures should be noted on the log sheets by the drivers.
CDMA RF Optimisation Technology Applications Group
Issue 0.8 July 10, 1998 Page 30
5.4.2.2. Benchmark Route
A Benchmark Route can be a useful means of assessing network performance and consistency withoutthe need for a full network drive. It should take the form of a single loop that is selected to stay wellwithin 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. Itshould be driven each time a change is made to the network. The data from the Benchmark Route can becompiled 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 probablyat 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 twophones are used one phone can carry calls for approximately 10 mins duration but at least one phoneshould make short calls (e.g. 2 mins). Do not attempt to re-establish a call immediately following adropped 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, ifthere are, say, two selector shelves (twelve cards each for a total of 24) and only a single phone makingmany calls, each time a call was originated, it would be assigned to the next available selector card andthe assignments would alternate between the two shelves. A single phone operating on a particularselector card with the SBS log mask given earlier will fill the data buffer with information in about 16minutes. If the data logging buffer becomes full on a selector card, the behaviour depends on how the logwas initiated, but in any case, some data loss guaranteed (even with continuous mode).
CDMA RF Optimisation Technology Applications Group
Issue 0.8 July 10, 1998 Page 31
5.4.4.2. Logging Strategy
To avoid overflowing the data buffer, mobile calls should be limited to around 12 to15 minutes. Afterthis time, the call would be terminated and another call originated (but the same logs should be keptopen), this second call would occupy a different selector card and 15 more minutes of data can becollected. Obviously, this only applies to the phone making the long Markov calls, the other phone isalready making short Markov calls so its logging load will be spread among the selector cards. Also, toavoid losing large amounts of data due to logging failures, a 30 minute logging period should be imposedon 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...)
CDMA RF Optimisation Technology Applications Group
Issue 0.8 July 10, 1998 Page 32
Note, while every effort should be made coordinate with the SBS logs, it is not critical if the mobile logsare 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 eachdata 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. Textdescription 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
CDMA RF Optimisation Technology Applications Group
Issue 0.8 July 10, 1998 Page 33
6. Data Analysis Procedures
The following sections cover general data analysis procedures for the majority of the network. Analysisof “special case” areas may reveal a need for slightly different settings than these overall proceduresindicate.
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 aregenerated 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 asproblems at specific locations.
6.1. Tools
(This section under major re-construction due to recent tools evolution - transition to RF Optimizerwithin Nortel).
6.2. Datafill Audit and Shakedown
6.2.1. Datafill Audit
Examine the configuration files for all BTSs and the BSC and make sure the expected RF parameters arein place correctly.
6.2.2. Shakedown Data Analysis
Generate mobile message text files from the shakedown runs and, for each sector, examine the parametersettings in the Sync Channel Message, System Parameters Message, Extended System ParametersMessage, 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 (rememberingthat this is only used for idle handoff). The Nortel RF Optimizer automatically generates Shakedownreports.
6.3. System Access
6.3.1. Access Failure Analysis
Since at least one of the phones in the test vehicle is making many short calls, useful data on accessattempts is available.
If the radio link fails prior to the mobile sending the Service Connect Complete Message then it isconsidered a failed access attempt. Tools such as RF Optimizer will automatically identify the timestampsof access failures. Using the mobile message text files, message flow files and parametric files, classify thefailures 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)
CDMA RF Optimisation Technology Applications Group
Issue 0.8 July 10, 1998 Page 34
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 arelikely due to the mobile being restricted to one pilot during access (any other pilots are effectivelyinterferers). 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 ofthe 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 behappening 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 ratereports can be produces as required. However, measuring the access success rate on a pre-commercial 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 areclearly 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.
(Set INIT_PWR to be consistent with average TXGA - others should be at baseline datafill for now butneed to be subject of a detailed test)
6.4. Dropped Calls
6.4.1. Link Supervision
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 goodframes (i.e. every 2 consecutive good frames resets a 5 second fade timer).
CDMA RF Optimisation Technology Applications Group
Issue 0.8 July 10, 1998 Page 35
Additionally, the mobile will disable its transmitter if 12 consecutive erasures are received and will re-enable 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 HandoffCompletion Message) is received to a Handoff Direction Message within 5 seconds. The HandoffDirection Message will be re-tried 6 times. Additionally, if QuickRepeat is enabled, each of these re-triesis 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 asNortel’s RF Optimizer will identify and timestamp calls which ended prematurely. Throughinspection of the mobile message logs and parametric data, the root cause of some of the dropscan be determined without the need to use the selector logs. However, most of them will needdeeper 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 toprovide a step-by-step approach to dropped call root cause analysis, there is no substitute forthorough knowledge of the air interface and IS-95.
If the radio link fails after the mobile sends the Service Connect Complete Message then it isconsidered a dropped call. Using the symptoms described in chapter 7, separate the dropped callsinto the following categories:
1. Coverage related
2. “Optimisable” e.g. slow handoff, search window, coverage control, PN plan related.
Examine the location for all of the category 1. failures. Check that this type of dropped call is nothappening 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 existingsites 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 particularlyuseful 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.
CDMA RF Optimisation Technology Applications Group
Issue 0.8 July 10, 1998 Page 36
6.4.3. Dropped Call Rate
Tools such as Nortel’s RF Optimizer will automatically generate dropped call statistics based onthe actual number of test calls. If the long calls are to be used, the following method can be usedto avoid skewing the data:
• In conjunction with the customer, decide on an average call duration (e.g. 100 secs) that willbe used in the calculations.
• Use the total call time output from the data analysis tool and calculate the number ofequivalent calls using the average call duration. Data for all phones for an entirenetwork/cluster drive should be used.
• Eliminate any dropped calls that should not count in the total (e.g. drive routes that are clearlyout 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.
6.5. RF Coverage/Handoff Control
Controlling the coverage area of individual cells is the single most important aspect of CDMA RFoptimisation and is crucial to good CDMA performance. Much has been written about theelimination of frequency planning in CDMA. All this really means is the loss of one degree offreedom for interference control. Antenna patterns, orientations and tilts are the main tools usedto 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 andbuilt-in electrical downtilt. Downtown (and probably suburban) areas will often need downtiltswell 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 reasonsdoes not by itself cause “pilot pollution”.
If these steps are not taken, the system will be prone to the following “Pilot Pollution” relatedproblems:
• “Slow handoff” dropped calls: Since, for a given SRCH_WIN_A setting, the number of activepilots has a big influence on search time, there is an increased chance of a new, strong pilotnot 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 themobile is in 4-way handoff in a loaded system, the active pilot Ec/Io values could all bearound -13dB. When a new pilot crosses T_ADD at, say, -14dB, it is already nearly equal tothe active set pilots. By the time the phone has filtered the measurement, sent a Pilot StrengthMeasurement Message and the SBS has queried the BTS for resources, the new pilot may becausing so much forward link interference that the Handoff Direction Message fails to reachthe mobile.
CDMA RF Optimisation Technology Applications Group
Issue 0.8 July 10, 1998 Page 37
• “Window” related dropped calls: If pilots are being seen some distance outside their intendedcoverage area, dropped calls may results for two reasons. 1) If that pilot is strong enough tocause interference to a call in progress, but the mobile’s 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 setand the call may drop. 2) If the mobile originates on the distant site and hence uses it as itstiming reference, the local sites will be “invisible” if they are outside SRCH_WIN_N and thecall will drop as soon as one of the local sites becomes strong. Note that it is unlikely that themobile will switch its timing to the distant site while on a call since this would require that norake 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 manypilots with no dominant server or in a rapidly changing environment. In these cases, the pilots notcurrently being demodulated serve as “hot standbys” to which rake fingers can be assigned veryquickly. This can be very important in maintaining a call in a difficult environment. However, in ordernot to compromise capacity (both forward and reverse link), every effort should be made to ensurethat this is the exception rather than the rule. Also, since the mobile only has three rake fingers, ifthere are, say, 4 equal pilots, the mobile will assign 3 fingers to 3 of them, leaving the 4th as aninterferer. This will require a higher forward power allocation to overcome this interference and hencelower capacity.
The following three sections describe how to load survey data into a mapping tool to generateplots that will indicate which sites are candidates for antenna changes. The source data usedshould represent one entire drive of the system/cluster:
1. Generate files containing lat/long and handoff state (by number of sectors - not channelelements). Use 6 colours to identify the number of sectors involved and generate one plot forthe 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 -16to -8 with a step of 2. Generate one plot for the entire system/cluster. (The Nortel RFOptimizer can generate these plots automatically).
3. After studying the above plots, create a list of sectors which are possible contributors to thehigh handoff or poor Ec/Io areas. For each of these sectors, the idea is to generate a plot forthat sector alone showing where that pilot is appearing. Three types of per-pilot plots can beused; strongest rake finger, any rake finger, any occurrence in a PSMM. The value to beplotted is the Ec/Io. Suggested settings are -16 to -8 with a step of 2. Generate plots for onesector 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 forthe 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: Thehandoff state and overall Ec/Io plots should be used as an indicator of the worst case areas forexcessive handoff and interference. In areas of high handoff (4, 5 and 6 way), examine the per-pilot plot for each sector in that area and determine whether each pilot is intended to providecoverage in that area. The three types of per-pilot plot (strongest rake finger, any rake finger, anyoccurrence in a PSMM) will show progressively greater coverage area for a given pilot so someexperimentation will be required to find the clearest picture.
CDMA RF Optimisation Technology Applications Group
Issue 0.8 July 10, 1998 Page 38
If the problems occur along the main beam of the antenna, a downtilt alone should be sufficient. Ifthere are problems along the edge of the antenna beam, also consider a narrower beamwidthantenna and/or a re-orientation. Do not try to remove signal from areas where the mobile transmitpower is above 18dBm (red) since these are the areas where high handoff is actually helping tomaintain the call. To help decide on the exact changes, use single cell signal plots in Planet andexperiment with antenna changes. A signal level reduction that will get the offending pilot belowT_ADD should be calculated and applied before re-driving the area (see appendix 9.5 for anexample calculation). Beware that, as unwanted pilots are removed from an area, the Io is beingreduced and so the next drive of the area may reveal new problem pilots, making this somewhatof an iterative process.
The data for these plots is best taken without any forward link loading since this will raise theEc/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 theabove section, further reduction of handoff should only be contemplated in very unusualcircumstances. 4, 5 and 6 way handoff can be beneficial in many instances where there are manypilots with no dominant server or in a rapidly changing environment. In these cases, the pilots notcurrently being demodulated serve as “hot standbys” to which rake fingers can be assigned veryquickly. 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 beconsidered 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 followingreasons:
• These values have given good results in simulations and field testing to date, particularly withrespect to dropped call rate.
• In “pilot polution areas”, the Ec/Io levels of the active set pilots can be as low as -12 or -13dB. Even with T_ADD at -14dB, a new pilot will not be detected until it is almost equal instrength with the current pilots. By the time the mobile has measured it, sent a Pilot StrengthMeasurement Message, the system has set up resources and sent back an Extended HandoffDirection Message, the forward link is often to poor for this to reach the mobile and he calldrops. 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 reverselink coverage has been designed assuming 4dB soft handoff gain, we can calculate (for a propagationslope of 3.5) that the last 4dB of the cell radius represents an area of 42%. Therefore, 42% of the cellarea 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 ofreverse link coverage) would be a very bad thing to do. This is a very simplistic calculation and also thecell overlap that you will always get in a real design will help a lot with the reverse link coverage but itindicates 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).
CDMA RF Optimisation Technology Applications Group
Issue 0.8 July 10, 1998 Page 39
6.6. Search Windows
The search sequence for mobile that has two active pilots and a neighbour list of three PNs isroughly as follows (the actual algorithm will be specific to individual handset manufacturers butthis will illustrate the principle):
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 timesfor the SRCH_WIN_A/N/R windows. Minimising the search time is crucial to CDMA performance, bothto avoid dropped calls (due to a new pilot increasing very rapidly) and to maximise capacity (any delay inadding a new neighbour into the active set means it is effectively an interferer and hence more power isrequired to maintain the desired FER).
However, the chip sets commonly used in current handsets cannot search infinitely fast. Setting the searchwindows too small will not result in a worthwhile speed improvement and may risk missing someimportant signal energy or a new neighbour. The following table gives the acceptable search windowcombinations:
CDMA RF Optimisation Technology Applications Group
Issue 0.8 July 10, 1998 Page 40
The following table gives the datafill, maximum delay and corresponding distance for various windowsizes:
Window size (chips) Datafill Value Max Delay (uS) Distance (km)
14 (+7) 4 5.7 1.71
20 (+10) 5 8.1 2.44
28 (+14) 6 11.4 3.42
40 (+20) 7 16.3 4.88
60 (+30) 8 24.4 7.32
80 (+40) 9 32.6 9.76
100 (+50) a 40.7 12.20
130 (+65) b 52.9 15.86
160 (+80) c 65.1 19.52
226 (+113) d 92.0 27.57
The following three sections explain how to establish a search window settings that are consistent withthe 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 pilotonly. This is the basis for setting the optimum value for SRCH_WIN_A.
Finger Packet
Packet Size: 15
Pilot Offset EcI0
312 0.00 -10.61 Locked
312 1.32 -14.38 Locked
320 0.10 -14.28 Locked
E.g. In the above finger packet, 2 fingers are locked to PN 312 so the 1.32uS offset wouldcontribute to the histogram.
CDMA RF Optimisation Technology Applications Group
Issue 0.8 July 10, 1998 Page 41
Gather all the histogram files for one entire network/cluster run. Classify the areas by average cellsize (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 thehistogram against the “Max Delay” column in the above table and choose a window size that willcapture 95% of the finger separations. Check the shape of the histogram to ensure that theexisting window setting is not already too small (i.e. is there a sharp cutoff at the current windowsetting). In this case, more data will have to be collected with a wider window setting before aproper 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 followingcalculations can be performed:
For an active window setting of 60 chips and assuming the window is centered on the main ray from thecellsite, a multipath component that just falls inside the window will have traveled an extra 7.3km (30chips @ 0.244km/chip = 7.3km).
For a nominal 2km radius and assuming a best case of free space path loss and no reflection loss, themultipath will be 20log(9.3/2) = 13dB lower than the main path. At the cell edge, even for an unloadedsystem, 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 spacethe multipath will be 7.8dB lower (-12.8dB Ec/Io if we continue with the 5dB Ec/Io main rayassumption) while assuming a 3.5 exponent the multipath will be 13.7dB down (-18.7dB Ec/Io). The freespace 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 5kmcase, the free space multipath component will be 4.5dB down (-9.5dB Ec/Io) while the 3.5 exponentmultipath will be 7.9dB down (-12.9dB Ec/Io).
Clearly the 5km case could benefit from a larger active search window since components falling justoutside the window would be appreciable interferers. For the 2km case, the 3.5 exponent still gives only amarginal benefit. However, the free space case would be of value but how realistic is a free spaceassumption?
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 neighbourswith a neighbour window setting of 100 chips. With an active window of 28 chips, the search time willbe 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.
CDMA RF Optimisation Technology Applications Group
Issue 0.8 July 10, 1998 Page 42
6.6.2. SRCH_WIN_N
In the Pilot Strength Measurement Messages, the mobile reports the phase of the pilots to thenearest chip resolution. Unless this pilot comes from another sector of the reference cell, therewill likely be some offset from an exact PN (multiple of 64 chips). For example, in a system withPilot_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:
Generate histograms of the offsets as described above. This is the basis for setting the optimumvalue for SRCH_WIN_N.
Gather all the histogram files for one entire network/cluster run. Classify the areas by average cellsize (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 thehistogram against the possible window settings in IS-95/J-STD 008. The histogram should bebiased to the positive side (i.e. pilots delayed from the reference are more common than earlyarriving pilots). Remembering that the window is centered around the reference, choose a windowsetting that covers 99% of the offsets. E.g. if 99% of offsets corresponds to, say, 47 chips, thenext highest “half window” is 50 chips so a window setting of 100 chips (datafill of 10) would beappropriate. Check the shape of the histogram to ensure that the existing window setting is notalready too small (i.e. is there a sharp cutoff at the current window setting). In this case, moredata 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 pilotsmissing from the neighbour list will be captured but also allows slightly more distant “stray” pilotsto be detected.
Since these windows perform the same function for the BTS as SRCH_WIN_A does for themobile, the same analysis result can be used. Say the 95% point on the histogram was 12.4uS or15.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 settingsshould always be multiples of 125 i.e. 125 (for this example), 250,375, 500, 625 etc.
CDMA RF Optimisation Technology Applications Group
Issue 0.8 July 10, 1998 Page 43
6.7. Neighbour Lists
Remembering that every Pilot Strength Measurement Message contains a pilot which isdesignated as the reference pilot, the basic rules of neighbour list adjustment based on live dataare:
1. Any pilot that is requested to be added in a Pilot Strength Measurement Message should be inthe neighbour list of the reference pilot in that PSMM.
2. Any pilots that are currently in the reference cell’s neighbour list but never occur in aPilotStrengthMeasurementMessage should be removed from that neighbour list.
For example, consider the following NeighborListTuningArray (the NeighborListTuningArray issimply a repeat of the PilotStrengthMeasurementMessage with extended baseid included):
Base ID Sector Band Class CDMA Freq Pilot Strength Keep Bit Pilot_PN
PN 220 is the reference (since it ocurrs first in the message) so we are working on the neighbourlist for that sector. PN 216 is being dropped so we do not consider it in this analysis. PNs 192 and212 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 attainedthrough normal drive testing. Also, since the data represents actual traffic patterns, there is far lessrisk of making bad neighbour list decisions because of the drive test routes chosen. Finally, sincethe 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 entrywas missing, first refer to the predictions and determine whether that pilot is intended to coverthat area. If not, the problem should be remedied with antenna adjustments. Only if it isdetermined that a genuine neighbour list omission has been found should the pilot be added to thereference cell’s neighbour list.
CDMA RF Optimisation Technology Applications Group
Issue 0.8 July 10, 1998 Page 44
For cases 2 and 3, generate a per-site histogram of all the handoff transitions requested by thedrive test mobiles over a complete drive of the system/cluster. The reference cell determineswhich sector’s neighbour list is being examined. Further refinement can be added by including themax, min and average Ec/Io for each entry. This is particularly useful for pilots found by aRemaining Set search since the frequency of occurrence may be low yet the strength may be high.
The above represents the output for one sector (KC104x in this example) and that 6036 NLTArecords were logged with this sector as the reference. There is one entry for every PN that occurswhen KC104x is the reference pilot (it is shown here with sector designations but the tool couldbe made to display PNs or baseids). Each entry contains the number of times that sector isrequested, the percentage that represents and the average Ec/Io. Underlined sectors are those notin 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 goodEc/Io) but should be added to KC104x’s NL. KC96z should be probably removed (unless it is animmediate neighbour and it is just low traffic that is causing this characteristic). KC208x isprobably being found through the Remaining Set search (low “hits” but good Ec/Io) and shouldbe added if it is determined that it does not need removing from the area through RF coveragecontrol.
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 theminimum for that sector to be analysed. Consider removing any pilots that are currently in theneighbour 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 adjacentsectors of a sectored site). Consider adding pilots that are not currently in the neighbour list buthave 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 indropped calls. Remember, though, that long neighbour lists result in longer search times to findnew pilots. During these delays, a new pilot that has not yet been searched is an interferer and thiswill result in a higher forward power allocation from the BTS to overcome the interference. If thisoccurs 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 ofNeighborListTuningArray data.
CDMA RF Optimisation Technology Applications Group
Issue 0.8 July 10, 1998 Page 45
A B C
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 A’s neighbour list. The assumption is that, if C is a handoff candidate thenB certainly will be (if this is not true, there are likely bigger problems to be addressed first). C will be inB’s neighbour list and hence the composite neighbour list sent to the mobile while in the right half of Awill contain C. The advantage occurs when the mobile is in the left half of cell A since the mobile will notwaste search time looking for cell C. Obviously the above diagram is very idealistic. Due to site selectionissues 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 aimshould be to minimise neighbour lists.
Only in exceptional circumstances (e.g. hard handoff border cells) should the BTS neighbour list bedifferent 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, thefollowing 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 thatFER is NOT included as a metric. This is because we are confident that power control works and that ifall other issues are addressed, good FER performance will naturally follow.
CDMA RF Optimisation Technology Applications Group
Issue 0.8 July 10, 1998 Page 46
6.9. Per-Site Analysis
Analysis of data for when the mobile is locked to a single pilot can reveal configuration or performanceissues 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 willhighlight any sites having a significantly different link balance. A site with a high transmit gain adjustmay be suffering from a poor receiver noise figure or may be in a location where forward linkinterference is prevalent. A site with an abnormally low transmit gain adjust may have a low transmitpower.
2. A file containing all lines from the parametric flat file for which the number of pilots locked = 1. Acolumn containing the PN is needed. This will allow additional performance analysis on a per-sitebasis 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 otheranalysis 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 CDPDmulticouplers and likely has a higher noise figure (hence higher TXGA). Subsequent investigationrevealed that the transmit power was 7dB low on the GILDZ sector (hence low TXGA). All othersectors are “normal” (the data was collected with no load on the system, hence the low overall values).
CDMA RF Optimisation Technology Applications Group
Issue 0.8 July 10, 1998 Page 47
Pilot PN Site Average TXGA
8 LGLY -14.411692
60 WROCY -10.224532
68 NWSTY -15.800661
76 HCTR -16.165448
80 SURR -15.964134
84 KNDY -16.857579
88 PANY -13.542665
92 POCO -16.432903
104 CLOV -16.466863
116 GILDY -15.796377
128 MURR -14.556199
136 LHED -16.48573
144 PMAN -14.431992
148 BURNY -10.874728
152 HANY -14.361585
220 WROCZ -16.575031
228 NWSTZ -14.310556
248 PANZ -11.875561
276 GILDZ -22.511815
308 BURNZ -9.3749509
380 WROCX -10.456281
388 NWSTX -13.104353
408 PANX -12.938774
412 COLE -17.127062
436 GILDX -14.196346
468 BURNX -9.9643809
The Nortel RF Optimizer will perform this analysis over many mobile logs automatically.
CDMA RF Optimisation Technology Applications Group
Issue 0.8 July 10, 1998 Page 48
6.10. Capacity
The main requirement for obtaining good CDMA capacity is to eliminate unnecessary handoff andminimise 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
( )
( )N
W R
Eb No vf S=
×× ×
/
/
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 theprocessing gain is used to fight the noise of other users). To design “real” cells, we need to allocate someof 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, thenoise 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 eitherpole capacity or 50% load.
CDMA RF Optimisation Technology Applications Group
Issue 0.8 July 10, 1998 Page 49
The only terms we can influence easily are f and S and since these will also be improved when weoptimise 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 testdata 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 thenumber of users with average forward traffic channel gain and typical soft handoffpercentage for a system/cluster.
Nf f f
f hrf v
Pilot Page Synch
traff=
- + +
× ×
1 ( )
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 onthe collected handoff statistics for the system under test where:
CDMA RF Optimisation Technology Applications Group
Issue 0.8 July 10, 1998 Page 50
( ) ( ) ( )
( ) ( ) ( ) ( ) ( )( )
( ) ( ) ( ) ( )( )
( ) ( ) ( ) ( ) ( ) ( )( )
hrf = + ⋅ + ⋅ +
⋅ + ⋅ + ⋅ + ⋅ + ⋅ ⋅+
⋅ + ⋅ + ⋅ + ⋅ ⋅+
⋅ + ⋅ + ⋅ + ⋅ + ⋅ + ⋅ ⋅
η η η
η η η η η υ
υ
η η η η υ
υ
η η η η η η υ
υ
1 1 1 2 1 3
2 2 2 3 2 4 2 5 2 6 2
3 3 3 4 3 5 3 6 3
4 4 4 5 4 6 5 5 5 6 6 6 4
2 3
2 3 4 5 6
3 4 5 6
4 5 6 5 6 6
, , ,
, , , , ,
, , , ,
, , , , , ,
• δ x η(α,β) is defined as follows:
• δ = number of sources of power control bits the system is having to send to theone mobile
• η(α,β) = the percentage of time the one mobile experienced this type ofhandoff, 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., theadjusted voice activity to account for variations in power gain of the powercontrol bit due handoff involving x cells.
Voice Activity Factor (VAF)
• υ = the average Markov voice activity factor for single sector coverage
υx
x
P full P half
P quarter P eighth p
= ⋅ + ⋅ +
⋅ + ⋅ ⋅ + ⋅
[ ( ) ( ) .
( ) . ( ) . ]
1 056231
2
0 44671
40 3162
1
8
23
24
1
24
• υ = 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 eachcorresponding frame
• 23/24 = the portion of a frame for which the relative power levels apply
CDMA RF Optimisation Technology Applications Group
Issue 0.8 July 10, 1998 Page 51
• 1/24 = the portion of a frame for which the power control power level applies
• 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=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 ourloads that further reduce the power of these frame rates.
6.10.1.2.2. From BTSPerformanceData
The following equation gives the potential loaded capacity of a sector in terms of the number of userswith average per-link power and typical soft handoff percentage for a system/cluster.
Definitions:
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 inisolated 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 ofthis as “links per user”).
6.10.1.2.3. Interpreting the EquationsThe average traffic channel power gives us the average power that one “link” or “connection” to a sectorwill require. The handoff statistics allow us to calculate the capacity penalty due to the fact that one userwill generate “links” to several sectors (or, equivalently, one sector will serve the actual users in it’s ownsector 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 thepeak load on the sector at 100% blocking (equivalent to all radios being used in an AMPS sector). Whenthe system is running at 1% blocking, individual sectors will occasionally peak at 13 users but the averagewill be 6.6 users.
NP P P P
P SPU
CallBlock Pilot Page Sync
Link
=- + +( )
*
CDMA RF Optimisation Technology Applications Group
Issue 0.8 July 10, 1998 Page 52
Note that, unlike a wireline application, the 13 users are not independent “channels” and this number isinfluenced by the average load on the system, in this case 6.6 users (Erlangs). Therefore, it would beerroneous to decide to run a system at 5% blocking and use the Erlang B table to establish that 8.8Erlangs could be carried. If there are, on average, 8.8 users on each sector then, due to the extrainterference in the system, the peak available will be less than 13. Therefore, 8.8 Erlangs/5% blocking isnot a valid combination. Likewise, as the average load decreases below 6.6 Erlangs, the blocking willreduce 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 tounderstand some aspects of BTS operation. Refer to the table at the end of this section (1900MHz BTSillustrated - Nortel employees can retrieve this spreadsheet from the Technology Applications webpageserver and experiment with different settings).
The BTS forward link has two “domains”; the digital domain and the analogue domain. The digitaldomain refers to algorithms involving the digital “gains” that control the output level of each ChannelElement. The analogue domain refers to the total BTS output power as measured at the RFFE Antenna 0on the 1900MHz equipment or the “Demarc” panel on 800MHz equipment and controlled by anattenuator in the upconverter. The “fully blossomed” value of this attenuator is controlled by adatafillable 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 CE’s can only take even values because the LSB is fixed at 0). The output power isthen adjusted using TxAttenNormal until an output power of 4 Watts is obtained (note that this is NOTthe pilot setting since the pilot is actually run at a lower gain i.e. we are NOT “calibrating for a 4Wpilot”). Once this relationship has been established, we can calculate the power equivalent to any gain orcombination of gains.
Example; what is the output power for a) the pilot and b) the pilot + sync + paging if the digital gains arepilot = 186, sync = 60 and paging = 156.
Answer; Since the digital gains are voltage gains, most calculations are in terms of “bits squared” toconvert 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
CDMA RF Optimisation Technology Applications Group
Issue 0.8 July 10, 1998 Page 53
The Transmit Power Tracking Loop (TPTL) is provides a guaranteed linkage between the analogue anddigital domains since it constantly maintains the 2542 – 4Watts relationship. This is achieved using a feedback loop that sums up the current digital gains for all overhead, traffic and OCNS channels, calculatesthe expected output power and compares it to the analogue sensor reading. If the two do not match, anoffset (TPTLOffset) is applied to the upconverter attenuator. Note that accurate calibration is stillrequired since the TPTL will not apply more than +/-6dB of correction. However, great emphasis mustbe placed on confirming the sensor accuracy since TPTL relies on it’s readings. TPTL is in release 6.1.1for 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 fixedvalues datafilled at the BTS on a per-sector basis. The traffic channels vary within a defined range asrequired by forward link power control. The range for the traffic channel gains is datafilled relative topilot power. For example, with a pilot gain of 216, an upper limit of -1dB pilot and a lower limit of -15dBpilot, the selector will send digital gains in the range 192 to 38. Note that the pilot gain is datafilled bothper-sector at the BTS and as a global parameter at the SBS. It is the SBS value that is used to calculatethe digital gains for the traffic channel. Therefore, even if the pilot gain at one sector of a BTS is loweredby, say, 1dB to 192, the SBS will continue to send digital gains in the range 192 to 38. I.e., for this sectoralone, the traffic channels are now effectively 0dB pilot to -14dB pilot.
The forward link Call and HandoffBlockingThresholds are datafilled in terms ofExcessForwardLinkCapacity which is a bits-squared value. ExcessForwardLinkCapacity is calculated asfollows:
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. Ifthe 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 ifthe “blocking threshold reference” is crossed although ExcessForwardLinkCapacity will never bereported as a negative number.
CDMA RF Optimisation Technology Applications Group
Issue 0.8 July 10, 1998 Page 54
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 toreport the total power at the demarc panel (800MHz) or the RFFE output (1900MHz). The report fromthis sensor is in units of 1/16th dBm. Beware that this sensor is not immune to the waveform of thetransmitted signal and since the sensor has been deliberately calibrated for the “most likely” situations, anoffset 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 isexceeded, the BTS will wilt the sector by one step and re-compare the reading with TxPowerMax. This isthe Power Limiting algorithm and it repeats until the power no longer exceeds TxPowerMax. This limitsthe output power to TxPowerMax. However, forward link power control will act in opposition to thepower limiting, possibly causing an unstable situation. For this reason, this algorithm should be viewed asan HPA protection mechanism only and the blocking thresholds should be set such that Power Limiting isa rare occurrence. The FwdHandoffBlockingThreshold should be at a higher power than theFwdCallBlockingThreshold (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 changesor 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 tosystem performance) is to use attenuators in the antenna cables.
Table ?: BTS Forward Link Power and Blocking Calculations
Power Power Sector- Percentage
dB relative Notes
Key Calculation Datafill
Bitssquare
(Watts) (dBm) TxPower of pilot to pilot
Pilot a 186 34596 2.14 33.31 100.00 0.00
Sync b 60 3600 0.22 23.49 10.41 -9.83
Paging (Half Rate) c 156 12168 0.75 28.78 35.17 -4.54
Total Overhead d a + b + c 50364 3.12 34.95 559 1.63
Typical User Traff Chan Gain e (97^2)*VAF*1.15 3895 0.242 23.83 -9.48 5)
CDMA RF Optimisation Technology Applications Group
Issue 0.8 July 10, 1998 Page 55
MinPilotToTotalPowerRatio f -135 1)
Blocking Threshold Reference g a / 10^(f/160) 241421 14.97 41.75 668 1), 4)
CallBlockingThreshold h 61000 61000 3.78
HandoffBlockingThreshold i 0 0 0.00
% of TXPowerMax
Calls will block at: j g - h 180421 11.19 40.49 647 90.1 3)
Handoffs will block at: k g - i 241421 14.97 41.75 668 120.6 Beware >TXPowerMax
Capacity Stuff
Number of connections n (j - d)/e 29.0
Sectors per user o 2.2
Sector Capacity q n/o 13.2
Pilot % Pilot dB down
TXPowerMax s 655 12.41 40.94 655 17.28 -7.62
Notes
1) Remember the calculation STARTS from the pilot power - MinPilotToTotalPowerRatio doesNOT 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 arereferenced 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 throughoutthe network. However, sometimes there will be a requirement to improve capacity still further over asmall 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 andunnecessary handoff will both lead to higher capacity. It is important to stress the unnecessary handoffsince, taken too far, handoff reduction will result in poor performance of the forward link in terms ofdropped calls, FER and capacity.
The following strategies should be considered for improving capacity over a small area (the “hotspot”):
CDMA RF Optimisation Technology Applications Group
Issue 0.8 July 10, 1998 Page 56
• Removing interfering handoff from other sectors: If the mobile is going into handoff with sectorsoutside the hotspot area and this is causing handoff in excess of 3-way, those sectors should beremoved by downtilting/antenna change/orientation change/power reduction (remember to reduce thereverse link as well). Since the mobile has only three rake fingers, consistent handoff above 3-wayrequires more traffic channel power to overcome the interference from the active set members thatare not being demodulated.
• Removing interfering power from other sectors: If sectors outside the hotspot are transmitting powerinto the hotspot but the Ec/Io is too low for the mobile to go into handoff, those sectors should beremoved by downtilting/antenna change/orientation change/power reduction (remember to reduce thereverse link as well). These interfering sectors result in a need for more traffic channel power toovercome the interference and maintain FER.
• Reducing handoff within the hotspot: If pilot quality is good throughout the hotspot, a reduction inpilot gain by 1 or 2dB on the hotspot sectors can be very effective. Since the traffic channels willremain at the same absolute level as before, this has the effect of lowering the Ec/Io of the hotspotsectors and hence reducing handoff. This is much more effective than increasing T_ADD andT_DROP for three reasons:
1. Raising T_ADD and T_DROP must be done on the surrounding sectors as well as the hotspotsectors 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 theother hand, targets the hotspot sectors very specifically and will also allow surrounding sectors topick up some of the traffic since it actually shifts the handoff boundaries rather than just reducinghandoff.
2. Because of the rules for updating T_ADD and T_DROP (most negative value for any of theactive set), many more sectors need to be changed than are really required. This may causeproblems 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 ofmuch simulation and field testing effort (reference power control report). Target frame error rates may beadjusted if the average frame error rates are not meeting customer expectations (changes to the reverselink should be done by scaling all 5 targets). Changes to the step sizes or the upper/lower/start valuesshould not be contemplated unless a specific set of carefully designed tests are carried out solely for thispurpose.
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 workswith non-equal per-rate target FERs)
CDMA RF Optimisation Technology Applications Group
Issue 0.8 July 10, 1998 Page 57
6.12. Hard Handoff
(This section under construction - main aim is to achieve trigger conditions that result in the transition toa 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 idlemode 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 it’s reference cell. The propagation delay in terms of chips for 2km is2/0.244 = 8.2 chips.
• The mobile will use this signal for it’s timing reference so it’s timing is now 8.2 chips “late” relative tosystem 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, thesignal arrives 8.2 + 8.2 = 16.4 chips “late”.
• This is would be the RTD measurement if the BTS were making all it’s measurements right at theantenna. In reality, there is some processing delay on both the transmit and receive paths internal tothe BTS. Two parameters, FwdDistributionDelay and RvsDistributionDelay, are available toeffectively “zero” out this internal delay. If these have been datafilled correctly then all RTDcalculations only need to take the “over the air” delay into account. Otherwise, the sum of these twoparameters will effectively be added to all RTD measurements. The DistributionDelays are datafilledin 1/8th chip units. RTD is also reported by the system in 1/8th chip units. A report is generated everytime the RTD changes by 2 chips.
Example: What is the required datafill value for an RTD triggered hard handoff to occur at 1km from acell a) if the DistributionDelays have been set correctly and b) if the DistributionDelays have been left at 0on 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 theDistributionDelays is in 1/8th chip units and is 79 + 212 = 291. Therefore, the datafill required for b) is291 + 66 = 357.
6.13. Other
Future revisions of this document will contain sections on the following:
CDMA RF Optimisation Technology Applications Group
Issue 0.8 July 10, 1998 Page 58
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 fieldissues that will be encountered throughout the network. Section 8 will cover issues specific tospecial cases.
7.1. Successful Call
This section explains the characteristics in the data for a phone that originates succesfully, remains in theservice 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_PWRsetting)
• 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 andreleased 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 BTSacquires the reverse traffic channel. All transmissions are 1/8 rate null frames)
• Forward Acknowledgement (received from SBS on traffic channel - acknowledges acquisition ofreverse 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 thetraffic channel).
• Service Connect Complete Message (sent to SBS - we consider a successful origination to have beenmade 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 samePNs requested by the mobile).
CDMA RF Optimisation Technology Applications Group
Issue 0.8 July 10, 1998 Page 59
• Handoff Completion Message (sent to SBS - confirms receipt of Extended Handoff DirectionMessage).
• 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:
• Receive power > -100dBm
• Transmit power < +18dBm
• Normal Transmit Gain Adjust (actual value depends on site configurations, loading, NOM_PWRsetting)
• 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
A message flow file for the same basic call will contain the following IS-95 messages: MM 01:12:02.5850 I95_AChanOriginationMsgType AS:7 MS:5 AR:1
MM 01:12:02.7287 I95_PChanCDMAChannelListMsgType PPN:320
MM 01:12:02.8475 I95_PChanOrderMsgType
MM 01:12:03.1475 I95_PChanExtendedSystemParametersMsgType PPN:320
MM 01:12:03.1688 I95_PChanGeneralPageMsgType
MM 01:12:03.6687 I95_PChanChannelAssignmentMsgType
SS 01:12:03.7400 I95_FTChanOrderMsgType AS:7 MS:0 AR:1 OR:16
MM 01:12:03.8087 I95_FTChanOrderMsgType AS:7 MS:0 AR:1 OR:16
MM 01:12:03.8863 I95_RTChanOrderMsgType AS:0 MS:0 AR:0 OR:16
SS 01:12:03.9200 I95_RTChanOrderMsgType AS:0 MS:0 AR:0 OR:16
SS 01:12:03.9400 I95_FTChanPowerControlParametersMsgType
SS 01:12:03.9600 I95_FTChanServiceConnectMsgType AS:7 MS:2 AR:1
MM 01:12:04.0075 I95_FTChanPowerControlParametersMsgType
MM 01:12:04.0288 I95_FTChanServiceConnectMsgType AS:7 MS:2 AR:1
MM 01:12:04.0675 I95_RTChanServiceConnectCompletionMsgTyp AS:1 MS:0 AR:1
SS 01:12:04.1000 I95_RTChanServiceConnectCompletionMsgTyp AS:1 MS:0 AR:1
MM 01:12:04.1075 I95_RTChanOrderMsgType AS:2 MS:1 AR:0 OR:16
SS 01:12:04.1400 I95_RTChanOrderMsgType AS:2 MS:1 AR:0 OR:16
SS 01:12:04.2200 I95_FTChanOrderMsgType AS:0 MS:0 AR:0 OR:16
MM 01:12:04.2887 I95_FTChanOrderMsgType AS:0 MS:0 AR:0 OR:16
CDMA RF Optimisation Technology Applications Group
Issue 0.8 July 10, 1998 Page 60
MM 01:12:05.2075 I95_RTChanPilotStrengthMeasurementMsgType AS:2 MS:1 AR:1PPNs:320R:( -7.00)K 312:(-12.50)K
SS 01:12:05.2400 I95_RTChanPilotStrengthMeasurementMsgType AS:2 MS:1 AR:1PPNs:320R:( -7.00)K 312:(-12.50)K
SS 01:12:05.6800 I95_RTChanOrderMsgType AS:4 MS:5 AR:0 OR:16
SS 01:12:12.9400 I95_FTChanServiceOptionControlMsgType AS:2 MS:5 AR:1
MM 01:12:13.0287 I95_FTChanServiceOptionControlMsgType AS:2 MS:5 AR:1
MM 01:12:13.1075 I95_RTChanOrderMsgType AS:5 MS:6 AR:0 OR:16
SS 01:12:13.1400 I95_RTChanOrderMsgType AS:5 MS:6 AR:0 OR:16
SS 01:13:45.1000 I95_FTChanServiceOptionControlMsgType AS:4 MS:0 AR:1
MM 01:13:45.1888 I95_FTChanServiceOptionControlMsgType AS:4 MS:0 AR:1
MM 01:13:45.2288 I95_RTChanServiceOptionControlMsgType AS:0 MS:3 AR:0
SS 01:13:45.5200 I95_FTChanServiceOptionControlMsgType AS:4 MS:0 AR:1
MM 01:13:45.6100 I95_FTChanServiceOptionControlMsgType AS:4 MS:0 AR:1
MM 01:13:45.6875 I95_RTChanOrderMsgType AS:0 MS:4 AR:0 OR:16
SS 01:13:45.7200 I95_RTChanOrderMsgType AS:0 MS:4 AR:0 OR:16
MM 01:13:52.3275 I95_RTChanOrderMsgType AS:0 MS:5 AR:1 OR:21
SS 01:13:52.3600 I95_RTChanOrderMsgType AS:0 MS:5 AR:1 OR:21
SS 01:13:52.4400 I95_FTChanOrderMsgType AS:5 MS:1 AR:0 OR:21
MM 01:13:52.5087 I95_FTChanOrderMsgType AS:5 MS:1 AR:0 OR:21
MM 01:13:52.9725 I95_SChanSyncMsgType PPN:312
CDMA RF Optimisation Technology Applications Group
Issue 0.8 July 10, 1998 Page 61
Note how the message sequence and acknowledge sequence numbers work e.g. if a Pilot StrengthMeasurement Message is sent with msg seq 3, the Extended Handoff Direction Message will have an ackseq 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 proceedingnormally, every traffic channel message will appear twice, once at each logging point).
Order type 21 is a release message.
CDMA RF Optimisation Technology Applications Group
Issue 0.8 July 10, 1998 Page 62
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 - dropspaging channel
1 or more probes (have seen upto 5), no Ack or CA at mobile,then immediately back to SYNC.Poor Ec/Io. Lots of Bad PagingChannel CRCs.
Control RF to reducecases of multiple pilotswith no dominant server.
Does pilot selection algorithm needimproving?
Bad pilot choice - missedChannel Assignment Msg
Mobile receives P-channel orderand stops probing but no CAseen. Selector logs will haveNOIS msgs setting up resourcesetc.
Control RF to reducecases of multiple pilotswith no dominant server.
Does pilot selection algorithm needimproving?
Bad pilot choice - fails toacquire fwd tch
Mobile receives channelasignment but goes to SYNCwithin 1 second. Selector powercontrol setpoints at selectorfrozen at starting values. Mobilenever enables its transmitter.
Control RF to reducecases of multiple pilotswith no dominant server.Increase PTX start to -1dB.
Does pilot selection algorithm needimproving? Also, fix introduced in2.4.5 that temporarily increasesfwd TCH gain by 5.5dB duringacquisition phase.
Bad pilot choice - distantPN
At the end of a call, mobilechooses to Sync to a distant PNeven though better local PNs areapparently available. Nextorigination fails becauseNeighbour List of distant PNdoes not contain any of the localPNs.
Downtilt distant PN ifpossible.
Mobile algorithm only looks forfirst adequate PN rather than thebest PN. Does pilot selectionalgorithm need improving?
Bad pilot choice - beforeSVC
Forward link dies before firsthandoff can be completed (andstill before Service Connect(Complete) messages). Usuallysee multiple EHODs and ServiceConnects from selector but notarriving at mobile.
Control RF to reducecases of multiple pilotswith no dominant server.
Does pilot selection algorithm needimproving?
CDMA RF Optimisation Technology Applications Group
Issue 0.8 July 10, 1998 Page 63
Dropped Calls
Slow handoff Mobile requests handoff to newpilot (which was in NL), selectorsees PSMM, starts sendingEHODs but none arrive at mobilebecause new PN is interferer(stays as candidate). Mobile willlikely SYNC to pilot it wasrequesting. Poor Ec/Io, high fwderasures
Minimise search time byoptimsing SRCH_WINs(especially A but don't gobelow 28 chips), trimmingneighbour lists andreducing the number ofway HO by controllingRF. If new pilot increasesin strength suddenly, lookat alternative antennaarrangements.
Currently highest reason fordropped calls. Do N and A windowanalysis asap in the optimisationprocess. Don't forget to trim yourneighbour lists after doingdowntilts. Selector selnt05aa hasquickrepeat and higher gain onEHOD to mitigate this problem.
Coverage Mobile RX close to or below -100dBm. Mobile TX above+18dBm. Bad erasures bothways, poor Ec/Io. High selectorpower control setpoints.
If you really needcoverage here and none ofthe existing cellsites canbe "persuaded" to cover itthen you need a newcellsite.
PN Aliasing Mobile sees and requests handoffto a PN in the neighbour list butcall continues to degrade anddies with all symptoms of fwdlink interference (good RX, poorEc/Io, high erasures).
Inspection of the PilotDatabase neighbour listreveals that the PNactually refers to a re-useof that PN and not the onethe mobile is headingtowards. PN re-tunerequired.
Mobile fails to sendHandoff CompletionMessage
Mobile sends Ack to ExtendedHandoff Direction Message butdoesn't follow up with HOC.Selector times-out waiting forHOC.
Mobile fix required. Mobile has NOT acted on theEHOD (has not updated its ActiveSet).
Pilot not in neighbour list Good mobile RX power but poorEc/Io and erasures. Usual causeof death is messaging failure onfwd link. After drop, mobileSYNCs to a pilot that wasn't inlast neighbour list update.PSMMs unlikely (although maybe picked up on Remaining Setsearch).
First see if the pilot thatcaused the drop isintended to serve thatarea. If not, control thecoverage (downtilt etc.). Ifit is (or it can't beremoved from that area)then a neighbour listchange is reqd.
Don't forget to re-assess yourneighbour lists after doingdowntilts - can any be removed?
Un-identified Interferer Good mobile RX power but poorEc/Io and erasures. Usual causeof death is messaging failure onfwd link. After drop, mobileSYNCs to a pilot that was in lastneighbour list update but noPSMMs sent.
Essentially a neighbourlist problem as above butinterference has goneaway by time mobile syncsso hard to tell who it is.Driving area very slowlycan often reveal theinterfering PN. Easier tosee with OCNS off.
CDMA RF Optimisation Technology Applications Group
Issue 0.8 July 10, 1998 Page 64
Pilot outsideSRCH_WIN_N
Good mobile RX power but poorEc/Io and erasures. Usual causeof death is messaging failure onfwd link. After drop, mobileSYNCs to a pilot that was in lastneighbour list update but noPSMMs sent.
First see if the pilot thatcaused the drop isintended to serve thatarea. If not, control thecoverage (downtilt etc.). Ifit is (or it can't beremoved from that area)then need widerSRCH_WIN_N on sites inthat area.
Beware, SRCH_WIN_N cannotcurrently be updated during a callso mobiles originating in otherparts of network will not have thewider window. Likewise, mobilesoriginating in this area will carrythe wider window for duration ofcall.
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 interferencefrom a source outside the CDMA system being optimised.
Some likely sources of interference are: intermodulation from an AMPS-only BTS, co-channelinterference from an AMPS BTS that has not been cleared from the CDMA channel, an adjacent CDMAoperator using the same channel (this will remain until inter-system soft handoff is available), amicrowave link, raised noise floor due to the transmitter spectrum of another CDMA operator in thesame 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 ofthe 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 itis the same mesage).
CDMA RF Optimisation Technology Applications Group
Issue 0.8 July 10, 1998 Page 65
• 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 parametricfiles 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 goto the sync channel.
• If the selector repeats a message 5 times without seeing the ack, it will send a forward release and thecall will be torn down. If the mobile sees the release, it will respond with a reverse release and stoptransmitting.Otherwise, it will timeout when no good frames are received for TBD secs.
7.3.2 Analysis with Selector Logs
Using the full parametric files, the following can be established:
7.3.3. Further Analysis
7.3.4 Corrective Action
7.7. Site Not In Service
i.e. pilot/paging/sync are being broadcast but can’t 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 requestingsite 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
CDMA RF Optimisation Technology Applications Group
Issue 0.8 July 10, 1998 Page 66
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 withproblem
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)
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 calldrops
Rvs: (high TXGA, high TX)
CDMA RF Optimisation Technology Applications Group
Issue 0.8 July 10, 1998 Page 67
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 - competitior’s TX noise floor will interferewith fwd link
7.14.1 Symptoms in Mobile Data
Looks like fwd interference (good RX, poor Ec/Io, poor FER, high TXGA)
CDMA RF Optimisation Technology Applications Group
Issue 0.8 July 10, 1998 Page 68
8. Other Optimisation Procedures and Special Cases
8.1. 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, canbe 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 beenput 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…)
CDMA RF Optimisation Technology Applications Group
Issue 0.8 July 10, 1998 Page 69
9. Appendices
9.1. Sample Mobile Data Log Sheets
DATE: (YYMMDD) VAN CREW: RUN #:
TEST:
ROUTE:
VEHICLE MIN CALL
TYPE
RATE SBSLOGS
2ND
PHONE
LOGFILE
B N Q M V 13 8 Y N Y N M
B N Q M V 13 8 Y N Y N M
DATA COLLECTION SOFTWARE: HANDSET SOFTWARE:
NETWORK SOFTWARE: LOGMASK:
# SITES ACTIVE: SITES NOT AVAILABLE:START TIME STOP TIME
The top portion of a mobile log file appears above, a complete set of log sheets can be found in Appendixxxx. The engineer monitoring the data collection tool was required to keep this detailed log throughoutthe 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 datacollection 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 incase 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 datacollection. This information is vital in the event that a problem is subsequently identified with the datacollection 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 Nortelvan, Q indicated the Qualcomm van, and B indicated the BCTel van.
MIN: The mobile identification number used for the data collection.
CDMA RF Optimisation Technology Applications Group
Issue 0.8 July 10, 1998 Page 70
Call Type: The appropriate letter was circled to indicate the type of call being used for the testing. Mindicated 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 duringtesting, 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. Theselog 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 theGPS 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 toquickly code the event. As Vancouver has many bridges and bridges had been identified as potentialproblem 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 circledas handoffs occur.
Location: The street and direction being traveled is entered at the beginning of each run, then all crossstreets are recorded as they are crossed. When the vehicle turns, the street and the new direction isentered. This information is especially useful when trying to determine if a drop occurred in an areawhere there was no coverage.
Last Modified: 04/22/99 09:26 AM
CDMA RF Optimisation Technology Applications Group
Issue 0.8 July 10, 1998 Page 71
DATE: (YYMMDD) VAN CREW: RUN #:
TEST:
ROUTE:
VEHICLE MIN CALL
TYPE
RATE SBSLOGS
2ND
PHONE
LOGFILE
B N Q M V 13 8 Y N Y N M
B N Q M V 13 8 Y N Y N M
DATA COLLECTION SOFTWARE: HANDSET SOFTWARE:
NETWORK SOFTWARE: LOGMASK:
# SITES ACTIVE: SITES NOT AVAILABLE:START TIME STOP TIME
CDMA RF Optimisation Technology Applications Group
Issue 0.8 July 10, 1998 Page 73
DATE: (YYMMDD) CONTINUATION SHEET: ___ OF ____ RUN #:
TEST:
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?
CDMA RF Optimisation Technology Applications Group
Issue 0.8 July 10, 1998 Page 74
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 methodallows 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 byPlanet but a maximum of 50 files can be loaded at any one time (true at release 2.5.12). The files shouldbe place in the “results” directory. For every survey file, a corresponding header file needs to be createdin the “head” directory (the contents are not critical for merely displaying data). Use a script such as thefollowing 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 toadjust 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. Movingfrom left to right across the rows, the following items appear.
CDMA RF Optimisation Technology Applications Group
Issue 0.8 July 10, 1998 Page 75
First row
PN Offset: in decimal
Receive State: uses the following codes:
0: Pilot Channel Acquisition
1: Sync Channel Acquisition
2: Idle
3: Access
4: Traffic Channel
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) or66.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: 960727
General Notes/System Status:
16-Cells on air
BTS/BSC S/W is 2.2 with the following revisions:Integration Lab version 6,
Note: 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 therequired results since the Io will also reduce when this pilot is lowered. A quick way to find out the Ioreduction 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.
