I

II I

II

I II

I

~

~

I

CDMA ~ 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 ~II 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

I

I I

II

!

il

I

I

II

I

il

II

!

II

I

I

,

II

I

I

I

I

I

~

I

~ I

~

~

I

~

CDMA RF Optimisation

Technology Applications Group

1. About Issue 0.8

2. Introduction

2.1. CDMA Optimisation Overview 2.1.1. Pre-Commercial

2.1.2. Commercial

2.1.3. System Expansion

2.2. Related Documents

2.3. Scope of this Document 2.4. Revision History

2.4. Contributors

2.5. Audience

3. Optimisation Procedure

3.1. Entrance Criteria

3.2. Sequence of Events

3.2.1. Pre-Commercial 3.2.1.1. First Pass: Unloaded 3.2.1.2. Second Pass: Loaded 3.2.2. Commercial

3.3. Exit Criteria

4. Initial System Parameters

4.1. Datafill Example 13

4.2. Types of Parameters 13

4.2.1. IS-95/J-S1'O-008 vs. Nortel Specific 13

4.2.2. Global/Sector Specific/BSC/BTS 13

4.2.3. Setting Parameters 15

4.2. PN Planning 15

4.2.1. "Co-PN" 15

4.2.2. "Adjacent PN' 16

4.3. Initial Neighbour List Generation 16

4.4. BTS Calibration 17

4.5. Search Windows 18

4.5.1. SRCH_ WIN_A, AccessChannelDemodulationSearch Width, TrafficChannelDemodulationSearch Width 19

4.5.2. SRCH_ WIN_N, SRCH_ WIN_R 20

4.5.3. AccessChannelAcquisitionSearch Width, TrafficChannelAcquisitionSearch Width 20

4.6. Neighbor Configuration File, Setneighbor and Checkneighbor 20

5. Data Collection

5.1. Tools

5.1.1. Mobile Data Collection 5.1.2. Test Van RF Configuration

Issue 0.8 July 10, 1998

Page 2

6

7

7 7 7 7

8 8 8 9 9

10

10 10 10 10 11 12

I2

13

23

23 23 23

i I

~

CDMA RF Optimisation

Technology Applications Group

5.1.3. The Base Station Manager (BSM) 5.2. Simulating Loading

5.2.1. ForwardLink

5.2.2. Reverse Link

5.3. Data Required

5.3.1. Selector Log Mask 5.3.2. Mobile Log Mask

5.4. Drive Testing

5.4.1. Shakedown

5.4.2. Drive Routes

5.4.2.1 Drive Route Selection 5.4.2.2. Benchmark Route

5.4.2.3. Driving with only one cluster of cells on air 5.4.3. Test Calls

5.4.4. Logging

5.4.4.1. Data Collection Restrictions 5.4.4.2. LoggingStrategy

5.5. Data Management

5.5.1 Data Transfer and Tracking

6. Data Analysis Procedures

6.1. Tools

6.2. Datafill Audit and Shakedown 6.2.1. DatUlII}\u(tit

6.2.2. Shakedown Data Analysis

6.3. System Access

6.3.1. Access Failure Analysis 6.3.2. Access Success Rate 6.3.3. Access Parameter Tuning

6.4. Dropped Calls

6.4.1. Link Supervision 6.4.1.1 Mobile 6.4.1.2 SBS

6.4.2. Analysis

6.4.3. Dropped Call Rate

6.5. RF Coverage/Handolf Control 6.6. Search Windows

6.6.1. SRCH_ WIN_j\

6.6.2. SRCH_ WIN_N

6.6.3. SRCH_ WIN_R

6.6.4. BTS }\ccessChannelDemodulationSearchWidth, TrafficChannelDemodulationSearchWidth

6.7. Neighbour Lists

6.8. Performance/Trend Analysis 6.9. Per-Site Analysis

6.10. Capacity

6.10.1. Capacity Equations 6.10.1.1. Reverse Link

Issue 0.8

July 10, 1998

Page 3

24 24 24 25

26 26 28

29 29 29 29 30 30 30 30 30 31

32 32

33

33 33 33 33

33 33 34 34

34 34 34 35 35 36

36 39 40 42 42 42

43 45 46 48 48 48

· I

II

I

I I

'.11.

I I

i

I

I

II

I

~

CDMA RF Optimisation

Technology Applications Group

6.10.1.2. Forward Link

6.10.1.2.1. From Drive Test Data 6.10.1.2.2. From BTSPerformanceData 6.10.1.2.3. Interpreting the Equations

6.10.2. BTS Operation 6.10.2.1. BTS Calibration

6.10.2.2. The Digital Domain, Forward Power Control and the Forward Blocking Thresholds 6.10.2.3. The Analogue Domain, Power Sensor and Power Limiting

6.10.3. Optimising for Forward Link Capacity

6.11. Power Control

6.12. Hard Handoff

6.12.1. Round Trip Delay (RID) Calculations

6.13. Other

7. Dropped Call and Access Fallure Reasons and Solutions

7.1. Successful Call

7.1.1 Symptoms in Mobile Data

7.1.2 Analysis with Selector Logs

7.2. Access Fail and Dropped Call Reasons in Single Frequency System 7.3. Hard Handolf

7.4. External Interference (Fix this section)

7.3.1 Symptoms in Mobile Data

7.3.2 Analysis with Selector Logs

7.3.3. Further Analysis

7.3.4 Corrective Action

7.7. Site Not In Service

7.7.1 Symptoms in Mobile Data

7.7.2 Analysis with Selector Logs

7.7.3. Further Analysis

7.7.4 Corrective Action

7.8. Interference From Non Co-located AMPS Cellsite

7.8.1 Symptoms in Mobile Data

7.8.2 Analysis with Selector Logs

7.8.3. Further Analysis

7.8.4 Corrective Action

7.11. Handoff Boundary Balance

7.11.1 Symptoms in Mobile Data 7.11.2 Analysis with Selector Logs 7.11.3. Further Analysis

7.11.4 Corrective Action

7.12. Interference from Microwave Link (1900)

7.12.1 Symptoms in Mobile Data

7.12.2 Analysis with Selector Logs

7.12.3. Further Analysis

7.12.4 Corrective Action

7.13. Interference From Foregin System Mobiles into CDMA BTS

7.13.1 Symptoms in Mobile Data

7.13.2 Analysis with Selector Logs

Issue 0.8

July 10, 1998

Page 4

49 49 51 51 52 52 53 54 55

56 57 57

57

58

58 58 59

62 64 64 64 65 65 65

65 65 65 65 65

66 66 66 66 66

66 66 66 66 66

66 66 67 67 67

67 67 67

I

I

CDMA RF Optimisation

Technology Applications Group

7.13.3. Further Analysis 7.13.4 Corrective Action

7.14. AMPS AlB Band Coordination

7.14.1 Symptoms In Mobile Data

8. Other Optimisation Procedures and Special Cases

8.1. Adding New Sites 8.2. Other Special Cases

9. Appendices

9.1. Sample Mobile Data Log Sheets 9.2. Importing Files into Planet

9.3. QCP Tech Mode Screen

9.4. Sample Rundesc.txt

9.5. Calculating Required Power Reduction/or Unwanted PN

Issue 0.8

July 10, 1998

PageS

67 67

67 67

68

68 68

69

69 74 74 75 76

I I I

CDMA RF Optimisation

Technology Applications Group

1. About Issue 0.8

To be added to future issues:

• hard handoff (both "normal" and fl/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 NLT A 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

I I I

II

I

'I

I

CDMA RF Optimisation

Technology Applications Group

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:

• System/cluster shakedown/de-buggingldatafill audit

• RF coverage/handoff control

• Neighbour lists

• Dropped call rate

• Access success rate

• Search window settings

• Hard handoff success rate

A simulated load will likely be applied to the system/cluster for some stages of the optimisation.

2.1.2. Commercial

Efforts will concentrate on:

• RF coverage/handoff control

• Dropped call rate

• Access success rate

• Hard handoff success rate

• Capacity

2.1.3. System Expansion

Efforts will concentrate on:

• Introduction of new sites

• RF coverage/handoff control

• Capacity

• Dropped call rate

• Access success rate

• Hard handoff success rate

Issue 0.8

July 10, 1998

Page 7.

I

~

il

I.

I ~

I

-

I

I

I

I

CDMA RF Optimisation

Technology Applications Group

2.2. Related Documents

CDMA RF System Parameter Guideline for 800 and 1900 MHz, Prasanna SatarasinghelBrian troup, (Nortel) I

RF Datafill Spreadsheets I IS95A+ TSB74 (800MHZ)1 J-STD-008 (1900MHz)1

(above two documents to be combined in IS95B) I NOIS 2

PN Offset Planning Guide, Chu Rui Chang/Jane Wan, (Nortel)

Grayson Surveyor Installation and Operation, Lynne Patterson (Nortel) I Nortel RF Optimizer Manual I

Hard Handoff Deployment Tips, Datafill Verification, and Troubleshooting. David Boettger (Nortel) 4 Neighbour List Tuning Using the NeighborListTuningArray, Martin Kendall (Nortel) I

SBS Diagnostic Logging in Commercial Networks, Martin Kendall (Nortel) I

(BTS PeformanceData)

The numbers indicate the locations at which Nortel employees may find the latest soft copies of these documents:

1. huo:1147.143. 131 .92/groY0a(lechaopsJ (this document can also be found on this server)

2. ftp to 47.65.105.47, id: anonymous, dir: dist/80.docs

3. http://47.164.163.96:4000/root/bnr/mtxlwwwlhomepages/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

I II

I I

I

I I

~

I

CDMA RF ODtimisllion

TechnolotlV ADDUcations GroUD

0.3 96Nov18 Minor editorial (no content change)
0.4 97April24 Remove tool dependencies. Many updates based on field experience.
0.5 97Apri131 Correct minor mistakes
0.6 97Jul14 Major updates on overall strategy.
0.7 97Jul22 Capacity optimisation, initial search windows, many revisions
0.8 98June26 SRCH_ WIN_AIN rules, some cleanup 2.4. Contributors

The following are the key contributors to the processes contained in this document and/or to the document itself:

Remo Agostino

Bill Book

David Curtis

Rod Djurkovic

Joe Heikes

Chris Jedrzycki Martin Kendall Robert Keppeler Paul Kibukamusoke Corey Krieger Mike Maragoudakis Andrew Morrison Lynne Patterson Mark Prasse

Prasanna Satarasinghe

2.S. 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

I I I I I I I I

CDMA RF Optimisation

Technology Applications Group

3. Optimisation Procedure

3.1. Entrance Criteria

The following items represent the minimum entrance criteria for an optimisation exercise:

• All BTSs should have been correctly instailled and calibrated. The calibration values should be entered in the datafill.

• The spectrum should be clear down to a level of -11OdBm(800MHz) or -111dBm (1900MHz) (total power per 1.25MHz) at all locations in the service area.

• The network should be stable i.e. all required sectors are on the air, able to originate calls and make handoffs into and out of the sector.

• BSC support: Personnel should be available to carry out selector logging, parameter changes, enabling/disabling OCNS, wiltinglblosso..mmg<?!~~Jors.

• An up to date site database should be availlable in the prediction tool (e.g. Planet).

• All test vehicles/tools/maps etc. should be available. Data collection tools installed, GPS installed/calibrated.

• A PN plan should have been created and entered in datafill.

" ..... _- ----"'-,---",_ -, - ~ ... - -~-.-~< ,," - .. , .. ~"'.""'-~"

• Preliminary neighbour lists should have been created and entered in datafill.

• The optimisation exit criteria should have been defined.

3.2. Sequence of Events

3.2.1. Pre-Commercial

The following is a basic list of items that should be addressed during an optimisation exercise on a pre\ commercial system. Details for analysis methods will be found in later sections of the document.

3.2.1.1. First Pass: Unloaded

1. Perform datafill audit and shakedown

2. Simulated load is NOT applied at this stage (since we want to expose "stray" sectors)

3. Perform a full network/cluster drive while running 2 minute Markov calls and collecting mobile and

selector logs

4. Optimise SRCH_ WIN_A and BTS demodulation windows based on rake finger offset analysis.

5. 6.

Optimise SRCH_ WIN_NIR based on offsets in Pilot Strength Measurement Messages

"'-~-"""'"'··~·'''.,''''''''~_.,..,. .. ''''''.<.·"~,., ... ~.,_,~'''''''v'''., ...... "'' •• _''''''''t;.",",~'~'''''l'_''~

Perform th. e. RF. .. c.ov.e .... r .. a ..•.... ~~~alI~i~ (p~?~.:~~{~!~~!bJhs~c\g~), m~~~, mQQ!J~.BX, best,,!,!~.~~r E.ciIo, peI:PNp19~ l:!sne.ce.sS'azy (Dest finger/any fingerlPSMM occurrence))

Issue 0.8

July 10, 1998

Page 10

I

I I I I I I

I

CDMA RF Optimisation Technology Applications Group

7. Perform dropped call analysis. Plot locations in the data analysis tool.

8. Perform failed ac~~ss atlalysjs. Plotlocati_<l!nsjnJh~.g~t~_M~ool.

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 ~~~~;"'~;:;~y~r~~~)o pinpoint site problems

11. Create baseline data for the performance/trend anaJ~sjs ?

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 I~Q,$Jage. Otherwise, perform a full network/cluster drive while running 2 minute Markov calls and c.<:)!!~,~tiI!~ m?b~(t~!~!£r lo,&s

----------,.."'~~,,-,-._..,.~""""" ... """',. .. ''''' .. ''''

15. Re-generate the RF coverage analysis plots (plot: handoff state (by sectors), mobile TX, mobile RX, best finger Ecllo, per-PN plots as necessary (best finger/any fingerlPSMM occurrence»

16. Perform dropped call analysis. Plot locations on the~()y.erage analysis plots.

"" .. -" .. -- .. -."- .. ,-~,.,.,~.",".,,,,.'''''-'''''.-''''.~,, .. ,', _, ... ,.,_,_ .. "

17. Perform failed ~£~s§>analy.sis_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 s!~!~ (b_y: secto~l,-mobile...TX...mobile RX, best finger Ecllo, per-PN plots as necessary(best finger/any fingerlPSMM 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

I

I I II

I I

CDMA RF Optimisation

Technology Applications Group

In addition, many special cases will be encountered during optimisation. Procedures for some these will be added to this document in due course. However, there will always be specific issues that can only be solved through a thorough knowledge of the product, IS-95IJ-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 BTSPerformancelJ)ata as trend analysis data to pinpoint problem areas.

• Enable unconditional SBS logging of RT1.1 ~~~rListTll!!!n~ay and VitalData (see section 6 for analysis methods).

• Use unconditional SBS and BTS Diagnostic logging

• If particular MINs are suspect, enable a fun SBS optimisation conditionalJQgl!!~~~fQI~es.

'""~"'",-.' "'''~,...--'''-~, "~""""'->"-"""""""''"'.''"''.

• Use drive testing as a "last resort" means of characterising a problem area.

• Use drive testing to complete the integration of new sites.

3.3. Exit Criteria

Some possible exit criteria for an optimisation exercise are:

• Achieving a target dropped call rate.

• Achieving a target access success rate.

• Achieving coverage over a specified geographical area.

• Achieving a target capacity.

Issue 0.8

July 10, 1998

Page 12

I I

CDMA RF Optimisation

Technology AppHcations Group

4. Initial System Parameters

I 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.

II I I

I

I

I

4.2. Types of Parameters

4.2.1. IS·95/J·STD·OO8 vs. Nortel Specific

It is worth noting that some paramete!§~~_9~fi.!l~g_bYJh~_standards",5m.(;.tk.@~J()1l11d in I~:2~.Q! I:~:rP- 008 while others are NoriefspecHfcand can be found in the NMIS documents.

All RF related datafiJ] llanm,WfS 8ft exp)aipQd W !be CDMA RFS~:;tem Paratpeter Guideline for 800 ;nd 1900»l!3r- . iii. a.

4.2.2. Global/Sector SpecifidBSC/DTS

The distinction between these definitions is important and not necessarily obvious: • Global parameters apply to the whole system (one BSCIMTX)

andoff with two sec

ific rules fo

1. 2. 3. 4.

For T_AQP, T_DROP the SBS will send the lowest (most negative, e.g. Ci2:and -13 will

result ~,_. --_ , ' , "

For T_TDROP, the SBS will send th~maximum val .

For T_COMP, the SBS will send the inimum v;}~

5. 6.

See below for current limitations on per-sector paramet~rs:'-'---"'Some values are repeated at the BTS and BSC:

• V e

have'the setti~~ih_. at~!_~~c~~~~ fr~m .!!te~ast s~@~~~~!!! .. Et

,it~m

Issue 0.8

Page 13

July 10, 1998

I I I I I I I I I

CDMA RF Optimisation Techn<;»lolY Applications Group

• Values at the BSC apply to the traffic channel. SRCH_WIN_A, T ADD, T_DROP, T_TDROP and T _ COMP will all be sent on the en e Handoff Directi according to the above rules if the SBS detects that the"molil1e-doe orlfavellie cU!'f~1.Yiliii(i.e. every time a handQ.ff_Q.~C]JIs..Jhe SBS wor~~?':l!!1te 1!ew v~ues-accorgingiQ]i~~y.~~~w.lIAt

it last sent to the mobile, it sets the "Sear " and sends the new values QIlJrutExtended

Hanct6ffI5[rectioa-Message). Unfortunate y, until the"fiirrafflc'-SystemParanlet~r~- Message" is implemented, it is not possible to update the mobile's settings for SRCH_WIN_NLR.during,,,acall. Therefore, while these may be set per sector at the BSC, the mobile will currently only use the values

/' it gets from the pagm. . g channel. For exam le . . ~

} RC WIN~·~~bs~u~e~ntl~·~~~~~~~Wi~~~~~~~~~~

I. not u te Its sear wi do ti

\ agam.

~ ~ .--

F.~~~!~.~~~~t!rf.:t!~;:~:uthere

._' . .__,,~ .... ~,_~ .. .. .,_~_i1"'~ ·' __ ' __ w_,·_,""",·_··w· __ "_'_, __ .. '"-,' ... _- ,._ .. ,- ", -"'--'.-" _" .. "' .......

1. Use a script to update T_ADD on the required sectors at.the SBS only (all shelv~).

.. "" -.' '.'.- .. >."'.~."' ~ "'\." ~ --

2. Assess the change (e.g. by driye testing). Note that, sinceJ.!t~~~_!!Q~!J?~~n ~.h.cmg~d..1jhe first handoff in evc;,ry callvvilll1s~.!b.~cQld .. settingsJ~ute'Ye:rxl$.\!~~~Jla.ndo:~~·." se!!!~ftrunihe'SBS. ~i!:~mil!?~~~~~~.\V~e:1!.th~~~fLQfin3!Q!1A!he.~h~eJj§ .. .£9nsiderkd.

3. Try q.e:~.s..~ttingS at the_SBS,J!S..required. • """";::';'_"c", .. =:»

4. When the:. desir~4,s.ttt.j:Q_g_~!t~~!l~,~~t~Q~iSI!~C~Q,~!1IR~~~~J!I§t.~ith the new values,

-.. . '~~'; " ... ' . ,_ .,'"".,~,._,,:,;::, ;._,;-, ,:, :.' •. ,; ;"/::>,,;_-,",,,,'0 '"~;i;"", ~."

In NBSS7.0, the search windows and handoff parameters become settableat the BTS (see RF Parameter

Guide). '-, - '-----.-.- ... -

pom 0, mo e WI

following pnon es:

::::::::: ,....

1. ~~t1y been dropped from the active list but haye noty~<!.

2. The neighbour list as received on t!t~.!llOst recenl NeighQ9J.U: .. List!l~agei[Qm th~MC (although any pilots fr<?_l!1~1. above will not be repeated).

--=-- '-._"-,-- ~-,--

Note that, even if the Neighbour List Update Message contains 2Q~ the 1!lQQ!!C?wil1,g!~_p.riQ{ity to pilots defined in 1. above so all 20 might not be used. These rules are d~fj~gjnJl:u~JS2S standard.

""."~,,,-,-,~--,.,,.,.,,,,,~ ......... ".~

f e

1.

2. Remaining pilots are then ranked by strength as reported in the PSMM.

Issue 0.8

July 10, 1998

Page 14

CDMA RF Optimisation Technology ADPHcations Group

3. The neighbour list of the strongest pilot in this list is then included (although any pilots from 1. above will not be repeated).

4. The neighbour list of the next strongest pilot in the list( although any pilots from 1. or 2. above will

not be repeated).

5. . .. and so on until all the pilots have been used or the list has the maximum of 20 entries. These rules are Nortel proprietary.

For a neighbour list entry to be considered the same, both the PN and the extended baseid have to be the same. Therefore, it is perfectly possible to have repeated PNs as long as the baseid is different. As the neighbour list for each PSMM entry is being added, the order in which the neighbours are datafilled in the Pilot Database is preserved.

Processing a PSMM:

Each PN with a keep flag of 1 will be matched to a baseid by looking it up in the following order:

1. current active set

2. maintained neighbour set (i.e. limited to 20) in order it was built.

3. untruncated neighbor set (will be created "on the fly" using the NL build rules above but net stopping at 20)

The first PN match will halt the lookup.

4.2.3. Setting Parameters

All SBS parameters can be. changed quickly using "edit" commands (which may be scripted). Some BTS parameter changes may be made "online" from the BSM while others require a download (see RF Parameter Guide and RF datafill Spreadsheets).

4.2. PN Planning

The entrance criteria to RF optimisation include the req':l!!_~!!l~!l! that ~N plan !!~ already mc~n established. The!~fQ~-La_fulLfle~~!!ption of how to set to set up a PNJ~!~.f()r a system is.Q.'!tsic:!~Jhe

scope of th!~_4gc~nt. ----~.-""------ -~-,,- .

The symptoms in the diagn()~tic data will beexpl~Il~d in. al~t~!se£ti.gp.. However, .the JQUQwing illustrates the p(js~iI)1!f~es~~~.~r'i~~~~~~~C·· '" ...."'.

4.2.1. "Co·PN"

where R is average cell radius in region of interest and SRGIi .... WIN_A is expressed!!1_ships.

Issue 0.8

July 10, 1998

Page 15

I I I I

II

~

II

!

I

I

~

I

~

~

CDMA RF Optimisation Technology Applications Group

Another possibility for "Co-PN" interference is if PN1 is in the mobile's neighbour list but some energy from a distant re-use of PN1 falls inside the neighbour search window. The "correct" local PN1 will be put in the active list. If the "false" PN1 subsequently becomes one of the 3 strongest multipaths, the mobile will center an active search window on it and try to demodulate it resulting in forward link interference.

A third "Co-PN" possibility is if "false" PN energy arrives at the mobile that matches an active set PN that is not currently being demodulated. If the "false" PN subsequently becomes one of the 3 strongest multipaths, the mobile. will center an active search window on it and try to demodulate it resulting in forward link interference.

A fourth "Co-PN" possibility is if "false" PN energy arrives at the mobile that matches an active set PN that is currently being demodulated. This will only cause interference if the "false" PN energy falls inside the active window for that PN.

4.2.2. "Adjacent PN"

The adjacent PN is the next earliest PN in the sequence i.e. PN-PILOT_INC.

Problems first occur with cellsite spacin s in

uter r IUS = «P OT_INC x 64)/(3.3 x 1.2288»1t.«SRCH_ WIN_N)/(2 x 3.3 x 1.2288» + 2R lOner radius = «PILOT_INC x 64)/(3.3 x 1.2288» - «SRCH_WIN_N)/(2 x 3.3 x 1.2288» distances (in km).

If any distant pilot is interpreted as one of the pilots in the mobile's neighbour list, the local site will be added to the active list, even if not required. However, this will not cause demodulation problems unless the "false" PN becomes one the strongest three multipaths and a rake finger is assigned to it (note that, unless the mobile has already assigned a finger to that PN from the (correct) local PN, it will center it's active window on the "false" PN. Therefore, tJhe 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_lNC 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

I

I

I

CDMA RF Optimisation

Technology Applications Group

Alternatively, the initial neighbour lists for a mew system or portion of a system can be generated as follows:

1. In the prediction tool, generate a best server Ecllo 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 tCl> the neighbour list 'just in case". The objective is to keep the neighbour lists to the minimum length and hence reduce search times (see section 6.7. on neighbour list data analysis)

4.4. BTS Calibration

Some of the datafill values are outputs from the BTS calibration process (e.g. TXAttenNormal, BTS to RFFE cable losses). Ensure that these are present in the datafill before optimisation commences.

Issue 0.8

July 10, 1998

Page 17

CDMA RF Optimisation

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) DatafIll Value Max Delay (uS) Distance (km)
14 (±7) 4 5.7 1.71
20 (±10) 5 8.1 2.44
28 (±14) 6 11.4 3.42
40 (±20) 7 16.3 4.88
60 (±30) 8 24.4 7.32
80 (±40) 9 32.6 9.76
100 (±50) a 40.7 12.20
130 (±65) b 52.9 15.86
160 (±80) c· 65.1 19.52
226 (±113) d 92.0 27.57 Issue 0.8

July 10, 1998

Page 18

I I I I I I I I I

CDMA RF OptimisIUon

Technology Applications Group

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:

Neighbour Search Window (SRCH_ WIN_N) (chips)

20 28 40 60 80 100 130 160 226

Active/Candidate Search Window (SRCH_ WIN_A) (chips)

20

40

10

14

28

60

4.5.1. SRCH_ WIN;_,:A1 AccessChannelDemodulationSearch Width,

TrafficChannelDemoduiationSearch Width

35 * loglO(DIR) = 10 or DIR = 1.93

The extra distance the signal must travel is therefore 0.93R.

Therefore, the system can be divided into two or three groups of similar cell sizes and a representative cell radius chosen for each group. For examp1le, for R = 2km, the multipaths must travel 1.86km extra and since 1 chip represents 0.244km, the "half-width" of the window should be 1.86/0.244 = 7.6 chips and hence the full window width should be at least 15.2 chips.

Issue 0.8

Page 19

July 10, 1998

CDMA RF Optimisation

Technology Applications Group

The setting for SRCH_ WIN_A can be obtained from the table above. The next highest setting above the one calculated is 20 chips.

The BTS demodulation windows are set in l/Sth chip units i.e 15.2 * 8 = 121.6. However, the smallest increment that the CSM searches is 125 1I8th chip units so the settings should always be multiples of 125 i.e. 125 (for this example), 250,375, 500, 625 etc.

4.5.2. SRCH_ WIN_N, SRCH_ WIN_R

Since SRCH_ WIN_Nhas to allow for the difference in arrival time from djfferent "6rSs, the settin~ for a

iven sector can be established b measurin the distance to the most distant cell in the nei bour list.

E.g. or a ce to ce stance of 8km, the "h f-window" is 8/0.244 = 32.8 chips, the full window would

be 65.6 chips so the next highest setting of 80 chips would be required.

Remember, though that SRCH_WIN_N cannot be updated during a call so allowance should be made for mobiles establishing a call with a particular setting and then moving to an area of larger cell spacings (i.e. if in doubt, use a higher setting on smaller cells that are adjacent to an area of larger cells).

The remaining set search is used to find stray pilots and missing neighbours so a good setting for SRCH_ WIN_R is to use the next setting above the SRCH_ WIN_N.

4.5.3. AccessChanneiAcquisitionSearch Width, TraftlcChanneiAcquisitionSearch Width

The AccessChannelAcquisitionSearchWidth ets th ~hich an ori mation can b

rom a sector. e only window that is not "cen ere ut it, in a similar manner to the Round

np e ay c cu ations, it does need to allow for the "out plus retum"time. E.g. if access attempts are expected up to a 15km radius, the pilot channel takes 1510.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 ~~ chip units (likely rounded up to 1000).

--" .... "'~

4.6. Neighbor Configuration File, Setneigh~f.)J:'. anc:lCheckneiabbor

RF datafill that needs to be consistent between SBS shelves or between SBS andBTS 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 datafillcan 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 KEYI having a config value of 1 and priority of 2:

KEYl,1,2,KEY2,3,4

Issue 0.8

July 10, 1998

Page 20

CDMA RF Optimisllion

Technology Applications Group

The BTS neighbor list will use the NEIGHBORS column if either this column is not present or this list is empty for this entry. This field is optional.

BORDERT ARGET: 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

EHHOT ARGETCELL: Comma list of target cells for EHHO. CELL TYPE: Enumeration Standard, Pilot_Beacon, EHHO, and Border.

QUICKREPEAT: True or False for quick repeat.

FORWARDGAIN: Numeric value describing the forward gain.

BorderRetPilotRTDTbresh: RTD delay to trigger border handoff.

EHHOFERMAXFWD: Trigger for EHHO.

J

EHHOFERMAXRVS: Trigger for EHHO.

EHHOFERMODFWD: Trigger for EHHO. EHHOFERMODRVS: Trigger for EHHO. EHHOTCGMAX: Trigger for EHHO. EHHOEBNOMAX: Trigger for EHHO. EHHOWINDOWSIZE: Size of EHHO Window.

CAP ACITYTH~SHOLD: Numeric value for capacity threshold. FREQUENCYPRIORITY: Numeric value for frequency priority. T_ADD: Numeric value for adding pilots.

T_DROP: Numeric value for dropping pilots.

T_TDROP: Numeric value for drop timer value.

T_COMP: Numeric value for comparing pilots. T_ADD_OFFSET_A: Numeric value of add offset. T_ADD_OFFSET_B: Numeric value of add offset.

T_DROP _OFFSET_A: Numeric value of drop offset.

T_DROP _OFFSET_B: Numeric value of drop offset.

T_TDROP _OFFSET_B: Numeric value of tdrop offset.

DELTA_3: Numeric value .!or_ d~{f~r~!lce betw~~nCf~ andctili!cl~~."

~::~~=:: :~: :::::::::.::: ::~~~: ~~.

DELTA_6: Numeric value for difference betwee~stronges~and the Si;hPilOt.)

,,_ -_/

Issue 0.8

July 10, 1998

Page 21

I I I I

'I I

I I I.

I

CDMA RF Optimisation

Technology Applications Group

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

I

I

I I

I

I I I

I I

I

I

I

CDMA RF Optimisation

Technology AppllcationsGroup

s. Data Collegtion

5.1. Tools

5.1.1. Mobile Data Collection

Each test van should be equipped with equipment to collect data from the test mobile(s), a compatible GPS receiver.

5.1.2. Test Van RF Configuration

Phones may simply be placed inside the vehicle or, for more repeatable results, an external antenna-may be used. If external antennas are to be used, the most convenient way to configure the RF connections in the test van is to use either a car kit or a direct connection to the phone along with the external antenna. In order to produce "in-car" signal levels with an external antenna, attenuation must be added to the antenna connection in order to achieve the customer-specified vehicle or building penetration loss.

The following table is an example of the budget that should be calculated to correctly determine the attenuator required:

Losses/Gains (dB) Test Van "Real" Car
Antenna Gain +3.0 0
Cable and connectors - 3.0 0
Car Kit Loss . -6.0 0
Test Van Antenna Height +3.0 0
Attenuator -7.0 0
--
Penetration Loss 0 10
Total -10.0 -10
Difference OdB Ideally, the received power reading and-transmit power indication of the phones used in the test vans should be calibrated. The HP8924 COMA 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

I

I I I

I I I

I I

CDMA RF OptimiaUon

Technology AppHcationsGroup

5.1.3. The Base Station Manager ~SM)

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. Bello may be less than T _ADD when loading is applied. For this reason, at least one pass through the network without loading is preferred. The following methods will allow a simulatedloading to be applied approximates an even distribution of real users.

5.2.1. Forward Link

Forward link loading is achieved through OCNS (Orthogonal Channel Noise Source). The standard datafill reserves 2 channel elements per sector for OCNS. A gain setting of 120 allows 9 users per CE (18 total). Assuming the channel elements have been reserved, a script can be used to turn on OCNS very quickly" (if not, a full BTS download is required). The script defines the following:

." Number of simulated users required.

• Traffic channel gain per user (this should be the gain for full rate frames - do not try and account for voice activity in this number, the OCNS algorithm will do this automatically if the OCNS gain mode has been set to "Variable"). Gains of 90 to 125 are commonly used.

A sample calculation for OCNS is as follows:

For a particular capacity test using 1900MHz equipment, when 13 users were achieved, the average digital gain was 106 with a soft handoff overhead of 2.4 sectors per user. However, even if we want to simulate full load, this.is definitely not how OCNS should be set up since this completely fills the HP A 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 onaverage, there will be 6.6 users per sector throughout the system and this is what we should multiply by the soft handoff overhead and set with OCNS (i.e. the average number of "links" or "connections" to a sector is 6.6 x 2.4 = 16). Finally, allowance should be made for the 2 phones in the drive test vehicle and since it will add 2 "links" to the sectors in the drive test area, the final calculation would be:

Number of OCNS users = (6.6 x 2.4) - 2 -= 14 users at a gain of 106

For a sector that is running at 1% blocking, the total output power (including overhead channels) should be approximately 65% of the total HPA power. We can therefore check the above settings generate the correct power as follows:

Assuming a calibration of 254 = 4 Watts and standard overhead channel gains of pilot = 186, sync = 60, paging = 156 and PRAT=O, the power in the overhead channels is:

(186/254ix4 + (60/254)2X4 + (156/254)2X4 = 3.88W

Issue 0.8

July 10, 1998

Page 24

I

I

I I

I

I

CDMA RF Optimisation Technology Applications Group

When using "variable" mode, the OeNS 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 OeNS power is:

(106/254i x 4 x 0.45 x 14 = 4.39W

Since the full HPA power is 12.5W, the percentage is (3.88 + 4.39) x 100/12.5 = 66%. The corresponding numbers for 800MHz equipment would be:

OeNS gain = 123, oeNS users.e 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 OeNS users.

5.2.2. Reverse Link

A reverse link load can be crudely simulated by degrading the reverse link according to the following equation:

Degradation (dB) = 10glO(1 -Ioad)

where load is the fraction of pole capacity that the system is carrying (e.g. for 50% load, the required attenuation is 3dB total). Remember to allow for the load that the test phones will generate i.e. the actual attenuation applied would be less than 3dB.

Reverse link loading can be achieved by one of four methods:

1. Attenuate at the mobile (TX path only - requires that uplink and downi;i~ are separated using duplexers). This is the Nortel preferred method and shielded boxes with~nuators 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

I I

i I

I I I I !I

I

I

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
VoiceIMarkov Optimisation Detailed Network
calls Debugging
LogSBSNOISMessages Both Yes Yes Internal NOIS messaging
LogSBSIS95Messages 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 1 Rvs FER every 10 seconds
LogSBSPowerControl Both Yes Yes EwlNo 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 ESNIIMSI 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

Issue 0.8

July 10, 1998

Page 27

I I I I I

CDMA RF Ootimisllion

Technolo2v Aoolications Grouo

LogSBSRound Both Yes Yes RTD from each sector -
TripDelay logged every 10 sees
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 Em for every frame -
rasureIndicatorBit logged every 16 sees
LogSBSVitalData Both Yes Yes Error strings (very useful) I I

CDMA RF Optimisation

Technoloev 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:

1=log Field Description
O=nolog
0 Not used
0 AGC Val and Closed Loop Pwr Power control data for CD3000
Ctrl
0 Not used
0 Rev Link Frame Rates and Types Reverse link data transmitted.
I Access Channel Msgs All access channel messages sent.
I Rev Link Traffic ChnlMsgs All rvs Traffic Channel messages sent.
I Sync Channel Msg Entry All Sync Channel messages sent.
I Paging Channel.Msg Entry All Paging Channel messages reed.
I 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.
I Temporal Analyzer Finger Searcher finger offset and power.
0 Obsolete T A Searcher Data Searcher. data (not used).
0 ETAK Position and Speed Lat, long and speed from ETAK.
I Markov Frame Rate Data Markov rate and error data.
0 TA Searcher Data Searcher data (window size and
position, pilot offset, signal energy
measured, ete.).
0 Not used
0 Vocoder Err Mask Vocoder rate/data with bit errors
detected.
1 FMData Analog mode data.
I Access Probe Data Access probe information (seq number,
probe number, RX AGC, TXGA, etc.) Issue 0.8

July 10, 1998

Page 28

CDMA RF Optimis.ion
1 GPS Info
0 Not used
1 Sparse AGC
0 Not used AGC and Closed Loop Power Control for QCP80011900

Technology Applications Group

Latitude, longitude, speed, heading, time from the GPS receiver.

5.4. Drive Testing

5.4.1. Shakedown

Drive to each cell in the system and perform the following:

Phone 1: Keep Markov call up (or start as the site is approached if it's the first site you're testing)

1. as site approached, confirm handoff into site

2. if sectored, drive a complete circuit around the site and confirm handoff to all sectors

3. check that that the TX gain adjust is approx -10 to -20 when close to each sector

4. as you leave the site, confirm radius (RX power is "sensible").

Phone 2: On each sector, power down the phone, power up again, confirm a call can be originated and then release that call. Since the log is active (see below), this wUI capture sync, paging, call origination and tear down (make sure some idle time is captured on all sectors of a sectored site).

Mobile Logging: As you leave one site and head for another, stop the van somewhere in the soft handoff region and save the logs for both. Start new logs for both phones and continue to next site (i.e, For each phone, there will be one log per site).

See section 6.2.2. for shakedown data analysis.

5.4.2. 5.4.2.1

Drive Routes

Drive Route Selection

Using the coverage area predicted by the design tools, drive routes should be established throughout the area with emphasis placed on main streets and highways where customer traffic is expected to be high. The coverage area can be divided into regions and for each region the drive routes specified and written down. Each time a route is driven, it should be driven in exactly the same direction, from the same start point to the same end point. Each route should be given a name or number which was recorded on the mobile log sheet when the route is driven and the written log is included in the log book for easy reference during data analysis. During the drives, deviations from the routes such as detours and street closures should be noted on the log sheets by the drivers.

Issue 0.8

July 10, 1998

Page 29

I

I

I

II I

~

CDMA RF Optimisation

Technology Applications Group

5.4.2.2. Benchmark Route

A Benchmark Route can be a useful means of assessing network performance and consistency without the need for a full network drive. It should take the form of a single loop that is selected to stay well within the coverage area and to pass through the various clutter types available in the network.

The Benchmark Route should take about one to two hours to drive under normal driving conditions. It should be driven each time a change is made to the network. The data from the Benchmark Route can be compiled and analysed to look for trends in network performance.

5.4.2.3. Drivinl with only one cluster of cells on air

Should be used with care - need all the neighbours of the cells you are driving to be active and probably at least one more tier of cells beyond that - even then will miss some interference problems.

If data has been collected on a small cluster, the following analysis can be performed:

• Datafill audit/shakedown

• Per-site TX gain adjust

• SRCH_ WIN_A

If conducted on a cluster, the following will have to be repeated when surrounding cells are active:

• Coverage/handoff control

• Neighbour list analysis

• SRCH_ WIN_NIR

• Detailed dropped call analysis

5.4.3. Test CaUs

With the exception of hard handoff borders, aAlI testing should be conducted using Markov calls. If two phones are used one phone can carry calls for approximately 10 mins duration but at least one phone should make short calls (e.g. 2 mins). Do not attempt to re-establish a call immediately following a dropped call. A wait period of, say, 1 minute should be used.

5.4.4. Logging

See "SBS Diagnostic Logging in Commercial Networks" for additional information.

5.4.4.1. Data Collection Restrictions

Selector logfiles are collected on the cards (not on the BSM) and are restricted to 0.5Mbytes. Also, if there are, say, two selector shelves (twelve cards each for a total of 24) and only a single phone making many calls, each time a call was originated, it would be assigned to the next available selector card and the assignments would alternate between the two shelves. A single phone operating on a particular selector card with the SBS log mask given earlier will fill the data buffer with information in about 16 minutes. If the data logging buffer becomes full on a selector card, the behaviour depends on how the log was initiated, but in any case, some data loss guaranteed (even with continuous mode).

Issue 0.8

July 10, 1998

Page 30

!

~

I,

i

~ I

I

I

CDMA RF Optimisation

Technology Applications Group

5.4.4.2. LoggiDg Strategy

To avoid overflowing the data buffer, mobile calls should be limited to around 12 to15 minutes. After this time, the call would be terminated and another call originated (but the same logs should be kept open), this second call would occupy a different selector card and 15 more minutes of data can be collected. Obviously, this only applies to the phone making the long Markov calls, the other phone is already making short Markov calls so its logging load will be spread among the selector cards. Also, to avoid losing large amounts of data due to logging failures, a 30 minute logging period should be imposed on the data collection process.

The following is an example of a strategy that will reduce the risk of filling selector buffers:

At the BSC:

1. Start logging on the hour

2. Stop log at 25 minutes after the hour

3. Upload logs and put in the appropriate date/run directory

4. Start logging at half past the hour

5. Stop logging at 55 minute past the hour

6. Upload logs and put in the appropriate date/run directory

7. (and so on ... ) In the test vans:

1. Start logging on the hour

2. Start long Markov call on one phone

3. Start making short Markov calls on second phone

4. At 12 minutes past the hour, terminate the long call and re-establish (do not stop the log)

5. At 24 minutes past the hour, terminate calls on both phones

6. Stop log at 25 minutes after the hour

7. Save logs, tidy up written logs and prepare to re-start logging

8. Start logging at half past the hour

9. Start long Markov calIon one phone

10. Start making short Markov calls on second phone

11. At 42 minutes past the hour, terminate the long call and re-establish (do not stop the log)

12. At 54 minutes past the hour, terminate calls on both phones

13. Stop log at 55 minutes after the hour

14. Save logs, tidy up written logs and prepare to re-start logging

15. (and so on ... )

Issue 0.8

July 10, 1998

Page 31

I I I I

CDMA RF OptimiSllion

Technology Applications proup

Note, while every effort should be made coordinate with the SBS logs, it is not critical if the mobile logs are shorter or longer by a few minutes.

5.5. Drive Test Data Management Abbreviations used in this section.

The abbreviations used in the file names in this section should be interpreted as follows. yy: the year

mm: the month

dd: the day

nn: the run number

MMMM: the MIN number of the phone

tttt: the time (GMT) in minutes and seconds cc: the cluster

RUN: the word "run" appears explicitly in the file name

5.5.1 Data Transfer and Tracking

Due to the large amount of data that will be accumulated during optimisation, logging and tracking each data file is crucial.

An example naming convention is as follows:

• Selector logs: MMMMccrr.sbs

• Mobile logs: MMMMccrr.mbl

Additionally, a directory structure that includes the date should be considered mandatory. Text description files of the test conditions, purpose etc. should also be placed in the relevant directories.

5.6. Unconditional SBS Logging of Live. Users .

5.7. BTS PerformanceData

Issue 0.8

July 10, 1998

Page 32

CDMA RF Optimisation

Teebnoloav Applications Group

6. Data Analy,is 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.2.1. 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 aad, for each sector, examine the parameter settings in the Sync Channel Message, Systew Parameters Mes,§age, 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

6.3.1. Access Failure Analysis

Since at least one of the phones in the test vehicle is making many short calls, useful data on access attempts is available.

If the radio link f .

2. Access probes exhausted (seen by system but ack not reaching mobile)

Issue 0.8

July 10, 1998

Page 33

I

I

~

I

I

CDMA RF Optimisation Technology Applications Group

3. Ack received by mobile but Channel Assignment Message not seen

4. Channel Assignment Message seen at mobile but mobile does not acquire forward traffic channel

5. Mobile acquires forward traffic channel but system does not acquire reverse tch

6. System acquires reverse traffic channel but forward ack does not reach mobile

7. Forward ack reaches mobile but reverse ack does not reach system

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).

ilots are seen. If it seems. to be

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 at precommercial system can only be done using drive test data.

If 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. AccessParemeter Tuning

(INIT_PWR, NOM_PWR, MAX_REQ_SEQ, MAX_RSP _SEQ, PWR_STEP, NUM_STEP, MAX_CAP _SZ, PROBE BKOFF, BKOFF)

(Set INIT_PWR to be consistent with average TXGA - others should be at baseline datafill for now but need to be subject of a detailed test)

6.4. Dropped Calls

6.4.1. Link SUpervision

The link supervision algorithms define the criteria for dropping a call.

6.4.1.1

Mobile

The mobile will autonomously release the call if 250 frames are received without 2 consecutive good frames (i.e, every 2 consecutive good frames resets a 5 second fade timer).

Issue 0.8

July 10, 1998

Page 34

I

I

~

I

~

CDMA RF Optimisation

TechnoloKY Applications ,Group

Additionally, the mobile will disable its transmitter if 12 consecutive erasures are received and will reenable it when 2 consecutive good frames are received.

6.4.1.2 SBS

The SBS will autonomously release the call if 250 frames are received without 2 consecutive good . frames (i.e. every 2 consecutive good frames resets a 5 second fade timer).

The SBS will autonomously release the call if no acknowledgement (either an Ack or a Handoff Completion Message) is received to a Handotf 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 th¢ selector logs. However, most of them will need deeper investigation involving the SBS message files, the message flow files and parametric files (possibly after re-processing at 20mS resolution). While chapter 7 of this document attempts to provide a step-by-step approach to dropped call root cause analysis, there is no substitute for thorough knowledge of the air interface and $-95.

If the radio link fails after the mobile sends th Service Connect Co lete e then it is

consi ere a opped call. Using the symptoms described in chapter 7, separate the dropped calls into the following categories:

CD Coverage related

@ "Optimisable" e.g. slow handoff, search window, coveragecontrol, PN plan related. G) Equipment problems (e.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

I

I I

I

II

I

CDMA RF Optimisation

Technology Applications Group

6.4.3. Dropped Call Rate

Tools such as Nortel's RF Optimizer willautomatically generate dropped call statistics based on the actual number of test calls. If the long calls are to be used, the following method can be used to avoid skewing the data:

• In conjunction with the customer, decide on an average call duration (e.g. 100 secs) that will be used in the calculations.

• Use the total call time output from the data analysis tool and calculate the number of equivalent calls using the average call duration. Data for all phones for an entire network/cluster drive should be used.

• Eliminate any dropped calls that should not count in the total (e.g. drive routes that are clearly out of coverage, sites not in service due to datafill error etc.)

• Use the remaining drops and the total equivalent calls to calculates dropped call rate.

6.5. RF CoverageIHandotf Control

If these steps are not taken, the system will be prone to the following "Pilot Pollution" related problems:

._-........::===:;:;:;;;:111-- __

• Slow handoff' drC) ed c ive.n SRCH_ WIN_A setting, the number of active

ere is an increased chance of a new, stro ilo

not In de uickl . enou h. This 1 ma e worse y tlte fact that, in hi h handoff areas,

the pilot Ecllo values are typically very lo}v (because 0 ehigh 10). For example, if the mobile is in 4-wayhandoff in a loaded system, the active pilot Ecllo values could all be around -13dB. When a new pilot crosses t_ADD at, say, -14dB, it is already nearly equal to the active set pilots. B the tim hon·· has filtered the meas Pj1Qt Streng,th ,Measurement Message and the SBS has q eried the BTS fot resources, the new pilot may bx ~sing so much torwara lInK Interterencei IDat the Handoff DlrectlOn Message fails to reach ~.~~ ~

---

Issue 0.8

July 10, 1998

Page 36

I

I I I

I

I I

I

I

The following three sections describe how to Ioad survey data into a mapping tool to geherate 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 tiles containing latllong 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 latllong and the IEcllo 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 li~t of sectors which are possible contributors to the high handoff or poor Bello areas. For each of these sectors, the idea is to generate a plot for that sector alone showing where th~ 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 Ecllo. 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 latJlong and mobile transmit power. Suggested colour settings are: less than 13dBm = green, 13 to 18dBm = 'orange, 18 to 23 dBm = red. Generate one plot for the entire system/cluster. (The Nortel RF Optimizer can generate these plots automatically) ..

Analysis of these plots is somewhat subjective but the general procedure is as follows: The handoff state and overall Ecllo plots should b' used as an indicator

Issue 0.8

July 1", 1998

Page 37

II I

I I

I

~

I

I

• •

I

~

~

CDMA RF Optimistuon I .. Technologv AppUcations Group

If the problems occur along the main beam oflthe antenna, a downtilt alone sho

an enna r a re-onentanon. 0 not try to emove signal from areas where the mobile transmit

power IS above 18dBm (red) since these are the areas where high handoff is actually helping to maintain the call. To help decide on the exact changes, use single cell signal plots in Planet and experiment with antenna changes. A signal level reduction that will get the offending pilot below T_ADD should be calculated and applied before re-driving the area (see appendix 9.5 for an example calculation). Beware that, as unwant~dl?i1ots are removed from an area, the 10 is beiqg 1 reduced and so the ne"t drive of the area may 'reveal new problem pilots. makjn~ 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 Ecllo levels throughout the system and expose pilots that might not otherwise be seen.

T_ADDrr_DROP settings of -14/-16 are the recommended settings at this time for the following :::- 'C.

reasons:

• These values have given good results in simulations and field testing to date, particularly with respect to dropped call rate.

• In "pilot polution areas", the Bello levels Of the active set pilots can be as low as -12 or -13 dB. Even with T_ADD at -14dB, a new pilot will not be detected until it is almost equal in strength with the current pilots. By the time the mobile has measured it, sent a Pilot Strength Measurement Message, the system has setup 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 alloss 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 4<$ soft handoff g~n, we can. calculate (for a propagation slope of 3.5) that the last 4dB of the cell radius represents an area of 42%. Therefore, 42% of the cell area needs to be in soft handoff to ensure complete reverse link coverage. Restricting it to, say, 35% using the handoffthreshold(s) (which are forward link parameters and hence somewhat independent of reverse link coverage) would be a very bad thing to do. This is a very simplistic calculation and also the cell overlap that you will always get in a real design will help a lot with the reverse link coverage but it indicates the need to think very carefully about this.

More "intelligent" handoff algorithms are currently the subject of much discussion and field test (soft handoff reduction algorithm will be in release 6.2 - will need to re-write this section).

Issue 0.8

July U), 1998

Page 38

I I I I I I I I I

II II

I I

_ CDMA RF Optimisation

Technology Applications Group

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):

AI, A2, NI, AI, A2, N2, AI, A2, N3, R, AI, A2, Nl, ...

. \ I 1 I \ I J

The worst case searc . me to fi our can therefore be gen~~ise4.~.=._.

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 anew neighbour. the following table gives the acceptable search window combinations:

Neighbour Search Window (SRCH_ WIN_N) (chips)

20 28 40 60 80 100 130 160 226

Active/Candidate ~.lIlr"'h Window (SRCH_ WIN_A) (chips)

'10

14

20

28

40

60

Issue:O.8

Page 39

July U), 1998

I I I I I I I I I

CDMA RF Optimisation Technology Applications Group

The following table gives the datafill, maximum delay and corresponding distance for various window sizes:

Window size (chips) Dataftll Value Max Delay (uS) Distance (km)
14 (±7) 4 5.7 1.71
20 (±IO) 5 8.1 2.44
28 (±14) 6 11.4 3.42
40 (±20) 7 16.3 4.88
60 (±30) 8 24.4 7.32
80 (±40) 9 32.6 9.76
100 (±50) a 40.7 12.20
130 (±65) b 52.9 15.86
160 (±80) c 65.1 19.52
226 C±113) d 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 system/cluster.

6.6.1. SRCH_ WIN_A

Generate histograms of the maximum mobile finger separation for fingers locked to one pilot only. This is the basis for setting the optimum' value for SRCH ..... WIN_A.

Finger Packet

Packet Size: 15
Pilot Offset EcIO
312 0.00 -10.61 Locked
312 1.32 -14.38 Locked
320 0.10 -14.28 Locked Eig. 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 1e), 1998

Page 40

I

I I I

I

CDMA RF Optimisation

Technology Applications Group

Gather all the histogram files for one entire network/cluster run. Classify the areas by average cell size (two or three regions should be sufficient e.g. "small" (dense) urban cells and "large" suburban/rural cells) and generate an overall combined histogram for each region. Evaluate the histogram against the "Max Delay" column in the above table and choose a window size that will capture 95% of the finger separations. Check the shape of the histogram to ensure that the existing window setting is not already too small (i.e. is there a sharp cutoff at the current window setting). In this case, more data will have to be collected with a wider window setting before a proper judgment can be made.

The Nortel RF Optimizer will perform this analysis automatically.

To get an idea of the tradeoffs involved for different active search window settings, the following calculations can be performed:

For an active window setting of 60 chips and assuming the window is centered on the main ray from the cellsite, a multipath component that just falls inside the window will have traveled an extra 7.3km (30 chips @ 0.244km1chip = 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 2010.g(9.3/2) = 13dB lower than the main path. At the cell edge, even for an unloaded system, the Bello of the main ray is unlikely to be better than -5dB which puts the multipath at -18dB i.e. marginal benefit. For a more realistic path loss exponent of 3.5, the multipath will be 3510g(9.3/2) = 23.3dB lower (approx, -28.8dB Ecllo).

When we consider the larger cells and rework the numbers for, say, a 5kIn radius, assuming free space the multipath will be 7.8dB lower (-12.8dB E¢1I0 if we continue with t!le 5dB Ecllo main ray assumption) while assuming a 3.5 exponent the multipath will be 13.7dB down (-18.7dB Bello). 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 Ecllo) while the 3.5 exponent multipath will be 15.1dB down (,.20.1dB Ecllo). For the 5km case, the free space multipath component will. be 4.5dB down (-9 .5dB Eello) while the 3.5 exponent multipath will be 7.9dB down (-12.9dB Ec/Io].

Clearly the 5km case could benefit from a larger active seerch 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 qf 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 sees. With an active window of 60 'chips, the search time will be 0.64 sees i.e. a 52% penalty.

2. All Ecllo values will decrease as loading increases.

Issue 0.8

July 10, 1998

Page 41

I I I I I

CDMA RF Optimisltion

Te£~oI9gy Applications Aroup

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 wiQ.;:likely be some offset from an exact PN (rnultiple 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_PHASEI(PILOT_INC * 64»+ 0.5) * PILOTjlNC

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-STDOOS. The histogram should be biased to the positive Side (i.e. pilots delayed from the reference are more common than early arriving pilots). Remembering that the window is centered around the-reference, choose a window setting that covers 99% of the offsets. E.g. if ~9% of offsets corresponds to, say, 47 chips, the' . next highest "half window" is 50 chips so a window setting of 100 chips (datafil} of 10) would be appropriate. Check the shape of the histogram to ensure that the existing window setting is not ' already too small (i.e. is there a sharp cutoff * the current window setting). In this case, more data will have to be collected with a wider window setting before a proper judgment can be made.

The Nortel RF Optimizer will perform this analysis automatically.

6.6.3. SRCH_ WIN_R

SRCH_ WIN_R is typically set one-step higher than SRCH_ WIN_N. This ensures that pilots missing from the neighbour list will be captured but also allowsslightlymore distant "stray" pilots

to be detected. "

6.6.4. BTS AccessChannelDemodt4ationSearch Wiclth,

TrafticChannelDemodulationSearchWidth

rform the same functi: n for the BTS AS

mobile the alsis result can u the 95%0· histo ram was r

15.2 chips. The BTS demodulation windows are set in l/Sth chip units i.e 15.2 * S = 121.6. However, the smallest.increment that the CSM searches is 125 I/Sth 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

I

CDMA RF Optimisltion

Tecbnology Applications Group

6.7. Neigbbour Lists

~:-

G Any pilot that is requested to be addeg in ~ Pilot Strength Mensurement Message should be in !!_Ie neighbour list of the reference pilot in that PSMM.

G;) ~y pilots that are currently in the referen~e cell's I!eighbour list but never occur in a PilotStrengtbMeasurementMessaKt< should be removed from that nei&hbour Jist.

For example, consider the following NeighbotListTuningArray (the NeighborListTuningArray is simply a repeat of the PilotStrengthMeasurementMessage with extended baseid included):

Base ID Sector Band Class CDMA FIteq Pilot Strength Keep Bit Pilot_PN
------- ------ ---------- --------- -------------- -------- -------.-
28 3 1 50 -8.50 1 220
221 2 1 50 -11.50 1 192
28 1 1 50 -17.00 1 212
28 2 1 50 -21.50 0 216 PN 220 is the reference (since it ocurrs first in the message) so we are working on the neighbour list for that sector, P~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 ~ata 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

I I

CDMA RF Optimis.tion

Technology Applications .Group

For cases 2 and 3, generate a per-site histogram of all the handofftransitions 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/Io for each entry. This is particularly useful for pilots found by a Remaining Set search since the frequency of Occurrence may be low yet the strength may be high.

Tuning tool sample output:

KCI04x, 6036: KCI04y,2335,21,-8; KCI04z,2705,26,-9; ... ; KC68y,536,5,-1O; KC96z,34,0.3,- 11; KC208x,41,0.4,-9

The above represents the output for one sector (KCI04x 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 KCI04x is the reference pilot (it is shown here with sector designations but the tool could be made to display PNs or baseids). Each entry contains the number of times that sector is requested, the percentage that represents and I;the averageEc/Io. Underlined sectors are those not in the currently datafilled NL.

In the above example, the first two entries are the adjacent sectors of the same BTS so they are "normal" entries. KC68y is likely being found through the composite NL (high "hits" and good Bc/Io) but should be added to KCI04x's NL. :KC96z should be probably removed (unless it is an immediate neighbour and it is just low traffic that is causing this characteristic). KC208x is probably being found through the RemainingSet search (low "hits" but good Ec/Io) and should be added if it is determined that it does not need removing from the area through RF coverage control.

The Nortel RF Optimizer contains tools to provide a much more sophisticated analysis of NeighborListTuningArray data.

Issue 0.8

July lQ, 1998

Page 44

I

CDMA RF Optimisation

Technology Applications Group

Figure 2.: Neighbour List Example

6.8. Performanceffrend Analysis

If multiple drives of the same drive routes are-planned, Of if.a benchmark route is being used, the following parameters should be tracked:

• Average forward traffic channel gain and percent time at maximum

• Handoff overhead by sectors

• Average mobile transmit power and percent time within 5dB of maximum

• Dropped call rate

The values of all of these measurements should reduce as the optimisation process progresses. Note that FER is NOT included as a metric. This is because we are confident that power control works and that if all other issues are addressed, good FER performance will naturally follow.

Issue 0.8

July 10, 1998

Page 45

I

I

II I I I It I

III

~

I

I

I

I

CDMA RF Optimigtion

Technology Applications Group

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.

power.

2. A file containing all lines from the parametric flat me for which the number of pilots Iockede 1. A column containing the PN is needed. Thislwill allow additional perforinance analysis on a per-site basis e.g. FER, tJ:'affk: channel gain, Ew/No setpoint, finger separation.

The following table is an example output of al per-site transmit gain adjust analysis. We know from other analysis that the Whiterock (WROC) site is s~bject to interference from an adjacent COMA system (hence higher TXGA). The Burnaby (BURN)! site has the COMA BTS running from the COPD 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).

..,) '-h(f' 'TG-ot\ .~~ 1) ,?_- ~ c:.IZ.-\~ ,-,~ ~

i., )~.rwc.r-el L~""L... l .... +--~ <,

Issue 0.8

July 10, 1998

Page 46

I I I I

~

II

CDMA RF Optimisation

Technology Applications Group

Pilot PN Site I Average TXGA
8 LGLY -14.411692
60 WROCY -10.224532
68 NWSTY -15.800661
76 HCTR -16.165448
80 SURR -15.964134
84 KNDY -16.857579
88 PANY -13.542665
92 POCO -16.432903
104 CLOV -16.466863
116 GILDY -15.796377
128 MURR -14.556199
'136 LHED -16.48573
144 PMAN -14.431992
148 BURNY -10.874728
152 HANY -14.361585
220 WROCZ -16.Q75031
228 NWSTZ -14.310556
\
248 PANZ -11.875561
276 GILDZ -22.511815
.. -.
308 BURNZ -9.3749509
380 WROCX -10.4562~1
388 NWSTX -13.104353
408 PANX -12.938774
412 COLE -17.127062
436 GILDX -14.196346
468 BURNX -9.9643809 The Nortel RF Optimizer will perform this analysis over many mobile logs automatically.

Issue 0.8

July lQ, 1998

Page 47

I

I

I

I I I

CDMA RF Optimisation

Technology Applications Group

6.10. Capacity

capacity is toeliminate unnecessary handoff and

~~!!!!l~~n:mlm~~~muwm~~~oth orward and reverse lirikS through e following:.

• 80()d RF covera 'control no unnecessary handoff and interference)

• effective handoff (good neighbour lists, optimum search windows)

----

• 0 timum power control settings

• IItaximise paging channel effectivene~s

- ~ ----

• maximise access channel effectiveness

-------~----------------

6.10.1.

Capacity Equations

6.10.1.1. Reverse Link

(W IR)

N = (~b/No)x v x fx S

Where:

N = theoretical number of users per sector (Pele Capacity)

WIR = the ratio of spreading bandwidth to information bandwidth (i.e. the processinj gain) EblNo = the energy per bit / noise density

v = the voice activity factor (V AF)

f = the ratio of power received from users in this sector to power received fromall users S = the sectorisation gain

All values expressed in linear terms (not dB).

This equation takes no account of thermal noise and so is for a sector of zero radius (100% of the processing gain is used to fight the noise of o~er users). To design "real" cells, we need to allocate some of the processing gain to fighting thermal noise, We typically allocate half (i.e. we design for 50% loading). If we measure the noise floor of a B1I'S receiver with no load and then apply 50% load, the noise floor will double (since we are allocating half the noise to each). This is the "3dB noise rise for 50% load". A more general equation linking noise lise and load is:

Load (%)i= 100 x (1- lOC-NRllO»)

Therefore, if we can measure the noise rise th~t a certain number of users causes, we can calculate either pole capacity or 50% load.

Issue 0.8

July lq, 1998

Page 48

I ,I I

CDMA RF Optimisation

Technology 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.

/

/

I

1 .. (fpIIOI + fpage + fSynch)

N = -----=-----=---

flralf X hrf x v

Defmitions:

N == the number of average users a sector can support assuming the above conditions. tpilot = the fraction of total HP A power allocated for the pilot channel

fpage = the fraction of total HP A power allocated for the paging channel

fSynch = the fraction of total HP A power allocated for the synch channel

ftrafi = the average fraction of totallHPA power allocated for on~ann~l 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 (V AF)

Handoff Reduction Factor (lujf>: this term adjusts the average power per user based on the collected handoff statistics! for the system under test where:

Issue 0.8

July lQ, 1998

Page 49

I I I I I I

CDMA RF Optimisation I

Technology Applications Group

(2''11(2,2) +3''11(2,3) +4·'t\2,4) +5''11(2,5) +6''I1(2,6))'U2

~------~----~~----~----~~--+

U

(3''11(3,3) +4''11(3,4) +5'ljh5) +6'11(3,6))'U3

~------------~------~~--+

U

(4 ''11(4,4) + 5 '11(4,5) + 6 '~4,6) + 5 '11(5,5) + 6 '11(5,6) + 6 ''11(6,6)) 'U4 U

• 8 x 11( a,~) is defined as follows:

• 0 = number of sources of power control bits the system is having to send to the one mobile

• l1(a,~) = the percentage of time the one mobile experienced this type of

handoff, and

• a = the number of dells with which the mobile is communicating

• .. ~ = the number of sectors with which the mobile is communicating

• Ux= voice activity I factor for 'x' number of cells in soft handoff (i.e., the adjusted voice activity to account for variations in power gain of the power control bit due handoff involving x cells.

Woice Activity Factor (V Af)

• U = the average Markov voice activity factor for single sector coverage

I

l u, = [P(full) . [+ P(half)0.5623· 2 +

1 1 23 1

P(quarter)0.4467· 4 + P(eighth)0.3162·i)· 24 + 24' e.

• U = the average Markov voice activity factor for single sector coverage

• P(full) = the probability of a full rate frame occurring = 0.291

• P(halt) = 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, 114, 118 = 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 SO

Issue 0.8

I

I

I

I I

I

CDMA RF Optimisation Technology APDUcations·Group

• 1124 = the portionof a frame for which the power control power level applies

• Px2 = the relative power (relative to a "no handoff" power control bit) given to

a power control bit for the appropriate type handoff:

• for x=2 (for handoffs involving 2 cells), P22 = 2

• for x=3 (for handoffs involving 3 cells), p/ = 3

• for x=4 (for handoffs involving 4 or more cells), p/ = 4

• the constants for 112, 114, & 118 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.

Definitions:

N = P Ca!IBlock - (P Pilot + P"age + P sync) PLink * SPU

N = the peak number of unique average users a sector can support assuming the above conditions. PCallBlock= the power at which new calls are blocked

PPilol = the pilot channel power

PPage = the paging channel power

PSynch = the synch channel power

Plink = the average power that one "link" consumes (a link is defined as every user who is either in isolated coverage of this sector or who is in handoff with this sector)

SPU (Sectors Per User) = the average number of sectors that one user is in handoff with (could think of this as "links per user").

Finally, therefore, the equation calculates how many of these "average users" can be fitted into one HP A. 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 lQ, 1998

Page 51

I I II

I I I I I I II

I I

I I

CDMA RF Optimisation Technology AppUcationsGroup

Note that, unlike a witeline 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, onavetage, 8.8 users on each sector then, due to the extra interference in the system, the peak available ~il1 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. ~efer to the table at the end of this section (I900MHz 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"; th~ digital domain and the analogue domain. The digital domain refers to algorithms involving the digital "gains" that control the output level of each Channel Element. The analogue domain refers to the total BTS output power as measured at the RFFE Antenna 0 on the 1900MHz equipment or the "Demarc'{panel on 800MHz equipment and controlled by an attenuator in the upconverter. The "fully blossomed" value of this attenuator is controlled by a datafillable parameter TxAttenNormal.

(Need a diagram hereto illustrate above)

6.10.2.1. BTS Calibration

The two domains are "linked" at calibration time by enabling a single channel element at full gain of 254 (not 255 since the CE~s can only take even values because the LSB is fixed at 0). The output power is then adjusted using TxAttenNormal until an ~utput power of 4 Watts is obtained (note that this is NOT the pilot setting since the pilot is actually run ~t a lower gain i.e. we are NOT "calibrating for a 4W pilot"). Once this relationship has been established. we can calculate the power equivalent to any gain or combination of gains.

E~amPl ... e .. ! w ..' hat is the. 9,"~,.tp. ut ~wer fO~;»)he p. ilot an~'b)the pilot + sync + paging if the digital gains are

pilot = (86~ sync = \~and pagmg =. .

- .. -"".~-'

Answer; Since the digital gains ~e-~~llageg~ps. most calculations are in 'terms' of''bitssQ_\Ulred'' to

convert t()p~~er. Therefore, if(t~1~~~~t~s. the power corresponding to 186 is:

power = (1862/2542) x 4 = 2.14 Watt&~

and the power for all three channels is:

power = ((1862 + 602 + 1562)/2542) X 4 = 3.88 Watts

Issue 0.8

July 10, 1998

Page S2

I

II

I I I !I

I

II

~ I

I

CDMA RF Optimis,tion Tubnolggy Applications Group

The Transmit Power Tracking Loop (TPTL) ~s provides a guaranteed linkage between the analogue and digital domains since it constantly maintains ~e 2542 - 4Watts relationship. This is achieved using a feed back loop that sums up the current digital gai s for all overhead, traffic and OCNS channels, calculates the expected output power and compares it t . e an ogue sensor"1'eltding. If the two do not match, an offset (TPTLOffset) is appli~qlQ_the .. UPC9JIy~ner.attellU~tor. Note that accurate calibration is still required since the TPTL will not apply more Iithan +/-6dB of correction. However, great emphasis must be placed on connniiing-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.2.2. The Digital Domain, ForwaIjd Power Control and the Forward Blocking Thresholds The power output of any channel element is controlled by a digital gain. The overhead channels are fixed values datafilled at the BTS on a per-sector basis. The traffic channels vary within a defined range as required by forward link power control. The ~ange for the traffic channel g.s is datafilled relative to pilot power. For example, with a pilot gain o~ 216, an upper limit of -ldB pi~ot and a lower limit of -15dB pilot, the selector will send digital gains in th~ range 192 to 38. Note that the pilot gain is datafilled both per-sector at the BTS and as a global parameter at the SBS. It is the SBS value that is used to calculate the digital gains for the traffic channel. Therefore, even if the pilot gain at one sector of a BTS is lowered by, say, IdB to 192, the SBS will continue tOi. send digital gains in the range 192 to 38. I.e., for this sector alone, the traffic channels are now effectively 0dB pilot to -14dB pilot.

The forward link Call and Handofflslecking'Ihresholds are datafilled in terms of ExcessForwardLinkCapacity which is a bits-squared value. ExcessForwardLinkCapacity is calculated as follows:

1. Square the pilot gain (e.g. 1862 is 34596)

'!. Divide by MinPilotToTotalPowerRatio (elg. 34596 divided by -7.5dB (in linear terms) is 194547).

Call this number the "blocking threshold reference".

3. Sum up the bits-squared over all channel elements

4. Subtract item 3. from item 2. The result i~ the ExcessForwardLinkCapacity.

If the ExcessForwardLinkCapacity is less than the FwdCallBlockingThreshold, then block new calls. If the ExcessForwardLillkCapacity is less than tlteFwdHandoffBlockingThreshold, then block handoffs. The table shows how these numbers translatelto actual powers in Watts. Note that there is no action if the "blocking threshold reference" is crossed hlthough ExcessForwardLinkCapacity will never be reported as a negative number.

Issue 0.8

July lQ, 1998

Page 53

CDMA RF Optimiation Technology Applications Group

6.10.2.3. The Analogue Domain, Po~er Sensor and Power LiIIliting

Immediately following the High Power Amphfier (HPA), there is a power sensor that is calibrated to report the total power at the demarc panel (SOOMHz) or the RFFE output (1900MHz). The report from this sensor is in unitsof 1/16th dBm. Beware ~at this sensor is not immune to the waveform of the transmitted signal and since the sensor has ~en deliberately calibrated for the "most likely" situations, an

offset needs to be applied in some cases: .

1. Single walsh code, low power (i.e. during calibration): sensor reads correctly.

2. Three walsh codes, low power (i.e. overhead channels only): sensor reads correctly

3. Multiple walsh codes, low power (i.e. fet low power users): sensor reads O.75dBlow (12116th dB).

4. Multiple walsh codes, medium to high power (i.e. carrying traffic): sensor reads correctly.

I

The sensor reading is compared against a datafillable upper limit TxPowerMax. If this threshold is exceeded, the BTS will wilt the sector by on, step and re-compare the reading with TxPowerMax. This is the Power Limiting algorithm and it repeats 4ntil the power no longer exceeds TxPowerMax. Thislimits 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 ~locking threshold.$ should be set such that Power Limiting is a rare occurrence. The FwdHandofffilockingjrhreshold should be at a higher power than the FwdCallBlockingThreshold (give priority to ~xisting calls).

Using TxAttenNormal to permanently reduce the transmit power is not recommended for two reasons:

1. The Transmit Power Tracking Loop that fs soon to be introduced (6.Lt) will null out small changes or cause a fault to be reported for larger changes (> 6dB).

2. For every IdB that the forward link is reduced, the reverse link noise figure should be increased idB.

Although there is another parameter that can accomplish this, it is not datafillable(requires all "action") and so the change is very hard tp maintain.

The (crude but) effective way to achieve an equal reduction in coverage OIl both links (which is vital to system performance) is to use attenuators in ~e antenna cables.

Table ?: BTS Forward Link Power yd BtPcking Calculatlpns

! Power Power Sector- Percentag dB relative Notes
I e
Key Calculation patafil Bits (Watts) (dBm) T~J>ower of pilot to pilot
square
Pilot a 186 34596 2.14 33.31 100.00 0.00
Sync b 60 3600 0.22 23.49 10.41 -9.83
Paging (Half Rate) c 156 12168 0.75 28.78 35.17 -4.54
Total Overhead d a+b+c 50364 3.12 34.95 559 1.63
Typical User Traff Chan Gain e (971\2)*VAF*1.15 3895 0.242 23.83 -9.48 5) Issue 0.8

July 1~, 1998

Page 54

I I I I I I

CDMA RF Outimisation

Technoleav Auulications $,irouu

MinPiIotToTotalPowerRatio f Ii -135 1)
I'

I
Blocking Threshold Reference g a 11 0"( f1160) I, 241421 14.97 41.75 668 1),4)
CaliBIockingThreshoid h 1.61000 61000 3.78
HandoffBiockingThreshoid i Ii 0 0 0.00
% of TXPowerMax I
Calls will block at: ~ . g-h 180421 11.19 40.49 647 90.1 13) II
Handoffs will block at: k g - i 241421 14.97 41.75 668 120.6 Beware>
I: TXPowerMax
Ii I I
Capacity Stuff 1
Number of connections n (j - d)/e 29.0
I
Sectors per user 0 2.2
Sector Capacity q nlo 13.2
I ,Pilot %' Pilot dB down 11
TXPowerMax I, 655 12.41 40;94 6S~ 17.28 -7.621
s Notes

1) Remember the calculation STARTS from the pilot power - MioPilotToTotalPowerRatio does NOT set pilot power.

3) Calls should be blocked at 90% of TX~owerMax.Handoffs should not be blocked.

4) This number by itself has no meanlnq, 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 ForwardLink Capacity

The procedures covered in the RF coverage control section are aimed at giving good capacity throughout the network. However, sometimes there will ~e 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 4apacity. It is important to stress the unnecessary handoff since, taken too far, handoffreduction 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"):

July Ie), 1998

Issue 0.8

Page SS

CDMA RF Optimisation

TecJmology Applications· Group

• Removing interfegng handoff from otherl sectors: If the mobile is going into handoff with sectors outside the hotspot area and this is causing handoff in excess of 3-way, those sectors should be removed by downtiltinglantenna change/erientation 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.

~~~~~~I:i:W.~=~~~,,-=~~t~o~rs: If sectors outside the hotspot are transmitting power into the hotspot but the Ecllo is too low or the mobile to go into handoff, those sectors should be removed by downtiltinglantenna 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 $R.

• Reducing handoff within the hotspot: If ~ilot quality is good throughout the hotspot, a reduction in pilot gain by 1 or 2dB on the hotspot sectors can be very effective. Since the traffic channels will remain at the same absolute level as before, this has the effect of lowering the Be/lo of the hotspot sectors and hence reducing handoff. This [s much more effective than increasing T _ADD and

T _DROP for three reasons:

1. Raising T_ADD and T_DROP must 1j>e done on the surrounding sectors as well as the hotspot sectors since the mobile needs to have the new values before approaching the hotspot sectors. This causes a general lowering of handoff throughout the region. Reducing the pilot gain, on the other hand, targets the hotspot sectors very specifically and will also allow surrounding sectors to pick up some of the traffic since it actually shifts the handoff boundaries rather than just reducing handoff.

2. Because of th~ rules for updating T _.AJ)D and T _DROP (most negative value for any of the active set), mctny more sectors need tq be changed than are really required. This may cause problems elsewhere where the higher'T_ADD and T_DROP cannot be tolerated,

3. Reducing the pilot power frees up some HPA power for traffic channels.

6.11. Power ContrOl

The power control parameters given in the Technology Applications datafill spreadsheets are the result of much simulation and field testing effort (reference power control report). Target frame error rates may be adjusted if the average frame error rates are notmeeting customer expectations (changes to the reverse link should be done by scaling allS targets). Changes to the step sizes or the upperllower/start values should not be contemplated unless a specific $et of carefully designed tests are carried out solely for this purpose.

The forward link power control parameters f0r rate set 1 (PWR_REP _THRESH, PWR_REp _FRAMES) should not need to be adjusted.

(Explain why reverse link looks like set to 0.5% but is really 1 % because of the way the algorithm works with non-equal per-rate target FERs)

Issue 0.8

July If), 1998

PageS6

CDMA RF Optimisation

Teehnoleev 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 (RID) C,lcuiations

The BTS is able to measure the Round Trip Delay as follows:

• Remembering that 1 chip is 0.814uS, 1 chip represents a l-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 2/0.244 = 8.2 chips.

• The mobile will use this signal for it's timing reference so it's timing is now 8.2 chips "late" relative to system time.

When the mobile now transmits to the B1I'S,afurther 8.2 chip delay is incurred. The BTS "expects" the signal to arrive as if the mobile were ~t 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 RID measurement if the BTS were making all it's measurementsright at the antenna. In reality. there is some processing delay on both the transmit and receive paths internal to the BTS. Two parameters, FwdDistributiqnDelay and RvsDistributionDelay, are available to effectively "zero" out this internal delay. ~f these have beendatafilled correctly then all RTD calculations only need to take the "over tljte air" delay into account. Otherwise, the sum of these two parameters will effectively be added to all! RID measurements; The DistributionDelays are datafilled in 1/8th chip units. RTD is also reported by the system in lISth chip units. A report is generated every time the RTD changes by 2 chips.

Example: What is the required datafill value tor an RTD triggered hard handoff to occur at lkm from a cell a) if the DistributionDelays have been set correctly and b) if the DistributionDelays have been left atO on a 1900MHz BTS.

Answer: lkm represents a l-way delay of 1/0~244 = 4.1 chips and hence a Round Trip Delay of 8.2 chips. Since the datAf.tl1 is in 1/8th chip units, the dat~ll for answer.ajis 66. On a 1900MHz BTS, the sum of the DistributionDelays is in 1/8th chip units and is 79 + 212 = 291. Therefore, the datafill required for b) is 291 + 66 = 357.

6.13. Other

Future revisions of this document will contain sections on the following:

• registration

• paging, SMS

• traffic management (blocking thresholds, breathing, multi-carrier) • (more ... )

Issue 0.8

July 1~, 1998

Page 57

CDMA RF Optimisation

Technology Applications Group

7. Dropped C,U and Access Faihtre Reasons and Solutions

(This section under re-construction)

This section details the characteristics that wi~l be observed in the diagnostic logs for various field issues that will be encountered throughout th~ network. Section 8 will cover issues specific to special cases.

7.1. Successful CaD

This section explains the characteristics in the! data for a phone that originates succesfully, remains in the service area, completes a handoff and makes a normal release.

7.1.1 Symptoms in Mobile Data

If only mobile data is available, the parametric files will show:

• Receive power> -100dBm

• Transmit power < + 18dBm

• Normal Transmit Gain Adjust (actual value depends on site configurations, loading, NOM_PWR setting)

• Low forward FER

Good Ec/Io (> -12dB) on at least one pilot

Under these conditions, messaging will be reliable. In message file output,a bas.: call (originated and released from the mobile) will contain the following elements :

• Origination message (sent to MTX on Ac¢ess Channel).

:3TS 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 (sentlto 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 HandoffDirection Message (from SBS - directs handoff - if all is well, will contain same PNs requested by the mobile).

Issue 0.8

July 10, 1998

Page 58

I I I I I I I I

• HandoffCompletion Message (sent to S ,S - confirms receipt of Extended HandoffDirection

Message).

• Neighbour List Update Message (from S$S - contains new composite Neigbour List)

• Release Order (sent to SBS)

• Release Order (from SBS)

7.1.2

Analysis with Selector Logs

Using the parametric files, the following can be established:

• Receive power> -l00dBm

• Transmit power < + 18dBm

• Normal Transmit Gain Adjust (actual value depends on site configurations, loading, NOM_PWR

setting)

• Ew/No setpoint below maximum

• Traffic Channel gain below maximum

", Low forward FER (either full or all rate) .. Low reverse FER (either full or all rate)

;~ Good Bello (> .. 12dB) on at least one pilot

A .nessage flow me for the same basic call w~ll contain the following IS-95 messages:
mr 01:12:02.5850 195_AChanOriginationMs~e AS:? MS:5 AR:1
MM 01: 12: 02.7287 195_PChanCDMAChannelLi~tMsgType ppm 320
MM 01:12:0;2.8475 195_PChanOrderMsgType
MM 01:12:03.1475 195_PChanExtendedSyste~parametersMsgType PE'N:320
MM 01:12:03.1688 I 95_PChanGeneralPageMsdTYPe
MM 01:12:03.6687 195_PChanChannelAssi~entMsgType
SS 01:12:03.7400 I 95_FTChanOrderMsgType AS:7 MS:O AR:1 OR:16
MM 01:12:03.8087 I 95_FTChanOrderMsgType AS:7 MS:O AR:1 OR:16
MM 01:12:03.8863 195_RTChanOrderMsgType AS:O MS:O AR:O OR:16
SS 01:12:03.9200 I 95_RTChanOrderMsgType AS:O MS:O AR:O OR:16
SS 01:12:03.9400 195_FTChanE'owerControlaarametersMsgType
SS 01:12:03.9600 195_FTChanServiceConne~tMsg'l'ype AS:7 MS:2 AR:1
MM 01:12:04.0075 195_FTChanpowerControl~arametersMsgType
MM 01:12:04.0288 195_FTChanServiceConneqtMsgType AS:7 MS:2 AR:1
MM 01:12:04.0675 I 95_RTChanServiceConneqtCompletionMsgTyp AS:1 MS:O AR:1
SS 01:12:04.1000 195_RTChanServiceConnedtCompletionMSgTyp AS:1 MS:O AR:1
MM 01:12:04.1075 I 95_RTChanOrderMsgType AS:2 MS:1 AR:O OR:16
SS 01:12:04.1400 195_RTChanOrderMsgType AS:2 MS:1 AR:O OR:16
SS 01:12:04.2200 195_FTChanOrderMsgType AS:O MS:O AR:O OR:16
MM 01:12:04.2887 I 95_FTChanOrderMsgType AS:O MS:O AR:O OR:16
Issue 0.8 July lQ, 1998 Page 59 Issue 0.8

July 1~, 1998

Page 60

I
I CDMA RF Outimisltion TechnQI2KI Al!I!lications ~rouu
MM 01:12:05.2075 I95_RTChanPilotStrengt~MeasurementMsgType AS:2 MS:1 AR:1
PPNs: 320R: ( -7.00)K 312: (-12.50)K
SS 01:12:05.2400 I95_RTChanPilotStrengtijMeasurementMsgType AS:2 MS:1 AR:1
I PPNs:320R: ( -7.00)K 312: (-12.50)K
SS 01:12:05.3000 I95_FTChanExtendedHandqffDirectionMsgType AS:1 MS:3 AR:1
PPNs:320 (0) 312 (1) SrchWin A:6 TA:~8 TD:32 TC: 5 TTD: 3
I SS 01:12:05.3200 I95_FTChanExtendedHand~ffDirectionMsgType AS:1 MS:3 AR:l
PPNs:320 (0) 312 (1) SrchWin A:6 TA:~8 TD:32 TC: 5 TTD: 3
SS 01:12:05.3600 I 95_FTChanExtendedHandqffDirectionMsgType AS:1 MS:3 AR:1
PPNs:320 (0) 312 (1) SrchWin A:6 TA:~8 TD:32 TC: 5 TTD: 3
I MM 01:12:05.3688 I 95_FTChanExtendedHandQffDirectionMSgType AS:l MS:3 AR:1
PPNs: 320 (0) 312 (1) SrchWin A:6 TA:~8 TD:32 TC: 5 TTD: 3
MM 01:12:05.4075 I 95_RTChanOrderMsgType AS:3 MS:2 AR:O OR:16
I MM 01:12:05.4100 I 95_FTChanExtendedHandqffDirectionMsgType AS:l MS:3 AR:1
PPNs:320 (0) 312 (1) SrchWin A:6 TA:28 TD:32 TC: 5 TTO: 3
SS 01:12:05.4400 I95_RTChanOrderMsgType AS:3 MS:2 AR:O OR:16
II MM 01:12:05.4475 I95_RTChanHandoffCompl~tionMsgType AS:3 MS:2 AR:1
PPNs:320 312
MM 01:12:05.4500 I 95_FTChanExtendedHand,ffDirectionMSgType AS:1 MS:3 AR:1
i PPNs:320 (0) 312 (1) SrchWin A:6 TA: 8 TD:32 TC: 5 TTD: 3
II SS 01:12:05.4800 I95_RTChanHandoffComp1etionMSgType AS:3 MS:2 AR:1
PPNs: 320 312
I MM 01:12:05.4875 I95_RTChanOrderMsgType AS:3 MS:3 AR:O OR:16
SS 01:12:05.5000 I 95_FTChanNeighborListqpdateMsgType AS:2 MS:4 AR:1 PPN
Inc: 4 NPNs:316 60 300 288 428 304 292 176 ~20 364 56 284 172 276 200 188 184 296 424 428
SS 01:12:05.5200 I 95_RTChanOrderMsgType AS:3 MS:3 AR:O OR:16
II MB 01:12:05.5275 I 95_RTChanOrderMsgType AS:3 MS:4 AR:O OR:16
SS 01:12:05.5600 I95_RTChanOrderMsgType AS:) MS:4 AR:O OR:16
MM 01:12:05.5700 I 95_FTChanNeighborListqpdateMsgType AS:2 !(S:4 AR:1 PPN
II Inc: 4 NPNs:316 60 300 288 428 304 292 176 4120 364 56 284 172 276 200 188 184 296· 424 4.28
SS 01:12:05.6800 I 95_RTChanOrderMsgType AS:4 MS:5 AR:O OR:16
I SS 01:12:12.9400 I95_FTChanServiceOptionControlMsgType AS:2 MS:5 AR:1
MM 01:12:13.0287 I 95_FTChanServiceOptionControlMsgType AS:2 MS:5 AR:1
MM 01:12:13.1075 I 95_RTChanOrderMsgType AS:5 MS:6 AR:O OR:16
I SS 01:12:13.1400 I 95_RTChanOrderMsgType AS:5 MS:6 AR:O OR:16
~ SS 01:13:45.1000 I 95_FTChanServiceOptionControlMsgType AS:4 MS:O AR:1
MM 01:13:45.1888 I95_FTChanServiceOptioniControlMsgType AS:4 MS:O AR:1
'I MM 01:13:45.2288 195_RTChanServiceOptio~ControlMsgType AS:O MS:3 AR:O
SS 01:13:45.5200 I 95_FTChanServiceOptioniControlMsgType AS:4 MS:O AR:1
I MM 01:13:45.6100 I95_FTChanServiceOptioniControlMsgType AS:4 MS:O AR:1
MM 01:13:45.6875 I 95_RTChanOrderMsgType AS:O MS:4 AR:O OR:16
SS 01:13:45.7200 I95_RTChanOrderMsgType AS:O MS:4 AR:O OR:16
MM 01:13:52.3275 195_RTChanOrderMsgType AS:O MS:5 AR:1 OR:21
SS 01:13:52.3600 I 95_RTChanOrderMsgType AS:O MS:5 AR:1 OR:21
SS 01:13:52.4400 I 95_FTChanOrderMsgType AS:5 MS:1 AR:O OR:21
MM 01:13:52.5087 I 95_FTChanOrderMsgType AS:5 MS:1 AR:O OR:21
MM 01:13:52.9725 195_SChanSyncMsgType PPN:312 I I I I I I II I I

~

CDMA RF Optimisation

TechnololY Applications Group

I 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 acknowledgjrnent to that particular PSMM).

The MM and SS indicate messages logged at the mobile and SBS respectively (i.e. if all is proceeding normally, every trafficchannel message will appear twice, once. at each logging point).

Order type 21 is a release message.

Issue 0.8

July lQ, 1998

Page 61

I I I I I I I I

CDMA. RF OptimisMion

Technology Applications Group

7.2. Access Fail and Dropped Call Reas~ns in Single Frequency System i.e. no hard handoff

Description Symptoms in data , Solution Comments
Access FaDures
Bad pilot choice - drops 1 or more probes (have seen up Control RF to reduce Does pilot selection algorithm need
paging channel to 5), no Ack or CA at mobile, cases of multiple pilots improving?
then immediately back tq SYNC. with no dominant server.
Poor Ecllo. Lots of Bad Jfaging
Channel CRCs. " '
Bad pilot choice - missed Mobile receives P-channtc1 order Control RF to reduce Does pilot selection algorithm need
Channel Assignment Msg and stops probing but no CA cases of multiple pilots improving?
seen. Selector logs will have with no dominant server.
NOIS msgs setting up resources
etc.
Bad pilot choice - fails to Mobile receives channel , Control RF to reduce Does pilot selection algorithm need
acquire fwd tch asignment but goes to S~C cases of multiple pilots improving? Also, fix introduced in
within 1 second. Selectorlpower with no dominant server. 2A.5 that temporarily increases
control setpoints at select Increase P.I2' start to - fwd TClI gain by 5 5dB during
frozen at starting values. . obile IdB. acquisition phase.
never enables its transmitter.
Bad pilot choice - distant At the end of a call, mob~le Downtilt distant PN if Mobile alsorithm onl~ look~ for
PN chooses to Sync to a dis~t PN possible. first adequate PN r!!b~[ $llIlD Ib~
even though better local ,Ns are best PN. Does pilot selection
-
apparently available. ~ algorithm need jmprovin~?
origination f!!ila bc!;IlIoJSC. ., ..
Neighbour List of l1illrllnriPN

does not contain any. of the local
PNs.
Bad pilot choice - before Forward link dies before lfirst Control RF to reduce Does pilot selection algorithm need
SVC handoff can be completed (and cases of multiple pilots improving?
still before Service Connect with no dominant server.
(Complete) messages). utually
see multiple EHODs and tervice
Connects from selector b t not
arriving at mobile. Issue 0.8

July lQ, 1998

Page 62

I

I

I I I

CDMA RF Optimisation

Technology Applications Group

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 PN is interferer neighbour lists and neighbour lists after doing
(stays as candidate). Mobile will reducing the number of downtilts. Selector selnt05aa has
likely SYNC to pilot it was way HO by controlling quickrepeat and higher gain on
requesting. Poor Ecllo, high fwd RF.1f 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
l00dBm. Mobile TX above coverage here and none of
+18dBm. Bad erasures both the existing cell sites can
ways, poor EclIo. High selector be "persuaded" to cover it
power control setpoints. then you need a new
cellsite.
_.
PN Aliasing Mobile sees and requestshandoff Inspection of the Pilot
to a PN in the neighbour Iist but Database neighbour list ,.
call continues to degrade. and reveals that the PN
dies with all symptoms of fwd actually refers to are-use
link interference (good RX, poor of that PN and not the one
Bello, high erasures). the mobile is heading
towards. PN re-tune
required.
Mobile fails to send Mobile sends Ack to Extended Mobile fix required. Mobile has NOT acted on the
Handoff Completion Handoff Direction Message but EHOD (has not updated its Active
Message doesn't follow up with HOC. Set).
Selector times-out waiting for
~
Pilot not in neighbour list Good mobile RX power but poor First see if the pilot that Don't forget to re-assess your
Bello and erasures. Usual cause caused the drop is neighbour lists after doing
of death is messaging failure on intended to serve that downtilts - can any be removed?
fwd link. After drop, mobile area. If not, control the
SYNCs to a pilot that wasn't in coverage (downtilt etc.). If
last neighbour list update. it is (or it can't be
PSMMs unlikely (although may removed from that area)
be picked up on Remaining Set then a neighbour list
search). change is reqd.
Un-identified Interferer Good mobile RX power butpoor Essentially a neighbour
Ec/Io and erasures. Usual cause list problem as above but
of death is messaging failure on interference has gone
fwd link. After drop, mobile away by time mobile syncs
SYNCs to a pilot that was in last so hard to tell who it is.
neighbour list update but.no Driving area very slowly
PSMMs sent. can often reveal the
interferingPN. Easier to
see with OCNS off. Issue 0.8

July 10, 1998

Page 63

I I

, I

I

II

II III I ii,

I I

CDMA RF OptiJnisttlgn

TechpoJ.oay Applications $!roup

If a reverse message is repeated because an ack is not received, either it is not getting to the selector (reverse link is worse) or the fwclack isnet reaching the mobile (fwd liDle is worse). The parametric files may indicate which is hapi>erung but ideally selector logs are required.

• If a fwd message is repeated then the rvs ack is not reaching the selector (reverse link is worse).

• !f the mobile repeats a message 3 times without seeing the ack, it will tear the call down and will gp !E the SynC channel. ...

• If the selector repeats a message 5 times Without seeing the,ack, it wil! send a forward release apdJbe ~al1 will be torn deivB. If the mobile sees tihe release, it will respond willi a reverse release and stop transmitting. Otherwise, it will timeout when no good frames are received for TBD sees,

7.3.2 Analysis with Selector Logs

Using the full parametric files, the following can be established:

7.3.3.

Further Analysis

7.3.4 Corrective Action

7.7. Site Not In Service

i.e. pilot/paging/sync are being broadcast but can't handoff/originate

7.7.1 Symptoms in Mobile Data

looks like fwd interference (good RX, poor &110, poor FER, high TXGA), will see PSMMs requesting site and see site go to candidate on data collection tool but never active

7.7.2 Analysis with Selector Logs

NOIS will show failure to setup resources at new site

7.7.3. Further Analysis

Repeat shakedown at the site

7.7.4 Corrective Action

Issue 0.8

July 10, 1998

Page 65

I i

CDMA BE Optimisation

Technology Applications proup

7.8. Interference From Non Co·located AMPS CeUstte

7.8.1 Symptoms in Moblle Data

Looks like fwd interference (good RX, poor Ecllo, poor FER, high TXGA)

7.8.2 Analysis with Selector Logs

7.8.3.

Further Analysis

7.8.4 Corrective Action

Need either more CDMA power or less AMPS - likely neither are practical so will have to live with problem

7.11. Handoff Boundary Balance

7.11.1 Symptoms in Moblle Data

7.11.2

Analysis with Selector Logs

7.11.3. Further Analysis

7.11.4 Corrective Action

7.12. Interference from Microwave Link (1900)

Could be forward or reverse link interference

7.12.1 Symptoms in Moblle Data

Fwd: (good RX, poor Ecllo, poor FER, high tXGA), mobile will sync to the problem site after call drops

Rvs: (high TXGA, higll TX)

Issue 0.8

July 10, 1998

Page 66

I I I I

I I

CDMA RF OptimlsJ$ion

TedmololY ADDlications proup

I 7.13. Interference Irom Foregln System Mobiles into CDMA BTS

7.12.2 Analy. with Selector Logs

7.12.3. Furth .. Analysis

7.12.4 Correttive Action

7.13.1

Symptoms in Mobile Data

reverse link interference (high TXGA, high TK)

7.13.2

Analysis with Selector Logs

7.13.3. Further Analysis

7.13.4 Corrective Action

7.14. AMPS AlB Band Coordination

i.e. 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 ISclIo, poor FER, high TXGA)

Issue 0.8

July 10, 1998

Page 67

cnMA RF Optimiglion Technology AppUcations Group

8. Other Optillisation Proeedurm and Special Cases

8.1. Adding New Sites

Adding a new site to an existing (optimised) system, either for capacity (embedded cell) or for coverage (edge cell) consists of the following steps:

• Create new neighbour lists for the new cell and the surrounding cells using the method in section 4.3.

• Estimate suitable antenna downtilts using Ec/Io plots in Planet

• Create the datafill.for the new cell (parameters such as search windows, access channel settings, can

be copied from surrounding cells)

• Blossom the cell during a low traffic period and perform shakedown

• Cell is now available for carrying traffic

• Enable the NeighborListTuningArray and rune 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

I

II I I

II

CDMA RF Optimisation

Tecbnology Applications Group

9. Appendices

9.1. Sample Mobile Data Log Sheets

DATE: (YYMMDD) VAN CREW: I RUN':
TEST:
ROUTE:
VEHICLE Mit CALL RAtE SBS 2ND LOG FILE
TVP.E LOGS PHONE
B N Q M V 13 ! 8 Y N Y N M
B N Q M V 13 8 Y N Y N M
DATA COLLECTION SOF'ntlARE: HANDSET SOFTWARE:
NETWORK SOFTWARE: LOGM4SK=
• SITES ACTIVE: SITES Not AVAlLAEJLE:
S1'ARTTIME STOP TIME

KEV TIME MIN COMMefmI LCi>CAnoN
· ___ a.tNCCLI IJUO(lIlnv ... "" HCIl'IKNovLIILY!.HIOMUIIII_ POCO _ WACX WAC'I WACZ FlWD IWIY

___ a.CI!ICCLI .......... _, ................. VLHEI) MUIIII_ - __ IWfY __ PQCO ...... WACX WAC'lWI'IQl:FlWD IWIY The top portion of a mobile log file appears above, a complete set of log sheets can be found in Appendix xxx, The engineer mooitoring the data collection tool was required to keep this detailed log throughout the data collection proeess. The first following information was recorded on the log sheet.

Date: The format for the date was yymmdd $ld this format was maintained throughout the data collection process. TIle data was placed in subdirectories on all the computers under this date.

Van Crew: A record of the members of the 'fan crew on the day the data was collected is necessary in case there are any questions about the logs af1Ierthey are collected.

Run Number: The rUn number is always prefixed by a letter to indicate the van that was used for data collection. This information is vital in the event that a problem is subsequently identified with the data collection tools in the van.

Test: A description of the test being done anell the parameter or situation being investigated. Route: The drive route used for the data collection.

Vehicle: The appropriate letter is circles to iJldicate 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 1~, 1998

Page 69

I I I I II

I I I

CPMA RF Optimiytion I lJclmology APDUcatjons (lroup

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 logsjwere 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 on~ mobile was being logged during testing.

Log FHe: The log file.name provided by the (lata collection tool at the end of the logging period. These log file names always begin with an M.

Date Collection Soft9are: 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 h.dsets 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 bot on the air during the test.

Start Time and Stop Time: The start time and stop time of th¢ mobile log. All times recorded use the GPS time of the system in order to reference (he data logs beina collected by the data collection tools.

Key: The key is contained in a footer on the log sheet. Events of note. are recorded using the key to

. quickly code the event. As Vancouver has many bridges and bridges had been identified as potential problem areas, a code was required to track data collected on bridges.

KEY: D· DROPPED CALL F • ACCESS FAILURE U· CALL UP 81· ON BRIDGE 80· FF BRIDGE S· VEHICLE STOPPED

M • VEHICLE MOVIN T· NORMAL CALL TERMINATI X.· CROSS STREET ORINTliRSECTION

Time: The GPS system time of the event beiag logged.

MIN: Used when two MINs are being logge~ 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 .lIJ1d direction being traveled is entered at the beginning of each run, then all cross streets are recorded aszhey are crossed. Whep. the vehicle turn$, 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: 04122199 09:26 AM

Issue 0.8

July 1", 1998

Page 70

I _!

I ,

Iii I!

1,1' I,

I

I

I

I

I

I

I

CDMA RF OPtimisation

Technology Applications' Group

DATE: (VYMMDD) VAN CREW: 1 RUN#:
TEST:
ROUTE:
VEHICLE MIN CALL RATE SBS 2ND LOGFILE
TYPE LOGS 'PHONE
B N Q M V 13 8 y N y N M
B N Q M V 13 8 y N y N M
DATA CoLLECTION SOFTWARE: HANDSET SoFTWARE:
NETWORK SOFTWARE: LOGMAS~:
# SITES ACTIVE: SITES NOT AVAI.LABLE:
trARTTtME STOP TtME

KEY TIME MIN COMMENTS LOCAnON
_1ANY_a.tN COl.I ClLDXCilLDYCILDZ HClRl<NDl'l.III.VLHID MUFIA __ IfflH_I'IINY~_ POCOIUVI_WN::YWACZA.WDHoW(

_IANY _aJ:NCXllI ClLDXCilLDYCILDZ HClRlCIClYl.III.YLHID MUFIA __ Y _____ POCO ___ WACZA.WDHoW(

IANXIANY_a.CNCOl.I CIUlXCilLDYCILDZ HCTlIII<NDl'LGLYLHlDMUFIA ___ • ____ POCOIUAII __ WACZA.WOHoW(

• 1ANX __ a.CN COl.I Cll.DXCilLDYCILDZ HCTRilClClYl.QI.YLHID MUFIA --tMIIiPANXPIlft. __ POCO ___ WACZA.WD HoW(
IANX IANY _aJ:NCCU! Cll.DXQU)YCILDZ HCTRi-vl.lll.~ LHlDMUFIA _______ POCO.1lUIIA __ WACZA.WDHoW(

_IANY _aJ:N COl.I ClLDXCiILDY CILDZ HCTR~l.III.VLHlDMUFIA ___ PAH!t~ _ POCO 1UVI_'MIeYWACZA.WD HoW(

___ aJ:NCCI.I ClLDXCilLDYCILDZ HCTRlomvl.lll.YLHlDMUFIA _______ POco ___ WACZA.WDHoW(

_1ANY_a.tNCOl.IClLDXQ~ClLDZHCTR~~LHlDMUFIA _______ POCO ___ WACZ~HoW(
IANXIANY-~~ -'l ClLDXCilLDYCILDZ HCTRlomvl.lll.YLHID ________ POCOIUA8 __ WACZA.WDHANY

· __ IRNZa.tNCCU Cll.DXCiILDY~HCTR~l.III.Y ..... ________ POCO ___ WACZA.WDHoW(

_IANY _a.tN COU! ClLDXCilLDYCILDZ HCTR ioovLGLY LHlDMUFIA _______ POCO ..... _~WACZA.WOHoW(

IRNXIANY_a.CNCOl.I CIUlXCilLDYCILDZ HCTRi<Novl.lll.YLHID ________ POCO ___ WACZ~""'"

· IRNX __ a.tN CXllI CII.DX CilLDYGILDZ HCTR PIOV l.III.V LIED MUFIA _______ POCO IIJRR WACltWAatWACZA.WD HANY
IRNX 1 __ a.tN CXllI GUlXCiILDY'iM'Z HCTRPIOYLGLYLHID """"" NW8X ___ PANY __ POCOIUMWACX _WACZFI.WD HoW(
___ aJ:N COl.I Cll.DXQUlYCILDZ HCTRlPt:rtl.lll.YLIED """"" NW8X __ PANX ___ POCOIUAllWACK _WllCZA.WOHAHY Issue 0.8

July io, 1998

Page 71

CDMA RF Optimiytion

Tecbpology AppHcations group

I

DATE: (VYMMDD) CONTIMUATION SHEET: _OF __ RUN':
TEST:
KEY TIME MIN COMMENTS LOCATION
___ aDf c:cu Gl.DXGlDYGLDZ HC'Il! ~LGLYI.HEO MU'IA NWOX __ p~ ___ PCC08UAR WRCX'NRC'IWRCl:!'lWDHNIY
___ aDfCCII.EGl.DXGlDYGLDZHC'Il!~~I.HEO~NWOX ______ PCCOIUMWRCX'NRC'IWRCl:~HNIY
___ aDfCOLE Gl.DXGlDYGILDZ HC'Il!~LGLY I.HEO _ NWOX _Y!WiU ____ PCCOIUMWRCX'NRC'IWRCl:~ HNIY
IRNX __ aDfCOLE Gl.DXGUlY GI.DZ HC'Il! ~LGLYI.HEO _ NWOX __ i>ANX _ P __ PCCOIUMWRCX'NRC'IWRCl:FlWD HNIY
___ aDf CCUI Gl.DXQU)YGLDZ HCTA ~LGLV I.HEO ____ I>ANX ___ PCCOIURAWRCX'NRC'IWRCl:FlWDHNIY
___ aDfCCII.E Gl.DXQU)YGLDZ HC'Il! ~LGLYI.HEO ___ P __ PCCOIUM WRCX'NRC'IWRCl:~HNIY

___ aDf CCUI Gl.DXGlDYGLDZ HC'Il! ilNDYLGLYlHID MU'IA _______ POCO IUMWRCX'NRC'IWRCl:FlWD HNIY
___ aDf COLE Gl.DXGlDYGLDZ HC'Il! IINDvLGLYlHID ________ PCCOIUMWRCX\WICVWRCl:FlWD HNIY
__ lI!NZaDf COLE Gl.DXGlDYGLDZ HC'Il! IINDvLGLY I.HEO ________ P0C08UAAWRCXWW::VWRCl:~HNIY
IIRNX_lI!NZaDfCCII.E Gl.DXQIDYGI.DZ HC'Il! 1INDV I.QI.YlHID ____ ~ P'8rJW« _ !'9CQ8UAR WRCXWW::V~FlYl!!HNIY
___ aDfCOLE Gl.DXQU)YGLDZ HC'Il!IINDvLGLYI.HEO ______ ~_ PCCO_WRCX'NRC'IWACZ~HNIY

__ lI!NZaDf CCII.E Gl.DXGI.DY~ HCIIR IINDvLClLYLHI!O MU'IA _______ PCCOIURAWRCX'NRC'IWACZFlWD HNIY
__ lI!NZaDfCCILE Gl.DXGlDYGLDZ HC'Il! IINDvLGLV lHID MU'IA ___ P ____ PCC08UARWRCX'NRC'IWACZFlWDHNIY
IRNX __ aDfCCLI <lI.DXQIDYGLDZ HCTA IINDv LGLYI.HEO ___ NWlZ __ oWoz_ POCOIUM WRCX'NRC'IWRCZ~ HNIY
_ IRNX __ aDfCCILE Gl.DXQU)YGLDZ HCTA IINovLGLYlHID __ XIMIY ___ P __ PCCOIU'lAWRCXWW::VWRCl:~ HNIY
____ aDf CClI.l_ _CIIIlXGlDYGI.DZ HCTA IINDvI.Ql.YlHID MU'IA _______ PCC08UARWRCX'NRC'IWRCl:FlWD HNIY
_I!!!!I! ___ aDf COLE Gl.DXQU)YGI.DZ HCTA MNoYLGLY lHID ________ PCCOIUM WRCXWW::VWRCZ FlWDHNIY

___ aDf COLI Gl.DXGIDY QLDZ HCTA MNov LGLYLHEI) ______ 1WCl_ PCCO IU'lAWRCX 'NRC'IWRCZFlWDHNIY
IIRNX __ aDfCOUii Gl.DXQU)YGLDZ HCI1'lIlNovLCILYI.HEDMU'IA ___ P~ ___ PCC08UARWRCXWW::VWRCZFlWDHNIY
___ aDfCOLl Gl.DXQU)YGLDZ HC'Il! ~YLClLY I.HEO MUI¥I ___ IWIX ___ PCC08UARWRCX'NRC'IWRCZ FlWDHNIY
___ a.CN CClI.l_ Gl.DXGlDYGI.DZ HCTA MNov I.QI.Y!.HED ______ P __ POCO ..... A WRCX WRCYWRCZFlWD HNIY I

II

i

Issue 0.8

July 10, 1998

Page 72

CDMA RF Optimisation

Teclmology Applications Group

I

CONTItilUATION SHEET: _ OF __

DATE: (VYMMDD)

RUN.:

TEST:

--~----~--------------~------------------------------------~

NUMBER OF DROPPPED CALLS FOR THIS RUN:

NUMBER OF CALL ORIGINATION FOR THIS RUN:

I

NUMBER OF ACCESS FAILURES FOR THIS RUN:

I

I

PROBLEM AREAS: (GIVE CROSS STREETS WHEN POSSIBLE)

I ~ I

Is FURTHER INVESTIGATION REQUIRED: YES No IF YES, WHY?

July 10, 1998

Issue 0.8

Page 73

cnMA RF Optimigtion

Technology Apptications Group

9.2. Importing FDes into Planet

Since a survey loader.specific to the data analysis tool output tile 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. I.) to obtain tiles of the form:

Decimal Latitude, Decimal Longitude, Value ito be displayed.

The separator between the 3 columns can be multiple spacesand/or tabs. File length is not limited by Planet but a maximum of 50 files can be loaded at anyone time (true at release 2.5.12). The tiles 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:

#!lbinlcsh

#Martin Kendall, Nov 95

#Expects to be run from results directory.

#Will create a header file for every file found Using #head_temp as a template

rm .. lheadl* .hd

foreach stile ( * )

echo $sfile

set headfile = $stile".hd" echo $headfile

cp .. lheadlhead_temp .. lheadl$headfile end

Use the "Tools/Surveys" function to load the survey data and "Draw/Signal" to display it. Remember to adjust the cutoff limits.(e.g. when displaying $clIo, 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 -10, a display ap~ars with tWQ rows of th=-yalnes. Moving from left to right~a~~C?~~!~~_!()~~_tJ .. he foll~"Y!!lgJtem~_M>pear.

Issue 0.8

July 14), 1998

Page 74

CDMA RF Optimisation

TechnololY ADDHcations ,Group

First row

PN Offset:

in decimal

Receive State: uses the following codes:

_ ... _-- ... _._. __ .. _-

0: Pilot Channel Acquisition

- ... ,-.,.,.,~.- ... , .. ,,,.--.-~~-.-.~.-,, .... ,., ..• ,,~.---

1: Sync Channel Acquisition

----'''~'''''!!'~

2: Idle

3: Access

4: Traffic Channel

-"" 'O,", .. _,>'_.,~" .. _rr~""~''''' ~

Receive Pow~~:_.. in c.QdeQ...,~, can be tmnslated.b¥:ff>J!¥~eJl~'.Jn!!1JllCi[ t~iwal,

subtracting g~~lr'?w.~~~~~ divide result by.fu!~e, and then subtract 63.25 (800MHz) or 66.25 (19OOMHz). TIlls final resul!!~ .. ~m.

Second row

First value u~~1!EP~ Second value unsupported

Transmit Gain Adjust: in coded hex, can _~_~s!!\.!~4J~y_£0I!Y~m!1g value to decimal and dividi~~ . (a alue of 7F means the transmitter is inactive).

9.4. Sample Rundesc.txt

15-cell "Expanded Trial" at BCTel Run descriptions for date: 960727 General Notes/System Status:

16-Cells on air

BTS/BSC S/W is 2.2 with the following revisions:Integration Lab version 6, selector controller 18A, selector 21, SCI 13, BTS controller 7C CSM 4a, rfc.lip 9, 'MTX05AM

Network survey after bringing up Haney.

Run

S/W Call Configuration ll.oute/Loc Purpose of Run

1. 61 M13 NPG/CKT/7db SURR General Network Survey

1.61 M13 NPG/CKT/7db SURR General Network Survey

MIN

NOl NOl

8580 8598

Note: 8580 performed the long calls. 8598 performed the short calls.

8580 dropped call 152nd X 34th.

N02 N02

8580 8598

NPG/CKT /7 db NPG/CKT/7db

$URR General Network Survey $URR General Network Survey

1. 61 M13 1. 61 M13

Note: 8598 MDM locked up. 2 access failures for 8580.

Issue 0.8

July 10, 1998

Page 75

I I

CDMA RF OptlDJisatiqn

Technology Applications iGroup

QOl QOl

4289

NPG/CKTl7db NPG/CKT/7db

COQ/POCO Gen Network Survey COQ/POCO Gen Network Survey

1. 61 1.61

)113 )113

8568

Note: 4289 drops on Westwood X LHED & Mariner X Hickey.

8568 MDM crashed.

Q02 Q02

4289 8568

COQ/POCO Gen Network Survey COQ/POCO Gen Network Survey

1. 61 1.61

M13 M13

NPG/ CKT 17 db NPG/CKT/7db

Note:

4289 problems on Como Lake Rd: X Wasco & X Seymore & X Barker. Mariner X Woodward.

8568 power cycle->Q03.8586

Q03 Q03

4289 4243

NPG/CKT/7db NPG/CKT/7db

Pit Mdw/Mpl Rdg pit Mdw/Mpl Rdg

Network Survey Network Survey

1. 61 1. 61

M13 M13

Note:

4289 3 drops. 10 access failures. LHED X Indian Res. North on 287.

Poor coverage for entire run, both phQnes.

BOl 8572 1.61 M13 NPG/ CKT /7 db 13RN/NWEST Network Survey
BOl 8574 1.61 M13 NPG/CKT/7db l=!RN/NWEST Network Survey
Note: 8572 power cycle 142 st X 24 av->bl18572.err
B02 8572 1.61 M13 NPG/CKT/7db BRN/NWEST Network Survey
B02 8574 1.61 M13 NPG/CKT/7db BRN/NWEST Network Survey
Note: US West Interference on Marine Drive from Magdalene to Maple St. 9.5. Calculating Required Power Reduc~ion for Unwanted PN

Assume 4 pilots are being received at strengths as follows:

-7dB

-7dB

-10dB

-lldB

and we want to get the last one below T_ADIl> (-14dB). A simple reduction of 3dB will not achieve the required results since the 10 ~uraiso ~Cill.~rn~riJI[fp~lQ_tisJQW~d. A quick way to fmd out the 10 reduction is to assign weightings to the pilots, starting with liq~_!!!:i~_str~1!~t:

-7= 1

-7 = 1

-10 = 0.5

-11 = 0.4

for a grand total of 2.9. When we remove the ilast, we will have an 10 reduction of~.?(~9 = -0.64dB. Therefore, the pilot needs to lowered by 3 + 0.64 = 3.64dB.

Issue 0.8

July lq, 1998

Page 76

Sign up to vote on this title
UsefulNot useful