RF Troubleshooting Guide

Lucent Technologies
Bell Labs Innovations
CDMA
R F P E R F O R M A N C E A N A LY S I S
&
TROUBLESHOOTING
GUIDE
R EV 18.0
RF P ERFORMANCE ANALYSIS AND TOOLS

GROUP
LUCENT TECHNOLOGIES PROPRIETARY

CDMA RF P ERFORMANCE A NALYS IS & T ROUB LES HOOTING G UIDE
TA B L E O F C O N T E N T S
1. INTRODUCTION................................................................................................................................... 8
2. USING THIS GUIDE ............................................................................................................................. 9

2.1 USING THE GUIDE FOR SYSTEM-LEVEL TROUBLESHOOTING AND ANALYSIS ..............10
2.2 USING THE GUIDE FOR TROUBLESHOOTING SPECIFIC CDMA PERFORMANCE
PROBLEMS ................................................................................................................................11
2.3 USING THE GUIDE AS A REFERENCE FOR PRINCIPLES OF KPI PERFORMANCE
MANAGEMENT AND TROUBLESHOOTING ...........................................................................12
3. VOICE AND DATA KPI OPTIMIZATION AND TROUBLESHOOTING .................................. 13
3.1 ESTABLISHED CALL RATE ....................................................................................................14
3.1.1 RF Access Failure (TCCF) Analysis........................................................................... 15
3.1.1.1 Concepts and Optimization Techniques........................................................................ 15
3.1.1.1.1 Initial Cell Selection by Mobile in Idle Mode............................................................ 17
3.1.1.1.2 Access Probe Sequence ............................................................................................. 18
3.1.1.1.3 Channel Assignment Message on Paging Channel ................................................... 18
3.1.1.1.4 Traffic Channel Acquisition by Mobile and Cell....................................................... 22
3.1.1.1.5 Final Handshake to Confirm Service Option and Service Connection...................... 24
3.1.1.2 Silent Reoriginations..................................................................................................... 24
3.1.1.3 Recent IS95B Enhancements ........................................................................................ 25
3.1.1.3.1 Access Entry Handoff (AEHO) Feature .................................................................... 26
3.1.1.3.2 Access Handoff (AHO) Feature ................................................................................ 26
3.1.1.3.3 Channel Assignment into Soft Handoff (CAMSHO) Feature..................................... 26
3.1.1.4 TCCF Causes and Associated Fixes ............................................................................. 27
3.1.1.4.1 High Traffic Areas..................................................................................................... 27
3.1.1.4.2 Cross-Carrier TCCFs ............................................................................................... 29
3.1.1.4.3 Poorly Defined Neighbor Lists.................................................................................. 34
3.1.1.4.4 Excessive Soft-Handoff Zones ................................................................................... 36
3.1.1.4.5 Lack of RF Coverage ................................................................................................ 37
3.1.1.4.6 Search Window Problems ......................................................................................... 38
3.1.1.4.7 External Interference ................................................................................................ 39
3.1.1.4.8 Co-PN Interference ................................................................................................... 40
3.1.1.4.9 Hardware Goes Into Bad State ................................................................................. 41
3.1.1.4.10 Intermittent Hardware Problems .............................................................................. 42
3.1.1.4.11 CRTU/CTRM TCCFs ................................................................................................ 42
3.1.2 Call Setup Failure Analysis ........................................................................................ 43
3.1.2.2 Commonly Encountered Types of Call Setup Failures ................................................. 44
3.1.2.2.1 Call Shutdown Type 43 (CS-[43])............................................................................. 44
3.1.2.2.2 Call Shutdown Type 10 (CS-[10])............................................................................. 44
3.1.2.2.3 Speech Handler Failures........................................................................................... 45
3.1.3 CE/PP Resource Blocking Analysis ............................................................................ 46
3.1.3.1.1 Conceptual Overview for 2G Cells............................................................................ 46
3.1.3.1.2 3G1X Enhancements & Concepts ............................................................................. 48
3.1.3.1.3 CE/PP Blocking Definition ....................................................................................... 50
LUCENT T ECHNOLOGIES P ROPRIETARY

3.1.3.1.4 CE/PP Resource Blocking Management Techniques ................................................ 50

3.1.3.2 CE/PP Resource Blocking Causes and Associated Fixes.............................................. 51
3.1.3.2.1 Cell Resource Capacity Reached .............................................................................. 51
3.1.3.2.2 Hardware Outages .................................................................................................... 53
3.1.3.2.3 Intermittent Hardware Problems .............................................................................. 53
3.1.4 Forward Power Resource Blocking Analysis.............................................................. 54
3.1.4.1.1 Conceptual Overview ................................................................................................ 54
3.1.4.1.2 Important Lucent Features and Translations ............................................................ 58
3.1.4.1.3 Forward Power Resource Blocking Management Techniques.................................. 59
3.1.4.2 Forward Power Resource Blocking Causes and Associated Fixes................................ 60
3.1.4.2.1 Sector has reached Capacity Limit............................................................................ 60
3.1.4.2.3 Incorrect Setting of VAF Causes Early Overload ..................................................... 62
3.1.4.2.4 Overload Not Detected on All Carriers of Multi-Carrier Sector............................... 63
3.1.5 Reverse RF Loading Resource Blocking Analysis ...................................................... 66
3.1.5.1.2 Reverse RF Loading Blocking Management Techniques .......................................... 68
3.1.5.2 Reverse RF Loading Resource Blocking Causes and Associated Fixes ....................... 70
3.1.5.2.1 Sector has reached Capacity Limit............................................................................ 70
3.1.5.2.3 Overload Not Detected on All Carriers of Multi-Carrier Sector............................... 71
3.1.6 Termination Failures Related to Call Delivery Type.................................................. 75
3.1.7 Termination Failures due to Registration Problems and Paging Strategies .............. 76
3.1.7.1.2 Registration and Paging Strategy Recommendations ............................................... 79
3.2 DROP CALL RATE ...................................................................................................................80
3.2.1 Lost Calls .................................................................................................................... 80
Conceptual Overview ................................................................................................................... 80
Optimization Steps for Reducing Lost Calls................................................................................. 81
3.2.1.2 Lost Call Causes and Associated Fixes......................................................................... 83
3.2.1.2.1 Poorly Defined Neighbor Lists.................................................................................. 83
3.2.1.2.2 High Traffic Areas..................................................................................................... 85
3.2.1.2.3 Significant Areas of Poor Coverage.......................................................................... 86
3.2.1.2.4 Island-Mode Cell....................................................................................................... 87
3.2.1.2.5 Handoff Cell is Blocking on All Carriers .................................................................. 88
3.2.1.2.6 Pilot Polluted Areas .................................................................................................. 89
3.2.1.2.7 Search Window Problems ......................................................................................... 89
3.2.1.2.9 Co-PN Interference ................................................................................................... 91
3.2.1.2.10 Hardware Outages and/or Intermittent Hardware Problems ................................... 93
3.2.1.2.11 Incorrectly Optimized New Cell ................................................................................ 93
3.2.1.2.12 Inadvertent Change of Translations.......................................................................... 94
3.2.2 CP Fail Drops ............................................................................................................. 95
3.2.2.1.1 General Description.................................................................................................. 95
3.2.2.1.2 Inter-Frequency Semi-Soft Handoff Concepts........................................................... 96
3.2.2.1.3 Optimization Steps for Reducing CP Fail Drops ...................................................... 99
3.2.2.2 CP Fail Causes and Associated Fixes ......................................................................... 100
3.2.2.2.1 Poorly Optimized Border Sectors............................................................................ 100
3.2.2.2.2 Incorrect Management of Cross-Carrier Assignments on Border Sectors .............. 101
3.2.2.2.3 Drops due to Undesired Hard-Handovers .............................................................. 102
LUCENT T ECHNOLOGIES P ROPRIETARY 2

3.3 FCH FRAME ERROR RATE ..................................................................................................103

3.3.1 Concepts and Optimization Techniques.................................................................... 103
3.3.1.1 Forward Frame Error Rate (FFER) ............................................................................. 104
3.3.1.1.1 2G and 3G Radio Configurations............................................................................ 104
3.3.1.1.2 FFER Calculation for 2G RS2 ................................................................................ 104
3.3.1.1.3 FFER Calculation Using PMRM ............................................................................ 106
3.3.1.1.4 Optimization Steps for FFER .................................................................................. 106
3.3.1.2 Reverse Frame Error Rate (RFER) ............................................................................. 107
3.3.1.2.1 RFER Calculation ................................................................................................... 107
3.3.1.2.2 Optimization Steps for RFER .................................................................................. 108
3.3.1.2.3 Other Poor RFER Causes and Associated Fixes..................................................... 108
4. HIGH SPEED PACKET DATA (HSPD) - SPECIFIC KPI OPTIMIZATION AND
TROUBLESHOOTING ..................................................................................................................... 110
4.1 SUPPLEMENTAL CHANNEL BLOCKING / RATE REDUCTION .........................................114
4.1.1 Blocking / Rate Reduction Due to RF Capacity........................................................ 115
4.1.1.1 Concepts and Optimization Techniques...................................................................... 115
4.1.1.1.1 Overview of SARA ................................................................................................... 115
4.1.1.1.2 Forward Link Optimization Techniques.................................................................. 116
4.1.1.1.3 Reverse Link Optimization Techniques ................................................................... 117
4.1.1.2 RF Capacity Related Failure Causes and Suggested Fixes ......................................... 119
4.1.1.2.1 Excessive Areas Lacking Pilot Dominance ............................................................. 119
4.1.1.2.2 Excessive Pathloss .................................................................................................. 119
4.1.1.2.3 Neighbor List Problems .......................................................................................... 120
4.1.1.2.4 Candidate Sector Resource Blocking ...................................................................... 122
4.1.2 Blocking / Rate Reduction Due to Packet Pipes ....................................................... 123
4.1.2.1.1 Conceptual Overview .............................................................................................. 123
4.1.2.1.2 Important Lucent Features...................................................................................... 124
4.1.2.1.3 Packet Pipe Provisioning Strategies ....................................................................... 124
4.1.2.2 PP Blocking / Rate Reduction Causes and Associated Fixes...................................... 126
4.1.2.2.1 Blocking / Rate Reduction due to Insufficient PP Provisioning .............................. 126
4.1.2.2.2 Blocking / Rate Reduction due to Span Outage....................................................... 126
4.1.3 Blocking / Rate Reduction Due to Channel Fragments ............................................ 127
4.1.3.1.1 Overview of 3G Channel Cards .............................................................................. 127
4.1.3.1.2 CF Provisioning Strategies ..................................................................................... 128
4.1.3.1.3 Assigning Calls to Appropriate Channel Cards by Technology .............................. 129
4.1.3.2 CF Blocking / Rate Reduction Failure Causes and Fixes............................................ 131
4.1.3.2.1 Blocking / Rate Reduction because no FCH available............................................ 131
4.1.3.2.2 Blocking / Rate Reduction because no SCH available ............................................ 132
4.1.4 Blocking / Rate Reduction Due to Walsh Codes ....................................................... 132
4.1.4.1.1 Overview of Variable Walsh Spreading Factors ..................................................... 132
4.1.4.1.2 Concept of Walsh Code Blocking............................................................................ 133
4.1.4.1.3 Walsh Code Optimization Techniques..................................................................... 135
4.1.4.2 Walsh Code Blocking / Rate Reduction Failure Causes and Fixes ............................. 135
4.1.4.2.1 Unavailable Walsh Codes due to Excessive High-Speed Connections.................... 135
4.1.4.2.2 Unavailable Walsh Codes due to Excessive Low-Speed Connections..................... 136
4.2 EXCESSIVE ANCHOR TRANSFERS ......................................................................................136
4.2.1 Concepts and Optimization Techniques.................................................................... 136
4.2.1.1 Conceptual Overview.................................................................................................. 136
4.2.1.2 Optimization Techniques ............................................................................................ 137

4.3 3G!3G INTER-FREQUENCY HANDOFFS..........................................................................138

4.3.1 Concept / Reasons for Throughput Degradation ...................................................... 138
4.3.2 Symptoms and Identification Techniques.................................................................. 139
4.3.3 Suggested Fixes for Improvement ............................................................................. 139
4.4 3G!NON-3G HANDOFFS ....................................................................................................140
4.4.1 Concept / Reasons for Throughput Degradation ...................................................... 140
4.4.2 Symptoms and Identification Techniques.................................................................. 141
4.4.3 Suggested Fixes for Improvement ............................................................................. 141
4.5 OUTAGES AND ERRORS IN THE PACKET NETWORK .........................................................142
APPENDIX A METRIC CROSS-REFERENCE ............................................................................ 143
APPENDIX B OVERVIEW OF SPAT TOOL................................................................................ 145
List of Tables
TABLE 3.1 NUMBER OF CALLS SUPPORTED WITH PPOPT .......................................................................... 47
TABLE 3.2 NUMBER OF CALLS PER SERVICE CLASS FOR VARIOUS PACKET PIPE BANDWIDTHS ................ 50
TABLE 3.3 VOICE ACTIVITY FACTOR SETTINGS AND CORRESPONDING SCALING FACTORS ......................... 56
TABLE 3.4 TABLE OF TYPICAL PEAK PRIMARY ERLANG VALUES ............................................................... 58
TABLE 3.5 TABLE OF TYPICAL PEAK PRIMARY ERLANG VALUES ............................................................... 68
TABLE 3.6 2G AND 3G RADIO CONFIGURATIONS ..................................................................................... 104
TABLE 4.1 NUMBER OF CALLS PER SERVICE CLASS FOR VARIOUS PACKET PIPE BANDWIDTHS .............. 125
List of Figures
FIGURE 1 IS95A ORIGINATION CALL FLOW...................................................................... 16
FIGURE 2 SEMI-SOFT HANDOFF CALL FLOW................................................................... 96
FIGURE 3 FCH/SCH UTILIZATION FOR TYPICAL WEB BROWSING SESSION ....... 111
FIGURE 4 3G1X HIGH SPEED PACKET DATA NETWORK PROTOCOL STACK....... 114
FIGURE 5 RC3 WALSH CODE TREE..................................................................................... 134

List Of Abbreviations
AOC Aggregate Overload Control

AR Autonomous Registration
CAM Channel Assignment Message
CCC CDMA Cluster Controller
CCU CDMA Cluster Unit
CDM CDMA Digital Module
CDMA Code Division Multiple Access
CDN Call processing Database Node
CE Channel Element
CMPIFHO CDMA Multiple Pilots Inter-Frequency Handoff
CN Cellular Networking
CTA Customer Technical Advocate
DCS Digital Cellular Switch
ECAM Extended Channel Assignment Message
ECP Executive Cellular Processor
ECU Enhanced Channel Unit
FCH Fundamental Channel
FFER Forward Frame Error Rate
HSPD High Speed Packet Data
IFHOTI Inter-Frequency Handoff Trigger Improvement
IROC Improved Reverse link Overload Control
ISPAGE Intersystem Paging
KPI Key Performance Indicator
LDAT Lucent Data Analysis Tool
MSC Mobile Switching Center
OMP Operation and Management Platform
PN Pseudorandom Noise
PP Packet Pipe
PSMM Pilot Strength Measurement Message
RFER Reverse Frame Error Rate
ROC Reverse link Overload Control

List Of Abbreviations (Con’t)
ROP Read-Only Printer

TCCF Traffic Channel Confirmation Failure
TLDN Temporary Location Directory Number
SCN Special Cellular Networking
SCH Supplemental Channel
SCCM Service Connect Complete Message
SH Speech Handler
SPAT System Performance Analysis Tool
UNL Undeclared Neighbor List
VLR Visitor Location Register

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 #2 – Forward and Reverse Overload Control
and Supplemental Air Resource Allocation
[5] CDMA RF Translation Application Note #3V – Voice Power Control
[6] CDMA RF Translation Application Note #4 – Handoff
[7] CDMA RF Translation Application Note #4D – 3G1X Data Handoff
[8] CDMA RF Translation Application Note #7 – Timing, Delay and Access Parameters
[9] 401-612-221 CDMA Packet Pipe Optimization and Packet Pipe 16
[10] 401-612-429 Backhaul Engineering Enhancement
[11] SRD-1536 CDMA Performance and Capacity Metrics – R18, Issue 7.0
[12] Experiences with SS7 Message Reduction, Registration Control and Paging Version 2.0, M. Dal
Pan, J.D. Newell, December 21, 2000.
[13] CDMA 3G Packet Data – 3G Overview, David A. Welsh, Wireless Development –
CDMA/3G Packet Data, February 2002
[14] Troubleshooting guide for Packet Data
[15] 3G1X RF Optimization Guidelines,
http://rfec.wh.lucent.com/html/cdma/rf_amp_docs.htm
[16] Multi-Carrier Optimization Guidelines for PCS and Cellular CDMA Systems,
http://rfec.wh.lucent.com/html/cdma/rf_amp_docs.htm

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.

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 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 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 (KPI’s).
The details on how this Guide may be used to address each of these requirements are described in
the sections below.

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 (KPI’s). Section 3 lists all the KPI’s that are
common to Voice and Data services, while Section 4 lists the additional KPI’s 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 4. This overview will provide the necessary background
to understand the rest of the detailed discussions on Data-specific KPI’s listed in this section.
With these KPI’s 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 KPI’s.
This is listed in Sections 3 and 4 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 3 and 4 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 3 and 4.
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.

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 is 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 of the 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.

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 (KPI’s). 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 3 lists all the Key Performance Indicators (KPI’s) that are common to Voice and Data,
while Section 4 lists the additional KPI’s that are specific only to Data performance. Included in
Section 4 is some necessary background concepts required to understand the Data-specific KPI’s
listed in this section. A list of possible failure components that constitute failures in KPI
performance are also listed in these sections.
Sections 3 and 4 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 describes 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.

3. VOICE AND DATA KPI OPTIMIZATION AND

TROUBLESHOOTING
Voice Key Performance Indicators (KPI’s) 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 (KPI’s), as will be elaborated upon
in this section. These three KPI’s are:
1) Established Call Rate
2) Frame Error Rate
3) Drop Call Rate
With Data calls, as explained in Section 4, 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 KPI’s 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 KPI’s related to the performance of the network through these SCHs (which only pertain to
Data calls) are discussed in Section 4.
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, where applicable, new upcoming features that will help in improving the KPI
performance are discussed.

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

Established Call Rate = x 100%
Orig. Seiz. + Term. Seiz.
SRD-1536 [11] 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.

3.1.1 RF Access Failure (TCCF) Analysis
3.1.1.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.
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 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.

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 N5m (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 N5m 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 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
are 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.
1
Only the most common TCCF Types are presented in this figure.

3.1.1.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. When the mobile finds another PN of sufficiently greater strength, it will perform an
idle-mode handoff2. 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
number of neighbors in the idle mode was extended to 20, but the default translation will
still be 12 unless explicitly changed.
• 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.
2
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.

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 UNL3
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).
3.1.1.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]).
3.1.1.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
3
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).

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.
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) which 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) which 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) which 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 pathloss (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.
3G mobiles will only hash onto 3G carriers and 2G/3G1X mixed carriers (see Section 4.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 either 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 carrier4. 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.
4
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.

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.
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 are 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 [5]. This reference should be required reading before making
any decisions and optimization based on these algorithms.
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 3.1.1.4.2.

3.1.1.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 channel5 and acquire the null traffic
data that is sent by the cell. Upon successful acquisition6, 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 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:
• 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 causes 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 pathloss 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.
5
In CDMA systems, a traffic channel is a combination of a carrier frequency and Walsh Code.
6
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).

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 UNL7 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.
• 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 3.1.4.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. 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 soft-handoff zones, namely, through physical antenna and attenuation
changes.
7

3.1.1.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 (Figure 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 excessive number of Type 7 TCCFs are 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.
3.1.1.2 Silent Reoriginations
Silent reoriginations 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 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 subsequently be discounted from the origination
seizures, since 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 there is currently no way to track these occurrences.
3.1.1.3 Recent IS95B Enhancements
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.

3.1.1.3.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 can be individually
set to be AEHO-allowed through the fci form. Inter-MSC neighbors are not permitted to be
AEHO-allowed.
3.1.1.3.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 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 IS95A8 neighbors are not permitted to be
AHO-allowed.
3.1.1.3.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 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.
8
An IS95A neighbor is any sector that is configured purely as a 2G cell with p_rev less than 5.

This feature will likely have the strongest positive impact on TCCF performance because the
TCCF Type 2 messages (Acquire Mobile Failure - see Figure 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.
3.1.1.4 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 3.1.1.1 are followed.
3.1.1.4.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
High traffic levels may be identified by examining the traffic erlangs carried by the sectors
exhibiting high TCCF rates. 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.
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.
There are however several dangers with reducing soft-handoff zones, especially if this is 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.
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 may 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.

3.1.1.4.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 3.1.1.1.3.
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 3.1.1.1.3), then there will
likely be several assignments on that border carrier, even without having any seizures.
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 3.1.1.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
feature must be activated to ensure reliable handdowns. See Section 3.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. This results in the different carriers
carrying different loads, thus, potentially causing differences 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
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.
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] 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.
Miscalibrated powers may be easily rectified by performing the calibrations according to

the Methods and Procedures guidelines for the appropriate calibration option. Reference [3]
goes 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 3.1.3.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 a 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.
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 sometimes specific carriers are 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 3.2.2.1.2 discusses this algorithm in
more detail. Reference [5] 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 are 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.
3.1.1.4.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 3.1.1.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 (UNL9) 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.
9

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
concatenated, 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 [15]. This would entail removing that sector
from the area through antenna downtilts, azimuth changes, antenna model changes and/or
BCR/CBR attenuation changes [15].
• 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.
3.1.1.4.4 Excessive Soft-Handoff Zones
As discussed in Section 3.1.1.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.
• Isolate sectors exhibiting high soft-handoff percentage through service measurements.

This is done by examining the primary and secondary CE usage on these sectors. 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 UNL10 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.
10

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 3.1.1.3.
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 are 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.
3.1.1.4.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
[15]. 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.
3.1.1.4.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.
Due to the large number of possible pilots (512 / PILOT_INC), each with a spacing of (64 x
PILOT_INC) chips11, 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.
11
The definition and use of PILOT_INC is discussed under Co-PN Interference later in this section.

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 [5] delves into the details of search windows and should be read before attempting
to optimize these windows.
3.1.1.4.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.
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.
3.1.1.4.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 a 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.
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 [15].
3.1.1.4.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 cell.
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 3.1.3.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.
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 degradations in both TCCFs
and dropped calls.

Typically, the problem may be cleared by restoring the affected hardware elements from the
switch. If this fails to clear the problem, then on-site diagnostics and possible hardware
replacements might be necessary.
3.1.1.4.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) which 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 is notified of the problem.
3.1.1.4.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 which 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.

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 which 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.
3.1.2 Call Setup Failure Analysis
Call setup failures are a catch-all 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 catch-all 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.

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.
3.1.2.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.
3.1.2.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 which 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, the problem may be cleared by restoring the affected CCC from the switch. If this
fails to clear the problem, then on-site diagnostics and possible hardware replacements might
be necessary.
3.1.2.2.2 Call Shutdown Type 10 (CS-[10])
Failed handoffs in the Unanswered state will result in CS-[10]’s which 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.
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 3.2.2 under CP Fail Drops.
3.1.2.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
Checking for the stability of speech handlers and/or software anomalies usually resolved
speech handler failure issues.

3.1.3 CE/PP Resource Blocking Analysis
These failures 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.
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.
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.
3.1.3.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). Each set of 4 CCUs is controlled by a CDMA Cluster Controller
(CCC). Each of these CCCs are 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 [9]).
The relationship between PPs and CEs is provided in [9] 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 3.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 3.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
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 [9]. 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 needs 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 the same
frequency is used by all channels. 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.
3.1.3.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
comes in two forms:
• ECU-32 cards – for Series II cells.
• CCU-32 cards – for Flexent cells.
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).
- 3212 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
12
Typical maximum supported SCH CFs are 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.

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.
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 require 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).
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 3.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 3.2 NUMBER OF CALLS PER SERVICE CLASS FOR VARIOUS PACKET
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
PIPE BANDWIDTHS
3.1.3.1.3 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 3.2.2.2.
3.1.3.1.4 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 3.1.1.4.2) and CP Fail Drops

(Section 3.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 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 [9]and [10].
3.1.3.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.
3.1.3.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. The root cause
may be further narrowed by examining service measurements that are able to isolate just
the PP blocking. 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 3.1.3.2.2 below.
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 3.1.3.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.
For example, looking at Table 3.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 3.1.3.1.4 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.

3.1.3.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 3.1.3.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 which has a component to perform such analysis
(Appendix B provides an overview of this tool).
As this is a cell hardware issue, it is recommended that the customer Operations team is
notified of the problem.
3.1.3.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.
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.
3.1.4 Forward Power Resource Blocking Analysis
3.1.4.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) [4].
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 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.
A more detailed presentation on this topic is presented in [4].
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.
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 3.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.
An important point to understand is that amplifiers entering into the cool-down state will
introduce serious power resource blocking problems for the period of time that it is in cool-
down. 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.

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 units13 (dgu’s) should not exceed 77760, 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 overrriden on a sector-by-sector basis in the ceqface form. This ensures that
the output power remains the same, but changes the relationship between dgu’s and actual
output power to reduce the dgu values used.
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 3.1.1.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.
13
Digital gain units (dgu’s) are a measure of per-channel output power from the base stations. Dgu’s have a square
relationship to the output power (Watts). The actual conversion from dgu’s 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 are subsequently tuned to the desired total power as per the selected calibration option.

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 2G Voice.
Table 3.4 TABLE OF TYPICAL PEAK PRIMARY ERLANG VALUES
Typical Peak Erlangs Typical Peak Erlangs

Erlang-B
Blocking All Mobiles Rate Set 2 All Mobiles Rate Set 1
1% 6.6 12.0
2% 7.4 13.2
3.1.4.1.2 Important Lucent Features and Translations
It is recommended that the following recommendations for translations be followed to ensure

that there are no fundamental problems with the way in which power is utilized by the cells.
• 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 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 the [3] 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 [4].

3.1.4.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] 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 [4] when
attempting to do this because there may be other translations that also have to be changed
in conjunction with these overload thresholds.
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 will be highly likely, in a
growing system, that 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.
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 criteria, 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.
3.1.4.2 Forward Power Resource Blocking Causes and Associated Fixes
3.1.4.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.
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 3.1.4.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 is not an indication of true power capacity problems, but rather
is indicative of some other problem with the cell site configuration and/or hardware. This type
of problem is discussed in detail in Section 3.1.4.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 3.1.4.1.3 should be followed to alleviate
the problem.
As discussed in Section 3.1.4.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.

This is done by examining the primary and secondary usage on these sectors. The ratio of
secondary 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.
14

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 are low when compared to IS95A mobiles, turning on these
features will have negligible impact on the soft-handoff percentage.
3.1.4.2.3 Incorrect Setting of VAF Causes Early Overload
As described in Section 3.1.4.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 3.3).
• 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 3.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.
3.1.4.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.
There are differences in coverage footprints between the various carriers of the sector due to
inconsistent physical antenna configurations on-site. This results in the different carriers
carrying different loads, thus, potentially causing differences in observed overloads.
azimuth and downtilt. Note that, depending on the implementation, it is possible that multiple
carriers may share the same transmit antenna. If this is the case, then this cause may be ruled
out as being the root of the problem.
also possible that the antennas may not be equally affected by physical obstructions on-site. If
this the case, it may be necessary to relocate all the antennas, if adjusting their elevations
and/or azimuths will not clear these barriers.
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 overload durations.
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.).

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 3.1.1.1.3 discusses this algorithm in more
detail. Reference [5] 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. Alternatively, this border sector could converted to a full-traffic sector, if
possible15.
If neither of the above suggestions are effective or appropriate, then consider adding carriers
to the 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.
15
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 [16] for detailed procedures on such
optimization).

Miscalibrated powers may be easily rectified by performing the calibrations according to the
Methods and Procedures guidelines for the appropriate calibration option. Reference [3] goes
into great detail on these options.
Power drift problems may usually be resolved only through hardware replacements.
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 3.1.3.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 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
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, ECU/CCU-32), Packet Pipes (PPs), T1
spans, etc.
Problems related to this cause will result in a sudden performance degradation the moment the
hardware goes out of service. In general, this problem will manifest itself in service
based on 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 sometimes specific carriers are 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.
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 3.1.1.1.3.
3.1.5 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 capacity16.
Note that before IROC, it was recommended that the reverse RF loading resource blocking
algorithm be turned off. This is because the algorithm could not estimate the noise floor
accurately enough resulting in false triggers of reverse power blocking. The reverse algorithm
may be turned off by setting the upper_rev_load to 100% in the ecp/ceqface database forms.
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.
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 number 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 [4].
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 3.1.1.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
16
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.

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 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 2G Voice.
Table 3.5 TABLE OF TYPICAL PEAK PRIMARY ERLANG VALUES
Typical Peak Erlangs Typical Peak Erlangs

Erlang-B
Blocking All Mobiles Rate Set 2 All Mobiles Rate Set 1
1% 6.6 12.0
2% 7.4 13.2
3.1.5.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.
3) 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] for details on this mapping).
1) While not recommended unless as a last resort, the overload thresholds may be increased
to delay when the cells go into overload.
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 will be highly likely, in a
growing system, that 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 criteria, 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.

3.1.5.2 Reverse RF Loading Resource Blocking Causes and Associated Fixes
3.1.5.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 3.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 is not an indication of true power capacity problems, but rather
is indicative of some other problem with the cell site configuration and/or hardware. This type
of problem is discussed in detail in Section 3.1.5.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 3.1.5.1.2 should be followed to alleviate
the problem.
As discussed in Section 3.1.5.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.


This is done by examining the primary and secondary usage on these sectors. The ratio of
secondary 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.
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.
3.1.5.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.
17

There are differences in coverage footprints between the various carriers of the sector due to
inconsistent physical antenna configurations on-site. This results in the different carriers
carrying different loads, thus, potentially causing differences in observed overload durations.
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.
also possible that the antennas may not be equally affected by physical obstructions on-site. If
this the case, it may be necessary to relocate all the antennas, if adjusting their elevations
and/or azimuths will not clear these barriers.
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
reverse overload durations.
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
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 3.1.3.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 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
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, ECU/CCU-32), Packet Pipes (PPs), T1
spans, etc.

Problems related to this cause will result in a sudden performance degradation the moment the
hardware goes out of service. In general, this problem will manifest itself in service
based on 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 3.1.1.1.3.
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 3.1.1.1.3 discusses this algorithm in more
detail. Reference [5] 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. Alternatively, theis border sector could be converted to a full-traffic sector,
if possible18.
If neither of the above suggestions are effective or appropriate, then consider adding carriers
to the 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.
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 [16] for detailed procedures on such
optimization).

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.
FFER equally.
the area and 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.

3.1.6 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 reason why these CN TCCFs occur are just the same as those discussed in Section 3.1.1.
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
3.1.1, 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) which 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.

3.1.7 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 case19.
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
19
Service measurement counters will also miss failures where the mobiles receive the page, but their response was not
successfully received by the network, usually because of RF-related problems.

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 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. [12] 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 are 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.)
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 Registraion 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 Areq/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 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 a customer-perceived service degradation.
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.
3) A reduction in battery life on the mobiles because of the increased transmissions required
to communicate these ARs.
3.1.7.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 3.1.5.
• Activate timer-based registrations on all cells in the system and ensure that the
registration interval is no less than 30 minutes.
• 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. [12] also provides an in-depth study and recommendations on this topic.

3.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 Established Calls
SRD-1536 [11] provides a detailed description of the peg counts and equations used to determine
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 3.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 are
discussed separately in this section, with the understanding that each concept discussed under
either category may also marginally apply to the other.
3.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 for the duration of the Traffic Channel Supervision Interval which is a translatable
parameter (tcsupervsn on the ecp/cell2 database forms). When this loss is detected, the cell
will attempt to audit the mobile up to nine times. 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 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 the 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
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.
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 UNL20
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).
• 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 [15]. 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.
There also exists Lucent 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 3.4) and implement capacity reduction techniques as per
the suggestions in Section 3.1.4.1 under the topic on Forward Power Resource Blocking
Management Techniques. This is especially important if noticeable degradations in drop
call performance is 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 3.1.4.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.
20

For mature systems, the UNL21 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.
The techniques to fix or manage these overshooting sectors is 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.
3.2.1.2 Lost Call Causes and Associated Fixes
3.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
effective in identifying missing neighbor list entries and erroneous priority assignments.
this problem.
21

BCR/CBR attenuation changes.
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
PN Ambiguity Issues
performed.

3.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.
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.
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.
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 this is 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 may 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.
• 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.
3.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:
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.
3.2.1.2.4 Island-Mode Cell
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.
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 indicative of this problem which manifest themselves as HEH messages on the ROP.
3.2.1.2.5 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 3.1.3, 3.1.4 and 3.1.5.

3.2.1.2.6 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 3.2.1.2.1) or hardware blocking (Section 3.2.1.2.5).
It is difficult to identify pilot polluted areas through service measurements. 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 tests would be the most effective ways 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
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.
3.2.1.2.7 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) chips22, 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 [5] delves into the details of search windows and should be read before attempting
to optimize these windows.
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.
22
The definition and use of PILOT_INC is discussed under Co-PN Interference later in this section.

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.
FFER equally.
the area and 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.
3.2.1.2.9 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 a 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 [15].

3.2.1.2.10 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.
3.2.1.2.11 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.

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 range of 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 3.2.1.2.1 (Poorly Defined Neighbor Lists)
• Section 3.2.1.2.10 (Hardware Outages and/or Intermittent Hardware Problems)
• Section 3.2.1.2.12 (Inadvertent Change of Translations)
3.2.1.2.12 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 changes 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.
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.
3.2.2 CP Fail Drops
3.2.2.1.1 General Description
Typically, the largest component of CP Fail Drops are Handoff (HO) Complete Timeouts
which 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 3.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.

The call flow for a semi-soft handoff is presented in Figure 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).
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 2 SEMI-SOFT HANDOFF CALL FLOW
3.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 [5]. 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.
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).
There are two methods to trigger directed inter-frequency handoffs, namely, the Tr_CHo
algorithm and the IFHOTI algorithm. The IFHOTI is an improved mechanism that was
introduced in Release 12.0, but the choice is given to use either algorithm.
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 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 is compared against the Border Sector
Loss Threshold for Inter-frequency Handoff trigger. The creation of the Ec/Io Loss Metric was
motivated by the fact that handing down on an absolute Ec/Io threshold will make the
handdown location dependent on the loading on the network. This is because the Ec/Io
experienced at any location is a function of Io which varies with loading even though received
Ec remains constant. The Ec/Io Loss Metric comparison will take this loading into effect, thus
allowing for the Border Sector Loss Threshold for Inter-frequency Handoff threshold to
determine the location of the handdown, rather than this handdown be based off the absolute
Ec/Io value. For calls that are in simplex mode just before the handoffs, only the Border
Sector Loss Threshold comparison to the Ec/Io Loss Metric is made.
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.
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.
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.
3.2.2.1.3 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 algorithm is used on border sectors, it is imperative that the
IFHOTI algorithm is also employed on those sectors. Section 3.1.1.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 [16].
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 3.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.
3.2.2.2 CP Fail Causes and Associated Fixes
3.2.2.2.1 Poorly Optimized Border Sectors
As discussed in Section 3.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 2 illustrates how this failure condition results
in CP Fail Drops.

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
3.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 3.2.2.1.2, and in [16].
• 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 3.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.
3.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 3.1.1.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
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
3.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 3.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 3.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.
3.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.
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 3.1.3, 3.1.4 and 3.1.5.
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 3.2.2.1.2) discusses the
shotgun feature in detail.
3.3 FCH Frame Error Rate
3.3.1 Concepts and Optimization Techniques
As discussed in Section 3, 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.
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 are discussed in
detail below.

3.3.1.1 Forward Frame Error Rate (FFER)
3.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 [5]) describes these radio configurations, as per the
IS2000 standard.
Table 3.6 2G AND 3G RADIO CONFIGURATIONS
System Type Radio Configuration Vocoder Rate

IS-95 A/B IS-2000
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
3.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 3.6 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 be therefore be calculated as follows:
Number of RS 2 FL Frame Erasures

FFERRS 2 = x 100%
Total Number of RS 2 FL Frames Transmitted
where FL = Forward Link
SRD-1536 [11] provides a detailed description of the peg counts and equations used to
determine 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:
Number of RS 2 FullRate FL Frame Erasures

FullRate FFERRS 2 = x 100%
Total Number of RS 2 FullRate FL Frames Transmitted
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.
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 exceed a specific
number of frames which is 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.
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 do 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.
3.3.1.1.3 FFER Calculation Using PMRM
It is expected that, in future releases, the mechanisms will be in place to generate accurate
FFER service measurement peg counts based on these PMRM messages. There will be
separate settings for how these messages are generated (waiting period, etc.) for 2G RS1 calls
versus calls on other 3G RCs. 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 are 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.
3.3.1.1.4 Optimization Steps for FFER
The optimization steps suggested for FFER will be identical to those recommended to manage
drop calls (Section 3.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 3.2.1 may be referenced for details on optimization recommendations.

3.3.1.2 Reverse Frame Error Rate (RFER)
3.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. All the frames sent by the mobile are captured by the network,
which subsequently evaluates whether these frames are received in error or not. The RFER
may then be computed.
The RFER may be computed precisely for all rate sets, and may be calculated as follows:
Number of RL Frame Erasures of Vocoder VO

RFERVO = 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, 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 which 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 rate 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.
3.3.1.2.2 Optimization Steps for RFER
As with FFER, all of the recommendations for optimizing drop call performance (Section
3.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.
3.3.1.2.3 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 3.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, a 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.
CDMA 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.
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.

4. 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)
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
given duration. For the current release, 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). 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 3 FCH/SCH UTILIZATION FOR TYPICAL WEB BROWSING SESSION
Forward Supplemental Channel (F-SCH) Implementation
With Lucent implementation, SCH can only be transmitted in simplex mode over the downlink.
That is, only a single pilot will set up and transmit 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.
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 that is not
allowed to enter into the Active Set for whatever reason. 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.
SCH Rate Determination
The actual rate that is assigned to the SCH is dependent upon 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. The SCH rate may be further reduced if there is insufficient
backlogged data to justify the computed rate, where this backlogged data will reside in the mobile
for the reverse link, and in the network (5E) elements for the forward link.
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.
Key Performance Indicator – SCH Throughput
All problems with the SCH will ultimately manifest themselves as a degradation in the achieved
SCH Throughput 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 = 2,4,8,16
R
SCH Throughput = x 9.6 kbps

∑ Rx_Frames
R = 2,4,8,16
R
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 a 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-use 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

• 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
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 will not be available until Release 19. 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 IWF Router Server

(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 4 3G1X HIGH SPEED PACKET DATA NETWORK PROTOCOL STACK
4.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 4 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
The following sections examine failure causes and fixes/improvements for each of these
categories in detail.
4.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.
4.1.1.1.1 Overview of SARA
The evaluation of the RF link and subsequent rate allocation is administered by the
Supplemental Air Resource Allocation (SARA) algorithm. 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 [4].
4.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).
2) Excessive pathloss.
Therefore, forward-link optimization for F-SARA would involve making sure the above two
conditions are minimized, especially in areas of expected significant high-speed traffic. The
suggested optimization techniques for each of the two 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.
Minimizing Pathloss
There are several choices for minimizing pathloss by improving coverage problems. They are:

4.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.
Therefore, reverse-link optimization for R-SARA would similarly involve making sure the
above two conditions are minimized. The suggested optimization techniques for each of the
two conditions are discussed below.
Ensuring no Strong Candidate Set Pilots Blocked from Entering Active Set
There are two conditions which 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.
If the problem is with missing neighbor list entries, then these neighbors should be added,
If the problem is with the integrity of the neighbor list, then the appropriate fix should be
Reciprocity

PN Ambiguity Issues
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.
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 3.1.3, 3.1.4 and 3.1.5.
Minimizing Pathloss

4.1.1.2 RF Capacity Related Failure Causes and Suggested Fixes
4.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 metric could be used to estimate the problem (available
with R19). 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.
The suggested fix is ensure 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.
4.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).


4.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 4.1.1.2.1 above, will result in poor rate
assignments.
Handoff Matrix (HOMAX) and the Undeclared Neighbor List (UNL23) features have been
very effective in identifying missing neighbor list entries and erroneous priority assignments.
23

this problem.
Reciprocity
PN Ambiguity Issues

performed.
4.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 4.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 4.1.1.2.1 above, will result in poor rate assignments.
The affected cell site should be generating resource blocking counts in service measurements.
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 3.1.3, 3.1.4 and 3.1.5.

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

4.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) [9].
2) Backhaul Engineering Enhancement [10].
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.
4.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 4.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 4.1.2.1.2.
Table 4.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.

Table 4.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 4.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 4.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.

4.1.2.2 PP Blocking / Rate Reduction Causes and Associated Fixes
4.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).
• 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.
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 3.1.3.1.4 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.
4.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 4.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 which has a component to perform such analysis
(Appendix B provides an overview of this tool).
4.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 are 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.
4.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.
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).
- 3224 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
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.
4.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
24
Typical maximum supported SCH CFs are 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.

CFs per call. Also, for the reverse link, 32 CFs are shared among both FCH and SCH.
Therefore, this should be carefully accounted for when provisioning the CFs.
With the early stages of 3G deployment, 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.
There are two important concepts related to ensuring that the above appropriate allocation of
calls by technology are performed, namely, the Allow Sharing 3G1X Carrier and 2G/3G Load
Preference Deltas features. These concepts are discussed in the next section below.
4.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 carriers25 (see Section 4.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 either 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
25
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.

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

4.1.3.2 CF Blocking / Rate Reduction Failure Causes and Fixes
4.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.
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 4.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 4.1.2.1).

4.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.
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.
4.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.
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.
4.1.4.1.1 Overview of Variable Walsh Spreading Factors
In CDMA systems, a set of orthogonal Walsh Codes are 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 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
Therefore, given that the chip rate is maintained at 1.2288 Mchips/sec for all baseband rates,
therefore the Walsh Code lengths must therefore be modified in inverse proportion to these
baseband data rates.
4.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 limitation26 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.
The following figure illustrates the concept of this blocking when RC3 is used..
26
The maximum number of Walsh codes in 2G networks is 55 = 64-7 (reserved for paging) –1 (reserved for sync) – 1
(reserved for pilot).

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

4.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 not be manipulated. 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 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.
4.1.4.2 Walsh Code Blocking / Rate Reduction Failure Causes and Fixes
4.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
4.1.4.1.2).
There will be direct peg counts with Release 19 that indicates blocking due to lack of Walsh
Codes. The distribution of rate assignments may also be determined through Release 17
counts.
There is no control over how the cell sites assign Walsh Codes to calls. However, if such
blocking is occurring, then one possibility is to offload traffic to neighboring sectors, if
possible. Other traffic offloading techniques discussed in Section 3.1.4.1.3 may also be
applied.
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 [4] discusses
this in more detail.

4.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 4.1.4.1.2).
There will be direct peg counts with Release 19 that indicates blocking due to lack of Walsh
Codes. The distribution of rate assignments may also be determined through Release 17
counts.
There is no control over how the cell sites assign Walsh Codes to calls. However, if such
blocking is occurring, then one possibility is to offload traffic to neighboring sectors, if
possible. Other traffic offloading techniques discussed in Section 3.1.4.1.3 may also be
applied.
Note that limiting the maximum assigned rate will not help in this case because the
fundamental problem is with too many lower rate assignments.
4.2 Excessive Anchor Transfers
4.2.1 Concepts and Optimization Techniques
4.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 concept27. 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.
27
The concept of Anchors do not exist on the reverse link because the R-SCH is combined by all soft-handoff legs of
the call.

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.
4.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.
- Isolate sectors exhibiting high soft-handoff percentage through service
measurements. This is done by examining the primary and secondary usage on these
sectors. The ratio of secondary 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 UNL28 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.
28

These excessive soft-handoff zones may be rduced through a combination of physical

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 the data call will be carried
more often pilots that are not dominant. Therefore, it is preferred to solve the problem in its
roots through RF optimization discussed above.
!3G Inter-Frequency Handoffs

4.3 3G!
4.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.

4.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.
4.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):
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 [16] 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 3.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.
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.
Understanding and resolving cell resource blocking is an involved topic in its own right, and is
discussed in detail in Sections 3.1.3, 3.1.4 and 3.1.5.

!non-3G Handoffs
4.4 3G!
4.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 [5], namely:
• 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 [5].
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.

4.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.
4.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.
• 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 4.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.

4.5 Outages and Errors in the Packet Network

The implementation of HSPD services in 3G networks require several addition 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) [13].
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 [14] 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.

APPENDIX A METRIC CROSS-REFERENCE
Table A.1 Established Call Rate metric cross-reference
Metric_Name Reference Sections

3G to 2G Origination Assigned due to CE Overflow Rate 3.1.3.2
3G to 2G Origination Assigned due to PP Overflow Rate 3.1.3.2
3G to 2G Origination Assigned due to RF Balancing Rate 4.1.1.2
3G to 2G Origination Assigned Overflow Rate 3.1.3.2, 4.1.1.2
3G to 2G Termination Assigned due to CE Overflow Rate 3.1.3.2
3G to 2G Termination Assigned due to PP Overflow Rate 3.1.3.2
3G to 2G Termination Assigned due to RF Balancing Rate 4.1.1.2
3G to 2G Termination Assigned Overflow Rate 3.1.3.2, 4.1.1.2
Analog Redirection Rate 3.1.3, 3.1.4
3.1.1.4.1, 3.1.4.2.1, 3.2.1.2.2,
Average Number of CEs (per Hour) 3.1.3.2.1, 4.1.1.2.4
Average Number of Primary CEs (per Hour) 3.1.1.4.4, 3.1.1.4.1
Average Number of Walsh Codes (per Hour) 3.1.1.4.1
Established Call Rate 3.1
Established Call Rate for Origination 3.1
Established Call Rate for Termination 3.1
Established Calls 3.1.1.4.1
Handoff Blocking Rate due to CE/PP Overflow 3.1.3, 3.2.1.2.5
Handoff Blocking Rate due to Power Control Overload Rate 3.1.4, 3.2.1.2.5
Orig & Term Block Rate due to CE Overflow 3.1.3.2
Orig & Term Block Rate due to CE/PP Overflow 3.1.3.2
Orig & Term Block Rate due to FWD/REV Power Overload 3.1.4.2
Orig & Term Block Rate due to PP Overflow 3.1.3.2
Origination Assignment 3.1.1.4.1
Origination Blocking 3.1.3, 3.1.4
Origination RF Failure Rate 3.1.1.4
Origination Seizure 3.1.1.4.1
Page Response Seizure 3.1.1.4.1
Primary CE Usage Fraction 3.1.1.4.4, 3.1.1.4.1
Secondary CE Usage Fraction 3.1.1.4.4
Silent Re-Origination Rate 3.1.1.2
Speech handler Failure Rate 3.1.2.2.3
Termination Assignment 3.1.1.4.1
Termination Blocking 3.1.3, 3.1.4
Termination RF Failure Rate 3.1.1.4
Total Assignment 3.1.1.4.1
Total Blocking 3.1.3, 3.1.4
Total Seizure 3.1.1.4.1
Undeclared Neighbor HO Failure Rate 3.2.1.2.1, 3.1.1.4.3
Voice Mail Redirection Rate 3.1.7

Table A.2 Drop Call rate metric cross-reference

3G to 2G SemiSoft Handoff Blocking Rate 3.2.1.2.5
Call Shutdown Rate 3.2.2.2
Drop Call Rate 3.2
Hard Handoff Order-Complete Failure Rate 3.2.2.2
Hard Handoff Request-Complete Failure Rate 3.2.1.2.5, 3.1.3, 3.1.4, 3.2.2.2
Hard Handoff Request-Order Failure Rate 3.2.1.2.5, 3.1.3, 3.1.4
Island 3.2.1.2.4
Lost Call Rate 3.2.1.2
Soft Handoff Order-Complete Failure Rate 3.2.2.2
Soft Handoff Request-Complete Failure Rate 3.2.1.2.5, 3.1.3, 3.2.2.2, 3.1.4
Soft Handoff Request-Order Failure Rate 3.2.1.2.5, 3.1.3, 3.1.4
Table A.3 Frame Error Rate metric cross-reference

Aggregate Frame Error Rate on Forward Channel (FFER) 3.3.1.1
Frame Error Rate on Reverse Channel (RFER) 3.3.1.2.2, 3.3.1.2.3
Full Rate Frame Error Rate on Forward Channel (FFER) 3.3.1.1
Table A.4 Packet Data metric cross-reference

3G Forward Data Burst Rate 4.1
3G Forward Supplemental Channel Priority Release Rate 4.1
3G Reverse Data Burst Rate 4.1
3G Reverse Supplemental Channel Priority Release Rate 4.1

APPENDIX B O V E RV I E W O F S PAT TO O L
System Performance Analysis Tool 3G (SPAT3G) is a PC-based tool that is designed for rapid
troubleshooting, system performance analysis and RF optimization. SPAT3G has the ability to
analyze Service Measurements (SM), ROP, Translations, Neighbor list and Handoff Matrix
(HOM) data simultaneously. SPAT3G supports ECP release 18 and beyond. For markets with
ECP release 17 or lower, SPATv17 should be used.
SPAT3G structure
There are two components in SPAT3G – the OMP scripts and the PC GUI tool. The OMP scripts
have to be installed on the OMP to collect SM, ROP, Translations and HOM data on a daily
basis. 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 and HOM data that was collected for
that day. The naming convention used for the zipped file is ECP-Number_yyyymmdd.sp (e.g.
1_20020715.sp).
The sp file needs to be downloaded to the PC from the OMP everyday for further analysis. The
PC portion of the SPAT3G tool processed the sp file(s) along with the cells information (e.g.
cells.txt or cells.mdb from LCAT) and Street maps and creates a SPAT3G database. This
database is used in displaying the SM performance metrics, ROP analysis, Translations summary,
FCIAlert analysis and Handoff Matrix analysis. The cells information and street maps can be
combined into a “GeoScheme” in SPAT3G which can be re-used to create multiple SPAT
databases for the same market (e.g. one database for each month of the year). The next few
sections explain the different types of analyses that are available with SPAT3G 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
SPAT3G 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 calculations. 2G and 3G
performance metrics are available for Voice and Data separately.
Figure B1 shows the executive summary of SPAT3G. The executive summary shows key
performance metrics on a per system level for the whole day (24-hour) and/or for the busy hour
for each day for which SM data is available. 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 SPAT3G. For example, Lost Call rate and Call Shutdown rate metrics are
available under the Drop Call tab in SPAT3G.

Figure B1: SPAT3G Executive Summary window

Figure B2: SPAT3G performance metrics on a per cell level
Figure B2 shows the per cell level view of a certain metric. Double-clicking on any grid opens
up a definitions window for the peg count or the metric. The formula used for the calculation of
the metric is available in as part of the display window along with the threshold that is used to
color-code the metric. SPAT3G metrics are also available in map view format. Figure B3 shows
one such example of a performance metrics on a map. Each cell/sector is color-coded according
the value of the metric that is being displayed.
SM metrics and peg counts can also trended if data from multiple days is available. Figure B4
shows multiple metrics as a trend for about a month’s worth of data.

Figure B3: Map view of SM metrics
Figure B4: Performance metric and peg count trending

ROP Analysis
SPAT3G analysis of ROP data is done on a per system and per cell level. 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.
Figure B5 shows the system level view of Call Processing Failures.
Figure B5: ROP analysis display in SPAT3G

Translations Summary
The existing translations settings for a system can be viewed using SPAT3G. As part of the OMP
scripts, SPAT3G picks up the TRX file that is generated on the OMP. The TRX file contains the
translations settings from all the database forms and for all cell/sectors in the system.
SPAT3G color-codes any translation setting that is different from Lucent recommended values.
Comparison of this setting can also be made against specific user-set values also 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. Figure B6 shows a sample translations summary window with a definition
window.
Figure B6: Sample translations summary display

FCIAlert Analysis
FCIAlert tool is now available from within SPAT3G. 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 has now been eliminated. The different types of
warnings that are generated include Reciprocity alert, and one-way and two-way PN ambiguity
alerts.
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.
Handoff Matrix Analysis
Analysis of Handoff Matrix data is also possible with SPAT3G. 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.
Other features in SPAT3G
There are other features in SPAT3G 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, SPAT3G can also be used to view translations
summary and perform FCIAlert and Handoff Matrix analysis.
Any table that is displayed in SPAT3G can also be exported as a comma-delimited file. This file
can then be used for further analysis if the need exists. SPAT3G 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.
User preferences can be set from the “Preferences” menu option. Some examples of preferences
are setting working directory, custom ranges for maps, adding new translations field for display,
and setting handoff matrix threshold.
A detailed SPAT3G presentation is available as a course (LTW453Y) from the Wireless

University website (http://wirelessu.lucent.com).

RF Troubleshooting Guide

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

RF Troubleshooting Guide

Caricato da

Copyright:

Formati disponibili

Lucent Technologies

Bell Labs Innovations

RF P ERFORMANCE ANALYSIS AND TOOLS

LUCENT TECHNOLOGIES PROPRIETARY

2. USING THIS GUIDE ............................................................................................................................. 9

LUCENT T ECHNOLOGIES P ROPRIETARY

3.1.3.1.4 CE/PP Resource Blocking Management Techniques ................................................ 50

LUCENT T ECHNOLOGIES P ROPRIETARY 2

3.3 FCH FRAME ERROR RATE ..................................................................................................103

LUCENT T ECHNOLOGIES P ROPRIETARY 3

4.3 3G!3G INTER-FREQUENCY HANDOFFS..........................................................................138

APPENDIX B OVERVIEW OF SPAT TOOL................................................................................ 145

FIGURE 2 SEMI-SOFT HANDOFF CALL FLOW................................................................... 96

FIGURE 5 RC3 WALSH CODE TREE..................................................................................... 134

LUCENT T ECHNOLOGIES P ROPRIETARY 4

AOC Aggregate Overload Control

LUCENT T ECHNOLOGIES P ROPRIETARY 5

List Of Abbreviations (Con’t)

ROP Read-Only Printer

LUCENT T ECHNOLOGIES P ROPRIETARY 6

LUCENT T ECHNOLOGIES P ROPRIETARY 7

• Base station hardware failures (including intermittent problems)

LUCENT T ECHNOLOGIES P ROPRIETARY 8

2. USING THIS GUIDE

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

LUCENT T ECHNOLOGIES P ROPRIETARY 9

2.1 Using the Guide for System-Level Troubleshooting and Analysis

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

LUCENT T ECHNOLOGIES P ROPRIETARY 10

2.2 Using the Guide for Troubleshooting Specific CDMA Performance

LUCENT T ECHNOLOGIES P ROPRIETARY 11

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

LUCENT T ECHNOLOGIES P ROPRIETARY 12

3. VOICE AND DATA KPI OPTIMIZATION AND

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

1) Established Call Rate

2) Frame Error Rate

3) Drop Call Rate

LUCENT T ECHNOLOGIES P ROPRIETARY 13

3.1 Established Call Rate

(Orig. Seiz. − Orig. Failures) + (Term. Seiz. − Term. Failures)

• RF Access Failures (TCCFs)

LUCENT T ECHNOLOGIES P ROPRIETARY 14

3.1.1 RF Access Failure (TCCF) Analysis

3.1.1.1 Concepts and Optimization Techniques

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

LUCENT T ECHNOLOGIES P ROPRIETARY 15

MS Cell Site CDN DCS

Origination Message on Access Channel

Base Station Ack on Paging Channel

Cell Null Traffic Data

Channel Assignment on Paging Channel

Mobile Traffic Preamble on Acquiring TC1 TCCF Type 2

Mobile Null Traffic Speech Handler Assignment

Frame Selector Assignment

Service Connect Message on Traffic Chan

Service Connect Complete on Traffic Chan TCCF Type 3

Figure 1 IS95A ORIGINATION CALL FLOW1

LUCENT T ECHNOLOGIES P ROPRIETARY 16