CDMA RF Performance Analysis & Troubleshooting Guide R28.0 - Final

CDMA 3G-1X
R F P E R F O R M A N C E A N A LY S I S
&
TROUBLESHOOTING
GUIDE
R EL 28.0
RF T OOLS & S ERVICES S YSTEMS

E NGINEERING GROUP
T H I S D O C U M E N T I S F O R A L C AT E L - L U C E N T I N T E R N A L U S E O N LY
D O N O T D I S T R I B U T E O U T S I D E A L C AT E L - L U C E N T
ALCATEL-LUCENT
PROPRIETARY
TA B L E O F C O N T E N T S
0. CHANGE HISTORY.............................................................................................................................. 9
1. INTRODUCTION................................................................................................................................. 15
2. USING THIS GUIDE ........................................................................................................................... 16

2.1 USING THE GUIDE FOR SYSTEM-LEVEL TROUBLESHOOTING AND ANALYSIS ..............17
2.2 USING THE GUIDE FOR TROUBLESHOOTING SPECIFIC CDMA PERFORMANCE
PROBLEMS ................................................................................................................................18
2.3 USING THE GUIDE AS A REFERENCE FOR PRINCIPLES OF KPI PERFORMANCE
MANAGEMENT AND TROUBLESHOOTING ...........................................................................19
3. SUMMARY OF PERFORMANCE RELATED FEATURES IN RELEASE 27 & 28 ................... 20
3.1 RF PERFORMANCE FEATURES IN RELEASE 27..................................................................20
3.2 RF PERFORMANCE FEATURES IN RELEASE 28..................................................................21
3.2.1 Feature Exceptions in Release 28 ............................................................................... 25
4. VOICE AND DATA KPI OPTIMIZATION AND TROUBLESHOOTING .................................. 26
4.1 ESTABLISHED CALL RATE ....................................................................................................27
4.1.1 Established Call (a.k.a. Service Connect Complete Counts), Bad or Invalid ESN
Counts, and other recent Call Establishment Counts............................................................ 27
4.1.2 RF Access Failure (TCCF) Analysis........................................................................... 28
4.1.2.1 Concepts and Optimization Techniques........................................................................ 28
4.1.2.1.1 Initial Cell Selection by Mobile in Idle Mode............................................................ 30
4.1.2.1.2 Access Probe Sequence ............................................................................................. 32
4.1.2.1.3 Channel Assignment Message on Paging Channel ................................................... 32
4.1.2.1.4 Traffic Channel Acquisition by Mobile and Cell....................................................... 38
4.1.2.1.5 Final Handshake to Confirm Service Option and Service Connection...................... 40
4.1.2.2 Silent Reoriginations..................................................................................................... 40
4.1.2.3 Silent Page .................................................................................................................... 41
4.1.2.4 Recent IS95B Enhancements ........................................................................................ 42
4.1.2.4.1 Access Entry Handoff (AEHO) Feature .................................................................... 42
4.1.2.4.2 Access Handoff (AHO) Feature ................................................................................ 43
4.1.2.4.3 Channel Assignment into Soft Handoff (CAMSHO) Feature..................................... 43
4.1.2.5 TCCF Causes and Associated Fixes ............................................................................. 43
4.1.2.5.1 High Traffic Areas..................................................................................................... 44
4.1.2.5.2 Cross-Carrier TCCFs ............................................................................................... 45
4.1.2.5.3 Poorly Defined Neighbor Lists.................................................................................. 51
4.1.2.5.4 Excessive Soft-Handoff Zones ................................................................................... 52
4.1.2.5.5 Lack of RF Coverage ................................................................................................ 54
4.1.2.5.6 Search Window Problems ......................................................................................... 54
4.1.2.5.7 External Interference ................................................................................................ 55
4.1.2.5.8 Co-PN Interference ................................................................................................... 56
4.1.2.5.9 Hardware Goes Into Bad State ................................................................................. 57
4.1.2.5.10 Intermittent Hardware Problems .............................................................................. 58
4.1.2.5.11 CRTU/CTRM TCCFs ................................................................................................ 58
4.1.3 Call Setup Failure Analysis ........................................................................................ 59
4.1.3.2 Commonly Encountered Types of Call Setup Failures ................................................. 60
4.1.3.2.1 Call Shutdown Type 43 (CS-[43])............................................................................. 60
4.1.3.2.2 Call Shutdown Type 10 (CS-[10])............................................................................. 60
CDMA 3G-1X RF P ER FOR MANCE A NALYS IS & T ROUB LESHOOT ING G U IDE
4.1.3.2.3 Speech Handler Failures........................................................................................... 61

4.1.4 CE/PP/Signaling Link Resource Blocking Analysis.................................................... 61
4.1.4.1.1 Conceptual Overview for 2G Cells............................................................................ 62
4.1.4.1.2 3G1X Enhancements & Concepts ............................................................................. 63
4.1.4.1.3 Signaling Link Concepts............................................................................................ 65
4.1.4.1.4 CE/PP Blocking Definition ....................................................................................... 66
4.1.4.1.5 CE/PP Resource Blocking Management Techniques ................................................ 66
4.1.4.2 CE/PP Resource Blocking Causes and Associated Fixes.............................................. 67
4.1.4.2.1 Cell Resource Capacity Reached .............................................................................. 68
4.1.4.2.2 Hardware Outages .................................................................................................... 70
4.1.4.2.3 Intermittent Hardware Problems .............................................................................. 70
4.1.4.3 Signaling Link Overload Causes and Outages, and Associated Fixes .......................... 71
4.1.4.3.1 Signaling Link Overload ........................................................................................... 71
4.1.4.3.2 Hardware Outages .................................................................................................... 72
4.1.4.3.3 Incorrect Provisioning or Inadvertent Changes to Facilities Translations............... 73
4.1.5 Forward Power Resource Blocking Analysis.............................................................. 74
4.1.5.1.1 Conceptual Overview ................................................................................................ 74
4.1.5.1.2 Important Lucent Features and Translations ............................................................ 78
4.1.5.1.3 Forward Power Resource Blocking Management Techniques.................................. 79
4.1.5.2 Forward Power Resource Blocking Causes and Associated Fixes................................ 80
4.1.5.2.1 Sector has reached Capacity Limit............................................................................ 80
4.1.5.2.3 Incorrect Setting of VAF Causes Early Overload ..................................................... 82
4.1.5.2.4 Overload Not Detected on All Carriers of Multi-Carrier Sector............................... 83
4.1.6 Reverse RF Loading Resource Blocking Analysis ...................................................... 86
4.1.6.1.2 Reverse RF Loading Blocking Management Techniques .......................................... 88
4.1.6.2 Reverse RF Loading Resource Blocking Causes and Associated Fixes ....................... 89
4.1.6.2.1 Sector has reached Capacity Limit............................................................................ 89
4.1.6.2.3 Overload Not Detected on All Carriers of Multi-Carrier Sector............................... 91
4.1.6.2.4 External Interference ................................................................................................ 93
4.1.7 Termination Failures Related to Call Delivery Type.................................................. 94
4.1.8 Changes to Call Delivery Types.................................................................................. 95
4.1.9 Termination Failures due to Registration Problems and Paging Strategies .............. 95
4.1.9.1.2 Registration and Paging Strategy Recommendations ............................................... 98
4.2 DROP CALL RATE .................................................................................................................102
4.2.1 Lost Calls .................................................................................................................. 102
4.2.1.1 Concepts and Optimization Techniques...................................................................... 102
Conceptual Overview ................................................................................................................. 102
Optimization Steps for Reducing Lost Calls............................................................................... 104
4.2.1.2 Lost Call Causes and Associated Fixes....................................................................... 106
4.2.1.2.1 Poorly Defined Neighbor Lists................................................................................ 106
4.2.1.2.2 High Traffic Areas................................................................................................... 107
4.2.1.2.3 Significant Areas of Poor Coverage........................................................................ 109
4.2.1.2.4 Island-Mode Cell due to loss of network synchronization....................................... 110
4.2.1.2.5 Island-Mode Cell due to differences in Packet Pipe delays..................................... 111
4.2.1.2.6 Handoff Cell is Blocking on All Carriers ................................................................ 112
4.2.1.2.7 Pilot Polluted Areas ................................................................................................ 113
4.2.1.2.8 Search Window Problems ....................................................................................... 114
4.2.1.2.9 External Interference .............................................................................................. 115
4.2.1.2.10 Co-PN Interference ................................................................................................. 115
4.2.1.2.11 Hardware Outages and/or Intermittent Hardware Problems ................................. 117
A LC ATE L - LUCENT P ROPR IETARY

3
4.2.1.2.12 Incorrectly Optimized New Cell .............................................................................. 117

4.2.1.2.13 Inadvertent Change of Translations........................................................................ 118
4.2.2 CP Fail Drops ........................................................................................................... 119
4.2.2.1.1 General Description................................................................................................ 119
4.2.2.1.2 Inter-Frequency Semi-Soft Handoff Concepts......................................................... 120
4.2.2.1.3 Directed Inter-Frequency Handoffs ........................................................................ 121
Tr_CHo Inter-frequency Handoff Trigger.................................................................................. 121
IFHOTI Inter-frequency Handoff Trigger.................................................................................. 121
Distance Based Inter-frequency Handoff Trigger ...................................................................... 122
3G-1X Mobile Assisted Inter-frequency Handoff ....................................................................... 123
4.2.2.1.4 Pilot Assisted Inter-Frequency Handoffs ................................................................ 124
4.2.2.1.5 3G-1X Return from Handoff Failure....................................................................... 125
4.2.2.1.6 Optimization Steps for Reducing CP Fail Drops .................................................... 126
4.2.2.2 CP Fail Causes and Associated Fixes ......................................................................... 127
4.2.2.2.1 Poorly Optimized Border Sectors............................................................................ 127
4.2.2.2.2 Incorrect Management of Cross-Carrier Assignments on Border Sectors .............. 128
4.2.2.2.3 Drops due to Undesired Hard-Handovers .............................................................. 129
4.3 FCH FRAME ERROR RATE ..................................................................................................131
4.3.1 Concepts and Optimization Techniques.................................................................... 131
4.3.1.1 Forward Frame Error Rate (FFER) ............................................................................. 131
4.3.1.1.1 2G and 3G Radio Configurations............................................................................ 131
4.3.1.1.2 FFER Calculation for 2G RS2 ................................................................................ 132
4.3.1.1.3 FFER Calculation Using PMRM ............................................................................ 133
4.3.1.1.4 FER Reporting Changes for Release 22.................................................................. 134
4.3.1.1.5 Optimization Steps for FFER .................................................................................. 135
4.3.1.2 Reverse Frame Error Rate (RFER) ............................................................................. 135
4.3.1.2.1 RFER Calculation ................................................................................................... 135
4.3.1.2.2 RFER Reporting Changes for Release 21 ............................................................... 136
4.3.1.2.3 RFER Reporting Changes for Release 22 ............................................................... 136
4.3.1.2.4 Optimization Steps for RFER .................................................................................. 137
4.3.1.2.5 Other Poor RFER Causes and Associated Fixes..................................................... 137
5. HIGH SPEED PACKET DATA (HSPD) - SPECIFIC KPI OPTIMIZATION AND
TROUBLESHOOTING ..................................................................................................................... 139
5.1 SUPPLEMENTAL CHANNEL BLOCKING / RATE REDUCTION .........................................145
5.1.1 Blocking / Rate Reduction Due to RF Capacity........................................................ 146
5.1.1.1.1 Overview of SARA ................................................................................................... 146
5.1.1.1.2 Forward Link Optimization Techniques.................................................................. 146
5.1.1.1.3 Reverse Link Optimization Techniques ................................................................... 148
5.1.1.2 RF Capacity Related Failure Causes and Suggested Fixes ......................................... 150
5.1.1.2.1 Excessive Areas Lacking Pilot Dominance ............................................................. 150
5.1.1.2.2 Excessive Pathloss .................................................................................................. 151
5.1.1.2.3 Neighbor List Problems .......................................................................................... 152
5.1.1.2.4 Candidate Sector Resource Blocking ...................................................................... 153
5.1.2 Blocking / Rate Reduction Due to Packet Pipes ....................................................... 154
5.1.2.1.1 Conceptual Overview .............................................................................................. 154
5.1.2.1.2 Important Lucent Features...................................................................................... 155
5.1.2.1.3 Packet Pipe Provisioning Strategies ....................................................................... 155
5.1.2.2 PP Blocking / Rate Reduction Causes and Associated Fixes...................................... 156
5.1.2.2.1 Blocking / Rate Reduction due to Insufficient PP Provisioning .............................. 156
5.1.2.2.2 Blocking / Rate Reduction due to Span Outage....................................................... 157
5.1.3 Blocking / Rate Reduction Due to Channel Fragments ............................................ 158
5.1.3.1.1 Overview of 3G Channel Cards .............................................................................. 158

4
5.1.3.1.2 CF Provisioning Strategies ..................................................................................... 159

5.1.3.1.3 Assigning Calls to Appropriate Channel Cards by Technology .............................. 160
5.1.3.2 CF Blocking / Rate Reduction Failure Causes and Fixes............................................ 161
5.1.3.2.1 Blocking / Rate Reduction because no FCH available............................................ 161
5.1.3.2.2 Blocking / Rate Reduction because no SCH available ............................................ 162
5.1.4 Blocking / Rate Reduction Due to Walsh Codes ....................................................... 163
5.1.4.1.1 Overview of Variable Walsh Spreading Factors ..................................................... 163
5.1.4.1.2 Concept of Walsh Code Blocking ............................................................................ 164
5.1.4.1.3 Walsh Code Optimization Techniques..................................................................... 166
5.1.4.2 Walsh Code Blocking / Rate Reduction Failure Causes and Fixes ............................. 166
5.1.4.2.1 Unavailable Walsh Codes due to Excessive High-Speed Connections.................... 166
5.1.4.2.2 Unavailable Walsh Codes due to Excessive Low-Speed Connections..................... 167
5.1.4.2.3 Unavailable Walsh Codes due to Multiple Paging Channels.................................. 168
5.2 EXCESSIVE ANCHOR TRANSFERS ......................................................................................170
5.2.1 Concepts and Optimization Techniques.................................................................... 170
5.2.1.1 Conceptual Overview.................................................................................................. 170
5.2.1.2 Optimization Techniques ............................................................................................ 170
5.3 3G3G INTER-FREQUENCY HANDOFFS ..........................................................................172
5.3.1 Concept / Reasons for Throughput Degradation ...................................................... 172
5.3.2 Symptoms and Identification Techniques.................................................................. 172
5.3.3 Suggested Fixes for Improvement ............................................................................. 172
5.4 3GNON-3G HANDOFFS ....................................................................................................173
5.4.1 Concept / Reasons for Throughput Degradation ...................................................... 173
5.4.2 Symptoms and Identification Techniques.................................................................. 174
5.4.3 Suggested Fixes for Improvement ............................................................................. 174
5.5 OUTAGES AND ERRORS IN THE PACKET NETWORK OR OTHER CELL SITE HARDWARE
COMPONENTS ........................................................................................................................175
APPENDIX A METRIC CROSS-REFERENCE ............................................................................ 177
APPENDIX B OVERVIEW OF SPO TOOL .................................................................................. 180
APPENDIX C KMS SOLUTIONS CROSS-REFERENCE ........................................................... 190
LIST OF FIGURES
FIGURE A-1 IS95A ORIGINATION CALL FLOW ............................................................................. 30
FIGURE A-2 SEMI-SOFT HANDOFF CALL FLOW .......................................................................... 120
FIGURE A-3 FCH/SCH UTILIZATION FOR TYPICAL WEB BROWSING SESSION .......................... 140
FIGURE A-4 3G1X HIGH SPEED PACKET DATA NETWORK PROTOCOL STACK .......................... 144
FIGURE A-5 RC3 WALSH CODE TREE ......................................................................................... 165
APPENDIX FIGURE 1 EXECUTIVE SUMMARY ............................................................................... 181

APPENDIX FIGURE 2 SM SUMMARY WINDOW AND PEG COUNT DETAILS .................................. 182
APPENDIX FIGURE 3 SM MAP ..................................................................................................... 183
APPENDIX FIGURE 4 SM TREND .................................................................................................. 183
APPENDIX FIGURE 5 ROP SUMMARY .......................................................................................... 184
APPENDIX FIGURE 6 TRX SUMMARY WINDOW .......................................................................... 185
APPENDIX FIGURE 7 MAP OF TRIANGULATED PCMD DROP CALLS ........................................... 186

5
L I S T O F TA B L E S
TABLE A-1 ESTABLISHED CALL RATE METRIC CROSS REFERENCE ................................. 177
TABLE A-2 DROP CALL RATE METRIC CROSS REFERENCE .............................................. 178
TABLE A-3 FRAME ERROR RATE METRIC CROSS REFERENCE ......................................... 178
TABLE A-4 PACKET DATA RATE METRIC CROSS REFERENCE.......................................... 179
TABLE C-1 KMS SOLUTIONS CROSS REFERENCE............................................................. 190

6
List of Abbreviations
AOC Aggregate Overload Control
AR Autonomous Registration
AR Assistance Request
BCCH Broadcast Control Channel
CAM Channel Assignment Message
CBR CDMA Baseband Radio
CCC CDMA Cluster Controller
CCU CDMA Cluster Unit
CDBS CDMA Distributed Base Station
CDM CDMA Digital Module
CDMA Code Division Multiple Access
CDN Call processing Database Node
CE Channel Element
CFS Candidate Frequency Search
CMPIFHO CDMA Multiple Pilots Inter-Frequency Handoff
CMU CDMA Modem Unit
CN Cellular Networking
CRC CDMA Radio Controller
CTA Customer Technical Advocate
CTU Common Timing Unit
DACS Digital Access and Cross Connect Switch
DCS Digital Cellular Switch
DGU Digital Gain Unit
DTX Discontinuous Transmission
ECAM Extended Channel Assignment Message
ECP Executive Cellular Processor
ECU Enhanced Channel Unit
EIB Erasure Indicator Bit
ER Enhanced Registration
ESN Electronic Serial Number
FAF Feature Activation File
FCH Fundamental Channel
F-CCCH Forward Common Control Channel
FEC Forward Error Correction
F-FCH Forward Fundamental Channel
FFER Forward Frame Error Rate
F-SCH Forward Supplemental Channel
HD High Density
HEH Hardware Error Handler
HLR Home Location Register
HSPD High Speed Packet Data
IAOC Improved Aggregate Overload Control
IFHOTI Inter-Frequency Handoff Trigger Improvement
IROC Improved Reverse link Overload Control

7
List of Abbreviations (Cont)

ISPAGE Intersystem Paging
KPI Key Performance Indicator
LDAT Lucent Data Analysis Tool
MCR Multi-Carrier Radio
MEID Mobile Equipment Identifier
MIB Management Information Base
MSC Mobile Switching Center
OMP Operation and Management Platform
OMR Oscillator Module - Rubidium
PCPM Power Control Parameter Message
PDSN Packet Data Serving Node
PMRM Power Measurement Report Message
PN Pseudorandom Noise
PP Packet Pipe
PSMM Pilot Strength Measurement Message
Q-PCH Quick Paging channel, a 3G specific Paging Channel
RCF Release Confirmation Failure
RCS Radio Cluster Server
R-EACH Reverse Enhanced Access Channel
RFER Reverse Frame Error Rate
R-FCH Reverse Fundamental Channel
R-SCH Reverse Supplemental Channel
ROC Reverse link Overload Control
ROP Read-Only Printer
RFU Radio Frequency Unit
TCA Traffic Channel Assignment
TCCF Traffic Channel Confirmation Failure
TFU Timing and Frequency Unit
TLDN Temporary Location Directory Number
SARA Supplemental Channel Air Resource Allocation
SCN Special Cellular Networking
SCH Supplemental Channel
SCCM Service Connect Complete Message
SCRM Supplemental Channel Request Message
SH Speech Handler
SMRG Service Measurement Report Generator
SMV Selectable Mode Vocoder
SMS Short Message Service
SPAT System Performance Analysis Tool
SPO System Performance Optimization Tool (The next generation SPAT3G)
UCR Universal CDMA Radio
UNL Undeclared Neighbor List
URC Universal Radio Controller
VLR Visitor Location Register

8
0. CHANGE HISTORY
Version Changes Date

R18 Initial Release May 2002
R20 Updates reflecting new call processing features, reference web sites and April 2003
SPAT3G information for Release 19 and 20 such as distance base directed
hard handoffs. Changes include an improved explanation on 3G Data
Supplemental Channel rate determination as well as lost call determination
and additional information on island mode cells.
R21 Updates reflecting new call processing features, peg counts and references November 2003
for Release 21. Changes include explanation of the new FER peg counts as
well as Walsh code usage and Service Connect Complete counts; changes to
HSPD features including the 3G-1X HSPD Mobility Improvements Using
Softer Handoff For The Forward Supplemental Channel and 3G-1X HSPD
with Simultaneous Transmission on FCH and SCH (CDMA).
R22 Updates reflecting new call processing features, peg counts and references September 2004
for Release 22. Changes include:
 Updates to the Service Connect Complete Counts (now referred to as Established Call
Counts)
 Added information on the SMS Message Overload Control feature
 Added information on Multiple Access/Paging Channels
 Added information on the new Same Carrier and Cross-Carrier TCCF counts
 Added information on the improved Distance Based Handoffs as well as their peg counts;
 Added information on 3G-1X Mobile Assisted Inter-Frequency Handoffs and 3G-1X
Return from Handoff Failure features
 Added information regarding changes to the FER peg counts
 Added information on the Fast Data Call Setup feature & F-SCH Improved Scheduler
 Added information on effects of additional paging channel in F-SCH performance
 Updated SPAT3G section with new features
 Updated and corrected Appendix A, Metric Cross Reference table
 Corrected references to application notes taking into account new documents
 Added information on and references to the new Release Confirmation Failure peg counts
 Added information on and references to the Voice vs. Packet Data Call Admission
feature
R23 Updates to the acronym list, new call processing features, peg counts and February 2005
references for Release 23. Changes include:
 Updated the List of Abbreviations and the Reference Section
 Added a Link for the CDMA Release Letters
 Added information on the Allocate CDMA Overhead Channels to 2G Cards
 Added information on the Distance Based Origination/Termination
 Updated information on Release 23 and 8 MB RAM CRCs
 Added a reference to the CDMA Release letters
 Included information on the new dgu limit for the ModCell 4.0 platform with UCRs
 Updated and corrected the SPAT3G section with new feature information
 Added information on the CDMA-CS-L peg counts
R24 Updates to the acronym list, new call processing feature, peg counts and August 2005
 A new section covering performance affecting features has been added
 Added the new Lucent Alerts link
 Added information on the 3G-1X Call Admission Policy with System Resource

9
Reservation Based on RF Power Optional Feature Description

 Added information on the enhanced Paging & Access Channel Occupancy peg counts
 Explained changes to the Rate Requested counts for HSPD calls and new information on
the new unauthorized HSPD call attempt counts
 Added information on counts pegging 3G HSPD calls blocked due to lack of resources
 Added information on counts pegging the average dgu for forward voice and data traffic
channels
 Added information on counts pegging Origination/Termination call attempts diverted to
co-located cells due to various reasons
 Added information on recent Lucent Alerts and a link to the Lucent Support Extranet
R25 Updates to the acronym list, new call processing features, peg counts and March 2006
 Updated section covering performance affecting features for Release 25 and 26
 Added information on the Priority Paging and Adaptive Paging features
 Added information on the 3G CE Reservation for 3G Hand-offs feature
 Added information on some of the new Service Measurements for Capacity and
Performance Management including those used for CCU/CMU monitoring
 Updated the SPAT3G section with information from the latest release.
 Added information on the effect of the Customer Critical Translations Maintenance -
Phase 1 in the maximum dgu limit for Flexent sites with UCRs/MCRs, the F-SARA and
R-SAR algorithms and the Adaptive RSSI Noise Floor Algorithm for IROC.
 Added information on the two new handoff escalation parameters.
 Added information on the new parameter for simultaneous data transmission on F-SCH
and F-FCH.
 Added information on the discontinuation of Lucent proprietary call delivery methods
and references for ISPAGE.
 Added information on recent hardware issues as documented in Lucent Alerts.
 Updated KMS Solutions Cross-Reference table with recent performance troubleshooting
tickets.
 Added information on the Cross-Band Load Balancing feature
R26 Updates to the acronym list, new call processing features, peg counts and August 2006
 Updated section covering features for Release 26 and 27
 Added information on the Increase Neighbor List to 40 on Traffic & Paging Channel
feature
 Added information on the new Paging Channel Overhead Message Broadcast Rate
parameter and its possible use for managing paging channel occupancy
 Added information on the Enhanced Reverse Link Monitoring - Service Measurements
feature, and related new service measurements and parameters, including the new
Number of Audits Sent to Mobile Before Call Release parameter
 Added information on the CDMA SM Enhancements - Phase 7 feature, including some
of the abandoned termination counts and TLDN timeout counts
 Added information on the Four-to-Six (4-6) Sector Configuration for Flexent ModCell
4.0's feature
 Added information on the Subscriber Access Control (CCLM/ECCLM) - Phase II feature
and how it may be used to modify the list of carriers used for mobile hashing
 Added information on the 3G CE Reservation for 3G Packet Data Call Setup feature
 Updated information on the use of Auxiliary Cell and Sector Control parameters
 Added information on the CDMA Handoff Matrix (HOM) Tool Improvements feature
tickets
R27 Updates to the acronym list, new call processing features, peg counts and December 2006

10
 Changed Lucent entries to Alcatel-Lucent where relevant

 Updated section covering features for Release 27 and 28
 Updated Metric Cross-Reference table to include new Established Calls calculation using
pegs and Carrier Imbalance metrics
 Added references to RF Power Calibration for CDMA Base stations
 Added information on the new “CE Provisioning Fragmentation with the CMU-IVB”
feature which affects call setup
 Added information on a Peak CE usage problem for CDMs using URC-II controllers
 Added information on the move of Origination and Termination Failure counts due to
DCS Errors from the ECP-PAF-CARR-CDMA section to the ECP-PAF-CARR-CDMA-
SC section
 Added information on the new silent reorigination counts introduced in Release 27
 Added information on the new Primary transfers for soft, softer and semi-soft handoffs
peg counts
 Added information on the 3G CDMA Origination / Termination Overflows with
Handoff/SO33 Reserved Channels Available peg count as it affects CE assignment
 Added information on Resolved CARES tickets for release 27, including MAIFHO
handoff trigger issues; Cell reboots caused by changes to Signaling Link Parameters;
Inconsistencies between Abandoned Termination counts and the Page Response Seizure
and Assignment counts; and Problems with re-enabling overhead channels after DS1
recoveries
tickets
R28  Updated section 3.2 with following features in Release R28: October 2007
o 6 Access Channels Per Paging Channel
o Inter-band Idle Mode Load Balancing
o Increase of Number of Carriers Supported in CGSA
o SUA Support for Sending CDMA and 1xEV-DO Cell Software From the AP
to Cells and Restarting
o CDMA BTS 2400
o Enhanced treatment of Unauthorized Packet Data Calls Handled by the 3G 1X
RNC
o Support for multiple non-contiguous TLDN Blocks
o Dual Band (Cellular/PCS) IA Modular Cell 4.0B for Single Band PCS
Configurations
o Ethernet backhaul for both CDMA and EVDO for Modcell 1.0/2.0/3.0/4.0
o Packet Data Dormant Handoff Optimization
 Added a section 3.2.1 for feature exceptions in R28
 Added a new section 3.3.2.3 Silent page to indicate changes in metrics
for R28 due to this peg counts
 Added information about the Call Setup failure peg count
modification and the effect on RF Failure rate metrics (section 3.3.3.1)
 Updated SPAT3G section with new SPO information

11
References
[1] 401-610-009 System Capacity Monitoring & Engineering (SCME) Guide
[2] CDMA RF Translation Application Notes – Introduction
[3] CDMA RF Translation Application Note #1 – Forward Link Transmit Path
[4] CDMA RF Translation Application Note #1F – Flexent Forward Link Transmit Path
[5] CDMA RF Translation Application Note 2F: Forward Link Overload Control and
Supplemental Air Resource Allocation
[6] CDMA RF Translation Application Note 2R: Reverse Link Overload Control and
Supplemental Air Resource Allocation
[7] CDMA RF Translation Application Note #3V – Voice Power Control
[8] CDMA RF Translation Application Note #3D – Data Power Control
[9] CDMA RF Translation Application Note #4 – Handoff
[10] CDMA RF Translation Application Note #4D – 3G1X Data Handoff
[11] CDMA RF Translation Application Note #7 – Timing, Delay and Access Parameters
[12] CDMA RF Translation Application Note #11 – Miscellaneous Topics, September 2003
[13] 401-612-221 CDMA Packet Pipe Optimization and Packet Pipe 16
[14] 401-612-429 Backhaul Engineering Enhancement
[15] SRD-1536 CDMA Performance and Capacity Metrics
[16] Experiences with SS7 Message Reduction, Registration Control and Paging Version 2.0, M. Dal
Pan, J.D. Newell, December 21, 2000.
[17] CDMA 3G Packet Data – 3G Overview, David A. Welsh, Wireless Development –
CDMA/3G Packet Data, February 2002
[18] Troubleshooting guide for Packet Data
[19] 3G1X RF Optimization Guidelines,
http://rfcoresupport.wh.lucent.com/RFCoreSupportWebPage/guidelines.htm
[20] Multi-Carrier Optimization Guidelines for PCS and Cellular CDMA Systems,
http://rfcoresupport.wh.lucent.com/RFCoreSupportWebPage/guidelines.htm
[21] SRD-1996 CDMA Performance and Capacity Metrics for Packet Data – R19, Issue 3.0
[22] 401-610-055/057 Input/Output Message Manual
[23] 401-610-135 Service Measurements Manual
[24] 401-601-009 Autonomous & Enhanced Registration
[25] 401-612-009 Subscriber Pre-Page Announcement (do we need this, see text for
comments)
[26] 401-610-036 Database Update Manual
[27] CL3725 RF Engineering, Capacity and Growth Engineering of CDMA Systems
[28] ARD-0189 AMPS/PCS 3G-1X Packet Data Architecture, 3G-1X Cell Site Architecture
Document
[29] 3G1x High Speed Packet Data Performance Expectations - Release 21 and earlier

12
[30] 401-612-717 Distance Based Hand-Off and Origination/Termination Optional Feature

Description
[31] 401-612-716 3G-1X Mobile Assisted Interfrequency Handoff (Hard and Semi-soft) &
3G-1X Return from Hand-off Failure (Hard and Semi-soft)
[32] 401-612-392 CDMA Short Message Service (SMS)
[33] 401-612-700 3G-1X High Speed Data with Improved Scheduling: Dynamic F-SCH Rate
[34] 401-612-590 CDMA Multiple Access Channel Support per Paging Channel
[35] 401-612-559 CDMA Multiple Paging/Access Channels per Carrier/Sector
[36] 401-612-574 Voice vs. Data Call Admission Optional Feature Description
[37] 401-612-388 3G-1X Data Features Optional Feature Description
[38] 401-612-745 Allocate CDMA Overhead Channels (Pilot, Sync, Paging, Access) on 2G
Channel Cards Optional Feature Description
[39] 401-612-755 3G-1X Call Admission Policy with System Resource Reservation Based on
RF Power Optional Feature Description
[40] 401-612-798 Priority Paging Optional Feature Description
[41] 401-612-791 Adaptive Paging and Related Features Optional Feature Description
[42] 401-612-784 3G CE Reservation for 3G Hand-offs Optional Feature Description
[43] 401-612-346 ANSI-41 Enhanced TIA Call Delivery with ISPAGE Optional Feature
Description
[44] 401-612-759 Co-located Intra-band Load Balancing and Related Features
[45] 401-710-102 Radio Cluster Server and Flexent Mobility Manager Radio Cluster Server
[46] 401-612-140 CDMA Handoff Matrix and Related Features Optional Feature
Description Feature IDs 2062.0, 3185.0, and 12172.0
[47] 401-703-437 CDMA RF Power Calibration Manual for Modcell/Compact 4.0/4.0B, and
BTSs 4400/8401/8420
[48] 407-703-438 CDMA RF Power Calibration Manual for HD Modcell 4.0/4.0B
[49] 407-703-439 CDMA RF Power Calibration Manual for Modcell 1.0/2.0/3.0, Microcell,
and CDBS
Useful Web Pages

APXLibrary: http://nwswww.ih.lucent.com/˜apxlib/
Ask Lucent: http://asklucent.web.lucent.com/
Assert Database: http://ctso.lucent.com/asserts/
Database & RCV Pages: http://nwswww.ih.lucent.com/˜db-home/
Knowledge Store: http://servility.ih.lucent.com/msstpi/
Lucent Alerts (Legacy): http://mss.web.lucent.com/bulflash/bulflash.html
Lucent Alerts (New): http://olcs.web.lucent.com/alerts/
Lucent Navigator: http://navigator.web.lucent.com/
Wireless Service
Creation & Performance: http://rfcoresupport.wh.lucent.com/
Saba Training (IP&T) https://training.lucent.com/SabaWeb/

13
Cares Tickets (ARs) http://cares.web.lucent.com/

CDMA Release Letters http://nwswww.wh.lucent.com/˜cdma-ce/RL/
Lucent Support Extranet https://wireless.support.lucent.com/

14
1. INTRODUCTION
The CDMA Performance Analysis Guide has been put together to facilitate the system
performance maintenance, analysis and troubleshooting of IS95A/B and IS2000 CDMA
networks. The purpose of this guide is to not only provide information on the various CDMA
performance degradation causes and troubleshooting techniques, but also to provide a conceptual
overview of all the key performance metrics and their associated optimization guidelines. This
guide is primarily intended for Customer Technical Advocates (CTAs) and RF Performance
Engineers.
One of the most important points to realize is that there are a vast number of diverse reasons why
CDMA systems may exhibit problems. For example, parts of the system may not operate
optimally for any combination of the following reasons:
 Base station hardware failures (including intermittent problems)

 Poor RF environment
 Sub-optimal cell site location / antenna placement
 Translations entry errors or accidental changes
 Translations requiring optimization
 Core network problems (capacity overflows, hardware failures, incorrect
provisioning etc.)
 Incorrect antenna assembly
 Cell site capacity limitations
 Improper RF optimization
While this list is not exhaustive, it demonstrates clearly the breadth of issues that could affect
CDMA systems. It is therefore imperative that the CDMA engineer follows a disciplined process
of proactive maintenance and reacts efficiently and effectively to real-time system performance
degradations.
In order to do this, the engineer must first have a fundamental understanding of all the Key
Performance Indicators (KPIs) that will best characterize the performance of the network. Upon
understanding these KPIs, the engineer must know the key proactive optimization steps to take to
maximize their performance. Finally, the engineer should be aware of potential causes of
degradation in the performance of these KPIs and know the solutions to improve or fix these
problems.
This Guide addresses all of these aspects in detail. Section 2 on Using This Guide provides a
series of strategies on how to best use this Guide to tackle a variety of CDMA performance
management and troubleshooting scenarios. It is strongly recommended that this section be read
before attempting to use this document.

15
2. USING THIS GUIDE
This Guide was written to provide the engineers with effective documentation that will
complement various performance analysis tools (such as SPAT, WatchMark Prospect etc.) by
providing the necessary structure and details to troubleshoot and resolve CDMA network
problems.
To that effect, this Guide may be used for any combination of the following:
 To perform system-wide CDMA network performance management where a large

selection of cells are collectively optimized for various key performance indicators.
Such type of performance management may typically be required for activities such as
system audits or to baseline the performance of markets upon initial entry by Alcatel-
Lucent.
 To perform troubleshooting, analysis and resolution of specific CDMA network
performance problems, as indicated through service measurements and other switch-
based features and reports.
These specific problem analysis requirements may typically result from open customer
tickets or ARs or if Alcatel-Lucent support is called in (contracted) to resolve specific
customer issues.
 To act as a reference guide for the various principles and theory associated with the
performance of the various Key Performance Indicators (KPIs).
The details on how this Guide may be used to address each of these requirements are described in
the sections below.
This version of the CDMA 3G-1X RF Performance Analysis & Troubleshooting Guide only
reflects troubleshooting for Lucent CDMA equipment. While some references of the document
have been updated to reflect the newly created Alcatel-Lucent, most of the references to the
hardware and software are still to Lucent or Lucent Technologies hardware or software. These
references will be updated in future versions of this document as their nomenclature is updated.

16
2.1 Using the Guide for System-Level Troubleshooting and Analysis

As described above, this type of system-wide troubleshooting and analysis is typically done
during system audits (either periodic or one-time) or when engineers who are new to their
markets need to establish a baseline by “cleaning up” the performance.
The approach adopted in this Guide is to first characterize the system performance as being
comprised of a series of Key Performance Indicators (KPIs). Section 4 lists all the KPIs that are
common to Voice and Data services, while Section 5 lists the additional KPIs that are specific
only to Data performance. Given the relatively recent release of support for packet data services
through the IS2000 standard, a brief overview of Lucent’s implementation of High Speed Packet
Data (HSPD) is also provided in Section 5. This overview will provide the necessary background
to understand the rest of the detailed discussions on Data-specific KPIs listed in this section.
With these KPIs defined, the strategy to perform system-level troubleshooting and analysis then
is as follows:
1) Know the list of all possible failure components that could result in degradations in the
performance of these KPIs.
This is listed in Sections 4 and 5 under each of the KPI sections.
2) Understand the fundamental concepts behind why each of these failure components
may occur and proactive optimization strategies to ensure optimal performance is
attained for each of these components.
These concepts and proactive optimization steps are described in Sections 4 and 5 under
each of the failure components of each KPI.
3) Understand all of the possible failure causes for each of these KPI failure components,
the concepts and reasons for these failures, symptoms and identification techniques to
isolate these failure causes, and suggestions for resolving these failures.
Each of these failure causes must then be tested to see whether they are occurring on
any of the cells in the system using the appropriate identification techniques, and
subsequently should be resolved by employing the suggested fixes.
These detailed discussions on the failure causes for each of the KPI failure components
are also discussed in Sections 4 and 5.
Note that, when performing such system-level audits or performance management, it is

recommended that this effort be preceded by a translations scrub to check every important RF
translation parameter against Lucent recommendations. Any deviations from these
recommendations must either be corrected or documented if such deviations were intentionally
set.
This Guide will not delve into a detailed discussion on translations and their associated
recommended values because this topic is already discussed very effectively and in great detail in
[2], with cross-references to other translation application notes that describe related concepts to
each of these translations.

17
2.2 Using the Guide for Troubleshooting Specific CDMA Performance

Problems
This section describes how this Guide may be used to resolve a very specific performance issue in
a CDMA network. This may typically occur in response to customer trouble tickets, or when
Lucent has been contracted by the customer to tackle a particular issue.
The steps needed to efficiently and effectively handle such performance problems are listed
below. The method in which this Guide may be used to complement this process is also detailed
in these steps.
1) Clearly define the problem. Often, the true problem is not characterized accurately
because of possible misrepresentations as this problem is communicated through multiple
people. Alternatively, this could also result because of a lack of detailed analysis of the
problem due to insufficient information or know-how.
This Guide does not delve into the subject of problem characterization. However, it is
necessary that the problem be ultimately narrowed down to one or more failing
performance metrics in order to effectively use this document to resolve the problem at
hand.
The SPAT tool defines metrics as per Lucent Systems Engineering requirements, and will
therefore be used as a reference for all the RF performance metrics. This tool is described
in Appendix B while a list of SPAT metrics is provided in Appendix A.
2) List all possible failure root causes that could result in the problem currently being
investigated.
This is achieved in the Guide through the cross-reference provided in Appendix A. This
appendix lists all of the sections that are related to each SPAT metric. This list will
therefore serve as a cross-reference for all possible root causes for these metrics.
3) Isolate the root cause of the problem by understanding all of the symptoms associated
with each of the possible causes, and testing them against the current problem under
investigation.
Each of the sections in the Guide that correspond to the possible causes for the degraded
KPI performance will have in them a description of the symptoms of that particular
cause, along with identification techniques to isolate that cause. These identification
techniques need to be employed for each of the sections listed in the cross-reference in
Appendix A to narrow down to the root cause of the problem.
4) Fix the problem once the root cause is determined. Note that it may not always be
possible to implement the fix immediately. For instance, the root cause might require an
additional site as the appropriate fix, which could take several months.
Again, each of the sections in the Guide that correspond to possible root causes for the
degraded KPI performance will have in them a discussion on suggested fixes for that
particular root cause.

18
2.3 Using the Guide as a Reference for Principles of KPI Performance

Management and Troubleshooting
This Guide may also be used as educational material, without the need to resolve any actual
performance issue. This is because a significant portion of the material is dedicated to explaining
the concepts behind the various Key Performance Indicators (KPIs). In addition, the Guide
discusses in detail the description, identification and resolution of root causes of problems that
could result in KPI performance degradations.
Section 4 lists all the Key Performance Indicators (KPIs) that are common to Voice and Data,
while Section 5 lists the additional KPIs that are specific only to Data performance. Included in
Section 5 is some necessary background concepts required to understand the Data-specific KPIs
listed in this section. A list of possible failure components that constitute failures in KPI
performance are also listed in these sections.
Sections 4 and 5 go on to discuss each of the KPI failure components in detail. First, the concept
behind these failure components is discussed. Subsequently, proactive optimization steps are
listed to ensure optimal performance of these components. Finally, these sections describe all of
the possible failure causes that could result in performance degradation in each of the failure
components, along with identification techniques and suggestions for fixes.

19
3. SUMMARY OF PERFORMANCE RELATED FEATURES IN

RELEASE 27 & 28
This section provides a high level list of RF performance-impacting features scheduled for
Releases 27 & 28. Detailed information on these features can be found in the appropriate Release
or Planning letter. Additional information may be found in Lucent’s Knowledge store.
3.1 RF Performance Features in Release 27

These are the RF performance-impacting features found in Release 271. They are included as
reference information and to aid in troubleshooting planning.
 FID 4610.11 - CDMA SM Enhancements - Phase 8: This feature provides new

service measurements that provide new or additional information about the following
events:
o SMS Termination Layer 3 Acknowledgements for CPAGE SMS

o Unauthorized 2G Packet Data Attempts from a 3G Mobile
o Incoming Primary Leg Transfers
o Inter-MSC ANSI-41 Hard Handoffs
o Negative Acknowledgements for CPAGE and CTRAF SMS
o SM Changes to Support PM Enhancements
 Silent Re-originations with Traffic Channel Confirmation Failures
 Overflow with Handoff/SO33 Reserved Channels Available
 Modification to existing counts
 FID 10378.6 - CE Provisioning Fragmentation with the CMU-IVB: This feature

allows the provisioning of Channel Elements (CEs) for Flexent ModCell 4.0 products
with CMU-IVB in chunks of 32 CEs. An improved FAF activation of CEs that will
enable the usage of CE chunks on a per cell basis and tracking of the CE usage for each
cell at the ECP is required. This is a pay-as-you-grow feature that allows the purchase
Channel Elements (CEs) in chunks of 32 CEs for Flexent ModCell 4.0 products equipped
with CMU-IVB Modems. Channel Element purchases are controlled by QFAF and
activated on a board basis as equipped via RC/V translations parameters for each CMU-
IVB. Access is restricted to the total number of CEs purchased as defined by the FAF file
entry. CE purchase can be tracked for each Cell. Important: This feature requires all
CMU-IVB modems installed in the Network to be provisioned for CE activation.
Incorrectly provisioned boards will fail initialization and will be placed out of service.
This includes all CMU-IVBs that were previously operating with pre-R27.0 ECP and
Cell loads. All of those boards must now be provisioned via RCV translations.
 FID 11020.0 - Flexible Routine Diagnostics Enhancements: This feature modifies the
current Routine Diagnostics (RTDIAG) scheme. Currently BTS RTDIAG can only be
set to run once a day. This feature introduces the capability to also schedule RTDIAG for
particular day(s) of the week and day(s) of month. ModCell 4.0 circuit packs have higher
1
Not all Release 27 features are listed, only those affecting RF performance and troubleshooting capabilities.

20
density than in other BTS platforms. When there is only one radio per sector configured
in a ModCell 4.0, when radios are taken out of service for diagnostics, customers
perceive higher blocked call rates. As a result, this feature also introduces the option to
disable “Radio Diagnostics” from Routine Diagnostics. A new inventory control
parameter is also introduced with this feature to allow the user to schedule inventory
control at a particular time of day.
 FID 12179.2 - Customer-Critical Translations Maintenance - Phase 3: This feature is

the continuation of 12179.1 in the previous release. Additional maintenance work has
been done for the temporary translations. This feature provides maintenance for
“Temporary Use” (also referred to as spare) translations used in the system in previous
releases. The temporary use translations are generally implemented to control certain
functionality related to new features in the field. These translations are used for quick
turn-around to support critical requests from customers and to support short-term
performance studies. Under this feature certain temporary use translations from selected
previous releases have been reviewed and transitioned as appropriate. The temporary
translations have been made permanent with this feature. This feature also provides
retrofit scripts for migrating the settings of temporary translations to either the new
standard translation or hard coded value as applicable. Any change to the settings of these
“Temporary Translations” that are done after the ECP Release 27.0 retrofit will not be
automatically migrated to the new translations and so will not be used by any R27.0 or
later cells. IMPORTANT: It is recommended that if the old translations are changed on
an R27.0 ECP (which should only need to be done to impact pre-R27 cells), then the new
translations should also be set at the same time, in order to reduce problems when later
upgrading cells to R27.00.
3.2 RF Performance Features in Release 28

These are the RF performance-impacting feature found in Release 282. They are included as
reference information and to aid in troubleshooting planning.
 FID 4417.6 - 3G1X PCMD Enhancements - Phase 4: This standard feature updates the
Per Call Measurements Data (PCMD) feature and introduces the following fields:
o Radio Link Protocol (RLP) bytes transmitted and retransmitted: These fields are
used to measure the performance of the RLP during High Speed Packet Data
(HSPD) calls. The RLP counts are under the control of a new FAF.
o Additional ‘Call Setup’ Time Stamps: These fields improve call setup
performance analysis.
o New Call Final Class/Call Final Class Qualifiers (CFC/CFCQs) include the
following:
o A CFCQ to identify a call that was not answered because the terminating mobile
was inactive (and therefore not paged).
o A CFCQ to identify a call to an inactive mobile and the terminating MSC does
not attempt to page the mobile.
2
Not all Release 28 features are listed, only those affecting RF performance and troubleshooting capabilities.

21
o Pilot Strength Measurement Message (PSMM) Data for SMS calls on Access and
Paging Channels
 FID 8920.10 - 5Estrip support for Release 28.0: This standard feature adds 5Estrip
support for additional 5ESS TRFC report sections.
 FID 10438.5 – Performance Metrics and SM Report Generator (SMRG) Updates

Phase 6: This standard feature enhances the Lucent-recommended Performance Metrics
for voice, data, and 1xEV-DO to include new and changed R28.0 features and functions.
It also enhances the Lucent provided SMRG templates (cdma.t and ctrig.t) to report on
the new and changed voice and data performance metrics, including updates to the call
attempts formulas and to critical triggers. This feature ensures that Vallent Prospect for
Lucent, SCME (401-610-009), and SMRG are all consistently using the Performance
Metrics.
 FID 10818.1 - ANSI-41 Hard Handoff During Origination: This optional feature is
designed to perform the handoff on a mobile-originated call while waiting for the called
subscriber to answer. This capability improves the call success rate.
 FID 12431.1 - Inter-system Paging for SMS: This feature introduces a capability to
perform intersystem paging for SMS termination to a mobile in a border system. This
enhancement improves the page response rate for SMS Short Message/Text Delivery.
This feature uses an existing ANSI-41 message, ISPAGE2, between the anchor and
border MSC, for paging for SMS for a mobile in border system. Once the MS is located
in the border MSC, the anchor MSC sends payload/bearer to the border MSC using a new
ANSI-41 message, ISSMDPP.
 FID 2064.5 - Six (6) Access Channels per Paging Channel: This optional feature
supports simultaneous use of two Paging Channels (FIDs 2064.0 and 2064.1), while
supporting up to six Access Channels per each of the two Paging Channels. This brings
maximum Access Channel capacity to 12 per sector per carrier, when two Paging
Channels are deployed per sector per carrier. This feature is mutually exclusive with
feature FID 2063.1, which supports two Access Channels per Paging Channel. Currently
two Access Channels are supported per Paging Channel (FID 2063.1) per sector per
carrier. This feature (2064.5) increases the number of Access Channels supported per
paging channel from two to six per sector per carrier.
With 2 Access Channels per sector per carrier customers still are experiencing high
Access Channel occupancy resulting in overload in number of markets. CDMA Access
performance is one of the major criteria used by the service providers to evaluate how
well a CDMA system performs in the field. The percentage of access success rate (or
failure rate) over time is a strong indication of the network performance.
 FID 12896.0 – Boomer Capability for Modular Cell 4.0, Modular Cell 4.0 HD,
Compact 4.0 and BTS 4400 using 2PAMs: This feature addresses software
development to allow for the use of the 2PAMs (C2PAMs and P2PAMs) in applications
that require the Cell (Modular Cell 4.0, HD 4.0, Compact 4.0) to transmit up to three dB
higher than the standard TX output power. Applications include:
o The use of the 2PAM in 33W applications, needed to support the Autoplex to
Flexent migration of the HD no later than CY 2008 allowing for the

22
paralleling of three 2PAMs to increase the maximum output power from

20W to 33W and would be used with the MCR.
o Expansion of the PCS footprint using P2PAMs to be equal to that of Cellular
in the same Cell site. This feature would require the use of TTLNAs.
 FID 10361.2 - Increase of Number of Carriers Supported in CGSA: This feature

allows for up to 33 carriers to be equipped in the Cellular Geographical System Area
(CGSA) form. It expands carrier range from 1-18 to 1-33 on CGSA form. This increase
allows for a single CGSA form to be used for a single SID, in those cases where one SID
may contain a large number of carriers.
o This feature is only supported on NGN AP and requires OMP FX v2.

o Note: Co-located Modcell (with SII) cannot be supported with carriers 19-33
on any release. Pre-28.00 software generics do not support carriers 19-33.
 FID 2064.6 - Inter-band Idle Mode Load Balancing: This feature provides a
mechanism to redirect idle mobiles from one band class to another when the source band
class is more heavily loaded than the other band class in dual band deployments. Dual
band deployments are done via dual band cells or co-located cells or overlaid cells.
Enhancements to dual band environments help new mobiles. This feature provides a
solution to improve the performance of dual band deployments by balancing the
distribution of idle eligible dual band mobiles across both band classes for current/legacy
mobiles.
o Load balancing is done based on paging channel occupancy and RF loading

on a location area wide (cluster of cells) basis for each band class. When the
loading on one band class exceeds an activation threshold while the loading
on the second band class is below an acceptance threshold, a percentage of
eligible dual band mobiles that registered on the first band class is redirected
to paging channels on the second band class. Criteria for eligible mobiles for
redirection include mobile type, supported band classes, and time of last
redirection.
o RC/V controls are provided for customers to set desired thresholds for
mobile re-direction. Also control to turn this feature on and off for each cell,
sector and band class is provided.
o Service Measurements to track number of eligible 1x dual-band mobiles
redirected to the other band are provided to enable customers to monitor the
performance of this feature.
o Impacted SMs are: ECP-PAF-CARR 25, 26, 27 and ECP-LA-BC 1
 FID 12089.2 – SUA Support for Sending CDMA and 1xEV-DO Cell Software From
the AP to Cells and Restarting: This feature will provide SUA support for the actual
sending of the cell software from the RCS-AP and the RNC-AP down to the cell sites.
This feature will also provide SUA support for generating a RCS restart from the FMM-
AP that will result in a reboot of both the CDMA and 1xEV-DO portions of the cell and
cause the cell to come up on the newly downloaded cell software. This feature includes any
SUA GUI/LUI work needed to support the send and restart activities. This feature does
not cover GNP-APs or series II cells or microcells.

23
o This feature covers CDMA cells in a single frame, CDMA cells in multiple
frames, and converged CDMA and 1xEV-DO cells.
o This feature only supports sending and restarting of software at the cell level
and does not support sending and restarting of software for individual
components of a cell
o This feature also includes an interface between SUA and RCS (MRA) that
will provide SUA with status information on cells after the restart. This
information will provide a summary of status of the CDMs at the cell site.
FID 13019.0 – CDMA BTS 2400: The CDMA BTS 2400 is a new base station targeted for Hole
Filling and In-building applications. Its characteristics are as follows:
o Small form factor with Volume of less than 120 liters and weight of less than
60 Kg
o Support for 3G1x & 1xEV-DO
o 1 Sector
o Multi-carrier
o RF power: mW to 32 W(PCS) or 40 W (850)
o 2 Channel card slots (for 1x and/or 1xEV-DO)
o Frequency Band: PCS and 850 in R28
o Power options include AC, 24V DC and -48V DC
FID13192.0 - Enhanced treatment of Unauthorized Packet Data Calls Handled by the 3G

1X RNC: This feature provides new SMs to:
o Measure call attempts that either had missing profiles or ‘no-service’ defined
in VLR
o Measure 2G packet data calls in a system not equipped to handle packet data
calls at the FPS
FID 92940.0 - Support for multiple non-contiguous TLDN Blocks: This feature will benefit
Service providers who have several markets where they need more TLDNs but do not have large
enough contiguous blocks. It provides the ability to provision multiple non-contiguous blocks of
TLDNs for Call delivery. New category of SM pegs “TLDNBLK” have been introduced
indicating different states of TLDNs.
FID 8859.13 / 8859.15 – Dual Band (Cellular/PCS) IA Modular Cell 4.0B for Single Band
PCS Configurations: Addresses a Dual-Band Cell equipped with 2 Cellular/PCS Modular Cell
4.0Bs (1 cabinet for each frequency band), operating on 1 RCS instance and capable of
supporting IA.With this feature Intelligent Antenna (IA) can be enabled on a per sector per
assemblage basis.
FID 12267.0 / .1 - Ethernet backhaul for both CDMA and EVDO for Modcell
1.0/2.0/3.0/4.0: This feature basically Provide Ethernet interface for Modcell 1.0/2.0/3.0/4 for
CDMA and EVDO. 10/100 BaseT is supported as Ethernet interface at the BTS. Existing
CDMA-SUBCELL/CRC/URC peg count category has been modified with 5 newly added pegs
for backhaul facility type, downlink and uplink average as well as peak throughput rates.
FID 10689.2 / 7098.18 - Packet Data Dormant Handoff Optimization: This feature eliminates
the traffic channel setup for dormant handoffs. This allows the PCF and PDSN bindings to be
updated without setting up the traffic channel. DHOO assigns traffic channels only when Data

24
Ready to Send. Four new peg counts have been introduced in existing CDMA-CS (88-91)
category for Packet data origination messages.
3.2.1 Feature Exceptions in Release 28
This section identifies any features originally planned for release 28 that are not being
delivered at the time of General Availability.
o FID 10665.15 – Two MLGs Support In 3G1X URC
o FID 12393.0 – Compact 4.0, BTS 4400 support for TTLNAs
o FID 12896.0 – High Transmit Power Support

25
4. VOICE AND DATA KPI OPTIMIZATION AND

TROUBLESHOOTING
Voice Key Performance Indicators (KPIs) refer to a small collection of metrics that best represent
the entire user experience with the quality of a cellular voice network. In essence, the customer
perception of this network will be driven by the following factors:
1) How easy and fast is it to access the network and make a call? Similarly, how reliably
and promptly is the customer able to receive calls?
2) How good is the quality of the call during the call?
3) How often are the calling parties able to gracefully end the call themselves, as opposed to
the network “dropping” their call prematurely?
These three factors lead to three Key Performance Indicators (KPIs), as will be elaborated upon in
this section. These three KPIs are:
1) Established Call Rate
2) Frame Error Rate
3) Drop Call Rate
With Data calls, as explained in Section 5, a Fundamental Channel (FCH) is established and
maintained throughout the duration of the call. This FCH is set up and torn down in exactly the
same way as the Traffic Channel (TCH) during a Voice call. Also, the Data FCH can be torn
down (dropped) for all the same reasons as why Voice calls on an FCH can be dropped.
Therefore, all of the principles discussed with these three KPIs will apply equally to the “quality”
of the Data connection. Of course, with Data, any degradation in this quality will just translate to
throughput problems, due to delays in channel establishment, undue frame errors during data
transfer and undesired periods of zero transfer resulting from dropped calls.
In addition to the FCH, the Data call may also establish an additional channel called the
Supplemental Channel (SCH) to provide the necessary bandwidth for high-speed data transfers.
The KPIs related to the performance of the network through these SCHs (which only pertain to
Data calls) are discussed in Section 5.
This section provides a detailed conceptual overview of each of these Voice and Data KPIs, as
well as optimization techniques and guidelines to maximize their performance. It goes on to
discuss potential causes for failures in these KPIs along with suggestions for improvements and
fixes. Finally and where applicable, new upcoming features that will help in improving the KPI
performance are discussed.

26
4.1 Established Call Rate

This performance indicator measures the percentage of originating and terminating call attempts
that are successfully established. This is one of the most critical performance indicators as it is the
best measure of customer-perceived call blocking.
The high-level equation for established call rate may be represented as follows:
(Orig. Seiz.  Orig. Failures)  (Term. Seiz.  Term. Failures)

Establishe d Call Rate  x 100%
Orig. Seiz.  Term. Seiz.
SRD-1536 [15] provides a detailed description of the peg counts and equations used to determine
this KPI.
There are several categories of failures that contribute to degradations in the established call rate
metric, namely:
 RF Access Failures (TCCFs)

 Call Setup Failures
 CE/PP Resource Blocking
 Forward Power Resource Blocking
 Reverse RF Loading Resource Blocking
 Call Delivery Type Related Termination Failures
 Registration Related Termination Failures
 Other Miscellaneous Failures Component
The following sections examine failure causes and fixes/improvements for each of these
categories in detail.
The only category that will not be discussed in detail in this document is the last category – Other
Miscellaneous Failures Component. These encompass several other failures that typically occur
much less frequently in CDMA networks. An example would be failures due to no Speech
Handler (SH) assignment received at the cell. While these failures will not be discussed in great
detail in this document, the Lucent support center should be contacted if these failures become a
significant contributor to established call failures.
4.1.1 Established Call (a.k.a. Service Connect Complete Counts), Bad

or Invalid ESN Counts, and other recent Call Establishment
Counts
While the description of the Established Call Rate Formula shown in Section 4.1 is simple, the
actual formula is quite complicated. To calculate the number of established calls requires more
than a dozen individual peg counts. For ECP/Cell Release 21 a new set of peg counts called
Service Connect Completions were introduced which simplify the calculation of established calls.

27
These peg counts report the number of Service Connect Complete instances for 2G as well as 3G
calls, voice and data, originations and terminations, and SMS calls.
The service connect complete counts peg the number of times a cell site received a Service
Connect Complete Message from mobile stations, indicating successful call setup. See Figure A-1
for information on when the service connect complete message happens in the call processing
flow. While these counts were introduced as experimental in release 21.0, they became finalized
in release 21.1 and were renamed Established Call Counts While these new peg counts simplify
the calculation of established calls, their use has been limited due to their recent introduction.
For Release 24 a new set of peg counts tracking originations and terminations by mobiles with
bad or invalid ESNs have been added. These new peg counts, in the ECP-PAF-CARR-SC
section, count the number of origination or termination seizures that come from mobiles with bad
or invalid ESNs. These counts affect the numerator and denominator of the Established Call Rate
KPI and thus need tracking. See [23] and the Release 24 letter for more information. After
Release 24 was deployed it was noticed that the Bad ESN counts might be inaccurate and produce
erroneous results when used in the Established Call Rate KPI. Please consult the following ARs:
1-1263298 and 1-1289837 for more information.
For Release 27 a new peg count, ECP-PAF-CARR CDMA 29, was added which counts the
number of Unauthorized 2G Packet Data Originations from 3G Mobiles. This count complements
some of the other Unauthorized HSPD data counts introduced in Release 24; see Section 5, SCH
Rate Determination sub-section for more information.
Additionally, for Release 27, several Origination and Termination Failure counts due to DCS
Errors were moved from the ECP-PAF-CARR CDMA section to the ECP-PAF-CARR-SC
CDMA section (a total of four counts, ECP-PAF-CARR-SC-CDMA 50 to 53: one for 2G
Origination Failures, one for2G Termination Failures, one for 3G Origination Failures, and one
for 3G Termination Failures). See the Release 27 release letter and [23] for more information as
these counts replace counts in the ECP-PAF-CARR-CDMA section. Any established call metric
using these counts should be updated for Release 27 to properly capture these failures.
4.1.2 RF Access Failure (TCCF) Analysis
4.1.2.1 Concepts and Optimization Techniques
A Traffic Channel Confirmation Failure (TCCF) is generated when a cell site fails to receive the
Service Connect Complete Message (SCCM) upon issuing a Channel Assignment Message (CAM)
or Extended Channel Assignment Message (ECAM). A TCCF may occur either on a mobile-
originated attempt or a termination attempt, whereby the mobile receives a call.
It is important to note that this type of failure can only happen after channel assignment implying
that the base station had the hardware resources to support the call.
The failures may be further broken down into Origination Traffic Channel Confirmation Failures
(O-TCCFs), for mobile-originating calls, Termination Traffic Channel Confirmation Failures (T-
TCCFs), for mobile-terminating calls, and Alert Confirmation Failures, also for mobile-
terminating calls.

28
During the call setup process, there is a sequence of messages that are communicated between the
cell and the mobile. Depending on which point during this message transfer the failure occurs, a
different type of TCCF will be recorded on the ROP (see Figure A-1). However, all these failures
are bundled under a single TCCF counter in service measurements.
TCCFs are normally associated with poor RF conditions, thus, the TCCF rate is also commonly
referred to as the RF Access Failure Rate. However, as will be seen in this section, there may be
other hardware-related failures that may also result in TCCFs.
The call setup process for IS95A systems may be categorized into the following stages:
1. Initial Cell Selection by Mobile in Idle Mode
2. Access Probe Sequence on Access Channel
3. Acknowledgement by Cell on Paging Channel
4. Channel Assignment Message on Paging Channel
5. Traffic Channel Acquisition by Mobile and Cell
6. Final Handshake to Confirm Service Option and Service Connection

An example call flow is presented in the following figure that describes the call processing that
occurs for a mobile-origination. The stages at which the various common ROP TCCF messages
are generated are also indicated in this figure.

29
MS Cell Site CDN DCS
Origination Message on Access Channel
Base Station Ack on Paging Channel
Cell Origination
Cell Null Traffic Data
Origination Acknowledgement
Channel Assignment on Paging Channel
Mobile Traffic Preamble on Acquiring TC1 TCCF Type 2

Base Station Ack on Traffic Channel2 Speech Handler Request TCCF Type 1
Mobile Ack on Traffic Channel
Mobile Null Traffic Speech Handler Assignment
Frame Selector Assignment
Null Traffic
Null Traffic
Service Connect Message on Traffic Chan
Service Connect Complete on Traffic Chan TCCF Type 3
Channel Confirmation
1 Mobile acquires traffic channel when it detects N 5m (typically 2) good null traffic frames within T 50m seconds (typically 200/1000ms = 10-50 frames)
2 Mobile has T 51m seconds to receive Base Station Acknowledgement Order (typically 2 sec)
TCCF Type 2 - Aquire Mobile Failure (Mobile fails to receive N 5m good frames , or Cell Site fails to receive Mobile Traffic Preamble.)
TCCF Type 1 - Layer 2 Acknowledgement Failure (Cell Site fails to receive acknowlegement for Base Station Acknowledgement Order)
TCCF Type 3 - Service Connect Complete Failure (Cell Site fails to receive Service Connect Complete Message from Mobile)
FIGURE A-1 IS95A ORIGINATION CALL FLOW1

Although a TCCF can only happen after channel assignment, the previous stages may also create
adverse conditions that will eventually lead to TCCFs. Therefore, each of these stages is
described below, along with how they may affect TCCFs and optimization steps to take to
maximize the performance.
The IS95B enhancements to the call setup standards are subsequently discussed.
4.1.2.1.1 Initial Cell Selection by Mobile in Idle Mode
General Description
When in the idle mode, the mobile constantly monitors the paging channel on the pilot that it is
camped on. In addition, it compares the strength of the current pilot with all other available pilots.

30
When the mobile finds another PN of sufficiently greater strength, it will perform an idle-mode
handoff3. Subsequently, it will start monitoring this new paging channel and the process repeats.
The mobile follows a particular sequence when searching for other pilots, which is determined by
the neighbor list sent to it on the paging channel of the sector that it is currently on. The mobile
will scan the pilots on the neighbor list with much greater frequency than the rest of the pilots,
which belong to the Remaining Set.
Therefore, in order to ensure that the mobile is always camped on the most ideal pilot for an area,
it is imperative that the neighbor list provided to the mobile is accurate and complete. This is
because, in IS95A systems, once the setup process has begun, the mobile will remain on the same
pilot in simplex mode for the duration of the call setup process.
Optimization Steps for Initial Cell Selection Stage
 Ensure that the Paging Channel Neighbor List Selection (pgcl_nlsel) translation
parameter in the ecp/ceqface database form is set to 20. Prior to Release 14.0, only 12
neighbors could be sent to the mobile in idle mode even though 20 neighbors could
be entered for that sector to be used during calls. With Release 14.0 and greater, the
limit for the number of neighbors in idle mode was extended to 20, but the default
translation will still be 12 unless explicitly changed. With Release 26.0 and greater,
the limit for the number of neighbors in idle mode was further extended to 40. This
increased number of neighbor list entries requires that the Forty NGBR parameter in
the cell form, and the Expanded (40) Neighbor Lists Enable in the fci forms be
enabled, and that the additional neighbor list entries be entered in the Alternate
Neighbor List 2 in the fci form. Additionally, the Maximum Neighbor List Number
Sent To Mobile and the Paging Channel Neighbor List Selection in the ceqface/ecp
forms may need to be updated. See [11] for more information. Care must be taken
when using this parameter, as increasing the neighbor list size may increase paging
channel occupancy, see Section 4.1.9.1.2 for more information.
 Ensure neighbor lists are accurate and complete. Some of the important
characteristics of a good neighbor list are:
 They should satisfy reciprocity. That is, if sector A is in sector B’s neighbor list, then
sector B should also be in sector A’s neighbor list. It is very rare that non-reciprocity
can be justified in CDMA systems because of the fact that all cells are transmitting at
the same frequency. Therefore, if one sector is strong enough to be neighbored with
another, then the converse, by definition, will also be true. The FCIAlert tool will
help verify reciprocity (Appendix B).
 The neighbor lists should capture all potential valid neighbors and be prioritized
correctly. The Handoff (HO) Matrix and Undeclared Neighbor List (UNL) tools will
help greatly in ensuring that this is achieved (Appendix B), assuming there is
sufficient call volume to make these tools statistically valid.
3
The IS98 standard only mandates that this idle-handoff be performed at least when the candidate pilot is 3 dB stronger
than the current active one. The actual algorithm and thresholds used to perform these idle-handoffs are left up to the
equipment vendor, as long as these minimum requirements are met.

31
The HO Matrix tool logs all handoff activity that actually took place in the network
and is a useful tool to prioritize neighbors and delete unused neighbors. The UNL4
tool may be used to add missing neighbors as it captures strong pilots that could not
be added to the Active Set because they were not part of the neighbor list. Though
these pilots are captured in the call state, the neighbor list additions will apply to the
idle state also.
When using the UNL feature, it is often more effective to first use service
measurements to narrow down and focus on the sectors exhibiting the most severe
UNL problems (as a proportion of their total traffic). Tools such as SPAT (Appendix
B) may be used to easily arrive at this list of affected sectors.
 There should be no PN ambiguities in the neighbor list. The FCIAlert tool can be
used to check for this (see Appendix B for details on the tool and this condition).
4.1.2.1.2 Access Probe Sequence
The mobile goes into the access probe sequence stage either when it receives a page from the
base station, for terminating calls, or when the user hits the Send button, for originating calls.
The mobile selects an initial power to transmit the first probe based on the received signal
strength and some adjustment factors. The mobile subsequently ramps up the power on
successive probe attempts for every unacknowledged probe.
The purpose of the access probe parameters is to minimize the power transmitted, while
maximizing the access success rate and minimizing the access delay. The access probe
parameters should be set according to Lucent recommended values (as listed in [2] and [11]).
4.1.2.1.3 Channel Assignment Message on Paging Channel
General Description
Assuming the cell has hardware and power resources to support the access attempt, it will send
out a Channel Assignment Message (CAM) on the paging channel. Otherwise, it will send a re-
order and a TCCF will not result. The channel assignment message will tell the mobile to use a
particular Walsh code and it may direct the mobile to another 1.25 MHz carrier.
A cross-carrier assignment results when the mobile is assigned to a carrier other than that which it
was idle on. Otherwise, the assignment is known as a same-carrier assignment. It is important to
distinguish between the two cases because cross-carrier TCCFs normally result when there is a
mismatch in coverage between the carrier the mobile was idle on and the carrier the mobile was
assigned to. The concepts behind channel assignments are discussed in detail below.
4
Several steps must be followed to enable UNL: 1) The FAF feature 547 must be activated. 2) The Undeclared
Neighbor List (unl) translation must be set to y on all sectors of interest on the ceqface form, or switch-wide on the ecp
form. 3) The Search Window Size: Remaining Set (srchwinr) translation in the ceqface form must be changed from its
recommended value of zero to 7 or greater (preferably at least 9 to ensure all distant interferers are captured).

32
Channel Assignment Concepts
All mobiles execute a hashing algorithm to select the frequency to camp on, an algorithm that is
understood by the network. This algorithm uses the mobile IMSI to hash onto one of the
frequencies listed in the Channel List Message (CLM) that is sent by the base stations over the
Paging channel to all idle mobiles on their sectors. When the mobile needs to make a call attempt,
all communication over the Access and Paging channels will be on this hashed frequency.
When it comes time for the channel assignment by the network, the network first examines the
Carrier Assignment Algorithm (tca_alg) in the ecp/ceqface database forms of the sector serving
the call setup. There are three possible choices for the algorithm:
1) Originating Carrier (oc) that always attempts to assign the channel on the hashed
frequency, regardless of the traffic distribution across the carriers of that sector. Note that
cross-carrier assignments may still occur with this oc algorithm if the hashed carrier does
not have the resources to serve the call.
2) RF Loading (rf) that attempts to distribute the traffic evenly across carriers, permitting
some amount of imbalance to favor same-carrier assignments. The preference is to assign
the call to the hashed frequency but the call will be assigned to any other frequency that
is experiencing traffic loads that are less than RF Loading Weight Factor percentage of
its own traffic load, RF Loading Weight Factor (tca_weight) being a translatable
parameter in the ecp/ceqface database form.
3) CCC Loading (cc) that distributes the traffic according to the percentage of CCC
utilization across the various carriers. As with rf loading, all calls are given preference to
remain on the carrier that they hashed on, but in the case of cc loading, calls may be
assigned to another carrier that has a lower CCC utilization. This option is rarely used.
There is a special modification to the hashing algorithm when the mobile is camped on a border
sector. In this case, the mobile is instructed to hash only onto one of the common carriers. This is
achieved by the border sectors removing the border carriers from the CLM, thus forcing the
mobiles to hash only onto the common carriers. This feature is known as the Omit Border Carrier
from Channel List Message feature. This feature is automatically activated without any
additional translations if the internal border carrier is configured for directed inter-frequency
CDMA-to-CDMA handoff.
There is an important reason for having this feature. Border sectors will typically have much
larger coverage footprints on their border carriers because of the reduced interference on these
carriers. Therefore, if the mobiles do hash onto and set up calls on these carriers, then there is a
high chance of dropped calls when handdowns are triggered onto its common carriers that do not
have coverage in these border carrier overshoot areas. There is also a high probability of a failed
origination or termination attempt due to high path loss (that is, the mobile locks onto a PN at the
cell/sector edge).
There are two important algorithms introduced with 3G services that could also result in cross-
carrier assignments. They are the Allow Sharing 3G1X Carrier (share_3g1x) translation in the
ceqface3g database form and the 2G/3G Load Preference Deltas (ld_prf_dlta_2g/3g1x) in the
ceqface3g database form. The former affects the frequency list used by the mobiles to hash over,
and the latter is a modification to the carrier assignment algorithm used by the network to
ultimately assign a frequency to a call.

33
3G mobiles will only hash onto 3G carriers and 2G/3G1X mixed carriers (see Section 5.1.3.1 for
descriptions on how these carriers are defined). Similarly, 2G mobiles will only hash onto 2G and
2G/3G1X carriers. However, if the Allow Sharing 3G1X Carrier is enabled on a 3G carrier, then
2G mobiles are also allowed to hash onto the 3G carriers.
The reason for having this translation is to allow the flexibility to both segregate 2G and 3G calls
entirely onto their own carriers, or to allow at least the 2G mobiles to hash across all carriers,
regardless of technology. The latter is the preferred approach with early 3G deployments, since it
is unlikely that there will be enough 3G traffic to require dedicating an entire carrier to 3G calls,
even if this carrier is populated completely with 3G cards.
In such a scenario, if the Allow Sharing 3G1X Carrier is not enabled, then 2G mobiles will never
hash onto these 3G carriers, but will likely have many assignments to these carriers if rf load
balancing is turned on (since there will be typically lower traffic on these carriers due to lack of
3G traffic). Therefore, there will be an undue number of cross-carrier assignments (depending on
2G/3G load preference delta settings), greatly increasing the risk of cross-carrier TCCFs.
Additionally, if an existing 2G carrier was converted to support 3G without enabling this sharing,
then this will increase the loading on the 2G Paging/Access channels as fewer carriers are now
accommodating 2G load.
The 2G Load Preference Delta (ld_prf_dlta_2g) and 3G Load Preference Delta

(ld_prf_dlta_3g1x) translations serve to bias the RF Loading Weight Factor (tca_weight in the
ecp/ceqface forms) in such a way that it favors the 2G calls to get assigned to 2G carriers, and 3G
calls to 3G carriers. If a 3G mobile hashes onto a 2G carrier, then the loading on all other 3G
carriers on that sector are lowered by the 3G Load Preference Delta in order to make them more
attractive for assignment to this 3G call. If that 3G call hashes onto a 3G carrier, then this 3G
Load Preference Delta gets applied to itself, making it more attractive for the 3G call to stay on
that same 3G carrier5. The same logic applies to the 2G Load Preference Deltas.
This concept is best explained with an example. Say that a cell is configured with two carriers,
the first (F1) being a 2G/3G1X mixed carrier with current RF loading at 50%, and the second
(F2) being a 3G-only carrier with current RF loading at 25%. Also assume that the RF Loading
Weight Factor is set to 20%, 2G Load Preference Delta is set to 30%, 3G Load Preference Delta
is set to 40% and Allow Sharing 3G1X Carrier is set to y on all carriers.
Based on this configuration, the following scenarios describe various examples of how these
translations get applied to determine the assigned carrier.
Scenario 1: 2G mobile originates on F1
In this case, for the purposes of the carrier assignment algorithm, F1 Loading = 50-20-30 = 0
(20% RF Loading Weight Factor since this is the originating carrier, and 30% 2G Load
Preference Delta since this carrier has 2G) and F2 Loading = 25 (2G Load Preference Delta will
not get applied for this carrier since it is 3G-only). Therefore, the call will be assigned to F1, even
though it is carrying significantly more traffic.
5
Note that if there is more than one 3G carrier on that sector, then the 3G Load Preference Delta gets equally applied to
all of these 3G carriers, making it still possible for cross-carrier assignments to occur.

34
In this case, F1 Loading = 50-30 = 20 and F2 Loading = 25-20 = 5. Therefore, the call will be
assigned to F2. Here, the 2G delta is not large enough to overcome the load factor and the fact
that F2 is carrying much less traffic.
In this case, F1 Loading = 50-20-40 = -10 and F2 Loading = 25-40=-15. Therefore, the call will
be assigned to F2. Note that the 3G deltas cancel out since both carriers support 3G, leaving only
the load factor to decide the outcome.
It can be seen therefore that there can be significant cross-carrier assignments if these translations
are not populated correctly. The current recommendation is that the Allow Sharing 3G1X Carrier
is enabled on all carriers, regardless of technology. Furthermore, the 2G Load Preference Deltas
should be set to zero, and the 3G Load Preference Deltas should be set to a high value, for
example, 40. These recommendations are consistent with the expectation that the overwhelming
percentage of mobiles currently in the market is 2G mobiles. These recommendations must be
revisited as the 3G penetration increases.
The assignment algorithms may be configured for all the cells in the system via the ecp form and
overridden on a sector-by-sector basis on the ceqface/ceqface3g form. A detailed explanation of
this topic is in [11]. This reference should be required reading before making any decisions and
optimization based on these algorithms.
Recent Modifications to the Channel Assignment Process
As of Release 19, new parameters were introduced to better control voice vs. data call admission
as part of the “Voice vs. Packet Data Call Admission” feature. Carriers may be set to accept only
voice calls, only packet data calls, apportion the carrier between voice and packet data calls, and
accept all calls. This is done using parameters including Carrier Usage, Maximum Amount of 3G
Fundamental Equivalent Usage, Voice vs. Packet Data Usage Percentage, Firs-come First Serve
Percentage and Supplemental Channel Percentage (all on the ceqface form), and 3G Allowed
Carrier (on the cgsa and cell2 forms). Additionally, this feature requires the “Voice vs. Packet
Data Call Admission” entry in the system’s FAF file.
This feature also introduced several new peg counts to determine the number of originations,
terminations, or handoffs denied due to voice vs. data apportioning. This feature does not affect
Markov calls. Additionally, voice and data call handoffs are treated differently depending on the
target cell configuration. For more information see [36].
Since Release 20, ModCell 4.0 cells have been used in co-located partnerships with other cells.
This co-located partnership further changes the traffic channel assignment (TCA) algorithms.
These changes to the TCA algorithms are not covered in this guide due to the complexity and
variety of these partnerships. Please refer to [11] for more information. For Release 24 peg counts
showing origination and termination attempts diverted to co-located cells have been added. These
counts break down the reason for the diversion (RF balancing, CE overflow, packet pike and
Walsh code blockage), as well as the attempt’s technology (2G vs. 3G). See [23] and the Release
24 letter for more information.

35
Additionally, cell co-location may cause other channel assignment issues depending on its
configuration and Release. For example, prior to Release 23, the Channel List Message was being
improperly constructed when one cell had all carriers as non-border carriers and the partner cell
as border carriers. The border carriers were still included in the Channel List Message causing
problems during channel assignment. See Lucent Alert 05−0228 for more information.
For Release 23 a new feature called “Distance Based Origination/Termination” was introduced
which further modifies the call assignment algorithm. Before this feature, it was possible for calls
to get assigned to border carriers (even if they had smaller values for RF Loading Weight factors)
as the system tried to load balance calls, even in areas outside the optimal coverage and hand
down regions. This could increase the cross carrier TCCF rate and the drop call rate by assigning
calls on areas of marginal coverage and triggering hand downs in non-optimized areas.
With this feature enabled (the feature requires a FAF entry), border carriers are not considered for
traffic channel assignment if mobiles are outside a translatable outer distance threshold. Border
carriers will only be considered for channel assignment when a co-located partner cell is not
available and all carriers have exceeded the specified outer distance threshold (Outer Orig/Term
Distance Threshold on the ceqface form).
This feature can be used to let cross-carrier assignments occur as long as they happen within a
certain distance from a cell and at a certain signal level. Additionally, this feature may be used
with border and non-border carriers to better control call assignment.
The “Distance Based Origination/Termination” feature works by biasing the RF Loading Weight
Factors of the seized and border carriers if the following conditions are met:
 The Inner Origination/Termination Distance Threshold or Inner Ec/Io Threshold (both on

the ceqface form) are not disabled (set to “OFF” in RC/V).
 When the Inner Origination/Termination Distance Threshold is not disabled (set to “OFF”
in RC/V) and the distance between the mobile station and the serving sector does not
exceed the specified Inner Origination/Termination Distance Threshold.
 When the Inner Ec/Io Threshold is not disabled (set to “OFF” in RC/V), the Ec/Io
reported in the origination/termination messages exceeds the specified Inner Ec/Io
Threshold.
 If the Inner Ec/Io Threshold is not disabled (set to “OFF” in RC/V) and the mobile is
IS95A only, then the Ec/Io threshold does not apply. For IS95A mobiles, if an inner
distance threshold is provisioned (not “OFF”), only the inner distance threshold is
checked.
If these conditions are met, the RF Loading Weight Factor for the seized carrier may be lowered
enough to make it the same value as the border carrier, increasing call assignments to the border
carrier. The Inner Ec/Io Threshold determines when a Close-In Factor (on the ceqface form)
parameter may be used to further decrease or increase the RF Loading Weight Factor (effectively
the Close-In Factor is multiplied to the RF Loading Weight Factor).
The distance unit (miles or kilometers) used by the Outer Orig/Term Distance Threshold and the
Inner Orig/Term Distance Threshold is determined by the Border Sector Distance Threshold
Units (on the ecp form, the same parameter used by the Distance Based Handoff feature).

36
Additionally, this feature only works if the Carrier Assignment Algorithm (tca_alg) in the
ecp/ceqface is set to rf.
There are some feature interactions for cells using the “Distance Based Origination/Termination”
feature and the Load Shedding Capability feature. See [30] and [11] for more information as well
as the Release 23 release letter.
For Release 24, a new Flexent-only feature called “3G-1X Call Admission Policy With System
Resource Reservation Based On RF Power” is available. This feature uses RF Power as the
determining resource parameter to be used for voice or packet data call admission. When used,
this new feature takes precedence over the “Voice vs. Data Call Admission” introduced in
Release 19 and it allows users to reserve a percentage of RF power for use by voice or data F-
FCHs. In other words, this new feature is independent of and mutually exclusive with the “Voice
vs. Data Call Admission” feature.
The “3G-1X Call Admission Policy With System Resource Reservation Based On RF Power”
introduces the Voice vs. Packet Data Call Admission Method (vdadmeth parameter in the cell2
form). This parameter determines whether FCH or RF Power is used as the call admission-
determining factor.
The RF power resource reservation may be done at the carrier level and additional service
measurements have been added to help optimize this feature’s settings. See [39] as well as the
Release 24 release letter for more information. Some of the new peg counts in the CDMA-PAF-
CARR section keep track of the Peak Power for the Fundamental Channels for Voice and Data
and the Maximum Allowed RF Power Usage on Voice and Data Call Admission Apportioned,
see [23] for more information on these new peg counts.
For Release 25, the new Cross-Band Load Balancing feature further adds possible modifications
to the channel assignment process. The feature provides load balancing among all carriers across
band classes 0 and 1 (1900 MHz/850 MHz bands). The load-balancing algorithm evaluates all
available voice carriers across the two bands for voice calls and all available data carriers across
the two bands for data calls. The algorithm also considers CE, packet pipe, and Walsh code
resource availability of each carrier. Cross-band load balancing is provided within a stand-alone
dual band cell at call set up and at semi-soft handoff. This also happens when the dual band cell is
in a co-located partnership and is the accessed cell in the call setup.
This feature requires a FAF entry and is enabled by setting several translations in the ceqface
form. See [44] for more information. Additionally, new service measurements used to keep track
of cross band channel assignments on originations and terminations have been added to the
CDMA-PAF-CARR-SC section.
For Release 26, a new feature called “Subscriber Access Control (CCLM/ECCLM) - Phase II”
allows engineers to modify the CDMA Channel List Message (CCLM) and Enhanced CDMA
Channel List Message (ECCLM), thus controlling the carriers which appear in these messages.
Access to certain carriers may be modified by controlling what carriers appear in these messages.
In addition, non-Lucent carriers may be added to these messages, and carriers may be repeated as
well. Mobile hashing into a particular carrier may be biased by having repeated entries of this
carrier. This is used for instances where a cell site has an uneven hardware distribution (for
example, some carriers having more CEs than others).

37
This feature requires a FAF entry and is enabled on a per-cell or per-ECP basis using the
Subscriber Access Control Phase II Switch in the cell2 and ecpcdma forms. There are other
parameters in the cell2, ceqface and cgsa forms that may need to be set for this feature to be fully
utilized. See the Release 26 release letter and [26] for more information.
Optimization Steps for Channel Assignment on Paging Channel Stage
The primary optimization step in this stage is to take appropriate steps to minimize cross-carrier
TCCFs. This can be done in one of two ways:
 Configure the various parameters discussed in the previous section to minimize cross-
carrier assignments to begin with. Without cross-carrier assignments, there will be no
chance for cross-carrier TCCFs.
 If cross-carrier assignments do occur, then minimize the failures that result from these
assignments.
The topic of cross-carrier TCCFs is discussed in detail in Section 4.1.2.5.2.
4.1.2.1.4 Traffic Channel Acquisition by Mobile and Cell
General Description
It is at this stage that the bulk of the TCCFs will occur. After the mobile receives the channel
assignment message, it is instructed to tune to that traffic channel6 and acquire the null traffic data
that is sent by the cell. Upon successful acquisition7, the mobile sends a Traffic Channel
Preamble, which must be acknowledged by the cell to complete this stage.
Any failure in this cycle will result in a TCCF (which is represented as either a TCCF Type 2 or
Type 1 in the ROP – see Figure A-1). Typically, 80% of the TCCFs are of Type 2. Given below
are some possible failure scenarios:
1) The base station transmits the null traffic on the traffic channel with a predefined power
level, Nominal Traffic Channel Gain (nom_gain), which is entered in translations. If the
power is not sufficient to overcome the RF interference levels at that moment, then the
mobile will fail to acquire the traffic channel with sufficient quality and a TCCF will
result. The nom_gain translation can be set ecp-wide on the ecp form and overridden on a
sector-by-sector basis on the ceqface form.
2) The pilot that the mobile initially started the call setup process on is no longer the
dominant pilot in the area. However, the IS95A standard mandates that this pilot be
maintained for the duration of the setup. Therefore, the strong interference created by the
unused pilot could cause TCCFs. Note that a pilot could lose dominance for any of the
following reasons:
6
In CDMA systems, a traffic channel is a combination of a carrier frequency and Walsh Code.
7
Mobile acquires traffic channel when it detects N5m (typically 2) good null traffic frames within T50m seconds
(typically 200ms/1000ms, that is, 10/50 frames).

38
 It was never the ideal pilot to begin with (neighbor list problems).
 The mobile is in a soft-handoff area with two or more pilots ‘ping-ponging’ in their
dominance.
 Distant interferers are overshooting into the area inconsistently.
3) High traffic loads and/or pilot pollution in the area cause the interference levels to be too
high. This results in the inability of the traffic and/or paging channels to overcome this
interference level, causing a communication breakdown on either or both links, resulting
in a TCCF.
4) High path loss causes the pilot, and correspondingly the traffic, paging and access
channels, to be too weak to support the call. This could be inside buildings or in areas not
well covered through the RF design for that market.
Optimization Steps for Traffic Channel Acquisition Stage
 The setting for the nom_gain parameter is key for TCCF performance. If it is set too
low, the mobile will have trouble acquiring the traffic channel and abort the access
attempt. If it is set too high, it will have a negative impact on the capacity of the
sector and the system in general because of the unnecessary rise in interference
caused. The Lucent recommendations should be entered for this parameter and only
optimized as needed on a sector-by-sector basis. The SPAT tool provides tools to
audit all the cell translations (Appendix B).
 Reduce excessive soft-handoff zones in the system. This is generally not an easy task
because the balance has to be drawn between having sufficient soft-handoff zones for
seamless handoffs and not having too much, as this will affect TCCF performance
and system capacity. The only options for reducing the soft-handoff zones will be
through antenna configuration modifications (model, tilt, azimuth etc.) and/or
through attenuation (BCR/CBR) changes. Note that changing t_add and t_drop is not
an option for idle mode and call setup performance because these parameters are not
used at this stage.
 There must be a general discipline to reduce overshooting sectors throughout the
network. They have a profound effect, not just on TCCFs, but also on drop call and
FER performance.
For mature systems, the UNL8 feature is a good place to start to get a list of
overshooting sectors. The HO Matrix tool will also provide insights to the sector
coverage. Alternatively, the footprint of the sectors may be mapped out based on
drive test data, though this is usually a more costly and time-consuming exercise.
The techniques to fix or manage these overshooting sectors are the same as those
used for reducing soft-handoff zones, namely, through physical antenna and
attenuation changes.
8

39
 Highly loaded sectors should be brought under control, especially if significant

TCCF performance degradations are observed during the busy hours when the Erlang
utilizations are high. The techniques to manage overloaded sectors are discussed in
Section 4.1.5.1.
 Pilot polluted areas should be identified and eliminated (as much as possible),
especially if it is observed that there are performance degradations in these areas.
While it is difficult to directly identify pilot polluted areas through service
measurements, peg counts aid in this respect. These counts include three pegs that
measure the number of pilots above t_add with a full active set and three peg counts
that measure the number of pilots above t_comp also with a full active set. Pilot
polluted areas can be identified through drive tests, either with a scanner or with a
mobile phone. The techniques used to reduce these pilot polluted areas will be the
same as those used to reduce soft-handoff zones, namely, through physical antenna
and attenuation changes.
4.1.2.1.5 Final Handshake to Confirm Service Option and Service Connection
General Description
TCCFs may result because of a failure during final service negotiation. If the mobile is directed to
a service option that it does not support, a TCCF Type 7 (Service Negotiation Failure) will be
logged in the ROP (See Figure A-1).
TCCFs may also result anytime during this entire stage before the Service Connect Complete
Message (SCCM) is received by the cell because of RF link problems (TCCF Type 3 on the
ROP). However, the number of TCCFs at this stage should be significantly less than that for the
Traffic Channel Acquisition Stage above. This is because the fact that the traffic channel was
successfully acquired would already have minimized the likelihood of, or even eliminated, many
of the key TCCF reasons, and that call is allowed to enter into SHO before SCM/SCCM
exchange.
Optimization Steps for Final Handshake Stage
The main optimization step is to confirm that there are no problems with service option
negotiations by verifying that an excessive number of Type 7 TCCFs is not occurring on the ROP
using filtering tools such as SPAT (Appendix B). If there is a large number of this type of TCCF,
then this normally implies an error in how the service options were configured at the switch.
Contact Lucent or the Service Provider’s Operations team to resolve this issue.
As far as TCCFs of Type 3 are concerned, all of the suggestions listed for the Traffic Channel
Acquisition Stage will also help reduce TCCFs at this stage. There are no special optimization
steps for this type of TCCF.
4.1.2.2 Silent Reoriginations
Silent reorigination was a concept introduced in the mobiles to help reduce the high customer-
perceived access failure rates that was typical with IS95A networks. The mobiles will

40
autonomously reoriginate calls that failed in their access attempt without user intervention. This is
akin to an automatic redial on failures.
It is important to note that no intervention is required from the network end to activate this
feature. This is an inherent feature in the mobile phones. There are however service
measurements to track occurrences of these silent reoriginations. This is done through inference.
An origination attempt is deemed to be a “silent reorigination” if exactly the same number is
dialed by the same calling party within a pre-defined period of time that is set in translations.
The feature to track these silent reoriginations needs to be turned on in translations by setting the
CDMA Silent Reorigination Feature Enabled (sro_enabled) in the ecp form to y. The associated
timer may also be set in the ecp form by setting the CDMA Silent Reorigination Time Difference
Value (sro_time_diff). This setting is usually set to 10 seconds.
These silent reorigination counts must be discounted from the origination seizures otherwise there
will be multiple seizures pegged for the same origination attempt, driving the access failure rate
artificially higher.
It is also possible for the assignments and TCCFs to be inflated through similar double counting,
though, up to Release 27, there was no way to track these occurrences.
For Release 27, new pegs were added that count the number of 2G and 3G Silent Reoriginations
with TCCFs. These counts, ECP-PAF-CARR-SC-CDMA 55 and 57 are available for voice as
well as for data calls. Additionally, new pegs, CDMA-PAF-CARR-SC 169 and 170 count the
number of 2G and 3G Silent Reoriginations with Channel Assignments have also been
introduced. See the Release 27 release letter and [23] for more information.
4.1.2.3 Silent Page
Starting with Relaese 28, Page response seizures due to silent page for 2G and 3G peg counts
ECP-PAF-CARR-SC-CDMA 30 and 32, are subtracted from termination attempts in order to
provide a more accurate result for valid attempts.
Following are a list of all metrics that are modified for R28 with this change:
o Termination Established Call Rate
o Origination and Termination Established Call Rate
o System Access Denial Rate
o Engineered Blocking Rate
It is also important to note that Packet Data performance metrics are also affected by this exact
same change and following metrics have to be modified accordingly by subtracting Silent
pages from termination seizures:
o Termination Established Call Rate
o Origination and Termination Established Call Rate
o Seizure to Assignment deficit Rate

41
4.1.2.4 Recent IS95B Enhancements9
The most significant recent advancement that will have a tremendous impact on TCCF
performance is the IS95B standard. The standards body has recognized the limitations of the
IS95A standard and has incorporated several changes that will improve the performance at almost
every stage of the call setup process discussed above.
In particular, the IS95B has tackled the two most significant problems with the IS95A procedures,
namely:
1) The entire call setup is performed on the initial pilot that was identified as being the best
at the beginning of the process. This pilot may lose dominance during the course of the
call setup process.
2) The entire call setup is performed in the simplex mode on a single PN, with soft-handoff
only activated at the beginning of the actual call. Mobiles in high-interference, soft-
handoff areas may not be able to sustain the quality on a single pilot, even if this pilot
maintains its dominance in the area.
To alleviate these problems, the IS95B has introduced several new features. These features are
discussed in the following sections. Note that an obvious, but sometimes overlooked point is that
only IS95B or IS2000 capable mobiles will be able to take advantage of these enhancements.
For the purposes of the feature descriptions below, the primary sector refers to the sector that
“owns” the call setup for an originating or terminating mobile. This primary sector will be in
charge of all communication of control information with the mobile, and will also be responsible
for setting up the various resources within the network to handle the call. The primary sector is
usually, but not necessarily, the sector that the mobile idled and initiated the call on.
The secondary sectors are the sectors that are brought in by the primary sector to aid in the call
setup process, in accordance with the various IS95B features. The list of secondary sectors is
primarily driven by measurements made at the mobile, as will be described in the sections below.
4.1.2.4.1 Access Entry Handoff (AEHO) Feature
This feature only affects termination (page) response performance. It allows for mobiles to send a
Page Response Message on a different (stronger) sector that the one that page was originally
received on. This new, stronger pilot will assume the role as the primary sector for the call setup.
The Access Entry Handoff Enable (aeho_enable) translation field in the ecp database form needs
to be enabled to activate this feature. Each neighbor of each sector is individually set to be
AEHO-allowed through the fci form. Inter-MSC neighbors are not permitted to be AEHO-
allowed.
9
Refer to Lucent Alert 03-132 for recent information regarding some of these enhancements.

42
4.1.2.4.2 Access Handoff (AHO) Feature
With this feature, mobiles are allowed to listen to another (stronger) sector, other than the primary
sector, for the Extended Channel Assignment Message from the cell site (Figure A-1 illustrates at
which point of the call flow this message is generated). This provides another opportunity for the
mobile to use a stronger pilot during the call setup process.
The mobiles will report the Access Handoff List on the Page Response Message or the
Origination Message listing all the strong pilots it measured. This list of pilots forms the
secondary pilots. The cell site will subsequently transmit the Channel Assignment Message over
the primary sector as well as on all the secondary sectors.
Note that the list of pilots that constitute the Access Handoff List must be a subset of the list of
AHO enabled neighbor sectors of the original primary sector (in the fci form). The CDMA
Access Handoff (aho_enable) translation field in the ecp/ceqface database form needs to be
enabled to activate this feature. Inter-MSC and IS95A10 neighbors are not permitted to be AHO-
allowed.
4.1.2.4.3 Channel Assignment into Soft Handoff (CAMSHO) Feature
This feature allows the mobile to enter directly into soft-handoff when the channel assignment is
made. This is achieved using the Extended Channel Assignment Message. The mobile may be
assigned up to 6 traffic channels in soft/softer handoff, and will attempt to acquire the traffic
channel using all these pilots (see Figure A-1 to view stage at which traffic channel acquisition
occurs).
Only neighbor sectors of the original primary sector that are CAMSHO-enabled will be allowed
to participate in this feature (in the fci form). Of these sectors, the actual list of sectors chosen for
soft-handoff will only be the strong pilots that are reported by the mobile in the Page Response
Message or the Origination Message.
This feature will likely have the strongest positive impact on TCCF performance because the
TCCF Type 2 messages (Acquire Mobile Failure - see Figure A-1) are typically the most
dominant type of failure that results in TCCFs. The Channel Assignment into Soft Handoff
(camsho_enable) translation field in the ecp/ceqface database form needs to be enabled to
activate this feature. Inter-MSC and IS95A neighbors are not permitted to be AHO-allowed.
As of Release 22, it is recommended to not enable AHO and CAMSHO due to performance
issues recently discovered through field trials. See Lucent Alert 03-132 and [11] for more
information.
4.1.2.5 TCCF Causes and Associated Fixes
Given below are some common causes and conditions that will result in TCCFs along with their
associated fixes / suggestions for improvements. Note that some of these failures may be avoided
if the optimization steps in Section 4.1.2.1 are followed.
10
An IS95A neighbor is any sector that is configured purely as a 2G cell with p_rev less than 5.

43
4.1.2.5.1 High Traffic Areas
Concept / Reason for Failure
Areas of high traffic volume can experience an increase in TCCF rates. This is because several
high-traffic sectors in an area raises the interference levels significantly, making it difficult for the
paging and access channels to overcome this interference. It will also increase the chances that
the traffic channel is not acquired successfully for the same reasons.
Failure Symptoms and Identification Techniques
Examining the traffic Erlangs carried by the sectors exhibiting high TCCF rates may identify high
traffic levels. Note that, if this is indeed the root cause for the TCCFs, then there must be several
sectors covering the same area with very high traffic levels. A single sector with high traffic will
not justify that sector experiencing high TCCFs because its own sector traffic is mutually
orthogonal and should not affect the performance much.
Another important indication is that there should be a clear correlation between the TCCF
performance and traffic levels. It should be observed that the TCCF performance gets sharply
worse as the traffic picks up beyond a certain point. If the TCCF performance is consistently poor
during all hours of the day, then it is unlikely that high traffic levels are the root cause.
Suggested Fixes for Improvement
If the TCCF performance is deemed to be poor because of high traffic levels, then the only real
solutions available are to either add a carrier to the sectors in the area to relieve traffic, or to add
cell splits to offload the traffic to new cells. For PCS applications for Flexent ModCells 4.0Bs, if
cell splits are not an option, then additional sectorization may be possible. The Flexent ModCells
4.0B platform supports four to six sector configurations with the introduction of the new “Four-
to-Six (4-6) Sector Configuration for Flexent ModCell 4.0's Specific Growth-limited 5 MHz PCS
Applications” feature. This feature provides with all configuration parameters needed to support
cell sites with more than three sectors. Additional cell site hardware may be required to utilize
this feature, please see the Release 26 release letter for more information.
Performing optimization to offload sectors is usually a difficult exercise if there are more than a
couple of sectors in an area experiencing high traffic, since there will be limited sectors to offload
this traffic to. Adjusting translation parameters to increase the traffic carried by sectors will only
make matters worse because it will add to the excessive interference that was the root cause of the
problem to begin with.
One possible alternative solution, though sometimes difficult to achieve, is to reduce the amount
of overall soft-handoff percentage in the affected area. Reducing soft-handoff has many positive
aspects in relation to TCCF performance. In addition to reducing the interference levels, it will
also reduce the areas with pilot dominance problems.
However, there are several dangers with reducing soft-handoff zones, especially if they are not
properly executed. Given the nature of CDMA systems where the coverage shrinks with traffic
loading, it is quite possible that areas of weak to no coverage can be created during peak hours if
the soft-handoff reductions are too aggressive.

44
Also, it is always wise to manage soft-handoff zones by performing physical antenna

optimization, if possible, as opposed to changes in translations such as BCR/CBR attenuation.
Changing attenuation values to manage coverage has several drawbacks.
 Typically, it is recommended that the BBA/CRC Max. Power (max_power)

translation (set in the ceqcom2/crceqp/cdmeqp/bbueqp/btseqp forms based on cell
type) is reduced proportionately when attenuation is increased at a sector. While in
theory, the average power allocated to each user should also go down (thus
maintaining the same traffic capacity at the sector); this might not hold true in soft-
handoff areas where the average power allocated to the users may remain constant. If
this were to happen, then the sectors will actually go into forward power overload
even sooner. While this may or may not affect TCCF performance directly, it will
have several other negative impacts on the performance of call establishments and
dropped calls.
 The alternate solution is to leave the max_power unchanged despite increasing
attenuation, which will also potentially have negative impacts. Fully loaded sectors
will deteriorate the ability of the overhead channels to overcome the increased
interference, since these overhead channels are actually transmitting at a lower power
due to the attenuation introduced. This will potentially result in more areas of weak
coverage, which in turn will affect TCCF performance.
Antenna adjustments do not suffer any of the drawbacks discussed above. The coverage problems
are solved fundamentally, without introducing any of the capacity and/or interference issues due
to max_power and BCR/CBR mismatches as discussed above. Of course, there isn’t always the
option to perform such physical antenna optimization, especially in the cases when these antennas
are shared among multiple technologies (overlay systems). In these circumstances, there may be
no choice but to perform parameter adjustments to control coverage.
4.1.2.5.2 Cross-Carrier TCCFs
Generally, cross-carrier assignments should be avoided unless deemed absolutely necessary.

When a mobile re-tunes to another frequency as a result of a cross-carrier assignment, there is an
increased chance that the mobile will fail the call setup attempt, due to differing levels of
interference on the two carriers and/or mismatches in coverage.
Coverage mismatch between carriers can result from a faulty antenna or cable, incorrect power
output on a specific carrier due to drift or miscalibration, inconsistent antenna configuration such
as azimuth, downtilt, or antenna model, or inconsistent BCR/CBR attenuation settings for the
different carriers within a given sector. Note that such coverage mismatches should be
accompanied by an observed difference in traffic carried by the different carriers of the sector in
question.
In order to understand how to minimize cross-carrier assignments, it is first important to

understand how mobiles select the frequency to initiate call setup, and subsequently how the
network selects the frequency to ultimately assign the call request to (which may not necessarily
be the same frequency as the one on which the entire call setup process was executed on). This
topic is discussed in detail in Section 4.1.2.1.3.

45
Detecting the existence of cross-carrier TCCFs is not straightforward. Given below are some
possible methods of detection.
 Use ROP messages to determine the assigned versus idle frequency. The assigned
frequency may be inferred from the TCCF ROP message if the mapping between the
CCC/CDMs and the associated carrier frequency is known. The idle (hashed)
frequency may be determined by applying the mobile hashing algorithm on the IMSI
reported in the TCCF message.
There is an important source of inaccuracy with this approach. The ROP message
gives no indication of the frequencies sent in the Channel List Message, nor does it
give any indication of the order of the frequencies in the list. Therefore, this
algorithm may only be applied if the engineer has explicit knowledge of how the
channel lists are constructed in the market being analyzed. Note that the channel list
may be modified for border sectors as well as for sectors with 3G cards, as previously
discussed.
 Detect occurrences of cross-carrier assignments. Though this does not necessarily

imply that cross-carrier TCCFs are occurring, it is still not advisable to create
conditions that will result in cross-carrier assignments (other than on border sectors).
Effort should therefore be taken to identify such sectors and reduce or eliminate
cross-carrier assignments, if possible.
Cross-carrier assignments may be detected by examining the number of seizures
versus assignments on each carrier of a sector. It is usually a good sign on cross-
carrier assignments if the total number of seizures and assignments summed across
all carriers are approximately equal, but there are great disparities in their proportions
on a carrier-by-carrier basis.
A simple example will illustrate this point. Say a particular sector has two carriers.
Carrier 1 has 100 origination seizures and 10 assignments. Carrier 2 has 0 origination
seizures and 90 assignments. There are a total of 100 origination seizures and 100
origination assignments on this sector, but clearly a large percentage of Carrier 1’s
originations are being cross-assigned to Carrier 2.
Note that the example described above is common with border sectors. Border
carriers will never have any seizures given the Omit Border Carrier from Channel
List Message feature (which is automatically activated on all handdown border
sectors without requiring any translation entries). However, if rf loading is used (see
Section 4.1.2.1.3), then there will likely be several assignments on that border carrier,
even without having any seizures.
Detecting cross-carrier assignments can also be done by looking at Carrier Imbalance

metrics. These metrics compare traffic carried by each carrier in a sector against
traffic carried by the sector overall. Cross carrier assignments are happening if a
particular carrier within a sector is carrying most of the sector’s traffic. Again, one
carrier carrying most of a sector’s traffic is common with border sectors. Tools such
as SPAT (Appendix B) may be used to easily calculate carrier imbalance.

46
 Use the Same Carrier and Cross-Carrier TCCF Counts. For Release 22, new
sector level counts were introduced that peg the number of same, and cross-carrier,
TCCFs. While these counts are not broken down for origination and terminations or
2G and 3G calls, they provide information on the number of TCCFs that occur due to
cross-carrier assignments. Refer to Appendix A for more information.
There are two strategies to solve cross-carrier TCCF problems.
 Avoid cross-carrier assignments altogether. As discussed above, cross-carrier

assignments can occur for any one or more of the following reasons:
 The choice of carrier assignment algorithm coupled with the traffic distribution
across carriers results in cross-carrier assignments.
 The choice of how carriers are configured (2G, 3G, 2G/3G1X mixed) coupled with
the carrier assignment algorithm used along with new translations that bias mobiles
to stick with carriers of their own technology.
Important: If all carriers are configured as 2G/3G1X mixed carriers, then all of the
new translations (Allow Sharing 3G1X Carrier, 2G/3G Load Preference
Delta) have no effect on assignments because they cancel each other out.
Cross-carrier assignments due to choice of assignment algorithm may be avoided by
selecting the oc assignment algorithm (see Section 4.1.2.1.3). There are however
some important drawbacks to using this algorithm. They are:
 If the sector needs the capacity relief on the common carriers, then setting oc will not
work, since calls are not allowed to leave those common carriers.
 With data users, the links can be heavily loaded (RF power utilization-wise) with
relatively few data users, increasing the case for rf load balancing.
If any of the above drawbacks are of concern for the sector in question, then it is
important to keep the rf load balancing but take steps to minimize traffic imbalances
between carriers of that sector.
While this may be difficult to do for border sectors by virtue of their function, non-
border sectors should always be carrying approximately equal traffic on all carriers.
If they are not, then the reason for this imbalance must be investigated and corrected.
Note that cross-carrier assignments on border carriers usually will not pose a problem
with cross-carrier TCCFs because the border carriers typically have larger coverage
footprints than their common carrier counterparts due to the reduced interference on
the border carriers. This may not necessarily be true however, especially if there are
problems with the border carrier antenna, or if the BCR/CBR attenuation settings are
set differently on the border carrier.
Important: If border sectors are set up to use the rf carrier assignment algorithm, then it is
imperative that these border sectors use the IFHOTI triggering mechanism to
ensure that the assigned calls to the border carriers remain on these carriers
long enough to provide the necessary capacity relief. Also, the CMPIFHO

47
feature must be activated to ensure reliable handdowns. See Section 4.2.1 for
more information on these inter-frequency handoff features.
The other reason when cross-carrier assignments may occur is due to resource
blocking on one or more, but not all the carriers of a particular cell. In this case, an
escalation process is followed whereby the call is assigned to the least loaded non-
blocking carrier of that same sector.
This type of problem may be resolved by understanding the reason for this blocking
and taking the appropriate actions to alleviate the problem.
 Ensure successful call establishment even in the face of cross-carrier

assignments. Listed below are several possible reasons that could result in cross-
carrier TCCFs, techniques to identify whether these reasons are the root cause of the
problem, and suggested fixes.
Differences in Coverage Footprints
There are differences in coverage footprints between the various carriers of the sector due to
inconsistent physical antenna configurations on-site. Disparity in coverage footprints results in
the different carriers carrying different loads, thus, potentially causing variation in observed
overloads.
These antenna configurations come in the form of antenna models, installed elevation, azimuth
and downtilt. Note that, depending on the implementation, it is possible that multiple carriers may
share the same antenna. If this is the case, then this cause may be ruled out as being the root of
the problem.
The solution to this problem is to perform an on-site audit of the differences in antenna
configuration between antennas of the same sector, and correct the problem. Note that it is also
possible that the antennas may not be equally affected by physical obstructions. If this is the case,
it may be necessary to relocate all the antennas, if adjusting their elevations and/or azimuths will
not clear these barriers.
Faulty Antenna or Cable Assembly
A faulty antenna or cable assembly on one of the carriers of the problematic sector may cause that
carrier to have a much smaller footprint, resulting in it carrying a much lighter load. Therefore,
this will result in unequal load balancing and consequently, unequal observed power overloads.
The solution to this problem is to perform a sweep test on the antenna assembly of the affected
sector. This will allow for isolating the problem between the cable assembly and the antenna
itself. Sweep tests are also capable of isolating the problem down to the precise components that
are failing (connectors, jumpers etc.).
Output Power Drifts or Miscalibration
The output power being transmitted out of the problematic carrier of the sector may be
miscalibrated or drifting. This could be due to a problem with the amplifier, lack of sufficient
preventive maintenance calibrations or because the power was never calibrated correctly to begin
with.

48
This problem could be detected in a number of ways. If the CDMA Radio Test Units
(CRTU/CTRMs) are operational at the cell, then a Pilot Level (PL) functional test (FT) may be
performed to check the output power. This test will indicate problems with the output power,
assuming the CRTU/CTRM is properly calibrated.
Alternatively, the output power may be verified on-site using a power meter. Note that the
technician must have explicit knowledge of the calibration option selected for that carrier because
the output power varies according to the option selected (see [3] and [4] for a list of available
calibration options).
Power drifts are not as easy to capture. One method is to run periodic CRTU/CTRM PL FT’s and
examine the measured output power in the ROP. A drifting power amplifier will manifest itself in
a large variance in measured pilot power over time. Alternatively, the actual output power may be
measured over a long period of time on-site. This option is however highly undesirable because
the sector will be out of service on that carrier during this entire test.
Performing the calibrations according to the Methods and Procedures guidelines for the
appropriate calibration option may easily rectify miscalibrated powers. References [3] and [4] go
into great detail on these options.
Power drift problems are usually resolved through hardware replacements.
Cell Resource Differences between Carriers
There will be a difference in carried traffic between carriers if all the carriers of a site are not
equally distributed with traffic-equipped Channel Elements (CEs). Section 4.1.4.1 provides a
detailed definition of traffic-equipped CEs, along with hardware resource allocation management
techniques.
Note that, in order for this cause to be determined as the root cause for the observed differences in
carried traffic, it must be true that the carrier with the lower number of traffic-equipped CEs is
pegging handoff overflows. If this is not the case, then this implies that the lower number of
traffic-equipped CEs is sufficient to handle the call volume for that carrier, and therefore, will not
be the cause for differences in carried traffic between the carriers.
Hardware Outages
Outages on any call processing related hardware on a particular carrier of a cell could cause a
temporary reduction in traffic carried by that carrier. Examples of such hardware components
include CCCs/CDMs, channel cards (ECU/CCU-20), Packet Pipes (PPs), T1 spans, etc.
Problems related to this cause will result in sudden performance degradation the moment the
hardware goes out of service. In general, this problem will manifest itself in service
measurements in a very similar manner to when the cell is authentically out of traffic-equipped
CEs without any hardware troubles. The only way to distinguish between the two based on
service measurements would be to examine the peak channel elements used (CS4). The peak
channel elements used during the hours of blocking will be significantly lower than the number of
traffic-equipped CEs at the cell in cases when the blocking is due to hardware outages.
The obvious solution to this problem is to fix the failing hardware components, or make
arrangements for alternatives, to relieve its performance impact.

49
For CE availability, Release 23 introduced new peg counts that report aggregate and traffic
channel availability and the number of out of service channel elements. Please refer to [23] and to
section 4.1.4.2.2 for more information.
Inconsistent Attenuation Settings across Carriers
Attenuation settings (BCR/CBR) can be set independently for each carrier of a sector. Therefore,
a mismatch in carried traffic could be observed between the carriers of a sector if they are
configured with different attenuation settings, either intentionally or inadvertently. This would
result in greater power overloads observed on the carriers with less attenuation, since they will
carry more traffic.
Note that specific carriers are sometimes configured with greater attenuation on border sectors,
but are later not changed to be consistent with the rest of the carriers as the system grows and that
sector becomes full-traffic.
The solution to this problem is to conduct regular translation audits to verify that all carriers of all
sectors in the system are configured with the same attenuation values, unless there are good,
documented reasons why they should be otherwise.
Unbalanced Traffic on Border Cells
With border sectors, it is conceivable that the overloads are only limited to the common carriers
since the border carriers are actively attempting to direct the calls to these carriers. If this is the
case, then the following suggestions may be followed to fix the problem:
If the IFHOTI algorithm is not used on the border sector, then implement this feature so as to
carry more traffic on the border carrier. Section 4.2.2.1.2 discusses this algorithm in more detail.
Reference [9] is also required reading before any attempt is made to implement and optimize this
feature.
If IFHOTI is already employed, then optimize the trigger parameters to get more traffic to stay on
the border carrier, while maintaining the inter-frequency handdown performance at acceptable
levels.
If neither of the above suggestions is effective or appropriate, then consider adding carriers to the
adjacent cells and make this border carrier carry full traffic. This is of course a medium-term to
long-term solution because of the costs and justifications required to make this happen.
If cross-carrier assignments cannot be avoided, consider using the Distance Based

Origination/Termination feature. This feature may be used to limit cross-carrier TCCFs by
making sure cross-carrier assignments occur within distances that ensure good signal strength.
Refer to 4.1.2.1.3 for more information on this feature.

50
4.1.2.5.3 Poorly Defined Neighbor Lists
Concept / Reason / Effect of Failure
A poorly defined neighbor list may result in the mobile idling on a sub-optimal pilot for the
duration of the call setup, increasing the chances of a call setup failure. This topic is discussed in
detail in the conceptual overview presented in Section 4.1.2.1.
Poor neighbor lists may also result in sub-optimal performance of the CAMSHO feature because
the set of pilots selected for soft-handoff must be a subset of the neighbor list.
Several switch features exist that will easily trap neighbor list problems. Specifically, both the
Handoff Matrix (HOMAX) and the Undeclared Neighbor List (UNL11) features have been very
effective in identifying missing neighbor list entries and erroneous priority assignments.
When using the UNL feature, it is often more effective to first use service measurements to
narrow down and focus on the sectors exhibiting the most severe UNL problems (as a proportion
of their total traffic). Tools such as SPAT (Appendix B) may be used to easily arrive at this list of
affected sectors.
Problems with the neighbor lists may also be captured through integrity and consistency testing of
the neighbor list using tools such as FCIAlert. This tool captures a variety of problems such as
non-reciprocal neighbors and PN ambiguities within the neighbor list.
The SPAT tool explained in Appendix B may be used to quickly identify sectors exhibiting this
problem.
Alternatively, neighbor list problems may also be identified through drive tests. This method
however is generally more expensive and less reliable, since it will be difficult to drive all areas
of typical usage to capture all neighbor list problems. However, there is little choice but to use
drive tests for Greenfield (new) deployments, since switch-based neighbor list management tools
lack the traffic to make them statistically reliable.
The suggested fix is to modify the neighbor list in accordance with the problem detected.
 If the problem is with missing neighbor list entries, then these neighbors should be
added, with care to make sure the reciprocal neighbors are also added.
Note that there must be discipline exercised when adding neighbors, since sectors with
excessively large neighbor lists could perform poorly due to the increased processing
requirements. Additionally, given the fact that neighbor lists of sectors in soft-handoff are
11

51
concatenated, having large neighbor lists increases the chances that some neighbors will be
dropped in this concatenated list.
The solution in this case will be to perform physical and/or parameter optimization to eliminate
the need for the neighbor list entry [19]. This would entail removing that sector from the area
through antenna downtilts, azimuth changes, antenna model changes and/or BCR/CBR
attenuation changes [19].
 If the problem is with the integrity of the neighbor list, then the appropriate fix
should be applied. The FCIAlert tool will perform all of the following integrity
checks and more, but the most important ones are listed below.
Reciprocity
Reciprocity refers to making sure that if sector A is added to sector B’s neighbor list, then sector
B is also in sector A’s neighbor list. With CDMA networks, there is rarely any justification for
not satisfying reciprocity rules when populating neighbor lists because all sectors are transmitting
on the same frequency.
PN Ambiguity Issues
PN ambiguities may come in many forms. No two neighbors on the same neighbor list can have
the same PN assignment because this will confuse the network should this PN be reported as a
Candidate pilot. A less obvious problem will be when two neighbors share the same PN as a
result of neighbor list concatenation. This is commonly referred to as two-way PN ambiguity
problems (for any combination of two neighbor lists) up to n-way neighbor list problems (n up to
6). Typically, only two-way PN ambiguity checks are performed.
Cross-Face Neighbors
At a minimum, each sector must have all other sectors in the same cell as neighbors.
4.1.2.5.4 Excessive Soft-Handoff Zones
As discussed in Section 4.1.2.1, TCCFs are prone to occur in areas of excessive soft-handoff with
the IS95A call setup algorithm because the entire call setup is attempted over a single pilot. If this
pilot loses its dominance or becomes too weak even while it is the dominant pilot, then there is a
high likelihood for a TCCF. The pilot could lose dominance for the following reasons:
 Two or more pilots in soft-handoff are ‘ping-ponging’ in their dominance.

 Distant interferes are overshooting into the area inconsistently.
One reason a pilot can become too weak even while remaining dominant is if there are an
excessive number of reasonably strong pilots in the area causing the interference levels to be too
high for the dominant pilot to overcome.

52
 Isolate sectors exhibiting high soft-handoff percentage through service

measurements. Examining the primary and secondary CE usage on these sectors
does this. The ratio of secondary CE usage to total (primary + secondary) usage gives
the soft-handoff percentage. Percentages much larger than 50% should be flagged for
examination and possible optimization. Note that there may be several sectors
exhibiting such problems, especially in dense urban environments. It is always
prudent to examine the RF performance of these high soft-handoff sectors, and only
focus optimization activity on those exhibiting the most serious performance
problems.
 Use Handoff Matrix and UNL12 to isolate overshooting sectors. Both these
features can be used very effectively to capture sectors covering beyond their
intended coverage areas as well as distant interferers from several tiers of cells away.
Overshooting sectors have noticeable impact on the RF performance of the network,
and serious effort must be undertaken to control these sectors.
The following two approaches should be followed if it is suspected that excessive soft-handoff
zones are causing a rise in TCCFs.
 Turn on IS95B features on that sector and configure the neighbor lists
appropriately. This should already be done system-wide as a default, as suggested in
Section 4.1.2.4.
It is very important to note that even if these features are activated, only IS95B and
IS2000 mobiles will be able to take advantage of these enhancements. Therefore, in
markets where the penetration of such mobiles is low when compared to IS95A
mobiles, turning on these features will have negligible impact on TCCF performance.
The features should be activated regardless since the penetration of these IS95B and
IS2000 mobiles will inevitably increase.
 Reduce the soft-handoff zones to improve the pilot quality of the primary sector
handling the call setup. This can be done through physical optimization (changes in
antenna orientation, downtilt, model etc.) and/or BCR/CBR attenuation changes.
Note that manipulating t_add, t_drop and other handoff parameters will not help
TCCF performance because all of these parameters are only applied to calls in the
traffic state, not during call setups.
12

53
4.1.2.5.5 Lack of RF Coverage
TCCFs could be generated in areas of weak coverage whereby even the dominant pilot is unable
to overcome the noise floor. Areas of weak coverage could be a result of being inside buildings,
areas shadowed by obstacles such as hills, trees etc. or due to poor RF design of the cell sites.
It is difficult to determine poor RF coverage through service measurements or any other switch-
based tools. Typically, the drop call performance will also be poor, but this is inconclusive
because there are several other root causes that will result in degradations in both drop call as
well as TCCF performance.
The best way to confirm suspected weak coverage areas is through conducting drive tests. Areas
of very weak receive power, is an indication of weak coverage. Note that sufficient margin must
be added to account for in-building penetration losses in urban areas.
There are several choices for improving such coverage problems. They are:
 Perform physical optimization and/or parameter optimization to improve

coverage [19]. Physical optimization entails modifications of the antenna azimuths,
downtilts and/or antenna models. Parameter optimization is primarily through the
manipulation of BCR/CBR attenuation values and/or dgu settings. There may not
always be an option to implement this solution since the antennas may already have
been configured for optimal coverage and the attenuation values are at their
minimum.
 Add cell site to improve coverage. This would require even more justification that
the previous suggestion because of the vastly higher costs associated with this
solution. However, if there is a capacity constraint in the area, then it might typically
be easier to justify these cell splits.
4.1.2.5.6 Search Window Problems
Concept / Reasons for Failure
In IS95A/B systems, mobiles have five rake receivers, commonly referred to as ‘fingers’. Four of
these fingers are used to demodulate up to four best multipaths from the sectors in the Active Set.
The fifth rake receiver is known as the Searcher Finger and its primary job is to scan all possible
pilots and compare their strengths to the pilots in the Active Set. This information is then reported
back to the cell through the Pilot Strength Measurement Message (PSMM), which will then
evaluate these results and reconfigure the pilots to be used in the Active Set, if deemed necessary
to improve the performance.

54
Due to the large number of possible pilots (512 / PILOT_INC), each with a spacing of (64 x
PILOT_INC) chips13, it will take the Searcher Finger too long to scan through this entire space.
Therefore, the searcher is restricted to searching only over a ‘window’ of chips around each pilot,
known as the Search Window. This Search Window may be set differently for pilots in the
various sets (Active/Candidate, Neighbor and Remaining Sets).
It is intuitively obvious from the above discussions that if a pilot arrives outside of the Search
Window, then this pilot will not be captured and reported by the Searcher, and will therefore
never be a candidate to be used in the Active Set. In CDMA systems, due to the fact that all pilots
are transmitting over the same frequency, this missed pilot will immediately become a strong
interferer. The performance in these locations will degrade significantly and TCCFs and dropped
calls may result because of this strong interference.
Search window problems may be best captured using drive test data, either by using a pilot
scanner or by using the data logged off a mobile. With the pilot scanner, the delays of all the
arriving pilots may be directly viewed and analyzed. With the mobile-logged data, the delays of
all strong pilots may be extracted from Layer 3 messaging. Note that the mobile-logged data will
only give insights to pilots that are approaching the edge of their search windows. If the pilot is
completely outside of the search window, then the scanner will be the only way to capture this
problem.
These window problems may either be resolved by increasing the window sizes or by removing
the delayed pilot from the area through optimization. Note that areas of hilly terrain will generally
require larger search windows while smaller search windows may be used in dense urban
environments.
Reference [11] delves into the details of search windows and should be read before attempting to
optimize these windows.
4.1.2.5.7 External Interference
External interference in either the forward or reverse links will cause degradations in TCCF and
drop call performance on the carrier that it is on. This is because this interference raises the noise
floor of the system, requiring the forward or reverse link traffic signals to increase their transmit
powers to overcome it. If the interference is significant enough, then the base station or mobile
will run out of power and, as a consequence, the performance will degrade.
13
The definition and use of PILOT_INC is discussed under Co-PN Interference later in this section.

55
It is usually difficult to establish that external interference is the root cause of observed
performance degradations but sometimes service measurements will provide some clues to aid in
its discovery.
For example, strong reverse link interference could exhibit high RSSI rise and could even peg
significant counts of reverse power overload even though the carried traffic on the reverse link
does not justify such high reverse loading.
Another indicator of reverse link external interference could be an abnormally high Reverse
Frame Error Rate (RFER), even though the Forward Frame Error Rate (FFER) is within normal
ranges. Any true RF or optimization problems in the area should affect RFER and FFER equally.
External interference may be verified by using a spectrum analyzer to scan the affected CDMA
carrier. Typical interference will appear as spikes caused by inter-modulation products as well as
spurious signals. The source of the interference may be identified by driving around the area and
looking for the areas of concentration in the observed interference.
4.1.2.5.8 Co-PN Interference
In CDMA systems, pilots are differentiated by their PN offsets, which are really just time-shifted
versions of the same signal. There are 512 possible PN offsets, each being shifted in time by 64
chips (which correspond to approximately 10 miles). The important point to understand about PN
offsets is that, since they are just time shifted versions of each other, it is possible for a pilot to
appear like it has a different PN offset if it is able to travel far enough and still have sufficient
signal strength to be received by the mobiles. If two pilots in an area appear to have the same PN
offset with similar signal strengths, then the mobiles will not be able to resolve the two signals.
The process of PN planning is to avoid the potential problems listed above by intelligent
assignment of PN offsets to each sector in the system. To further reduce the chances for PN
assignment problems, only PN offsets in steps of PILOT_INC are assigned to these sectors,
PILOT_INC being an ECP-wide translation parameter. The larger the value of PILOT_INC, the
lower the chances that a PN offset will be associated with the wrong sector, since the pilot will
have to travel (PILOT_INC * 10 miles) and still be received with sufficient strength to be
mistaken for another PN offset.
Co-PN interference could result due to poor PN planning, improper choice of PILOT_INC or
inadvertent entry of incorrect PN offsets to sectors in translations. Interference may occur either
because the same PN offset was assigned to two sectors that “see” each other in the RF sense, or
if a sector assigned to a different PN offset traveled far enough with sufficiently low attenuation
to appear mistakenly as the same PN as another sector in the area. An example of a common
oversight is the inappropriate assignments of PN Offsets along water bodies. RF signals are able
to travel great distances with relatively low path loss over water, and therefore, great care must be
taken when allocating PN Offsets to all cells that share common water bodies.

56
Identifying the root cause of a problem to be because of Co-PN interference is not

straightforward.
One method of identifying Co-PN interference problems is through the examination of the delay
spread of the suspected pilot using a pilot scanner. Co-PN interference can be suspected if the
delay spread appears too large for the morphology, since this delay spread could actually be a
result of two separate sectors transmitting the same PN from very different distances.
Another indicator of Co-PN interference is if the Ec/Io and Receive Power in an area are very
good but the FFER performance is extremely poor. These results may be obtained through
mobile-logged drive test data. The reason for this is because there is no demodulation performed
when measuring Ec/Io, just raw power measurements. This will result in a good Ec/Io and
Receive Power being reported. The call however will not be able to be demodulated correctly
because of the direct co-PN signal interference, resulting in the poor FFER performance.
Note that neither of these indicators are definite proofs of Co-PN interference. However, they
provide good starting points in uncovering this problem.
Suggestions for Improvement
If Co-PN interference is identified, then the solution would either be to reassign the PN offset
values of the offending sectors, or to remove the offending sectors from the affected areas
through some combination of physical and parameter optimization [19].
4.1.2.5.9 Hardware Goes Into Bad State
Certain hardware elements in the cell sometimes (rarely) go into a bad state whereby they
generate a disproportionate number of TCCFs compared to other similar elements in the cell. This
can be identified from the ROP using ROP-filtering tools such as SPAT (Appendix B) that will
categorize TCCFs by hardware component in each cell14.
A typical example of this would be when a single CCC exhibits a much larger number of TCCFs
than all other CCCs in that carrier. Note that this assumes that all the CCCs within the carrier
have equal number of traffic-equipped channel elements (see Section 4.1.4.1 for the definition of
these channel elements). Otherwise, the TCCFs on each CCC should be distributed roughly
according to the number of equipped CEs in each CCC. The reason for this is because of channel
pooling resulting in all CEs being used equally by all sectors within the same carrier.
14
A recent example of hardware related TCCFs is documented in Lucent Alert 05−0382a. This alert describes a
problem affecting CMU-IV cards carrying large traffic volumes.

57
It is interesting to note that, with this example of CCCs causing TCCFs, the described problem
does not affect the drop call performance in any way on that carrier. Therefore, a clear way of
identifying this particular CCC problem is if a sudden, severe degradation in TCCF performance
is observed, but the drop call performance is maintained as per its typical values on that carrier.
Also, none of the surrounding cells will notice any degradation in both TCCFs and dropped calls.
Typically, restoring the affected hardware elements from the switch may clear the problem. If this
fails to clear the problem, then on-site diagnostics and possible hardware replacements might be
necessary.
4.1.2.5.10 Intermittent Hardware Problems
Sometimes, certain hardware elements in a cell go in and out of service, potentially causing
service-affecting problems such as TCCFs. An example of this would be Packet Pipes (PPs) that
go in and out of service, which typically might happen if there are problems with the associated
T1 line.
These types of intermittent hardware problems are characterized by a sudden degradation in the
performance of the KPIs the moment the problem starts happening.
The best way to capture such problems is through using ROP scripts that will be able to log and
report all hardware elements that go in and out of service. There are several tools that perform
such analysis, one of them being the SPAT tool (Appendix B) that will report all hardware
failures that occur throughout the day on a cell-by-cell basis.
The fix required will depend on the particular element exhibiting the problem. It is recommended
that the customer Operations team be notified of the problem.
4.1.2.5.11 CRTU/CTRM TCCFs
A CDMA Radio Test Unit (CRTU/CTRM) is a unit placed in every base station and its purpose is
to run a sequence of call processing tests on the cell for diagnostic purposes.
It is possible for these CRTU/CTRMs to generate TCCFs that will get captured in the TCCF
service measurement counters as well as on the ROP. This problem is not service affecting but is
important to capture and fix anyway because of the extra burden placed on the network to capture
and log these events.

58
Additionally, these CRTU/CTRMs will not be able to conduct their diagnostic tests if they are
generating these TCCFs, since the test calls never get established. It is therefore important to
identify and clear this problem.
It will usually be easy to distinguish CRTU/CTRM TCCFs on the ROP because CRTU/CTRM
phone numbers follow a well-defined pattern as per the local market’s convention. For example,
the number might be (973) 004-0001 that may refer to the CRTU/CTRM in cell 1 on ECP 4.
Tools exist such as SPAT (Appendix B) that provide per-cell mobile-high-runner reports that
make these ROP trends easy to capture.
The CRTU/CTRM TCCFs are captured as a separate peg count in service measurements and
must be discounted from the total Originations TCCF count to ensure accuracy in the calculated
KPI. Viewing these peg counts separately can immediately alert to this problem, if it is occurring.
Typically, the reason for CRTU/CTRM TCCFs is because the CRTU/CTRM mobile is not
correctly identified in translations at the switch on the sub form. Therefore, the network does not
recognize the mobile during service negotiation and rejects it, causing a TCCF. The fix is to make
an entry for this CRTU/CTRM in the sub form and configure it correctly to reflect that the
number is associated with a CRTU/CTRM.
4.1.3 Call Setup Failure Analysis
Call setup failures are a catchall failure type that captures all access failures that are not explicitly
captured by other service measurements. These types of failures may also be categorized into
origination and termination setup failures, and are usually either DCS related failures or software
processing failures.
Service measurements will capture these catchall failures as call setup failures. On the ROP, they
will be captured as Call Shutdowns in the Unanswered Origination or Termination state.
These call setup failures should be a rare occurrence in a normally operating system. Therefore,
the only optimization step that is required is to ensure that a process is in place to track the
appropriate call setup failure service measurements on a regular basis.
Should any alarming flares be observed in call setup failures on any particular sector, then the
means should also be in place to isolate the type of Call Shutdown appearing on the ROP and
react appropriately.
In Release 27.01 Call setup failure peg counts have been modified such that the system excludes
the mobile releases received from Access channel scenario. This will result in lower values for
call setup failure peg counts (PAF-CARR-SC15, PAF-CARR-SC16, PAF-CARR-SC38, PAF-

59
CARR-SC39) and hence it is possible to see a reduction in the RF failure Rate equations,
compared to previous releases.
The SPAT tool will provide both the means to view the appropriate metrics based on service
measurements on a sector-by-sector basis, as well as the ability to summarize the ROP output for
each of these sectors. Appendix B provides an overview of this tool.
4.1.3.2 Commonly Encountered Types of Call Setup Failures
Given below are the commonly encountered types of Call Shutdowns that result in call setup
failures being pegged in service measurements.
4.1.3.2.1 Call Shutdown Type 43 (CS-[43])
Occasionally, CCCs will go into a bad state and start generating a significant number of CS-
[43]’s that will get translated into call setup failures in service measurements.
Since the problem is associated with a single CCC, the problem will manifest itself as a
significant rise in call setup failures on all sectors of a single carrier.
The reason for this is because of channel pooling, resulting in the CEs in one CCC being shared
by all sectors of the cell. This channel pooling does not extend across carriers of a cell, thus
limiting the manifestation of the problem to the specific carrier associated with the problematic
CCC.
Typically, restoring the affected CCC from the switch may clear the problem. If this fails to clear
the problem, then on-site diagnostics and possible hardware replacements might be necessary.
4.1.3.2.2 Call Shutdown Type 10 (CS-[10])
Failed handoffs in the Unanswered state will result in CS-[10]’s that will get translated into call
setup failures in service measurements.
In addition to appearing as call setup failures in service measurements, these failures are also
recorded in the ROP as Call Shutdown Type 10 messages in the Unanswered Origination or
Termination states.

60
Most CS-[10]’s actually occur in the Answered state and manifest themselves as CP Fail Drops.
All of the improvement techniques to solve these types of CP Fail Drops will apply equally to
improving Call Setup failures of this nature. This topic is very involved in its own right, and is
discussed in detail in Section 4.2.2 under CP Fail Drops.
4.1.3.2.3 Speech Handler Failures
During the call setup process, a speech handler is requested and assigned by the MSC. However,
if the speech handler assignment is lost or the speech handler protocol results in a failure, then the
call setup process is declared to have failed.
Speech handler failures are recorded as a DCS-level peg count in service measurements.
Suggested Fixes for Improvements
Speech handler failure issues are usually resolved by checking for the stability of speech handlers
and/or software anomalies.
4.1.4 CE/PP/Signaling Link Resource Blocking Analysis
Cell sites deployed within a network communicate with the MSC via T1/E1 facilities (also known
as the cell site’s backhaul). These facilities carry both traffic information through packet pipes
and control and signaling information through reserved time slots known as signaling links.
The failures covered in this section happen when the cell processing the mobile call request does
not have the hardware resources to support the call, namely traffic-equipped channel elements
(CEs). CEs are deemed to be traffic-equipped if they are provisioned with sufficient packet pipe
(PP) bandwidth to support them. Additionally, these failures may occur when signaling links go
down or high occupancy causes them to shed messages. Note that if the PPs go down on a cell for
any reason, then this will the render the associated CEs unusable, thus potentially resulting in this
blocking condition.
High signaling link occupancy may occur due to unusually high traffic situations, hardware
outages or failures, improper network optimization, or improperly engineered signaling links.
Additionally, the signaling link may get overloaded as the carrier loading increases. If signaling
link congestion is severe, the signaling messages may be dropped and the performance of all call
signaling events (including access and handoff attempts) will be degraded.

61
Since both the signaling links and PPs utilize the backhaul, outages of the cell site’s T1/E1
facilities may impact both, with the resulting performance effects.
The following sections detail various concepts and features related to CEs and PPs, as well as
optimization techniques to proactively prevent or manage this blocking condition. Basic concepts
regarding signaling links are also discussed.
4.1.4.1.1 Conceptual Overview for 2G Cells
Channel Elements (CEs) and Packet Pipes (PPs) are two hardware resources required at the cell
to support calls. Each 2G voice call being supported by the system requires a single CE at the
base station while the PPs provide the backhaul to transfer the call information back and forth
from the base station to the switch.
CEs come in sets of ten (ECU cards) or twenty (CCU-20 cards), depending on whether the
Autoplex or Flexent series of CDMA equipment is being used respectively.
In the case of Autoplex Series II CDMA Minicells, these ECU cards are each housed in a CDMA
Cluster Units (CCU). A CDMA Cluster Controller (CCC) controls each set of 4 CCUs. Each of
these CCCs is in turn associated with a single sector on one carrier. Therefore, there will be three
CCCs per carrier in a three-sectored site.
With Flexent CDMA ModCells, up to six CCU-20 cards may be inserted into a single CDMA
Digital Module (CDM). There is one CDM per carrier in a cell site.
A bank of PPs will be associated with each CCC/CDM. The total bandwidth offered by these PPs
may be collectively used by all CEs associated with that CCC/CDM but may not be accessed by
CEs from any other CCC/CDM. There is a pre-defined relationship between the total number
of CEs in a CCC/CDM and the number of PPs needed to provide sufficient backhaul bandwidth
for these CEs. This relationship depends on whether two important FAF features are activated for
all sites in the ECP, namely, the Packet Pipe Optimization (PPOPT) and Packet Pipe 16 (PP16)
features (see [13]).
The relationship between PPs and CEs is provided in [13] for both without the PPOPT feature
activated and with this feature activated. For convenience, the relationship with PPOPT activated
is extracted from this documentation in Table 4.1 below. Note that it is strongly recommended
that this PPOPT feature be enabled on all cells on the cell2 form, as there is no disadvantage to
doing so.
Table 4.1 NUMBER OF CALLS SUPPORTED WITH PPOPT
Number Calls Supported for each Service Class PPOPT

64 kbps DS0s 56 kbps DS0s
Num DS0 2G RS1-8k 2G RS2-13k 2G RS1-8k 2G RS2-13k
1 2 1 2 1
2 7 5 6 4
3 12 8 10 7
4 16 11 14 10
5 21 15 19 13
6 26 19 23 16

62
7 32 23 27 19
8 36 26 31 22
9 41 30 36 26
10 47 34 40 29
11 53 39 44 32
12 57 42 49 35
13 62 45 53 39
14 67 49 58 42
15 72 53 63 46
16 78 57 69 50
A CE is said to be traffic-equipped if it has the necessary PP bandwidth to support a voice call.

Note that, based on the table above, it can be seen that the same number of PPs can equip more
CEs for Rate Set 1 (EVRC – 8K) as opposed to Rate Set 2 (13K). This is intuitive because 8K
calls will require less bandwidth on the backhaul.
For example, a CCC with 3 ECU cards and 7 DS0 PPs will only provide 26 traffic-equipped CEs
for Rate Set 1 without the PPOPT enhancement feature [13]. Therefore 4 CEs may never be used
for traffic. However, with the enhancement feature activated, 32 CEs may be supported with the 7
DS0s. However, since only 30 CEs are inserted into the CCC, therefore there will be 30 traffic-
equipped CEs for Rate Set 1.
It should be noted that at least 2 CEs per sector per carrier need to be reserved to carry the
overhead channels (Paging, Sync, Access and Pilot channels). These CEs do not need to be
traffic-equipped (and therefore do not need PPs associated with them).
Another important concept related to CE/PP utilization is channel pooling. In Lucent CDMA base
stations, all the CEs installed (across all CCCs/CDMs) in each carrier of a base station may be
used by all sectors of that carrier. This allows for the efficient use of CEs, especially in cases
when traffic is biased towards one or more sectors of the cell. Because of channel pooling, these
heavily loaded sectors can “borrow” CEs from those allocated to the lighter loaded sectors. This
is a unique luxury afforded to CDMA systems because all channels use the same frequency. Note
that channel pooling is not allowed across carriers of a site.
In addition, a call in softer handoff with two sectors of the same cell can share one CE. However,
a mobile in softer handoff with all three sectors of the cell will require two CEs to support the
call.
4.1.4.1.2 3G1X Enhancements & Concepts
With the advent of 3G, new channel cards have been introduced to handle the variety of service
classes that can be supported on Lucent systems. These new channel cards for 3G1X come in two
major forms:
 ECU-32 cards – for Series II cells.

 CCU-32, CCU-64, CMU-III, CMU-IV, and other channel cards – for Flexent cells.
These cards no longer carry physical channel elements, but rather are comprised of logical
channel elements called Channel Fragments (CFs). For example, each ECU/CCU-32 supports the
following CFs:

63
- 32 Forward FCH CFs (Supports F-FCH, Paging, Quick Paging and Pilot channels).
- 3215 Forward SCH CFs (Supports F-SCH and Sync channels).
- 32 Reverse FCH/SCH CFs (Supports R-FCH, R-SCH and Access channels).

Each of the FCH CFs can support any one of the following service classes:
- Forward / Reverse 13 kbps voice
- Forward / Reverse EVRC (8 kbps) voice
- Forward / Reverse 2G Circuit Data at 9.6 kbps
- Forward / Reverse 3G Packet Data at 9.6 kbps

Each Forward SCH (F-SCH) supports forward supplemental channel data at 9.6 kbps (16 CFs
needed to support 16X rate of 153.6 kbps). Each Reverse SCH (R-SCH) supports reverse
supplemental data at 19.2 kbps (8 CFs required to support 16X rate of 153.6 kbps).
Any single carrier may have a mix of 2G and 3G1X cards installed. The only restriction is that,
for Series II cells, a single CCC may not contain a mix of these cards, but different CCCs on the
same carrier may carry any combination of 2G and 3G1X cards. A carrier with only 2G cards
installed is commonly referred to as a 2G carrier, and likewise for 3G carriers that are only
installed with 3G cards. Any carrier with a mix of 2G and 3G1X cards installed is commonly
referred to as a 2G/3G1X mixed carrier.
A minimum of 5 overhead CFs are reserved per sector per carrier (15 in total for a 3-sectored cell
per carrier) – 4 forward overhead CFs for pilot, sync, paging and quick paging, 1 reverse
overhead CF for access. This is in contrast to only 2 overhead channel elements reserved for
overheads in 2G systems – 1 for pilot, sync and access, 1 for paging. For 2G/3G1X mixed
carriers, all overhead channels are assigned to the 3G1X CFs. However for Release 23, a new
feature called “Allocate CDMA Overhead Channels on 2G Channel Cards” allows users to
allocate the overhead channels to the 2G cards, as long as there are no 3G specific channels used
(Q-PCH, R-EACH, F-CCCH, BCCH). This feature is available to Flexent CDBS cells and
ModCells 1.0 to 3.0 only and may be enabled by using the ACDMAAOC2G parameter in the cell2
form. If this feature is enabled, the Q-PCH must be disabled.
The provisioning of Packet Pipes (PPs) has become a fairly complex task given the number of
different service classes supported by Lucent cell sites with 3G1X. The complication arises from
the fact that each of these service classes requires a different amount of PP backhaul bandwidth
for a single call. Thus, it becomes important to know the expected mix of usage among the
various service classes in order to correctly provision the cell site backhaul bandwidth.
There are two important variables in PP provisioning that must first be understood before being
able to allocate the appropriate bandwidth. They are the Packet Pipe Capacity Unit (PPCU) and
the Packet Pipe Loading Coefficient (PPLC).
15
Typical maximum supported SCH CFs is 32 with Release 18. Larger number of FCH and SCH CFs will be
supported with the CCU-64 cards that will be available with Release 19.

64
One PPCU is defined as the PP capacity required to service one 2G Rate Set 1 (8 kbps or EVRC)
call. In other words, if 1 DS0 were to have a capacity of 3 PPCU, this is the same as saying that
single DS0 will be able to support 3 2G Rate Set 1 calls.
The PPLC defines the number of PPCUs required to support a single call of any other service
class.
As an example, a 2G Rate Set 2 (13 kbps) voice call has PPLC = 1.35 for a cell site provisioned
with 8 DS0s, and that 8 DS0s have a joint capacity of 42 PPCU (see Table 4.2 below). This
means that this cell can either support a total of 42 Rate Set 1 calls or 31 Rate Set 2 calls
(42/1.35=31), or some combination in between that adds up to no more that 42 PPCU.
To illustrate the last point, say there are 30 Rate Set 1 calls and 8 Rate Set 2 calls requesting
service at that site. The 30 Rate Set 1 calls will require a capacity of 30 PPCU. The 8 Rate Set 2
calls will require a capacity of (1.35  8 = 10.8) PPCU. This gives a total of 40.8 PPCU, which
will be supported by the 8 DS0s above. The 9th Rate Set 2 call requesting service will require an
additional 1.35 PPCU, which will bring the total PPCU requirement to (40.8+1.35=42.15) PPCU.
This is greater than the 42 PPCU limit of the cell, and therefore the cell will deny access to this
9th Rate Set 2 call.
There will be efficiencies gained when supporting multiple calls. Therefore, the PPLCs for the
various service classes are a function of the total DS0s being provisioned at the cell. Given below
is a table providing an example of the capacity for the various service classes given that the PP16,
PPOPT and Backhaul Engineering Enhancement features are activated.
Table 4.2 NUMBER OF CALLS PER SERVICE CLASS FOR VARIOUS PACKET PIPE
BANDWIDTHS
Number Calls Supported for each Service Class per Number 64 kbps DS0s with PPOPT & 3G1X Backhaul Enhancement
Num DS0 Max PPCU 2G RS1-8k V 2G RS2-13k V 2G RS1-8k D 2G RS2-13k D 3G RS1-8k V 3G FCH Data 3G SCH Data
1 3 3 2 3 1 3 2 5
2 8 8 5 6 4 7 5 10
3 14 14 10 11 7 12 9 15
4 19 19 14 13 9 17 13 19
5 25 25 18 17 12 23 17 25
6 31 31 22 22 16 28 21 31
7 37 37 27 26 19 34 26 37
8 42 42 31 30 21 38 29 42
9 48 48 35 34 24 44 33 48
10 54 54 40 38 27 50 38 54
11 60 60 44 43 31 55 42 60
12 66 66 48 47 34 61 46 66
13 72 72 53 51 37 66 50 72
14 78 78 57 56 40 72 54 78
15 84 84 62 60 43 77 59 84
16 90 90 66 64 46 83 63 90
4.1.4.1.3 Signaling Link Concepts
Cell site to MSC signaling data is transmitted on signaling links using DS0 lines over DS1
facilities. The number of signaling links needed is dependent on the cell site type. Series II cells
require two DS0s per cell site for signaling. Flexent cells can have a varying number of signaling
links based on Flexent cell site type and configuration (but usually, two DS0s are required per
carrier). Signaling information includes handoff message orders between cell sites and the MSC,

65
registration messaging, call setup messaging and other information. As these messages consume
signaling link capacity, optimization of RF parameters affecting them will impact signaling link
capacity.
For Flexent cells these DS0 links are connected to the two application processors that host the
cell’s primary and alternate RCSs. The signaling links travel over DS1 facilities between the
application processors and the cell with nail-up connections through the digital cellular switch
(DCS) and/or a DACS. A DACS is a digital switching device for routing T1 lines. The DACS can
cross-connect any T1 line in the system with any other T1 line also in the system. Hence,
problems with the DACS may cause problems with the signaling links.
4.1.4.1.4 CE/PP Blocking Definition
An incoming call or soft handoff request is blocked at the cell if it does not have any traffic-
equipped CEs available across all carriers to support the request. That is, if a call is blocked on
the carrier it is on, then the blocking base station will first attempt to provide resources to this call
on any of the other carriers on that cell, with preference to the least loaded carrier. The call is
only completely blocked if every carrier in that cell does not have any resources to spare.
Blocking on only some, but not all, of the carriers will be discussed under CP Fail Drops in
Section 4.2.2.2.
For Release 24, a new per -packet pipe peg count section has been added to better track backhaul
occupancy. The CDMA-PP section has peg counts which track average and peak packet pipe
occupancies due to different traffic (voice calls, packet data calls, and SCH use) in both the
forward and reverse directions. These new counts were introduced as part of the Remote T1
Monitoring feature introduced in Release 24. These new counts may be used to determine packet
pipe utilization and thus help troubleshoot blocking due to PP use. See [23] for more information.
4.1.4.1.5 CE/PP Resource Blocking Management Techniques
With the above discussions in mind, there are some fundamental practices that should be
followed to ensure that a well-structured CE and PP management process is in place.
 Ensure that the PPOPT, Backhaul Engineering Enhancement and PP16 features are
enabled in all cells. This will ensure that the packet pipes are used optimally to
maximize the number of traffic-equipped CEs on-site.
 Ensure that all carriers in a cell are equally distributed with traffic-equipped CEs. The
carrier-hashing algorithm built into phones will statistically distribute the calls evenly
among all the carriers of a sector. However, if the CEs are not balanced between the
carriers, then this will result in the call assignments being cross-assigned to other
carriers, introducing the possibility for cross-carrier TCCFs (Section 4.1.2.5.2) and
CP Fail Drops (Section 4.2.2.2). While this suggestion doesn’t specifically affect
CE/PP resource blocking, it is stated here as a general guideline for good CE/PP
management.
The exception to this rule is when one or more of the carriers of a sector are
configured as border carriers (handdown or pilot-only carriers). In this case, the
border carriers may be configures with less CEs because their primary role is to

66
transfer the calls to the common carriers. However, care should be taken to revisit
such sites and add the appropriate CEs should they be made full traffic cells in the
future.
It is good practice to maintain clear documentation of the total number of installed
CEs, the number of PPs, and, as a result, the number of traffic-equipped CEs for each
service class in every carrier of every site. This will make for timely problem analysis
and will also aid in the decisions to add CEs and/or PPs on a cell with hardware
resource problems.
 Regularly monitor the peak number of channel elements used in a cell and take
proactive steps to prevent blocking by ensuring that the peak usage does not cross a
pre-defined percentage of total number of traffic-equipped CEs at the cell.
Alternatively, some service providers will allow for marginal, controlled resource
blocking. If this is the case, then monitor the blocking percentage at each cell and add
resources when the appropriate levels are reached.
Note that, when adding CEs to a cell, it is important to evaluate the PP bandwidth
allocated and increase this allocation as per the tables in [13] and [14].
 Ensure that as cell equipment grows older its hardware resources stay up to date if
needed. For example, cell sites with older CDMA Radio Controllers (CRCs) with
8MB of RAM can only handle up to 120 CEs. Additionally, prior to Release 21,
newer CRCs with 32MB of RAM could only handle 120 CEs. As of Release 21 and
later this has been increased to 170 for the newer 32MB CRCs. It is good practice to
follow hardware and software requirement changes as new releases are introduced.
Additionally, for Release 23 (and later releases), CRCs with 8MB of RAM will not
be initialized and will remain out of service on ModCells 1.0 to 3.0 and Flexent
CDBS and CEDBS sites after the cell generic is changed to R23. This may reduce
capacity on cells just retrofitting to Release 23. See Lucent Alert 04-233 for more
information.
For the specific 8MB CRC 120 CE limitation, inventory data can be used to identify
by apparatus code and series which CRCs may need replacing by using a tool like
SPAT.
 Determine whether the cell sites showing blocking are using the Voice vs. Data Call
Admission feature, and whether this feature’s parameters require optimization.
 Ensure that CCU cards that support CE Provisioning Fragmentation are properly
provisioned. For Release 27, the new “CE Provisioning Fragmentation with the
CMU-IVB” feature allows the provisioning of the CMU-IVB cards in Flexent
ModCells 4.0 in 32 CE increments. This implies that, while the overall CE capacity
of the CMU-IVB card is 128 CEs, only a fraction of them could be enabled. The
CMU-IVB provisioning can be verified in the btseqp form by looking at the ce_max
and ce_enabled parameters.
4.1.4.2 CE/PP Resource Blocking Causes and Associated Fixes
CE/PP resource blocking may still occur even if all the suggested optimization steps in the
previous section are followed. Given below are some common conditions that will result in such
CE/PP resource blocking and their associated fixes / suggestions for improvements.

67
4.1.4.2.1 Cell Resource Capacity Reached
Calls will be blocked from originating or terminating on a cell when there are no traffic-equipped
channel elements across all carriers of that cell to service these calls. That is, if a call is blocked
on the carrier it is on, then the blocking base station will first attempt to provide resources to this
call on any of the other carriers on that cell, with preference to the least loaded carrier. The call is
only completely blocked if every carrier in that cell does not have any resources to spare.
 Service measurement peg counts indicate presence of CE/PP blocking.

Examining service measurements that are able to isolate just the PP blocking may
further narrow the root cause. The presence (or lack thereof) of these PP blocking
counts will determine whether the CE/PP blocking observed because of lack of PPs
or CEs.
 Peak CE usage indicates that resource blocking is due to authentic resource
capacity constraints. The reason for checking this is because there could also be
resource blocking because of span outages and/or outages of channel element cards,
CCCs, etc. Problems due to these hardware outages are discussed in detail in Section
4.1.4.2.2 below.
 Peak CE usage indicates 120 CEs are being used at the subcell level (CDMA
SUBCELL 8, Peak Number of 3G Fundamental Channels in Use), but cell site
has more than 120 CEs for that subcell (and enough PP capacity). This indicates
a limitation on older CRC hardware that cannot handle more CEs. See 4.1.4.1.5 and
ARs 1-0960143 and 1-0789308 in the Cares web site.
 For Release 24 and later releases, use the new per-packet pipe peg count section to
track average and peak packet pipe occupancies due to different traffic types. See
[23] for more information.
 For sites with CDMs which use URC-II controllers, Peak CE usage indicates that no
more than 498 CEs can be assigned, even though the CDM has more than 498 CEs
available. This is a known issue that has been resolved in Release 27. See the Release
27 release letter and refer to whc_cell_cr38144 for more information. This problem is
also reflected in “Channel Activation Failure” CP Failure messages, which may
escalate to a “CDMA Traffic Channel Activation Failure” HEH if they occur often
enough.
With 3G networks, determining whether cell sites have reached their full capacity of traffic-
equipped channel elements is not straightforward because the amount of packet pipes consumed
is dependent on the particular mix of service classes supported by that cell (see Section 4.1.4.1.2
on 3G1X Enhancements & Concepts).
One method to do this is to examine the service class that will yield the minimum number of total
channel fragments used for the number of packet pipes provisioned at the cell. If the actual peak
channel elements that were used during the hours of resource blocking were even lower that this
minimum value, then it is quite likely that the problem is not with authentic lack of resource
capacity provisioned at the cell, but rather some other hardware problem.

68
For example, looking at Table 4.2, if the cell site is provisioned with 16 DS0s, and the service
classes being serviced are primarily 2G and 3G voice, then that cell site should at least be able to
support 66 channel fragments (corresponding to 2G Rate Set 2 - 13 kbps voice calls). Therefore,
the peak channel elements in use should at least be 66 in order to even consider that the cell site
has reached its provisioned resource limits.
Alternatively, the ROP may be examined to check whether there were any hardware failures
during the hours of resource blocking. An important caveat to this approach is that hardware
outages are only logged in the ROP the moment they occur. Therefore, it is possible that
hardware elements may be out of service but still not register on the ROP during the hours of
resource blocking because these outages actually occurred earlier.
Once it is determined that the problem is truly due to an authentic shortage of equipped resources,
channel elements and/or packet pipes may be added to resolve the problem. Care should be taken
to add these resources equally on all carriers, and to document the additions for proper cell
resource management.
An alternate solution would be to offload traffic from the blocking sector as per the suggestions in
Section 4.1.4.1.5 on CE/PP Resource Blocking Management Techniques.
Note that some service providers may desire to maintain some marginal level of cell resource
blocking so that cell sites are not over-engineered to cater to peak traffic utilizations. The market
guidelines should be followed in requesting these cell resource additions.
For CE resource shortages due to older CRC hardware, replace older CRCs with newer hardware;
see ARs 1-0960143 and 1-0789308 in the Cares web site for more information.
For cell sites with mixed 2G/3G CEs carrying mostly 3G traffic, it may be possible to free
additional 3G CEs for call handling by moving all overhead channels to the 2G CEs. This can be
done only if there are no 3G specific overhead channels (Q-PCH, R-EACH, F-CCCH, BCCH) in
use. This can be done using the Allocate CDMA Overhead Channels on 2G Cards feature, see
[38] for more information.
Additionally, as the network changes (new cell adds, splits, new carriers, changes in border cells,
changes in traffic type or traffic patterns, etc.) reexamine the use of features that may be reserving
CEs for other use. For example, reexamine the use of features such as “3G CE Reservation for 3G
Hand-offs” (see section 4.2.1.2.6), “Voice vs. Packet Data Call Admission” (see section
4.1.2.1.3), or “3G-1X Call Admission Policy with System Resources Reservation Based on RF
Power” (see section 4.1.5.1.3) and “3G CE Reservation for 3G Packet Data Call Setup” (see
section 5.1.3.2), as the network matures and changes.
Lastly, for any CEs that support Provisioning Fragmentation, verify that they are properly
configured to the required number of CEs. This provisioning may be done by looking at the
btseqp form and verifying the ce_max and ce_enabled parameter settings.
Additionally, for Release 27, a new peg count, CDMA-PAF-CARR 225, has been added to peg
3G CDMA Origination / Termination Overflows with Handoff/SO33 Reserved Channels
Available. This peg counts instances when the cell cannot allocate a 3G traffic channel for setting
up a 3G call and 3G channel elements are available for supporting either handoffs or SO33 calls.

69
This peg count may indicate incorrect provisioning of the channel elements by reserving too
many channels. Pegging this count does not necessarily mean the call was blocked. It only means
the call could not be assigned to 3G traffic channel. See [23] and the Release 27 release letter for
more information.
4.1.4.2.2 Hardware Outages
Any CCCs/CDMs, CCUs or PPs that are down in a cell will reduce the number of traffic-
equipped CEs available to support calls, resulting in premature call blocking.
It is therefore very important to always compare the peak number of channel elements used
during the hours of blocking against the expected number of traffic-equipped CEs on the site.
This will ensure that CEs and/or PPs are not inadvertently being added to the site because of an
incorrect analysis of the problem. See the previous Section 4.1.4.2.1 for details on how to do this.
Hardware outages may be viewed on the ECP Control & Display page (commonly referred to as
the ‘cartoon’ page) and may also be captured in the ROP as HEH messages. Due to the magnitude
of ROP file sizes, they are best analyzed using filtering scripts. Many such scripts exist, an
example being the SPAT tool that has a component to perform such analysis (Appendix B
provides an overview of this tool).
For Release 23 (and later releases), CRCs with 8MB of RAM will no longer be supported. Any
8MB CRC will not be initialized and will remain out of service after the cell generic is changed to
R23. Upgrading 8MB CRCs to newer CRCs as explained in Lucent Alert 04-223 can prevent this
hardware outage.
Additionally, for Release 23, a new set of peg counts (CDMA-CS-L, or CDMA Cell Site Long
counts), may be used to identify the number of out of service channel elements. See [23] for more
information on these new counts. These new counts include aggregate and traffic channel element
availability.
As this is a cell hardware issue, it is recommended that the customer Operations team be notified
of the problem.
4.1.4.2.3 Intermittent Hardware Problems
Occasionally, hardware components enter into an intermittent state whereby they go in and out of
service. These types of problems are usually difficult to capture because they may not exist when
the technicians look at the ECP Control & Display page. CCCs/CDMs, CCUs and PPs are all
possible candidates for this type of problem.

70
Again, the key indicator that this is not an authentic problem of insufficient cell resources is the
peak number of channel elements used during the hours of blocking, which would not be equal to
the expected number of traffic-equipped CEs on the cell in question.
This root cause is best identified by looking in the ROP for intermittent problems with these key
hardware components. The use of scripts to capture all failures on a cell or sector basis is key in
identifying problems such as these since it will be very difficult to extract trends from merely
viewing the raw ROP output. The SPAT tool (Appendix B) will perform such an analysis and
quickly point out hardware problems with all service-affecting cell hardware components.
of the problem.
4.1.4.3 Signaling Link Overload Causes and Outages, and Associated

Fixes
Signaling link blocking or outages may still occur even if all the suggested optimization steps are
followed. Given below are some common conditions that will result in such signaling link
blocking or outages and their associated fixes and suggestions for improvements.
4.1.4.3.1 Signaling Link Overload
As cell sites carry more traffic, signaling information controlling those calls increases as well. For
cells carrying a lot of call traffic, as well as for sites located in MSC border areas (where
registration or paging activity is usually higher) or other areas where other signaling messages
may be utilized, signaling links may become overloaded. Severe overload may result in signaling
messages being dropped, which may affect overall cell site performance.
o Service measurement peg counts indicate high peak and average Signaling Link
occupancy. Examining service measurements that indicate the peak and average
Signaling Link occupancy may point towards signaling link capacity exhaustion. High
signaling link occupancy must be consistent and should coincide with periods of high
traffic. These service measurements are found in the CDMA-CS and CDMA Subcell sub-
sections, see [23] for more information.
If it is confirmed that signaling links are overloaded, it is recommended that the customer
Operations team be notified of the problem. It may be necessary to offload traffic of this
cell/carrier to neighbor cells or carriers.

71
For Release 25, two new Flexent-only features may be used to better manage high signaling link
occupancy. The first one is Traffic Overload for Flexent Platforms (Part 2), which uses signaling
occupancy measurements as inputs to the CDMA Traffic Overload Control feature. This feature
ensures cell sites operate in a predictable manner during high loading situations. The Signaling
Link Overload Control Enabled (Frame Relay only) parameter in the cell and ecp forms is used to
enable the Traffic Overload for Flexent Platforms (Part 2) feature.
The other feature, Increase Signaling Link Capacity for URCm in ModCell 1.0, 2.0, 3.0 and
Compact Cell, allows for the use of more than 2 DS0s for signaling links for ModCells 1.0 to 3.0
using the URCm controller. This feature allows the increase of signaling links to 4 DS0s using
the Signaling Link Width parameter in the cdmeqp form. See the Release 25 release letter for
more information.
For Release 26, for ModCells 4.0 and 4.0 Compact, the new “Increased Signaling Link Capacity
For ModCell 4.0 And Compact 4.0” feature increases the signaling link capacity from 2 DS0s to
4 DS0s for these ModCells with all UCR types. See the Release 26 release letter for more
information.
4.1.4.3.2 Hardware Outages
Any T1/E1 facilities problem may cause the signaling links to go down. If a cell site looses its
backhaul connection to the MSC, the signaling links will also go down. The backhaul connection
may be lost for several reasons, including cell site hardware outages, DACS outages, and others.
As with the packet pipes, hardware outages may be viewed on the ECP Control & Display page
and may also be captured in the ROP as HEH messages. Both the ECP Control & Display pages
and the ROP messages may help narrow down the cause of the outage.
Due to the magnitude of ROP file sizes, they are best analyzed using filtering scripts. Many such
scripts exist, an example being the SPAT tool that has a component to perform such analysis
(Appendix B provides an overview of this tool).
As backhaul outages may be caused by multiple hardware problems, it is recommended that the
customer Operations team be notified of the problem.
Prior to Release 27, changing Signaling Link related parameters in translations using RC/V was
causing cell sites to reboot without any warning. This would cause major impacts to overall
resource availability. Changes to the following parameters were causing these reboots:
 cdmeqp form: Signaling Link Width, AP Signaling Link Information for Connections at the
AP: Primary AP DS1/DS0, AP Signaling Link Information for Connections at the AP:
Alternate AP: DS1/DS0.

72
 btseqp form: Signaling Link Width, AP Signaling Link Information for Connections at the
AP: Primary AP DS1/DS0, AP Signaling Link Information for Connections at the AP:
Alternate AP: DS1/DS0.
 cmodeqp form: Primary Application Processor Number, Alternate Application Processor
Number.
 apeqp form: DS1 Configuration: Link Speed
A software change in RC/V was made in Release 27 warning users that changes to these
parameters are service affecting. See AR 1-1401772 for more information.
Additionally, sites may be reporting missing overhead channels (Pilot, Paging, and Sync
channels) as a result of DS1 issues. Frequent major or critical alarms with DS1 facilities may
cause problems re-enabling the overhead channels as a result of the DS1 recovery. This has been
mostly observed with cells having one CDM and one CCU. Thus it is always good practice to
clear out any possible issues with noisy T1s or other DS1 issues. See AR1-1492957 and Lucent
Alert 06−0547.
4.1.4.3.3 Incorrect Provisioning or Inadvertent Changes to Facilities Translations
T1/E1 facilities and their associated signaling links need to be provisioned through translation
parameters. The provisioning indicates to the cell sites and to the mobile switching center which
DS0s to use for signaling among other things. Errors in provisioning new T1/E1 facilities, or
signaling links, or sudden changes to existing facilities or signaling links translations, may cause
signaling links to go out of service.
Improper translation settings for new facilities and signaling links usually result in the inability to
communicate to the cell site from the MSC. This may be verified by consulting the ECP Control
& Display pages and may also be captured in the ROP.
Accidental translations changes, if they are serious ones, will typically result in a sudden, severe
performance degradation starting the instant the change was made effective at the switch.
Capturing these changes is not always easy because of the sheer number of translations that exist.
However, efforts should be focused on translations that are likely to have an impact in the
communication between the MSC and the cell sites. It is also effective to use tools that provide
reports of translations and translation changes. The SPAT tool (Appendix B) provides for such a
feature. Finally, it should be noted that all changes to translations are captured on a daily basis by
the switch and saved in files in the OMP. The login userids are also tagged with these changes.
Lucent support center or the customer’s operations team should be contacted if these files need to
be viewed.
Once identified, the solution will be to correct, or reverse, the translation error. Proper
documentation should always be maintained for all translation changes to help track root causes

73
of performance problems. Also, consult the askLucent web site and [45] for more information on
signaling link problems.
4.1.5 Forward Power Resource Blocking Analysis
4.1.5.1.1 Conceptual Overview
These failures happen when the sector processing the mobile call request does not have sufficient
forward power resources to support the call, a condition known as forward power overload.
With the older algorithms, this occurs when the power being utilized by that cell exceeds the
Lower Threshold which is a percentage of Max Power, both of these being parameters that may
be set in translations. This is known as the Gain Clipping (GC) algorithm.
Recently, improved algorithms were introduced to better trigger and manage this overload
condition. This algorithm is known as the Aggregate Overload Control (AOC) [5].
The following sections discuss the various details related to both of these overload algorithms.
Forward Link Overload Thresholds
As mentioned above, there are two distinct algorithms used to implement the forward link
overload mechanism, namely, the Gain Clipping (GC) algorithm for pre-Release 16.0 cells and
the Aggregate Overload Control (AOC) for Release 16.0 and greater. Note that with Release 16.0
and greater, the choice is given to implement either algorithm on a per-cell basis. The GC
algorithm was decommissioned starting with Release 17.03, and will no longer be an option for
overload control after this release.
With the GC method, two thresholds are set on both the forward and reverse links to manage the
power utilization, namely the Lower Power Threshold (lower_pwr_thresh) and the Upper Power
Threshold (upper_pwr_thresh), both set in the ecp/ceqface database forms. All new calls are
blocked when the power utilization crosses the lower threshold. All handoffs are also restricted,
in addition to new calls, when the power utilization crosses the upper threshold. Typical values
for these thresholds on the forward link are 85% and 90% of the BBA Max. Power (max_power)
translation, which is set in the ceqcom2/crceqp/cdmeqp/bbueqp forms based on cell type.
With Release 16.0, the AOC method for downlink overload control was introduced. With AOC,
two new thresholds were introduced to replace the lower and upper thresholds described above.
The new thresholds are the Scaling Power Threshold (aoc_pwr_thresh) and the Call Blocking
Power Threshold (block_pwr_thres), both set in the ecp/ceqface database forms.
When the short-term power utilization exceeds the scaling power threshold, the entire output
power is reduced. That is to say, every user in the system now is offered a slightly lower power,
in addition to lowered powers on the overhead channels (pilot, page, sync and access). This

74
allows for a graceful, temporary degradation in performance across all users until the short-term
power surge dissipates.
When the long-term power utilization exceeds the new call blocking power threshold, all new
(non-emergency) calls are blocked, but handoffs are still permitted. This blocking will occur until
the long-term power utilization falls back below the threshold by a certain amount (as defined by
other hysteresis settings).
Note that handoffs are never blocked with the AOC algorithm, in contrast to the GC algorithm.
The only exception to this is when the amplifier enters the AOC cool-down state, which is an
additional safeguard built in to the AOC algorithm to prevent over-driving the amplifier.
Handoffs will be rejected when the amplifier is in this state.
With the introduction of the ModCell 4.0 platform, an improved implementation of AOC, known
as Improved Aggregate Overload Control, was introduced. IAOC, available only in ModCell 4.0
cell sites, uses the same thresholds as AOC but operates at a much faster rate since it calculates
the total forward link transmit power on a per PCG basis (AOC functions at 50Hz while IAOC
works at 800 Hz). Calculations are done on all overhead channels, voice and data channels,
OCNS and Markov calls. IAOC functions in a similar way as AOC with respect to the Scaling
Power Threshold (aoc_pwr_thresh) and the Call Blocking Power Threshold (block_pwr_thres): if
the longer term unscaled average output power exceeds the Call Blocking Power Threshold, new
non-emergency calls are blocked, but handoffs are still permitted.
IAOC differs from AOC in that Multi-Carrier Control has replaced the cool-down state, whereby
the 3-second, 2-minute and 20-minute average aggregated power of up to 3 carriers is controlled.
The output power is controlled by an additional scaling factor determined by the multi-carrier
control algorithm. So the total output power under multi-carrier control is determined by the
IAOC 800 Hz scaling factor as well as the multi-carrier control scaling factor. While in multi-
carrier control, IAOC does not block handoffs.
A more detailed presentation on AOC and IAOC is presented in [5].
Capacity Enhancement Feature
Another important concept to understand is the application of scaling factors to scale up the
downlink overload thresholds, which in turn will allow more power to be utilized on the
downlink. These scaling factors may be applied to both the GC and AOC thresholds. This is
known as the Capacity Enhancement Feature.
The motivation for having these scaling factors is a result of the observation that the ratio of peak
energy to average energy utilized in the downlink was high. This means that bursts of high peak
energy frequently triggered the overload thresholds even though the average energy transmitted
by the amplifier was comfortably below its specifications.
Therefore, scaling factors were applied to increase the threshold levels at which overload will
occur beyond the specifications of the transmitter with the goal of achieving an average power
transmission that is more in line with these specifications. The net effect of doing this is to
increase the traffic load that can be carried on the downlink before triggering the overload
thresholds.

75
The translation used to perform this scaling is the Traffic Channel Voice Activity Factor
(tcvact_fact) in the ceqface form, which was previously an unused translation in the database.
The table below gives the valid settings for this translation and their corresponding scaling
factors.
Table 4.3 VOICE ACTIVITY FACTOR SETTINGS AND CORRESPONDING

SCALING FACTORS
Voice Activity Factor Multiplier Factor

ceqface
0.30-0.50 1.00 (Disabled)
0.55 1.00 (Disabled)
0.60 1.06
0.65 1.13
0.70 1.19
0.75 1.25
0.80 1.31
0.85 1.38
0.90 1.44
0.95 1.50
1.00 1.50
These scaling factors will only be applicable for certain types of amplifiers. In particular, these
scaling factors will not affect the HPCTU/HPCA (16W) amplifiers as well as amplifiers from
other vendors (type OV). The tcvact_fact translation will therefore be ignored if these types of
amplifiers are installed on the cell.
A related concept is that of cool-down modes. If the traffic load conditions on a sector result in
the peak energies being utilized for extended periods of time, then this could potentially damage
the transmitter, since the average power utilization may now run beyond the specifications.
A mechanism is therefore in place to step the overloads back to their original values, that is,
remove the scaling factors, for a period of time until the power utilization is reduced. The
amplifier is said to be in a cool-down state when this happens. The scaling factors are
reintroduced after the power utilization is reduced by triggering handoff and call blocking by
virtue of the new lowered thresholds.
Amplifiers entering into the cool-down state will introduce serious power resource blocking
problems for the period of time that they are in cool-down state. Therefore, it is always preferable
to upgrade the amplifiers to the high power ones (HPCTU/HPCA) on very heavily loaded sectors,
especially those that have a track record of going frequently into overload.

76
Special Limitation on ModCells – Potential for Early Overload
The current versions of Flexent ModCells have an additional limitation whereby the long term
average of the sum of the squared digital gain units16 (dgus) should not exceed 77,760, times a
multiplicative factor based on the voice activity factor translation (capacity enhancement feature,
discussed above).
If this limit is exceeded, then the forward power overload counters and algorithm will be
triggered, even if the actual lower threshold in power consumption is not reached. This scenario is
possible under certain combinations of amplifier type and power calibration option selected.
The solution to this problem is to ‘fool’ the base station by reducing the dgu values used while
maintaining the actual transmitted power. This can be achieved by reducing the Pilot, Page, Sync,
Nominal Traffic, Minimum Traffic and Maximum Traffic dgu translations by 1dB, while also
reducing the CBR attenuation by 1 dB. All of these settings may be set globally in the ecp form,
and overridden on a sector-by-sector basis in the ceqface form. This ensures that the output power
remains the same, but changes the relationship between dgus and actual output power to reduce
the dgu values used.
For Release 23 the dgu limit of the ModCell 4.0 using the UCR radios may be increased to three
times the previous limit (or 233,280 dgus). The Auxiliary Sector Control 3 parameter in the
ceqface form is used to enable this new limit, which allows pilot fractions to be set below the
recommended 15%. However, care must be taken so that, as the pilot fraction is decreased, the
received Ec/Io does not degrade to the point where performance is impaired. For more
information on setting the Auxiliary Sector Controls, see [4] and the appropriate Cell Software
Release letter. Due to limited experience with the new dgu limit it is recommended that it not be
enabled. For Release 25, the new “Customer Critical Translations Maintenance - Phase 1” feature
does not rely on the use of the Auxiliary Sector Control 3 parameter in the ceqface form to control
this increase in the dgu limit. Instead, this new feature hard coded the dgu limit increase to be
available all the time for ModCells 4.0 using the UCR and MCR radio.
For Release 24 new counts pegging the Average Digital Gain Units on forward voice and data
traffic channels may be used to trend dgus over time. This information may be useful when
deciding to expand the dgu limit for UCR radios. See [23] and the appropriate release letter for
more information.
These new counts provide averaged dgu values used by either voice or data users. These counts
are derived by taking the sum of the dgu^2 values divided by the number of voice or data users
every 20 ms. Thus, the peg counts represent the square root of this average. Because usage is
factored out by dividing by the number of users, it does not represent the power used by each type
of service. To determine the voice vs. data power usage you need to multiply the average dgu
values of these new counts by their FCH usage (for example by using the voice and data FCH
frame counts).
16
Digital gain units (dgus) are a measure of per-channel output power from the base stations. Dgus have a square
relationship to the output power (Watts). The actual conversion from dgus to output power in Watts is established
during power calibration. The overhead and traffic channels are set to pre-defined dgu values and the combined output
power from these channels is subsequently tuned to the desired total power as per the selected calibration option.

77
Multi-Carrier Considerations
It should be noted that if a sector has multiple carriers configured on it, then each of these carriers
will have its own power amplifier (PA). This implies that each carrier of each sector can
independently go into power overload on either link.
Therefore, when troubleshooting forward power overload problems, it is important to examine the
carried traffic and overload on each carrier of the problematic sector.
Because of the efficiency of the carrier assignment algorithms (when configured correctly – see
Section 4.1.2.1.3), calls should be very evenly distributed across carriers on a particular sector
under normal operating conditions.
If a significant mismatch in carried traffic is observed resulting in the bulk of overload problems
occurring only on a single carrier, then this would imply that some other problem exists on the
carrier carrying less traffic, as opposed to a fundamental problem with overloaded capacity on
that sector.
The exception to the statement above is if one or more of the carriers are configured as border
sectors (handdown or pilot-only). Border sectors will, by definition, carry less traffic because they
are constantly attempting to transfer the calls to the common carriers.
Typical Erlang Ranges
The actual loads that can be carried by CDMA sectors can vary significantly based on the RF
conditions, sector coverage and user patterns. However, certain rules of thumb may be established
for typical Erlang values that should be able to be carried by sectors.
The following table provides typical primary Erlangs that can be supported by each sector for a
single carrier. These numbers are obtained from [1], and assume that all traffic is purely 2G Voice
or purely 3G-1X Voice. For mixed traffic systems, the effective peak primary Erlangs are
between 7.4 (or 13.2) and 18.4 per sector per carrier for Erlang-B blocking of 2%.
Table 4.4 TABLE OF TYPICAL PEAK PRIMARY ERLANG VALUES
2G 3G
Erlang-B Typical Peak Erlangs Typical Peak Erlangs Typical Peak Erlangs
Blocking All Mobiles Rate Set 2 All Mobiles Rate Set 1 All Mobiles 8k (RC1)
1% 6.6 12.0
2% 7.4 13.2 18.4
4.1.5.1.2 Important Lucent Features and Translations
It is recommended that the cells meet the following translations recommendations to ensure that
there are no fundamental problems with the way in which power is utilized.
 Ensure that the Traffic Channel Voice Activity Factor (tcvact_fact) in the ceqface
form is set to a value of 1.00 (multiplicative factor of 1.5) across all sectors in the

78
system. Note that this setting may be applied indiscriminately, even to the high power
amplifiers (HPCTU/HPCA), since these amplifiers ignore the translation anyway.
 Ensure that all the amplifier types entered in translations (ceqcom2/
crceqp/cdmeqp/bbueqp forms based on cell type) match those actually installed on
the site.
 Ensure that the max_power translations in the ceqcom2 database (or the
crceqp/cdmeqp/bbueqp forms based on cell type) match the amplifier types installed
at the corresponding sites. Note that if any changes to BCR/CBR are done, then this
max_power translation will have to be changed accordingly to maintain the pilot
power to total power ratio. Please refer to [3] and [4] for details on this relationship.
Note that in some cases this rule can be broken and max_power may be left at the
maximum amplifier rated power to alleviate forward overload problems. If this is
done, then care must be taken to ensure that there were no undue performance or
coverage problems created by violating the pilot fraction of total power rule.
In addition, the AOC algorithm should be implemented for all cells for the forward link, if
available. The full recommendations for all the translations related to this feature may be found in
[5].
4.1.5.1.3 Forward Power Resource Blocking Management Techniques
The suggestions below describe how to manage forward power resource blocking, either
proactively before they occur or reactively once they already exist on one or more sectors. The
assumption in this section is that the cell is operating normally with traffic balanced across all
carriers (assuming it’s not a border sector), and the Voice Activity Factor settings are set
appropriately for the amplifier types to maximize the power utilization on the amplifiers. The
next section deals with situations when this is not the case.
It is important to note that the performance of sectors typically start to degrade even before power
overload conditions occur. It is therefore important to have a process in place to extrapolate sector
traffic loads on a regular basis and proactively apply the measures listed below before power
overloads even surface.
Short-Term Solutions to Fixing Forward Power Overload Problems
Given below are some suggestions to fixing power overload problems for the short-term until
other medium and long-term solutions can be put in place, if deemed necessary.
1) Offload the heavily loaded sectors using any combination of physical antenna changes
(reorientations, downtilts, antenna model changes etc.) and/or parameter changes
(attenuation, handoff parameters etc.). If attenuations are being changed, then the BBA
Max. Power (max_power) translation (set in the ceqcom2/crceqp/cdmeqp/bbueqp forms
based on cell type) must be changed accordingly to preserve the quality of the calls (see
[3] and [4] for details on this mapping).
2) While not recommended unless as a last resort, the overload thresholds may be increased
to delay when the cells go into overload. It is very important to refer to [5] when
attempting to do this because there may be other translations that also have to be changed
in conjunction with these overload thresholds.

79
The reason why this solution is not recommended is that it does not help fix the problem
fundamentally, but rather just delays its impact. Therefore, it is highly likely that in a
growing system the overloads will surface soon anyway. The other problem with raising
the thresholds is that it places a heavier burden on the already overloaded amplifiers,
increasing the chances of damaging it permanently.
1. Manage the Forward Power Overload by controlling voice or data call admission using
the “3G-1X Call Admission Policy with System Resource Reservation Based on RF
Power” see [39] for more information. This feature may be used to manage the admission
of voice or data calls using RF power as a limiting factor, however it does not solve the
fundamental issue.
Medium-Term Solutions to Fixing Forward Power Overload Solutions
The medium-term solution to fixing power overloads is to add additional carriers to the affected
sectors, and possibly some surrounding sectors for performance reasons. Typically, there will be
justifications required and significant costs involved with this option. This coupled with the
construction and equipment delivery time will typically only make this solution available a few
months later, thus will not be an effective short-term solution.
Of course, if a good practice of regularly projecting traffic Erlangs is in place, then markets can
anticipate the need for these additional carriers and have them installed in a timely manner, just in
time when they are really needed.
Long-Term Solutions to Fixing Forward Power Overload Solutions
In CDMA systems, extremely loaded areas will begin to potentially lose coverage due to the high
level of interference resulting in none of the pilots being dominant enough to overcome it.
Therefore, if coverage improvement is also a criterion, then the long-term solution would be to
add additional cells in the heart of the high capacity areas. This is obviously a long-term solution
because the cycle of design, cell selection, construction and optimization has to be performed.
Typically, this solution will be in the order of several months.
4.1.5.2 Forward Power Resource Blocking Causes and Associated Fixes
4.1.5.2.1 Sector has reached Capacity Limit
Sectors that have utilized all of their available forward power on all carriers on the forward link
will start blocking new calls, and possibly handoffs as well.
A sector may be deemed to have truly reached its capacity limitations if all carriers of the sector
are carrying high Erlangs that are approximately evenly distributed across these carriers. The
latter should result in approximately equal power overload durations on all sectors.

80
A second factor is that this sector should meet acceptable standards for soft/softer handoff
percentage. Otherwise, though this sector has reached its capacity limitations from a power
budget point of view, some of this power could potentially be shed if the soft handoff percentages
are brought back in line. Section 4.1.5.2.2 delves into this topic in detail.
Similarly, sectors in which the high traffic utilization and/or power overloads are biased only
towards a subset of the carriers are not an indication of true power capacity problems, but rather
are indicative of some other problem with the cell site configuration and/or hardware. This type
of problem is discussed in detail in Section 4.1.5.2.4.
If the affected sectors are deemed to have truly reached their capacity limitations, then the short,
medium and long-term suggestions in Section 4.1.5.1.3 should be followed to alleviate the
problem.
As discussed in Section 4.1.5.2.1 above, sectors could be running out of power budget because of
excessive soft handoff activity that would result in unnecessary power being utilized.
A disciplined approach to reducing these percentages to acceptable levels could result in

improved performance at many levels. There will be less interference in the network, which will
likely improve the performance of all the calls in the area. Also, reducing soft handoff
percentages will translate to reduced cell hardware resource utilization, which would translate to
significant cost savings for the operator in terms of channel element cards and packet pipes.

measurements. Examining the primary and secondary usage on these sectors does
this. The ratio of secondary usage to total (primary + secondary) usage gives the soft-
handoff percentage. Percentages much larger than 50% should be flagged for
problems.
17

81
The following two approaches should be followed if it is suspected that excessive soft-handoff
zones are causing a rise in TCCFs.
 Reduce the soft-handoff zones through optimization to improve the pilot quality
of the primary sector handling the call setup. Optimization may come in the form of
physical optimization (changes in antenna orientation, downtilt, model etc.) and/or
BCR/CBR attenuation changes.
 Turn on and optimize IS95B handoff algorithm parameters on that sector. The
IS95B standard introduced several enhancements to the method in which sectors are
selected to be in the Active Set of a CDMA call, with the intention of limiting this
selection to only sectors that are most likely to have a meaningful contribution to the
quality of the call. These algorithms were subsequently adopted by the IS2000
standard as well.
It is very important to note that even if these features are activated, only IS95B and
IS2000 mobiles will be able to take advantage of these enhancements. Therefore, in
markets where the penetration of such mobiles is low when compared to IS95A
mobiles, turning on these features will have negligible impact on the soft-handoff
percentage. For Release 26, the IS95B handoff algorithm has been further improved
by having the cell sites prevent pilots with Ec/Io values below the dynamic add
threshold from entering the active set. This enhancement is controlled using the
Auxiliary Cell Control 2 translation parameter in the cell2 form. See the Release 26
release letter for more information.
4.1.5.2.3 Incorrect Setting of VAF Causes Early Overload
As described in Section 4.1.5.1.1, it is recommended that all amplifiers maximize the overload
threshold scaling whenever possible, by setting the tcvact_fact translation to 1.00. Failure to do
this will cause sectors to go into overload early on the forward link with only modest traffic loads.
Failure Symptoms and Identifying Techniques
 Perform translations audit. The easiest way to detect this problem is by doing a
system audit on this setting on all cells in the system. The SPAT tool (Appendix B)
performs such an audit.
 Examine peak power utilized per sector-carrier through service measurements.
If the tcvact_fact setting is set incorrectly, then it will be observed that the sector will
be going into overload with power levels that are well below the maximum that
should have been capable if the maximum multiplicative factor had been correctly
applied to the sector (see Table 4.3).

82
 Examine peak Erlang utilization at sector-carrier. Alternatively, this problem may

also be captured if it is noticed that sectors are not achieving peak Erlang values
anywhere close to those specified in Table 4.4. A caveat to this method of detection
is that the actual maximum traffic that can be carried by any individual sector is
highly dependent on several factors such as the RF environment, interference levels
and user patterns. Therefore, it is conceivable that some sectors may authentically
only be able to support much lower Erlangs despite the fact that the overload scalars
are maximized.
If not done so already, the tcvact_fact translation setting in the ceqface form should be set to 1.00
(multiplicative factor of 1.5) across all sectors in the system. Note that this setting may be applied
indiscriminately, even to the high power amplifiers (HPCTU/HPCA), since these amplifiers
ignore the translation anyway.
4.1.5.2.4 Overload Not Detected on All Carriers of Multi-Carrier Sector
With non-border sectors, all situations when overloads are not detected roughly equally on all
carriers of a multi-carrier sector indicated a problem with one or more carriers of that site.
Given below are some common reasons why this may occur, identifying techniques and
suggested fixes.
overloads.
share the same transmit antenna. If this is the case, then this cause may be ruled out as being the
root of the problem.
possible that the antennas may not be equally affected by physical obstructions on-site. If this is
the case, it may be necessary to relocate all the antennas, if adjusting their elevations and/or
azimuths will not clear these barriers.
this will result in unequal load balancing and consequently, unequal observed power overload
durations.

83
itself. Sweep tests are also capable of isolating the problem down to the precise components that
are failing (connectors, jumpers etc.).
If the IFHOTI algorithm is not used on the border sector, then implement this feature so as to
carry more traffic on the border carrier. Section 4.1.2.1.3 discusses this algorithm in more detail.
Reference [9] is also required reading before any attempt is made to implement and optimize this
feature.
levels. Alternatively, this border sector could be converted to a full-traffic sector, if possible18.
adjacent cells and make this border carrier now carry full traffic. This is of course a medium-term
to long-term solution because of the costs and justifications required to make this happen.
Output Power Drifts or Miscalibration
The output power being transmitted out of the problematic carrier of the sector may be
miscalibrated or drifting. This could be because of a problem with the amplifier, lack of sufficient
preventive maintenance calibrations or because the power was never calibrated correctly to begin
with.
This problem could be detected in a number of ways. If the CDMA Radio Test Units
(CRTU/CTRMs) are operational at the cell, then a Pilot Level (PL) functional test (FT) may be
performance to check the output power. This test will indicate problems with the output power,
assuming the CRTU/CTRM is properly calibrated.
Alternatively, the output power may be verified on-site using a power meter. Note that the testing
technician must have explicit knowledge of the calibration option selected for that carrier because
the output power varies according to the option selected.
Power drifts are not as easy to capture. One method is to run periodic CRTU/CTRM PL FT’s and
examine the measured output power in the ROP. A drifting power amplifier will manifest itself in
a large variance in measured pilot power over time. Alternatively, the actual output power may be
measured over a long period of time on-site. This option is however highly undesirable because
the sector will be out of service on that carrier during this entire test.
18
Sometimes the initial design of border sectors is conservative, and it is possible to convert some of these border
sectors to full-traffic sectors through more careful multi-carrier optimization (see [20] for detailed procedures on such
optimization).

84
Miscalibrated powers may be easily rectified by performing the calibrations according to the
Methods and Procedures guidelines for the appropriate calibration option. References [3] and [4]
go into great detail on these options. Additionally, CDMA RF power calibration manuals are
available, see [47], [48], and [49] for more information.
Power drift problems may usually be resolved only through hardware replacements.
techniques.
Note that, in order for this cause to be determined as the root cause for the differences in carried
traffic observed, it must be true that the carrier with the lower number of traffic-equipped CEs is
in forward overload. If this is not the case, then this implies that even the lower number of traffic-
equipped CEs is sufficient to handle the call volume for that carrier, and therefore, will not be the
cause for differences in carried traffic between the carriers.
Hardware Outages
include CCCs/CDMs, channel cards (ECU/CCU-20, ECU/CCU-32), Packet Pipes (PPs), T1
spans, etc.
service measurements would be to examine the peak channel elements used. The peak channel
elements used during the hours of blocking will be significantly lower than the number of traffic-
equipped CEs at the cell in cases when the blocking is due to hardware outages.
Inconsistent Attenuation Settings across Carriers
Attenuation settings (BCR/CBR) can be set independently for each carrier of a sector. Therefore,
a mismatch in carried traffic could be observed between the carriers of a sector if they are
configured with different attenuation settings, either intentionally or inadvertently. This would
result in greater power overloads observed on the carriers with less attenuation, since they will
carry more traffic.
Note that specific carriers are sometimes configured with greater attenuation on border sectors,
but are later not changed to be consistent with the rest of the carriers as the system grows and that
sector becomes full-traffic.

85
The solution to this problem is to conduct regular translation audits to verify that all carriers of all
sectors in the system are configured with the same attenuation values, unless there are good,
documented reasons why they should be otherwise.
Improper Setting of Carrier Assignment Algorithm
This is especially pertinent with 2G/3G1X mixed systems. Improper setting of 2G and 3G Load
Preference Deltas can potentially cause big differences in carried traffic amongst carriers of the
same sector. This is especially true if the 2G/3G Load Preference Delta settings are not aligned
with the actual 2G/3G1X traffic distribution. A detailed description of these settings is presented
in Section 4.1.2.1.3.
4.1.6 Reverse RF Loading Resource Blocking Analysis
These failures happen when a sector rejects new mobile calls or handoff requests because it is
experiencing high reverse link loading, a condition known as reverse power overload. This
mechanism is required to preserve the integrity of the reverse link, which could otherwise go into
an unstable state if the reverse loading becomes too high.
There are also two algorithms for reverse link overloads, namely the Reverse link Overload
Control (ROC) and Improved Reverse link Overload Control (IROC) algorithms. IROC was
introduced with Release 16.1 to address some of the shortcomings of the older ROC algorithm.
The following sections discuss both of these overload algorithms.
Reverse link Overload Control (ROC) Algorithm
The ROC algorithm uses only the Received Signal Strength Indicator (RSSI) rise over Noise
Floor to determine the extent of the reverse link loading.
The overload mechanism is administered by setting two thresholds, namely the R.L. Overload
Control Lower Power Threshold (lower_rev_load) and the R.L. Overload Control Upper Power
Threshold (upper_rev_load) in the ecp/ceqface forms. All new calls are blocked when the power
utilization crosses the lower threshold. All handoffs are also restricted, in addition to new calls,
when the power utilization crosses the upper threshold. Typical values for the reverse link are
75% and 100% of pole capacity19.
It is not recommended that the ROC feature be activated because of limitations in the algorithm’s
ability to estimate the noise floor accurately, resulting in false triggering of reverse power
19
The % of pole capacity is translated to RSSI rise over Noise Floor based on standard theoretical calculations. It is this
dB rise over noise that is monitored by the cell site to trigger the appropriate actions based on the ROC algorithm.

86
blocking. Setting the upper_rev_load to 100% in the ecp/ceqface database forms can deactivate
the feature. The lower threshold may still be set to any desired level, which in turn will still
trigger (non service-affecting) reverse power overload counts in service measurements. The
IROC feature was introduced to overcome these limitations in the ROC algorithm and is
recommended for use in place of the ROC feature.
Improved Reverse link Overload Control (IROC) Algorithm
IROC improves on the ROC algorithm by using more inputs to arrive at a more accurate picture
of the true reverse link loading present at the sector. Specifically, the algorithm correlates the
RSSI rise over Noise Floor to two other inputs, namely the number of users (Walsh Codes) and
the Reverse Frame Error Rate (RFER).
It is deemed that there is truly high reverse link loading when all three of these indicators point to
a high loading condition. That is, there is a high RSSI rise over Noise Floor, high RFER and a
large number of users. If there are fewer numbers of users, and/or if the RFER is low, then a
greater RSSI rise over Noise Floor is allowed before any blocking conditions are implemented.
Unlike ROC, it is recommended that IROC be enabled on all sectors, especially in the presence of
HSPD calls. This is because these IROC thresholds are also used to manage the packet data call
admission. For 2G cells however, the upper limit may be set at 60 dB and the RFER Threshold
set at 20%. This effectively disables the reverse link overload algorithm for 2G calls, but enables
monitoring of the reverse loading levels. A full discussion on IROC, as well as all related
recommended translations, is presented in [6]. For Release 22.01, IROC was improved to support
an hourly noise floor figure per sector and carrier. This capability was controlled by the Auxiliary
Sector Control 3 parameter in the ceqface form. For Release 25, the new “Customer Critical
Translations Maintenance - Phase 1” feature introduced a new translation called Control for
Adaptive RSSI Noise Floor Algorithm in the ceqface3g form parameter that replaces the use of the
Auxiliary Sector Control 3 to enable or disable the hourly noise floor measurements. See the
Release 25 release letter and [6] for more information.
Multi-Carrier Considerations
It should be noted that if a sector has multiple carriers configured on it, then each of these carriers
will have its own receiver. This implies that each carrier of each sector can independently go into
reverse overload. Therefore, when troubleshooting reverse overload problems, it is important to
examine the carried traffic and overload on each carrier of the problematic sector.
Because of the efficiency of the carrier assignment algorithms (when configured correctly – see
Section 4.1.2.1.3), calls should be very evenly distributed across carriers on a particular sector
under normal operating conditions.
If a significant mismatch in carried traffic is observed resulting in the bulk of overload problems
occurring only on a single carrier, then this would imply that some other problem exists on the
carrier carrying less traffic, as opposed to a fundamental problem with overloaded capacity on
that sector.
The exception to the statement above is if one or more of the carriers are configured as border
sectors (handdown or pilot-only). Border sectors will, by definition, carry less traffic because they
are constantly attempting to transfer the calls to the common carriers.

87
Typical Erlang Ranges
The actual load that can be carried by CDMA sectors can vary significantly based on the RF
conditions, sector coverage and user patterns. However, certain rules of thumb may be established
for typical Erlang values that should be able to be carried by sectors.
The following table provides typical primary Erlangs that can be supported by each sector for a
single carrier. These numbers are obtained from [1], and assume that all traffic is purely 2G Voice
or purely 3G-1X Voice. For mixed 2G/3G Voice traffic systems, the effective peak primary
Erlangs are between 7.4 (or 13.2) and 18.4 per sector per carrier for Erlang-B blocking of 2%.
Table 4.5 TABLE OF TYPICAL PEAK PRIMARY ERLANG VALUES
2G 3G
Erlang-B Typical Peak Erlangs Typical Peak Erlangs Typical Peak Erlangs
Blocking All Mobiles Rate Set 2 All Mobiles Rate Set 1 All Mobiles 8k (RC1)
1% 6.6 12.0
2% 7.4 13.2 18.4
4.1.6.1.2 Reverse RF Loading Blocking Management Techniques
The suggestions below describe how to manage RF loading resource blocking, either proactively
before they occur or reactively once they already exist on one or more sectors. The assumption in
this section is that the cell is operating normally with traffic balanced across all carriers
(assuming it’s not a border sector). The next section deals with situations when this is not the
case.
It is important to note that the performance of sectors typically start to degrade even before
overload conditions occur. It is therefore important to have a process in place to extrapolate sector
traffic loads on a regular basis and proactively apply the measures listed below before power
overloads even surface.
Short-Term Solutions to Fixing Power Overload Problems
Given below are some suggestions to fixing overload problems for the short-term until other
medium and long-term solutions can be put in place, if deemed necessary.
 Offload the heavily loaded sectors using any combination of physical antenna
changes (reorientations, downtilts, antenna model changes etc.) and/or parameter
changes (attenuation, handoff parameters etc.). If attenuations are being changed,
then the BBA Max. Power (max_power) translation (set in the
ceqcom2/crceqp/cdmeqp/bbueqp forms based on cell type) must be changed
accordingly to preserve the quality of the calls (see [3] and [4] for details on this
mapping).
 While not recommended unless as a last resort, the overload thresholds may be
increased to delay when the cells go into overload.

88
The reason why this solution is not recommended is that it does not help fix the
problem fundamentally, but rather just delays its impact. Therefore, it is highly likely
that in a growing system the overloads will surface soon anyway.
Medium-Term Solutions to Fixing Overload Solutions
The medium-term solution to fixing overloads is to add additional carriers to the affected sectors,
and possibly some surrounding sectors for performance reasons. Typically, there will be
justifications required and significant costs involved with this option. This coupled with the
construction and equipment delivery time will typically only make this solution available a few
months later, thus will not be an effective short-term solution.
Of course, if a good practice of regularly projecting traffic Erlangs is in place, then markets can
anticipate the need for these additional carriers and have them installed in a timely manner, just in
time when they are really needed.
Long-Term Solutions to Fixing Overload Solutions
In CDMA systems, extremely loaded areas will begin to potentially lose coverage due to the high
level of interference resulting in none of the pilots being dominant enough to overcome it.
Therefore, if coverage improvement is also a criterion, then the long-term solution would be to
add additional cells in the heart of the high capacity areas. This is obviously a long-term solution
because the cycle of design, cell selection, construction and optimization has to be performed.
Typically, this solution will be in the order of several months.
4.1.6.2 Reverse RF Loading Resource Blocking Causes and Associated

Fixes
4.1.6.2.1 Sector has reached Capacity Limit
Sectors that have reached maximum prescribed loading levels on all carriers on the reverse link
will start blocking new calls, and possibly handoffs as well.
A sector may be deemed to have truly reached its capacity limitations if all carriers of the sector
are carrying high Erlangs that are approximately evenly distributed across these carriers. The
latter should result in approximately equal power overloads on all sectors.
A second factor is that this sector should meet acceptable standards for soft/softer handoff
percentage. Otherwise, though this sector has reached its capacity limitations from a reverse
loading point of view, some of this power could potentially be shed if the soft handoff
percentages are brought back in line. Section 4.1.6.2.2 delves into this topic in detail.
Similarly, sectors in which the high traffic utilization and/or power overloads are biased only
towards a subset of the carriers are not an indication of true power capacity problems, but rather

89
are indicative of some other problem with the cell site configuration and/or hardware. This type
of problem is discussed in detail in Section 4.1.6.2.3.
If the affected sectors are deemed to have truly reached their capacity limitations, then the short,
medium and long-term suggestions in Section 4.1.6.1.2 should be followed to alleviate the
problem.
As discussed in Section 4.1.6.2.1 above, sectors could be running into reverse overload because
of excessive soft handoff activity that would result in unnecessary interference on the reverse
link.
A disciplined approach to reducing these percentages to acceptable levels could result in

improved performance at many levels. There will be less interference in the network, which will
likely improve the performance of all the calls in the area. Also, reducing soft handoff
percentages will translate to reduced cell hardware resource utilization, which would translate to
significant cost savings for the operator in terms of channel element cards and packet pipes.

problems.
20

90
If it is suspected that excessive soft-handoff zones are causing a rise in TCCFs, then reduce the
soft-handoff zones through optimization to improve the pilot quality of the primary sector
handling the call setup. Optimization may come in the form of physical optimization (changes in
antenna orientation, downtilt, model etc.).
Note that BCR/CBR changes, as well as other parameter optimization such as manipulating
IS95B handoff algorithm parameters will not help reduce reverse link interference because this
interference will still be present at the receivers regardless of these settings.
4.1.6.2.3 Overload Not Detected on All Carriers of Multi-Carrier Sector
With non-border sectors, all situations when overloads are not detected roughly equally on all
carriers of a multi-carrier sector indicated a problem with one or more carriers of that site.
Given below are some common reasons why this may occur, identifying techniques and
suggested fixes.
overload durations.
share the same antenna. If this is the case, then this cause may be ruled out as being the root of
the problem.
possible that the antennas may not be equally affected by physical obstructions on-site. If this is
the case, it may be necessary to relocate all the antennas, if adjusting their elevations and/or
azimuths will not clear these barriers.
this will result in unequal load balancing and consequently, unequal observed reverse overload
durations.
itself. Sweep tests are also capable of isolating the problem down to the precise components

91
techniques.
Note that, in order for this cause to be determined as the root cause for the differences in carried
traffic observed, it must be true that the carrier with the lower number of traffic-equipped CEs is
pegging handoff overflows. If this is not the case, then this implies that even the lower number of
traffic-equipped CEs is sufficient to handle the call volume for that carrier, and therefore, will not
be the cause for differences in carried traffic between the carriers.
Hardware Outages
include CCCs/CDMs, channel cards (ECU/CCU-20, ECU/CCU-32), Packet Pipes (PPs), T1
spans, etc.
service measurements would be to examine the peak channel elements used. The peak channel
elements used during the hours of blocking will be significantly lower than the number of traffic-
equipped CEs at the cell in cases when the blocking is due to hardware outages.
Improper Setting of Carrier Assignment Algorithm
This is especially pertinent with 2G/3G1X mixed systems. Improper setting of 2G and 3G Load
Preference Deltas can potentially cause big differences in carried traffic amongst carriers of the
same sector. This is especially true if the 2G/3G Load Preference Delta settings are not aligned
with the actual 2G/3G1X traffic distribution. A detailed description of these settings is presented
in Section 4.1.2.1.3.
If the IFHOTI algorithm is not used on the border sector, then implement this feature to carry
more traffic on the border carrier. Section 4.1.2.1.3 discusses this algorithm in more detail.
Reference [9] is also required reading before implementing and optimizing this feature.

92
levels. Alternatively, this border sector could be converted to a full-traffic sector, if possible21.
adjacent cells and make this border carrier now carry full traffic. This is of course a medium-term
to long-term solution because of the costs and justifications required to make this happen.
Significant external interference on the reverse link could drive the sector into reverse overload
even though the carried traffic does not warrant such a high RSSI rise. The IROC algorithm will
have some ability to account for these interference spikes because it attempts to correlate this
RSSI rise with the number of users and measured RFER. Still, the reverse overload conditions
could be triggered if the interference causes enough of an RSSI rise over Noise Floor.
Though there is no absolute method of detecting external interference through service

measurements, this problem may be suspected if a very high RSSI rise on a sector is detected
even though the carried traffic on the reverse link does not justify such high reverse loading.
looking for the areas of concentration in the observed interference. Triangulation methods may
also be used with multiple analyzers or scanners to track the interference source.
The fix would be to remove the stop the source of interference, once identified. Sometimes this
would entail contacting the offending party to terminate the transmissions. The biggest challenge
is usually to identify the interference source to begin with.
The IROC algorithm may need to be disabled or adjusted to prevent unwarranted call blocking
until this interference is eliminated.
21
Sometimes the initial design of border sectors is conservative, and it is possible to convert some of these border
sectors to full-traffic sectors through more careful multi-carrier optimization (see [20] for detailed procedures on such
optimization).

93
4.1.7 Termination Failures Related to Call Delivery Type

There are two common methods of delivering incoming calls when the mobile is not at its home
MSC. They are the Cellular Networking (CN) method and the Special Cellular Networking
(SCN) method. The primary difference between the two is that the CN delivery method uses
inter-MSC trunks to deliver the calls between Mobile Switching Centers (MSCs), while the SCN
method used the PSTN for such delivery.
If the CN delivery type is used in a market, then all TCCFs that occur whenever this delivery
mechanism is utilized are captured as CN Termination TCCFs. This counter will be zero if the
SCN delivery method is used, and all TCCFs will be captured in the traditional TCCF peg counts.
The reasons why these CN TCCFs occur are just the same as those discussed in Section 4.1.2.
The only difference is that the events are captured by a different counter at a system level, as
opposed to the cell level, whenever the CN delivery type is employed to set up a call. The steps
required to optimize these types of TCCFs will be the same as those discussed in Section 4.1.2,
and will not be reiterated here.
It is also possible under special circumstances where there will be additional termination failures
when the SCN delivery method is used. In particular, the SCN delivery method will not allow for
more than one Temporary Location Directory Number (TLDN) to be associated with the same
mobile. A TLDN is assigned to a mobile whenever a call needs to be routed to a Mobile
Switching Center (MSC) other than its Home MSC.
A situation may arise whereby the mobile is physically located in the Home MSC, but still has an
entry in another MSC’s Visitor Location Register (VLR), usually due to registration delays or
configuration errors. When this happens, calls to this mobile will be routed from the Home MSC
(H-MSC) to the Visited MSC (V-MSC) that in turn needs to assign a second TLDN and route
these calls back to the Home MSC. This is sometimes referred to as a “double hop”.
The CN delivery method supports such a scenario, allowing the call setup to proceed. The SCN
delivery method, however, does not allow for such a scenario, resulting in a termination failure.
How the service measurements capture this situation depends on whether flood paging is turned
on or not. Since the network believes that the mobile is in the V-MSC, the mobile will only be
paged eventually in the H-MSC if flood paging is turned on. In this case, a page response seizure
is captured in service measurements, but if SCN delivery is used, a subsequent assignment will
not be pegged because of the problem stated above.
On the other hand, if flood paging is not turned on, then the mobile will never be paged on the H-
MSC. Therefore, no page responses will be captured, effectively resulting in this problem being
missed by service measurements. These types of problems may however be captured by internal
Lucent OMP scripts such as pfpgstats (that is able to monitor all paging activity to arrive at the
true termination failure rates).
If this problem is found to be happening, then the solution will be to migrate the market to CN
delivery type.
For Release 26, the new “CDMA SM Enhancements - Phase 7” feature introduced some new peg
counts than can be used for troubleshooting TLDN timeouts for 2G and 3G terminations. See the
Release 26 release letter and [23] for more information. This new feature also introduced new peg

94
counts for abandoned originations and terminations for 2G and 3G calls before and after traffic
channel assignment. The counts for abandoned originations and terminations are the CDMA-
PAF-CARR-SC 159 to 166 counts.
Prior to Release 27 it was found that the terminations abandoned counts were inconsistently
pegged, such that these counts were larger than the difference between the 2G/3G Page Response
Seizures and their 2G/3G Termination Channel Assignment counts. See AR1-1420642 and the
Release 27 release letter for more information.
4.1.8 Changes to Call Delivery Types

As of Release 27 several of the proprietary call delivery types are to be discontinued beginning
March of 2006. As the ISPAGE and ISPAGE2 features now provide a more complete and
standards-based approach to call delivery, the following features are being discontinued:
 FAF 202 − FTN Inter−Switch Call Delivery (FTNISCD)

 FAF 398 − FYI Page upon Route Request (FYIPURR)
 FAF 407 − Flood Page upon Route Request (FLDPURR)
See Lucent Alert 06−0044 for more information on the discontinuation notice. Also, see [43] for
information in ISPAGE.
4.1.9 Termination Failures due to Registration Problems and Paging

Strategies
Registration is the process by which the mobiles inform the network of their location, allowing
the network to efficiently locate these mobiles to deliver incoming calls. Intimately tied to
registration are paging strategies. Paging strategies determine when and which cells should page
the mobiles for incoming calls.
Depending on how the registration and paging strategies are set up in a market, it is conceivable
that mobiles are sometimes paged incorrectly, resulting in these mobiles never having the
opportunity to receive these pages and respond accordingly. These missed incoming calls
subsequently (usually) get routed directly to voice mail.
It is important to note that this component of the termination failures will not be captured by
service measurements. This is because all termination statistics with service measurements start
with Termination Seizures which are logged when the cell site successfully receives a page
response from the mobile, which will not happen in this case22.
22
Service measurement counters will also miss failures where the mobiles receive the page, but the network, usually
because of RF-related problems, did not successfully receive their response.

95
These types of problems may however be captured by internal Lucent switch-based scripts such
as pfpgstats that are able to monitor all paging activity to arrive at the true termination failure
rates. Alternatively, these failures can be determined from the field by conducting terminations
tests along switch boundaries, where registration and paging problems are most likely resulting in
termination failures.
Because of the strong relationship between the two, registration and paging strategies must
always be considered together to arrive at an efficient configuration. The ideal configuration is
dependent on many factors such as the size of the market, the number of switches, mobility
patterns of users, user density, road patterns, available paging and registration-related equipment
(for instance, type of Home Location Register – HLR), etc. Therefore, every market may have a
different combination of the two strategies based on its particular requirements.
There are two main types of paging strategies, namely, flood paging and smart (directed) paging.
Flood paging refers to the case when all the MSCs in a market are paged for every incoming call.
It is intuitively obvious that this type of paging will maximize the chances that mobiles receives
the page, but at the expense of a high overhead on the paging channels due to a lot of unnecessary
paging on MSCs that the mobiles never even visited.
The alternative is smart paging where only the MSCs that were most recently visited by the
mobiles are paged. While this is a lot more efficient in terms of paging overhead, it introduces the
need for Autonomous Registrations (ARs) by the mobiles to constantly keep the network updated
of their whereabouts. This also introduces the possibility of missed pages if the network does not
have the most updated location of these mobiles at the instant when calls need to be delivered to
them.
A combination of these two paging schemes is also allowed whereby the network makes directed
attempts on the most recently visited MSC initially, and if it still fails to get a page response, then
the flood page is done. This is normally the recommended mode.
Note that an alternative to flood paging is the Intersystem Paging (ISPAGE) feature. ISPAGE has
the same net effect as flood paging, but is implemented differently to support certain switch
hardware configurations that are incapable of implementing flood paging. The Flexent/Autoplex
Wireless Networks Optional Feature Document 401-612-346 contains details on this feature. [16]
also provides an in-depth study and recommendations on this topic.
The topic on ARs is a detailed one and a good reference on this topic can be found in the
Flexent/Autoplex Wireless Networks Optional Feature Document 401-612-009. A summary of
the important points is discussed below.
There are four main situations that could generate ARs, namely:
1) Timer-based Registrations
2) Registrations during Mobile Power Up/Down
3) Zone-based Registrations
4) Registrations during Parameter Change (examples of parameters - slotted vs. non-slotted

mode, slot cycle etc.)

96
All four of these types of ARs should be employed in a market with the correct settings to achieve
the optimal balance between registration activity and termination success rate. The AR
mechanisms that would need the most optimization would be the timer-based and zone-based
registrations. Therefore, the rest of this section will be devoted to the concepts associated with
these two types of registrations.
Timer-based registrations instruct the mobiles to register with the network periodically over fixed
time intervals. This interval period is defined in translations as the field CDMA Time-Based
Registration Period (regprd_c) on the cell2 form and also on a switch-wide basis on the cgsa
form.
Important: There is an exponential relationship between the regprd_c setting and the time
interval. For example, the value 58 for this field corresponds to an interval of 30
minutes, while the value 29 corresponds to only 12 seconds! Therefore, great
care must be taken in ensuring that the correct value is populated in this field;
else there will be an exponential increase in unnecessary registration activity. The
complete mapping for this translation can be found on Table cell2-4 in the
Flexent/Autoplex Wireless Networks Optional Feature Document 401-610-036.
Zone-based registrations instruct the mobile to register every time they cross a zone, a zone being
a collection of cells that are specified in translations to be part of the same location area.
Typically, each MSC is specified to be a single zone. Zone-based registrations are event-based
and may occur as many times as there are zone-boundary crossings. They may coexist with timer-
based registrations.
A potential problem with zone-based registration is if the mobiles are rapidly switching back-and-
forth between zones, causing a tremendous increase in registration activity on these zone-
boundary cells. These registration activities could deplete access channel resources for valid call
attempts and may also dramatically increase the call processing loads on the cells as well as the
Call processing Database Node (CDN) at the switch.
There are therefore two translation parameters that, if configured correctly, can dramatically
reduce the number of zone-based registrations while still maintaining acceptable termination
success rates. These translations are the Location Area/Zone ID Registration – CDMA (totzones)
and CDMA Zone Registration Timer (zone_tmr) parameters that may be set on the cell2 form on a
cell-by-cell basis. These parameters also may be set switch-wide on the cgsa form.
These parameters allow a method for the mobile to maintain a history of recently visited zones
(up to totzones), and prevent re-registering on these zones, with the expectation that the mobile
might revert back to the original zone that it was on. The mobile will only register onto this new
zone if it did not revert back to its original zone within the interval zone_tmr.
The feature is best understood with an example. Say totzones is set to 2 and zone_tmr is set to 1
minute. A mobile initially registers with MSC A in Zone A. There is no timer associated with this
registration since it is the first zone seen by the mobile. The mobile then moves to MSC B in
Zone B. At this point, the mobile registers with MSC B since there is no current timer preventing
it from doing so. Zone A is added to a ZONE_LIST, which is maintained by the mobile, and a
timer is started. If the mobile moves back to Zone A before the timer expires, then no registration
is done. If now the mobile remains on Zone A until the timer expires after 1 minute, then the
mobile re-registers with Zone A. If however, the mobile reverted back to Zone B before the timer
expired, then no registrations are performed and the network still has the information that the

97
mobile is in Zone B, which in this case is accurate. In this last scenario, after Zone A’s timer
expires, it will be removed from the mobile’s ZONE_LIST.
There is an important drawback to this algorithm, which may be explained using the example
above. It can be seen in one of the scenarios above that there is a period of time, which could be
up to a maximum of zone_tmr minutes, when the mobile is in Zone A but it is registered as being
in Zone B. During this period, the smart paging strategy will fail because the wrong MSC (MSC
B) will page the mobile. If flood paging is not turned on, then MSC A will never page this
mobile, causing the entire termination attempt to fail. Even if flood paging is turned on, this will
result in a delayed response to the termination attempt because the system first tries to page MSC
B.
On the other hand, having too many ARs due to over-aggressive registration strategies, while
possibly improving the termination success rate marginally, could have many other detrimental
effects on the system. Some examples of these effects are:
1) Increase in Access Channel and Paging Channel occupancy, potentially increasing the
number of access probes required to make a successful attempt. This will increase the
setup delays for new calls, causing customer-perceived service degradation. Some of the
service measurements used to track access and paging channel occupancy are discussed
in section 4.1.9.1.2.
2) Increase in processor occupancy on all hardware elements involved with registrations.

This includes cell processors, Cell Site Node (CSN) processors, Call processing Database
Node (CDN) processors, Data Link Node (DLN) processors and SS7 node processors.
There will also be an increase in SS7 link occupancy. For Release 25, a new feature
called Service Measurements for Capacity and Performance Management introduces
several new counts in the CDMA-CS section that may be used for tracking processor
occupancies for CCUs. Additionally, other sections such as CDN Long Counts, AP OC
counts, contain other service measurements that may be used to track processor
occupancies for other network elements, see [23] for more information.
3) A reduction in battery life on the mobiles because of the increased transmissions required
to communicate these ARs.
4.1.9.1.2 Registration and Paging Strategy Recommendations
Based on the above discussions, given below are some recommendations on how the registration
and paging strategies should be applied for optimal performance. Note that these suggestions may
not apply to all markets, as some of these markets may have unique requirements.
 Turn on a combination of smart paging and flood paging on all MSCs. This ensures that
mobiles will eventually get their pages even if the registrations fail to identify the correct
MSC that these mobiles are on. If flood paging cannot be implemented in the market,
then activate the ISPAGE feature instead.
 Use CN call delivery type whenever possible. This will eliminate one source of
termination failures associated with multiple TLDNs as explained in Section 4.1.6.
 Activate timer-based registrations on all cells in the system and ensure that the
registration interval is no less than 30 minutes.

98
 Activate zone-based registration on all cells in the system and set the totzones to as many
MSCs that could interact with mobiles on the inter-MSC borders. Note that it is okay to
enable zone-based registrations on all cells in the system since this setting will have no
impact on registration rates on cells that do not interact with an MSC border.
The setting of zone_tmr is market-specific. As mentioned previously in the Conceptual
Overview, a balance must be drawn between the number of registrations and the
termination success rate performance when selecting the value to set. This balance will be
different for different markets but the range of this setting is typically between 1 to 2
minutes.
There are also several other parameters that must be set in order to properly configure
this feature, such as the CDMA Registration Zone ID that must be uniquely assigned to
each MSC or set of cells to identify them as separate zones. The Flexent/Autoplex
Wireless Networks Optional Feature Document 401-612-009 contains the necessary
details and must be read thoroughly before attempting to change the market’s registration
configuration. [16] also provides an in-depth study and recommendations on this topic.
 For markets with a large number of SMS calls, large increases in Paging Channel
occupancy due to SMS activity may be problematic by causing failed call setups. Since
Release 19 the SMS Message Overload Control feature has been available to reduce the
effects of SMS traffic on regular paging messages. This feature applies to idle mobiles
and affects Traffic Channel SMS messages, CDMA paging channel SMS messages, and
CDMA Alert With Information SMS messages. When this feature is enabled it lowers the
scheduling priority of SMS General Page Messages and allows voice (and data) pages to
take precedence over SMS pages. Additionally this feature avoids sending an SMS
General Page Message if all cells have all the SMS feature flags disabled in the cell2
form.
Using the SMS Message Overload Control, smsmsg_ovrld parameter on the ecp form,
enables this feature. See [32] for more information.
 Consider enabling Multiple Access/Paging Channels for carriers consistently exhibiting
very high Access or Paging Channel occupancy. It is recommended that these options be
considered after other optimization techniques (such as proper optimization of
registration/paging settings) have been implemented.
 The Multiple Access Channel per Paging Channel feature is available from Release 21.1
onwards and consists of having up to two access channels per paging channel. While high
access channel occupancy is not very common the additional access channel should lower
access channel occupancy where needed. Having the appropriate entry in the FAF file
enables this feature, by enabling the MULT (2) ACC CH parameter on the cell2 form,
and by listing the number of access channels per paging channel in the different hardware
equipage forms (ceqcom2, btseqp, cdmeqp, crcseq, or bbueqp depending on the hardware
type). When this feature is enabled, up to two access channels are available per paging
channel. For more information on this feature refer to [34].
 The Multiple Paging Channel feature has been available from Release 19 (for SII sites),
and Release 20 (for Flexent sites). High paging channel occupancy is more common than
high access channel occupancy, however enabling multiple paging channels per
sector/carrier must be carefully considered. Additional paging channels may have
significant impact in 3G-1X data rates, see Section 5.1.4.2.3 for more information.
Having the appropriate entry in the FAF file enables this feature, by enabling the MUTL
(2) PAGE CH parameter on the cell2 form, and by listing the number of paging channels

99
in the different hardware equipage forms (ceqcom2, btseqp, cdmeqp, crcseq, or bbueqp
depending on the hardware type). For more information on the multiple paging channels
feature refer to [35].
Additionally, once multiple paging channels are enabled, the Neighbor Configuration
Parameter (nghb_conf in the fci form) must be changed per the new paging channel
settings. For more information on the proper nghb_conf setting, refer to [11]. Improper
settings of the nghb_conf parameter in sectors with multiple paging channels may cause
missed pages. If many sectors have this parameter not properly set, the effect may be
significant enough to trend using the Unconditional No Page Response Rate metric.
Tools like SPAT may be used to check Neighbor Configuration Parameter settings in the
fci form.
Care must be taken when enabling the Multiple Paging Channel and the Multiple Access
Channel per Paging Channel features at the same time and when all overhead channels
end up on 2G CCUs. Refer to [34] for more information.
 For Release 23, a slight reduction of Paging Channel occupancy may be achieved by
using the Auxiliary Sector Control 1 (in the ceqface form). The reduction is achieved by
decreasing the size of the General Neighbor List message for 3G 850 MHz cells. The size
of the General Neighbor list message is decreased by not transmitting the neighbor
configuration or neighbor PN parameters, in which case 3G mobiles with an Operating
Protocol Revision of IS2000 or higher get this information from the 2G Neighbor List
Message. For more information on setting the Auxiliary Sector Controls, see [4] and the
appropriate Cell Software Release letter. For Release 26, the new “Customer-Critical
Translations Maintenance - Phase 2” feature replaced the use of Auxiliary Sector Control
1 for improvement of Paging Channel occupancy with the new Control for Paging
Channel Occupancy Improvement parameter in the cell2 form. See the Release 26 release
letter for more information.
 Up to Release 23, the Paging Channel Occupancy peg counts were only available at the
sector level. For Release 24, several enhancements to the Paging Channel Occupancy peg
counts were introduced. The enhancements include availability of Average Paging
Channel Occupancy peg counts at the carrier level; breakdown of the peg counts by
technology (2G Voice, 3G Voice, 3G Packet Date, etc.); and breakdown by type of data
sent such as Overhead Messages, Feature Notification Messages, and SMS. See the
Release 24 release letter and [23] for more information.
 For Release 24, the Access Channel Occupancy peg counts were also improved by
providing similar enhancements including peg counts availability at the carrier level,
breakdown of the counts by technology and type of data sent. See the Release 24 release
letter and [23] for more information.
 For Release 25, two new paging features may be utilized to reduce paging channel
occupancy. These two features are Priority Paging and Adaptive Paging. Priority Paging
may maximize page response rate in situations where minimal shedding of page
messages occurs by letting engineers increase the priority of first page attempts that
usually have a higher probability of being answered. This feature should be used for
cases of intermittent paging channel overload. It should not be relied on in situations of
consistent paging channel overloads. In these cases, the fundamental reason for the high
paging channel overload should be resolved. This feature requires a FAF entry and is
enabled using the Priority Paging Control flag in the cell2 form or the ecp form. Net
form parameters may are used to set Paging Priorities according to paging message type.
See [40] for more information as this feature may interact with other types of paging

100
features. Several service measurements have been introduced that measure the number of
discarded page messages based on priority.
 The Adaptive Paging feature (also new in Release 25) allows the MSC to page a limited
list of cells on the first page if there is a high probability of finding the mobile on this list.
The MSC creates and maintains a dynamic list of cells per homer or roamer mobile and
tracks page responses per mobiles in this list. The MSC could use the list of cells to page
the mobile if the tracked match rate exceeds a translatable value. Mobiles that do not
meet the translatable value of tracked match rates will be paged with the existing paging
strategy. This feature will reduce paging channel occupancy if mobiles repeatedly receive
pages on a limited number of cells. For Release 25, this feature is only available for
Voice calls (no Packet Data Calls), and has several hardware and software requirements.
See [41] for more information. Setting the Adaptive Paging Feature Status translation in
the net form activates this feature (it can also be used to set the feature in “study” mode
where a list of cells is build and information regarding mobile location accuracy is
tracked without actually paging the mobile using adaptive paging). If the percentage of
previous successful location matches is greater than the Adaptive Paging Threshold, also
in the net form, adaptive paging is used to page a mobile. Additionally, translations
limiting the number of cells in the cell list and how long a cell may reside in the list
(without any location based activity) are available. Several new peg counts, tracking the
Adaptive Paging feature are available as well.
 For Release 26, the new “Paging Channel Overhead Message Broadcast Rate” parameter
in the ceqface form may be used to manage high paging channel occupancy problems (for
example, due to increased neighbor list size or increases in SMS traffic). In the paging
channel, cell sites send system overhead messages at least once every so many slots. The
number of slots is controlled using this new parameter. While it is not recommended to
change the default value of the Paging Channel Overhead Message Broadcast Rate
parameter, in cases of very high paging channel occupancy, the value assigned to this
new parameter may be increased. Care must be taken when changing this parameter as it
may affect call setup times.

101
4.2 Drop Call Rate

This is also one of the most critical performance indicators as it is a key measure of the quality of
the call. Dropped calls are generally regarded as one the most frustrating experiences for
customers and therefore much of the optimization efforts are geared towards improving this
metric. The Drop Call Rate is a measure of the ratio of the number of dropped calls to the total
number of established calls.
The high-level equation for drop call rate may be represented as follows:
Lost Calls  CP Fail Drops

Drop Call Rate  x 100%
Total Establishe d Calls
this KPI.
In the above definition, the Total Established Calls is just the numerator of the equation specified
for the Established Call Rate KPI described in Section 4.1.
The two Major Failure Categories that constitute Dropped Calls are CP Fail Drops and Lost
Calls.
Lost Calls typically account for approximately 70% of all dropped calls. CP Fail Drops is a
catch-all counter that captures the remaining 30% of drops that are not accounted for in Lost
Calls, usually because these drops occur under special circumstances that are best captured by the
call processing nodes in the ECP complex.
While conditions that will cause CP Fail Drops may also result in Lost Calls and vice versa, each
condition will usually bias the failures to one or another. Therefore, each of these categories is
discussed separately in this section, with the understanding that each concept discussed under
either category may also marginally apply to the other.
4.2.1 Lost Calls
Conceptual Overview
A Lost Call occurs when a cell is no longer able to detect the reverse link with sufficient quality.
Prior to Release 16.1, the Lost Call detection algorithm worked this way: if 25 more frames are in
error out of the last 50 received frames, start the Traffic Channel Supervision Interval which is a
translatable parameter (tcsupervsn on the ecp/cell2 database forms, usually set to 8 or 10
seconds). After the TCSI timer expires, the cell will attempt to audit the mobile up to nine times
in 400 ms. intervals. If it still does not receive any acknowledgement from the mobile, it will tear
down (drop) the call, resulting in the Lost Call service measurement counter to be pegged. This
event will also be logged in the ROP as a Lost Call message. The TCSI may be reset to 0 if the
cell receives 45 good frames out of the last 50.

102
Since Release 16.1, a new feature called Lost Call Detection Improvement via changes to the
TCSI Algorithm was introduced. This feature makes the requirements for starting the TCSI timer
more stringent by requiring that 5 consecutive frames be received in error in addition to the old
requirement needed to start the TCSI timer. It also makes it easier to reset the timer by requiring
that at least 2 consecutive good frames be received in order to reset the TCSI timer.
For Releases 16.1 and 17, this feature was controlled by the Target Frame Error Rate for High
Capacity, Rate Set 2 parameter (vfer2 in the ecp/ceqface forms). For Release 18 and later, this
feature is always on (See [9] for details).
For Release 26, the new “Enhanced Reverse Link Monitoring - Service Measurements” feature
introduced a new parameter called Number of Audits Sent to Mobile Before Call Release in the
ecpcdma and cell forms that can be used to control the number of audits sent to the mobile (after
the TCSI timer expires) before declaring a lost call . By increasing this parameter, call processing
takes longer to declare a call as lost, giving the reverse link an opportunity to recover (and thus
avoid some lost calls). However, this may tie up resources that could be used for other calls. This
feature also introduces new peg counts that may be used for troubleshooting lost call rate issues.
See Section 4.2.1.2 for more information.
The most commonly encountered reasons for Lost Calls are listed below. As mentioned in the
beginning of this section, these reasons may also result in an appreciable rise in CP Fail Drops,
though not as significant as Lost Calls.
1) Incorrectly populated neighbor lists preventing strong pilots from being added to the
Active Set. These strong pilots eventually cause so much interference that the call drops.
In these cases, the mobile will typically synchronize to the strong pilot immediately after
dropping the call, offering a method to capture this type of problem with drive test data.
Such problems may also be captured at the switch using the Undeclared Neighbor List
(UNL) tool, as described in Appendix B.
2) A poor RF environment will cause drops because it will increase the chances for the loss
of signal on either or both links. A poor RF environment can be caused either because of
excessive pathloss (due to foliage, dense buildings etc.), highly varying terrain or
excessive interference.
3) A poor RF design and/or initial optimization will also set the stage for many dropped
calls. Poor RF design can come in the form of sub-optimal cell locations, heights, antenna
azimuths, link budget errors, etc. Poor RF optimization can come in the form of
improperly populated neighbor lists, improper use and audits of RF translation
parameters, poorly optimized antenna configurations, etc.
4) Performance degradations may occur as a result of heavy traffic loads, potentially leading
to dropped calls. This is because the heavily loaded sectors raise the interference level to
a point that makes it difficult for the mobiles and the cells to overcome it on the reverse
and forward links respectively.
5) Pilot-polluted areas could result in the lack of a dominant server in an area, even though
there is ample total received power, leading to dropped calls. Pilot-pollution typically
occurs in areas that are visible (from an RF-sense) from many areas of the network.
Examples of this include bridges, elevated highways and roadways along water bodies.
Pilot-pollution may also occur due to improper selection of cell sites, resulting in these

103
cell sites causing excessive interference in areas beyond their targeted coverage areas.
Finally, pilot-pollution may result due to a sub-optimal antenna azimuth strategy that fails
to take advantage of the antenna patterns to reduce interference.
For Release 22, a new set of pegs were introduced which count release confirmation failures.
These failures occur when cell sites time out while waiting for a mobile reply to a forced release
message from the cell. After timing out, the cell site tears down the call. There are pegs that count
the instances of all release confirmation failures and the instances of release confirmation failures
that occur with the TCSI timer running. These pegs may be used to optimize the TCSI timer. See
[23] for more information. There are release confirmation counts for 2G and 3G Voice and Data.
The release confirmation failure peg counts differ from the lost call peg counts in that the release
confirmation failure counts would occur only if the cell had sent a forced release message to the
mobile and the cell timed out while waiting for a mobile response. From the mobile user’s
perspective this occurrence would be considered a lost call, thus it is possible that these new peg
counts would be added to the Drop Call Rate KPI in the future.
Optimization Steps for Reducing Lost Calls
The suggestions below address the common causes for dropped calls listed above.
 Ensure neighbor lists are accurate and complete. Some of the important
characteristics of a good neighbor list are:
 They should satisfy reciprocity. That is, if sector A is in sector B’s neighbor list, then
sector B should also be in sector A’s neighbor list. It is very rare that non-reciprocity
can be justified in CDMA systems because of the fact that all cells are transmitting at
the same frequency. Therefore, if one sector is strong enough to be neighbored with
another, then the converse, by definition, will also be true. The FCIAlert tool will
help verify reciprocity (Appendix B).
 The neighbor lists should capture all potential valid neighbors and be prioritized
correctly. The Handoff (HO) Matrix and Undeclared Neighbor List (UNL) tools will
help greatly in ensuring that this is achieved (Appendix B).
The HO Matrix tool logs all handoff activity that actually took place in the network
and is a useful tool to prioritize neighbors and delete unused neighbors. The UNL23
tool may be used to add missing neighbors as it captures strong pilots that could not
be added to the Active Set because they were not part of the neighbor list. Though
these pilots are captured in the call state, the neighbor list additions will apply to the
idle state also.
When using the UNL feature, it is often more effective to first use service
measurements to narrow down and focus on the sectors exhibiting the most severe
UNL problems (as a proportion of their total traffic). Tools such as SPAT (Appendix
B) may be used to easily arrive at this list of affected sectors.
23
Neighbor List (UNL) translation must be set to y on all sectors of interest on the ceqface form, or switch-wide on the
ecp form. 3) The Search Window Size: Remaining Set (srchwinr) translation in the ceqface form must be changed from
its recommended value of zero to 7 or greater (preferably at least 9 to ensure all distant interferers are captured).

104
For Release 26, the number of neighbor list entries supported has increased to 40. To
use this increased number of neighbor list entries the Forty NGBR parameter in the
cell form, and the Expanded (40) Neighbor Lists Enable in the fci forms be enabled,
and that the additional neighbor list entries be entered in the Alternate Neighbor List
2 in the fci form.
The additional neighbor list entries may be useful in areas with closely deployed cell
sites and for in-building applications. However, care must be taken when deciding
whether additional neighbor list entries should really be added to the current neighbor
list.
This increase only applies to mobiles supporting IS95B and later. Additionally, the
Maximum Neighbor List Number Sent To Mobile and the Paging Channel Neighbor
List Selection in the ceqface/ecp forms may need to be updated. See [9] for more
information. However, care must be taken when incrementing the size of the
neighbor list as this may increase paging channel occupancy. See Section 4.1.9.1.2
for more information.
 There should be no PN ambiguities in the neighbor list. The FCIAlert tool can be
used to check for this (see Appendix B for details on the tool and this condition).
 Perform periodic system-wide drive tests of all major roadways and high-traffic
areas. Optimize the coverage and manage the interference levels using techniques
such as physical antenna configuration changes and parameter optimization [19].
These drives may also be used as an opportunity to identify and resolve certain types
of problems that may be best identified with drive tests. Examples of this are search
window problems and co-PN interference. There are many commercial tools to
perform such drive test analysis. Lucent also has internal tools such as the Lucent
Data Analysis Tool (LDAT) to perform CDMA drive test post-processing.
 Identify all heavily loaded sectors (that is, sectors whose total carried Erlangs are
approaching the values in Table 4.4) and implement capacity reduction techniques as
per the suggestions in Section 4.1.5.1 under the topic on Forward Power Resource
Blocking Management Techniques. This is especially important if noticeable
degradations in drop call performance are noticed during the busy hours only on
these sectors. Note that, if the load is not evenly distributed among the carriers of
these sectors, then this might be indicative of some other problem. These cases are
dealt with in Section 4.1.5.2 under the topic on Overload Not Detected on All
Carriers of Multi-Carrier Sector.
 There must be a general discipline to reduce overshooting sectors throughout the
network. These overshooting sectors will result in unpredictable behavior and drops
in the system since they will appear in unexpected areas. These sectors will also draw
more capacity than they were intended for.
For mature systems, the UNL24 feature is a good place to start to get a list of
overshooting sectors. The HO Matrix tool will also provide insights into the sector
coverage. Alternatively, the footprint of the sectors may be mapped out based on
drive test data, though this is usually a more costly and time-consuming exercise.
24

105
The techniques to fix or manage these overshooting sectors are through physical
antenna and attenuation changes.
 Pilot polluted areas should be identified and eliminated (as much as possible),
especially if it observed that there are performance degradations observed in these
areas. The only way to identify pilot polluted areas is through drive tests, either with
a scanner or with a mobile phone. The techniques used to reduce these pilot polluted
areas will be the same as those used to reduce overshooting sectors above, namely,
through physical antenna and attenuation changes.
4.2.1.2 Lost Call Causes and Associated Fixes
4.2.1.2.1 Poorly Defined Neighbor Lists
Concept / Reason / Effect of Failure
A poorly defined neighbor list will result in potentially strong Candidate pilots being rejected
from entering the Active Set and participating in the call. Instead, these Candidate pilots will act
as pure interference to the call. If this interference is sufficiently strong, the mobile will drop the
call, resulting in a lost call.
Handoff Matrix (HOMAX) and the Undeclared Neighbor List (UNL) features have been very
problem.
drive tests for greenfield (new) deployments, since switch-based neighbor list management tools
Note that there must be discipline exercised when adding neighbors, since sectors with
excessively large neighbor lists could perform poorly due to the increased processing

106
requirements. Additionally, given the fact that neighbor lists of sectors in soft-handoff are
concatenated, having large neighbor lists increases the chances that some neighbors will
be dropped in this concatenated list.
The solution in this case will be to perform physical and/or parameter optimization to
eliminate the need for the neighbor list entry [19]. This would entail removing that sector
from the area through antenna downtilts, azimuth changes, antenna model changes and/or
BCR/CBR attenuation changes.
should be applied. Given below are important integrity checks that must be
performed on neighbor lists. The FCIAlert tool will perform all of the following
integrity checks and more, but the most important ones are listed below.
Reciprocity
Reciprocity refers to making sure that if sector A is added to sector B’s neighbor list,
then sector B is also in sector A’s neighbor list. With CDMA networks, there is rarely
any justification for not satisfying reciprocity rules when populating neighbor lists
because all sectors are transmitting on the same frequency.
PN Ambiguity Issues
PN ambiguities may come in many forms. No two neighbors on the same neighbor list
can have the same PN assignment because this will confuse the network should this PN
be reported as a Candidate pilot. A less obvious problem will be when two neighbors
share the same PN as a result of neighbor list concatenation. This is commonly referred
to as two-way PN ambiguity problems (for any combination of two neighbor lists) up
to n-way neighbor list problems (n up to 6). Typically, only two-way PN ambiguity
checks are performed.
4.2.1.2.2 High Traffic Areas
Areas of high traffic can cause an increase in lost calls. This is because several high-traffic
sectors in an area raises the interference levels significantly, making it difficult for the traffic
channel to overcome this interference.
High traffic levels may be determined by examining the traffic Erlangs carried by the sectors
exhibiting poor lost call performance. Note that, if this is indeed the root cause for the lost calls,
then there must be several sectors covering the same area with very high traffic levels. A single
sector with high traffic will not justify that sector experiencing high lost calls because its own
sector traffic are mutually orthogonal and should not affect the performance much.

107
Another important trend to look for to isolate this root cause is that there should be a clear
correlation between the lost call performance and traffic levels. It should be observed that the lost
call performance gets sharply worse as the traffic picks up beyond a certain point. If the lost call
performance is consistently poor during all hours of the day, then it is unlikely that high traffic
levels are the root cause.
Another way of identifying high traffic areas is looking for high Erlangs carried by the sectors in
question and high RSSI values. For Release 26, the new “Enhanced Reverse Link Monitoring -
Service Measurements” feature introduced several new peg counts that may be used to measure
RSSI such as the Reverse Link Peak RSSI on Diversity Path 0/1, Reverse Link Hourly Low RSSI
on Diversity Path 0/1, and Reverse Link Thermal Noise Floor on Diversity Path 0/1, among
others. See the respective Release 26 release letter as well as [26] for more information.
If the lost call performance is deemed to be poor because of high traffic levels, then the only real
solutions available is to either add a carrier to the sectors in the area to relieve traffic, or to add
cell splits to offload the traffic to new cells. For PCS applications for Flexent ModCells 4.0Bs, if
cell splits are not an option, then additional sectorization may be possible. The Flexent ModCells
4.0B platform supports four to six sector configurations with the introduction of the new “Four-
to-Six (4-6) Sector Configuration for Flexent ModCell 4.0's Specific Growth-limited 5 MHz PCS
Applications” feature. This feature provides with all configuration parameters needed to support
cell sites with more than three sectors. Additional cell site hardware may be required to utilize
this feature, please see the Release 26 release letter for more information.
Performing optimization to offload sectors is usually a difficult exercise if there are more than a
couple of sectors in an area experiencing high traffic, since there will be limited sectors to offload
this traffic to. Playing with translation parameters to increase the traffic carried by sectors will
only make matters worse because it will add to the excessive interference that was the root cause
of the problem to begin with.
One possible alternative solution, though sometimes difficult to achieve, is to reduce the amount
of overall soft-handoff percentage in the affected area.
There are however several dangers with reducing soft-handoff zones, especially if they are not
executed properly. Given the nature of CDMA systems where the coverage shrinks with traffic
loading, it is quite possible that areas of weak to no coverage can be created during peak hours if
the soft-handoff reductions are too aggressive.
Also, it is always wise to manage soft-handoff zones by performing physical antenna

optimization, if possible, as opposed to changes in translations such as BCR/CBR attenuation.
Changing attenuation values to manage coverage has several drawbacks.
 Typically, it is recommended that the BBA Max. Power (max_power) translation (set
in the ceqcom2/crceqp/cdmeqp/bbueqp forms based on cell type) is reduced
proportionately when attenuation is increased at a sector. While in theory, the
average power allocated to each user should also go down (thus maintaining the same
traffic capacity at the sector); this might not hold true in soft-handoff areas where the
average power allocated to the users may remain constant. If this were to happen,
then the sectors will actually go into forward power overload even sooner. This may
have negative impacts on the performance of call establishments and dropped calls.

108
 The alternate solution to leave the max_power unchanged despite increasing

attenuation will also potentially have negative impacts. These fully loaded sectors
may deteriorate the ability of the traffic channels to overcome the increased
interference, since these traffic channels are actually transmitting at a lower power
due to the attenuation introduced. This will potentially result in more areas of weak
coverage, which in turn will affect lost call performance.
Antenna adjustments do not suffer any of the drawbacks discussed above. The coverage problems
are solved fundamentally, without introducing any of the capacity and/or interference issues due
to max_power and BCR/CBR mismatches as discussed above. Of course, there isn’t always the
option to perform such physical antenna optimization, especially in the cases when these antennas
are shared among multiple technologies (overlay systems). In these circumstances, there may be
no choice but to perform parameter adjustments to control coverage.
4.2.1.2.3 Significant Areas of Poor Coverage
Lost calls could be generated in areas of weak coverage whereby even the dominant pilot is
unable to overcome the noise floor. Areas of weak coverage could be a result of being inside
buildings, areas shadowed by obstacles such as hills, trees etc. or due to poor RF design of the
cell sites.
There are several choices for improving such coverage problems. They are:

manipulation of BCR/CBR attenuation values. There may not always be an option to
implement this solution since the antennas may already have been configured for
optimal coverage and the attenuation values are at their minimum.

109
4.2.1.2.4 Island-Mode Cell due to loss of network synchronization
On rare occasions, a cell will go out of synchronization with the network, causing it to be in an
‘island-mode’ whereby it is not able to handoff to any surrounding cell and vice versa. This
happens when the RFTG does not reestablish correct timing after experiencing flywheeling due to
temporary loss of line-of-sight with the GPS satellites or hardware failures.
A cell in island-mode is usually clearly recognizable from service measurements. The most
important sign is a severe drop in soft-handoff activity on the affected cell, since this cell will no
longer have any soft-handoff with its neighboring cells. Note that there will still be some
marginal soft-handoff activity when the cell is in three-way softer handoff. Soft-handoff
percentage may be determined through examining the ratio of secondary to total (primary +
secondary) CE usage at the cell. Normal cells (that have surrounding cells that are operational)
will typically achieve at least 30% soft-handoff activity. Additionally, for Release 27, a new set
of pegs that count the number of primary transfers may offer an indication that a cell has become
an island mode cell. These counts are CDMA-PAF-CARR-VO 41, 42, 46, 67, and CDMA-PAF-
CARR-SC 175 to 177. In particular, a sharp decrease in the 3G Soft or Semi-Soft Primary
Transferred In count may indicate that a cell site is not handing off to its neighbors. Keep in mind
that this count, along with others showing traffic and handoff activity depend on traffic patterns.
Other signs of island-mode cells include the following:
 All carriers of all sectors of the affected cell will experience high drop call
percentage as mobiles drive out of the cell coverage area and drop their calls, since
they are not able to handoff to another site. Note that these drops will manifest
themselves only as Lost Calls, not CP Fail Drops. This is because the mobile will
never be directed to handoff in the first place, eliminating the possibility for Handoff
(HO) Timeouts.
 All carriers of all sectors pointing towards the affected cells will also experience very
high drop percentage.
 Examination of the ROP will show RFTG flywheeling activity on the cell. Note
however that this in itself is not an indication that the cell is in island-mode. This is
because flywheeling is a very common occurrence in IS95 systems and the base
stations are able to operate for several hours with accurate timing, with the aid of a
rubidium clock, until timing is reestablished with the GPS satellites. This however
may serve as a good check if all the above symptoms are observed.
The best way to verify that the cell is in island-mode is to test the ability of the cell to handoff in
the field. Freshly collected handoff matrix data may also be used to confirm the lack of soft-
handoff activity with any surrounding cell site.
If a cell is determined to be in island-mode, then the instructions presented in Fax Flash #98-269
must be followed to clear the problem. Fax Flash #99-023 also presents some alarms that are

110
indicative of this problem which manifest themselves as HEH messages on the ROP. Recent TFU
hardware issues showing excessive flywheeling are also covered in Lucent Alert 05−0207a.
Recent CTU-II and CTU with OMR issues also include hardware packs taking a long time to
acquire GPS (see Lucent Alert 06−0005) or exhibiting timing stability (see Lucent Alert
05−0741a).
4.2.1.2.5 Island-Mode Cell due to differences in Packet Pipe delays
During soft handoff a mobile communicates with more than one base station at the same time.
These base stations will in turn send the speech frames from the call in soft handoff to the MSC
for further processing through their packet pipes. At the MSC, the Speech Handler is responsible
for picking the best speech frame during call processing. Due to the delay sensitive nature of
voice communications, the difference in arrival time of speech frames from a call in soft handoff
has to be kept within a certain range.
On rare occasions, a cell will have a large enough difference in its packet pipe delay when
compared to the delay of neighboring sites, causing it to be in an ‘island-mode’ whereby it is not
able to handoff to any surrounding cell and vice versa. In this case, the RFTG/TFU hardware is
not at fault, and there is no problem with GPS reception. This happens when neighboring sites
have packet pipe delays that are sufficiently different from the problem site to prevent the MSC
from combining speech frames coming from these sites. This in turn could be due to the packet
pipes being routed differently or going through defective hardware.
This delay differential may also result in degraded voice quality.
This type of island-mode cell is usually recognizable from service measurements or drive test
data (see 4.2.1.2.4). However this type of failure may be more intermittent and may also be
accompanied by decrease in voice quality while in soft handoff.
Other signs of this type of island-mode cell include the following:
 All carriers of all sectors of the affected cell will experience high drop call
percentage as mobiles drive out of the cell coverage area and drop their calls, since
they are not able to handoff to another site. Note that these drops will manifest
themselves mostly as Lost Calls, and possible CP Fail Drops.
 All carriers of all sectors pointing towards the affected cells will also experience very
high drop percentage.
The best way to verify that the cell is in island-mode is to test the ability of the cell to handoff in
the field. Freshly collected handoff matrix data may also be used to confirm the lack of soft-
handoff activity with any surrounding cell site. A T-BIRD (or similar) facilities measurement
equipment may be used to measure facilities delay. A one-way delay larger than 40 ms. will cause
problems in call processing, while a delay difference larger than 8 ms. between neighboring sites
will impair handoffs and reduce voice quality. Refer to [27] for more information.

111
If a cell is determined to be in this type of island-mode, then the only solution is to reduce the
difference in packet pipe delay between neighboring sites. Removing hardware components
between the cell site in question and the MSC may do this, or by verifying this cell’s span routing
(refer to CAROD tickets IC18221 & IC17580 & IC16273).
4.2.1.2.6 Handoff Cell is Blocking on All Carriers
Calls could drop because the mobiles are not able to handoff to a sector that is blocking on all
carriers due to resource constraints. Note that it is conceivable that the call is maintained even
under this scenario as long as the serving sectors in the Active Set are still able to collectively
overcome the interference caused by this blocking sector. However, if the blocking sector’s pilot
becomes the dominant one, then the probability that the call will drop is very high.
It should also be noted that, in Lucent systems, if a soft-handoff request is blocked on one carrier,
then the network will first attempt to move the entire call to another carrier that is not blocking, a
process referred to as handoff escalation. The handoff request is only completely blocked if the
sector is blocking on all carries.
If this problem is significant enough to result in lost calls, then the affected cell site should also
be generating resource-blocking counts in service measurements. Also, the sectors with poor lost
call performance pointing towards the blocking cell should show a marked increase in dropped
calls during these hours of cell resource blocking.
The solution to this problem is to solve the cell resource-blocking problem. Cell resource
blocking can come either in the form of hardware resource blocking or RF resource blocking.
Understanding and resolving cell resource blocking is an involved topic in its own right, and is
discussed in detail in Sections 4.1.4, 4.1.5 and 4.1.6.
If the cell resource-blocking issue is due to CEs, and resolution of the blocking problem may not
be immediate, an alternative short-term fix for Flexent cell sites is to reserve CEs for handoff
purposes. For Release 25, a new feature called 3G CE Reservation for 3G Hand-offs is available.
This feature allows reserving CEs for 3G voice and 3G data calls only and is enabled using the
3G HO RES flag in the cell2 form and the actual number of CEs to reserve is set per carrier using
the 3G only CE HO Num parameter also in the cell2 form. If used, this new feature overrides the
old 2G and 3G CEs reserved for handoff feature that would reserve CEs for handoffs regardless
of whether it was for 2G or 3G calls, which could result in 3G voice or data calls being degraded
to 2G CEs. See [42] for more information. A service measurement in the CDMA-CS section was
introduced to measure the impact this new feature may have, see [23] for more information.
Handoff escalation may also occur in situations where a 3G call is trying to handoff to a
candidate with 3G resources, all of them occupied, or when a 3G call is trying to handoff to a

112
candidate that has 2G only resources. In some situations, handoff escalation may not occur
quickly enough (as the escalation has to occur when the candidate sector is t_comp stronger than
the strongest active set sector), resulting in calls being lost as the RF environment deteriorates. As
of Release 25 two new parameters are introduced as part of the Customer Critical Translations
Maintenance - Phase 1 feature. These two new parameters, 3G Handoff Escalation due to 2G-
Only Sector/Carrier and 3G Handoff Escalation due to Lack of 3G Resources, both on the cell3g
form, may be used to trigger the handoff escalation sooner, by only requiring that the candidate
sector be at t_add. These two parameters may be used to improve 3G-to-3G or 3G-to-2G handoff
escalation by avoiding potential dragging of the calls into inadequate RF environments before the
handoff is triggered. The functionality provided by these two new parameters are available for
releases prior to Release 25 through borrowed translations. See [9] for more information.
4.2.1.2.7 Pilot Polluted Areas
An area is considered “pilot polluted” if the aggregate Active pilot Ec/Io is weak because of
significant pilot energy outside of the Active Set because of too many other pilots. Note that the
pilot energy outside of the Active Set may also result from a single strong interferer. This is not
pilot pollution, but rather some other problem such as neighbor list problems (discussed in
Section 4.2.1.2.1) or hardware blocking (Section 4.2.1.2.6).
While it is difficult to directly identify pilot polluted areas through service measurements, peg
counts aid in this respect. These counts include three pegs that measure the number of pilots
above t_add with a full active set and three peg counts that measure the number of pilots above
t_comp also with a full active set. Keep in mind that the mere existence of excessive soft-handoff
zones is not necessarily an indication of pilot pollution since these handoff zones could
predominantly be comprised of pilots that are all able to participate in the Active Set.
Drive testing would be the most effective way to identify pilot polluted areas. Some drive test
analysis tools such as the Lucent Data Analysis Tool (LDAT3G) have specialized metrics that
explicitly indicate pilot polluted areas along the drive route.
Once identified, pilot polluted areas may be reduced or eliminated through physical optimization
(changes in antenna orientation, downtilt, model etc.) and/or BCR/CBR attenuation changes.
Manipulating t_add, t_drop and other handoff parameters may also help marginally resolve pilot
pollution by allowing more of these “polluting” pilots to enter into the Active Set. However, it is
recommended that the problem is solved at its root through RF optimization, if possible.

113
4.2.1.2.8 Search Window Problems
In IS95A/B systems, mobiles have five rake receivers, commonly referred to as ‘fingers’. Four of
these fingers are used to demodulate up to four best multipaths from the sectors in the Active Set.
The fifth rake receiver is known as the Searcher Finger and its primary job is to scan all possible
pilots and compare their strengths to the pilots in the Active Set. This information is then reported
back to the cell through the Pilot Strength Measurement Message (PSMM), which will then
evaluate these results and reconfigure the pilots to be used in the Active Set, if deemed necessary
to improve the performance.
Due to the vast number of possible pilots (512 / PILOT_INC), each with a spacing of (64 x
PILOT_INC) chips25, it will take the Searcher Finger too long to scan through this entire space.
Therefore, the searcher is restricted to searching only over a ‘window’ of chips around each pilot,
known as the Search Window. This Search Window may be set differentially for pilots in the
various sets (Active/Candidate, Neighbor and Remaining Sets).
It is intuitively obvious from the above discussions that if the pilot arrives outside of the Search
Window, then this pilot will not be captured and reported by the Searcher, and will therefore
never be a candidate to be used in the Active Set. In CDMA systems, due to the fact that all pilots
are transmitting over the same frequency, this missed pilot will immediately become a strong
interferer. The performance in these locations will degrade significantly and dropped calls may
result because of this strong interference.
Search window problems may be best captured using drive test data, either by using a pilot
scanner or by using the data logged off a mobile. With the pilot scanner, the delays of all the
arriving pilots may be directly viewed and analyzed. With the mobile-logged data, the delays of
all strong pilots may be extracted from Layer 3 messaging. Note that the mobile-logged data will
only give insights to pilots that are approaching the edge of their search windows. If the pilot is
completely outside of the search window, then the scanner will be the only way to capture this
problem.
These window problems may either be resolved by increasing the window sizes or by removing
the delayed pilot from the area through optimization. Note that areas of hilly terrain will generally
require larger search windows while lower search windows may be used in dense urban
environments.
Reference [9] delves into the details of search windows and should be read before attempting to
optimize these windows.
25
The definition and use of PILOT_INC is discussed under Co-PN Interference later in this section.

114
External interference in either the forward or reverse links will cause degradations in drop call
performance on the carrier that this interference is on. This is because this interference raises the
noise floor of the system, requiring the forward or reverse link traffic signals to increase their
transmit powers to overcome it. If the interference is significant enough, then the base station or
mobile will run out of power and, as a consequence, the performance will degrade.
It is usually difficult to establish that external interference is the root cause of observed
performance degradations but sometimes service measurements will provide some clues to aid in
its discovery.
For example, strong reverse link interference could exhibit high RSSI rise and could even peg
significant counts of reverse power overload even though the carried traffic on the reverse link
does not justify such high reverse loading.
looking for the areas of concentration in the observed interference. Triangulation methods may
also be used with multiple analyzers or scanners to track the interference source.
For Release 26, the new “Enhanced Reverse Link Monitoring - Service Measurements” feature
introduced several new peg counts that may be used to detect external interference such as the
Reverse Link Peak RSSI on Diversity Path 0/1, Reverse Link Hourly Low RSSI on Diversity
Path 0/1, and Reverse Link Thermal Noise Floor on Diversity Path 0/1, among others. See the
respective Release 26 release letter as well as [23] for more information.
The fix would be to remove the source of interference, once identified. Sometimes this would
entail contacting the offending party to terminate the transmissions. The biggest challenge is
usually to identify the interference source to begin with.
4.2.1.2.10 Co-PN Interference
In CDMA systems, pilots are differentiated by their PN offsets, which are really just time-shifted
versions of the same signal. There are 512 possible PN offsets, each being shifted in time by 64
chips (which correspond to approximately 10 miles). The important point to understand about PN

115
offsets is that, since they are just time shifted versions of each other, it is possible for a pilot to
appear like it has a different PN offset if it is able to travel far enough and still have sufficient
signal strength to be received by the mobiles. If two pilots in an area appear to have the same PN
offset with similar signal strengths, then the mobiles will not be able to resolve the two signals.
The process of PN planning is to avoid the potential problems listed above by intelligent
assignment of PN offsets to each sector in the system. To further reduce the chances for PN
assignment problems, only PN offsets in steps of PILOT_INC are assigned to these sectors,
PILOT_INC being an ECP-wide translation parameter. The larger the value of PILOT_INC, the
lower the chances that a PN offset will be associated with the wrong sector, since the pilot will
have to travel (PILOT_INC * 10 miles) and still be received with sufficient strength to be
mistaken for another PN offset.
Co-PN interference could result due to poor PN planning, improper choice of PILOT_INC or
inadvertent entry of incorrect PN offsets to sectors in translations. Interference may occur either
because the same PN offset was assigned to two sectors that “see” each other in the RF sense, or
if a sector assigned to a different PN offset traveled far enough with sufficiently low attenuation
to appear mistakenly as the same PN as another sector in the area.
An example of a common oversight is the inappropriate assignments of PN Offsets along water

bodies. RF signals are able to travel great distances with relatively low pathloss over water, and
therefore, great care must be taken when allocating PN Offsets to all cells that share common
water bodies.
Identifying the root cause of a problem to be because of Co-PN interference is not

straightforward.
One method of identifying Co-PN interference problems is through the examination of the delay
spread of the suspected pilot using a pilot scanner. Co-PN interference can be suspected if the
delay spread appears too large for the morphology, since this delay spread could actually be a
result of two separate sectors transmitting the same PN from very different distances.
Another indicator of Co-PN interference is if the Ec/Io and Receive Power in an area are very
good but the FFER performance is extremely poor. These results may be obtained through
mobile-logged drive test data. The reason for this is because there is no demodulation performed
when measuring Ec/Io, just raw power measurements. This will result in a good Ec/Io and
Receive Power being reported. The call however will not be able to be demodulated correctly
because of the direct co-PN signal interference, resulting in the poor FFER performance.
Note that neither of these indicators are definite proofs of Co-PN interference. However, they
provide good starting points in uncovering this problem.
If Co-PN interference is identified, then the solution would either be to reassign the PN offset
values of the offending sectors, or to remove the offending sectors from the affected areas
through some combination of physical and parameter optimization [19].

116
4.2.1.2.11 Hardware Outages and/or Intermittent Hardware Problems
Sometimes, certain hardware elements in a cell go in and out of service, or remain out of service,
potentially causing service-affecting problems such as dropped calls. An example of this would
be Packet Pipes (PPs) that go in and out of service, which typically might happen if there are
problems with the associated T1 line.
These types of intermittent hardware problems are characterized by a sudden degradation in the
performance of the KPIs the moment the problem starts happening.
The best way to capture such problems is through using ROP scripts that will be able to log and
report all hardware elements that go in and out of service. There are several tools that perform
such analysis, one of them being the SPAT tool (Appendix B), which will report all hardware
failures that occur throughout the day on a cell-by-cell basis.
Additionally, for Release 23, new out of service peg counts were added that might help detect
hardware outages. Please refer to 4.1.4.2.2 for more information.
As this is a cell hardware issue, it is recommended that the customer Operations team is notified
of the problem.
4.2.1.2.12 Incorrectly Optimized New Cell
A poorly optimized or malfunctioning new cell that is turned on in an area could also affect the
drop call performance in all areas that interact (RF-wise) with this new cell.
The clearest sign that the new cell is the cause of the problems is to determine whether the
problems suddenly started happening the moment the new cell was turned on.
Note that new cells are typically turned on several times prior to being ‘officially’ turned on by
the operator. The cells are turned on for cell integration and usually for optimization as well.
Therefore, it is important to have complete information on all of the activity on the new cell to be
able to draw clear correlations to the network performance.
This root cause may be confirmed through analysis of drive tests conducted in the area after the
new cell site is turned on, and through looking at service measurements for this cell and its
neighbors.

117
Once it is determined that the new cell has caused the performance degradations, the next step is
to isolate the problem with the new cell and fix it. There is a wide variety of problems that could
occur, many of them already discussed in the various sections of this document. These problems
could be any one of, but not limited to, the following:
 Hardware outages and/or intermittent problems (includes span/PP issues)

 Neighbor list entry problems
 Error in translation parameter entries (PN assignment, etc.)
 Power calibration errors
 Antenna configuration errors or requires optimization
The possible problems with new cell sites are too diverse and detailed to discuss in this section.
There are however several other sections within this document that deals with each of these
potential problems. In particular, the following sections may be referenced:
 Section 4.2.1.2.1 (Poorly Defined Neighbor Lists)

 Section 4.2.1.2.11 (Hardware Outages and/or Intermittent Hardware Problems)
 Section 4.2.1.2.13 (Inadvertent Change of Translations)
4.2.1.2.13 Inadvertent Change of Translations
Sometimes, an accidental change of translations at the switch can have a dramatic negative
impact on the performance of sectors/cells in the network. Certainly, some translation parameters
have much more of a dramatic effect on performance than others. For example, small changes to
t_add and t_drop may only have a moderate effect on drop call performance. On the other hand,
if a PN Offset is advertently changed on a sector to be the same as the PN Offset of a neighboring
sector, then the performance of the entire area will be drastically worse.
These accidental translations changes, if they are serious ones, will typically result in a sudden,
severe performance degradation starting the instant the change was made effective at the switch.
Capturing these changes is not always easy because of the sheer number of RF translations that
exist. However, efforts should be focused on regularly auditing those translations that are likely to
have dramatic performance impacts, such as the PN Offset. It is also effective to use tools that
provide quick and convenient reports of all translations that have deviated from Lucent
recommendations. The SPAT tool (Appendix B) provides for such a feature. Finally, it should be
noted that all changes to translations are captured on a daily basis by the switch and saved in files
in the OMP. The login userids are also tagged with these changes. Lucent support center or the
Service Provider’s Operations team should be contacted if these files need to be viewed.

118
Once identified, the solution will be to reverse the translation error. Proper documentation should
always be maintained for all translation changes to help track root causes of performance
problems.
4.2.2 CP Fail Drops
4.2.2.1.1 General Description
Typically, the largest component of CP Fail Drops is Handoff (HO) Complete Timeouts that
refer to calls that are dropped during the process of a handoff.
Important: HO Complete Timeouts occur when a Handoff Direction Message is sent to the
mobile directing it to perform a soft or semi-soft handoff but the system does not
get a Handoff Completion response from the mobile within a predefined period
of time. Thus, by definition, HO Complete Timeouts can only occur after the
handoff is accepted by the system. Therefore, situations in which handoffs will
not be approved due to lack of resources (CE blocking, power blocking etc.) will
not result on HO Complete Timeouts but rather will result in Lost Calls.
In the ROP, CP Fail Drops correspond to all Call Shutdown messages in the Answered
Origination and Terminations state. Handoff Complete Timeouts in particular are captured in the
ROP as Call Shutdown Type 10 (commonly referred to as CS-[10]). There are also specific peg
counts in service measurements that will capture these timeout events.
Most of the Lost Call reasons discussed in Section 4.2.1.1 will also result in CP Fail Drops.
However, there are certain conditions that will almost exclusively result in CP Fail Drops,
without a corresponding rise in Lost Calls. These special conditions will be the focus of this
section.
The most significant of these conditions is the performance of hard and semi-soft handoffs. Both
hard and semi-soft handoffs are “break-before-make” handoffs, and will result in handoff
complete timeouts if the call fails to successfully execute these handoffs. For Release 26, the new
“CDMA Handoff Matrix (HOM) Tool feature” may be used to collect handoff matrix counts
down to the carrier level. This is useful in determining the amount of hard, or semi-soft handoffs,
out of particular sectors (or carriers), which may be later used to prioritize hard, or semi-soft
handoff failure rates. This feature requires a new FAF entry, see [46] for more information.
The call flow for a semi-soft handoff is presented in Figure A-2 below. A dropped call (CP Fail
Drop) will occur if the target cell site fails to receive the Handoff Completion Message from the
mobile upon issuing the order to the requesting cell site to go ahead with the semi-soft handoff.
These failures may also be tracked in service measurements by comparing the hard handoff order
to completion rates (see figure below).

119
Due to the importance of this topic, the concepts behind how these semi-soft handoffs are
triggered and executed are discussed in detail in the following section.
MS Requesting Cell Target Cell CDN DCS
PSMM
Intra/Inter-Cell Handoff Request
Cell Null Traffic Data
Intra/Inter-Cell Handoff Ack (Order)
Handoff Direction Message
Mobile Traffic Data
Handoff Completion Message
Handoff Completion
Handoff Completion
Handoff Completion
FIGURE A-2 SEMI-SOFT HANDOFF CALL FLOW
4.2.2.1.2 Inter-Frequency Semi-Soft Handoff Concepts
The topic of inter-frequency handoffs is a very important one that warrants further explanation.
The discussion below only presents a summary of this topic. The details and Lucent
recommendations can be found in [9]. This application note is required reading before any
attempt is made to configure and optimize border sectors.
There are two distinct phases that relate to inter-frequency handoffs:
1) The first phase triggers the inter-frequency semi-soft handoff using the selected
triggering algorithm.
2) Upon receiving a valid trigger, the next phase redirects the mobile to the new carrier,
either in simplex mode or in soft-handoff, depending on the option selected. This phase
will also determine the choice of pilots to go into simplex or soft-handoff on the new
frequency, which must be specified in translations.

120
For the first phase, there are two forms of triggers for inter-frequency handoffs; directed handoffs
(commonly referred to as handdowns) and pilot-assisted handoffs (commonly referred to as
handovers).
4.2.2.1.3 Directed Inter-Frequency Handoffs
There are three methods to trigger directed inter-frequency handoffs, namely, the Tr_CHo
algorithm, the IFHOTI algorithm, and the Distance Based Directed Handoff. The IFHOTI is an
improved mechanism that was introduced in Release 12.0, while the Distance Based Directed
Handoff was introduced in Release 19 (with many enhancements introduced in Release 22). The
choice is given to use any of these algorithms.
Tr_CHo Inter-frequency Handoff Trigger
With the Tr_CHo algorithm, an inter-frequency handoff is directed on a border sector if the
following criteria are all met:
1) All the Active Set pilots are border sectors.
2) The call is in either simplex or two-way soft/softer handoff. (Note that the handdown will
not take place if the call is in three-way handoff or greater).
3) The Ec/Io of the strongest Active Set pilot is below the CDMA-CDMA Handoff
Threshold (c_c_ho_th) threshold that is set in the ecp/ceqface database form.
While this algorithm works pretty well, there are some drawbacks. It is possible for calls to get
dragged without handing down because conditions (1) and (2) above are not met. The call may
then eventually handdown much later but may then drop the call, since the coverage of border
carriers typically extend well beyond their corresponding common carriers’ coverage.
Alternatively, the calls may handdown very quickly if the mobile is close to the border carrier,
since conditions (1) and (2) are easily met, and condition (3) is also met since the Tr_CHo
threshold is typically set to a very high value (default is –4 dB).
IFHOTI Inter-frequency Handoff Trigger
IFHOTI improves on the previous algorithm by allowing the mobiles to stay on the border carrier
for much longer while maintaining, or even improving, on the handdown reliability. This is
achieved through two new triggers called the Border Pilot versus Interior Pilot (BPIP) Threshold
(bpinp_comp) and the Border Sector Loss Threshold for Inter-frequency Handoff (Ifho_blos_th)
in the ecp/ceqface database form.
The first trigger condition must be met before the second trigger is considered. The first trigger is
met when the strongest border pilot is stronger than the strongest interior pilot by the defined
threshold. This ensures that the border pilot is the strongest serving sector in the area, thus setting
the stage for a reliable handdown. Note that condition (1) in the old algorithm is no longer
imposed.
When the first trigger is met, the Ec/Io Loss Metric trigger is evaluated. The creation of this
metric was motivated by the fact that handing down on an absolute Ec/Io threshold will make the

121
handdown location dependent on the loading on the network. This is because the Ec/Io
experienced at any location is a function of Io that varies with loading even though received Ec
remains constant. The Ec/Io Loss Metric will take this loading into effect, thus allowing for this
threshold to determine the location of the handdown, rather than this handdown be based off the
absolute Ec/Io value.
The net effect of using the IFHOTI triggering mechanism is that the border carriers will carry
significantly more traffic while maintaining or improving the handdown performance, assuming
the triggers are optimized correctly.
The IFHOTI algorithm may be activated on a cell-by-cell basis on the cell2 form. There is a
restriction on this algorithm in that the inter-frequency semi-soft handoff will only be directed if
the total number of channel elements (CEs) used in the Active Set is less than or equal to 3.
Distance Based Inter-frequency Handoff Trigger
The Distance Based Directed Handoff is a new feature introduced in Release 19 for those RF
environments where IFHOTI on its own cannot control the handoff location because the Ec/Io
Loss Metric is too easily met, or where hard handoff ping-ponging occurs due to the RF
environment (for example areas of low signal strength between border cells due to rolling hills).
Using this feature, the directed handoffs take place only when the distance to each active leg in
the active set is greater than its respective distance threshold and the IFHOTI threshold conditions
are met.
For Releases 19 through 21, distance thresholds are set per face using two parameters: the Gain
Threshold for High Capacity (dgu) – Rateset 1 (gain1_thresh) and the Gain Threshold for High
Capacity (dgu) – Rateset 2 (gain2_thresh), both in the ecp/ceqface forms.
The distance thresholds are used in the following way:
Distance Threshold = (gain1_thresh – 34) * gain2_thresh where gain2_thresh has the following
values:
Table 4.6 VALUES FOR GAIN2_THRESH

gain2_thresh (value in Scale
ceqface/ecp forms)
34-80 0.0
81 0.1
82 0.2
83 0.5
84 1.0
85 - 100 0.0
So, for example, a value of 60 miles could be achieved by using gain1_thresh = 94 and
gain2_thresh = 84. For Release 22, several enhancements to the Distance Based Directed
Handoff were introduced, including an upper distance threshold. The enhancements consist of
new parameters to replace the Gain Threshold for High Capacity settings by Border Sector
Distance Lower and Border Sector Distance Upper Thresholds (dho_lower_prm and

122
dho_upper_prm on the ceqface form). The new parameters include a flag to enable the
enhancements (Enable Distance-Based Hand-off Phase 2, dho_enable on the ecp form) and a
translation to specify the distance units (Border Sector Distance Threshold Units, dho_unit, in
miles or kilometers in the ecp form).
The new distance threshold controls the handoff in such a way that the handoff is triggered if the
following conditions are met:
 The distance from the mobile to each member of the active pilot set is greater than the
lower distance threshold AND Ec/Io threshold requirements have been met, OR
 The distance from the mobile to each member of the active pilot set is greater than the
upper distance threshold regardless of the Ec/Io threshold requirements.
Other parameters check for the validity of the measurements used for distance determination
(Border Sector Distance Validity Check Period, dho_valid_prm on the ceqface form), or for
distance differences (Border Sector Distance Upper Limit Difference, dho_du_prm, also on the
ceqface form). With this enhancement, additional service measurements have been introduced
which can be used to determine reference Ec/Io and round trip delay measurements for the
directed handoff. See [30] for more information.
3G-1X Mobile Assisted Inter-frequency Handoff
For Release 22 a feature called Mobile Assisted Inter-frequency Handoffs (MAIFHO) was
introduced to increases inter-frequency handoff success rates. This feature allows IS-2000
Protocol Revision 6 (or higher) mobiles in RC 3 or higher, to measure pilot strengths on different
candidate frequencies. The measurements are compared against thresholds that determine
whether an inter-frequency handoff should be triggered. The feature applies to CDMA 3G-to-3G
or 3G-to-2G semi-soft and hard handoffs.
The feature requires a FAF entry and is enabled using the 3G1X MAIFHO flag in the cell2 form,
and by using the Enable MAIFHO (maifho_enable in the cell3g form) for 3G1X Voice calls, and
the Enable MAIFHO for 3G Packet Data (maifho_3gd_enbl in the cell3g form) for 3G1X Packet
data calls.
If this feature is enabled, cell sites send a Candidate Frequency Search (CFS) Request message to
a mobile on all handoff legs (provided all handoff legs are running Release 22) if the following
conditions are met:
 For 3G voice calls (Service Option other than 33), the MAIFHO feature is enabled
 For 3G data calls (Service Option 33), the MAIFHO feature is enabled for 3G Packet
Data Calls
 The Radio Configuration of the call is equal to or greater than 3
 IFHOTI is enabled & the strongest border pilot minus the strongest interior pilot is
greater than Border Pilot versus Interior Pilot (BPIP) Threshold (bpinp_comp in the
ceqface form)
 The Ec/Io Loss Metric is greater than the MAIFHO Loss Metric Threshold (maifho_loss
in the ceqface3g form)
 And one of these two is true:

123
o If the Distance Based Inter-frequency Handoff feature is enabled, the slew-

compensated and valid one-way distances to each sector in the active set are
greater than the MAIFHO Border Sector Distance Threshold (maifho_dist in
the ceqface3g form)
o If the Distance Based Inter-frequency Handoff feature is disabled, OR is
enabled, but the slew-compensated one-way distances are NOT valid, the
non-compensated distance to each sector in the active set is greater than the
MAIFHO Border Sector Distance Threshold (maifho_dist in the ceqface3g
form)
The mobile responds to the Candidate Frequency Search Request with candidate pilot strength
measurements. If the combined signal strength of the candidate pilots is stronger than the
combined signal strength of the active set pilots by the MAIFHO Active Set vs. Candidate Set
Comparison Threshold (maifho_a_tcomp in the ceqface3g form) a MAIFHO handoff trigger is
generated, whereby the cell site directs the mobile to the best handoff candidate. This feature adds
two new service measurements: CDMA-PAF-CARR-SC 81 and 82. One counts the number of
lost calls that occur while a mobile is searching for interfrequency candidates, the other counts the
number of times the primary leg receives a Candidate Frequency Search Report. See [31] for
more information.
Prior to Release 27, there were several RF conditions where the Candidate Frequency Search
Report message used by MAIFHO processing was not forwarded to the RCS for handoff
evaluation. As a result, the handoff did not take place, and the call dragged, leading to a dropped
call. See AR 1-1365894 for more information.
4.2.2.1.4 Pilot Assisted Inter-Frequency Handoffs
There are also two forms of pilot-assisted inter-frequency handoffs, namely, the T_Comp method
(Pilot_Only_T_Comp) and the T_Add method (Pilot_Only_T_Add). The T_Comp method
triggers a handover when the border pilot exceeds the strongest Active Set pilot by t_comp (a
translatable parameter). With the T_Add method, the handover is triggered when the border pilot
crosses an absolute threshold, t_add. The t_add and t_comp parameters are set in the ceqface
database form.
It is generally recommended that the directed inter-frequency algorithms be used for all border
sectors, and not the pilot-assisted method. The reason for this is that, with the pilot-assisted
method, the border pilots will be a major source of interference until the handover actually takes
place. This is because the border sectors are transmitting only their pilots on their border carriers,
and may only participate in the call upon handing over to the common carriers. This increases the
probability that the call will drop even before the inter-frequency handoff has a chance to take
place.
Once the inter-frequency handoff is triggered, the next phase involves the network determining
the common carrier to go to and the pilots that will serve the call in the Active Set. This is based
on the translation entries in two forms, namely, the cdhfl and cdhnl forms.
In addition to other parameters, the cdhnl form contains a neighbor list for every border sector to
be used exclusively when performing inter-frequency handoffs. How these entries get used
depends on whether the CMPIFHO feature is activated. This feature is commonly referred to as
the ‘shotgun’ feature and may also be enabled on a cell-by-cell basis on the cell2 form.

124
The shotgun feature allows the mobile to enter directly into soft-handoff upon tuning to the new
common frequency.
When directed inter-frequency handoffs are used in conjunction with the shotgun feature, up to
six of the original border sector’s cdhnl neighbor list entries will be selected as the pilots to be in
soft-handoff. If there is more than one border sector in the Active Set, then a neighbor list
concatenation algorithm is employed to select the soft-handoff pilots based on the cdhnl neighbor
list entries of all the border sectors. The actual number of pilots that can be in soft-handoff is (7 –
Total number of CEs utilized in the call prior to semi-soft handoff). The reason for this is because
the same speech handler is used before and after the handoff, and the limit on the maximum
number of CEs that each speech handler can support is 7. Incidentally, these types of handoffs are
called semi-soft handoffs for this very reason, namely, because the inter-frequency handoff uses
the same speech handler.
With the pilot-assisted inter-frequency handovers, all the serving pilots in the Active Set as well
as all pilots of sufficient strength that are in the Candidate Set will become part of the Active Set
in the common carrier after handover, restricted of course to a maximum of 6-way soft/softer-
handoff. Note that the call could potentially go into 6-way handoffs with all inter-frequency
handoffs regardless of the Maximum Number of Active Set Pilots (maxlegs) translation parameter
setting in the ceqface database form.
A very significant point to understand about the pilot-assisted inter-frequency handoffs is that
such handovers may happen even on interior sectors that are out of resources to support the call
on the carrier it is on, a process referred to as handoff escalation. Therefore, turning on the
shotgun feature will improve handover performance of the entire system, especially when
capacity and/or hardware problems cause many of these handovers to occur.
A key point about using the shotgun feature is that this feature will only be utilized if every sector
that is a candidate to be in soft-handoff has this feature activated in the cell2 form for its
associated cell. It is therefore advised to turn on this feature on every cell in the system, as there
is every advantage and no disadvantage to having this feature activated.
If the shotgun feature is not activated in a cell, then the call goes into simplex mode on a single
pilot in the Active Set upon inter-frequency handoff.
With directed handoffs, the pilot selected to be in simplex mode is the first entry in the cdhnl
neighbor list of the strongest border sector when the handoff was triggered. It is therefore usually
imperative that the first entry of the cdhnl neighbor list be its own sector to ensure reliable
handdowns.
With pilot-assisted handoffs, the pilot selected will be the border pilot itself in the case of the
Pilot_Only_T_Comp method and the strongest pilot in the Active Set for the Pilot_Only_T_Add
method.
4.2.2.1.5 3G-1X Return from Handoff Failure
For Release 22 a new feature called 3G-1X Return from Handoff Failure was introduced. This
new feature allows mobiles to return to the cell site that started the semi-soft (or hard handoff)
attempt when the handoff fails. This feature allows IS-2000 Protocol Revision 6 (or higher)

125
mobiles, using Radio Configuration 3 or greater, to return from failed hard handoffs for 3G Voice
calls and from failed semi-soft handoffs for 3G Voice Circuit Data or 3G Packet Data calls.
Before this feature, whenever a semi-soft or hard handoff failed, the old primary and secondary
legs would release all resources related to the call. With this feature, the old primary and
secondary legs will not release those resources and attempt to communicate with the mobile.
The feature requires a FAF entry and is enabled by using the Allowed to Return If Semi-Soft HO
Fail (rtn_ssho_fail in the cell3g form) for semi-soft handoffs and by using the Allowed to Return
If Hard HO Fail (rtn_hho_fail in the cell3g form) for hard handoffs. Additionally, a handoff
timer, HO Wait Timer (ho_wait_timer in the cell3g form) has been added which tells how long
the old primary cell shall wait for the mobile to return from a failed handoff. The return from
failure evaluation for hard or semi-soft handoffs is slightly different; see [31] for more
information. Additionally, service measurement counts have been added which peg the number of
times mobiles return from inter and intra MSC hard and semisoft handoffs. See [23] for more
details.
4.2.2.1.6 Optimization Steps for Reducing CP Fail Drops
The suggestions below address the common causes for dropped calls listed above.
 It is very important to manage the inter-frequency handdown and handover

performance in the network. To that effect, it is recommended that the following be
done:
 In all cases when the rf carrier assignment algorithm is used on border sectors, it is
imperative that the IFHOTI algorithm is also employed on those sectors. Section
4.1.2.1.3 describes the carrier assignment algorithms in detail, while the topic on
Inter-Frequency Semi-Soft Handoff Concepts in this section discusses the IFHOTI
algorithm. Note however that IFHOTI (in conjunction with the shotgun feature) is
only effective if properly optimized. Therefore, great care must be taken to populate
the cdhnl neighbor list entries, keeping in mind the potential neighbor list
concatenations that may occur. Detailed multi-carrier optimization procedures are
presented in [20].
Important: Note that a limitation of the IFHOTI algorithm is that, even after all the
triggers are met, the semi-soft handoff will finally only be directed if the
call is using a maximum of three CEs. Therefore, all border sectors using
this algorithm as well as all interior sectors that interact with it must
have their maxlegs parameter set to 3, to ensure that the call can at most
go into 3-way soft handoff in the border areas.
 All cells should turn on the shotgun feature. There is no disadvantage to turning on
this feature and the potential benefits are significant, especially in cases where
several unexpected inter-frequency handovers are occurring in the system. The
shotgun feature is discussed under the topic on Inter-Frequency Semi-Soft Handoff
Concepts earlier in this section (Section 4.2.2.1.2).
 Ensure that the first entry in all cdhnl forms is its own sector. This is especially
important when the Tr_Cho algorithm is used for handdowns, as the call will almost
certainly drop if this is not the case. The topic on Inter-Frequency Semi-Soft Handoff
Concepts previously in this section discusses why this will be the case.

126
4.2.2.2 CP Fail Causes and Associated Fixes
4.2.2.2.1 Poorly Optimized Border Sectors
As discussed in Section 4.2.2.1, poorly optimized border sectors will result in an increase in CP
Fail Drops because of Handoff Completion Timeouts during inter-frequency semi-soft handoffs.
If poorly optimized border sectors are truly the root cause of the high CP Fail Drops, then both of
the following conditions must be satisfied.
 All sectors exhibiting high CP Fail Drops are also border (handdown) sectors.
Border sectors may be easily determined by looking for the existence of the cdhnl
and cdhfl entries for these sectors.
 All sectors exhibiting high CP Fail Drops are also exhibiting poor hard handoff
order to completion success rates. Figure A-2 illustrates how this failure condition
results in CP Fail Drops. In addition to looking at the peg counts indicating poor hard
handoff order to completion success rates, the new Release 26 “CDMA Handoff
Matrix (HOM) Tool feature” may be used to track the number of inter-frequency
handoffs from each source sector-carrier.
Given below are various suggestions that will help alleviate border sector performance problems.
 Employ IFHOTI to trigger handdowns. The IFHOTI triggers ensure that the
handdowns are occurring at predictable locations, increasing the consistency of the
handdown performance. The IFHOTI mechanism is discussed in detail in Section
4.2.2.1.2 earlier in this chapter.
 Optimize cdhnl entries. The proper population of these cdhnl entries will require
knowledge of the locations of the handdowns as triggered by the IFHOTI mechanism
discussed above. This topic is also discussed in Section 4.2.2.1.2, and in [20]. Use the
new per-carrier handoff counts to verify that the inter-frequency handoffs are
occurring between the desired carriers. See [46] for more information.
 Eliminate unnecessary border sectors and make them full-traffic. This is
especially true with systems that have border sectors that were originally configured
using the older Tr_Cho handdown triggering mechanism (see Section 4.2.2.1.2).
With this older mechanism, a fairly thick border area needed to be configured
because handdowns will only occur when all pilots in the Active Set are border
sectors. With the newer IFHOTI algorithm, such a limitation is removed, allowing for
a much smaller border area, with almost all interior cells having the ability to be
configured as full-traffic sectors.
 Employ the Distance Based Handoff and/or Mobile Assisted Inter-frequency
Handoff features. For those areas where the IFHOTI triggered handoffs are not

127
reliable enough (for example, along rolling hills where directed handoffs may ping-
pong between cells, or other difficult RF conditions) use the distance based handoffs.
For Release 22, parameters have been introduced that control the lower and upper
distance thresholds used to trigger handoffs. See 4.2.2.1.2 for more information. For
those areas where other candidate frequencies have enough coverage to provide
accurate pilot strength measurements, consider using the Mobile Assisted Inter-
frequency Handoff feature.
 Employ the Return from Handoff Failure feature. For those areas where fixes are
non-trivial or long-lead items, employ the Return from Handoff Failure feature.
While the root cause of the poor inter-frequency handoffs must be investigated, this
feature may help with reducing the effects of inter-frequency handoff failures.
 Employ the Distance Based Origination/Termination feature. Calls may get
assigned to border carriers in areas not optimized for hand downs (for example areas
far away from a site). When this happens, unwanted hand downs may get triggered
resulting in increased CP Fails. This feature may be used to prevent these CP Fails by
excluding border carriers from channel assignments, see 4.1.2.1.3 and [30] for more
information.
4.2.2.2.2 Incorrect Management of Cross-Carrier Assignments on Border Sectors
If a border sector is configured to use the rf carrier assignment algorithm, then the IFHOTI
algorithm as well as the shotgun feature must accompany it in order to maintain acceptable drop
call performance and achieve the desired capacity relief.
If the rf algorithm is used with the older Tr_CHo algorithm, then calls will get assigned to the
border carrier. Subsequently, these calls will typically almost immediately hand back down to the
common carriers. All inter-frequency handdowns will introduce the possibility of drops,
especially if features such as the shotgun feature are not activated.
This is because, without the shotgun feature, calls will start on the new frequency in simplex
mode. If that area happens to be a soft-handoff zone, then the possibility exists that the call will
drop, due to the high levels of interference, before it had a chance to add these soft-handoff
members into the Active Set.
Section 4.1.2.1.3 discusses the carrier assignment algorithms in detail.
If the incorrect management of cross-carrier assignments is truly the root cause of the high CP
Fail Drops, then both of the following conditions must be satisfied.
 All sectors exhibiting high CP Fail Drops are also border (handdown) sectors.
Border sectors may be easily determined by looking for the existence of the cdhnl
and cdhfl entries for these sectors.
 All sectors exhibiting high CP Fail Drops are also showing cross-carrier
assignments. Cross-carrier assignments may be determined to be occurring if these

128
border carriers are displaying call assignments in service measurements. Note that
there will be no seizures on these border carriers given the Omit Border Carrier from
Channel List Message feature (which is automatically activated on all handdown
border sectors without requiring any translation entries). This means that if the border
sectors are showing assignments, then this implies that cross-carrier assignments
have occurred.
The suggested fix is to maximize the semi-soft handoff success rate. Specifically, the following
suggestions may be followed.
 Employ IFHOTI to trigger handdowns. The IFHOTI triggers ensure that the
handdowns are occurring at predictable locations, increasing the consistency of the
handdown performance. The IFHOTI mechanism is discussed in detail in Section
4.2.2.1.2 earlier in this chapter.
 Optimize cdhnl entries. The proper population of these cdhnl entries will require
knowledge of the locations of the handdowns as triggered by the IFHOTI mechanism
discussed above. This topic is also discussed in Section 4.2.2.1.2.
 Eliminate unnecessary border sectors and make them full-traffic. This is
especially true with systems that have border sectors that were originally configured
using the older Tr_Cho handdown triggering mechanism (see Section 4.2.2.1.2).
With this older mechanism, a fairly thick border area needed to be configured
because handdowns will only occur when all pilots in the Active Set are border
sectors. With the newer IFHOTI algorithm, such a limitation is removed, allowing for
a much smaller border area, with almost all interior cells having the ability to be
configured as full-traffic sectors.
4.2.2.2.3 Drops due to Undesired Hard-Handovers
Undesired hard-handovers may result due to sector resource blocking on one carrier, causing all
incoming calls to be redirected to another non-blocking carrier on the same sector, a process
referred to as handoff escalation. There will always be a risk of drops with any inter-frequency
handoff due to potential differences in sector coverage and/or interference levels between the
carriers.
These handovers may be considered as undesirable because these sectors were never intended to
perform such inter-frequency handovers, and therefore were not designed and optimized for this
purpose.
This root cause may be suspected if high drop call percentages are observed on all sectors that are
pointing towards a sector experiencing cell resource blocking on one or more carriers. It can be
inferred that inter-frequency handoffs were being attempted if the blocking sectors are pegging
handoff overflow counts and/or power overload handoff block counts on one or more, but not
all, carriers.

129
The solution to this problem is to solve the cell resource-blocking problem. Understanding and
resolving cell resource blocking is an involved topic in its own right, and is discussed in detail in
Sections 4.1.4, 4.1.5 and 4.1.6.
Note that, in addition to solving the cell resource-blocking problem, the shotgun feature should be
enabled on every cell in the system. This way, even if these undesired hard handovers happen, the
semi-soft handover success rate will be greatly improved. The topic on Inter-Frequency Semi-
Soft Handoff Concepts earlier in this section (Section 4.2.2.1.2) discusses the shotgun feature in
detail.

130
4.3 FCH Frame Error Rate
4.3.1 Concepts and Optimization Techniques

As discussed in Section 4, there are three main components to a wireless voice system that will
make the customers perceive it to be of high quality, namely, the ability to easily get onto the
system to make calls, maintain good voice quality for the duration of the call, and gracefully end
the call when done with the conversation.
The previous two KPIs address two of these components, namely, the access to the network and
the drop call rate. This current KPI addresses the third component, which is the voice quality
during the call.
The frame error rate is defined as the ratio of the number of bad frames received over a period of
time to the total number of frames received in that same duration. It is generally accepted that the
FER is a good indicator of voice quality in digital wireless systems. The high-level equation for
Frame Error Rate is:
Frame Error Rate 

Bad Frames Re ceived
x 100%
Total Frames Re ceived
This rate may be measured on both the forward and reverse links as Forward Frame Error Rate
(FFER) and Reverse Frame Error Rate (RFER) respectively. Each of these is discussed in detail
below.
4.3.1.1 Forward Frame Error Rate (FFER)
4.3.1.1.1 2G and 3G Radio Configurations
Before getting into the discussion of FFER concepts and formulas, it is instructive to understand
the various radio configurations that are available for 2G and 3G calls.
Formerly, with 2G (IS95A/B) networks, two types of rate sets were available, namely Rate Set 1
(8 kbps vocoder rate), and Rate Set 2 (13 kbps vocoder rate). These rate sets are commonly
referred to as RS1 and RS2 respectively.
With the advent of the 3G1X standard (IS2000), backward compatibility was maintained, and 3G
mobiles operating on 2G channel cards will employ the exactly same protocols and behavior as
RS1 and RS2, but are referred to as 3G Radio Configuration 1 (RC1) and 3G Radio
Configuration 2 (RC2) respectively.
For 3G mobiles operating on 3G cards, the types of calls available are RC3 through RC5, where
these different types are distinguished by their data rates and coding techniques. The following
table (directly taken from [7]) describes these radio configurations, as per the IS2000 standard.

131
Table 4.7 2G AND 3G RADIO CONFIGURATIONS

Radio Configuration
System Type IS-2000 Vocoder Rate
IS-95 A/B
Forward Reverse
2G Rate Set 1 RC1 RC1 8 kbps
2G Rate Set 2 RC2 RC2 13 kbps
3G1X N/A RC3 RC3 8 kbps
4.3.1.1.2 FFER Calculation for 2G RS2
The FFER is computed differently for 2G RS2 calls versus 2G RS1 and 3G RC3-5 calls (see
Table 4.7 above for definitions of these configurations). This is because of the different power
control and frame error reporting mechanisms in place for these different types of calls.
However, among these, only the 2G RS2 calls provide currently enough information for the
network to compute and report FFER accurately. The reason for this is because the forward
power control algorithm employed by 2G RS2 (and equivalently, 3G RC2) calls provides the
network with enough information to calculate the FFER precisely. An indicator (called the
Erasure Indicator Bit – EIB) is sent with each frame that is sent on the reverse link with
information on whether the forward channel frame received two frames back was in error or not.
These erasure counts may be summed to provide an exact calculation of the frame error rate in
service measurements, since the network will also have precise knowledge of the total number of
frames transmitted to all the mobiles.
The RS2 FFER may therefore be calculated as follows:
FFERRS 2 
Number of RS 2 FL Frame Erasures
x 100%
Total Number of RS 2 FL Frames Transmitted
where FL = Forward Link
this KPI.
In addition, there is sufficient granularity in the returned information from the mobile to also
determine the FFER for only full-rate frames. This is important because services such as voice
carry all useful information over full-rate frames only and use lower rate frames for quality-
insensitive data such as simulated background noise.
The RS2 Full-Rate FFER may therefore be calculated as follows:
FullRate FFERRS 2 
Number of RS 2 FullRate FL Frame Erasures
x 100%
Total Number of RS 2 FullRate FL Frames Transmitte d

132
where FL = Forward Link
With 2G RS1 (and equivalently, 3G RC1) calls however, the forward power control algorithm
calls for the mobiles to report frame errors on the forward link using the Layer 3 message Power
Measurement Report Message (PMRM). The algorithm used to determine when and what to send
on this message is as follows.
Prior to Release 21, the mobile counts the number of forward link frames in error over a
predefined number of frames, which may be entered in the translation field Power Control
Reporting Frames (pwrrptframes; default = 56 frames or 1.12 seconds). If the number of errors
exceeds a specific number of frames, also a translatable parameter Power Report Delay
(pwrrptdelay; default = 2 frames), then a PMRM is sent by the mobile to the serving sector with
information on the measurement interval and number of frames in error. These translations are no
longer used for Release 21, see Section 4.3.1.1.3 for more information.
Upon sending the PMRM, the mobile waits for a certain number of frames before starting its
measurements again. This waiting period is translatable and usually defaulted to 20 frames. Note
that there will be no frame error checking by the mobile during this waiting period.
If the number of errors detected during a measurement interval does not exceed the predefined
threshold, then the counter and measurement period resets and the process is repeated.
The important point to note is that, given this algorithm, it will not be possible for service
measurements to calculate the FFER accurately for these calls. This is because forward frame
errors that occur during the waiting periods, after PMRM generation, will not get captured and
reported back to the base station by the mobile.
Even if this waiting periods are disabled (set to zero), the service measurements are currently not
set up to read the exact number of errors reported in these PMRM messages to arrive at an
accurate FFER reading.
4.3.1.1.3 FFER Calculation Using PMRM
For ECP/Cell Release 21 a new set of translations and peg counts have been introduced which
help in the collection of FFER data using PMRM messages for both the Fundamental and
Supplemental Channels, see [12]. The new FFER counts will be provided by all sectors
requesting PMRM messages from mobiles as primary sectors. The new counts are available for
2G and 3G Voice, and for 3G Data. For 3G Data calls, the counts are also available per F-SCH
rate.
The translations used for setting up PMRM reporting include parameters to enable the collection
of PMRM messages, as well as threshold-based, or period-based PMRM reporting parameters.
The translation Send PCPM for PMRM Reporting FER SM, pcpm_fer_sm, in the ceqface form is
used to set when the Power Control Parameter Message (PCPM) is sent to a mobile during call
setup. The PCPM message contains the settings the mobile uses to report data in the PMRM
messages. Other translations control whether PMRM data is reported on a periodic basis or a
threshold basis, with additional parameters controlling the period and threshold. See [12] for
more information.

133
There are separate settings for these parameters for RC1 (2G RS1) calls versus calls on other RCs
(RC 2 through 5). This is because the 2G RS1 forward power control mechanism is intimately
tied to the PMRM mechanism, and so the settings must be handled with care for these types of
calls and may need to be set differently from the rest.
Note that 3G calls (RC3 – 5) employ a completely different mechanism for forward power
control that relies neither on frame-by-frame indicator bits nor on the PMRM mechanism. They
rely instead on a very fast power control mechanism (400-800 Hz, which translates to up to 16
times a frame), where the burden of evaluating the downlink performance and subsequent
issuance of forward power adjustment commands is shifted to the mobile. The PMRM mechanism
may however always be turned on for these calls in order to facilitate the FFER service
measurement counters described above.
Along with the new translations controlling the reporting of PMRM messages Release 21
introduces new service measurement peg counts used to calculate both FFER and RFER. The
new FFER peg counts break down the frame counts per Radio Configuration (RC1 through 5),
Vocoder type (13K, EVRC, SMV), and Voice or Data, with the Data counts having separate
counts for the Forward Fundamental and Forward Supplemental Channels. Additionally, the
Supplemental Channel counts are broken down by F-SCH rate. See Appendix A for metrics using
these new peg counts, and Section 4.3.1.2 for more information on the RFER counts.
For Release 21, the new FFER peg counts used scaling factors to report frame counts and frame
errors. The scaling factors used were 1024 for frame counts and 128 for frame error counts. This
meant that for frame counts, the total number of frames transmitted was rounded off to multiples
of 1024; the same was true for frame errors, which were rounded off to multiples of 128. Also,
the total frame count was being rounded down to the nearest multiple of 1024. The scaling factors
were needed to avoid overloading the CCC/CRC and the TDM buses. These scaling and rounding
off actions do not introduce large inaccuracies for high traffic periods, however for low traffic
periods, the inaccuracies may be significant.
4.3.1.1.4 FER Reporting Changes for Release 22
For Release 22, the scaling factors and the rounding criteria for the new FER peg counts have
been changed to improve their accuracy for both the FFER and RFER counts. For Release 22, the
new scaling factors are the following (with the Release 21 scaling factors included for reference):
Table 4.8 SCALING VALUES FOR FER PEG COUNTS: R22 VS. R21
R22 Frame Count R22 Frame Error
Rate
Scale Factor Scale Factor
9.6 Kbps (FCH) 512 64
19.2 Kbps (2x SCH) 256 32
38.4 Kbps (4x SCH) 128 16
76.8 Kbps (8x SCH) 64 8
153.6 Kbps (16x SCH) 32 4
307.2 Kbps (32x SCH) 16 2
All Rates 1024 128

134
Additionally, the rounding criterion for the FER counts for Release 22 is to round the frame
counts to the closest scaled value.
4.3.1.1.5 Optimization Steps for FFER
The optimization steps suggested for FFER will be identical to those recommended to manage
drop calls (Section 4.2.1). This is because typically most drop calls will be preceded by a period
of high FFER. The converse is also true, that is, an area with high FFER will also be an area with
a high likelihood for drops.
Therefore, Section 4.2.1 may be referenced for details on optimization recommendations.
If no other performance problems are apparent and the FFER metric shows relatively high values,
it may be due to the PMRM parameter settings. For example, threshold based reporting may be
used instead of periodic based reporting. See [12] for more information.
4.3.1.2 Reverse Frame Error Rate (RFER)
4.3.1.2.1 RFER Calculation
The RFER may always be computed precisely by the network because the information is captured
right at the network. The network, which subsequently evaluates whether these frames are
received in error, captures all the frames sent by the mobile or not. The RFER may then be
computed.
The RFER may be computed precisely for all rate sets, and may be calculated as follows:
RFERVO 
Number of RL Frame Erasures of Vocoder VO
x 100%
Total Number of RL Frames Received of Vocoder VO
where RL = Reverse Link

VO = Vocoder (13K/8K/EVRC)
Note that it is not possible with the currently available service measurement peg counts to
distinguish the frame error rate on just the full-rate frames on the reverse link. This is a significant
point for the reverse link for pre-Release 18.0 cells because the different frame rates on the uplink
are power controlled to different quality levels, with the full-rate frames being afforded the best
quality.
Because of this, the Aggregate RFER on pre-Release 18.0 cells will typically always be worse
than the FFER, be it Full-Rate FFER or Aggregate FFER. Aggregate RFER values would be in
the order of twice as bad as the Aggregate FFER. The reason for this is explained in greater detail
below.
All base stations that are in soft-handoff will receive identical frames from the mobile at any
instant in time. Therefore, the network will have to evaluate these frames and select what it
perceives to be the best one. This is achieved through a process known as frame selection that is
done at the MSC level. The frame selector will select any frame that is received without error,

135
and will only declare the entire frame an erasure if all the frames from the base stations in soft-
handoff fail their CRC checks.
Intimately tied to this process is the reverse link power algorithm. There are two main
components to this algorithm, namely the open-loop and close-loop algorithm. The open-loop
algorithm sets the coarse mobile transmit power purely based on the receive power and some
adjustment factors. The closed-loop algorithm further fine-tunes this transmit power based on the
real-time reverse Eb/No requirements.
The closed-loop algorithm also consists of two components, namely, the inner-loop and outer-
loop algorithms. The inner-loop is between the mobile and each base station involved in soft-
handoff. Each base station requests the mobile to either increase or decrease its transmit power
based on the desired Eb/No target value, which is called the Eb/No Setpoint. The outer-loop is at
the MSC level. This algorithm uses the quality of the link based on after-frame-selection
performance to fine-tune the Eb/No Setpoint to be used by all the base stations in the inner-loop.
Important: Another important factor used by the outer-loop in determining the Eb/No
Setpoint is the state of the call that is based off the frame rate (full-rate, half-rate,
etc.). Full-rate frames on pre-Release 18.0 cells are afforded the highest quality
and will therefore warrant the highest Eb/No Setpoint.
This is a very important point to understand when interpreting service measurement counts for
RFER. As mentioned above, the reverse link frame error and total counts in service
measurements do not differentiate between the rates of the frames. Therefore, the calculated
RFER will be an aggregate FER over all rates. This will result in the RFER always looking
significantly worse than the Full-Rate FFER values because the forward link power control
algorithm has no component to adjust the transmit power uniquely for different forward link
frame rates.
Starting with Release 18.0, all reverse link rates are afforded the same quality. Therefore, the
Aggregate RFER values will no longer be inflated, and instead should be in-line with the target
RFER setting in translations.
4.3.1.2.2 RFER Reporting Changes for Release 21
A new set of service measurement counts for reporting Reverse Frame Error Rate has been
introduced in ECP/Cell Release 21. The new peg counts break down the frame counts per Radio
Configuration (RC1 through 4), Vocoder type (13K, EVRC, SMV), and Voice or Data, with the
Data counts having separate counts for the Reverse Fundamental and Reverse Supplemental
Channel. Additionally, the Supplemental Channel counts are broken down by R-SCH rate. See
Appendix A for metrics using these new peg counts and [12] for more information.
No translation settings need to be changed in order to use the new Release 21 RFER peg counts.
4.3.1.2.3 RFER Reporting Changes for Release 22
For Release 22, there are several changes in the way the RFER pegs are counted. The first change
is explained in Section 4.3.1.1.4 with regards to the scaling factors. The second change
introduced in Release 22 is that previous to this release, the base station was evaluating reverse
traffic frames before the mobile actually started transmitting in the reverse traffic channel. During

136
a short interval of time (about 30 to 34 frames worth), the base station was counting frame
erasures even though the mobile is not acquired in the traffic channel yet.
For R-SCH FER counts, two additional changes are implemented in Release 22 which consist in
stopping the evaluation of reverse frames after the base station receives a request from the mobile
to end a data burst, and better evaluation of DTX frames. In the first case, the base station was
evaluating about 11 R-SCH frames after receiving a mobiles’ request to end the burst. In the
second case, some DTX frames were being evaluated as frame errors, artificially increasing the
R-SCH FER. See [12] for more information.
4.3.1.2.4 Optimization Steps for RFER
As with FFER, all of the recommendations for optimizing drop call performance (Section 4.2.1)
also apply to managing RFER performance. This is because a failure on either the forward or
reverse link will result in a dropped call, making all issues pertaining to drop calls relevant to
both FFER and RFER.
In addition, there may be failures unique to the reverse link that could result in performance
degradations only in that link. These failures are less common and therefore are not addressed in
the drop call section but rather will be discussed in the following section.
4.3.1.2.5 Other Poor RFER Causes and Associated Fixes
The following discussion is limited to cases when the RFER is high but the corresponding FFER
is within normal ranges. As discussed above, if RFER and FFER have both degraded, then most
of the potential causes for dropped calls discussed in Section 4.2 will also apply in this case.
External Interference on Reverse Link Carrier Only
External interference raises the noise floor of the system, requiring the mobiles to increase their
transmit powers on the reverse link to overcome it. If the interference is significant enough, then
the mobile will run out of power and, as a consequence, the RFER performance will degrade.
In addition to high observed RFER, strong reverse link interference could exhibit high RSSI rise
and could even peg significant counts of reverse power overload even though the carried traffic
on the reverse link does not justify such high reverse loading.
uplink carrier. Typical interference will appear as spikes caused by inter-modulation products as
well as spurious signals. The source of the interference may be identified by driving around the
area and looking for the areas of concentration in the observed interference.
Loss of Reverse Link Diversity
Reverse link diversity gain is a critical component in ensuring good quality on the uplink. A
significant hit may be observed in received Eb/No should this gain be diminished, causing the
RFER to rise.

137
The reverse link diversity may be lost either because of antenna assembly problems on one of the
receive antennas, or because of faulty hardware related to the diversity branch.
Antenna assembly problems may be especially difficult to identify in cell sites that have an
exclusive antenna for receive diversity, as opposed to all antennas being duplexed to transmit
additional carriers. The ROP may be used to capture such problems through the DIVIMB error
under the REPT:CELL HEH message block.
Additional information on troubleshooting diversity imbalance for the ModCell 4.0 cell sites may
be found in Lucent Alert 05-026. The Lucent support Extranet contains additional information on
troubleshooting diversity imbalance issues and includes a diversity imbalance troubleshooting
tool for ModCells 1.0 through 4.0.

138
5. HIGH SPEED PACKET DATA (HSPD) - SPECIFIC KPI

OPTIMIZATION AND TROUBLESHOOTING
Conceptual Overview of Lucent Implementation of HSPD
With IS2000, two types of channels have been introduced to handle data traffic, namely the
Fundamental Channel (FCH) and Supplemental Channel (SCH).
The following section describes key performance indicators that are particular only to data calls.
These indicators are all related to the Supplemental Channel (SCH), which are employed
exclusively to provide high data rates for packet data calls.
The data call is initially established on the FCH, just like voice. Upon call establishment, data
transfers are initially over the FCH at a maximum rate of 9.6 kbps. If the call moves into soft-
handoff, then the data is transmitted over all soft-handoff legs on both the forward and reverse
links.
If sufficient backlogged data exists, then a SCH is set up to transfer the data at higher rates. One
of four possible discrete rates may be assigned. These rates are represented as multiples of 9.6
kbps as follows:
 2X (19.2 kbps)
 4X (38.4 kbps)
 8X (76.8 kbps)
 16X (153.6 kbps)
For Release 22 a new feature called Fast Packet Data Call Setup is introduced which shortens the
average call setup time for packet mode data calls. The feature affects new data call originations
as well as mobile and network data call re-activations. This feature consists of two changes. The
first change allows a cell site’s controllers and channel elements to acquire a mobile faster by
setting up the call on a traffic channel before receiving a speech handler confirmation from the
ECP. If the ECP lacks resources or determines the mobile is not allowed to make data calls, the
call is torn down. The second change consists of a reduction in the time it takes the channel
elements to deliver access burst messages to the cell controller.
The feature is enabled using the Fast Packet Data Call Setup Enabled (fastpkt_enable in the
ecp3g form) parameter. Enabling this feature must be done after considering resource utilization
since mobiles not allowed to make data calls may consume system resources for short periods of
time, reducing the system’s overall data capacity. See the Blocking / Rate Reduction sections for
information on resource utilization. It has been reported that the Fast Packet Data Call Setup
feature may not process call setup events properly for all releases up to Release 24. This may
cause call setup failures that are reported as asserts and call processing failure messages in the
ROP. See Lucent Alert 05−0589a for more information. This problem was corrected for releases
24.02 and beyond.
The figure below shows how the SCH and FCH channels are utilized for a typical web browsing
session. For the forward link, depending on the amount of backlog, measured in bytes at the 5E,
and depending on the resources available at the cell, a SCH is set up for a given rate and for a

139
given duration. Before Release 21, the FCH or the SCH may transmit data on the forward link,
but not both simultaneously. To conserve resources and minimize interference, the FCH is torn
down after a period of inactivity (e.g. 15 seconds, this period is controlled by the RLP Inactivity
Timer, rlp_tmr in the ecp and sub forms, if the sub form exists). However, the PPP connection
between the mobile and the client (e.g. a laptop with a wireless modem card or data-capable
mobile attached to it) and the IWF or PCF/PDSN is maintained.
Web Browsing Session
Dormant Active Dormant Active
Supplemental
Channel
Bursts
First
Data
153.6 153.6 153.6
Arrived SCH SCH SCH
at IWF
76.8 76.8 76.8
SCH SCH SCH
38.4
9.6 kbps FCH 9.6 FCH
Mouse Start Mouse Fundamental

Click Reading Click Channels
Web Page
Access
Time
Download Dormancy Timer
Network Time Duration
Delay Queuing Delay
"Think" Time
( incl. SCH Setup Delay)
FIGURE A-3 FCH/SCH UTILIZATION FOR TYPICAL WEB BROWSING SESSION
Forward Supplemental Channel (F-SCH) Implementation
Prior to Release 21, in the Lucent implementation, SCH can only be transmitted in simplex mode
over the downlink. That is, only a single pilot, known as the Anchor Leg, transmits over the SCH,
even in soft-handoff areas. The FCH connection is always maintained in soft-handoff, even while
the SCH is up. The FCH will primarily be used for control purposes during SCH transfer.
The reason for doing this is two-fold. The level of RF interference and power consumption on the
downlink will be greatly reduced by preventing all soft-handoff legs from transmitting at these
high levels. Also, considerable resources (Channel Elements and Packet Pipes) can be saved at
the network end by not needing duplicated resources on multiple cell sites for the same data call.
The Anchor Leg is not necessarily the Primary Leg. The Primary Leg, as in 2G Voice calls
assumes call control and signaling functions and exists for voice as well as data calls. For HSPD
calls it also controls Anchor Leg setup and tear down. The Anchor Leg is the leg that transmits

140
the strongest pilot as seen by the mobile, it determines the F-SCH rate, and data burst duration
and start time. The Primary Leg sends the messages instructing the mobile about SCH setup and
tear down. If a HSPD call is in simplex mode, the Primary Leg assumes the role of the Anchor
Leg if it can support packet data calls [28]. Anchor transfer is the process of tearing down the F-
SCH and moving it from its current leg to another leg and setting up the F-SCH anew.
In Release 21 a new feature called “3G-1X HSPD Mobility Improvements Using Softer Handoff
For The Forward Supplemental Channel” is introduced. While the F-SCH is still transmitted in
simplex in soft-handoff areas, this feature allows the transmission of the F-SCH in the softer
handoff state. This benefits the F-SCH Burst Rates by avoiding anchor transfers in softer handoff
areas without using extra channel elements or packet pipe bandwidth. However it must be kept in
mind that RF downlink transmit power and Walsh Codes would be used up by the softer leg. New
translations have been introduced which enable this feature and set several thresholds for its
operation. See [5] and [37] for more information.
Another Release 21 feature, namely the “3G-1X HSPD with Simultaneous Transmission on FCH
and SCH (CDMA)” feature allows transmission of data packets on both the F-FCH and F-SCH at
the same time. See [5] for more information. For Release 25, as part of the new Customer Critical
Translations Maintenance - Phase 1 feature, a new parameter called Simultaneous Transmission
on F-FCH and F-SCH on the ceqface3g form, is used to enable the simultaneous transmission of
data on the F-FCH and F-SCH. See the Release 25 release letter for more information.
For Release 22, a new feature called “3G-1X HSPD With Improved Scheduling: Dynamic F-SCH
Rate” further improves the F-SCH data rates. This feature allows dynamic F-SCH rate re-
assignment without terminating the current burst. The anchor leg evaluates resources for rate re-
assignment and notifies the 5E and mobile of the new rate while the existing burst is ongoing. See
[33] and [37] for more information. This improves forward data rate by reducing gaps between
bursts of different rates and by avoiding tearing down bursts for rate upgrades (which is the
current procedure prior to this feature).
This feature requires a FAF entry and is enabled by using the 3G IMPRV SCH II parameter in the
cell2 form. This feature also requires the 3G-1X HSPD with Improved Scheduling Algorithm
feature introduced in Release 20.
Reverse Supplemental Channel (R-SCH) Implementation
In contrast to the F-SCH, R-SCH will always be set up to transmit over all soft-handoff legs. This
is because it is critical in the reverse link for base stations to have influence over the power
control and rate determination of all mobiles that are received with sufficient energy at those
sectors. Uncontrolled rise in received interference could drive these sectors into an unstable state.
For the same reason, R-SCH will not be assigned if there is a strong Candidate pilot (not allowed
to enter into the Active Set for whatever reason) whose Ec/Io is greater than the strongest active
set pilot by a threshold. The threshold is determined by the rsch_apoffset (Ec/Io Offset for R-SCH
Admit (dB) in the ceqface3g form). Note that there is no increase in mobile transmit power due to
the fact that the mobile is being demodulated by several sectors in handoff, since the same reverse
signal is being demodulated by all the soft handoff legs, whereas significant power would need to
be consumed on the forward link for soft handoff of the F-SCH.
Additional information on F-SCH and R-SCH scheduling is available in the Translation

Application Note 11: Miscellaneous Topics, see [12] for more information.

141
SCH Rate Determination
The actual rate that is assigned to the SCH depends upon several factors. First, the maximum
SCH rate is obtained from the F-SCH Max Rate and R-SCH Max Rate translations (maxrate_fsch
and maxrate_rsch in the ecp3g and ceqface3g forms). Then, the F-SCH or R-SCH rates are
determined by the amount of backlogged data in the 5E (for the F-SCH) or the mobile (for the R-
SCH).
In the forward link, after this rate is determined, the 5E will send a burst request to the Anchor
Leg. At this stage the SCH rate may be further reduced depending on the outcome of four
resource managers, as follows:
 RF Capacity (SARA) Manager
 Channel Fragment (CF) Manager
 Packet Pipe (PP) Manager
 Walsh Code (WC) Manager
The ultimate rate assigned to the SCH by the cell is the minimum of the maximum rates returned
by each of these resource managers. Once this rate is determined, the Anchor Leg requests the
Primary Leg to send an Extended Supplemental Channel Assignment Message (ESCAM) to the
mobile alerting it of supplemental channel setup. In the reverse link, when the mobile determines
it has enough data to send, it sends a Supplemental Channel Request Message (SCRM) to its
Primary Leg to obtain resources for an SCH. If the call is in soft handoff, the Primary Leg queries
all Secondary Legs to determine the maximum supportable R-SCH rate. Each leg determines a
rate based on their resource managers with the R-SCH rate finally determined by the leg with the
minimum supportable rate. Note that the WC Manager is not applied to the R-SCH because
Walsh Codes are not used for channelization on the reverse link. Therefore, the R-SCH rate
determination algorithm will only employ the first three resource managers listed above.
For Release 21, new service measurement peg counts describing the SCH requested rates after
data backlog and before resource manager determination have been added. The new counts break
down the rate requested by forward and reverse SCH and by data rate. These counts may be
useful in determining those situations whereby the burst rate is low due to lack of backlogged
data. See Appendix A for other metrics using these new peg counts. If the Release 21 feature
“3G-1X HSPD Mobility Improvements Using Softer Handoff For The Forward Supplemental
Channel” is enabled, the Rate Requested counts are affected in this way: If the Anchor Leg is in
simplex mode, the service measurement peg counts are pegged at the simplex Anchor Leg; if the
anchor leg is in softer handoff mode, the counts are pegged at the initial Anchor Leg.
For Release 24, the F-SCH rate requested counts have been modified in the following ways: Fist,
the Rate Requested counts for all rates will only be pegged in cases of overload; second, the pegs
are no longer pegged when a continuation is denied for a rate upgrade attempt. Instead, the pegs
will get pegged when, after the upgrade attempt is processed, and the upgrade is denied. See the
appropriate release letter and [23] for more details.
When an Anchor Leg determines it can support an F-SCH it indicates the data burst rate, delay
time and duration back to the MSC. At the end of a data burst, it may be continued depending on
resource availability and data backlog. Currently, for an R-SCH, the Primary Leg assigns an R-
SCH for an infinite duration, and forces the mobile to send an additional SCRM to indicate the
end of a data burst.

142
For Release 24 two new peg counts, in the ECP-PAF-CARR section, tracking unauthorized
origination or termination HSPD call attempts have been added. The unauthorized origination
count has been moved from another section (the old Invalid 3G HSPD Origination Seizures
count), while the termination count is brand new. These counts are used to determine the number
of mobiles making HSPD call attempts but that are not authorized or provisioned to make these
calls. For newly deployed markets, where not many subscribers have provisioned their mobiles to
make data calls, the number of unauthorized calls may be relatively high. See [23] for more
information. Additionally, for Release 27 a new peg count, ECP-PAF-CARR CDMA 29, was
added which counts the number of Unauthorized 2G Packet Data Originations from 3G Mobiles.
This count is be pegged when a 3G mobile attempt is rejected with SO_REJECT and
subsequently tries 2G attempt which is also unauthorized.
Key Performance Indicator – SCH -Data Burst Rate
All problems with the SCH will ultimately manifest themselves as degradation in the achieved
SCH Data Burst Rate for the mobiles in HSPD calls. Therefore, this will be the only KPI to be
discussed for HSPD.
The high-level equation for SCH Throughput may be represented as follows:
 R  Rx_Frames R
SCH Throughput 
R  2,4,8,16
 Rx_Frames
x 9.6 kbps
R
R  2,4,8,16
where Rx_FramesR=2,4,8,16 refers to the total number of received frames of rate 2X, 4X, 8X and
16X respectively on the link under investigation.
All problems with data transfers will ultimately manifest itself as degradation in this achieved
throughput to the customers. It is however difficult to isolate throughput problems by merely
observing low throughputs at a sector since it is quite possible that the applications themselves do
not require or request higher rates. For example, if there are many low speed applications being
run on a given sector during a given hour, then low sector throughput for this sector is not
necessarily an indication of a problem.
There may also be other customer-perceived throughput problems that will never get captured
through service measurements to begin with. For example, mechanisms that interrupt the SCH
high-speed data transfer such as Anchor Transfers and inter-frequency handoffs will not get
reflected in the SCH Throughput metric described above.
However, given that there is sufficient backlogged data to send, SCH throughput will deteriorate
when either the assigned SCH rate is less than the maximum possible (16X), or when the SCH is
not transmitted altogether. Therefore, throughput problems are best tackled by knowing and
detecting the existence of all possible failure causes that are known to directly reduce throughput
to levels lower than that requested by the applications concerned.
The existence and extent of SCH throughput problems (from an end-user perspective) may
therefore be inferred from the presence and magnitude of one or more of the following possible
failure causes:
 Supplemental Channel Blocking / Rate Reduction

143
 Blocking / Rate Reduction due to RF Capacity

 Blocking / Rate Reduction due to Packet Pipe
 Blocking / Rate Reduction due to Channel Fragments
 Blocking / Rate Reduction due to Walsh Codes
 Excessive Anchor Transfers
 3G3G Inter-Frequency Handoffs
 3Gnon-3G Handoffs
 Outages and Errors in the Packet Network and other Cell Site Hardware Components
Each of these failure causes is discussed in detail in the following sections.
It should be noted that most of the necessary service measurements required to isolate these
failures are available in Release 19 (and beyond). The topics are still discussed since these
problems could still be occurring, even if the service measurements do not exist to capture them.
In this document we concern ourselves mostly with the throughput measured at the RLP (radio
link protocol) layer and the IS2000 physical layer, shown in the figure below.
PCF PDSN
Acctg.
& Auth.
AAA
PP IP
Internet
L-interf. IP
Laptop Mobile BS Router Server

IWF
(Client) (Terminal) MSC
APP APP
TCP TCP
UDP UDP
IP IP IP
PPP PPP
L2 L2
WAN WAN
Low-Level Low-Level RLP RLP FR FR
Interface Interface L1 L1
IS2000 IS2000 PP PP T1 T1
Client Terminal BS MSC IWF Router Server
FIGURE A-4 3G1X HIGH SPEED PACKET DATA NETWORK PROTOCOL STACK

144
5.1 Supplemental Channel Blocking / Rate Reduction

The ultimate SCH rate assigned by the cell will be the minimum of the rates returned by the four
resource managers (see Section 5 above for details on the resource managers). The SCH will be
prevented from being set up altogether if at least one of these resource managers is not able to
support even the lowest SCH rate (2X). If the SCH is not set up, the FCH will transmit any
backlogged data.
There will therefore be four possible failure categories corresponding to each of these four
resource managers, namely:
 Blocking / Rate Reduction due to RF Capacity

 Blocking / Rate Reduction due to PP Blocking
 Blocking / Rate Reduction due to Channel Fragments
 Blocking / Rate Reduction due to Walsh Codes
Each of these resource managers peg blocking, or rate reduction, service measurement peg counts
which are used for troubleshooting purposes, see Appendix A for a list of blocking and rate
reduction metrics.
In Release 21 a new feature called “3G-1X HSPD Mobility Improvements Using Softer Handoff
For The Forward Supplemental Channel” is introduced. Prior to this feature, the Anchor Leg
would always be in simplex so pegging of the blocking or rate reduction counts was always in the
anchor leg. If this feature is enabled, the Anchor Leg may now be in softer handoff mode, thus
the pegging of the blocking or rate reduction peg counts has been modified in this way: If the
Anchor Leg is in simplex mode, the service measurement peg counts are pegged at the simplex
Anchor Leg; if the anchor leg is in softer handoff mode, the counts are pegged at the initial
Anchor Leg.
In Release 24 new peg counts showing HSPD Overflows due to no 3G resources have been
added. These new counts peg HSPD origination or terminations (originations and terminations
with service option 33) that cannot be setup due to lack of 3G resources, whether the resources
are RF capacity resources, packet pipes, channel fragments, or Walsh codes. These new counts,
which are in the CDMA-PAF section, peg regardless of whether the 3G blocked calls get
assigned 2G resources. Thus these counts are quick indicators of whether any 3G HSPD blocking
is occurring.
Another set of new peg counts in Release 24 measure the Average Digital Gain Units utilized by
both voice and data forward traffic channels. The approximate amount of power utilized by voice
or data traffic may be determined using these new counts that are in the CDMA-PAF-CARR-RC
section. With this information, the voice-data power usage may be managed on a per-carrier basis
as needed. See section 4.1.5.1.1, [23] and the appropriate release letter for more information on
these new counts.
Further analyzing other peg counts and other information, such as ROP reports, may determine
blocking categories. The following sections examine failure causes and fixes/improvements for
each of these categories in detail.

145
5.1.1 Blocking / Rate Reduction Due to RF Capacity
This blocking / rate reduction occurs when the RF link is not able to support the requested SCH
rate. The primary sector associated with the data call will perform this determination by
employing the Supplemental Air Resource Allocation (SARA) algorithm. SARA is operated
independently for the forward and reverse links, and will be employed for the setup of each data
call on both these links.
5.1.1.1.1 Overview of SARA
The Supplemental Air Resource Allocation (SARA) algorithm administers the evaluation of the
RF link and subsequent rate allocation. This algorithm is invoked for each data call, and is
operated independently for the forward and reverse links.
The Forward SARA (F-SARA) algorithm is applied by the Anchor Sector and primarily uses the
following inputs to determine its maximum supportable rate on the forward link:
 Pilot measurements reported on all pilots seen by the mobile using the Pilot Strength
Measurement Message (PSMM).
 Available transmit power at the Anchor Sector servicing the data call.
The Reverse SARA (R-SARA) algorithm uses the following inputs:
 RSSI rise on each soft-handoff leg.

 Average reverse pilot Ec/Io of all data calls on each soft-handoff leg (used to
determine current loading).
For R-SARA, the algorithm is applied on all soft-handoff legs, and the minimum of the maximum
rates returned by each of these legs is selected as the final maximum supportable rate on the
reverse link.
A detailed discussion of the SARA algorithm is beyond the scope of this document, but in-depth
descriptions of this algorithm may be found in [5] and [6].
For Release 25, the new Customer Critical Translations Maintenance - Phase 1 feature added
several new optimization parameters. These parameters may now be used to further optimize both
the F-SARA and R-SARA algorithms. These new parameters are detailed in the Release 25 letter
as well as the previously listed references.
5.1.1.1.2 Forward Link Optimization Techniques
It has been found through optimization trials that the following conditions (in order of priority)
most often result in poor maximum rate assignments by F-SARA:
1) Lack of a clear dominant pilot in an area – that is, two or more pilots of approximately
equal strength (similar Ec/Io’s).

146
2) Excessive pathloss.
3) Excessive voice and data traffic.
Therefore, forward-link optimization for F-SARA would involve making sure the above three
conditions are minimized, especially in areas of expected significant high-speed traffic. The
suggested optimization techniques for each of the three conditions are discussed below.
Creating Pilot Dominance
Creating pilot dominance entails ensuring that a single pilot has sufficiently higher pilot receive
power (as measured through Ec/Io measurements) as compared to all other pilots in the area. This
can be best achieved through a combination of physical optimization (changes in antenna
orientation, downtilt, model etc.) and/or BCR/CBR attenuation changes.
Note that manipulating t_add, t_drop and other handoff parameters will not help create pilot
dominance because these parameters only control which pilots are allowed to enter into the
Active Set, but do nothing to change the fundamental pilot dominance, or lack thereof.
For softer handoff areas, where pilot dominance may be hard to achieve, consider using the “3G-
1X HSPD Mobility Improvements using Softer Handoff for the Forward Supplemental Channel”
feature. This feature should help reduce anchor transfers in softer handoff areas and may improve
forward supplemental channel data rates. Refer to [37] for more information.
Minimizing Pathloss
There are several choices for minimizing pathloss by improving coverage problems. They are:

Managing Voice and Data Traffic
There are several choices for managing excessive voice and data traffic. They are:
 Adding carriers to existing cell sites. This option would require justification and
planning due to the high cost associated with this solution.
 Add cell site to improve coverage. As when trying to minimize pathloss, this would
require extensive justification and planning because of the vastly higher costs
associated with this solution.

147
 Off-loading traffic to neighboring cell sites. While this option is less costly than the
previous two solutions, it requires some optimization and monitoring efforts to make
sure the performance of neighboring sites does not degrade to unacceptable levels.
 Consider using the “Voice vs. Data Call Admission” feature. This option would
require turning on this feature and determining optimal translation parameter settings
to help manage voice vs. data traffic. This feature can help manage low data rate
issues caused by using traffic channel cell resources for voice traffic at the expense of
data traffic (however care must be taken to balance voice and data performance
needs). See Section 4.1.2.1.3 and [36] for more information.
 Consider using the 3G-1X Call Admission Policy with System Resource
Reservation Based on RF Power” feature. If excessive voice and data traffic cause
a lack of RF power, and if data call admission has a priority over voice call admission
consider using this feature. For Release 24 this feature added an option to control call
admission for voice or data calls based on RF power. See Section 4.1.2.1.3 and [39]
for more information. However, care must be taken to balance voice and data
performance needs as well. This feature supersedes and is mutually exclusive of the
“Voice vs. Data Call Admission” feature that is based on FCH usage.
5.1.1.1.3 Reverse Link Optimization Techniques
For the reverse link, the primary conditions that often result in poor rate assignments were found
to be the following:
1) Strong Candidate pilot not allowed to enter into the Active Set.
2) Excessive pathloss.
3) Excessive voice and data traffic.
Therefore, reverse-link optimization for R-SARA would similarly involve making sure the above
three conditions are minimized. The suggested optimization techniques for each of these
conditions are discussed below.
Ensuring no Strong Candidate Set Pilots Blocked from Entering Active Set
There are two conditions that will result in strong Candidate Set pilots being rejected from
entering into the Active Set. These conditions, along with suggestions for fixes, are presented
below.
 Neighbor List problems. The network will reject allowing any sector to enter into
the Active Set if it does not belong in the neighbor list of at least one of the sectors
currently in the Active Set.
The suggested fix is to modify the neighbor list in accordance with the problem
detected.
If the problem is with missing neighbor list entries, then these neighbors should be

148
Note that there must be discipline exercised when adding neighbors, since sectors
with excessively large neighbor lists could perform poorly due to the increased
processing requirements. Additionally, given the fact that neighbor lists of sectors in
soft-handoff are concatenated, large neighbor lists increases the chances that some
neighbors will be dropped in this concatenated list.
eliminate the need for the neighbor list entry [19]. This would entail removing that
sector from the area through antenna downtilts, azimuth changes, antenna model
changes and/or BCR/CBR attenuation changes.
If the problem is with the integrity of the neighbor list, then the appropriate fix
Reciprocity
Reciprocity refers to making sure that if sector A is added to sector B’s neighbor list,
then sector B is also in sector A’s neighbor list. With CDMA networks, there is rarely
any justification for not satisfying reciprocity rules when populating neighbor lists
because all sectors are transmitting on the same frequency.
PN Ambiguity Issues
PN ambiguities may come in many forms. No two neighbors on the same neighbor
list can have the same PN assignment because this will confuse the network should
this PN be reported as a Candidate pilot. A less obvious problem will be when two
neighbors share the same PN as a result of neighbor list concatenation. This is
commonly referred to as two-way PN ambiguity problems (for any combination of
two neighbor lists) up to n-way neighbor list problems (n up to 6). Typically, only
two-way PN ambiguity checks are performed.
 Handoff sector is resource blocking on all carriers. If this is the case, then the
Candidate sector will be rejected from entering into the Active Set since that sector
will not have any resources to support the traffic channel.
The solution to this problem is to solve the cell resource-blocking problem. Cell
resource blocking can come either in the form of hardware resource blocking or
power resource blocking. Understanding and resolving cell resource blocking is an
involved topic in its own right, and is discussed in detail in Sections 4.1.4, 4.1.5 and
4.1.6.
Minimizing Pathloss

149

Managing Voice and Data Traffic
There are several choices for managing excessive voice and data traffic. They are:
 Adding carriers to existing cell sites. This option would require justification and
planning due to the high cost associated with this solution.
 Add cell site to improve coverage. As when trying to minimize pathloss, this would
require extensive justification and planning because of the vastly higher costs
associated with this solution.
 Off-loading traffic to neighboring cell sites. While this option is less costly than the
previous two solutions, it requires some optimization and monitoring efforts to make
sure the performance of neighboring sites does not degrade to unacceptable levels.
 Consider using the “Voice vs. Data Call Admission” feature. This option would
require turning on this feature and determining optimal translation parameter settings
to help manage voice vs. data traffic. This feature can help manage low data rate
issues caused by using most cell resources for voice traffic at the expense of data
traffic (however care must be taken to balance voice and data performance needs).
See Section 4.1.2.1.3 and [36] for more information.
5.1.1.2 RF Capacity Related Failure Causes and Suggested Fixes
5.1.1.2.1 Excessive Areas Lacking Pilot Dominance
It has been found that there is a strong correlation between pilot dominance and assigned data
rates on the SCH. Poor rates will be assigned when there is a lack of a clear dominant pilot in an
area, that is, there are two or more pilots of approximately equal strength (similar Ec/Io’s).
Identifying areas lacking pilot dominance is difficult to do with service measurements. However,
the Anchor Transfer Rate and the Pilot Pollution metrics could be used to estimate the problem
(available with R19 and beyond). These areas are best captured with drive tests. An area can be
considered to lack pilot dominance if there are extended stretches where one or more pilots are
very close in Ec/Io to the strongest (dominant) Active Set pilot.

150
The suggested fix is ensuring that pilot dominance is achieved in the affected areas. This can be
best achieved through a combination of physical optimization (changes in antenna orientation,
downtilt, model etc.) and/or BCR/CBR attenuation changes.
Note that manipulating t_add, t_drop and other handoff parameters will not help create pilot
dominance because these parameters only control which pilots are allowed to enter into the
Active Set, but do nothing to change the fundamental pilot dominance, or lack thereof.
5.1.1.2.2 Excessive Pathloss
Cell sites and/or mobiles will lack the necessary transmit power to achieve the desirable Eb/No at
the receiving end should the pathloss be too excessive. Data calls will be even more sensitive to
this since these calls will require much higher transmit powers when compared to voice
transmissions (proportional to the ratio of the high-speed data rate to the data rate for voice).


151
5.1.1.2.3 Neighbor List Problems
On the reverse link, SCH bursts are rejected altogether if there exists a strong Candidate sector
that is not allowed to enter into the Active Set. One way in which this can happen is if these
Candidate sectors are missing from the neighbor lists of all currently active pilots in the Active
Set.
On the forward link, strong Candidate sectors that are not added to the Active Set will result in
poor pilot dominance, which, as explained in Section 5.1.1.2.1 above, will result in poor rate
assignments.
Handoff Matrix (HOMAX) and the Undeclared Neighbor List (UNL26) features have been very
problem.
drive tests for Greenfield (new) deployments, since switch-based neighbor list management tools
Note that there must be discipline exercised when adding neighbors, since sectors
with excessively large neighbor lists could perform poorly due to the increased
processing requirements. Additionally, given the fact that neighbor lists of sectors in
soft-handoff are concatenated, large neighbor lists increases the chances that some
neighbors will be dropped in this concatenated list.
26

152
eliminate the need for the neighbor list entry [19]. This would entail removing that
sector from the area through antenna downtilts, azimuth changes, antenna model
changes and/or BCR/CBR attenuation changes.
Reciprocity
Reciprocity refers to making sure that if sector A is added to sector B’s neighbor list, then
sector B is also in sector A’s neighbor list. With CDMA networks, there is rarely any
justification for not satisfying reciprocity rules when populating neighbor lists because all
sectors are transmitting on the same frequency.
PN Ambiguity Issues
PN ambiguities may come in many forms. No two neighbors on the same neighbor list can
have the same PN assignment because this will confuse the network should this PN be
reported as a Candidate pilot. A less obvious problem will be when two neighbors share the
same PN as a result of neighbor list concatenation. This is commonly referred to as two-
way PN ambiguity problems (for any combination of two neighbor lists) up to n-way
neighbor list problems (n up to 6). Typically, only two-way PN ambiguity checks are
performed.
5.1.1.2.4 Candidate Sector Resource Blocking
On the reverse link, SCH bursts are rejected altogether if there exists a strong Candidate sector
that is not allowed to enter into the Active Set. One way in which this can happen is if these
Candidate sectors are missing from the neighbor lists of all currently active pilots in the Active
Set, as discussed in Section 5.1.1.2.3 above.
Another way in which this can occur is if the Candidate sector is experiencing resource blocking
on all carriers, resulting in the Candidate sector being rejecting from participating in the call since
that sector will not have any resources to support the traffic channel.
On the forward link, strong Candidate sectors will result in poor pilot dominance, which, as
explained in Section 5.1.1.2.1 above, will result in poor rate assignments.
The affected cell site should be generating resource-blocking counts in service measurements.

153
The solution to this problem is to solve the cell resource-blocking problem. Cell resource
blocking can come either in the form of hardware resource blocking or power resource blocking.
5.1.2 Blocking / Rate Reduction Due to Packet Pipes
Packet Pipes (PPs) refer to the backhaul from the cell sites to the core network (MSC). Usually,
these PPs are in the form of DS0 channels in a T1 or E1 line. Each DS0 channel has a bandwidth
of either 64 kbps or 56 kbps.
The SCH rate could be reduced or blocked due to lack of packet pipe bandwidth at the cell to
backhaul the data back to the MSC. The task of packet pipe provisioning is complicated by the
fact that every service class of calls requires a different amount of packet pipe bandwidth to
support it. Examples of service classes include 2G EVRC Voice, 2G 13k Voice, 3G EVRC
Voice, 3G 13k Voice, 2G Circuit Data, 3G Packet Data, etc.
Therefore, packet pipes need to be provisioned based on some expected distribution of these
service classes, and blocking may occur if the cell ends up supporting more high-bandwidth
services than originally anticipated.
There are two important variables in PP provisioning that must first be understood before being
able to allocate the appropriate bandwidth. They are the Packet Pipe Capacity Unit (PPCU) and
the Packet Pipe Loading Coefficient (PPLC).
One PPCU is defined as the PP capacity required to service one 2G Rate Set 1 (8 kbps or EVRC)
call. In other words, if 1 DS0 were to have a capacity of 3 PPCU, this is the same as saying that
single DS0 will be able to support 3 2G Rate Set 1 calls.
The PPLC defines the number of PPCUs required to support a single call of any other service
class.
As an example, a 2G Rate Set 2 (13 kbps) voice call has PPLC = 1.35 for a cell site provisioned
with 8 DS0s, and that 8 DS0s have a joint capacity of 42 PPCU (see Table 5.1 below). This
means that this cell can either support a total of 42 Rate Set 1 calls or 31 Rate Set 2 calls
(42/1.35=31), or some combination in between that adds up to no more that 42 PPCU.
To illustrate the last point, say there are 30 Rate Set 1 calls and 8 Rate Set 2 calls requesting
service at that site. The 30 Rate Set 1 calls will require a capacity of 30 PPCU. The 8 Rate Set 2
calls will require a capacity of (1.35  8 = 10.8) PPCU. This gives a total of 40.8 PPCU, which
will be supported by the 8 DS0s above. The 9th Rate Set 2 call requesting service will require an
additional 1.35 PPCU, which will bring the total PPCU requirement to (40.8+1.35=42.15) PPCU.

154
This is greater than the 42 PPCU limit of the cell, and therefore the cell will deny access to this
9th Rate Set 2 call. There will be efficiencies gained when supporting multiple calls. Therefore,
the PPLCs for the various service classes are a function of the total DS0s being provisioned at the
cell.
5.1.2.1.2 Important Lucent Features
There are a couple of Lucent FAF features that will enable better utilization of the packet pipes.
In other words, these FAF features increase the PPCU capacity per DS0. The two features are:
1) Packet Pipe Optimization (PPOPT) [13].
2) Backhaul Engineering Enhancement [14].
Once the FAF features are loaded, these two features must be activated at a cell level on the cell2
form. There is every advantage, and no disadvantage, to turning on these features, so this must be
done on every cell site. Note that these FAF features also affect the PPLC values.
Another feature that should be activated on every cell is the PP16 feature. This feature allows for
finer granularity in DS0 assignments to cell sites, and also increases the total number of DS0s that
can be allocated to a CCC or CDM.
All of these features in combination will reduce the total number of T1s required for the
backhaul, which is usually of critical importance to the customers because these backhaul costs
are recurring costs that constitute a significant portion of the network maintenance expenses.
5.1.2.1.3 Packet Pipe Provisioning Strategies
The first step in determining the PP bandwidth to allocate to a cell is to first understand the
capacity offered for the various service classes based on the number of DS0s provided. As
discussed in Section 5.1.2.1.1 above, this may be computed by knowing the PPLC values for each
of the service classes, coupled with the PPCU capacity of the PPs. As discussed, this PPCU
capacity is a function of the activated FAF features discussed in Section 5.1.2.1.2.
Table 5.1 below presents an example of the capacity for the various service classes given that the
PP16, PPOPT and Backhaul Engineering Enhancement features are activated.

155
Table 5.1 NUMBER OF CALLS PER SERVICE CLASS FOR VARIOUS PACKET
PIPE BANDWIDTHS
Number Calls Supported for each Service Class per Number 64 kbps DS0s with PPOPT & 3G1X Backhaul Enhancement
Num DS0 Max PPCU 2G RS1-8k V 2G RS2-13k V 2G RS1-8k D 2G RS2-13k D 3G RS1-8k V 3G FCH Data 3G SCH Data
1 3 3 2 3 1 3 2 5
2 8 8 5 6 4 7 5 10
3 14 14 10 11 7 12 9 15
4 19 19 14 13 9 17 13 19
5 25 25 18 17 12 23 17 25
6 31 31 22 22 16 28 21 31
7 37 37 27 26 19 34 26 37
8 42 42 31 30 21 38 29 42
9 48 48 35 34 24 44 33 48
10 54 54 40 38 27 50 38 54
11 60 60 44 43 31 55 42 60
12 66 66 48 47 34 61 46 66
13 72 72 53 51 37 66 50 72
14 78 78 57 56 40 72 54 78
15 84 84 62 60 43 77 59 84
16 90 90 66 64 46 83 63 90
Note that this table only provides the maximum capacity of the DS0s for each service class if
traffic from no other service class is present. For example, 10 DS0s will provide enough capacity
for either 54 2G Rate Set 1 calls or 40 Rate Set 2 calls. However, if there is a mix of Rate Set 1
and 2 calls, then the methodology and formulas described in Section 5.1.2.1.1 above need to be
used to compute the required PP bandwidth (see [1] for detailed examples on how to do this).
The actual number of DS0s to provision for a carrier of a cell site may be determined by first
computing the expected distribution and volume of traffic expected for each of the service classes
in the table, and then determining the appropriate number of DS0s to assign to that carrier in
accordance with the procedure described in Section 5.1.2.1.1. A detailed methodology is provided
in [1] on how to determine this traffic distribution and volume among the various service classes.
5.1.2.2 PP Blocking / Rate Reduction Causes and Associated Fixes
5.1.2.2.1 Blocking / Rate Reduction due to Insufficient PP Provisioning
A cell site will reject SCH assignments if it is out of Packet Pipe bandwidth to support the
backhaul of traffic for these data calls.
 Service measurement peg counts indicate presence of PP blocking/rate reduction

on SCH (only available with Release 19 and beyond).
 ROP indicates no hardware outages during hours of blocking / rate reduction.
An important caveat to this approach is that hardware outages are only logged in the
ROP the moment they occur. Therefore, it is possible that hardware elements may be
out of service but still not register on the ROP during the hours of resource blocking
because these outages actually occurred earlier.

156
 For Release 24, use the new per-packet pipe counts to determine PP utilization
due to different traffic type. These new counts, in the CDMA-PP section, and may
be used to determine average and peak PP utilization due to voice and data calls in
the forward and reverse direction.
Once it is determined that the problem is truly due to an authentic shortage of equipped resources,
packet pipes may be added to resolve the problem. Care should be taken to add these resources
equally on all carriers, and to document the additions for proper cell resource management.
An alternate solution would be to offload traffic from the blocking sector as per the suggestions in
Section 4.1.4.1.5 on CE/PP Resource Blocking Management Techniques.
Note that some service providers may desire to maintain some marginal level of cell resource
blocking so that cell sites are not over-engineered to cater to peak traffic utilizations. The market
guidelines should be followed in requesting these cell resource additions.
Verify the use of the new Release 22 feature Fast Packet Data Call Setup; while this feature may
improve data call setup times, it may increase PP resource usage especially in markets with a
significant number of mobiles not authorized for data calls. While disabling the feature may
provide some relief it may still be necessary to add PP capacity.
5.1.2.2.2 Blocking / Rate Reduction due to Span Outage
A cell site will reject SCH assignments if it is out of Packet Pipe bandwidth to support the
backhaul of traffic for these data calls. This can occur when either the cell is authentically out of
packet pipe resources (Section 5.1.2.2.1 above), or if span outages at the cell render several
packet pipes out of service.
Hardware outages may be viewed on the ECP Control & Display page (commonly referred to as
the ‘cartoon’ page) and may also be captured in the ROP as HEH messages. Due to the magnitude
of ROP file sizes, they are best analyzed using filtering scripts. Many such scripts exist, an
example being the SPAT tool that has a component to perform such analysis (Appendix B
provides an overview of this tool).
of the problem.

157
5.1.3 Blocking / Rate Reduction Due to Channel Fragments
The SCH rate could be reduced or blocked because of insufficient SCH Channel Fragments
available to support the requested rate. With 3G, new channel cards are introduced that have
logical channel elements called channel fragments (CFs). One block of CFs is allocated to the
SCH alone, and may not be used by calls requiring FCH CFs, and vice versa.
CF provisioning requires the correct allocation of FCH and SCH CFs to each carrier to support
the anticipated traffic for both types of channels. Note that even if the CFs are installed at the cell,
they can only be used to support actual traffic if they also have the necessary packet pipe
bandwidth required to support the service class of the call that they are servicing. Therefore, the
process of CF provisioning is intimately tied to the process of Packet Pipe provisioning discussed
above.
5.1.3.1.1 Overview of 3G Channel Cards
With the advent of 3G, new channel cards have been introduced to handle the variety of service
classes that can be supported on Lucent systems. These new channel cards for 3G1X comes in
two forms:
 ECU-32 cards – for Series II cells.

 CCU-32 cards – for Flexent cells (and their variants, such as CCU-32A, CCUII,
CMUIII, etc).
As mentioned above, these cards no longer carry physical channel elements, but rather are
comprised of logical channel elements called Channel Fragments (CFs). Each ECU/CCU-32
supports the following CFs:
- 32 Forward FCH CFs (Supports F-FCH, Paging, Quick Paging and Pilot channels).
- 3227 Forward SCH CFs (Supports F-SCH and Sync channels).
- 32 Reverse FCH/SCH CFs (Supports R-FCH, R-SCH and Access channels).

Each of the FCH CFs can support any one of the following service classes:
- Forward / Reverse 13 kbps voice
- Forward / Reverse EVRC (8 kbps) voice
- Forward / Reverse 3G Packet Data at 9.6 kbps
27
Typical maximum supported SCH CFs is 32 with Release 18. Larger number of FCH and SCH CFs will be
supported with the CCU-64 cards that will be available with Release 19 and beyond.

158
For RC3 each Forward SCH (F-SCH) CF supports forward supplemental channel data at 9.6 kbps
(16 CFs needed to support 16X rate of 153.6 kbps). Each Reverse SCH (R-SCH) supports reverse
supplemental data at 19.2 kbps (8 CFs required to support 16X rate of 153.6 kbps).
Any single carrier may have a mix of 2G and 3G1X cards installed. The only restriction is that,
for Series II cells, a single CCC may not contain a mix of these cards, but different CCCs on the
same carrier may carry any combination of 2G and 3G1X cards. A carrier with only 2G cards
installed is commonly referred to as a 2G carrier, and likewise for 3G carriers that are only
installed with 3G cards. Any carrier with a mix of 2G and 3G1X cards installed is commonly
referred to as a 2G/3G1X mixed carrier.
A minimum of 5 overhead CFs are reserved per sector per carrier (15 in total for a 3-sectored cell
per carrier) – 4 forward overhead CFs for pilot, sync, paging and quick paging, 1 reverse
overhead CF for access. This is in contrast to only 2 overhead channel elements reserved for
overheads in 2G systems – 1 for pilot, sync and access, 1 for paging. For 2G/3G1X mixed
carriers, all overhead channels are assigned to the 3G1X CFs.
5.1.3.1.2 CF Provisioning Strategies
The introduction of 3G services adds several complexities to the process of CF provisioning at

cell sites. In particular, the following factors should be considered in the decision process:
 The distribution of 2G versus 3G channel cards at a cell site should match the
expected traffic distribution of the respective services.
 The channel cards should be allocated between carriers in accordance to the chosen
strategy for the market – either all carriers are configured as 2G/3G1X mixed
carriers, or selected carriers are chosen for 2G versus 3G.
 Care should be taken to ensure sufficient SCH CFs are installed to support the
expected high-speed data traffic. While voice services of any rate (8k/13k etc.) will
only take a single forward and reverse FCH CF, high-speed data services would take
multiple SCH CFs per call. Also, for the reverse link, 32 CFs are shared between
both FCH and SCH. Therefore, this should be carefully accounted for when
provisioning the CFs.
With the early stages of 3G deployments, it is not anticipated that there will be significant 3G
traffic due to the low penetration of 3G mobiles as compared to 2G mobiles. Therefore, it is
recommended that only minimal 3G channel cards are deployed on most cells, and that all
carriers should be configured as mixed carriers. This is because it is unlikely that there will be
sufficient 3G traffic to justify a dedicated carrier for 3G.
As 3G penetration increases, there will come a time when it will be justified to configure entire
carriers as 3G-only to maximize the carried capacity based on 3G enhancements, as well as to
provide maximum capacity to support high-speed data calls.
When selected carriers are configured as 3G-only, and others as 2G-only or 2G/3G1X mixed
carriers, it will become important to ensure that all 3G calls are placed on 3G cards, if possible,
and similarly, all 2G calls on 2G cards. This is to ensure that the potential 3G capacity
improvements are not wasted because 2G calls are placed on these 3G cards, resulting in those
calls operating in 2G mode.

159
There are two important concepts related to ensuring that the above appropriate allocation of calls
by technology is performed, namely, the Allow Sharing 3G1X Carrier and 2G/3G Load
Preference Deltas features. These concepts are discussed in the next section below.
5.1.3.1.3 Assigning Calls to Appropriate Channel Cards by Technology
As discussed in the previous section, there are two important concepts that work hand-in-hand to
ensure that incoming 2G and 3G calls are assigned to their respective channel cards respectively
to ensure that the 3G cards are used to their full potential. These two features are the Allow
Sharing 3G1X Carrier and 2G/3G Load Preference Deltas features.
3G mobiles will only hash onto 3G carriers and 2G/3G1X mixed carriers28 (see Section 5.1.3.1
for descriptions on how these carriers are defined). Similarly, 2G mobiles will only hash onto 2G
and 2G/3G1X carriers. However, if the Allow Sharing 3G1X Carrier is enabled on a 3G carrier,
then 2G mobiles are also allowed to hash onto the 3G carrier.
The reason for having this translation is to allow the flexibility to both segregate 2G and 3G calls
entirely onto their own carriers, or to allow at least the 2G mobiles to hash across all carriers,
regardless of technology. The latter is the preferred approach with early 3G deployments, since it
is unlikely that there will be enough 3G traffic dedicating an entire carrier to 3G calls, even if this
carrier is populated completely with 3G cards.
In such a scenario, if the Allow Sharing 3G1X Carrier (share_3g1x in the ceqface3g form) is not
enabled, then 2G mobiles will never hash onto these 3G carriers, but will likely have many
assignments to these carriers if rf load balancing is turned on (since there will be typically lower
traffic on these carriers due to lack of 3G traffic). Therefore, there will be an undue number of
cross-carrier assignments, greatly increasing the risk of cross-carrier TCCFs.
The 2G Load Preference Delta (ld_prf_dlta_2g in the ceqface3g form) and 3G Load Preference
Delta (ld_prf_dlta_3g1x in the ceqface3g form) translations serve to bias the RF Loading Weight
Factor (tca_weight in the ecp/ceqface form) in such a way that it favors the 2G calls to get
assigned to 2G carriers, and 3G calls to 3G carriers. If a 3G call hashes onto a 2G carrier, then the
loading on all other 3G carriers on that sector are lowered by the 3G Load Preference Delta in
order to make them more attractive for assignment to this 3G call. If that 3G call hashes onto a
3G carrier, then this 3G Load Preference Delta gets applied to itself, making it more attractive for
the 3G call to stay on that same 3G carrier. The same logic applies to the 2G Load Preference
Deltas.
This concept is best explained with an example. Say that a cell is configured with two carriers,
the first (F1) being a 2G/3G1X mixed carrier with current RF loading at 50%, and the second
(F2) being a 3G-only carrier with current RF loading at 25%. Also assume that the RF Loading
Weight Factor is set to 20%, 2G Load Preference Delta is set to 30%, 3G Load Preference Delta
is set to 40% and Allow Sharing 3G1X Carrier is set to y on all carriers.
Based on this configuration, the following scenarios describe various examples of how these
translations get applied to determine the assigned carrier.
28
The exception to this rule is if all of the carriers in the cell site are 2G carriers. In this case, 3G mobiles will hash
onto one of these 2G carriers.

160
In this case, for the purposes of the carrier assignment algorithm, F1 Loading = 50-20-30 = 0
(20% RF Loading Weight Factor since this is the originating carrier, and 30% 2G Load
Preference Delta since this carrier has 2G) and F2 Loading = 25 (2G Load Preference Delta will
not get applied for this carrier since it is 3G-only). Therefore, the call will be assigned to F1, even
though it is carrying significantly more traffic.
In this case, F1 Loading = 50-30 = 20 and F2 Loading = 25-20 = 5. Therefore, the call will be
assigned to F2. Here, the 2G delta is not large enough to overcome the load factor and the fact
that F2 is carrying much less traffic.
In this case, F1 Loading = 50-20-40 = -10 and F2 Loading = 25-40=-15. Therefore, the call will
be assigned to F2. Note that the 3G deltas cancel out since both carriers support 3G, leaving only
the load factor to decide the outcome.
5.1.3.2 CF Blocking / Rate Reduction Failure Causes and Fixes
5.1.3.2.1 Blocking / Rate Reduction because no FCH available
There are two possible scenarios under which such a failure can happen:
1) There are no FCHs available when all assigned calls on them are 3G calls.
2) There are no FCHs available, but some of the existing calls on these 3G FCHs are
actually 2G calls.
Both of these scenarios will be discussed below.
For both cases, the cell site will peg CF/PP blocking, without corresponding PP blocking counts
(meaning that the blocking on the FCH was due to lack of Channel Fragments).
However, there are no direct peg counts available or planned that will be able to isolate clearly
which of the two scenarios is actually happening. There are peg counts that will count
occurrences of technology cross-assignments, that is, 2G calls assigned to 3G cards and vice
versa. There are also peg counts available that capture the peak CF usage. In some cases, these
two sets of peg counts may be correlated to arrive at which of the above scenarios is actually
occurring.

161
If the 3G data calls are being blocked because 2G calls are being assigned on 3G cards, then the
load preference deltas (as discussed in Section 5.1.3.1.1 above) must be revisited and modified to
ensure that the 3G cards are reserved for 3G calls.
If all calls on the 3G cards are 3G calls, then more 3G cards need to be added to the cell, with the
appropriate additions to the Packet Pipe bandwidth (Section 5.1.2.1).
Consider using the “Voice vs. Data Call Admission” feature. This option would require turning
on this feature and determining optimal translation parameter settings to help manage voice vs.
data traffic. This feature can help manage low data rate issues due to lack of FCH resources for
data traffic (however care must be taken to balance voice and data performance needs). See
Section 4.1.2.1.3 and [36] for more information.
improve data call setup times, it may increase CF resource usage especially in markets with a
provide some relief it may still be necessary to add CF capacity.
For Release 26, a new feature called “3G CE Reservation for 3G Packet Data Call Setup” may be
used to reserve 3G CF resources specifically for 3G packet data calls (calls with Service Option
33). This feature ensures that 3G CFs are not used for voice calls even if all other channel
element resources are already utilized. The “3G CE Reservation for 3G Packet Data Call Setup”
feature is turned on by using the 3G CE Reservation for Packet Data Call Setup parameter in the
cell2 form, and by setting the 3G CE PDCS Num, also in the cell2 form, to the desired value. The
3G CE PDCS Num parameter controls the number of CE resources reserved for 3G packet data
calls on a per cell-carrier level. This feature modifies the CDMA-CS 9 and CDMA-CS 68 peg
counts to take into account overflowing originating or terminating calls when 3G CE resources
are reserved for 3G packet data calls. See [23] for more information.
Additionally, this feature requires that ModCells 1.0, 2.0 and 3.0 deployed with CRCs be
upgraded to URCms and the feature does not support mixed frame ModCells. See the Release 26
release letter and [26] for more information. Also consult the Release 26 release letter as the “3G
CE Reservation for 3G Packet Data Call Setup” feature interacts with, and depends on, other
feature for proper functioning. For example, the “3G CE Reservation for 3G Packet Data Call
Setup” feature cannot be activated if the “Voice vs. Packet Data Call Admission” or the “3G-1X
Call Admission Policy with System Resources Reservation Based on RF Power” are also turned
on.
5.1.3.2.2 Blocking / Rate Reduction because no SCH available
Data rates will be reduced, or blocked entirely, if no SCHs are available to handle the requested
data rates.

162
The occurrences of this failure type may be directly pegged with Release 19 peg counts. Until
then, there will be no effective way to capture these events.
The fix would be to either add SCH channel fragments to the cell site, or offload traffic to
neighboring sectors to reduce the consumed channel fragments, if possible. Note that SCH
channel fragments cannot be added independently, and must instead be added through adding
ECU/CCU-32 cards.
Also, for Release 26, consider using the “3G CE Reservation for 3G Packet Data Call Setup”
feature as explained in 5.1.3.2.1.
5.1.4 Blocking / Rate Reduction Due to Walsh Codes
The SCH rate could be reduced or blocked if there are insufficient Walsh Codes at the sector to
allocate to the call. While Walsh Code shortage was rarely an issue in the past with purely voice
services, it may be of significant concern as the volume of data calls increases on each sector or if
more overhead channels are introduced, for example a second paging channel is added to a
carrier.
This is because higher data rates will require Walsh Codes of shorter lengths, which will
automatically discount several other Walsh Codes of larger lengths that are associated with those
shorter length Walsh Codes. This concept is described in more detail below.
5.1.4.1.1 Overview of Variable Walsh Spreading Factors
In CDMA systems, a set of orthogonal Walsh Codes is used to channelize the forward link traffic
channels. Walsh Codes are represented by their length (number of bits comprising the code) and
their function (which refers to a specific code or row among the various possible codes). The
nomenclature used is Wnl. For example, W3264 refers to the 32nd function (that is, the 32nd code or
row) of the set of 64-length Walsh codes.
The IS95 (2G) standard employed Walsh Codes of length 64, with pre-defined functions used for
overhead channels. For example, the Pilot channel is always allocated W064, the first Paging
Channel is always allocated W164, the second Paging Channel is always allocated W264 and so on
up to Paging Channel 7, and the Sync channel is always allocated W3264.
With 3G, the concept of Variable Walsh Spreading Factors (VWSF) is introduced to support
high-speed data transmissions. The reason for introducing this may be understood by examining
the following relationship:
Chip Rate = Baseband Symbol Rate  Walsh Code Length

163
Therefore, given that the chip rate is maintained at 1.2288 Mchips/sec for all baseband rates, the
Walsh Code lengths must therefore be modified in inverse proportion to these baseband data
rates.
For 3G an additional overhead channel became available called the Quick Paging Channel. When
provisioned, the Quick Paging Channel is allocated W80128 (which blocks the use of W1664 for
fundamental channel traffic since these two Walsh codes are not orthogonal).
Additionally, with 3G, a new radio configuration called Radio Configuration 4 (RC4) is available
which increases the length of available Walsh Codes to 128 for traffic channels. For RC4, the
W48128, W80128, and W112128 Walsh codes are not available for traffic since they are reserved for the
First, Second, and Third Quick Paging Channels respectively.
5.1.4.1.2 Concept of Walsh Code Blocking
Walsh Code blocking occurs when the sector runs out of Walsh Codes to assign to a mobile for a
forward link data transfer or voice call.
With 2G systems, this simply meant that there are no more functions (or codes) available for
traffic from the 64-length Walsh Codes. This was a fairly unlikely scenario in 2G networks
because the RF link usually will run out of capacity before this Walsh Code limitation29 is
reached. Therefore, this category of blocking was largely overlooked in 2G networks.
With 3G networks however, the assignment of variable length Walsh Codes significantly
increases the chances that the sector will run out of Walsh Codes if there are even a few high-
speed data calls in session. Additionally, having the capability of having multiple paging channels
in a carrier means there are fewer Walsh Codes for both voice and high-speed data calls.
The following figure illustrates the concept of this blocking when RC3 is used.
29
The maximum number of Walsh codes in 2G networks is 55 = 64 - 7 (reserved for paging) – 1 (reserved for sync) – 1
(reserved for pilot).

164
64 1x 32 2x 16 4x 8 8x 4 16x
Walsh Walsh Walsh Walsh Walsh
Codes Codes Codes Codes Codes
16x SCH
8x SCH
A B C
4x SCH
D
Pilot Sync QPCH paging

channel
FIGURE A-5 RC3 WALSH CODE TREE
Whenever a FCH is assigned to a voice or data call, all higher rate Walsh codes belonging to that
subtree are blocked from further use. For example, the paging channel Walsh code blocks the
16X SCH Walsh code in subtree C from being used. Similarly, the pilot, sync, and QPCH Walsh
codes block the 16X SCH Walsh code in subtree A from being used. Therefore, a maximum of
two 16X Walsh codes are available at any one time, limiting the maximum number of users that
can download at 153.6 kbps to two. Additionally, when a second paging channel is provisioned,
the 16X SCH Walsh code in subtree B is unavailable, limiting the maximum number of users that
can download at 153.6 kbps to one.
The filled circles indicate used Walsh codes and the empty ones indicate unused (but not
necessarily free) Walsh codes. When a SCH is set up with 16X Walsh code D, all 8X, 4X, 2X,
and 1X Walsh codes in that subtree become unavailable. Similarly, when a SCH is set up with 8X
Walsh code in the subtree corresponding to C, all 4X, 2X, and 1X Walsh codes in that subtree
become unavailable.

165
5.1.4.1.3 Walsh Code Optimization Techniques
The allocation of Walsh Codes are inherently performed by call processing within the Lucent
cells, and may be manipulated through new features and translations discussed in 5.1.4.2. The
basic strategy is to leave all branches related to particular root codes exclusively for FCH (voice
and low-speed data), and only open up selected root codes for high-speed data. This ensures that
there is a minimum capacity allocated to voice calls, which are still expected to form a significant
portion of the total traffic in these early stages of a 3G rollout.
The Walsh functions are also assigned in a manner that minimizes the number of additional
functions blocked. If there are no smaller-length codes available for a high-speed data call on the
SCH, then the rate will be stepped down and a higher-length code will be assigned to the call.
5.1.4.2 Walsh Code Blocking / Rate Reduction Failure Causes and

Fixes
5.1.4.2.1 Unavailable Walsh Codes due to Excessive High-Speed Connections
This type of blocking will occur if too many lower length Walsh codes are used for high-speed
data calls, discounting all related higher length codes for other lower-speed calls (see Section
5.1.4.1.2).
Peg counts indicating SCH rate reduction and blocking due to Walsh Codes are available. These
peg counts, along with other Walsh Code utilization metrics may be used to determine Walsh
code usage. The distribution of rate assignments may also be determined through the 3G F-SCH
rate selected counts which peg the number of times a burst of a specific rate is selected, see
Appendix A for more information.
Prior to release ECP/Cell Release 19 there was little control over how cell sites assign Walsh
Codes to calls. However if such blocking is occurring, then one possibility was to offload traffic
to neighboring sectors, if possible. Other traffic offloading techniques discusses in Section
4.1.5.1.3 were also applied. For ECP/Cell Release 19 the Preferred 8K Forward RC translation,
in the ceqface3g form, can be used to control Radio Configuration (RC) assignment, and thus the
possibility of using a larger Walsh Code pool. Radio Configuration 4 (RC4) has 128 Walsh
Codes, while RC3 has 64, thus using RC4 reduces rate reduction or blocking due to Walsh Code
shortages. However RC4 uses weaker FEC coding, which may slightly degrade RF performance.
With Release 20, a new feature called 3G-1X CDMA with Improved RC3/RC4 Walsh Code
Assignment Algorithm gives greater control on how calls get assigned Walsh Codes. This feature
assigns a radio configuration dynamically based on forward power utilization and Walsh Code
utilization.

166
This feature is enabled using the Improved RC3/RC4 Assignment Algorithm Enabled translation
in the ecp3g form. The RC4 Enabled Threshold (%) and RC4 Determination Threshold
translations in the ceqface3g form are used to control when calls get assigned. See [11] for more
information. The effectiveness of this feature also depends on the number of RC4-capable
mobiles in a market.
Alternatively, translations may be set to limit the maximum rate assigned on these blocking
sectors to ensure that too many lower length codes are not assigned. Reference [5] discusses this
in more detail.
5.1.4.2.2 Unavailable Walsh Codes due to Excessive Low-Speed Connections
This type of blocking will occur if too many higher length Walsh codes are used for low-speed
data and/or voice calls, discounting all related lower length codes for other high-speed calls
(see Section 5.1.4.1.2).
Appendix A for more information.
utilization.
mobiles in a market.

167
Note that limiting the maximum assigned rate will not help in this case because the fundamental
problem is with too many lower rate assignments.
improve data call setup times, it may increase Walsh Code utilization especially in markets with a
provide some relief it may still be necessary to ease Walsh Code utilization through other
methods previously mentioned.
5.1.4.2.3 Unavailable Walsh Codes due to Multiple Paging Channels
This type of blocking will occur if too many higher length Walsh codes are unavailable due to the
provisioning of multiple paging channels.
Appendix A for more information. Additionally the provisioning of multiple paging channels
may be verified by looking at translation parameter data using tools like SPAT (see Appendix B).
The provisioning of multiple paging channels is usually done for sectors showing very high
paging channel occupancy, where the relief provided by the additional paging channels is
required. In these cases it must be first determined whether the additional paging capacity is
absolutely needed, if it is, consider the suggested fixes detailed in the next paragraph. Otherwise,
consider de-provisioning the additional paging channels (a small reduction of paging channel
occupancy may be achieved by using the Auxiliary Sector Control 1 on the ceqface form, for
more information on setting the Auxiliary Sector Controls, see section 4.1.9.1.2 and the
appropriate Cell Software Release letter). For Release 26, the new “Customer-Critical
Translations Maintenance - Phase 2” feature replaced the use of Auxiliary Sector Control 1 for
improvement of Paging Channel occupancy with the new Control for Paging Channel Occupancy
Improvement parameter in the cell2 form. See the Release 26 release letter for more information.
For Release 24, new per-carrier Paging Channel Occupancy peg counts became available. These
counts may be used to determine which carriers absolutely require additional paging channels.
The new peg counts break down paging channel usage (by traffic type, for example, Overhead
Messages, Feature Notification Messages, SMS, and others), thus helping trouble shoot high
paging channel occupancy issues. See [23] for more information. Additionally, for Release 25,
the Adaptive Paging feature may be used to reduce paging channel occupancy. See Section
4.1.9.1.2 for more information on strategies for reducing paging channel occupancy and [41] for
more information on the Adaptive Paging feature.

168
utilization.
mobiles in a market. This feature assigns the same radio configuration to the supplemental
channel that is used for the fundamental channel.
In future releases, a new feature called “RC3/RC4 Improved Management for Supplemental
Channels” will allow separate assignment of radio configuration for the fundamental and
supplemental channels. This feature was introduced in R22.01, however its use is not
recommended due to mobile problems resulting from improper translation parameter settings.
Note that limiting the maximum assigned rate will not help in this case because the fundamental
problem is with paging channels taking too many of the higher rate Walsh Codes.
Also, verify the use of the new Release 22 feature Fast Packet Data Call Setup, while this feature
may improve data call setup times, it may increase Walsh Code utilization especially in markets
with a significant number of mobiles not authorized for data calls. While disabling the feature
may provide some relief it may still be necessary to ease Walsh Code utilization through other
methods previously mentioned.
For multiple-carrier systems, another solution, instead of changing radio configuration, is to bias
high speed data calls from the carriers with multiple paging channels to other carriers with one
paging channel by using the 3G1X Data Load Preference Delta (d3g_ldpf_delta on the ceqface3g
form) parameter. This solution must be implemented with care since it may increase cross-carrier
TCCFs and overload the carrier where data calls are getting assigned.

169
5.2 Excessive Anchor Transfers
5.2.1 Concepts and Optimization Techniques
5.2.1.1 Conceptual Overview
Any instance when the SCH is inactive even while there is backlogged data to send may be
construed as a throughput hit. Such a condition will arise during Anchor Transfers, whereby the
data call is transferred from one Anchor sector to another.
Anchor Transfers is exclusively a forward-link concept30. Only a single sector carries the
Supplemental Channel (SCH) on the forward link, even in areas of soft-handoff. This sector is
designated as the Anchor Sector.
As RF conditions vary and another pilot assumes dominance, the Anchor designation is
transferred to this stronger pilot when certain hysteresis threshold criteria are met. When this
event occurs, the prior Anchor Sector tears down its SCH, and subsequently the new Anchor
Sector establishes a new SCH with the mobile and resumes the high-speed transfer. This process
is known as the Anchor Transfer process. The hysteresis threshold may be set in translations.
Of note in this procedure is the fact that there will be a brief period where the SCH is inactive
during this process, even in the presence of backlogged data that requires this high-speed transfer.
These periods of SCH outages will result in a modest hit to the throughput. The extent of the
effect of these Anchor Transfers is directly proportional to the number of Anchor Transfers that
occur.
5.2.1.2 Optimization Techniques
The primary cause of Anchor Transfers is due to shifting dominant pilots. Areas of rapidly
varying dominant pilots will be particularly prone to these transfers, possibly resulting in
noticeable throughput degradations. Given below are some optimization techniques.
 Minimize areas of varying dominant pilots. Typically, this problem is most severe
in soft-handoff zones. Therefore, minimizing excessive soft-handoff zones will
typically help reduce unnecessary Anchor Transfers. Areas of excessive soft-
handoffs may be determined using the following techniques.
30
The concept of Anchors does not exist on the reverse link because the R-SCH is combined by all soft-handoff legs of
the call.

170

problems.
 Isolate sectors exhibiting a large number of anchor transfers. Examining sectors
with a large number of anchor transfers can be done by looking at the number of
anchors transfers and assignments, see Appendix A for more information.
Additionally, for Release 27, new counts for measuring the number of Primary
transfers in cases of Soft, Softer, and Semisoft handoff are available. These counts
are in the CDMA-PAF-CARR-VO and CDMA-PAF-CARR-SC sections and thus are
available for voice and data calls, see [23] for more information. These new counts,
along with the number of anchor transfers may be used to isolate those sectors which
may have an excessive number of anchor transfers. Keep in mind that the anchor leg
is not necessarily the primary leg. However the number of primary transfers may
point to a problem that also affects the number of anchor transfers.
These excessive soft-handoff zones may be reduced through a combination of physical

optimization (changes in antenna orientation, downtilt, model etc.) and/or BCR/CBR
attenuation changes.
Manipulating t_add, t_drop and other handoff parameters will typically not help resolve
this particular type of problem because Anchor Transfers usually occur amongst the
strongest pilots seen in an area, while these handoff parameters affect the entry and
removal of the weaker pilots.
 Increase Anchor Hysteresis Threshold. While this may limit the number of Anchor
Transfers, it may also result in poorer performance because pilots that are not
dominant will carry the data call more often. Therefore, it is preferred to solve the
problem in its roots through RF optimization discussed above.
 Enable the 3G-1X HSPD Mobility Improvements Using The Forward
Supplemental Channel feature. While this may reduce the number of Anchor
Transfers in softer handoff areas, it may also result in rate reduction or blocking due
to increased downlink RF Power and Walsh Code usage. This feature would benefit
those sectors with a large softer handoff area that do not have downlink RF power or
Walsh Code usage constraints. This feature is enabled by using the HSPD Multiple
Leg Enabled parameter in the cell3g form, and is further controlled by other
thresholds in the same form. See [5] for more information. If this feature is enabled
the Rate Requested and Rate Selected counts, the Rate Reduction and Blocking
counts, as well as the Anchor Transfer and Anchor assigned counts are pegged
differently depending on whether the Anchor Leg is in simplex or softer handoff
mode. If the Anchor Leg is in simplex mode, the service measurement peg counts are
31

171
pegged at the simplex Anchor Leg; if the anchor leg is in softer handoff mode, the
counts are pegged at the initial Anchor Leg.
5.3 3G3G Inter-Frequency Handoffs
5.3.1 Concept / Reasons for Throughput Degradation

A 3G HSPD call may be instructed to perform an inter-frequency handoff to another 3G carrier
on the same and/or other sectors for a variety of reasons. When this happens, the SCH is torn
down, and would need to be reestablished on the new carrier. This period of SCH inactivity will
directly translate to a reduction in the achieved end-user throughput.
Given below is a list of possible reasons why such an inter-frequency handoff may be triggered:
 The call is on a border sector, and the triggers for an inter-frequency handoff have
been met.
 A strong candidate is unable to support 3G soft-handoff, but has 3G resources to
support the HSPD call on another carrier. The original carrier could have rejected the
3G soft handoff for any of the following reasons:
1) All of the 3G resources on that carrier were utilized, resulting in handoff
escalation to another carrier.
2) The original carrier was never provisioned with 3G resources to begin with.
5.3.2 Symptoms and Identification Techniques

Currently, there is no direct method to detect the occurrence of these handoffs because of
insufficient granularity with existing service measurement peg counts. However, these handoffs
may be inferred as occurring if any of the following conditions are met:
 A multi-carrier network is known to be configured with 3G3G borders and

these border sectors show inter-frequency (that is, semi-soft) handoff activity in
service measurements.
 Known 3G multi-carrier cell(s) are experiencing handoff overflow counts and/or
overload handoff blocking counts on one or more, but not all, carriers. This
implies that inter-frequency handoffs will be attempted to move the HSPD call to the
non-blocking carriers. This can be confirmed by the existence of inter-frequency (that
is, semi-soft) handoff activity, even if none of the sectors in these cells are border
sectors.
5.3.3 Suggested Fixes for Improvement

If these handoffs are occurring on authentically configured border sectors, then the problem may
be minimized or eliminated using the following techniques (where applicable):

172
1) Use the IFHOTI algorithm to trigger the inter-frequency handoffs (if not already). If
IFHOTI is already being used, then perform multi-carrier optimization to extend the
coverage of the border carrier, if possible (see [20] for detailed procedures on how to do
this). Note that the cdhnl forms must be well optimized to preserve the handdown success
rate. These concepts are discussed in detail in Section 4.2.2.1.2.
2) Convert the affected border sector to a full-traffic sector, if possible. Sometimes, the
border regions are configured conservatively, and can in fact be extended out with proper
optimization of the handdown triggers and neighbor lists. If this is not possible, then one
or more neighboring sectors need to be installed with the additional carrier and be
configured as border sectors to allow the affected sector to become full-traffic. This
solution is of course a much more expensive option, and will usually require justification
and time to implement.
3) Additionally, for Release 25, the new 3G CE Reservation for 3G Hand-offs feature may
be used to reserve 3G CEs for 3G data calls. This may alleviate the problem in the short
run, but it is recommended that the fundamental lack of 3G resources be resolved. The
effectiveness of this solution also depends on the percentage of 3G calls that are 3G data
calls. See Section 4.2.1.2.6 for more information on this feature.
If the inter-frequency handoffs are occurring on otherwise full-traffic sectors, and handoff
overflows are also detected on these cells, then this implies a cell resource-blocking problem. The
obvious solution to this problem would be to resolve this resource blocking at the affected cells.
5.4 3Gnon-3G Handoffs
5.4.1 Concept / Reasons for Throughput Degradation

All 3G to non-3G handoffs will result in the HSPD call being released altogether. Such handoffs
may occur under any one of the following circumstances:
 A 3G2G handoff is triggered. This may occur under any one of the following
conditions:
1) A strong 2G-only candidate sector forces the entire call to be transferred to 2G.
2) A strong candidate sector has 3G resources available, but is not enabled to

support HSPD calls (FID-3833 is not enabled at the cell).
3) A strong candidate sector is 3G HSPD capable, but all 3G resources on all

carriers are already being utilized.
4) An inter-frequency handdown is triggered on a 3G-border sector, and all of the

common carriers only support 2G.
In scenarios 1-3 above, the criteria used to trigger the 3G2G handoff will be as
explained in [9], namely:

173
 The combined pilot strength of the Active Set pilots is less than –10dB.
AND/OR
 The candidate pilot strength is stronger than the strongest Active Set pilot.
 A hard-handoff is triggered to another vendor / system through IS-41. The criteria
used to trigger such handoffs are also described in [9].
If the HSPD call goes to 2G and there is still data to transmit, then another data call may be set up
in 2G-mode if 2G-IP service is enabled and supported by the mobile, but will most likely achieve
lower throughputs because the SCH will not be available.
If the HSPD call goes to another vendor’s network, or to another system, then it will depend of
the technology supported with this new network. If 3G HSPD is supported, then another HSPD
call may then be set up at that point to continue the data session.
5.4.2 Symptoms and Identification Techniques

3G2G handoffs may be identified through service measurements. It is instructive to view these
handoffs as a percentage of the total number of established calls on each sector to get an
appreciation of the magnitude of the problem. This may be readily viewed using tools such as
SPAT (Appendix B).
There are no direct peg counts to capture the number of 3G HSPD calls that are released due to
hard handoffs. However, this may be inferred to be happening on 3G cells that are also reporting
hard handoff activity, though the magnitude of the problem cannot be determined. For Release 22
new peg counts have been added that give an idea of the number of hard handoff activity for 3G
data calls, see [23] for more information.
5.4.3 Suggested Fixes for Improvement

Since such throughput degradations due to hard handoffs are difficult to identify and characterize,
this section will focus on suggestions to reduce the 3G2G handoffs on sectors that require good
HSPD throughputs.
The following steps may be taken to optimize such handoffs:
 A translations scrub must be performed to ensure that the HSPD feature (FID-3833)
is enabled on all 3G cells, unless there is an explicit directive to disable this feature
on selected 3G cells.
 If the problem is that distant 2G sectors are overshooting into a 3G-designated area,
then the solution will be to limit the coverage of these 2G sectors through a
combination of physical (antenna azimuths, downtilts, models, etc.) and/or parameter
(BCR/CBR attenuation, etc.) optimization.
 If the 3G calls are being released to neighboring 2G sectors, as per design, then the
solution will be to extend the number of 3G-enabled cells in order to expand the 3G
footprint. Of course, such a measure will require time to implement, and will require
justification of the HSPD throughput requirements for the affected sectors.

174
 If it is found that 3G calls are being released to 2G on 2G/3G mixed cells, then this
implies that there were no 3G resources available to support the 3G HSPD call. This
could be because of two reasons, namely:
1) The load preference deltas and 3G1X sharing translations were not optimally
configured, resulting in 2G calls consuming 3G resources. This topic is dealt in
detail in Section 5.1.3.1.3, including identification techniques and suggestions for
fixes.
2) The 3G resources were consumed totally by 3G calls, but there was insufficient
such resources allocated to these 2G/3G mixed cells. The solution then would be
to increase the allocation of 3G resources to these cells.
3) Additionally, for Release 25, the new 3G CE Reservation for 3G Hand-offs

feature may be used to reserve 3G CEs for 3G voice and data calls (which may
help with the release of 3G data calls as they are handed over to 2G CEs). This
may alleviate and manage the problem in the short run, but it is recommended
that the fundamental lack of 3G resources be resolved. The effectiveness of this
solution also depends on the percentage of 3G calls that are 3G data calls. See
Section 4.2.1.2.6 for more information on this feature.
5.5 Outages and Errors in the Packet Network or other Cell Site
Hardware Components
The implementation of HSPD services in 3G networks requires several additional network
elements to complement the existing network infrastructure for voice services. Specifically, data
packets traversing to and from external internet or other packet data networks are required to be
routed through a Packet Data Serving Node (PDSN), which will then communicate to the 5E
DCS via the Packet Control Function (PCF) [17].
Any hardware outages, protocol errors or hung queues on any of these network elements will
result in the customers experiencing reduced throughputs, even under good RF conditions and
ample cell resource availability.
A detailed discussion on all the possible types of problems and their corresponding identification
and resolution techniques is beyond the scope of this guide. However, reference [18] offers an
excellent troubleshooting manual to identify and resolve end-to-end HSPD problems, with a
focus on fixed network element failures.
Another important source of information will be the Lucent Alerts that catalog all problems that
have been uncovered, and will also document the resolution steps, if available.
As an example, a prominent alert (02-264) was released in May, 2002 that described a software
deficiency in the PHV4’s that resulted in its high-speed data burst queues being improperly
exhausted. This will then restrict data calls to a maximum of 9.6 kbps over the FCH, and will not
allow the SCH to be set up for any of the calls. This Lucent Alert provides details on a BWM
load to be installed, and other related procedures to be executed, to fix the problem.
Other hardware components errors include miscellaneous problems with cell site hardware. For
example a recent problem with URCs may cause problems with F-SCH data rates. The URC

175
hardware problem caused it to send corrupted messages with good layer 2 (HDLC) checksums on
their packet pipes. Some of these messages would get routed to the site’s neighbors causing
cluster wide F-SCH throughput degradation. See Lucent Alert 05−0250 for more information.
The Lucent Alert explains steps to take to identify the URCs (and URCms) that may have this
problem and how to solve it.

176
APPENDIX A METRIC CROSS-REFERENCE
Table A-1 Established Call Rate Metric Cross Reference

KPI Level Metric Name Section
Established Call Rate Primary Analog Redirection Rate 4.1.4, 4.1.5
Established Call Failure Rate 4.1
Established Call Failure Rate [Peg] 4.1
Established Call Failure Rate for Origination 4.1
Established Call Failure Rate for Origination [Peg] 4.1
Established Call Failure Rate for Termination 4.1
Established Call Failure Rate for Termination [Peg] 4.1
Established Calls 4.1.2.5.1
Established Calls [Peg] 4.1.2.5.1
Miscellaneous Ineffective Attempts 4.1
Origination Miscellaneous Ineffective Attempts 4.1
Termination Miscellaneous Ineffective Attempts 4.1
No Page Response Rate 4.1.7, 4.1.9
Unconditional No Page Response Rate 4.1.7, 4.1.9
Reorder Rate 4.1.2.1.3
Service Connect Complete Failure Rate 4.1.1
Service Connect Complete Failure Rate for Origination 4.1.1
Service Connect Complete Failure Rate for Termination 4.1.1
Secondary 3G to 2G Origination Assigned due to CE Overflow Rate 4.1.4.2
3G to 2G Origination Assigned due to PP Overflow Rate 4.1.4.2
3G to 2G Origination Assigned due to RF Balancing Rate 5.1.1.2
3G to 2G Termination Assigned due to CE Overflow Rate 4.1.4.2
3G to 2G Termination Assigned due to PP Overflow Rate 4.1.4.2
3G to 2G Termination Assigned due to RF Balancing Rate 5.1.1.2
Average CDMA Access Channel Occupancy 4.1.9
Average CDMA Paging Channel Occupancy 4.1.9
Cross Carrier TCCF Failure Rate 4.1.2.5.2
Same Carrier TCCF Failure Rate 4.1.2.5.2
Number of Cross Carrier TCCFs 4.1.2.5.2
Carrier 1-18 Imbalance 4.1.2.5.2
Forward Power Control Overload Duration in sec. 4.1.5
Forward Power Control Overload Number of Times 4.1.5
Handoff Blocking Rate due to CE/PP Overflow 4.1.4, 4.2.1.2.6
Handoff Blocking Rate due to CE/PP Overflow_CARRIER 4.1.4, 4.2.1.2.6
Handoff Blocking Rate due to Power Control Overload Rate 4.1.5, 4.2.1.2.6
Handoff Blocking Rate due to Power Control Overload Rate_CARRIER 4.1.5, 4.2.1.2.6
Load Management Blocking Rate 4.1
Load Management Redirection Rate 4.1
One Strong Pilot Above T_ADD 4.1.2.1.4, 4.2.1.2.7, 5.2
One Strong Pilot Above T_COMP 4.1.2.1.4, 4.2.1.2.7, 5.2
Orig & Term Block Rate due to CE Overflow 4.1.4.2
Orig & Term Block Rate due to CE/PP Overflow 4.1.4.2
Orig & Term Block Rate due to CE/PP Overflow_CARRIER 4.1.4.2
Orig & Term Block Rate due to FWD/REV Power Overload 4.1.5.2
Orig & Term Block Rate due to PP Overflow 4.1.4.2
Origination Assignments 4.1.2.5.1
Origination Seizure to Assignment Deficit Rate 4.1.4, 4.1.5
Origination RF Failure Rate 4.1.2.5
Page Response Seizures 4.1.2.5.1
Peak CDMA Access Channel Occupancy 4.1.9
Peak CDMA Paging Channel Occupancy 4.1.9
Peak No. of Traffic CE's in use 4.1.4.1.5
Peak No. of Walsh codes in use 5.1.4
Peak Power on Forward Link [W] 4.1.5
Primary CE Usage Fraction 4.1.2.5.4, 4.1.2.5.1
Primary Erlangs 4.1.4, 4.1.5
Primary Traffic Code Channel Usage 4.1.4, 4.1.5
Reverse Power Control Overload Duration in sec. 4.1.6
Reverse Power Control Overload Number of Times 4.1.6
Secondary CE Usage Fraction 4.1.5.2
Secondary Traffic Code Channel Usage 4.1.4, 4.1.5
Silent Re Origination Rate 4.1.2.2
Speech handler Failure Rate 4.1.3.2.3
System Access Denial Rate 4.1
System Access Failure Rate 4.1
Termination Assignments 4.1.2.5.1
Termination Seizure to Assignment Deficit Rate 4.1.4, 4.1.5

177
Termination RF Failure Rate 4.1.2.5

Three Strong Pilots Above T_ADD 4.1.2.1.4, 4.2.1.2.7, 5.2
Three Strong Pilots Above T_COMP 4.1.2.1.4, 4.2.1.2.7, 5.2
Total Assignments 4.1.2.5.1
Total Seizure to Assignment Deficit Rate 4.1.4, 4.1.5
Total Erlangs 4.1.5
Total Seizures 4.1.2.5.1
Total Traffic Code Channel Usage 4.1.4, 4.1.5
Two Strong Pilots Above T_ADD 4.1.2.1.4, 4.2.1.2.7, 5.2
Two Strong Pilots Above T_COMP 4.1.2.1.4, 4.2.1.2.7, 5.2
Undeclared Neighbor HO Failure Rate 4.2.1.2.1, 4.1.2.5.3
Vocoder Blocking Rate 4.1
Voice Mail Redirection Rate 4.1.9
Table A-2 Drop Call Rate Metric Cross Reference

Drop Call Rate Primary Call Shutdown Rate 4.2.2.2
Call Shutdown Rate [Peg] 4.2.2.2
Drop Call Rate 4.2
Drop Call Rate [Peg] 4.2
Dropped Calls 4.2
Lost Call Rate 4.2.1.2
Lost Call Rate [Peg] 4.2.1.2
Secondary 3G Data Mobile Release Rate Due to 2G only Neighbor 5.3, 5.4
3G to 2G SemiSoft Handoff Attempts Rate 4.2.1.2.6
Hard Handoff Order Complete Failure Rate 4.2.2.2
Hard Handoff Request Complete Failure Rate 4.2.1.2.6, 4.1.4, 4.1.5, 4.2.2.2
Hard Handoff Request Order Failure Rate 4.2.1.2.6, 4.1.4, 4.1.5
Island [Total/Secondary CE Usage] 4.2.1.2.4
Release Confirmation Failure Rate 4.2.1.1
Release Confirmation Failure [TCSI Active] Rate 4.2.1.1
Soft Handoff Order Complete Failure Rate 4.2.2.2
Soft Handoff Request Complete Failure Rate 4.2.1.2.6, 4.1.4, 4.2.2.2, 4.1.5
Soft Handoff Request Order Failure Rate 4.2.1.2.6, 4.1.4, 4.1.5
Undeclared Neighbor HO Failure Rate 4.2.1.2.1, 4.1.2.5.3
One Strong Pilot Above T_ADD 4.2.1.2.7
One Strong Pilot Above T_COMP 4.2.1.2.7
Two Strong Pilots Above T_ADD 4.2.1.2.7
Two Strong Pilots Above T_COMP 4.2.1.2.7
Three Strong Pilots Above T_ADD 4.2.1.2.7
Three Strong Pilots Above T_COMP 4.2.1.2.7
Table A-3 Frame Error Rate Metric Cross Reference

Frame Error Rate Primary Aggregate Frame Error Rate on Forward Channel [FFER] 4.3.1.1
Aggregate Frame Error Rate on Reverse Channel [RFER] 4.3.1.2.4, 4.3.1.2.5
FFER PMRM 8k/EVRC 4.3.1.1
Full Rate Frame Error Rate on Forward Channel [FFER] 4.3.1.1
2G Forward Frame Error Rate 4.3.1.1.3
3G Forward Frame Error Rate 4.3.1.1.3
2G Reverse Frame Error Rate 4.3.1.2.2
3G Reverse Frame Error Rate 4.3.1.2.2
Secondary 2G Forward Frame Error Rate [RC1] 4.3.1.1.3
2G Forward Frame Error Rate [RC2] 4.3.1.1.3
Forward Frame Error Rate [SMV] 4.3.1.1.3
Forward Frame Error Rate [EVRC] 4.3.1.1.3
Forward Frame Error Rate [EVRCB] 4.3.1.1.3
Forward Frame Error Rate [13K] 4.3.1.1.3
2G Reverse Frame Error Rate [RC1] 4.3.1.2.2
Reverse Frame Error Rate [SMV] 4.3.1.2.2

178
Reverse Frame Error Rate [EVRC] 4.3.1.2.2

Reverse Frame Error Rate [EVRCB] 4.3.1.2.2
Reverse Frame Error Rate [13K] 4.3.1.2.2
Average RSSI Rise Above the Noise Floor [dB] 4.1.2.5.7 4.1.6.2.4 4.2.1.2.9
Peak RSSI Rise Above the Noise Floor [dB] 4.1.2.5.7 4.1.6.2.4 4.2.1.2.9
One Strong Pilot Above T_ADD 4.3.1.1.5 4.2.1.2.7
One Strong Pilot Above T_COMP 4.3.1.1.5 4.2.1.2.7
Two Strong Pilots Above T_ADD 4.3.1.1.5 4.2.1.2.7
Two Strong Pilots Above T_COMP 4.3.1.1.5 4.2.1.2.7
Three Strong Pilots Above T_ADD 4.3.1.1.5 4.2.1.2.7
Three Strong Pilots Above T_COMP 4.3.1.1.5 4.2.1.2.7
Table A-4 Packet Data Rate Metric Cross Reference

Packet Data Primary 3G Forward Data Burst Rate 5.1
3G Forward Supplemental Channel Priority Release Rate 5.1
3G Reverse Data Burst Rate 5.1
3G Reverse Supplemental Channel Priority Release Rate 5.1
Anchor Transfer Rate 5.2
Secondary Forward Aggregate Transmitted Rate [Kbps] 5
Reverse Aggregate Transmitted Rate [Kbps] 5
Forward Aggregate Data Per call [Kbytes per call] 5
Reverse Aggregate Data Per call [Kbytes per call] 5
3G Forward Fundamental Channel Activity Rate 5
3G Reverse Fundamental Channel Activity Rate 5
3G Forward Supplemental Channel Activity Rate 5
3G Reverse Supplemental Channel Activity Rate 5
FSCH Blocking due to Channel Fragment Limit 5.1.3
FSCH Blocking due to Packet Pipe Limit 5.1.2
FSCH Blocking due to RF Capacity Limit 5.1.1
FSCH Blocking due to Walsh Code Limit 5.1.4
FSCH Data Transmitted [Kbytes] 5
FSCH Overall Rate Reduction 5.1
FSCH Rate Reduction due to Channel Fragment Limit 5.1.3
FSCH Rate Reduction due to Packet Pipe Limit 5.1.2
FSCH Rate Reduction due to RF Capacity Limit 5.1.1
FSCH Rate Reduction due to Walsh Code Limit 5.1.4
Walsh Code Utilization [RC3] 5.1.4.2
HSPD IWF/PCF Initiated Reactivation Failure Rate 5.5
HSPD Mobile Initiated Reactivation Failure Rate 5
HSPD Reactivation Data Protocol Handler [DPH] 5.5
Overflow
RSCH Rate due to Channel Fragment Limit
Blocking 5.1.3
RSCH Blocking due to Packet Pipe Limit 5.1.2
RSCH Blocking due to RF Capacity Limit 5.1.1
RSCH Data Transmitted [Kbytes] 5
RSCH Overall Rate Reduction 5.1
RSCH Rate Reduction due to Channel Fragment Limit 5.1.3
RSCH Rate Reduction due to Packet Pipe Limit 5.1.2
RSCH Rate Reduction due to RF Capacity Limit 5.1.1
FSCH Request to Assignment Deficit Rate 5
RSCH Request to Assignment Deficit Rate 5
FSCH Assignment Rate for 19.2 Kbps 5.1.4.2.1
3G FFCH Frame Error Rate 5
3G FSCH Frame Error Rate 5
3G RFCH Frame Error Rate 5
3G RSCH Frame Error Rate 5

179
APPENDIX B O V E RV I E W O F S P O TO O L
System Performance Optimization Tool (SPO) is the next generation of existing SPAT3G tool. It
is a PC-based tool that is designed for rapid troubleshooting, system performance analysis and RF
optimization. SPO has the ability to analyze Service Measurements (SM), ROP, Translations, Per
Call Measurement Data (PCMD), Flexent Inventory, Neighbor list, Handoff Matrix (HOM), and
Undeclared Neighbor List (UNL) data simultaneously. SPO supports ECP release 23 and
beyond. It is important to note that SPAT3G tool is still available and can be used but will
eventually be phased out and replaced entirely with SPO. For markets with ECP release 23 or
lower, SPAT3G should be used.
SPO structure
There are three components in SPO – the DFDP (Data Filtering and Data Packaging), DSM
(dedicated SPO Module), and the SPO PC GUI tool. The DFDP package have to be installed on
the OMP or any UNIX box to collect SM, ROP, Translations, PCMD, IWF/PCF, Flexent
Inventory, 5E counts, and HOM data on a daily basis, with PCMD data collection being optional.
A cron job can be set up on the OMP to run these scripts a few minutes past midnight every day
to collect the relevant data. At the completion of the cron job, a single zipped file is generated
that is an archive of the SM, ROP, Translations, PCMD (if collected), Flexent Inventory, 5E, and
HOM data that was collected for that day. The naming convention used for the zipped file is
ECP-Number_yyyymmdd.spr (e.g. 1_20050715.spr).
The spr file needs to be downloaded to the DSM PC from the OMP everyday for further
processing. The DSM portion of the SPO tool processes the spr file(s) along with the cells
information (e.g. LCAT file) and Street maps and creates an SP file. Using SP files, datasets are
generated with PC SPO tool. This datasets are used in displaying the SM performance metrics,
ROP analysis, Translations summary, PCMD analysis (if PCMD data is collected), FCIAlert
analysis, CDMA Directed Hard Handoff Neighbor List (CDHNL), Undeclared Neighbor List,
and Handoff Matrix analysis and basic 5E count data. Additionally, PDSN MIB data may be
manually added to a CDMA network (currently Starent and Cisco PDSNs are supported). The
cell information and street maps can be combined into a “GeoScheme” in SPO which can be re-
used to create multiple SPO datasets for the same market. The next few sections explain the
different types of analyses that are available with SPO once the data has been processed.
Service Measurements analysis
The sp files contain raw service measurement peg counts that are used within the PC portion of
SPO to compute performance metrics based on hard-coded equations (e.g. Drop Call rate, RF
Access Failure rate, etc.). These performance metrics are available on a per-system, per-cell, per-
sector and per-carrier levels depending on the peg counts used for the calculations. 2G and 3G
performance metrics are available for Voice and Data separately. Additionally, users may define
new performance metrics using the available peg counts, or modify existing metrics.
ALCATEL-LUCENT
PROPRIETARY
Appendix Figure 1 shows the executive summary of SPO. The executive summary shows key
performance metrics on a per system level for the whole day (24-hour), for the busy hour for each
day for which SM data is available, or for multiple hours (if multiple hour data is collected on the
OMP). Each metric is color-coded red when it exceeds a certain threshold. This enables the user
to rapidly identify which metric is under-performing in a system. All the performance metrics are
classified under multiple categories available as individual tabs in SPO. For example, Lost Call
rate and Call Shutdown rate metrics are available under the Drop Call tab in SPO.
Appendix Figure 1 Executive Summary
LUCENT T ECHNOLOGIE S P ROPR IE TARY

181
Appendix Figure 2 SM Summary Window and Peg count details
Appendix Figure 2 shows the per cell level view of a certain metric. Double-clicking on any grid
opens up a definition window for the peg count or the metric. The formula used for the
calculation of the metric is available as part of the display window along with the threshold that is
used to color-code the metric. SPO metrics are also available in map view format. Appendix
Figure 3 shows one such example of a performance metric on a map. Each cell/sector is color-
coded according to the value of the metric that is being displayed.
SM metrics and peg counts can also trended if data from multiple days is available. Appendix
Figure 4 shows multiple metrics as a trend for multiple days’ worth of data.

182
Appendix Figure 3 SM Map
Appendix Figure 4 SM Trend

183
ROP Analysis
SPO analysis of ROP data is available in two formats: ROP Reports and ROP Tables. ROP
Reports show ROP data in a pre-configured report format on a per-system and per-cell level or
lower (depending on the ROP message). ROP Tables show ROP data as tabular lists. For both,
ROP Reports and ROP Tables, several different categories of ROP analysis are available – Call
Processing Failures, Hardware Error Handlers, Asserts, Restorals, PP/DS1 HEH’s, etc. Wherever
it is relevant the failing hardware board is also specified in the analysis. For example, Call
Processing failure analysis is available at a per-system, per-cell, per-sector, per-CCC/CDM and
per-CCU levels.
The ROP Report was updated in SPO to include the following:
1. For CP failures, a Call Shutdown mapping to Call Release Reason or Assert has been added.
This analysis provides per-sector breakdown of the call shutdown types per call release reason or
per assert code.
2. For CP failures, Type 10 Call Shutdowns (CS-[10] Handoff Complete Timeout) are broken
down per sector per active set sectors. This analysis shows the number of CS-[10] per sector and
the other active set sectors on the active set at the time of the call shutdown.
Appendix Figure 5 shows the system level view of Call Processing Failures.
Appendix Figure 5 ROP Summary

184
Translations Summary
The existing translations settings for a system can be viewed using SPO. As part of the OMP
scripts, SPO picks up the TRX file that is generated on the OMP. The TRX file contains the
translations settings from several database forms and for all cell/sectors in the system.
SPO color-codes any translation setting that is different from Lucent recommended values.
Comparison of this translation setting can also be made against user-specific recommendations
and this is color-coded differently. In addition, some checks are done to verify the cell site type
before certain translations settings are compared against recommended values.
A definition window pops up when the user double-clicks on a particular translation grid. The
translations summary can also viewed for all the cells/sectors at the same time or for one
cell/sector at a time. Appendix Figure 6 shows a sample translations summary window with a
translation definition window. Additionally, doing time-based analysis may easily reveal changes
to translations over time. Translations from one network element can also be compared against
those of other elements.
Appendix Figure 6 TRX Summary Window
PCMD Analysis

185
PCMD analysis is now available from within SPO (if the PCMD data is collected in the OMP and
SPO is set to collect the data). Several reports are currently available for PCMD analysis: PCMD
Metrics Summary, Drop Call Metrics, Established Call Metrics, TCCF Matrix, SMS Metrics,
Service Option Matrix, Sector Traffic Pattern, Drop Call Analysis, Drop Call Triangulation and
Drop Call Distance Histogram, Access Failure Analysis, Access Failure Triangulation and Access
Failure Histogram, and several Mobile based metric reports.
For dropped calls and access failures the Drop Call/Access Failure Analysis, Drop Call/Access
Failure Triangulation, and Drop Call/Access Failure Distance Histogram provide additional
analysis for drops or access failures. The PCMD Metrics Summary analysis provides
performance metrics derived from PCMD recorded call events. The Drop Call Metrics provides a
breakdown of the drop call metrics. The TCCF and Service Option Matrices provide information
as to TCCF failures and Service Options requested. The Sector Traffic Pattern provides
information on traffic flow from an initial cell and sector to a final cell and sector. The Drop
Call/Access Failure Analysis report provides pilot set information for active and non-active set
information for dropped calls and access failures based on PSMM data as well as drop call and
access failure reasons and possible root cause information. Drop Call/Access Failure
Triangulation provides estimated dropped call and access failure locations if cell information is
available (triangulation for dropped calls and access failures is done if a GeoScheme was created
and associated to a dataset). Finally, the Drop Call/Access Failure Distance Histogram offers a
breakdown of the distances between the selected sector and its dropped calls and access failures.
Appendix Figure 7 shows a map if triangulated dropped calls.
Appendix Figure 7 Map of triangulated PCMD Drop Calls

186
FCIAlert Analysis
FCIAlert tool is now available from within SPO. The fci database information from the TRX file
is used to perform the FCIAlert analysis. The need for running the dbsurvey scripts to extract
neighbor list information from the OMP is not required any more. The different types of
warnings that are generated include Reciprocity alert, and one-way and two-way PN ambiguity
alerts and others.
In addition, the FCIAlert tabular report, a map view is available for the current neighbor list (with
priority groups marked in different colors) and for all the individual alerts. This enables the user
to visualize where the neighbor list problem is located.
For Release 22 and beyond, SPO displays distance between source and target sectors for all
FCIAlerts if cell location information is available as a GeoScheme. This data may be used to
prioritize FCIAlert fixes.
Handoff Matrix Analysis
Analysis of Handoff Matrix data is also possible with SPO. Handoff Matrix data (study types
1008 and 1009) from multiple days and multiple ECPs can be analyzed together. A Handoff
Summary output and an Add/Delete neighbor list suggestion output are displayed. Map view of
these two output types is also available.
For Release 22 and beyond, SPO displays distance between source and target sectors for handoff
matrix tables if cell location information is available as a GeoScheme as well as the reverse
handoff information.
CDMA Directed Hard Handoff Neighbor List (CDHNL) Analysis
SPO also provides a list of target faces that may be eligible for adding to a border sector’s
CDHNL lists based on handoff matrix data and current CDHNL entries. The CDHNL eligibility
list is presented in tabular form and can be used to optimize current or new CDHNL lists.
For release 22, SPO displays distance between source and target sectors for CDHNL tables if cell
location information is available as a GeoScheme.
Undeclared Neighbor List (UNL) Analysis
Analysis of UNL data is also possible with SPO. UNL data records contain information about
remaining set pilots reported by the mobile in the Pilot Strength Measurement Message (PSMM).
SPO can analyze UNL data and compare it with current neighbor lists and recommend neighbor
list additions. This data may also be used to identify overshooting sectors and recommend
antenna down-tilts or power attenuation. A Map view of UNL suggested additions are also
available.
For Release 22, SPO displays distance between source and target sectors for UNL tables if cell
location information is available as a GeoScheme.

187
PDSN Analysis
Analysis of PDSN MIB data is now possible with SPO. PDSN MIB data for Starent or Cisco
PDSNs is used to generate basic PDSN reports such as Starent and Cisco Metric summaries and
configuration reports.
For PDSN metric summaries, data may be viewed in tabular form or as trends, and metric
summaries are available showing the breakdown of a metric into its components.
Other features in SPO
There are other features in SPO that have not been described in detail in the previous sections that
are useful for performance analysis. One such key feature is the ability to create a subset. A
subset could be created as a collection of a few cells (e.g. cells within a cluster). The subset’s
performance can be compared against the performance of the system as a whole. Another
example of using subset analysis would be to compare performance across multiple carriers.
Even in the absence of SM and/or ROP files, SPO can also be used to view translations summary
and perform FCIAlert, UNL, and Handoff Matrix analysis.
For ECP Release 21 and beyond, the ability to collect and display simple 5E count information is
available in SPO. The 5E counts come from the Trunk Group and High Speed Data sections of
the TRFC30 reports (Sections 12 and 244 in NAR 5E).
Any table that is displayed in SPO can also be exported as a comma-delimited file or as an MS
Excel spreadsheet. This file can then be used for further analysis if the need exists. SPO also has
the mechanism to report bugs or feature requests. This can be done from the “Help” menu
option and an email from the user’s computer is sent automatically to the SPAT team.
Additionally, users may define their own performance metrics using the User Defined Metrics
feature. This feature allows users to create metrics from raw peg counts, or modify existing
metrics. Another feature, User Defined Categories, allows users to place any peg count, or any
metric, into user specified categories. These two features may be used to create custom reports or
provide specific data for further analysis.
User preferences can be set from the “Preferences” menu option. Some examples of preferences
are setting working directory, custom ranges, adding new translations field for display or
changing recommended values, and setting handoff matrix and UNL thresholds. Another user
preference is the SPO Service option. Using this option, a user may have SPO automatically
create datasets. This is done by enabling the SPO service and placing the sp files to be processed
in a drop-box location. The SPO service monitors this location and if it sees an sp file in it, it will
start processing. This may be done periodically, or a user may set a specific start time for creating
the dataset.
As of Release 25, LCAT (the cell site editing utility) was integrated into SPO. This utility is used
to create the cells.lcat files (historically known as cells.mdb) that contain cell locations as well as
antenna azimuths, antenna beam widths and other information use for mapping cell sites, or
analyzing cell location dependent data (such as PCMD drop call triangulation).
A detailed SPAT3G presentation is available as a course (LTW624) from the Wireless University
website. Online help providing how-to steps is also available within the tool or in the Wireless

188
Service Creation & Performance web site, see the References for more information. A modified
SPO training course is currently being worked at and will be available shortly.

189
APPENDIX C KMS SOLUTIONS CROSS-REFERENCE
Table C-1 KMS Solutions Cross Reference
Solution ID Solution Title

lu399986 Converting Cell from Release 26 to Release 27 and CCU Board will not restore after
lu382106 CBR out of service with configuration mismatch after routine diagnostics
lu375158 Increase Neighbor List to 40 on Traffic & Paging Channel Optional Feature
lu372800 Increase in EVRC 3G CP-Fail Call Setup Failures CDMA-PAF-CARR-SC 38
lu352040 Paging Channel Overhead Message Broadcast Rate
lu344444 CMU going in and out of service
lu343586 PP OOS after routine diagnostics
lu334268 M&P - Cell is OOS on CDMA 25.01 and 25.02 with Range Extansion feature activated on
lu332439 cell2 form.
URC OOS
lu321902 High access channel occupancy
lu319958 There are strong RF interference in the CDMA 450 band
lu312188 What is HOMAX
lu292473 Interfrequency handoff not working between two MSCs
lu291506 Very High RF Access Failure Rate
lu291230 To resolve 3G-1X data no reverse link throughput problem
lu251618 To resolve
TFU 3G-1X data no reverse link throughput problem
fails 1-2-32
lu214429 IS41 Inter Vendor Hard handoff pegs on Non-Borders
lu199009 How to set up 3G-1X Return From Handoff Failure?
lu198697 How to set up 3G-1X Mobile Assisted Inter-Frequency Handoff?
lu198558 How to set up Distance-Based Directed Handoff for Phase 2?
lu198557 High Reverse Frame Error Rate (RFER)
lu198556 Decrease in Reverse Frame Error Rate (RFER)
lu153516 Why Voice vs. Data Call Admission Feature can not reserve CE in a CCU32/ECU32 for data
amps77058 How to configure Modcell 4.0 and HD 4.0 signaling link width.
amps73680 Data throughput performance expectations for 3G1X using a Controlled Test Scenario
amps53945 Overview and optimization of Frame Error Rate (FFER and RFER )
amps53944 Increase in CP fail dropped calls due to Undesired Hard-Handoffs
amps53943 Increase in CPF dropped calls due to Incorrect Management of Cross-Carrier Assignments
amps53942 Increase in CP Fail Drops due to Poorly Optimized Border Sectors
amps53941 Overview and optimization of CP Fail Drops
amps53940 Increase in lost calls due to Inadvertent Change of Translations
amps53933 Increase in lost calls due to Incorrectly Optimized New Cell
amps53932 Increase in lost calls due to Intermittent Hardware Problems
amps53931 High lost call rate due to Co-PN Interference
amps53930 Increase in lost calls due to Reverse Link External Interference
amps53929 High lost call rate due to Search Window Problems
amps53928 High lost call rate due to Pilot Polluted Areas
amps53452 Increase in Lost Calls because Handoff Target Cell is Blocking on All Carriers
amps53451 Increase in Lost Calls due to Island-Mode Cell
amps53450 High Lost Call Rate due to Poor Coverage
amps53449 High Lost Call Rate due to High Traffic Areas
amps53448 High Lost Call Rate due to Poorly Defined Neighbor Lists
amps53417 Concepts and optimization techniques for lost calls
amps53416 What is the equation for drop call rate?
amps53414 Call receives secondary treatment due to registration problems and paging strategies
amps53413 Termination failures related to call delivery type
amps53412 Reverse Link Power Overload Blocking Due to External Interference
amps53387 Reverse link power overload detected on some carriers of multi-carrier sector
amps53386 Reverse link power overload blocking due to excessive soft-handoff zones
amps53385 Reverse link power overload blocking because sector has reached capacity limit
amps53383 Conceptual overview of reverse link power overload blocking
amps53382 Forward power overload is detected on some carriers of a multi-carrier sector
amps53061 Forward Power Resource Blocking due to Incorrect Setting of VAF
amps53060 Forward Power Resource Blocking due to Excessive Soft-Handoff Zones
amps53059 Forward Power Resource Blocking because Sector has Reached Capacity Limit
amps53058 How to Manage Forward Power Resource?

190
amps53019 Conceptual overview of forward power resource blocking

amps53017 CE/PP Resource Blocking due to Hardware Outages
amps53016 Blocking Due to lack of CE/PP Resources
amps52982 How to manage CE/PP resource blocking
amps52980 Conceptual overview of channel elements and packet pipes
amps52961 Call Setup failure due to Speech Handler Failures
amps52958 What are Call Processing Failures at Setup?
amps52957 Increase in CRTU/CTRM Traffic Channel Confirmation Failures
amps52956 Increase in Traffic Channel Confirmation Failures due to Intermittent Hardware Problems
amps52183 Increase in Traffic Channel Confirmation Failures When Hardware Goes Into Bad State
amps52182 Increase in Traffic Channel Confirmation Failures due to Co-PN Interference
amps52164 How to provision packet pipes
amps52102 Increase in Traffic Channel Confirmation Failures due to Reverse Link External Interference
amps52101 Increase in Traffic Channel Confirmation Failures due to Search Window Problems
amps52100 Increase in Traffic Channel Confirmation Failures due to Lack of RF Coverage
amps52099 Increase in Traffic Channel Confirmation Failure due to Excessive Soft-Handoff Zones
amps52098 Increase in Traffic Channel Confirmation Failure due to Poorly Defined Neighbor Lists
amps51603 3G Blocking due to Insufficient FCH Channel Fragments
amps51602 Reduced data throughput due to Span Outage
amps51601 Reduced data throughput Due to Insufficient Packet Pipe Provisioning
amps51600 Blocking due to insufficient packet pipe provisioning
amps50484 Cell Site Releasing Markov Calls
amps50475 Traffic Channel Confirmation Failure in High Traffic Areas
amps50475 Traffic Channel Confirmation Failure due to failing Cross-carrier Assignments
amps50474 What are IS95B enhancements to improve TCCF performance?
amps50473 What are Silent Reoriginations?
amps50407 What is TCCF?
amps50406 What is established call rate?
amps49951 Reduced data throughput due to 3G to Non-3G Handoffs
amps49950 Reduced data throughput due to 3G to 3G Hard Handoff
amps49758 What are Excessive Anchor Transfers?
amps49673 Reduced data throughput due to insufficient Walsh Codes
amps49671 Reduced data throughput due to insufficient SCH channel fragments
amps49670 SCH Blocking due to insufficient packet pipe provisioning
amps49669 Reduced data throughput due to span outage
amps49668 Overview of blocking / rate reduction due to RF
amps49608 What are key CDMA performance metrics?
amps16308 Modcell signaling links OOS on growth frame

191

CDMA RF Performance Analysis & Troubleshooting Guide R28.0 - Final

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

CDMA RF Performance Analysis & Troubleshooting Guide R28.0 - Final

Enviado por

Direitos autorais:

Formatos disponíveis

CDMA 3G-1X

RF T OOLS & S ERVICES S YSTEMS

2. USING THIS GUIDE ........................................................................................................................... 16

4.1.3.2.3 Speech Handler Failures........................................................................................... 61

A LC ATE L - LUCENT P ROPR IETARY

4.2.1.2.12 Incorrectly Optimized New Cell .............................................................................. 117

A LC ATE L - LUCENT P ROPR IETARY

5.1.3.1.2 CF Provisioning Strategies ..................................................................................... 159

APPENDIX B OVERVIEW OF SPO TOOL .................................................................................. 180

APPENDIX C KMS SOLUTIONS CROSS-REFERENCE ........................................................... 190

APPENDIX FIGURE 1 EXECUTIVE SUMMARY ............................................................................... 181

A LC ATE L - LUCENT P ROPR IETARY

A LC ATE L - LUCENT P ROPR IETARY

A LC ATE L - LUCENT P ROPR IETARY

List of Abbreviations (Cont)

A LC ATE L - LUCENT P ROPR IETARY

Version Changes Date

A LC ATE L - LUCENT P ROPR IETARY

Reservation Based on RF Power Optional Feature Description

A LC ATE L - LUCENT P ROPR IETARY

 Changed Lucent entries to Alcatel-Lucent where relevant

A LC ATE L - LUCENT P ROPR IETARY

A LC ATE L - LUCENT P ROPR IETARY

[30] 401-612-717 Distance Based Hand-Off and Origination/Termination Optional Feature

Useful Web Pages

A LC ATE L - LUCENT P ROPR IETARY

Cares Tickets (ARs) http://cares.web.lucent.com/

A LC ATE L - LUCENT P ROPR IETARY

 Base station hardware failures (including intermittent problems)

A LC ATE L - LUCENT P ROPR IETARY

2. USING THIS GUIDE

 To perform system-wide CDMA network performance management where a large

A LC ATE L - LUCENT P ROPR IETARY

2.1 Using the Guide for System-Level Troubleshooting and Analysis

Note that, when performing such system-level audits or performance management, it is

A LC ATE L - LUCENT P ROPR IETARY

2.2 Using the Guide for Troubleshooting Specific CDMA Performance

A LC ATE L - LUCENT P ROPR IETARY

2.3 Using the Guide as a Reference for Principles of KPI Performance

A LC ATE L - LUCENT P ROPR IETARY

3. SUMMARY OF PERFORMANCE RELATED FEATURES IN

3.1 RF Performance Features in Release 27

 FID 4610.11 - CDMA SM Enhancements - Phase 8: This feature provides new

o SMS Termination Layer 3 Acknowledgements for CPAGE SMS

 FID 10378.6 - CE Provisioning Fragmentation with the CMU-IVB: This feature

A LC ATE L - LUCENT P ROPR IETARY

 FID 12179.2 - Customer-Critical Translations Maintenance - Phase 3: This feature is

3.2 RF Performance Features in Release 28

A LC ATE L - LUCENT P ROPR IETARY

 FID 10438.5 – Performance Metrics and SM Report Generator (SMRG) Updates

A LC ATE L - LUCENT P ROPR IETARY

paralleling of three 2PAMs to increase the maximum output power from

 FID 10361.2 - Increase of Number of Carriers Supported in CGSA: This feature

o This feature is only supported on NGN AP and requires OMP FX v2.

o Load balancing is done based on paging channel occupancy and RF loading

A LC ATE L - LUCENT P ROPR IETARY

FID13192.0 - Enhanced treatment of Unauthorized Packet Data Calls Handled by the 3G

A LC ATE L - LUCENT P ROPR IETARY

3.2.1 Feature Exceptions in Release 28

A LC ATE L - LUCENT P ROPR IETARY

4. VOICE AND DATA KPI OPTIMIZATION AND

2) How good is the quality of the call during the call?

1) Established Call Rate