nck CDMA RF Optimisation Guidelines Issue 0.8 July 10, 1998 Martin Kendall Technology Applications Group Dept.: 7455 PROPRIETARY INFORMATION: The information contained in this document is the property of Nortel Wireless Networks. Except as specifically authorized in writing, the holder of this document shall keep all information contained herein confidential and shall protect. ‘same in whole or in part from disclosure and dissemination to third parties. © Nortel Wireless Networks 1998 All Rights ReservedCDMA RF Optimisatior Technology Applications Group 1. About Issue 0.8 6 Introduction a 2.1. CDMA Optimisation Overview 7 2.1.1. Pre-Commercial 7 21.2. Commercial 7 2.1.3. System Expansion 7 22. Related Documents 8 2.3. Scope of this Document 8 24. Revision History 8 24. Contributors 9 2.5. Audience i ‘Optimisation Procedure 10 3.1. Entrance Criteria 10 3.2. Sequence of Events 10 3.2.1, Pre-Commercial 10 3.2.1.1. First Pass: Unloaded 10 3.2.1.2. Second Pass: Loaded u 32.2. Commercial 2 3.3. Exit Criteria R 4. Initial System Parameters B 4.1. Datafill Example 13 42. Types of Parameters 2B 4.2.1, 1S-95/1-STD-008 vs. Nortel Specific B 4.22. Global/Sector SpecificBSCIBTS B 4.23. Setting Parameters 1s 42. PN Planning Is 42.1. ‘Co-PN" 15 422. “Adjacent PN” 16 4.3. Initial Neighbour List Generation 16 44. BTS Calibration 7 45. Search Windows 18 4.5.1, SRCH_WIN_A, AccessChannelDemodulationSearchWidth, TrafficChannelDemodulationSearchWidth 19 4.5.2. SRCH_WIN_N, SRCH_WIN_R 20 453. AccessChannelAcquisitionSearchWidth, TrafficChannelAcquisitionSearchWidth 20 4.6. Neighbor Configuration File, Seineighbor and Checkneighbor 20 5. Data Collection 2B 5.1. Tools 23 5.1.1. Mobile Data Collection 23 ‘$.1.2. Test Van RF Configuration 23 Issue 0.8 July 10, 1998 Page 2CDMA RE Optimisation ___........__-_—Technology Applications Group 5.1.3. The Base Station Manager (BSM) 4 5.2. Simulating Loading 2m 5.2.1. Forward Link wm 5.2.2. Reverse Link 25 5.3, Data Required 26 53.1. Selector Log Mask 26 5.3.2, Mobile Log Mask Bw 5.4. Drive Testing 29 $4.1. Shakedown 2 5.4.2. Drive Routes 29 542.1 Drive Route Selection 29 5.4.2.2. Benchmark Route 30 Driving with only one cluster of cells on air 30 5.4.3. Test Calls 30 544, Logging 30 5.4.4.1. Data Collection Restrictions. 30 5.4.4.2. Logging Strategy 31 5.5. Data Management 32 5.5.1 Data Transfer and Tracking 32 6. Data Analysis Procedures 3 6.1. Tools 33 6.2. Datafll Audit and Shakedown 33 6.2.1. Datafill Audit 33 62.2. Shakedown Data Analysis 3 6.3. System Access 33 63.1. Access Failure Analysis 33 632. Access Success Rate 34 63.3. Access Parameter Tuning En 6.4. Dropped Calls 34 64.1. Link Supervision 34 64.1.1 Mobile 34 64.12 SBS 35 642. “Analysis 35 643. Dropped Call Rate 36 65. RF Coverage/Handoff Control 36 6.6. Search Windows 39 66.1. SRCH_WIN_A 40 6.6.2. _SRCH_WIN_N 42 6.6.3. SRCH_WIN_R 42 66.4. BTS AccessChannelDemodulationSearchWidth, TrafficChannelDemodulationSearchWidth 2 67. Neighbour Lists 8 6.8. Performance/Trend Analysis “6 6.9. Per-Site Analysis 6 6.10. Capacity 48 6.10.1. Capacity Equations 48 6.0.1.1. Reverse Link 48 Issue 0.8 July 10, 1998 Page 3CDMA RF Optimisation _____..4.|..... Technology Applications Group 6.10.1.2. Forward Link 9 6.10.1.2.1. From Drive Test Data 9 6.10.1.2.2. From BTSPerformanceData 31 6.10.1.2.3. Interpreting the Equations 31 6.10.2. BTS Operation 32 6.10.2.1. BTS Calibration 52 6.10.2.2. The Digital Domain, Forward Power Control and the Forward Blocking Thresholds 53 6.10.23. The Analogue Domain, Power Sensor and Power Limiting 54 6.10.3. Optimising for Forward Link Capacity 55 6.1. Power Control 56 6.12. Hard Handoff 7 6.12.1. Round Trip Delay (RTD) Caleulations 37 6.13. Other 57 7. Dropped Call and Access Failure Reasons and Solutions 58 7.1. Successful Call 58 7.1.1 Symptoms in Mobile Data 38 7.1.2 Analysis with Selector Logs 39 7.2. Access Fail and Dropped Call Reasons in Single Frequency System 62 7.3. Hard Handoff 4 74, External Interference (Fix this section) “4 Symptoms in Mobile Data 64 ‘Analysis with Selector Logs 65 Further Analysis 65 Corrective Action 65 7.7. Site Not In Service OS ‘Symptoms in Mobile Data 65 ‘Analysis with Selector Logs 65 Funher Analysis 65 Corrective Action 65 7.8. Interference From Non Co-located AMPS Cellite 66 .8.1 Symptoms in Mobile Data 66 Analysis with Selector Logs 66 Further Analysis 66 Corrective Action 66 7.11. Handoff Boundary Balance 66 7.11.1 Symptoms in Mobile Data 66 7.112 Analysis with Selector Logs 66 7.113, Further Analysis 66 TILA Comective Action 66 7.12. __ Interference from Microwave Link (1900) 66 7.12 Symptoms in Mobile Data 66 7.122 Analysis with Selector Logs 6 7.12.3. Further Analysis 6 7124. Corrective Action 6 7.13. __ Interference From Foregin System Mobiles into CDMA BTS 67 7.13.1 Symptoms in Mobile Data a 7.132 Analysis with Selector Logs a Issue 0.8 July 10, 1998 Page 4CDMA RE Optimisation ‘Technology Applications Group 7.133. Further Analysis 67 7.13.4 Corrective Action o 7.14. AMPS A/B Band Coordination 7 7.14.1 Symptoms in Mobile Data 67 8. Other Optimisation Procedures and Special Cases 6 81. Adding New Sites 68 82, Other Special Cases 68 9. Appendices o 9.1. Sample Mobile Data Log Sheets 69 9.2, Importing Files into Planet ” 9.3. QCP Tech Mode Screen ” 9.4, Sample Rundese.txt 75 9.5. Caleulating Required Power Reduction for Unwanted PN 76 Issue 0.8, July 10, 1998 Page 5L About Issue 0.8 To be added to future issues: ¢ hard handoff (both “normal” and f1/f2) - triggers, 2-sectors/one site issue, idle mode options * flow diag balancing traffic across sectors © BTS PerfData * capacity parm tradeoffs determing RTD thresh by logging NLTA and finding RTDs for one way handoff or dominant pilot. © Guard zone spreads © HOD QuickRepeat by sector © SHOR algorithm application * FER © border issues © Access Channel © “Remote Opt” Issue 0.8 July 10, 1998 Page 62.__ Introduction 2.1. CDMA Optimisation Overview ‘The RF optimisation process will necessarily happen in several stages as a network evolves: 2.1.1. Pre-Commercial Efforts will concentrate on: ¢ Systenvcluster shakedown/de-bugging/datafill audit * RF coverage/handoff control © Neighbour lists ‘© Dropped call rate * Access success rate ‘+ Search window settings ‘© Hard handoff success rate A simulated load will likely be applied to the system/cluster for some stages of the optimisation. 2.1.2, Commercial Efforts will concentrate on: ‘© RE coverage/handoff control © Dropped call rate © Access success rate * Hard handoff success rate © Capacity 2.1.3, System Expansion Efforts will concentrate on: ‘* Introduction of new sites ‘© RE coverage/handoff control © Capacity © Dropped call rate © Access success rate © Hard handoff success rate Issue 0.8 July 10, 1998 Page 7CDMA RF Optimisation ||... ____sTechnology Applications Group 2.2, Related Documents CDMA RF System Parameter Guideline for 800 and 1900 MHz, Prasanna Satarasinghe/Brian troup, (Nortel) ! RF Datafill Spreadsheets * IS95A+TSB74 (800MHz)' J-STD-008 (1900MHz)! (above two documents to be combined in IS9SB) ' NoIs? PN Offset Planning Guide, Chu Rui Chang/Jane Wan, (Nortel) Grayson Surveyor Installation and Operation, Lynne Patterson (Nortel) ' Nortel RF Optimizer Manual ' Hard Handoff Deployment Tips, Datafill Verification, and Troubleshooting. David Boettger (Nortel) * Neighbour List Tuning Using the Neighborl istTuningArray, Martin Kendall (Nortel) ' SBS Diagnostic Logging in Commercial Networks, Martin Kendall (Nortel) ' (BTS PeformanceData) The numbers indicate the locations at which Nortel employees may find the latest soft copies of these documents: 1. tamer 145.01 eplaunstectaooa (this document can also be found on this server) 2. ftp to 47.65.105.47, id: anonymous, dir: dist/80.docs 3. https//47.164.163.96:4000/root/bnr/mtx/www/homepages/2n70/2n70.html 2.3. Scope of this Document ‘This document provides technical reference material to aid in the RF optimisation of CDMA systems. It also describes some tools and useful methods that have been employed by the Technology Applications Group. ‘This document does not attempt to cover such topics as scheduling, logistics, interaction with other groups etc. 2.4. Revision History Issue _| Date Reason for up-issue 0.1 |96Aug03 _| First issue, whole of document created. 0.2 __|96Aug30__| Extensive modifications, first release to field Issue 0.8 July 10, 1998 Page 8CDMA RE Optimisation = ———_______ Technology Applications Group 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 _[97Juli4 _ | Major updatés on overall strategy. 0.7 _|975ul22__| Capacity optimisation, initial search windows, many revisions 0.8 —_{|98June26 _ | SRCH_WIN_AJN rules, some cleanup 2.4. Contributors The following are the key contributors to the processes contained in this document and/or to the document itself: Remo Agostino Bill Book David Curtis Rod Djurkovie Joe Heikes Chris Jedrayeki ‘Martin Kendall Robert Keppeler Paul Kibukamusoke Corey Krieger ‘Mike Maragoudakis ‘Andrew Morrison Lynne Patterson Mark Prasse Prasanna Satarasinghe 2.5. Audience This document is intended as a guide to technical personnel wishing to write and implement CDMA RF optimisation procedures. ‘The reader is expected to have prior knowledge of the CDMA system and RF engineering principles. Issue 0.8 July 10, 1998 Page 9DMA RF Optimisation _____..|.|.|.|_______“Technology Applications Group 3.___Optimisation Procedure 3.1. Entrance Criteria ‘The following items represent the minimum entrance criteria for an optimisation exercise: * AIL BTSs should have been correctly installed and calibrated. The calibration values should be entered in the datafill. ‘* The spectrum should be clear down to a level of -110dBm (800MHz) or -111dBm (1900MH2) (total power per 1.25MHz) at all locations in the service area. © The network should be stable ic. all required sectors are on the air, able to originate calls and make handoffs into and out of the sector. * BSC support: Personnel should be available to carry out selector logging, parameter changes, enabling/disabling OCNS, wilting/blossoming of sectors. ‘* An upto date site database should be available in the prediction tool (e.g. Planet), * All test vehicles/tools/maps etc. should be available. Data collection tools installed, GPS installed/calibrated. * APN 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 321. 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 and selector logs 4. Optimise SRCH_WIN_A and BTS demodulation windows based on rake finger offset analysis. 5. Optimise SRCH_WIN_N/R based on offsets in Pilot Strength Measurement Messages 6. Perform the RF coverage analysis (plot: handoff (by sectors), mobile TX, mobile Ecflo, per-PN plots as necessary (best finger/any finger/PSMM occurrence) Issue 0.8 July 10, 1998 Page 10CDMA RF Optimisation ______.....__________—‘Technology Applications Group 7. Perform dropped call analysis. Plot locations in the data analysis tool. 8. Perform failed access analysis, Plot locations in the data analysis tool. 9. Tune the neighbour lists (using automated neighbour list audit tool, dropped call/failed access analysis and candidates that came from the Remaining Set) 10, Generate the per-site ‘fransmit Gain Adiusilaverages to pinpoint site problems 11. Create baseline data for the performance/trend analysis. 12. Make all the necessary changes to the network 13, Use “spot check” drives to re-create problems and validate changes 14. If changes are minor, go directly to the loaded stage. Otherwise, perform a full network/cluster drive while running 2 minute Markov calls and collecting mobile and selector logs 15, Re-generate the RF coverage analysis plots (plot: handoff state (by sectors), mobile TX, mobile RX, best finger Ec/lo, per-PN plots as necessary (best finger/any finger/PSMM occurrence) 16. Perform dropped call analysis. Plot locations on the coverage analysis.plots. 17, Perform failed access analysis. Plot locations on the coverage analysis plots. 18. Create new dataset for the performance/trend analysis 19. If the coverage control changes have proved effective and the dropped call/access fail rates and/or reasons are acceptable then move on to the loaded stage. Otherwise, repeat from item 12. 3.2.1.2, Second Pass: Loaded 1. Apply simulated load and perform full network/cluster drive while running 2 minute Markov calls and collecting mobile and selector logs 2, Re-generate the RF coverage analysis plots (plot: handoff state (by sectors), mobile TX. mobile RX, best finger Ec/To, per-PN plots as necessary(best finger/any finger/PSMM occurrence). 3. Perform dropped call analysis. Plot locations in the data analysis tool. Pay particular attention to coverage related issues. 4, Perform failed access analysis. Plot locations in the data analysis tool. Pay particular attention to coverage related issues. 5. Create new dataset for the performance/trend analysis 6. Perform analysis of special cases that are peculiar to the system (e.g. geographic, traffic “hotspots”) 7. If the coverage control changes still look good, the average number of sectors per user is not excessive (2.3 or lower is a good target (soft handoff reduction algorithm will be in release 6.2 - will need to re-assess this target)) and the dropped call/access fail rates and/or reasons are acceptable then initial optimisation is complete. Otherwise, make all the necessary changes to the network and repeat from item 1. 8. Complete the performance/trend analysis Issue 0.8 July 10, 1998 Page 11MA RE. rou In addition, many special cases will be encountered during optimisation. Procedures for some these will ‘be added to this document in due course. However, there will always be specific issues that can only be solved through a thorough knowledge of the product, IS-95/J-Std-008, the air interface etc. 3.2.2, Commercial ‘This topic will be covered in a separate System Performance Maintenance Guide but the key points are: ‘Use the MTX OMs and BTSPerformanceData as trend analysis data to pinpoint problem areas. * Enable unconditional SBS logging of RTD, ‘NeighborListTuningArray and VitalData (see section 6 for analysis methods). toe _ © Use unconditional SBS and BTS Diagnostic logging * Ifparticular MINs are suspect, enable a full SBS optimisation conditional logmask for those mobiles. ©. Use drive testing as “last resort” means of characterising a problem area. * Use drive testing to complete the integration of new sites. 33. Exit Criteria ‘Some possible exit criteria for an optimisation exercise are: * Achieving a target dropped call rate, © Achieving a target access success rate. * Achieving coverage over a specified geographical area, * Achieving a target capacity. Issue 0.8 July 10, 1998 Page 12DMA RE Optimisation ____________ Technology Applications Group 4. Tniti: item Parameters 4.1, Datafill Example Since a significant portion of an optimisation effort is devoted to system parameters, every effort should be made to begin with a datafill that incorporates the experiences gained in other markets, ‘The datafill given in the spreadsheets available from the Technology Applications Department will provide a solid starting point for an optimisation effort for a new system. 4.2. Types of Parameters 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. ALR relate, ined in the CDMA RF System ter Guideline for 800 and 1900 )ibiz, 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 ff with two sec coming different values for a given parametes there are para SENT ie rover ‘il be usee™ 1, For SRCH_WIN_A the SBS will seng‘the For SRCH_WIN_N the SBS will send th For SRCH_WIN_R the SBS will send the For T_ADD, T_DROP the SBS will send the lowest (most negative, e.g. <12/and -13 will result ig-13), 5. For T_TDROP, the SBS will send thé‘maximum value? 6. For TCOMP, the SBS will send the ‘Ginimam val, See below for current limitations on per-sector parameters. Some values are repeated at the BTS and BSC: widest value, FEN Issue 0.8 July 10, 1998 Page 13RF. © Values at the BSC apply to the traffic ctnae! SRCH_WIN_A, TAD, T_DROP, T_TDROP and T_COMP will all be sent on the © according to the above rules if the SBS detects that the mobile d SBS works out the new values according to the new active set and, if these values don’t it last sent the mobile it ses the “Search Included ag and e and sends the fiew values on the Extended Handoff Direction- Message). Unfortunately, until the “In Traffic System Parameters Message” is implemented, 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 values Note that, since setting SR id handoff parameters at the SBS)is far simpler than, downloading them to the BTSs/ this provides a quick means of testin; esting Ti setings. For example, if there is a need to experiment wit T_ADD settings on a few sectors, the following strategy can be used: 1. Use a script to update T_ADD on the required sectors at the SBS only (all shelves). 2. Assess the change (e.g. by drive testing). Note that, since the BTSs have not yet been changed, the first handoff in every call will use the old settings but every subsequent handoff will use the new —. setting from the SBS. This is a minor drawback when the speed of making the changes is considered. 3. Try new settings atthe SBS as required. y 4, When the desired settings have been on established Gownlond the BTS with the new values. In NBSS7.0, the search windows and handoff parameters become settable et the BTS (see RF Parameter Guide). = as Neighbour lists are somewhat of a sp PORT OMe obie wi gemerale a composts neil following priorities: —— 1. Any pilots that have recently been dropped from the active list but have not yet exceeded (GHBR_MAX_AGI nl 2. The neighbour list as received on the mast 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 priarity to pilots defined in 1. above so all 20 might not be used. These rules are defined in he 1995 standard. . The following priorities are used: 1. The neighbour list of the reference pilot from the PSMM. 2. Remaining pilots are then ranked by strength as reported in the PSMM. Issue 0.8 July 10, 1998 Page 14‘DMA Te Al 3. The neighbour list of the strongest pilot in this list is then included (although any pilots from 1. above will not be repeated). 4, The neighbour list of the next strongest pilot in the list(although any pilots from 1. or 2. above will not be repeated). 5. ... and so on until all the pilots have been used or the list has the maximum of 20 entries. ‘These rules are Nortel proprietary. For a neighbour list entry to be considered the same, both the PN and the extended baseid have to be the same. Therefore, itis perfectly possible to have repeated PNs as long as the baseid is different. As the neighbour list for each PSMM entry is being added, the order in which the neighbours are datafilled in the Pilot Database is preserved. Processing a PSMM: Each PN with a keep flag of 1 will be matched to a baseid by looking it up in the following order: 1. current active set 2. maintained neighbour set (ie. 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 nct stopping at 20) The first PN match will halt the lookup. 42.3. Setting Parameters Al SBS parameters can be changed quickly using “edit” commands (which may be scripted). Some BTS parameter changes may be made “online” from the BSM while others require a download (see RF Parameter Guide and RF datafill Spreadsheets). 4.2. PN Planning The entrance criteria to RF optimisation include the requirement that a PN plan has already been established. Therefore, a full de 10 set to set up a PN plan for a system is outside the scope of this document, explained in a later section. However, the following illustrates the possibilities for PN interference: imum cellsite spacing (in km) should be: where R’ average cell radius in region of interest and SRCH_WIN_A is expressed in chips. Issue 0.8 July 10, 1998 Page 15,Another possibility for "Co-PN" interference is if PN1 is in the mobile's neighbour list but some energy from a distant re-use of PN1 falls inside the neighbour search window. The "correct" local PN1 will be put in the active list. If the “false” PN1 subsequently becomes one of the 3 strongest multipaths, the mobile will center an active search window on it and try to demodulate it resulting in forward link interference. A third "Co-PN" possibility is if "false” PN energy arrives at the mobile that matches an active set PN that is not currently being demodulated. If the “false” PN subsequently becomes one of the 3 strongest ‘multipaths, the mobile will center an active search window on it and try to demodulate it resulting in forward link interference, A fourth "Co-PN" possibility is if "false" PN energy arrives at the mobile that matches an active set PN that is currently being demodulated. This will only cause interference if the "false" PN energy falls inside the active window for that PN. 4.2.2, “Adjacent PN” ‘The adjacent PN is the next earliest PN in the sequence i.e, PN-PILOT_INC. finner radius = (PILOT_INC x ayes x 1.2288)) - ((SRCH_WIN_N)/(2 x 3.3 x rE) distances (in km). If any distant pilot is interpreted as one of the pilots in the mobile’s neighbour list, the local site will be added to the active list, even if not required. However, this will not cause demodulation problems unless the "false" PN becomes one the strongest three multipaths and a rake finger is assigned to it (note that, unless the mobile has already assigned a finger to that PN from the (correct) local PN, it will center it's active window on the "false" PN. Therefore, the equations above are correct in having the SRCH_WIN_N and not SRCH_WIN_A). For the mobile to actually try and demodulate a distant "false PN" that is already being demodulated correctly from a local site, that site would have to fall inside the active search window. When considering the serving cell, the distances become: outer radius = ((PILOT_INC x 64)/(3.3 x 1.2288)) + ((SRCH_WIN_A)/(2 x 3.3 x 1.2288)) + 2R inner radius = ((PILOT_INC x 64)/(3.3 x 1.2288) - (SRCH_WIN_A)/(2 x 3.3 x 1.2288)) Another possibility for "Adjacent-PN" interference is if PN1 is in the mobile's neighbour list but some energy from a distant site using PN1-PILOT_INC falls inside the neighbour search window. The "correct" local PN1 will be put in the active list. If the "false" PN1 subsequently becomes one of the 3 strongest multipaths, the mobile will center an active search window on it and try to demodulate it resulting in forward link interference. 4.3. Initial Neighbour List Generation The Nortel RF Optimizer contains a feature (the “Natural Neighbors”) to generate an initial neighbour list. based on latitude/longitude/azimuth. Issue 0.8 July 10, 1998 Page 16co Techn Alternatively, the initial neighbour lists for a new system or portion of a system can be generated as follows: 1. In the prediction tool, generate a best server Ee/lo plot. 2. For each sector, create a neighbour list consisting of the sectors with which it shares a common boundary. 3. Prioritise the list according to the boundary length and traffic patterns such that the most likely transitions are earlier in the list. Do not be tempted to add more distant sites to the neighbour list “just in case”. The objective is to keep the neighbour lists to the minimum length and hence reduce search times (see section 6.7. on neighbour list data analysis) 44. BTS Calibration Some of the datafill values are outputs from the BTS calibration process (e.g. TXAttenNormal, BTS to RFFE cable losses). Ensure that these are present in the datafill before optimisation commences. Issue 0.8 July 10, 1998 Page 17CDMA RF Optimisation Technology Applications Group 4.5. Search Windows Initial search window settings for both the BTSs and mobiles can be estimated based on cell site radii in a given area. ‘The following table gives the datafill, maximum delay and corresponding distance for various window sizes: ‘Window size (chips) Max Delay (uS) Distance (km) 1447) 57 171 20 (410) 8.1 2.44 28 (414) 14 3.42 40 (420) 16.3 4.88 60 (+30) 244 1.32 80 (+40) 32.6 9.76 100 (450) 40.7 12.20 130 (+65) 52.9 15.86 160 (+80) 65.1 19.52 226 (4113) 92.0 27.57 Issue 0.8 July 10, 1998 Page 18‘DMA. Teck Al tions Grouy However, the chip sets commonly used in current handsets cannot search infinitely fast. Setting the search ‘windows too small will not result in a worthwhile speed improvement and may risk missing some important signal energy or a new neighbour. The following table gives the acceptable search window combinations: Active/Candidate Search Window (SRCH_WIN_A) Neighbour Search Window (SRCH_WIN_N) (chips) 45.1. _ SRCH_WIN_A, AccessChannelDemodulationSearchWidth, TrafficChannelDemodulationSearchWidth ‘SRCH_WIN A only has to allow for the difference in arrival Assu jonents that are wit prop: ent of 3,5, Ifthe cell r iftravels a distance D such that: 35 * loglO(D/R) = 10 or DIR = 1.93 of multipaths from the sgipe sector. 104B of the main path anc R then a multipath component will be 10dB down when ‘The extra distance the signal must travel is therefore 0.93R. ‘Therefore, the system can be divided into two or three groups of similar cell sizes and a representative cell radius chosen for each group. For example, for R = 2km, the multipaths must travel 1.86km extra and since 1 chip represents 0.244km, the “half-width” of the window should be 1.86/0.244 = 7.6 chips and hence the full window width should be at least 15.2 chips. Iseue 0.8 July 10, 1998 Page 19MA RF i Technology Applications The setting for SRCH_WIN_A can be obtained from the table above. The next highest setting above the one calculated is 20 chips. ‘The BTS demodulation windows are set in 1/8" chip units i.e 15.2 * 8 = 121.6. However, the smallest increment that the CSM searches is 125 1/8 chip units so the settings should always be multiples of 125 i.e. 125 (for this example), 250,375, 500, 625 etc. 45.2, SRCH_WIN_N, SRCH_WIN_R Since SRCH_WIN_N has to allow for the difference in arrival ti i the sett iven sector can be established by measuring the distance to the most distant cell in the neighbour list. Eg fara celto cel distance of km, the “balewindow is 0244 =32 8 cchips, the full window would be 65.6 chips so the next highest setting of 80 chips would be required. Remember, though that SRCH_WIN_N cannot be updated during a call so allowance should be made for mobiles establishing a call with a particular setting and then moving to an area of larger cell spacings if in doubt, use a higher setting on smaller cells that are adjacent to an area of larger cells). The remaining set search is used to find stray pilots and missing neighbours so a good setting for SRCH_WIN_R is to use the next setting above the SRCH_WIN_N. 45.3. AccessChannelAcquisitionSearch Width, TrafficChannelA cquisitionSearch Width ‘Ap Delay calculations, it does need to allow for the “out plus return” time. E.g. if access attempts are ‘expected up to a 15km radius, the pilot channel takes 15/0.244 = 61.5 chips so the mobile’s timing will be set accordingly. When it sends in an access probe, there will be a further 61.4 chip delay coming back to the BTS so the total window needs to be 122.8 chips or 983 1/8 chip units (likely rounded up to 1000). Until further notice, TraffigChannelAcquisitionSearchWidth should be set-equaltothe AccessChannelAcquisitio#SearchWidth. a 4.6. Neighbor Configuration File, Setneighbor and Checkneighbor RF datafill that needs to be consistent between SBS shelves or between SBS and BTS can be held in the Neighbor Configuration File (NCF). The Setneighbor and Checkneighbor commands at the BSM will then apply or verify the datafill end ensure consistency between subsystems. Some RF Optimizer features make use of the NCF file. ‘The following datafill can be held in the NCF file: PILOT: Number between 0 and 511. MANDATORY NEIGHBORS: Comma list of keys describing each of the neighbors. BTS_NEIGHBORS: Comma list of keys describing each of the neighbors of the BTS. If this is column is not defined, the BTS neighbors are set by the NEIGHBORS field: This list has three items for each neighbor: key, neighbor config value, and priority. It appears as the following with KEY having a config value of 1 and priority of 2: KEY1, 1,2,KEY2,3,4 Issue 0.8 July 10, 1998 Page 20RE Te ions The BTS neighbor list will use the NEIGHBORS column if either this column is not present or this list is empty for this entry. This field is optional. BORDERTARGET: Comma list of target cells for Border handoffs. BEACONTARGET: Comma list of pairs target cells and pilot pns for Pilot Beacon handoffs. This following example has 3 targets, 2 with the PILOT_PN of 251, 251,KEY1, 200, KEY2, 251, KEY3 EHHOTARGETCELL: Comma list of target cells for EHHO. CELLTYPE: Enumeration Standard, Pilot_Beacon, EHHO, and Border. QUICKREPEAT: True or False for quick repeat. FORWARDGAIN: Numeric value describing the forward gain. BorderRefPilotRTDThresh: RTD delay to trigger border handoff. EHHOFERMAXFWD: Trigger for EHHO. EHHOFERMAXRVS: Trigger for EHHO. EHHOFERMODFWD: Trigger for EHHO. EHHOFERMODRVS: Trigger for EHHO. EHHOTCGMAX: Trigger for EHHO. EHHOEBNOMAX: Trigger for HHO. 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 v difference between(Sronggstandthird pilot) DELTA_4: Numeric value for difference between stronges) and the fourth piloy. .gesDand the‘ ae ee DELTA_6: Numeric value for difference betweeb strongest/and the sixth pilot Issue 0.8 July 10, 1998 Page 21cor ti ions Grou ‘SRCH_WIN_A: Numeric value for search window of active set. SRCH_WIN_N: Numeric value for search window of neighbor set. SRCH_WIN_R: Numeric value for search window of remaining set. BTS_CRM_ACNAddr: Numeric value for the CRM ACN address. NGHBR_CONFIG: BTS Neighbor configuration numeric value. SEARCHPRIORITY: BTS Neighbor search priority numeric value, MultiPilotHHOEnabled: Enable multi-pilot targets, TRUE or FALSE. PILOTINCR: Numeric value for the pilot increment in the neighbors list. Issue 0.8 July 10, 1998 Page 225.1.1. Mobile Data Collection Each test van should be equipped with equipment to collect data from the test mobile(s), a compatible GPS receiver. 5.1.2. Test Van RF Configuration Phones may simply be placed inside the vehicle or, for more repeatable results, an external antenna may be used. If external antennas are to be used, the most convenient way to configure the RF connections in the test van is to use either a car kit or a direct connection to the phone along with the external antenna In order to produce “in-car” signal levels with an external antenna, attenuation must be added to the antenna connection in order to achieve the customer-specified vehicle or building penetration loss. ‘The following table is an example of the budget that should be calculated to correctly determine the attenuator required: Losses/Gains (4B) “Real” Car Antenna Gain Cable and connectors Car Kit Loss Test Van Antenna Height Attenuator Penetration Loss Ideally, the received power reading and transmit power indication of the phones used in the test vans should be calibrated. The HP8924 CDMA Mobile Tester will allow this type of measurement. Even if an exact calibration is not carried out, the various phones used in the test vehicles should be tested for consistency from unit to unit. Issue 0.8, July 10, 1998 Page 23CDMA RF Optimisation _______......________—Technology Applications Group 5.13. The Base Station Manager (BSM) ‘The BSM runs on a UNIX platform and forms part of the BSC. Its functions include parameter setting for the BSC and BTSs, BTS software downloads and diagnostic logging. A full description of the BSM is outside the scope of this document. The assumption will be made that trained personnel are available to take SBS and BTS Diagnostic logs, change parameters and download cell-sites. 5.2. Simulating Loading ‘Many customers will require that any optimisation be carried out at the planned traffic loading. Beware that this may actually mask “stray” pilots since the Ec/Io may be less than T_ADD when loading is applied. For this reason, at least one pass through the network without loading is preferted. The following methods will allow a simulated loading to be applied approximates an even distribution of real users. 5.2.1. Forward Link Forward link loading is achieved through OCNS (Orthogonal Channel Noise Source). The standard datafill reserves 2 channel elements per sectot for OCNS. A gain setting of 120 allows 9 users per CE (18 total). Assuming the channel elements have been reserved, a script can be used to tum on OCNS very quickly, (if not, a full BTS download is required). The script defines the following: ‘*, Number of simulated users required. ‘© Traffic channel gain per user (this should be the gain for full rate frames - do not try and account for voice activity in this number, the OCNS algorithm will do this automatically if the OCNS gain mode has been set to “Variable”). Gains of 90 to 125 are commonly used. A sample calculation for OCNS is as follows: For a particular capacity test using 1900MHz equipment, when 13 users were achieved, the average digital gain was 106 with a soft handoff overhead of 2.4 sectors per user. However, even if we want to simulate full load, this is definitely not how OCNS should be set up since this completely fills the HPA and guarantees 100% blocking. At 1% blocking, there can only be 13 users on a sector 1% of the time so, while individual sectors in a system instantaneously have 13 users, on average the number will be much lower. 13 channels is 6.6 erlangs so on average, there will be 6.6 users per sector throughout the system and this is what we should multiply by the soft handoff overhead and set with OCNS (ice. the average number of "links" or "connections" to a sector is 6.6 x 2.4 = 16). Finally, allowance should be made for the 2 phones in the drive test vehicle and since it will add 2 "links" to the sectors in the drive test area, the final calculation would be: ‘Number of OCNS users = (6.6 x 2.4) -2 For a sector that is running at 1% blocking, the total output power (including overhead channels) should be approximately 65% of the total HPA power. We can therefore check the above settings generate the correct power as follows: Assuming a calibration of 254 = 4 Watts and standard overhead channel gains of pilot = 186, syne = 60, paging = 156 and PRAT=0, the power in the overhead channels is: (186/254)'x4 + (60/254)"x4 + (156/254)"x4 = 3.88W 14 users at a gain of 106 Issue 0.8 July 10, 1998 Page 24RE T AN 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)*x 4x 0.45 x 14 = 4.39W. Since the full HPA power is 12.5W, the percentage is (3.88 + 4.39) x 100/12.5 = 66%. The corresponding numbers for 800MHz equipment would be: OCNS gain = 123, OCNS users = 14, pilot gain = 216, sync = 68, paging = 182, HPA = 16.8W, calibration is 254 = 4W. This also gives a percentage of 66%. Sectors requiring a lower load (either because of morphology classifications or based on existing AMPS traffic distributions) should be scaled using the number of OCNS users. 5.2.2. Reverse Link A reverse link load can be crudely simulated by degrading the reverse link according to the following equation: Degradation (4B) = logl0(1 - load) where load is the fraction of pole capacity that the system is carrying (e.g. for 50% load, the required attenuation is 34B total). Remember to allow for the load that the test phones will generate i.e. the actual attenuation applied would be less than 3B, Reverse link loading can be achieved by one of four methods: 1, Attemuate at the mobile (TX path only - requires that uplink and downi:nk are separated using duplexers). This is the Nortel preferred method and shielded boxes with attenuators for both reverse link loading and in-building penetration have been built for the purpose. 2. Attenuate at the BTS (beware that, if the attenuator cannot easily be placed ahead of the first active element, the attenuation value required will have to calculated such that the overall system noise figure is increased by the required degradation). 3. Use the internal attenuator (the “wilting” attenuator) at the BTS (not very accurate). 4. Do not actually degrade the reverse link but apply an offset during the data processing (not recommended since an optimistic dropped call rate will be obtained), Issue 0.8 July 10, 1998 Page 25,CDMA RF Optimisation Technology Applications Group 5.3. Drive Test Data Required The following sections define the log masks that should be used for the selector and mobile logging during drive testing. 5.3.1, Selector Log Mask The following table illustrates SBS log masks that will cover most aspects of RF optimisation. Log masks with this many attributes should only be enabled conditionally (i.e. for specific mobiles as entered in the CDMA ICC table at the MTX): Attribute Name Logged on Required for Required for What Voice/Markov | Optimisation | Detailed Network calls Debugging LogSBSNOISMessages, Both Yes Yes Internal NOIS messaging LogSBSIS9SMessages Both Yes Yes Air interface messaging LogSBSMarkovData Markov only Yes Yes Expected and received rvs frame rates/types LogSBSForwardMarkov | Markov only No No Cumulative Full and All rate Data Fwd FER every 20 seconds LogSBSReverseMarkov | Markov Only No No Cumulative Full and All rate Data Rvs FER. every 10 seconds LogSBSPowerControl Both Yes Yes Ew/No setpoint and fwd Data traffic chan gain per frame ‘LogSBSActiveSetChang Both No | Yes ‘New active set with baseids e LogSBSResourceUsage Both No Yes LogSBSCallAssociation Both Yes Yes Links ESN/IMST to callid LogSBSForwardLinkFE Both No No All rate FER summary for 1 R call LogSBSReverseLinkFE Both No No All rate FER summary for 1 R call LogSBSFrameSelection Both No Yes Indicates which BTS each Data frame was taken from LogSBSReceivedMuxDe Both Yes Yes Received frame rates/types cision ‘LogSBSTransmitMuxOp Both Yes Yes ‘Transmitted frame tion rates/types Issue 0.8 July 10, 1998 Page 26CDMA RE Te ications Grow LogSBSRound Both Yes Yes RTD from each sector ~ TripDelay logged every 10 secs LogSBSForwardTrafficF Both No Only for voice | Full bit content of every rameData quality issues frame (large) LogSBSReverseTrafficFr| Both No Only for voice | Full bit content of every ameData quality issues frame (large) LogSBSNeighborListTu Both Yes Yes PSMM content with baseids ningArray LogConfigData Both Yes Yes SBS parameters LogSBSForwardFrameE Both No Yes Fwd EIB for every frame — rasurelndicatorBit logged every 16 secs LogSBSVitalData Both Yes Yes Error strings (very useful) Iseue 0.8 July 10, 1998 Page 27CDMA RF Optimisation ‘Technology Applications Group 5.3.2. Mobile Log Mask The following table should be used as a guide when setting up the log mask at the mobile data collection equipment. For a full description for using the Grayson equipment, including details on tradeoffs incurred when logging the high volume attributes, see the separate documentation available from the Technology Applications Department: Islog Field O=no log 0 Not used 0 AGC Val and Closed Loop Pwr | Power control data for CD3000 Ctl 0 Not used 0 Rev Link Frame Rates and Types | Reverse link data transmitted. 1 Access Channel Msgs All access channel messages sent. i Rev Link Traffic Chnl Msgs All rvs Traffic Channel messages sent. i Sync Channel Msg Entry Alll Sync Channel messages sent. 1 Paging Channel Msg Entry All Paging Channel messages recd. 1 Fwd Link Traffic Chnl Entry _| Fwd Traffic Channel messages reed. 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 and position, pilot offset, signal energy measured, etc.). 0 Not used 0 Vocoder Err Mask ‘Vocoder rate/data with bit errors detected. 1 FM Data ‘Analog mode data, 1 ‘Access Probe Data Access probe information (seq number, probe number, RX AGC, TXGA, etc.) Issue 0.8 July 10, 1998 Page 28Latitude, longitude, speed, heading, time from the GPS receiver. 0 Not used 1 Sparse AGC AGC and Closed Loop Power Control for QCP800/1900 [o Not used 5.4. Drive Testing 541. 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 cach sector, power down the phone, power up again, confirm a call can be originated and then release that call. Since the log is active (see below), this will capture sync, paging, call origination and tear down (make sure some idle time is captured on all sectors of a sectored site). ‘Mobile Logging: As you leave one site and head for another, stop the van somewhere in the soft handoff region and save the logs for both. Start new logs for both phones and continue to next site (i.e. For each phone, there will be one log per site). See section 6.2.2. for shakedown data analysis. 5.42. Drive Routes 5.4.2.1 — Drive Route Selection Using the coverage area predicted by the design tools, drive routes should be established throughout the area with emphasis placed on main streets and highways where customer traffic is expected to be high. ‘The coverage area can be divided into regions and for each region the drive routes specified and written down. Each time a route is driven, it should be driven in exactly the same direction, from the same start point to the same end point. Each route should be given a name or number which was recorded on the mobile log sheet when the route is driven and the written log is included in the log book for easy reference during data analysis. During the drives, deviations from the routes such as detours and street closures should be noted on the log sheets by the drivers. Issue 0.8 July 10, 1998 Page 29CDMA RF Optimisation ____.||......_______—‘Technology Applications Group 5.4.2.2. Benchmark Route ‘ABenchmark Route can be a useful means of assessing network performance and consistency without the need for a full network drive. It should take the form of a single loop that is selected to stay well within the coverage area and to pass through the various clutter types available in the network. The Benchmark Route should take about one to two hours to drive under normal driving conditions. It should be driven each time a change is made to the network. The data from the Benchmark Route can be compiled and analysed to look for trends in network performance. 5.4.2.3. Driving with only one cluster of cells on air ‘Should be used with care - need all the neighbours of the cells you are driving to be active and probably at least one more tier of cells beyond that - even then will miss some interference problems. If data has been collected on a small cluster, the following analysis can be performed: © Datafill audivshakedown * Per-site TX gain adjust © SRCH_WIN_A If conducted on a cluster, the following will have to be repeated when surrounding cells are acti ‘© Coverage/handoff control © Neighbour list analysis © SRCH_WIN_NR + Detailed dropped call analysis 543. — Test Calls With the exception of hard handoff borders, aAll testing should be conducted using Markov calls. If two phones are used one phone can carry calls for approximately 10 mins duration but at least one phone should make short calls (e.g. 2 mins). Do not attempt to re-establish a call immediately following a dropped call. A wait period of, say, 1 minute should be used. 5.4.4, — Logging See "SBS Diagnostic Logging in Commercial Networks" for additional information. 5.4.4.1. Data Collection Restrictions Selector logfiles are collected on the cards (not on the BSM) and are restricted to 0.SMbytes. Also, if there are, say, two selector shelves (twelve cards each for a total of 24) and only a single phone making many calls, each time a call was originated, it would be assigned to the next available selector card and the assignments would alternate between the two shelves. A single phone operating on a particular selector card with the SBS log mask given earlier will fill the data buffer with information in about 16 minutes. If the data logging buffer becomes full on a selector card, the behaviour depends on how the log Was initiated, but in any case, some data loss guaranteed (even with continuous mode). Issue 0.8 July 10, 1998 Page 30cor timisation Applicat 5.4.4.2. Logging Strategy To avoid overflowing the data buffer, mobile calls should be limited to around 12 to15 minutes. After this time, the call would be terminated and another call originated (but the same logs should be kept open), this second call would occupy a different selector card and 15 more minutes of data can be collected. Obviously, this only applies to the phone making the long Markov calls, the other phone is already making short Markov calls so its logging load will be spread among the selector cards, Also, to avoid losing large amounts of data due to logging failures, a 30 minute logging period should be imposed ‘on the data collection process. The following is an example of a strategy that will reduce the risk of filling selector buffers: At the BSC: Start logging on the hour Stop log at 25 minutes after the hour Upload logs and put in the appropriate date/run directory Start logging at half past the hour Stop logging at 55 minute past the hour Upload logs and put in the appropriate date/run directory Nave err (and so on...) In the test vans: Start logging on the hour Start long Markov call on one phone Start making short Markov calls on second phone At 12 minutes past the hour, terminate the long call and re-establish (do not stop the log) ‘At 24 minutes past the hour, terminate calls on both phones Stop log at 25 minutes after the hour Save logs, tidy up written logs and prepare to re-start logging Start logging at half past the hour 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 Per Ana eyr 14, Save logs, tidy up written logs and prepare to re-start logging 15. (and so on...) Issue 0.8 July 10, 1998 Page 31DMA RF Optimisation _________mon9. Technology Applications Group Note, while every effort should be made coordinate with the SBS logs, itis not critical if the mobile logs are shorter or longer by a few minutes. 5.5. Drive Test Data Management Abbreviations used in this section. The abbreviations used in the file names in this section should be interpreted as follows. yy: the year mm: the month dd: the day nn: the run number MMMM: the MIN number of the phone tttt: the time (GMT) in minutes and seconds ce: the cluster RUN: the word "run" appears explicitly in the file name 5.5.1 Data Transfer and Tracking Due to the large amount of data that will be accumulated during optimisation, logging and tracking each data file is crucial. ‘An example naming convention is as follows: Selector logs: MMMMcerr.sbs © Mobile logs: MMMMcerr.mb1 Additionally, a directory structure that includes the date should be considered mandatory. Text description files of the test conditions, purpose etc. should also be placed in the relevant directories. 5.6. Unconditional SBS Logging of Live Users 5.7. BTS PerformanceData Issue 0.8 July 10, 1998 Page 326.__Data Analysis Procedures The following sections cover general data analysis procedures for the majority of the network. Analysis of “special case” areas may reveal a need for slightly different settings than these overall procedures indicate. Also, bear in mind that data analysis can be divided into two major “levels”: 1. “Macro” view: This is where either plots of parameters over large portions of the network are ‘generated or averages and trends of various parameters are considered. 2. “Micro” view: This includes analysis of specific events e.g. access fail/dropped call analysis as well as problems at specific locations. 6.1. Tools (This section under major re-construction due to recent tools evolution - transition to RF Optimizer within Nortel). 6.2. Datafill Audit and Shakedown 6.21. Datafill Audit Examine the configuration files for all BTSs and the BSC and make sure the expected RF parameters are in place correctly. 6.2.2. Shakedown Data Analysis Generate mobile message text files from the shakedown runs and, for each sector, examine the parameter settings in the Syne Channel Message, System Parameters Message, Extended System Parameters Message, Access Parameters Message and make sure the expected parameters are in place correctly. ‘Also, examine the Neighbour List Message and confirm that the neighbour list is correct (remembering that this is only used for idle handoff). The Nortel RF Optimizer automatically generates Shakedown reports, 6.3. System Access 63.1. Access Failure Analysis ‘Since at least one of the phones in the test vehicle is making many short calls, useful data on access attempts is available. Ifthe radio link hen itis cons the timestamps ‘OF access Tallures. Using the mobile message text files, message flow files and parametric files, classify the failures into one of the following categories: 1, Access probes exhausted (not received by system) 2. Access probes exhausted (seen by system but ack not reaching mobile) Issue 0.8 July 10, 1998 Page 33CDMA RF Optimisation Technology Applications Group Ack received by mobile but Channel Assignment Message not seen . Channel Assignment Message seen at mobile but mobile does not acquire forward traffic channel 3. 4. 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 mahile 1. Forward ack reaches mobile but reverse ack does not reach system 6. System receives reverse ack but Service Connect Message is not seen at mobile. Reverse link message failures are likely due to coverage problems. Forward link message failures are, Tikely due oe me Tee Hed To one pilot during access (any other pilots are effectively. interferers). RF Optimizer will map the locations of access failures. Check that reverse link failures are not happening in areas of solid coverage (suspect a problem at one of the sites if this appears to be the case). Forward link access failures are Ii n in areas where multiple pilots are seen. If it seems to be ing in isolated coverage, suspect a problentrat the site, 6.3.2. Access Success Rate Once the relevant OMs are in place and a system is carrying live traffic, the access success rate reports can be produces as required. However, measuring the access success rate on i 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 are clearly out of coverage, sites not in service due to datafill error etc.) © Use the remaining failures and the total call attempts to calculate the access failure rate. 6.3.3, Access Parameter Tuning (INIT_PWR, NOM_PWR, MAX_REQ_SEQ, MAX_RSP_SEQ, PWR_STEP, NUM_STEP, MAX _CAP_SZ, PROBE BKOFF, BKOFF) (Set INIT_PWR to be consistent with average TXGA - others should be at baseline datafill for now but need to be subject of a detailed test) 64, Dropped Calls 6.4.1, Link Supervision ‘The link supervision algorithms define the criteria for dropping a call. 64.1.1 Mobile The mobile will autonomously release the call if 250 frames are received without 2 consecutive good frames (i.e. every 2 consecutive good frames resets a 5 second fade timer). Issue 0.8 July 10, 1998 Page 34RF fon Te ications Gre 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. 64.1.2 SBS The SBS will autonomously release the call if 250 frames are received without 2 consecutive good frames (ie. every 2 consecutive good frames resets a 5 second fade timer). The SBS will autonomously release the call if no acknowledgement (either an Ack or a Handoff Completion Message) is received to a Handoff Direction Message within 5 seconds. The Handoff Direction Message will be re-tried 6 times. Additionally, if QuickRepeat is enabled, each of these re-tries is composed of 3 repeats i.e. a grand total of 18 repeats of the same message. 6.4.2. Analysis Dropped call analysis can consume a considerable amount of time. Custom scripts or tools such as Nortel’s RF Optimizer will identify and timestamp calls which ended prematurely. Through inspection of the mobile message logs and parametric data, the root cause of some of the drops can be determined without the need to use the selector logs. However, most of them will need deeper investigation involving the SBS message files, the message flow files and paramettic files (possibly after re-processing at 20mS resolution). While chapter 7 of this document attempts to provide a step-by-step approach to dropped call root cause analysis, there is no substitute for thorough knowledge of the air interface and IS-95. Ifthe radio link fails after the mobile sends the Service Connect Complete itis considered a dropped call. Using the symptoms described in chapter 7, separate the dropped calls into the following categories: Q Coverage related Q “Optimisable” e.g, slow handoff, search window, coverage control, PN plan related. @ Equipment problems (c.g. hardware failures, backhaul interruptions). @ Hardware or software design related problems. Examine the location for all of the category 1. failures. Check that this type of dropped call is not happening in areas of solid coverage (suspect a problem at one of the sites if this appears to be the case). If service is required in an area not currently covered, it may be possible to extend the range of existing sites through antenna orientation or type changes, otherwise, an additional site will be required. For category 2., apply the solutions described in chapter 7 for the different types of dropped calls. The message flow file containing messages logged at both the mobile and SBS is particularly useful here, Category 3. problems should be referred to the appropriate maintenance team. Category 4. problems should be communicated to the development teams through the SR (Service Request) process. Issue 0.8 July 10, 1998 Page 35RF Opti Applicat 6.4.3. Dropped Call Rate Tools such as Nortel's RF Optimizer will automatically generate dropped call statistics based on the actual number of test calls. Ifthe long calls are to be used, the following method can be used to avoid skewing the data: * In conjunction with the customer, decide on an average call duration (¢.g. 100 secs) that will be used in the calculations. ‘* Use the total call time output from the data analysis tool and calculate the number of equivalent calls using the average call duration. Data for all phones for an entire network/cluster drive should be used. * Eliminate any dropped calls that should not count in the total (¢.g. drive routes that are clearly out of coverage, sites not in service due to datafill error etc.) © Use the remaining drops and the total equivalent calls to calculates dropped call rate, 6.5. RF Coverage/Handoff Control ‘Controlling the coverage area of individual i i optimisation and is crucial to good CDMA performance, Much has been written about the ‘Ehimination of frequency planning in CDMA. Alll this really means is the loss of one degree of freedom for interference control. Antenna patterns, orientations and tilts are the main t0.confine cells to their intended coverage area and create a domi 7 ery careful thought ‘given to the choice of antenna type in terms of beamwidth and built-in electrical downtilt. Downtown (and probably suburban) areas will often need downtllis. well in excess of 6 deg so this would be a good choice of electrical owntilt in many instances, The beamwidth shoul be consistent ith maintaining 2 good overar a pood cover: s is will be especially true Tor sites to give in-bui ge. Note, however, that “over coveTing” at ara, eter to achicve i ‘building coverage or because of capacity reasons does not by itself cause “pilot pollution” If these steps are not taken, the system will be prone to the following “Pilot Pollution” related Since, for a given SRCH_WIN_A setting, the number of active ueTice on search time, there is an increased chance of a new, strong pilot. not eng dieted aucly ‘enough, This is made worse by the fact that, in high handoff areas, the pilot Ec/lo values are typically Very low (because of the high Io). For example, if the mobile is in 4-way handoff in a loaded system, the active pilot Ec/lo values could all be around -134B. When a new pilot crosses T_ADD at, say, -14dB, it is already nearly equal to the active set pilots. By the time the phone has filtered the measurement. sent a Pilot Strength ‘Measurement Message and the SBS has queried the BTS for resources, the new pilot may be ‘causing 50 mitch forward link interference that the Handoff Direction Message Tails to reach the mobile. fhe mobile Issue 0.8 July 10, 1998 Page 36DMA Technology Appl . Cone SD If pilots are being seen some distance outsi Coverage ae, rapped els nay rela Yortwo econ OUT at pa a ‘aise InerTeence oa can progies, but the mobile's ming references Tome oat ol the distant pilot will be outside SRCH. (_WIN_N and hence it it will not. to the active set timing reference, the local sites will be “invisible” if they are outside SRCH_WIN_N and the Gall will drop a soon as one of the local sites becomes strong. Note that itis unlikely that the inobile WIT SWiTGHTIS ing To the distant sie while ot a cal’ ing tothe distant site while on a call Since this would require that no take fingers be assigned to any of local sites. , 5 and 6 way handoff can be beneficial in many instances where there are many ‘no dominant server or in a rapidly changing environment. the pilots net currently being demodulated serve as “hot standt take fing can be assigned very ‘UCR THE Cn be very naan icing acai RCSA Hee oder ‘OTS compromise capacity (both forward and reverse link), every effort should be made to ensure that this is the exception rather than the rule. Also, ‘Since the mobile only has three rake fingers, there are, say, 4 eq ial pilots, the mobile will assign 3 fingers to 3 of them, Teaving the 4 as an interferes, This ‘equire a higher forward power allocation to overcome this interference and hence lower capacity. The following three sections describe how to load survey data into a mapping tool to generate plots that will indicate which sites are candidates for antenna changes. The source data used should represent one entire drive of the system/cluster: 1. Generate files containing lat/long and handoff state (by number of sectors - not channel elements). Use 6 colours to identify the number of sectors involved and generate one plot for the entire system/cluster. (The Nortel RF Optimizer can generate these plots automatically). 2. Generate files containing lat/long and the Ec/Io of the best finger. Suggested settings are -16 to -8 with a step of 2. Generate one plot for the entire system/cluster, (The Nortel RF Optimizer can generate these plots automatically). 3. After studying the above plots, create a list of sectors which are possible contributors to the high handoff or poor Ec/lo areas. For each of these sectors, the idea is to generate a plot for that sector alone showing where that pilot is appearing. Three types of per-pilot plots can be used; strongest rake finger, any rake finger, any occurrence in a PSMM. The value to be plotted is the Ec/Io, Suggested settings are -16 to -8 with a step of 2. Generate plots for one sector at a time. (The Nortel RF Optimizer can generate these plots automatically). 4. Generate files containing lat ong and mobile transmit power. Suggested colour settings are: Jess than 13dBm = green, 13 to 184Bm = orange, 18 to 23 Bm = red. Generate one plot for the entire system/cluster. (The Nortel RF Optimizer can generate these plots automatically). Analysis of these plots is somewhat subjective but the general procedure is as follows: The_ handoff state and overall Ec/lo plots should be used as an indicator of . excessive Tandinferferepos. In areas of high handoff (4, 5 and.6 way), examine the per- pilot plot for each eo in that area a ¢ whether each pilot is it nied to provide low progressivel! ter coverage area for a ‘iven pilot so some ae ‘will Beis eat to find the clearest picture. Issue 0.8 July 10, 1998 Page 37CDMA RE Optimisation ____________ Technology Applications Group ‘ite nobles coeur along the mun beam of es antenna: a down alone should be suficient IC ‘Rese ar problemi slong the edge of the entedna beam, also considera names beamidth ‘e-orientation, Do not try to remove signal from areas where the mobile transmit ‘power is above I8dBm (red) since these are the areas where high handoff is actually helping to maintain the call. To help decide on the exact changes, use single cell signal plots in Planet and experiment with antenna changes. A signal level reduction that will get the offending pilot below ‘T_ADD should be calculated and applied before re-driving the area (see appendix 9.5 for an example calculation). Beware that, as unwanted pilots are removed from an area, the Io is being reduced and so the next drive of the area may reveal new problem pilots, making this somewhat j of an iterative process, The data for these plots is best taken without any forward link loading since this will raise the Ec/Io levels throughout the system and expose pilots that might not otherwise be seen. After the coverage of the individual sites has been correctly adjusted using the circumstances. 4, 5 ‘way handoff can be beneficial in many instances oe wi Server OF in a rapidly changing environment. In these cases, the pilots not Grpeaty being demodulated sere as “bt standbys” te which cae fingers can be as quickly. This can be very important in maintaining a call in a difficult environment. ‘A majority of 2-way mixed with some 1-way (no handoff) and some 3-way handoff should be considered normal. An overall figure of 2 sectors per user can be considered a good target. ‘T_ADD/T_DROP settings of -14/-16 are the recommended settings at this tims for the following Teasons: = * These values have given good results in simulations and field testing to date, particularly with respect to dropped call rate. * In “pilot polution areas”, the Ec/Io levels of the active set pilots can be as low as -12 or -13 4B. Even with T_ADD at -14dB, a new pilot will not be detected until it is almost equal in strength with the current pilots. By the time the mobile has measured it, sent a Pilot Strength Measurement Message, the system has set up resources and sent back an Extended Handoff Direction Message, the forward link is often to poor for this to reach the mobile and he call drops. Rasing T_ADD will make this problem worse. © Dropping a pilot above -16dB represents a loss of useful signal. There are other reasons to avoid arbitrary reductions in soft handoff. For example, given that the reverse link coverage has been designed assuming 44B soft handoff gain, we can calculate (fora propagation slope of 3.5) that the last 44B of the cell radius represents an area of 42%. Therefore, 42% of the cell area needs to be in soft handoff to ensure complete reverse link coverage. Restricting it to, say, 35% using the handoff thresholds) (which are forward link parameters and hence somewhat independent of reverse link coverage) would be a very bad thing to do. This is a very simplistic calculation and also the cell overlap that you will always get in a real design will help a lot with the reverse link coverage but it indicates the need to think very carefully about this. ‘More “intelligent” handoff algorithms are currently the subject of much discussion and field test (Soft handoff reduction algorithm will be in release 6.2 - will need to re-write this section). Issue 0.8 July 10, 1998 Page 38RE tion Technolo 6.6. Search Windows ‘The search sequence for mobile that has two active pilots and a neighbour list of three PNs is roughly as follows (the actual algorithm will be specific to individual handset manufacturers but this will illustrate the principle): Al, A2, NI, Al, A2, N2, Al, A2,N3,R, Al, A2, NI, ... \ 1 ? . i to new ni our can therefore be generalised as: , fl Search Time = (Ny x (Tn (NaxTa))) + Tr _ Where Na, Ny are the number of actives and neighbours respectively. T,, Ty and Tp are the search times for the SRCH_WIN_A/N/R windows. Minimising the search time is crucial to CDMA performance, both to avoid calls (due to a new pifot increasing very rapidly) and to maximise ‘(any delay adding a new neighbour into the active set means itis effectively an Interlerer se More power is, Tequired to maintain the desired FER). —————rnrr—— However, the chip sets commonly used in current handsets cannot search infinitely fast. Setting the search ‘windows too small will not result in a worthwhile speed improvement and may tisk missing some important signal energy or a new neighbour. The following table gives the acceptable search window combinations: Active/Candidate Search Window (SRCH_WIN_A) (chips) 20 | 2 | 4 | 60 Search Window (SRCH_WIN_N) (chips) Issue 0.8 July 10, 1998 Page 39DMA RF. Techn ions Grou ‘The following table gives the datafill, maximum delay and corresponding distance for various window sizes: Window size (chips) | Datafill Value | Max Delay (uS) | Distance (km) 1447 4 31 171 20 (410) 5 81 2.44 28 (414) 6 114 3.42 40 (420) 7 163 4.88 60 (430) 8 244 732 80 (+40) 9 32.6 9.16 100 (450) a 40.7 12.20 130 (465) b 529 15.86 160 (+80) c 65.1 19.52 226 (4113) 92.0 27.57 The following three sections explain how to establish a search window settings that are consistent with the propagation environment within the systenv/cluster. 6.6.1. SRCH_WIN_A Generate histograms of the maximum mobile finger separation for fingers locked to one pilot only. This is the basis for setting the optimum value for SRCH_WIN_A. Finger Packet Packet Size: 15 Pilot Offset Ecl0 312 0.00 -10.61 Locked 312 1.32 -14.38 Locked 320 0.10 -14.28 Locked Eg. In the above finger packet, 2 fingers are locked to PN 312 so the 1.32uS offset would contribute to the histogram. Issue 0.8 July 10, 1998 Page 40CDMA RF Optimisation ‘Technology Applications Group Gather all the histogram files for one entire network/cluster run. Classify the areas by average cell size (two or three regions should be sufficient e.g. “small” (dense) urban cells and “large” suburban/rural cells) and generate an overall combined histogram for each region, Evaluate the histogram against the “Max Delay” column in the above table and choose a window size that will capture 95% of the finger separations. Check the shape of the histogram to ensure that the existing window setting is not already too small (ie. is there a sharp cutoff at the current window setting). In this case, more data will have to be collected with a wider window setting before a proper judgment can be made. ‘The Nortel RF Optimizer will perform this analysis automatically. To get an idea of the tradeoffs involved for different active search window settings, the following calculations can be performed: For an active window setting of 60 chips and assuming the window is centered on the main ray from the cellsite, a multipath component that just falls inside the window will have traveled an extra 7.3km (30 chips @ 0.244kn/chip = 7.3km). For a nominal 2km radius and assuming a best case of free space path loss and no reflection loss, the multipath will be 2010g(9.3/2) = 134B lower than the main path. At the cell edge, even for an unloaded system, the Ec/lo of the main ray is unlikely to be better than -5dB which puts the multipath at -184B ie. marginal benefit. For a more realistic path loss exponent of 3.5, the multipath will be 351og(9.3/2) = 23.34B lower (approx. -28.84B Ec/lo). When we consider the larger cells and rework the numbers for, say, a Skm radius, assuming free space the multipath will be 7.84B lower (-12.84B Ee/lo if we continue with the 54B Ec/To main ray assumption) while assuming a 3.5 exponent the multipath will be 13.7dB down (-18.74B Ec/lo). The free space value represents a useful benefit to demodulation but the 3.5 exponent value is still marginal. ‘The corresponding numbers for a 28 chip window are as follows: 14 chips represents 3.4km so, for the 2km case, the free space multipath component will be 8.6dB down (13.6dB Ec/lo) while the 3.5 exponent multipath will be 15.1dB down (-20,14B Ec/lo). For the 5km case, the free space multipath component will be 4.5dB down (-9.5dB Ec/lo) while the 3.5 exponent ‘multipath will be 7.94B down (-12.94B Ec/Io). Clearly the Skm case could benefit from a larger active secrch window since components falling just outside the window would be appreciable interferers. For the 2km case, the 3.5 exponent still gives only a ‘marginal benefit. However, the free space case would be of value but how realistic is a free space assumption? ‘Two more aspects need to be considered before any conclusions can be drawn: 1. Search time will be substantially increased. If we take an example of 3 active pilots. 10 neighbours with a neighbour window setting of 100 chips. With an active window of 28 chips, the search time will be 0.42 secs. With an active window of 60 chips, the search time will be 0.64 secs ie. a 52% penalty. 2, All Ecflo values will decrease as loading increases. Issue 0.8 July 10, 1998 Page 41CDMA RF Optimisation —________———Technology Applications Group 6.6.2. SRCH_WIN_N In the Pilot Strength Measurement Messages, the mobile reports the phase of the pilots to the nearest chip resolution. Unless this pilot comes from another sector of the reference cell, there will likely be some offset from an exact PN (multiple of 64 chips). For example, in a system with Pilot_Inc = 4, a phase of 4874 is actually PN 76 + 10 chip offset and a phase of 25338 is PN 396 - 6 chip offset. ‘The general formulas for converting PN_PHASE to a PN and an OFFSET are: PN = INT(PN_PHASE/(PILOT_INC * 64)) + 0.5) * PILOT_INC OFFSET = PN_PHASE - (PN * 64) Generate histograms of the offsets as described above. This is the basis for setting the optimum value for SRCH_WIN_N. Gather all the histogram files for one entire network/cluster run. Classify the areas by average’ cell size (two or three regions should be sufficient e.g, “small” (dense) urban cells and “large” suburban/rural cells) and generate an overall combined histogram for each region. Evaluate the histogram against the possible window settings in IS-95/J-STD 008. The histogram should be biased to the positive side (i.e. pilots delayed from the reference are more common than early arriving pilots), Remembering that the window is centered around the reference, choos a window setting that covers 99% of the offsets. E.g. if 99% of offsets corresponds to, say, 47 chips, the next highest “half window” is 50 chips so a window setting of 100 chips (datafill of 10) would be appropriate. Check the shape of the histogram to ensure that the existing window setting is rot « already too small (ie. is there a sharp cutoff at the current window setting). In this case, more data will have to be collected with a wider window setting before a proper judgment can be made. ‘The Noitel RF Optimizer will perform this analysis automaticaily. 6.63. | SRCH_WIN_R SRCH_WIN_R is typically set one step higher than SRCH_WIN_N. This ensures that pilots missing from the neighbour list will be captured but also allows slightly more distant “stray” pilots to be detected. 6.6.4. _ BTS AccessChannelDemodulationSearch Width, ‘TrafficChannelDemodulationSearchWidth ip units ie 15.2 * 8 = 121.6. ‘However, the smallest increment that the CSM searches is 125 1/8" chip units so the settings should always be multiples of 125 i.e. 125 (for this example), 250,375, 500, 625 etc. Issue 0.8 July 10, 1998 Page 42tion T ns Grouy 6.7. Neighbour Lists Remembering that Pilot Stren; ut i ich i designated as the reference pilot, the basic ‘of neighbour list adjustment based on live data ae iJot that is requested to be ot Stren; Any the neighbour list of the reference pilot in that PSMM. @ Any pilots that are currently in the reference cell's neighbour list but never occur ina For example, consider the following NeighborListTuningArray (the NeighborListTuningArray is simply a repeat of the PilotStrengthMeasurementMessage with extended baseid included): Base ID Sector Band Class CDMA Freq Pilot Strength Keep Bit —Pilot_PN 28 3 1 50 8.50 1 220 zai 2 1 50 11.50 2 192 28 1 1 50 17.00 1 212 28 2 1 50 21.50 ° 216 PN 220 is the reference (since it ocurrs first in the message) so we are working on the neighbour list for that sector. PN 216 is being dropped so we do not consider it in this analysis. PNs 192 and 212 should both be in the neighbour list for PN 220. ‘Neighbour list tuning data comes from three possible sources: 1, Dropped call/failed access analysis. 2. Pilot Strength Measurement Messages (PSMMs) from drive test data. 3. NeighborListTuningArray data logged at the selector. Item 3 is very powerful since the quantity of data far exceeds anything that could be attained through normal drive testing. Also, since the data represents actual traffic patterns, there is far less risk of making bad neighbour list decisions because of the drive test routes chosen. Finally, since the extended base id is included, PN re-use does not cause problems in the data analysis. If the conclusion reached while analysing any of the above sources is that a neighbour list entry was missing, first refer to the predictions and determine whether that pilot is intended to cover that area. If not, the problem should be remedied with antenna adjustments. Only if it is determined that a genuine neighbour list omission has been found should the pilot be added to the reference cell’s neighbour list. Issue 0.8 July 10, 1998 Page 43RF Oy n Tech For cases 2 and 3, generate a per-site histogram of all the handoff transitions requested by the drive test mobiles over a complete drive of the system/cluster. The reference cell determines which sector's neighbour list is being examined. Further refinement can be added by including the ‘max, min and average Ec/lo for each entry. This is particularly useful for pilots found by a Remaining Set search since the frequency of occurrence may be low yet the strength may be high. Tuning tool sample output: KC104x, 6036: KC104y,2335,21,-8; KC1042,2705,26, 11; KC208x,41,0.4,-9 The above represents the output for one sector (KC104x in this example) and that 6036 NLTA records were logged with this sector as the reference. There is one entry for every PN that occurs when KC104x is the reference pilot (it is shown here with sector designations but the tool could bbe made to display PNs or baseids). Each entry contains the number of times that sector is. ‘requested, the percentage that represents and the average Ec/lo. Underlined sectors are those not in the currently datafilled NL. In the above example, the first two entries are the adjacent sectors of the same BTS so they are “normal” entries. KC6By is likely being found through the composite NL (high “hits” and good Ecfio) but should be added to KC104x’s NL. KC96z, should be probably removed (unless it is an immediate neighbour and itis just low traffic that is causing this characteristic). KC208x is probably being found through the Remaining Set search (low “hits” but good Ec/Io) and should be added if itis determined that it does not need removing from the area through RF coverage control, KC68y,536,5,-10; KC96z,34, For each sector, examine the statistics in conjunction with the Planet equal power boundaries plot. ‘Make sure there is adequate data for the sector. 1000 NLTA records should be regarded as the ‘minimum for that sector to be analysed. Consider removing any pilots that are currently in the neighbour list but have been requested less than 1% of the time. If drive test data is being used, make sure that it is not a consequence of the drive routes (for example, do not remove adjacent sectors of a sectored site). Consider adding pilots that are not currently in the neighbour list but have been requested greater than 1% of the time. The Nortel RF Optimizer contains tools to provide a much more sophisticated analysis of NeighborListTuningArray data. Issue 0.8 July 10, 1998 Page 44Figure 2.: Neighbour List Example Referring to the figure above, even if cell C appears as a handoff candidate inthe right half of cell A G jaded), it might not be put in gttonr tether TC 1s x MaNGOTT Candidate then ‘3 certainly will be GY this is not true, there are likely bigger problems to bzaddressed first) CwilT bs in B's neighbour list and hence the composite neighbour list sent to the mobile while in the right half of A Will contain C- range THObIIe 1S Mt The eH Half Of cel ‘mobile will not, saste search time looking foreellC. ‘Obviously the above diagram is very idealistic, Due to site selection issues and the topology of a real environment, many unusual cell arrangements will be found in the field. ‘However, it illustrates the principle that, in order to reduce the search time to find new pilots, the aim should be to minimise neighbour lists. Only in exceptional circumstances (¢.g. hard handoff border cells) should the BTS neighbour list be different from the pilot database at the SBS. 6.8. Performance/Trend Analysis If multiple drives of the same drive routes are planned, or if a benchmark joute is being used, the following parameters should be tracked: © Average forward traffic channel gain and percent time at maximum * Handoff overhead by sectors © Average mobile transmit power and percent time within SdB of maximum ‘© Dropped call rate The values of all of these measurements should reduce as the optimisation process progresses. Note that FER is NOT included as a metric. This is because we are confident that power control works and that if all other issues are addressed, good FER performance will naturally follow. Issue 0.8 July 10, 1998 Page 45DI ion Te ications 6.9. Per-Site Analysis ‘Analysis of data for when the mobile is locked to a single pilot can reveal configuration or performance issues related to a particular site or sector. Generate the following: 1. A‘file containing the average transmit gain adjust on a per-site basis for all sites in a run, This will highlight any sites having a significantly different ink balance, A si with a hi i i Jpay be suffering from a poor receiver noise figure or may he in alocation where forward ink, interference is prevalent. A site with an. abnormally Jow transmit gain adjust may have a low transmit power. 2. A file containing all lines from the parametric flat file for which the number of pilots locked = 1. A column containing the PN is needed. This will allow additional performance analysis on a per-site basis e.g. FER, traffic channel gain, Ew/No setpoint, finger separation. ‘The following table is an example output of a per-site transmit gain adjust analysis. We know from other analysis that the Whiterock (WROC) site is subject to interference from an adjacent CDMA system (hence higher TXGA). The Bumaby (BURN) site has the CDMA BTS. running from the CDPD multicouplers and likely has a higher noise figure (hence higher TXGA). Subsequent investigation revealed that the transmit power was 7dB low on the GILDZ sector (hence low TXGA). All other sectors are “normal” (the data was collected with no load on the system, hence the low overall values). a) Wage TEA meng 7) Pan wren ite Gerd Dele beter. 2) Leu TA eens Lee Th Pee Issue 0.8 July 10, 1998 Page 46Pilot PN Site Average TXGA 8 LGLY 714.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 716.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 -9.9643809 ‘The Nortel RF Optimizer will perform this analysis over many mobile logs automatically. Issue 0.8 ‘July 10, 1998 Page 47CDMA RF Optimisation = —_—_—____————Technology Applications Group 6.10. Capacity ‘The main requirement for obtaining good CDMA capacity is to eliminate unnecessary handoff and _Jninimise the transmit pawer requirements on Goth Torward and reverse Tinks through the following: * good RF coverage,control (no unnecessary handoff and interference) ‘© effective handoff ( good neighbour lists, optimum search windows) * cptimum power control settings ‘* maximise access channel effectiveness eee 6.10.1. Capacity Equations 6.10.1.1, Reverse Link (wi) * Ebino)xv*'*S Where: N= theoretical number of users per sector (Pole Capacity) WIR = the ratio of spreading bandwidth to information bandwidth (ie. the processin;, gain) Eb/No = the energy per bit / noise density V= the voice activity factor (VAF) = the ratio of power received from users in this sector to power received from’all users S = the sectorisation gain Al values expressed in linear terms (not dB). This equation takes no account of thermal noise and so is for a sector of zero radius (100% of the Processing gain is used to fight the noise of other users). To design “real” cells, we need to allocate some Of the processing gain to fighting thermal noise. We typically allocate half (ie. we design for 50% loading). If we measure the noise floor of a BTS receiver with no load and then apply 50% load, the noise floor will double (since we are allocating half the noise to each). This is the “3dB noise rise for 50% oad”. A more general equation linking noise rise and load is: Load (%) = 100 x (1 - 10°%®"%) Therefore, if we can measure the noise rise that a certain number of users causes, we can calculate either pole capacity or 50% load. Issue 0.8 July 10, 1998 Page 48CDMA RF Optimisation ‘echnology Applications Group The only terms we can influence easily are f and S and since these will also be improved when we optimise the forward link capacity, all remaining discussion will concentrate on the forward link. 6.10.1.2. Forward Link Slightly different equations are used, depending on whether the data source is drive test data or BTSPerformanceData 6.10.1.2.1. From Drive Test Data The following equation gives the potential loaded capacity of a sector in terms of the number of users with average forward traffic channel gain and typical soft handoff percentage for a system/cluster. Definitions: N = the number of average users a sector can support assuming the above conditions. foux= the fraction of total HPA power allocated for the pilot channel fae «the fraction of total HPA power allocated for the paging channel oyna the fraction of total HPA power allocated for the synch channel four = the average fraction of total HPA power allocated for one traffic channel hrf = handoff reduction factor, a calculated value which takes into account the required RF power due to different types of handoff v= the voice activity factor (VAF) Handoff Reduction Factor (hrf: this term adjusts the average power per user based on the collected handoff statistics for the system under test where: Issue 0.8, July 10, 1998 Page 49fof = May +2-Myy +3-May + (2-201 #3-Mhas +4 +3-May +67 ee ee beens (-rs51#4-ay +5ag +6-Mhy9)* ee 49) FO Thay #5: * &xn(q,B) is defined as follows: * 8 =number of sources of power control bits the system is having to send to the one mobile * 1(@,B)= the percentage of time the one mobile experienced this type of handoff, and ‘© a= the number of cells with which the mobile is communicating ‘* B= the number of sectors with which the mobile is communicating © v4= voice activity factor for ‘x’ number of cells in soft handoff (ie., the adjusted voice activity to account for variations in power gain of the power control bit due handoff involving x cells. tor (V. Me © v=the average Markov voice activity factor for single sector coverage = [P(full) 1+ Ponalfy05623-5+ 1 P(quarter)0A467 +7 + P(eighth)03162- Px at 24 © v= the average Markov voice activity factor for single sector coverage © P(full) = the probability of a full rate frame occurring = 0.291 ‘* Phalf) = the probability of a half rate frame occurring = 0.039 © P(quarter) = the probability of quarter rate frame occurring = 0.072 * P(eighth) = the probability of an eighth rate frame occurring = 0.598 © 1/2, 1/4, 1/8 = the relative power (to a full rate frame) associated to each corresponding frame © 23/24 = the portion of a frame for which the relative power levels apply [ July 10, 1998 Page 50rot © 1/24= the portion of a frame for which the power control power level applies © px’ = the relative power (relative to a “no handoff" power control bit) given to a power control bit for the appropriate type handoff: © for x=2 (for handoffs involving 2 cells), p2? = 2 © for x=3 (for handoffs involving 3 cells), ps? = 3 © for x=4 (for handofts involving 4 or more cells), pi? = 4 * the constants for 1/2, 1/4, & 1/8 rate frames are hard coded numbers in our loads that further reduce the power of these frame rates. 6.10.1.2.2. From BTSPerformanceData The following equation gives the potential loaded capacity of a sector in terms of the number of users with average per-link power and typical soft handoff percentage for a system/cluster. P. Nw Pestbice “(Poucs + Poage + Payne) Definitions: Pane" SPU ‘N= the peak number of unique average users a sector can support assuming the above conditions. Peatniae= the power at which new calls are blocked Phusc= the pilot channel power Phage =the paging channel power Psyscr« the synch channel power Punk = the average power that one “link” consumes (a link is defined as every user who is either in isolated coverage of this sector or who is in handoff with this sector) ‘SPU (Sectors Per User) = the average number of sectors that one user is in handoff with (could think of this as “links per user”). 6.10.1.2.3. Interpreting the Equations The ave traffic cl r gi ink” or “cor tion” to a. or FE Tae ee ee average poe ha “Gus to the fact that one user Sector as well as other users in other sectors). Finally, therefore, the equation calculates how many of these “average users” can be fitted into one HPA. Therefore, when we say that the capacity is, say, 13 users based on this equation, we are saying that is the peak load on the sector at 100% blocking (equivalent to all radios being used in an AMPS sector). When the system is running at 1% blocking, individual sectors will occasionally peak at 13 users but the average will be 6.6 users. Issue 0.8 July 10, 1998 Page 51DI in 01 licat ‘Note that, unlike a wireline application, the 13 users are not independent “channels” and this number is influenced by the average load on the system, in this case 6.6 users (Erlangs). Therefore, it would be erroneous to decide to run a system at 5% blocking and use the Erlang B table to establish that 8.8 Erlangs could be carried. If there are, on average, 8.8 users on each sector then, due to the extra interference in the system, the peak available will be less than 13. Therefore, 8.8 Erlangs/5% blocking is not a valid combination. Likewise, as the average load decreases below 6.6 Erlangs, the blocking will reduce faster than the Erlang B table would suggest. 6.10.2, BTS Operation Before explaining some of the adjustments that can be made to optimise capacity, it is necessary to understand some aspects of BTS operation. Refer to the table at the end of this section (1900MHz BTS illustrated - Nortel employees can retrieve this spreadsheet from the Technology Applications webpage server and experiment with different settings). The BTS forward link has two “domains”; the digital domain and the analogue domain. The digital domain refers to algorithms involving the digital “gains” that control the output level of each Channel Element. The analogue domain refers to the total BTS output power as measured at the RFFE Antenna 0 ‘on the 1900MHz equipment or the “Demare” pane! on 800MHz equipment and controlled by an attenuator in the upconverter. The “fully blossomed” value of this. attenuator is controlled by a datafillable parameter TxAttenNormal. (Need a diagram here to illustrate above) 6.10.21. 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 is then adjusted using TxAttenNormal until an output power of 4 Watts is obtained (note that this is NOT the pilot setting since the pilot is actually run at a lower gain ie. we are NOT “calibrating for a 4W pilot”). Once this relationship has been established, we can calculate the power equivalent to any gain or combination of gains. Example; what is the output power fof a) the pilot and’b) the pilot + sync + paging if the digital gains are Pilot = £86; syne = 60 and paging = (36, Answer; Since the digital gains are-voltage gains, most calculations are in terms of “bits squared” to convert to power. Therefore, if 254? = a ‘Watts, the power corresponding to 186 is: power = (186/254) x4 = 2.14 Watts’ and the power for all three channels is: power = ((186" + 60° + 1567)/254*) x 4 = 3.88 Watts Issue 0.8 July 10, 1998 Page 52it Power Tracking Loop (TPTL) is provides a guaranteed linkage between the analogue and digital domains since it constantly maintains the 2542 - 4Watts relationship. This is achieved using a feed back loop that sums up the current digital gains for all overhead, traffic and OCNS channels, calculates the expected output power and compares it to the analogue senisorTeuding. If the two do not match, an offset (TPTLOfiset) is applied to the upconverter attenuator. Note that accurate calibration is still required since the TPTL will not apply more than +/-6dB of correction. However, great emphasis must be placed on confirmitig the sensor accuracy since TPTL relies on it’s readings. TPTL is in release 6.1.1 for 1900MHz and 6.3 for 800MHz, 6.10.22, The Digital Domain, Forward Power Control and the Forward Blocking Thresholds ‘The power output of any channel element is controlled by a digital gain, The overhead channels are fixed Values datafilled at the BTS on a per-sector basis. The traffic channels vary within a defined range as tequired by forward link power control. The range for the traffic channel gains is datafilled relative to pilot power. For example, with a pilot gain of 216, an upper limit of -1dB pilot and a lower limit of -15dB pilot, the selector will send digital gains in the range 192 to 38. Note that the pilot gain is datafilled both er-sector at the BTS and as a global parameter at the SBS. It is the SBS value that is used to calculate the digital gains for the traffic channel. Therefore, even if the pilot gain at one sector of a BTS is lowered by, say, 1dB to 192, the SBS will continue to send digital gains in the range 192 to 38. Le., for this sector alone, the traffic channels are now effectively OdB pilot to -14dB pilot. ‘The forward link Call and HandoffBlockingThresholds are datafilled in terms of ExcessForwardLinkCapacity which is a bits-squared value. ExcessForwardLinkCapacity is calculated as follows: 1, Square the pilot gain (e.g. 186” is 34596) 2. Divide by MinPilotToTotalPowerRatio (e.g. 34596 divided by -7.54B (in linear termns) is 194547). Call this number the “blocking threshold reference”, 3. Sum up the bits-squared over all channel elements 4. Subtract item 3. from item 2. The result is the ExcessForwardLinkCapacity. If the ExcessForwardLinkCapacity is less than the FwdCallBlockingThreshold, then block new calls. If the ExcessForwardLinkCapacity is less than the FwdHandoffBlockingThreshold, then block handoffs. The table shows how these numbers translate to actual powers in Watts, Note that there is no action if the “blocking threshold reference” is crossed although ExcessForwardL inkCapacity will never be reported as a negative number. Issue 0.8 July 10, 1998 Page 53CDMA RF Optimisgtion __..|.|.||..._____Technology Applications Group 6.10.2.3. The Analogue Domain, Power Sensor and Power Limiting Immediately following the High Power Amplifier (HPA), there is a power sensor that is calibrated to report the total power at the demarc panel (800MHz) or the RFFE output (1900MHz). The report from this sensor is in units of 1/16" dBm. Beware that this sensor is not immune to the waveform of the transmitted signal and since the sensor has been deliberately calibrated for the “most likely” situations, an offset needs to be applied in some cases: 1. Single walsh code, low power (i. 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 (ie. few low power users): sensor reads 0.754B low (12/16" dB). 4. Multiple walsh codes, medium to high power (i. carrying traffic): sensor reads correctly. The sensor reading is compared against a datafillable upper limit TxPowerMax. If this threshold is exceeded, the BTS will wilt the sector by one step and re-compare the reading with TxPowerMax. This is the Power Limiting algorithm and it repeats until the power no longer exceeds TxPowerMax. This limits the output power to TxPowerMax. However, forward link power control will act in opposition to the power limiting, possibly causing an unstable situation. For this reason, this algorithm should be viewed as an HPA protection mechanism only and the blocking thresholds should be set such that Power Limiting is a rare occurrence. The FwdHandoffBlockingThreshold should be at a higher power than the FwdCallBlockingThreshold (give priority to existing calls), ‘Using TxAttenNormal to permanently reduce the transmit power is not recommended for two reasons: 1. The Transmit Power Tracking Loop that js soon to be introduced (6.1.1) will null out small changes or cause a fault to be reported for larger changes (> 6dB). 2. For every 1dB that the forward link is reduced, the reverse link noise figure should be increased 1dB. Although there is another parameter that can accomplish this, itis not datafillable (requires an “action”) and so the change is very hard to maintain, ‘The (crude but) effective way to achieve an equal reduction in coverage on both links (Which is vital to system performance) is to use attenuators in the antenna cables. Fo IKey [calculation lot a ine lp ging (Half Rate) le [Total Overhead lt fasbee [Typical User Traff Chan Gain Je |(97™2)*VAP*1.15 Issue 0.8 July 10, 1998 Page 5410°60) 2aiaay Ib ou 61000} ki | 1) Remember the calculation STARTS from the pilot power - MinPilotToTotalPowerRatio does NOT set pilot power. 8) Calls should be blocked at 90% of TXPowerMax. Handoffs should not be blocked, 4) This number by itself has no meaning, it is just the level that the blocking thresholds are referenced to. 5) 1.15 factor allows for increased power of power control bits during handoff 6.10.3. Optimising for Forward Link Capacity The procedures covered in the RF coverage control section are aimed at giving good capacity throughout the network. However, sometimes there will be a requirement to improve capacity still further over a small area (up to, say, 4 sectors), possibly at the expense of capacity in the surrounding sectors. Referring to the forward link capacity equation, we can see that reductions in traffic channel power and unnecessary handoff will both lead to higher capacity. It is important to stress the unnecessary handoff since, taken too far, handoff reduction will result in poor performance of the forward link in terms of dropped calls, FER and capacity. The following strategies should be considered for improving capacity over a small area (the “hotspot”): Issue 0.8 July 10, 1998 Page 55RF. Te lications © Removing i i tors: If the mobile is going into handoff with sectors ‘outside the hotspot area and this is causing handoff in excess of 3-way, those sectors should be removed by downtilting/antenna change/orientation change/power reduction (remember to reduce the reverse link as well). Since the mobile has only three rake fingers, consistent handoff above 3-way requires more traffic channel power to overcome the interference from the active set members that are not being demodulated. © Removing interfering power from other sectors: If sectors outside the hotspot are transmitting power into the hotspot but the Ec/o is too low for the mobile to go into handoff, those sectors should be removed by downtilting/antenna change/orientation change/power reduction (remember to reduce the reverse link as well). These interfering sectors result in a need for more traffic channel power to overcome the interference and maintain FER. * Reducing handoff within the hotspot: If pilot quality is good throughout the hotspot, a reduction in pilot gain by 1 or 24B on the hotspot sectors can be very effective. Since the traffic channels will remain at the same absolute level as before, this has the effect of lowering the Ec/lo of the hotspot sectors and hence reducing handoff. This is much more effective than increasing T_ADD and T_DROP for three reasons: 1. Raising T_ADD and T_DROP must be done on the surrounding sectors as well as the hotspot sectors since the mobile needs to have the new values before approaching the hotspot sectors. This causes a general lowering of handoff throughout the region. Reducing the pilot gain, on the other hand, targets the hotspot sectors very specifically and will also allow surrounding sectors to pick up some of the traffic since it actually shifts the handoff boundaries rather than just reducing handoff. Because of the rules for updating T_ADD and T_DROP (most negative value for any of the active set), many more sectors need to be changed than are really required. This may caus problems elsewhere where the higher T_ADD and T_DROP cannot be tolerated. 3. Reducing the pilot power frees up some HPA power for traffic channels. v 6.11. Power Control ‘The power control parameters given in the Technology Applications datafill spreadsheets are the result of much simulation and field testing effort (reference power control report). Target frame error rates may be adjusted if the average frame error rates are not meeting customer expectations (changes to the reverse link should be done by scaling all 5 targets). Changes to the step sizes or the upper/lower/start values should not be contemplated unless a specific set of carefully designed tests are carried out solely for this Purpose. The forward link power control parameters for rate set | (PWR_REP_THRESH, PWR_REP_FRAMES) should not need to be adjusted. (Explain why reverse link looks like set to 0.5% but is really 1% because of the way the algorithm works with non-equal per-rate target FERs) Issue 0.8 July 10, 1998 Page 56CDMA RF Optimisation ‘Technology Applications Group 6.12. Hard Handoff (This section under construction - main aim is to achieve trigger conditions that result in the transition to a clear, unambiguous pilot on the target frequency. Talk about two types of Inter-System Hard Handoff; “double BTS” and “RTD”. Talk about pros/cons of defining other sectors as borders. Also talk about idle mode hard handoff options and all the “tricks” for idle mode, such as empty BTS neighbour lists). 6.12.1. Round Trip Delay (RTD) Calculations ‘The BTS is able to measure the Round Trip Delay as follows: + Remembering that 1 chip is 0.814uS, 1 chip represents a 1-way propagation distance of 244m. * Say a mobile is 2km from it’s reference cell. The propagation delay in terms of chips for 2km is 210.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 to system time, ‘When the mobile now transmits to the BTS, a further 8.2 chip delay is incurred. The BTS “expects” the signal to arrive as if the mobile were at zero distance from the BTS. In this example therefore, the signal arrives 8.2 + 8.2 = 16.4 chips “late”, * This is would be the RTD measurement if the BTS were making all it’s measurements right at the antenna. In reality, there is some processing delay on both the transmit and receive paths internal to the BTS. Two parameters, FwdDistributionDelay and RvsDistributionDelay, are available to ‘ffectively “zero” out this internal delay. If these have been datafilled correctly then all RTD calculations only need to take the “over the air” delay into account. Otherwise, the sum of these two parameters will effectively be added to all RTD measurements. The DistributionDelays are datafilled in 1/8" chip units. RTD is also reported by the system in 1/8" chip units. A report is generated every time the RTD changes by 2 chips. Example: What is the required datafill value for an RTD triggered hard handoff to occur at 1km from a cell a) if the DistributionDelays have been set correctly and b) if the DistributionDelays have been left at 0 on a 1900MHz BTS. Answer: Ikr: 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/8 chip units, the datafill for answer a) is 66. On a 1900MHz BTS, the sum of the DistributionDelays is in 1/8 chip units and is 79 + 212 = 291. Therefore, the datafill required for b) is 291 +66 = 357. 6.13. Other Future revisions of this document will contain sections on the following: © registration © paging, SMS © traffic management (blocking thresholds, breathing, multi-carrier) * (more...) Issue 0.8 July 10, 1998 Page 57Optimisation ology Aj rouy z. ropped .ccess Fail ms and Soluti (This section under re-construction) This section details the characteristics that will be observed in the diagnostic logs for various field issues that will be encountered throughout the network. Section 8 will cover issues specific to special cases 7A. Successful Call This section explains the characteristics in the data for a phone that originates succesfully, remains in the service area, completes a handoff and makes a normal release, 7.1.1 Symptoms in Mobile Data If only mobile data is available, the parametric files will show: + Receive power > -100dBm + Transmit power <+184Bm + Normal Transmit Gain Adjust (actual value depends on site configurations, loading, NOM_PWR setting) = + Low forward FER Good Ee/fo (> -124B) on at least one pilot Under these conditions, messaging will be reliable. In message file output, a basi; call (originated ant released from the mobile) will contain the following elements : * Origination message (sent to MTX on Access Channel). ‘BTS Acknowledgement (received from BTS on Paging Channel) + Channel Assignment (received from MTX on Paging Channel). * (Mobile now acquires the forward traffic channel, then starts its own transmitter, then the BTS acquires the reverse traffic channel. All transmissions are 1/8 rate null frames) + Forward Acknowledgement (received from SBS on traffic channel - acknowledges acquisition of reverse tch - this is ack requires an acknowledgement) + Reverse Acknowledgemnt (sent to SBS - acknowledges receipt of forward acknowledgemnt) + Service Connect Message (received from SBS on traffic channel - all remaining messaging is on the traffic channel). + Service Connect Complete Message (sent to SBS - we consider a successful origination to have been ‘made if this message is sent). + Pilot Strength Measurement Message (sent to SBS - initiates handoff). + Extended Handoff Direction Message (from SBS - directs handoff -if all is well, will contain same PN requested by the mobile). Issue 0.8 July 10, 1998 Page 58RF. Handoff Completion Message (sent to SBS - confirms receipt of Extended Handoff Direction Message). + Neighbour List Update Message (from SBS - contains new composite Neighbour List) fon + 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_PWR setting) + Bw/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/lo (> -12dB) on at least one pilot A auessage flow file for the same basic call will contain the following IS-95 messages: rou yot__01:12+02.5850 195_AChanoriginationMegtype AS:7 MSS ARI mae 12:02.7287 195_pchancoMAchannelListkegtype Pr:320 ym 01:22:02.8475 195_Pchanordertagtype vo 01:12:03.1475 195_PchanextendedSystenParanstersisgType PPN:320 YM —_01:12:03.1688 195_PchangeneralPagexedtype oe 6687 195_PchanchannelAssignnentMsgtype ss 7400. 195_PtChanordermagtype AS:7 MS:0 AR: OR:26 ae +8087 195_ptChandrderMagtype AS:7 MS:0 AR: OR:6 moe 8863 195_pTChanorderMsgtype AS:0 MS:0 AR: OR:26 ss 9200 195_RTChanordernsstyDe AS:0 5:0 AR:OOR:6 ss -9400 195_PTChanPowercontrol¥arametersisstype ss +9600 195 PxChanserviceconnectMagtype aS) M512 ARID 0 0075 195_P1ChanPowerControlParaneterstisgType m4 -0288 195_PTChanServiceConnectiagtype AS:7MS:2AREL oe 0675 195_paChanserviceconnectCompletiontaytyp AS:1 MS:0 ARE ss 1000 195_R7ChanServiceconnectCompletiontiagyp AS:1 Ms:0 ART ma 1075 195_arChanorderMegtype AS:2 Srl AR: OR:16 ss 1400 195_atChanordermegtype AS:2 MS:1AR:OOR:I6 88 01:12:04.2200 195 _Prchanorderxegtype AS:0Ms:0AR:0 R16 ym 01:12:06.2687 195 _PrChanorderegtype AS:D MS:O AR: ORE Issue 0.8 July 10, 1998 Page 5901:12:05.2075 195_RTChanPilotstrengthMeasurenentHagTyps AS:2 MBit PPNS:320R:( =7.00)X 3121 (-12.50)K SS 0112:05.2400__195_RTChanPilotstrengthMeasuronentMsgtype as:2 mst ARAL PPNS:320R: ( =7.00)K 322: (-12.50) 88 01:12:05.3000 195 _FrchankxtendediandoffDLrectionlsgType AS:L MS:3) RL PeNe:320 (0) 312 (i) Sechiin A:6 TA:2@ TO:32 TC; 3 TID: 3 88 01:12:05.3200 95 _rrchankxtendediandof fDirect ionagType AS: MS:3) ARIZ PPNs:320 (0) 332 (i) SrchWin A:6 TA:28 7D:32 Te: 5 TID: 3 88 01:12:05,360. 195 _Pachanextendediandof Direct LonMsgType AS:1 Ms:3) ART PeNs:320 (0) 312 (i) Sechiin A:6 TA:28 70.32 SC, 5 77D: 3 to 01:12:05.3608 195_Prchankxtendediiandof Direct LomMsgType asi MS: ART Ppxs:220 (0) 332 (I) SrchWin A:6 TA:2@ 0:32": 5 TED: 3 no 01:1205.4075 95_Rrchanordermsgtype AS:3 MS12 ARO ORI6 to 01:12:05,410 195_prchankxtendadiando£ {Direct ionMegtype aS M513 ARID 'PPN5:320 (0) 342 (1) Srohwin As6 TA:a8 "D.32 Se: 8 TID: 3 SS 01:12+05,4400 95 _RrChanorderusgtype AS:3 siz ARO WE 01:12:05.4475 _195_RTChanHandoffcompletionkesType ass aR: Pie :320°312 MOL ——01:12:08.4500_195_erChansxtendediiandof fDi eect ionttegtype AS Ms:3 ART Prmig:320 (0) 312 (7) SvehWin A:6 TA:28 "D:32 Te: 3 TID: 3 S$ 02:12:05.4800 195_RTChanlandof complet ionsgtype AS:3 MS? ARIZ PPNe:320 312 YM 01:12:05.4875_195_RTChanordernegtype AS:3 MG:3 AR: oR:36 SS_ 01:12:05,500. 195_rrchanVeighborLiatupdatenastype AS:2 used ARs. PEN, Enc: 4 MPws:326 G0 300 268 428 304 292 176 420 364 Se 284 172 276 200 186 184 296 426 428 S$ 02:12:05,520 195_RTChanorderMegtype AS:3 MS:3AR:OOR:16 MOL 02:12:05.5275195_RaChanordexMegtype AS:3 MS:4 AR: oR:16 SS 02;12:05.5600 195_RTChanorderMegtype AS:]MS:4 AR: oR:16 Wor 03:12:05.3700 195 _FTChanNetghborLi stupdateagiype 48:20 Moe aR: PP Tne: 4 NDNe:316 60 300 288 426 304 292 176 420 364 56286 272 276 200 188 154 296 426 428 SS 01:12:05.6800 195 _nichanordermegtype AS:€ MS:5AR:O.OR:I6 88 01:12:12,940 195_PrchanserviceopeioncontrolMegtype Ms:5 ARS wat 01:12:13.0287 195_prchanserviceoptioncontrolmsstype Ms:5 ARG Wr 01:12:23.1075195_archanordermagtype wS:6 AR: oR:26 SS 01:12:13,140 195_encnanorderisst¥ype MS:6 ARO OR: $5 01:13:45,100. 195_prenanserviceOpt ioncontroldesType Ass MB:0 ARS mor 01:13:45.1088195_prchanserviceoptionControlseytvpe Aes ws: asa Yo 01:13:45.2200 _195_pachanserviceoptionControlMegtype asd M533 ARO 55 01:13:45.5200 195_PrehanserviceoptioncontroidsgType ania % —_01:13:45.6100_195_PTchanserviceoptionControlMsgType area ye 02:13:45.6075 195 RachanorderteyType amo ont 85 01:13:45.7200 195_eachandrderitagtype ano ons vet 02:13:52.3275 195_enenanordertestype aso amet onsaa 85 02113+52.3600 195_Rochanordermegtype AS: WS: AR. oRs21 S$ 02113:52.4400 95_erchanordertegType AS'S MS: ARO OR:21 ve 02;13:52.5087 x95_Pnenanorderxestype ASS MSs. ARO OR:21 ver 02113:52.9725 195_schansynexegtype pis312 Iseue 0.8 July 10, 1998 Page 60DI Techn rou Note how the message sequence and acknowledge sequence numbers work e.g. if'a Pilot Strength Measurement Message is sent with msg seq 3, the Extended Handoff Direction Message will have an ack seq of 3 (confirming that it is the acknowledgment to that particular PSMM). ‘The MM and SS indicate messages logged at the mobile and SBS respectively (i. if all is proceeding normally, every traffic channel message will appear twice, once at each logging point). Order type 21 is a release message. Issue 0.8 July 10, 1998 Page 61DI oO Te 7.2, Access Fail and Dropped Call Reasons in Single Frequency System ie. no hard handoff Description [Symptoms in data Solution Access Failures Bad pilot choice - drops paging channel or more probes (have seen up | Control RF to reduce t0$),n0 Ack or CA at mobile, _|cases of multiple pilots then immediately back to SYNC. | with no dominant server. Poor Ee/fo. Lots of Bad Paging (Channel CRCs. Does pilot selection algorithm need improving? Bad pilot choice - missed JChannel Assignment Msg Mobile receives P-channel order [Control RF to reduce and stops probing but no CA —_|cases of multiple pilots seen. Selector logs will have | with no dominant server. }NOIS msgs setting up resources etc, [Does pilot selection algorithm need| improving? Bad pilot choice - fails to acquire fwd tch, [Mobile receives channel [Control RF to reduce asignment but goes to SYNC _| cases of multiple pilots within 1 second, Selector power | with no dominant server. [control setpoints at selector | Increase PTX start to - frozen at starting values. Mobile | 1¢B. never enables its transmitter. Does pilot selection algorithm need| improving? Also, fix introduced in 2.4.5 that temporarily increases {fwd TCH gain by 5 54B during acquisition phase. Bad pilot choice - distant PN JAtthe end of acall, mobile | Downtilt distant PN if [chooses to Sync to a distant PN | possible. [even though better local PNs are apparently available. Next eiginaon als case Neighbour List of distant PN does not contain an xe /Mobile algorithm only looks for est pequate PN athe than the BestPN Doss plat selection algorithm need improving? Bad pilot choice - before svc Forward link dies before first | Control RF to reduce handoff can be completed (and | cases of multiple pilots still before Service Connect. _| with no dominant server. (Complete) messages). Usually see multiple EHODs and Service [Connects from selector but not arriving at mobile. Does plot selection algorithm need| improving? Issue 0.8 July 10, 1998 Page 62+184Bm. Bad erasures both the existing cellstes can Dropped Calls Slow handoff [Mobile requests handoff to new Minimise search time by Currently highest reason for pilot (which was in NL), selector |optimsing SRCH_WINs _| dropped calls. Do N and A window| sees PSMM, starts sending especially A but don't go |analysis asap in the optimisation EHODs but none arrive at mobile] below 28 chips), trimming| process. Don't forget to trim your because new PNis interferer neighbour lists and neighbour lists after doing. (stays as candidate). Mobile will | reducing the number of | downtilts. Selector selntOSaa has likely SYNC to pilot it was | way HO by controlling | quickrepeat and higher gain on requesting. Poor Ee/lo, high fwd |RF. If new pilot increases | EHOD to mitigate this problem. erasures in strength suddenly, look at alternative antenna arrangements [Coverage Mobile RX close to or below - | If you really need 100dBm. Mobile TX above _| coverage here and none of, {wd link. After drop, mobile SYNCS to a pilot that wasn't in Tast neighbour list update. |PSMMSs unlikely (although may be picked up on Remaining Set, search), area. If not, contro the coverage (downtilt etc.) If it is (or it cant be removed from that area) then a neighbour list change is req way, peor Boo High selector [te -pemuned to covert powerconsolsepcins [ten you ed anew L alse BN Aang Mabie ses anda nection fe Plt foaPN inthe neighbour list ot |[Dataaevelghou Ist allconinssto dere and |rveithat the PN is with aleymptons offwd__ fetal rere oa r-se linkter (go RX poo that PN and not the one Peo hgh erase) the mobile eading fovars, PN rene require Noi aso snd | obie sede Asko Extended Mobile ix equied [Mobs as NOT acd one HandottConpion | Handotf Dectin Mesoge tt HOD (hs not opted seine Messe orn followup with HOC se. Selector tine. wating for OG or noin neithour it | Good mobile RX power bt poor [Fit se the plot tt” [Dol fogs remem your Fefloantercuree Usialcise’ [cased te opis, {ocghbeut linear cing ofdeuhiinessaping eure on fimendedosove tat Gowns can any beroved? Un-identified Interferer | (Good mobile RX power but poor Ec/lo and erasures. Usual cause of death is messaging failure on fwd link. After drop, mobile ISYNCs to a pilot that was in last neighbour list update but no PSMMSs sent. Essentially a neighbour lst problem as above but interference has gone away by time mobile syncs s0 hard to tell who itis. Driving area very slowly ]ean often reveal the interfering PN. Easier to see with OCNS off. Issue 0.8 July 10, 1998 Page 63,CDMA RF Optimisation __oo|.|...______sTechnologv Applications Group + Ifa reverse message is repeated because an ack is not received, either it is not getting to the selector (reverse link is worse) or the fwd ack is not reaching the mobile (fwd link is worse). The parametric files may indicate which is happening but ideally selector logs are required. + Ifa fwd message is repeated then the rvs ack is not reaching the selector (reverse link is worse). + Hethe mobile repeats a message 3 times without seeing the ack, it will tear the call down and will go ‘to the sync channel, + Ifthe selector repeats a message 5 times without seeing the ack, it will send a forward release and the ‘call will be tom down-if the mobile sees the release, it will respond witha reverse release and stop ‘transmitting. 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: 733. Further Analysis 73.4 Corrective Action 7:1. Site Not In Service i.e. pilovpaging/sync are being broadcast but can’t handoff/originate 7.7.1 Symptoms in Mobile Data looks like fwd interference (good RX, poor E¢/Io, poor FER, high TXGA), will see PSMMs requesting site and see site go to candidate on data collection tool but never active 7.1.2 Analysis with Selector Logs NOIS will show failure to setup resources at new site 7.73. Further Analysis Repeat shakedown at the site 7.14 Corrective Action Issue 0.8 July 10, 1998 Page 65CDMA RF Optimisation ____________mMm. Technology Applications Group 7.8. Interference From Non Co-located AMPS Celisite 7.8.1 Symptoms in Mobile Data Looks like fwd interference (good RX, poor Ec/lo, poor FER, high TXGA) 7.8.2 Analysis with Selector Logs 783. Further Analysis 7.84 Corrective Action Need either more CDMA power or less AMPS - likely neither are practical so will have to live with problem 7.11. Handoff Boundary Balance 7.11.1 Symptoms in Mobile Data 7.11.2 Analysis with Selector Logs 7.113. 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/lo, poor FER, high TXGA), mobile will sync to the problem site after call drops Rvs: (high TXGA, high TX) Issue 0.8 July 10, 1998 Page 66CDMA RF Optimisation ___........._____—Technology Applications Group 7.12.2 Analysis with Selector Logs 7.12.3. Further Analysis 7.124 — Correetive 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 ile. when competitor cellsite is at edge of CDMA cellsites - competitior’s TX noise floor will interfere with fwd link 7.14.1 Symptoms in Mobile Data Looks like fwd interference (good RX, poor Ee/lo, poor FER, high TXGA) Issue 0.8, July 10, 1998 Page 67co Te icat 8. ther imisation P) Special 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/lo plots in Planet © Create the datafill for the new cell (parameters such as search windows, access channel settings, can bbe copied from surrounding cells) © Blossom the cell during a low traffic period and perform shakedown * Cell is now available for carrying traffic * Enable the NeighborListTuningArray and tune the neighbour lists. ‘* Perform full optimisation of the area at the next opportunity (e.g. after several new cells have been put in service) 8.2. Other Special Cases Future revisions of this document will contain sections covering the following: © microcells highways ‘© geographic related © inter-system soft handoff © (others...) Issue 0.8 July 10, 1998 Page 68DMA RF Optimisation |... Technology Applications Group 9.___ Appendices 9.1. Sample Mobile Data Log Sheets Date: (YYMMDD) VAN CREW: RUN: | Test: | Roore | Venicue win Cat] Rate] SBS] _2ND Toone TYPE. Loos _| PHONE BN @ mvj ise |yni| yn IM BN @ mvjises|yniyniM DATA COLLECTION SOFTWARE: HaNoset SOFTWARE: NETWORK SOFTWARE: Loomask: # Sires Active: SITES NOT AVAILABLE: (START Te ‘Stor Te, Key | Te | MIN CoMmenTs: TLocamion pet ye 0 LE or re ao ae ew racer emt wens tncr weiner The top portion of a mobile log file appears above, a complete set of log sheets can be found in Appendix xxx. The engineer monitoring the data collection tool was required to keep this detailed log throughout the data collection process. The first following information was recorded on the log sheet. Date: The format for the date was yymmdd and this format was maintained throughout the data collection process. The data was placed in subdirectories on all the computers under this date. ‘Van Crew: A record of the memibers of the van crew on the day the data was collected is necessary in ‘case there are any questions about the logs after they are collected. Run Number: The ran number is always prefixed by a letter to indicate the van that was used for data collection. This information is vital in the event that a problem is subsequently identified with the data collection tools in the van. ‘Test: A description of the test being done and the parameter or situation being investigated. Route: The drive route used for the data collection. Vehicle: The appropriate letter is circles to indicate the van being used where N indicated the Nortel ‘van, Q indicated the Qualcomm van, and B indicated the BCTel van. MIN: The mobile identification number used for the data collection. Issue 0.8 July 10, 1998 Page 69Call Type: The appropriate letter was circled to indicate the type of call being used for the testing. M indicated Markov calls and V indicates Voice calls. Rate: The vocoder rate used by the mobile handset, 13 for 13k vocoder and 8 for 8k vocoder. SBS logs: Circling Y indicates that SBS logs were being collected in conjunction with the mobile logs, circling N indicated that no SBS logs were collected. Second Phone: Y was circled to indicate that a second mobile was logging in the same van during testing, N was circles to indicate that only one mobile was being logged during testing. ‘Log File: The log file name provided by the data collection tool at the end of the logging period. These Jog file names always begin with an M. Date Collection Software: The software version of the data collection tool on the day of the test. Network Software: The version of the software being used on the network. # of Sites Active: Number of sites on the air on the day of the test. Handset Software: The software version being used in the handsets on the day of the testing. Logmask: The logmask being used on the data collection tool during the testing. Sites not available: A list of sites that were not on the air during the test. Start Time and Stop Time: The start time and stop time of the mobile log. All times recorded use the GPS time of the system in order to reference the data logs being collected by the data collection tools. Key: The key is contained in a footer on the log sheet. Events of note are recorded using the key to quickly code the event. As Vancouver has many bridges and bridges had been identified as potential problem areas, a code was required to track data collected on bridges. Time: The GPS system time of the event being logged. MIN: Used when two MINs are being logged on the same log sheet. ‘Comments: This field is used to record any comments about events that occurred during the logging. Each of the sites (and sectors when appropriate) are listed in this section. Active set members are circled as handoffs occur. Location: The street and direction being traveled is entered at the beginning of each run, then all cross streets are recorded as they are crossed. When the vehicle turns, the street and the new direction is entered. This information is especially useful when trying to determine if a drop occurred in an area where there was no coverage, Last Modified: 04/22/99 09:26 AM Issue 0.8 July 10, 1998 Page 70CDMA RF Optimisation ___..64||.o.4||__=S_____—Technology Applications Group Test: ‘Dare: (YYMMDD) ‘VAN GREW: yui yn iM BN @ wviiwetlyn iy n iM DATA COLLECTION SOFTWARE: HANDSET SOFTWARE: { Loauas: ‘Sires NOT AVANLABLE: Pe BSS ME Nae | errr ne A Ye on ser on a0 a era er ee [stan auc eens nt = es 5.250 lee en se NO OP a HN a a CE oes Se se vets enon nin fp mmr meas Aenea ye enon er rare ecm manne escort 1A Uren Rewer Pr m3 9 9 08 1 nit cre sor on 20 2 a tm NY ts ve a a vs wen tre Rs Ne A 0.50 aa erase et rs it a eM RA Issue 0.8 July 10, 1998 Page 71ConmNUATION SHEET: __ sp on 0 25 0 RY a noose ws 28 9 or eo yar a e peso oak ava 7 es eg rn seme oe re one S86 er YS MP ee nn cc NO ak ts Hm ee ee i oT ss ron cv asso aorta MeN ee AN NS recone e028 ot TN 2 rs rem a Issue 0.8 July 10, 1998Dare: (YYMMDD) CONTINUATION SHEET: __ oF. Test: NUMBER OF DROPPPED GALLS FOR THIS RUN: NUMBER OF CALL ORIGINATION FOR THIS RUN: NUMBER OF ACCESS FAILURES FOR THIS RUN: | PROBLEM AREAS: (GIVE CROSS STREETS WHEN POSSIBLE) 1S FURTHER INVESTIGATION REQUIRED: YES NO Ir Yes, WHY? Issue 0.8 July 10, 1998 Page 739.2. Importing Files into Planet Since a survey loader specific to the data analysis tool output file formats does not yet exist, the following methoc allows survey data of various types to be displayed in Planet. Use scripts (such as those presented in chapter 6.1.) to obtain files of the form: Decimal Latitude, Decimal Longitude, Value to be displayed. ‘The separator between the 3 columns can be multiple spaces and/or tabs, File length is not limited by Planet but a maximum of $0 files can be loaded at any one time (true at release 2.5.12). The files should be place in the “results” directory. For every survey file, a corresponding header file needs to be created in the “head” directory (the contents are not critical for merely displaying data). Use a script such as the following to create the header files: #Ybin/esh, #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 1m ./head/*.hd foreach sfile (* ) echo Ssfile set headfile = $sfile" hd” echo Sheadfile cp /headshead_temp ./head/$headfile end Use the “Tools/Surveys” function to load the survey data and “Draw/Signal” to display it. Remember to adjust the cutoff limits (¢.g. when displaying Ec/lo, the default upper limit of -30 will have to be raised) and the contour settings to values appropriate to the data. 9.3. QCP Tech Mode Screen Handset Monitor Mode Found on the handset by choosing menu - 7 - 0, a display appears with two rows of three. values. Moving from left to right across the rows, the following items appear. Issue 0.8 July 10, 1998 Page 74CDMA RF Optimisation on Technology Applications Group First row PN Offset: in decimal Receive State: uses the following codes:_ 0: Pilot Channel Acquisition 1: Syne Channel Acquisition 2: Ide 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) or 66.25 (1900MHz). This final result is in dBm. Second row First value unsupported Second value unsupported Transmit Gain Adjust: in coded hex, can be translated by converting value to decimal and dividing by -2_ (aalue of 7F means the transmitter is inacti 9.4. Sample Rundesc.txt iS-cell *Bxpended Trial’ at sctel Ran descriptions for date: 960727 General Noves/syaten status: 26-colis on air n5/B8¢ S/W As 2.2 with the following revisions:integration tab version 6, selector controller 218A, selector 21, SCI 13, BIS controller 7 CSN éa, fe.Lip 9, ‘MIXOSAK Network survey after bringing up Haney. Run MIN S/W Cal Configuration Route/Loe Purpose of Run Nol 6580 1.61 3._—NPG/CKT/74b SUR General Network survey WoL 8598.61 M13. NPG/CKE/7db SUR General Network Survey Note 8580 perforned the long calls. 0598 performed the short calle 8500 dropped call 152nd x 3¢th. No? 8580 2.62 M13._—-NPO/CKT/74> SUR General Network Survey Noz 6598 1.61 MI3._—NEG/CKE/74b _SURR Genera Network Survey note! 8598 MOM locked up. 2 access failures for 8580 Issue 0.8 July 10, 1998 Page 751 4289,«1.61 13__NPG/CKT/7ab __COR/FOCO Gen Network Survey 0018569 «1.61 3_—NPG/CRT/74> —_COR/POCO Gen Network Survey Note 4289 drops on Westwood X LHED & Mariner X Hickey. 8568 MOM crashed, 902 4289 1.61 M13. NPG/cRT/7aD —_COQ/POCO Gen Network Survey 028568 1.62 M13. NPG/cRT/7a _cOg/POCO Gen Network Survey Note: 4209 problems on Cono Lake Rd: X Wasco & X Seymore & X Barker. Mariner X Woodward, 8568 power cycle->903.8586 034289 1.61 M3 MPG/CKIV7a> Lt Maw/pl Rag Network Survey 03424316123 NPG/CKT/7a> At Maw/Mpl Rag Network survey Not 4209 3 drops. 10 access failures. LHED x Indian Res, North on 287. Poor coverage for entire run, both phones. ol 8572 «1.61 13. MPG/CKT/7ab —BRN/AWEST Network Survey Bol 8574 1.61 13 NPG/CKT/7abBRN/WEST Network Survey Note 8572 power cycle 142 #t Xx 26 av->b116572.err 302 9572,«1.61 -M13._—NPG/CKT/74b_—BRN/AWEST Network Survey Boz 8574 1.61 -M13._—NPG/CKT/Tab © BRN/NWEST Network Survey 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: -74B -74B -10dB -11dB and we want to get the last one below T_ADD (-14dB). A simple reduction of 3dB will not achieve the required results since the Io will also reduce when this pilot is lowered. A quick way to find out the Io reduction is to assign weightings to the pilots, starting with Lor thie strongest: -11=04 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.644B. Issue 0.8 July 10, 1998 Page 76