Professional Documents
Culture Documents
RF Troubleshooting Guide Lucent PDF
RF Troubleshooting Guide Lucent PDF
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
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
LUCENT
T ECHNOLOGIES P ROPRIETARY
3.1.5.2 Reverse RF Loading Resource Blocking Causes and Associated Fixes ....................... 70
3.1.5.2.1
3.1.5.2.2
3.1.5.2.3
3.1.5.2.4
General Description.................................................................................................. 95
Inter-Frequency Semi-Soft Handoff Concepts........................................................... 96
Optimization Steps for Reducing CP Fail Drops ...................................................... 99
LUCENT
T ECHNOLOGIES P ROPRIETARY
4.1.1.2 RF Capacity Related Failure Causes and Suggested Fixes ......................................... 119
4.1.1.2.1
4.1.1.2.2
4.1.1.2.3
4.1.1.2.4
4.1.4.2 Walsh Code Blocking / Rate Reduction Failure Causes and Fixes ............................. 135
4.1.4.2.1
4.1.4.2.2
LUCENT
T ECHNOLOGIES P ROPRIETARY
APPENDIX B
List of Tables
TABLE 3.1
TABLE 3.2
TABLE 3.3
TABLE 3.4
TABLE 3.5
TABLE 3.6
TABLE 4.1
List of Figures
FIGURE 1
FIGURE 2
FIGURE 3
FIGURE 4
FIGURE 5
LUCENT
T ECHNOLOGIES P ROPRIETARY
List Of Abbreviations
AOC
AR
Autonomous Registration
CAM
CCC
CCU
CDM
CDMA
CDN
CE
Channel Element
CMPIFHO
CN
Cellular Networking
CTA
DCS
ECAM
ECP
ECU
FCH
Fundamental Channel
FFER
HSPD
IFHOTI
IROC
ISPAGE
Intersystem Paging
KPI
LDAT
MSC
OMP
PN
Pseudorandom Noise
PP
Packet Pipe
PSMM
RFER
ROC
LUCENT
T ECHNOLOGIES P ROPRIETARY
Read-Only Printer
TCCF
TLDN
SCN
SCH
Supplemental Channel
SCCM
SH
Speech Handler
SPAT
UNL
VLR
LUCENT
T ECHNOLOGIES P ROPRIETARY
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
LUCENT
T ECHNOLOGIES P ROPRIETARY
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:
Poor RF environment
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.
LUCENT
T ECHNOLOGIES P ROPRIETARY
The details on how this Guide may be used to address each of these requirements are described in
the sections below.
LUCENT
T ECHNOLOGIES P ROPRIETARY
LUCENT
T ECHNOLOGIES P ROPRIETARY
10
LUCENT
T ECHNOLOGIES P ROPRIETARY
11
LUCENT
T ECHNOLOGIES P ROPRIETARY
12
LUCENT
T ECHNOLOGIES P ROPRIETARY
13
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:
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.
LUCENT
T ECHNOLOGIES P ROPRIETARY
14
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.
LUCENT
T ECHNOLOGIES P ROPRIETARY
15
MS
Cell Site
CDN
DCS
TCCF Type 2
Channel2
TCCF Type 1
TCCF Type 3
Mobile acquires traffic channel when it detects N5m (typically 2) good null traffic frames within T 50m seconds (typically 200/1000ms = 10-50 frames)
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)
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.
Only the most common TCCF Types are presented in this figure.
LUCENT
T ECHNOLOGIES P ROPRIETARY
16
3.1.1.1.1
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 Bs neighbor list, then
sector B should also be in sector As 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.
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.
LUCENT
T ECHNOLOGIES P ROPRIETARY
17
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.
3.1.1.1.2
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).
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
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).
LUCENT
T ECHNOLOGIES P ROPRIETARY
18
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
LUCENT
T ECHNOLOGIES P ROPRIETARY
19
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 crosscarrier 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 crosscarrier 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.
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.
LUCENT
T ECHNOLOGIES P ROPRIETARY
20
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.
Scenario 2: 2G mobile originates on F2
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.
Scenario 3: 3G mobile originates on F1
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 crosscarrier TCCFs. This can be done in one of two ways:
-
If cross-carrier assignments do occur, then minimize the failures that result from
these assignments.
LUCENT
T ECHNOLOGIES P ROPRIETARY
21
3.1.1.1.4
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.
In CDMA systems, a traffic channel is a combination of a carrier frequency and Walsh Code.
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).
LUCENT
T ECHNOLOGIES P ROPRIETARY
22
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.
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
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).
LUCENT
T ECHNOLOGIES P ROPRIETARY
23
3.1.1.1.5
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 Providers 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
LUCENT
T ECHNOLOGIES P ROPRIETARY
24
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
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, softhandoff 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.
LUCENT
T ECHNOLOGIES P ROPRIETARY
25
3.1.1.3.1
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.
An IS95A neighbor is any sector that is configured purely as a 2G cell with p_rev less than 5.
LUCENT
T ECHNOLOGIES P ROPRIETARY
26
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
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
LUCENT
T ECHNOLOGIES P ROPRIETARY
27
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 isnt 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.
LUCENT
T ECHNOLOGIES P ROPRIETARY
28
LUCENT
T ECHNOLOGIES P ROPRIETARY
29
approximately equal, but there are great disparities in their proportions on a carrier-bycarrier 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 1s 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.
Suggested Fixes for Improvement
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.
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.
LUCENT
T ECHNOLOGIES P ROPRIETARY
30
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.
LUCENT
T ECHNOLOGIES P ROPRIETARY
31
LUCENT
T ECHNOLOGIES P ROPRIETARY
32
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 trafficequipped 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:
LUCENT
T ECHNOLOGIES P ROPRIETARY
33
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.
9
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).
LUCENT
T ECHNOLOGIES P ROPRIETARY
34
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.
Suggested Fixes for Improvement
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 Bs neighbor list, then
sector B is also in sector As 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 twoway 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.
LUCENT
T ECHNOLOGIES P ROPRIETARY
35
Cross-Face Neighbors
At a minimum, each sector must have all other sectors in the same cell as neighbors.
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.
Failure Symptoms and Identification Techniques
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
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).
LUCENT
T ECHNOLOGIES P ROPRIETARY
36
LUCENT
T ECHNOLOGIES P ROPRIETARY
37
11
The definition and use of PILOT_INC is discussed under Co-PN Interference later in this section.
LUCENT
T ECHNOLOGIES P ROPRIETARY
38
LUCENT
T ECHNOLOGIES P ROPRIETARY
39
LUCENT
T ECHNOLOGIES P ROPRIETARY
40
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].
LUCENT
T ECHNOLOGIES P ROPRIETARY
41
LUCENT
T ECHNOLOGIES P ROPRIETARY
42
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.
Failure Symptoms and Identification Techniques
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 markets
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 percell 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.
Suggested Fixes for Improvement
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
3.1.2.1
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.
LUCENT
T ECHNOLOGIES P ROPRIETARY
43
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
Given below are the commonly encountered types of Call Shutdowns that result in call setup
failures being pegged in service measurements.
LUCENT
T ECHNOLOGIES P ROPRIETARY
44
LUCENT
T ECHNOLOGIES P ROPRIETARY
45
3.1.3
3.1.3.1
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
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.
LUCENT
T ECHNOLOGIES P ROPRIETARY
46
Table 3.1
LUCENT
T ECHNOLOGIES P ROPRIETARY
47
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.
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).
Each of the FCH CFs can support any one of the following service classes:
-
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.
LUCENT
T ECHNOLOGIES P ROPRIETARY
48
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.
LUCENT
T ECHNOLOGIES P ROPRIETARY
49
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
3
1
3
2
3
1
3
2
5
8
2
8
5
6
4
7
5
10
14
3
14
10
11
7
12
9
15
19
4
19
14
13
9
17
13
19
25
5
25
18
17
12
23
17
25
31
6
31
22
22
16
28
21
31
37
7
37
27
26
19
34
26
37
42
8
42
31
30
21
38
29
42
48
9
48
35
34
24
44
33
48
54
10
54
40
38
27
50
38
54
60
11
60
44
43
31
55
42
60
66
12
66
48
47
34
61
46
66
72
13
72
53
51
37
66
50
72
78
14
78
57
56
40
72
54
78
84
15
84
62
60
43
77
59
84
90
16
90
66
64
46
83
63
90
PIPE BANDWIDTHS
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
LUCENT
T ECHNOLOGIES P ROPRIETARY
50
(Section 3.2.2.2). While this suggestion doesnt 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 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.
LUCENT
T ECHNOLOGIES P ROPRIETARY
51
LUCENT
T ECHNOLOGIES P ROPRIETARY
52
LUCENT
T ECHNOLOGIES P ROPRIETARY
53
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.
Suggested Fixes for Improvement
As this is a cell hardware issue, it is recommended that the customer Operations team is
notified of the problem.
3.1.4
3.1.4.1
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
LUCENT
T ECHNOLOGIES P ROPRIETARY
54
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.
LUCENT
T ECHNOLOGIES P ROPRIETARY
55
The table below gives the valid settings for this translation and their corresponding scaling
factors.
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 cooldown. 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.
LUCENT
T ECHNOLOGIES P ROPRIETARY
56
13
Digital gain units (dgus) are a measure of per-channel output power from the base stations. Dgus have a square
relationship to the output power (Watts). The actual conversion from dgus to output power in Watts is established
during power calibration. The overhead and traffic channels are set to pre-defined dgu values and the combined output
power from these channels are subsequently tuned to the desired total power as per the selected calibration option.
LUCENT
T ECHNOLOGIES P ROPRIETARY
57
1%
6.6
12.0
2%
7.4
13.2
Erlang-B
Blocking
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 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].
LUCENT
T ECHNOLOGIES P ROPRIETARY
58
LUCENT
T ECHNOLOGIES P ROPRIETARY
59
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.
3.1.4.2
LUCENT
T ECHNOLOGIES P ROPRIETARY
60
14
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).
LUCENT
T ECHNOLOGIES P ROPRIETARY
61
LUCENT
T ECHNOLOGIES P ROPRIETARY
62
conceivable that some sectors may authentically only be able to support much lower
erlangs despite the fact that the overload scalars are maximized.
Suggested Fixes for Improvement
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.
LUCENT
T ECHNOLOGIES P ROPRIETARY
63
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).
LUCENT
T ECHNOLOGIES P ROPRIETARY
64
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.
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 differences in
carried traffic observed, it must be true that the carrier with the lower number of trafficequipped 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
measurements in a very similar manner to when the cell is authentically out of trafficequipped 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. 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.
LUCENT
T ECHNOLOGIES P ROPRIETARY
65
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
3.1.5.1
3.1.5.1.1
Conceptual Overview
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
LUCENT
T ECHNOLOGIES P ROPRIETARY
66
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.
LUCENT
T ECHNOLOGIES P ROPRIETARY
67
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.
1%
6.6
12.0
2%
7.4
13.2
Erlang-B
Blocking
LUCENT
T ECHNOLOGIES P ROPRIETARY
68
LUCENT
T ECHNOLOGIES P ROPRIETARY
69
3.1.5.2
LUCENT
T ECHNOLOGIES P ROPRIETARY
70
17
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).
LUCENT
T ECHNOLOGIES P ROPRIETARY
71
LUCENT
T ECHNOLOGIES P ROPRIETARY
72
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 trafficequipped 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. 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.
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.
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.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).
LUCENT
T ECHNOLOGIES P ROPRIETARY
73
LUCENT
T ECHNOLOGIES P ROPRIETARY
74
3.1.6
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 MSCs 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.
LUCENT
T ECHNOLOGIES P ROPRIETARY
75
3.1.7
3.1.7.1.1
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.
LUCENT
T ECHNOLOGIES P ROPRIETARY
76
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 zonebased 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 TimeBased 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.
LUCENT
T ECHNOLOGIES P ROPRIETARY
77
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 backand-forth between zones, causing a tremendous increase in registration activity on these zoneboundary 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 As timer expires, it will be removed from the mobiles
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:
LUCENT
T ECHNOLOGIES P ROPRIETARY
78
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.
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 markets registration
configuration. [12] also provides an in-depth study and recommendations on this topic.
LUCENT
T ECHNOLOGIES P ROPRIETARY
79
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
3.2.1.1
Lost Calls
Concepts and Optimization Techniques
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
LUCENT
T ECHNOLOGIES P ROPRIETARY
80
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.
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 Bs neighbor list, then
sector B should also be in sector As 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
LUCENT
T ECHNOLOGIES P ROPRIETARY
81
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.
20
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).
LUCENT
T ECHNOLOGIES P ROPRIETARY
82
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
21
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).
LUCENT
T ECHNOLOGIES P ROPRIETARY
83
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.
Suggested Fixes for Improvement
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.
If the problem is with the integrity of the neighbor list, then the appropriate fix should be
applied. Given below are important integrity checks that must be performed on neighbor
lists. The FCIAlert tool will perform all of the following integrity checks and more, but the
most important ones are listed below.
Reciprocity
Reciprocity refers to making sure that if sector A is added to sector Bs neighbor list, then
sector B is also in sector As 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 twoway 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.
LUCENT
T ECHNOLOGIES P ROPRIETARY
84
Cross-Face Neighbors
At a minimum, each sector must have all other sectors in the same cell as neighbors.
LUCENT
T ECHNOLOGIES P ROPRIETARY
85
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 isnt 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.
LUCENT
T ECHNOLOGIES P ROPRIETARY
86
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
LUCENT
T ECHNOLOGIES P ROPRIETARY
87
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 softhandoff activity with any surrounding cell site.
Suggested Fixes for Improvement
If a cell is determined to be in island-mode, then the instructions presented in Fax Flash #98269 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.
LUCENT
T ECHNOLOGIES P ROPRIETARY
88
LUCENT
T ECHNOLOGIES P ROPRIETARY
89
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.
Failure Symptoms and Identification Techniques
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.
Suggested Fixes for Improvement
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.
The definition and use of PILOT_INC is discussed under Co-PN Interference later in this section.
LUCENT
T ECHNOLOGIES P ROPRIETARY
90
LUCENT
T ECHNOLOGIES P ROPRIETARY
91
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.
Failure Symptoms and Identification Techniques
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.
Suggested Fixes 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].
LUCENT
T ECHNOLOGIES P ROPRIETARY
92
LUCENT
T ECHNOLOGIES P ROPRIETARY
93
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:
LUCENT
T ECHNOLOGIES P ROPRIETARY
94
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 Providers Operations team should be contacted if these files
need to be viewed.
Suggested Fixes for Improvement
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
3.2.2.1
CP Fail Drops
Concepts and Optimization Techniques
LUCENT
T ECHNOLOGIES P ROPRIETARY
95
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
Handoff Completion
Handoff Completion
LUCENT
T ECHNOLOGIES P ROPRIETARY
96
LUCENT
T ECHNOLOGIES P ROPRIETARY
97
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 sectors 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
LUCENT
T ECHNOLOGIES P ROPRIETARY
98
neighbor list entries of all the border sectors. The actual number of pilots that can be in softhandoff 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 interfrequency 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 interfrequency 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.
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
LUCENT
T ECHNOLOGIES P ROPRIETARY
99
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
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.
LUCENT
T ECHNOLOGIES P ROPRIETARY
100
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.
LUCENT
T ECHNOLOGIES P ROPRIETARY
101
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.
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.
LUCENT
T ECHNOLOGIES P ROPRIETARY
102
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.
Failure Symptoms and Identification Techniques
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.
Suggested Fixes for Improvement
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 InterFrequency Semi-Soft Handoff Concepts earlier in this section (Section 3.2.2.1.2) discusses the
shotgun feature in detail.
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.
LUCENT
T ECHNOLOGIES P ROPRIETARY
103
3.3.1.1
3.3.1.1.1
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
System Type
Radio Configuration
IS-95 A/B
Vocoder Rate
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
3G1X
N/A
RC4
RC3
8 kbps
3G1X
N/A
RC5
RC4
13 kbps
LUCENT
T ECHNOLOGIES P ROPRIETARY
104
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:
FFERRS 2 =
FullRate FFERRS 2 =
LUCENT
T ECHNOLOGIES P ROPRIETARY
105
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.
LUCENT
T ECHNOLOGIES P ROPRIETARY
106
3.3.1.2
RFERVO =
LUCENT
T ECHNOLOGIES P ROPRIETARY
107
performance to fine-tune the Eb/No Setpoint to be used by all the base stations in the innerloop.
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, halfrate, 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.
LUCENT
T ECHNOLOGIES P ROPRIETARY
108
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.
External interference may be verified by using a spectrum analyzer to scan the affected
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.
LUCENT
T ECHNOLOGIES P ROPRIETARY
109
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.
LUCENT
T ECHNOLOGIES P ROPRIETARY
110
Dormant
First
Data
Arrived
at IWF
38.4
Active
Dormant
Supplemental
Channel
Bursts
153.6
SCH
153.6
SCH
76.8
SCH
76.8
SCH
76.8
SCH
Access
Time
Download
Network
Time
Delay Queuing Delay
( incl. SCH Setup Delay)
Figure 3
9.6 FCH
Start
Reading
Web Page
Mouse
Click
153.6
SCH
Mouse
Click
Fundamental
Channels
Dormancy Timer
Duration
"Think" Time
LUCENT
T ECHNOLOGIES P ROPRIETARY
111
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:
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
Rx_Frames
SCH Throughput =
R = 2,4,8,16
x 9.6 kbps
R = 2,4,8,16
where Rx_FramesR=2,4,8,16 refers to the total number of received frames of rate 2X, 4X, 8X and
16X respectively on the link under investigation.
All problems with data transfers will ultimately manifest itself as 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.
LUCENT
T ECHNOLOGIES P ROPRIETARY
112
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:
3G!non-3G Handoffs
LUCENT
T ECHNOLOGIES P ROPRIETARY
113
PCF
PDSN
Acctg.
& Auth.
AAA
PP
Laptop
(Client)
Mobile
(Terminal)
BS
L-interf.
MSC
IP
IP
Internet
Router
IWF
Server
APP
APP
TCP
UDP
TCP
UDP
IP
IP
PPP
PPP
Low-Level
Low-Level
Interface
Interface
Client
RLP
IS2000
Terminal
IS2000
BS
PP
RLP
FR
FR
PP
T1
T1
MSC
L2
L2
L1
L1
IP
WAN
IWF
Router
WAN
Server
LUCENT
T ECHNOLOGIES P ROPRIETARY
114
There will therefore be four possible failure categories corresponding to each of these four
resource managers, namely:
The following sections examine failure causes and fixes/improvements for each of these
categories in detail.
4.1.1
4.1.1.1
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.
Average reverse pilot Ec/Io of all data calls on each soft-handoff leg (used to determine
current loading).
LUCENT
T ECHNOLOGIES P ROPRIETARY
115
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 indepth descriptions of this algorithm may be found in [4].
4.1.1.1.2
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/Ios).
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:
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. 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.
LUCENT
T ECHNOLOGIES P ROPRIETARY
116
4.1.1.1.3
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.
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.
If the problem is with the integrity of the neighbor list, then the appropriate fix should be
applied. Given below are important integrity checks that must be performed on neighbor
lists. The FCIAlert tool will perform all of the following integrity checks and more, but the
most important ones are listed below.
Reciprocity
Reciprocity refers to making sure that if sector A is added to sector Bs neighbor list, then
sector B is also in sector As 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.
LUCENT
T ECHNOLOGIES P ROPRIETARY
117
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 twoway 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.
Handoff sector is resource blocking on all carriers. If this is the case, then the Candidate
sector will be rejected from entering into the Active Set since that sector will not have any
resources to support the traffic channel.
The solution to this problem is to solve the cell resource blocking problem. Cell resource
blocking can come either in the form of hardware resource blocking or power resource
blocking. Understanding and resolving cell resource blocking is an involved topic in its
own right, and is discussed in detail in Sections 3.1.3, 3.1.4 and 3.1.5.
Minimizing Pathloss
There are several choices for minimizing pathloss by improving 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. 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.
LUCENT
T ECHNOLOGIES P ROPRIETARY
118
4.1.1.2
4.1.1.2.1
LUCENT
T ECHNOLOGIES P ROPRIETARY
119
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.
Suggested Fixes for Improvement
There are several choices for minimizing pathloss by improving 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. 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.
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).
LUCENT
T ECHNOLOGIES P ROPRIETARY
120
Problems with the neighbor lists may also be captured through integrity and consistency
testing of the neighbor list using tools such as FCIAlert. This tool captures a variety of
problems such as non-reciprocal neighbors and PN ambiguities within the neighbor list.
The SPAT tool explained in Appendix B may be used to quickly identify sectors exhibiting
this problem.
Alternatively, neighbor list problems may also be identified through drive tests. This method
however is generally more expensive and less reliable, since it will be difficult to drive all
areas of typical usage to capture all neighbor list problems. However, there is little choice but
to use drive tests for greenfield (new) deployments, since switch-based neighbor list
management tools lack the traffic to make them statistically reliable.
Suggested Fixes for Improvement
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.
If the problem is with the integrity of the neighbor list, then the appropriate fix should be
applied. Given below are important integrity checks that must be performed on neighbor
lists. The FCIAlert tool will perform all of the following integrity checks and more, but the
most important ones are listed below.
Reciprocity
Reciprocity refers to making sure that if sector A is added to sector Bs neighbor list, then
sector B is also in sector As 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 twoway PN ambiguity problems (for any combination of two neighbor lists) up to n-way
LUCENT
T ECHNOLOGIES P ROPRIETARY
121
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.
LUCENT
T ECHNOLOGIES P ROPRIETARY
122
4.1.2
4.1.2.1
4.1.2.1.1
Conceptual Overview
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.
LUCENT
T ECHNOLOGIES P ROPRIETARY
123
LUCENT
T ECHNOLOGIES P ROPRIETARY
124
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
3
1
3
2
3
1
3
2
5
8
2
8
5
6
4
7
5
10
14
3
14
10
11
7
12
9
15
19
4
19
14
13
9
17
13
19
25
5
25
18
17
12
23
17
25
31
6
31
22
22
16
28
21
31
37
7
37
27
26
19
34
26
37
42
8
42
31
30
21
38
29
42
48
9
48
35
34
24
44
33
48
54
10
54
40
38
27
50
38
54
60
11
60
44
43
31
55
42
60
66
12
66
48
47
34
61
46
66
72
13
72
53
51
37
66
50
72
78
14
78
57
56
40
72
54
78
84
15
84
62
60
43
77
59
84
90
16
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.
LUCENT
T ECHNOLOGIES P ROPRIETARY
125
4.1.2.2
LUCENT
T ECHNOLOGIES P ROPRIETARY
126
4.1.3
4.1.3.1
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
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:
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:
LUCENT
T ECHNOLOGIES P ROPRIETARY
127
32 Forward FCH CFs (Supports F-FCH, Paging, Quick Paging and Pilot channels).
Each of the FCH CFs can support any one of the following service classes:
-
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.
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.
LUCENT
T ECHNOLOGIES P ROPRIETARY
128
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.
LUCENT
T ECHNOLOGIES P ROPRIETARY
129
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.
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.
Scenario 2: 2G mobile originates on F2
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.
Scenario 3: 3G mobile originates on F1
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.
LUCENT
T ECHNOLOGIES P ROPRIETARY
130
4.1.3.2
LUCENT
T ECHNOLOGIES P ROPRIETARY
131
4.1.4
4.1.4.1
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
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.
LUCENT
T ECHNOLOGIES P ROPRIETARY
132
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.
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).
LUCENT
T ECHNOLOGIES P ROPRIETARY
133
64 1x
Walsh
Codes
32 2x
Walsh
Codes
16 4x
Walsh
Codes
8 8x 4 16x
Walsh Walsh
Codes Codes
16x SCH
8x SCH
4x SCH
paging
channel
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.
LUCENT
T ECHNOLOGIES P ROPRIETARY
134
4.1.4.2
LUCENT
T ECHNOLOGIES P ROPRIETARY
135
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.
LUCENT
T ECHNOLOGIES P ROPRIETARY
136
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.
-
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
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).
LUCENT
T ECHNOLOGIES P ROPRIETARY
137
4.3 3G!
!3G Inter-Frequency Handoffs
4.3.1
The call is on a border sector, and the triggers for an inter-frequency handoff have been
met.
LUCENT
T ECHNOLOGIES P ROPRIETARY
138
4.3.2
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:
4.3.3
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.
LUCENT
T ECHNOLOGIES P ROPRIETARY
139
4.4 3G!
!non-3G Handoffs
4.4.1
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 vendors 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.
LUCENT
T ECHNOLOGIES P ROPRIETARY
140
4.4.2
4.4.3
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.
LUCENT
T ECHNOLOGIES P ROPRIETARY
141
LUCENT
T ECHNOLOGIES P ROPRIETARY
142
APPENDIX A
METRIC CROSS-REFERENCE
LUCENT
T ECHNOLOGIES P ROPRIETARY
143
Reference Sections
3.2.1.2.5
3.2.2.2
3.2
3.2.2.2
3.2.1.2.5, 3.1.3, 3.1.4, 3.2.2.2
3.2.1.2.5, 3.1.3, 3.1.4
3.2.1.2.4
3.2.1.2
3.2.2.2
3.2.1.2.5, 3.1.3, 3.2.2.2, 3.1.4
3.2.1.2.5, 3.1.3, 3.1.4
Reference Sections
3.3.1.1
3.3.1.2.2, 3.3.1.2.3
3.3.1.1
LUCENT
T ECHNOLOGIES P ROPRIETARY
144
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.
LUCENT
T ECHNOLOGIES P ROPRIETARY
145
LUCENT
T ECHNOLOGIES P ROPRIETARY
146
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 months worth of data.
LUCENT
T ECHNOLOGIES P ROPRIETARY
147
LUCENT
T ECHNOLOGIES P ROPRIETARY
148
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 HEHs, 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.
LUCENT
T ECHNOLOGIES P ROPRIETARY
149
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 colorcoded 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.
LUCENT
T ECHNOLOGIES P ROPRIETARY
150
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.
LUCENT
T ECHNOLOGIES P ROPRIETARY
151