Вы находитесь на странице: 1из 106

Motorola Confidential Proprietary 1

CDMA RF Application Note:


Parameters and Optimization
6/4/99
Draft Version 8.3.2
Matt Dillon
Daryl Anderson
Cellular Infrastructure Group
1475 West Shure Drive
Arlington Heights, IL 60004
MOTOROLA CONFIDENTIAL Copyright Motorola 1996
This document and the information contained in it is CONFIDENTIAL INFORMATION of
Motorola, and shall not be used, published, disclosed or disseminated outside of Motorola in
whole or part without Motorola's consent. This document contains trade secrets of Motorola.
Reverse engineering of any or all of the information in this document is prohibited. The copyright
notice does not imply publication of this document.
Motorola Confidential Proprietary 2
CHAPTER 1 INTRODUCTION 5
1.1 Scope 5
1.2 Description 5
CHAPTER 2 FORWARD POWER CONTROL PARAMETERS 6
2.1 Motorolas CDMA Forward Channel Power Control Execution 6
2.2 Parameter Impacts on System Performance 13
2.2.1 Forward Link Power Control For the 8 kHz Vocoder 13
2.2.2 Forward Link Power Control for the 13 kHz Vocoder 13
2.3 Parameter Descriptions 15
Customer Changeable Parameters - FER Targets 15
Fixed Parameters 15
CHAPTER 3 REVERSE LINK POWER CONTROL 19
3.1 CDMA Reverse Channel Power Control Execution 19
3.1.1 Closed Loop Reverse Power Control 20
3.1.2 Reverse Power Control Algorithm 22
3.2 Parameter Impacts on System Performance 25
CHAPTER 4 CELL SIZE PARAMETERS 28
4.1 Parameter Impacts on System performance 28
4.2 Parameter Descriptions 29
CHAPTER 5 HANDOVER PARAMETERS 31
5.1 Handover Types 31
5.1.1 Handover Modes 32
5.1.2 Inter-CBSC Soft Handoff 32
5.1.3 Fast Pilot Shuffle 34
5.1.4 Practical Considerations 34
5.2 Parameter Descriptions 36
CHAPTER 6 ACCESS AND SETUP PARAMETERS 39
Motorola Confidential Proprietary 3
6.1. Idle Parameters 39
6.2 Access Parameters 39
6.3 Setup Parameters 41
CHAPTER 7 MIGRATION TO A NEW SOFTWARE RELEASE 46
CHAPTER 8 FIELD OPTIMIZATION WORK CATOGORIES 48
CHAPTER 9 FIELD OPTIMIZATION PROCEDURES 51
9.1 Common Problems with General Optimization 51
9.1.1 No Dominant Pilot 51
9.2 Unique Optimization Cases 52
9.2.1 Origination and Handoff to Far (>4 miles) Away Sites 52
9.2.2 Hard Handoff Optimization 52
9.2.3 Controlling Soft Handoffs 55
9.2.4 2nd Carrier Implementation 60
CHAPTER 10 N-WAY AND YOU 63
10.1 Background 63
10.1.1 Pilot Dominance 63
10.1.2 MM Handoff Processing 63
10.1.3 Complex SHO 63
10.2 N-Way Components and Algorithms 64
10.2.1 Enable vs. Disable 64
10.2.2 Constraint Tables 64
10.2.3 Pilot Dominance 66
10.2.4 MM Filtering 69
10.3 Migration 77
10.3.1 Step 1 - Must Check 77
10.3.2 Step 2 Must Do 77
10.4 Performance Trends 79
10.4.1 Complex Off 80
10.4.2 RFLoss Set 80
10.4.3 SHO Factor Set 80
10.4.4 BTS Shuffle (MR sc991274 and sc994314) 81
10.5 Interaction with Other Features 81
10.6 Call Detail Logs (CDLs) 83
CHAPTER 11 WILL SYSTEMS 83
Motorola Confidential Proprietary 4
11.1 Overview 83
11.2 Drive test procedure 84
11.3 Installation procedures 84
11.3.1 Method 1 85
11.3.2 Method 2 86
11.4 Optimization 86
11.4.1 Forward link 87
11.4.2 Reverse link 87
11.4.3 Analysis Script 88
CHAPTER 12 TIMERS 90
12.1 Timers in the MM 90
12.2 XC Timers 92
12.3 BTS Timers 93
CHAPTER 13 CALL DETAIL LOGS 95
13.1 Analyzing Setup Failures using CDLs 95
13.2 Analyzing RF Losses using CDLs 98
13.3 Analyzing Call Performance with CDLs 100
Motorola Confidential Proprietary 5
Chapter 1 Introduction
1.1 Scope
This purpose of this document is to provide the reader with sufficient information to optimize a
Cellular or PCS CDMA system through the modification of RF system parameters.
The document divides the parameters into the following five major groups:
Forward Power Control Parameters
Reverse Power Control Parameters
Cell Size Parameters
Handover Parameters
Other Customer Adjustable parameters.
Finally, this document will present recommended Field Optimization Techniques along with a
trouble-shooting chart. For a more basic primer on CDMA refer to
http://www.pamd.cig.mot.com/~sfdez/cdma.net.ops.pdf which is a 260 page presentation by
Antonio Shappley.
1.2 Description
There are three categories of parameters. First, are the Customer Changeable Parameters that can
be adjusted through the system design and field optimization steps. These typically are handoff
parameters and forward ERP. Second, are the Customer Changeable Parameters that are difficult
to analyze in the field and require a calibrated laboratory evaluation to obtain repeatability. These
typically include the Power Control parameters. Finally, there is the category of parameters that
should not be changed by the customer.
Motorola Confidential Proprietary 6
Chapter 2 Forward Power Control Parameters
2.1 Motorolas CDMA Forward Channel Power Control Execution
Introduction
The purpose of forward channel power control is to minimize the amount of power transmitted to
a particular mobile station on the forward link. Minimizing power in a CDMA system reduces
interference and thus increases forward channel capacity. However, there is a trade-off between
this forward channel capacity and the forward link voice quality that mobile stations will
experience. The power control algorithm must balance power against acceptable voice quality.
The CDMA Air Interface Spec, IS-95A / J-STD-008, provides a mechanism for forward power
control but does not specify the algorithm for the infrastructure to implement. IS-95A / J-STD-
008 allows the infrastructure to control how a mobile station generates and transmits Power
Measurement Report Messages. This message specifies the number of frame errors a mobile
station has experienced. The mobile station can be directed to generate this message periodically
and/or when an error threshold is reached.
This note does not describe power control algorithm improvements that will be implemented in
future code releases.
Algorithm Overview
The basic idea of the algorithm is that the infrastructure will periodically reduce a traffic channels
forward gain setting. Reducing the gain has the effect of reducing the power delivered to a
mobile station. At some point, the infrastructure may reduce the gain to a point where mobile
station voice quality will soon be degraded. The mobile station will generate and transmit the
Power Measurement Report Message (PMRM) specifying the number of frame errors received
and the total number of frames over which these errors occurred. This essentially provides a short
term FER for the forward channel to the infrastructure.
The infrastructure equipment receives the PMRM and determines that the error threshold has
been reached. The infrastructure then increases the gain to all forward links corresponding to the
given mobile station, restoring FER to an acceptable level, thus preserving voice quality. The
infrastructure then restarts the periodic gain reductions after a specified delay.
See Figure 1 for a graphic representation.
Motorola Confidential Proprietary 7
Forward Power Control Illustration
Forward Gain Setting
Time (frames)
Infrastructure periodically steps
down forward gain setting
Mobile station measures
excessive frame errors, sends
PMRM
PMRM received,
gain setting increased
Figure 1.
There are several parameters which control the behavior of the algorithm. The Mobility Manager
(MM) and Operations and Maintenance Center Radio (OMCR) are responsible for provisioning
and downloading these parameters. All of the Forward Power Control (FPC) parameter settings
were derived by analysis, simulator results, and lab/field tests. Motorola does not recommend
that the FPC parameters be changed without careful consideration and consultation with
Motorola. Motorolas goal is have a generic set of FPC parameters that work for all systems.
Current Forward Power Control lab testing may result in some changes to the parameters to
enhance capacity while maintaining quality.
Gain Settings
The algorithm uses minimum gain settings which prevents the power to a mobile station from
falling below a certain level. The reason for doing this is to mitigate the stop sign effect. The
stop sign effect is when a mobile station comes to rest in a good coverage location, it may allow
its power level to drop significantly. When the mobile station resumes motion, its power
requirements will increase faster than the forward channel power control loop can deliver. The
minimum gain is therefore a trade-off between minimum gain and forward link voice quality.
The algorithm allows the gain floor and ceilings to be set as a function of the number of forward
links (i.e. the soft hand-off state). Due to the diversity benefit of soft hand off exceeding the
Motorola Confidential Proprietary 8
degradation caused by the additional interference, 3 way gain settings would be lower than 2 way
gain settings, and the 2 way gain settings would be lower than the 1 way settings.
The following equations below show the desired relationship between Page and Sync power to
Pilot power. These ratios are determined based on analysis and simulations of idealized and non-
idealized (XLOSS and measured pathloss data) systems with verification through field trials. The
values were chosen to minimize the interference caused by the paging and sync channel, in order
to maximize forward link capacity while maintaining adequate paging and sync channel coverage.
Ppage(9600) = 0.75 * Ppilot
Ppage(4800) = 0.40 * Ppilot
Psync(1200) = 0.10 * Ppilot
where
Ppilot is pilot power at the top of the frame
1
Ppage is the page power at the top of the frame
Psync is the sync power at the top of the frame
The pilot, page, sync, and traffic channel powers are set by setting corresponding digital gain
levels that are proportional to voltage. Hence, we have the relationship:
Ppage
Gpage
Gpilot



_
,

2
Ppilot
Ptch
Gtch
Gpilot



_
,

2
Ppilot
For example, the increase in TCH power could be determined from a TCH gain increase by
Ptch2 =
Gtch2
Gtch1




2
Ptch1 =
Gtch1 + x
Gtch1




2
Ptch1 =
x
Gtch1
+1




2
Ptch1
where
Gtch1 is the traffic channel gain of mobile k before a gain increase
Gtch2 is the traffic channel gain of mobile k after the gain increase
x is the traffic channel gain increase
The dynamic range of a TCH can easily be derived by

1
Frame refers to the Site Interface Frame in a SC9600 system and the Base Transceiver Site for SC60X,
SC24X0, and SC4850 systems.
Motorola Confidential Proprietary 9
Ptch_ max =
Gtch_ max
Gpilot






2
Ppilot
Ptch_min =
Gtch_min
Gpilot






2
Ppilot
Where Gtch_max = 127 (currently) and Gtch_min = 1
We use fixed pilot gain settings and do not vary them with traffic load. Fixed pilot gain settings
are based on designing to a fully loaded system with the constraint that pilot Ec/Io is acceptable
everywhere in the system.
PMRM Message Description
The Power Measurement Report Message (PMRM) is sent by the mobile to serving base stations
periodically (every PWR_REP_FRAMES) to indicate its current quality level and/or sent non-
periodically to indicate that the number of bad frames exceeds a threshold
(PWR_REP_THRESH) in a time window which is at most PWR_REP_FRAMES long (see
pertinent sections in IS-95A / J-STD-008).
PWR_THRESH_ENABLE =1 - enable threshold method for sending PMRM message
PWR_PERIOD_ENABLE =0 - disable periodic method for sending PMRM message
PWR_REP_FRAMES =9 (corresponding mobile parameter TOT_FRAMES)
PWR_REP_THRESH =3 (corresponding mobile parameter BAD_FRAMES)
PWR_REP_DELAY = 3 - four times this value (in terms of frames) is the time the mobile
waits after sending in a PMRM message. This delay prevents
repeatedly sending the message should the mobile be in a bad
location such that it gets a string of Frame erasures.
General
It is important to understand the definition of a bad frame on the forward link since this drives
forward power control. A Bad Frame is indicated when a 9600 baud frame is detected but CRC
fails, frame rate determination is not possible, or quality thresholds in rate determination are not
met. See IS-95A, 6.1.3.3.2 / J-STD-008 2.1.3.3.2 for more details.
Full rate frames have higher FER than lower rate frames due to PCB puncturing. This effects
power control parameter optimization. That is, we tend to shoot for lower than 1% composite
FER to obtain a desired full rate FER of 1%.
Motorola Confidential Proprietary 10
Care must be taken in setting the parameter values that affect how the mobile station generates
Power Measurement Report Messages (PMRMs). It is possible to cause the mobile to send this
message every 5 frames (every 100 ms) in periodic mode. Not only is this likely to significantly
degrade reverse link voice quality, but no additional information is being sent.
This algorithm does not presume that PMRMs are being generated in either the threshold or
periodic modes. Anytime a PMRM is received, the number of errors is compared with a
threshold. If the threshold is reached, the forward gain settings are increased.
Note that if threshold reporting is turned on, the parameter FwdPwrThresh must be set to be less
than PwrRepThresh. If it is not, the infrastructure will never detect excess errors and
consequently the forward power control algorithm will not work.
The Power Measurement Report Message is sent when the number of Frame Erasures at the
mobile exceeds a threshold PwrRepThresh in a window PwrRepFrames long. An equation can be
derived which predicts the mobiles FER based on current forward power control parameters
which is given in Figure 2.0 below.
Example of Motorola's IS-95A / J-STD-008 FPC
1% FER
Gain
o
o
o
o
o
o
o
o
stepDown(=2)
stepUp(=20)
deltatime (=25)
FE
deltatime*(stepUp/stepDown)
time (frames) -->
PwrRepDelay
113 113 12
PwrRepFrames
StepDownDelay(=50)
250
FER= PwrRepThresh/
[deltatime*(stepUp/stepDown)+
MAX(PwrRepDelay,StepDownDelay)]
Equation
dP = 20 log (1 + stepUp/Gtch_current)
Figure 2.0.
The forward link FER equation given in Figure 2.0 has been verified in the lab to be accurate for
a static channel and for a Rayleigh channel for a smaller range of settings. The equation noted
below can be used to calculate a predicted FER given a steady state channel (same speed, delay
spread, etc.).
Motorola Confidential Proprietary 11
FER
Pwr Re pThresh
deltatime
stepUp
stepDown



_
,

+ MAX Pwr Re pDelay, StepDownDelay ( )



1
]
1
It was found that the equation is more accurate when the numerator is modified to account for the
actual delay in applying the forward gain correction. Note that this equation is not meant to be
used as the sole method of choosing forward power control parameters but is part of a process
based also on simulations, lab tests, and field tests to determine the best possible parameters and
gain settings.
Motorola Confidential Proprietary 12
Forward Power Control in different SHO States
When an IS-95A / J-STD-008 mobile originates, its initial forward link power is set based on
either the paging channel gain (PchGain) or the maximum 3-way gain (MaxGain3Way) whichever
is larger. After the mobile has changed hand-off state (gone into 2 or 3 way soft/softer hand-off)
and returns to the single link state its maximum allowed gain is the maximum 1-way gain
(MaxGain1Way). The assumption here is that if the system is designed and operating properly
then the MaxGain1Way gain can be less than the origination gain setting because the mobile will
go into soft handoff when ever it runs into a high interference area. That is, it is assumed that all
high interference areas coincide with soft or softer hand-off regions and there are no coverage
holes that would be mitigated by restricting the 1-way TCH gain to the origination gain level
instead of the maximum 1-way gain. Figure 3.0 below is a state diagram describing forward
power control.
The forward link gain of a mobile will change depending on soft handoff transitions that occur.
Prior to R6, the gain would jump to the nominal level whenever a handoff transition would occur.
As of release six, when a soft add occurs (a channel element is added), the gain is set to the nom
value for the number of links. When a soft or softer drop or softer add occurs, the gain is set to
nom if its current value is greater than the nominal value or remains the same if the current value
is less than nom. The effects will be an increase in forward link capacity because mobiles will ride
at a lower average gain level and an increase in PMRM rate due to the gain not being bumped up
as often automatically.
State Diagram of Forward Power Control
TCH Gain Update
GminTchGainGmax
ORIG.
1-way 2-way 3-way
Gmin=MinGain1Way
Gmax=MAX(PchGain,MaxGain3Way)
Gtch=MAX(PchGain,MaxGain3Way)
Gmin=MinGain2Way
Gmax=MaxGain2Way
Gmin=MinGain3Way
Gmax=MaxGain3Way
NomGain1WayTchGainMaxGain1Way
Gmax = MaxGain1Way
GminTchGainGmax
TCH Gain Update
A=NomGain2WayTchGainMaxGain2Way (softer)
=NomGain2Way (soft)
A
B
TCH Gain Update
B=NomGain3WayTchGainMaxGain3Way (softer)
=NomGain3Way (soft, soft-softer)
NomGain2WayTchGainMaxGain2Way
GminTchGainGmax
(1) Wait OrigDelay frames before reducing TCH Gain every deltatime frames by StepDown units on Origination
(2) Increase TCH Gain by StepUp units whenever a PMRM message is received.
(3) Wait StepDownDelay frames after StepUp before continuing with TCH Gain reduction every deltatime frames
(4) The TCH Gain must fall inside limites based on n-way state or state transition
Figure 3.
Motorola Confidential Proprietary 13
Fast Power Down on Origination
In order to reduce the forward link power from the OrigGain more quickly, release six adds a fast
power down on origination feature. If no soft handoffs have occured after OrigDelay expires, the
gain will be reduced immediately to NomGain1Way then reduced further in steps of twice
StepDown. This process will continue until the MinGain1Way is hit, the mobile generates a
PMRM, or a soft handoff occurs. The benefit from this feature will be seen most from mobiles
that do not enter into soft handoff immediately following origination such as stationary or
pedestrian traffic or WiLL users.
2.2 Parameter Impacts on System Performance
2.2.1 Forward Link Power Control For the 8 kHz Vocoder
The explanation of the power control execution is shown below (from a joint technical meeting
note). There are no suggested field changeable forward power control settings. The default gain
settings have been set so that capacity is maximized while individual frame erasure rates are still at
an average of 1%. Operators might be willing to trade capacity in the early stages in order to
have lowered frame erasures rates in marginal coverage or multiple pilot zones. Keeping this in
mind, a few of the effects of changing the forward power control parameters will be explained.
To help control bursts of errors the MaxGain1-2-3 way settings can be changed to allow the
Power Measurement Report Message (PMRMs) to increase the gain to the maximum of 127.
The effects of this change would:
Decrease the FER rate when multiple PMRMs are sent in a row
Increase the overall system interference
Reduce call drop rate (for a lightly loaded system)
Provide the high Eb/No that the mobile requires for non-optimal conditions
The combination of StepUp/StepDown can be changed to effect the overall FER. The step up is
currently 20, the step down 1 and delta time 50. Increasing delta time will allow more time
between PMRMs and will lower the FER in areas that are covered/optimized. For a system
with limited forward coverage the increase in forward power will create coverage holes prior to
reverse link rise problems. System designs that are marginal in terms of the forward link, such
that raising forward power and forward TCH gain should be prepared to add cells in order to
compensate for the coverage holes that will appear with larger user densities.
2.2.2 Forward Link Power Control for the 13 kHz Vocoder
Erasure Indicator Bit (EIB)
Motorola Confidential Proprietary 14
Specific to Rate Set 2 only is the Erasure Indicator Bit. EIB is effective as of release seven and
works in addition to the PMRM method of increasing the forward channel gain. The MCC sends
the EIB to the transcoder. If the call is in soft handoff, the XC performs its selector function
where each EIB must be an erasure for the outcome to be an erasure. The XC then sends the
selected EIB to the MCCs on the next forward frame. If the EIB is an erasure, the forward gain
will be increased by StepUp. The effect of EIB will be to speed up the forward power control.
Motorola Confidential Proprietary 15
2.3 Parameter Descriptions
Customer Changeable Parameters - FER Targets
The FER targets can be changed by the customer in order to get a higher capacity while trading
off average forward FER. The regions that benefit most are those with high load and high
multipilot. These regions will experience less degradation during loaded and will have more
capacity before they experience degradation in the RF loss rates. Currently, release 7 and 8/8.1,
the FER targets only automatically apply to rate set 1 systems (8k). This is to aid the
parameterization of systems with mixed rate sets. The reverse link is not effected by the FER
targets in any release so far.
Systems with either rate set can take advantage of the concept of FER targeting by changing these
parameters. This can be especially useful for rate set2 systems that have an inherent lower
capacity due to the increase in Eb/No required for the higher data rate.
FER Target Delta Time Down Delay Step Up Step Down
FERA 35 75 20 1 .6% .7%
FERB 20 40 20 1 .9% 1.0%
FERC 10 20 20 1 1.5% 1.6%
FERD 7 20 15 1 2.5% 2.5%
* Assumes that the TCH gain settings are per defaults as noted in the parameter guide located at
http://scwww.cig.mot.com/~dillon
Fixed Parameters
MinGain1Way This is the lowest forward traffic channel digital gain level to which the
MCC will trickle down when a mobile is not in a soft or softer handoff.
NomGain1Way This is the starting forward traffic channel digital gain level for a mobile
which is not in a soft or softer handoff, except on an origination or
termination (see MaxGain3Way).
MaxGain1Way This is the maximum forward traffic channel digital gain level for a mobile
which is not in a soft or softer handoff, except on an origination or
termination (see MaxGain3Way).
Motorola Confidential Proprietary 16
MinGain2Way This is the lowest forward traffic channel digital gain level to which the
MCC will trickle down when a mobile is in a 2 way soft or softer
handoff.
NomGain2Way This is the starting forward traffic channel digital gain level for a mobile
which has entered a 2 way soft or softer handoff.
MaxGain2Way This is the maximum forward traffic channel digital gain level for a mobile
which is in a 2 way soft or softer handoff.
MinGain3Way This is the lowest forward traffic channel digital gain level to which the
MCC will trickle down when a mobile is in a 3 way soft or softer
handoff.
NomGain3Way This is the starting forward traffic channel digital gain level for a mobile
which has entered a 3 way soft or softer handoff.
MaxGain3Way This is the maximum forward traffic channel digital gain level for a mobile
which is in a 3 way soft or softer handoff. It may also be both the initial and
maximum setting at call origination or termination (refer to PchGain).
PchGain Specifies the gain setting for a sectors paging channel. It may also be both
the initial and maximum setting at call origination or termination The MCC
will use the larger of MaxGain3Way and PchGain in this situation.
StepUp Specifies the amount of the increase in forward channel digital gain by the
MCC when a gain increase is requested by the XC.
StepDown Specifies the amount of the periodic decrease in forward channel digital
gain by the MCC.
DeltaTime This is the amount of time (specified as a number of air interface frames) an
MCC channel element waits between gain step downs.
StepDownDelay This is the amount of time (specified as a number of air interface frames) an
MCC channel element waits after a gain step up before step downs resume.
Motorola Confidential Proprietary 17
OrigDelay This is the amount of time (specified as a number of air interface frames)
the channel element waits after an origination or termination before step
downs begin. This delay is to provide ample time for the mobile station to
request a two or three way soft handoff after a call setup.
MinPcbGain This parameter specifies the minimum gain setting for the reverse channel
closed loop power control bits transmitted on the forward channel.
PcbGainFact This parameter specifies the factor the infrastructure equipment multiplies
the current forward channel gain setting to determine what the power
control bit gain should be set to. Its range is 1 < PcbGainFact < 5 and it
can be set in increments of 0.25. Note that the PCB gain is a function of
the mobiles soft handoff state and uses the PcbGainFact value in its
calculation.
FwdPwrThresh This is the threshold against which the ERRORS_DETECTED field of the
RF: Power Measurement Report Message will be compared to determine
if a power step up is required for that mobile station. This parameter is
closely related to PwrRepThresh and must be set with this in mind.
PMRM Message Parameters
PwrThreshEna Enables threshold reporting mode (as specified in IS-95A / J-STD-008) in
the mobile station. Sent to the mobile station in the RF: System Parameters
Message as PWR_THRESH_ENABLE. Currently set at 1 to enable
threshold reporting.
PwrPeriodEna Enables periodic reporting mode (as specified in IS-95A / J-STD-008) in
the mobile station. Sent to the mobile station in the RF: System Parameters
Message as PWR_PERIOD_ENABLE. Currently set at 0 to disable
periodic reporting.
PwrRepThresh If threshold mode reporting (as specified in IS-95A / J-STD-008) is
enabled, this is the number of frame errors which will cause the mobile
station to send an RF: Power Measurement Report Message. This
Motorola Confidential Proprietary 18
parameter can be set to values from 0 to 31 frames. This parameter is sent
to the mobile station in the RF: System Parameters Message as
PWR_REP_THRESH.
PwrRepFrames This specifies to the mobile station the number of frames over which it will
count frame errors. This parameter can be set to certain values between 5
and 905 frames (refer to IS-95A / J-STD-008). This parameter is sent to
the mobile station in the RF: System Parameters Message as
PWR_REP_FRAMES.
PwrRepDelay This parameter specifies to the mobile station how many frames to delay
after sending an RF: Power Measurement Report Message before it
resumes counting frames and frame errors. It can be set to values between
0 and 124 in intervals of 4 frames. This parameter is sent to the mobile
station in the RF: System Parameters Message as PWR_REP_DELAY.
Motorola Confidential Proprietary 19
Chapter 3 Reverse Link Power Control
3.1 CDMA Reverse Channel Power Control Execution
Purpose
The purpose of this note is to give standard background information on reverse power control and
to give additional information as an aid for setting certain power control parameters which effect
system performance. The ultimate goal as stated in a previous note on forward power control is
to minimize the number of required customer changeable power control parameters without
sacrificing system performance.
Introduction
To simultaneously achieve high capacity and quality, IS-95A / J-STD-008 CDMA utilizes channel
power control. Reverse link (mobile to cell) power control varies the power transmitted by the
mobile to ensure that the power from each mobile arrives at the cell site at the minimum possible
level. If the mobiles transmit power is too low, voice quality will be degraded. If the mobiles
power is too high, the mobile may have high quality, but the resulting excess interference will
degrade capacity. Reverse Power Control consists of open and closed loop components. A
discussion on each is in the following sections.
Open Loop Reverse Power Control
The reverse power control open loop, which is performed at the mobile, attempts to account for
common or symmetrical losses on the reverse and forward links mainly due to pathloss and
shadowing (lognormal or slow fading). It is by necessity then, a relatively slow (with respect to
the closed loop) lowpass filtered process. Figure 1. below shows the reverse power control open
loop and the mobile portion of the inner closed loop.
Reverse Power Control Open Loop & Mobile Portion of Inner Closed Loop.
Motorola Confidential Proprietary 20
AGC
DE-INTERLEAVE
DEMOD
K- NoW
STRIP
PCB
1 dB
-1 dB
PCB
+
Z
-1
INTEGRATOR
OPEN LOOP
PC ESTIMATOR
ANTENNA
+
p = NoW
r
m
NoW = NthW+IoW+IocW
t_ol
m
p
t_cl
m
p
t
m
p
MOBILE STATION
K - turn around factor = -73 dBm
2
CLOSED (Inner) LOOP
OPEN LOOP
INIT PWR (dB)
+
NOM_PWR(dB)
sum access
probe
corrections
(dB)
Figure 1.
The amount of mobile transmit power ( P
t
m
) necessary to close the reverse link is estimated by
subtracting total noise plus interference measured at the mobile antenna ( P
r
m
N
o
W) from a
turn around factor (k = -73 dB). The open loop mobile transmit power estimate will be refined
by reverse closed loop power control.
P
t
m
k P
r
m
=
N
o
W N
th
W I
o
W I
oc
W + + =
where
N
th
W - receiver thermal noise and other non-CDMA system noise
I
o
W - serving cell power
I
oc
W - other CDMA cell interference power
3.1.1 Closed Loop Reverse Power Control
The closed power control loop consists of an inner and outer loop. The outer loop is maintained
at the base station and provides a means, based on received frame quality information (every 20
ms), to maintain consistent call quality. The inner loop is distributed between the mobile and the
base station and provides a means, via a 800 Hz power control channel (sending power control
bits (PCB) by puncturing symbols on the forward channel), of varying the mobile transmit power
to achieve a necessary signal to noise level at the base station receiver.
Motorola Confidential Proprietary 21
The closed loop accounts for non-symmetrical (uncorrelated) losses between the reverse and
forward links due to Raleigh/Rician (fast) fading, interference level variation (e.g. voice activity or
loading), differences in transmit and receive antenna gains, and other associated losses
(combiners, connectors, duplexors, etc.). It is the fast power control loop being updated every
1.25 ms (once every power control group (PCG)) that solves the near-far problem and effectively
mitigates small to medium received power variations due to Raleigh fading at slow speeds. This
effectiveness is mitigated for sub-rate mobile transmissions.
The portion of the closed loop reverse link power control algorithm performed at the base station
is shown in Figure 2 below.
Motorola Confidential Proprietary 22
Reverse Power Control Outer Loop & BTS portion of Inner Closed Loop
AGC
ANTENNA
AGC
ANTENNA
FHT
FQI
DEMOD.
DECODER Frame
Quality Info
A
1

2
FHT
FHT
DESPREAD FHT
A
Eb/No threshold
+
-
+
SET PCB
PCB
M = Estimated
Eb/No
m(n)
ADJUST OUTER LOOP
THRESHOLD
Frame
Quality Info
C
O
M
B
I
N
E
R
DESPREAD
DESPREAD
DESPREAD
finger
info.
ACCUMULATE
OVER 6 WALSH
SYMBOLS
Winning
Walsh Symbol
Info
Outer Loop Threshold Computer
IF(-)
PCB=1 (-1dB)
ELSE
PCB=0 (+1dB)
(DEMOD STATE)
Other
Info
FIGURE 2.
3.1.2 Reverse Power Control Algorithm
3.1.2.1 Inner Loop
Referring to Reverse Power Control Outer Loop & BTS portion of Inner Closed Loop above the
inner loop of the reverse power control algorithm is now summarized.
1) For each walsh symbol interval (n) compute the winning Walsh symbol energy, Ewin.
2) Compute Power Control Metric m(n) =
Ewin
k
where k is a scale factor.
3) Compute Power Control Group metric measured of all 6 winning walsh symbols in the PCG.
M m n ( )
n 0 =
5

=
4) Compare M to the Outer Loop threshold to increase or decrease mobile TX power via
puncturing power control bit (PCB) on forward traffic channel link.
Motorola Confidential Proprietary 23
Power is changed at the mobile by transmission of the Power Control Bit (PCB) by puncturing on
the forward traffic channel link at the BTS. The mobile power level is increased (PCB set to 0) if
the Power Control Group metric (M) is less than or equal to the current outerloop Threshold.
The mobile power level is decreased (PCB set to 1) if M is greater than the current outerloop
threshold. How much and when to increase or decrease mobile power determines algorithm
performance and has a direct impact on system capacity. The Power Control Group metric (M) is
related to Eb/No as given by the relation in Figure 3.
Delay in sending and applying the PCB degrades reverse power control performance. The error
rate of the PCB also has a performance impact. The increase in reverse link Eb/No required for
1% full rate FER operation due to degrading the PCB error rate from 1% to 5% is less than 0.3
dB. The elevated gain requirement of the PCB (with respect to the TCH gain) needed for a
nominal PCB error rate can be traded off against the excess interference it creates on the forward
link. Note that a requirement in IS-98 requires that during soft handoff a mobile must ignore a
links PCB if the fingers Ec/Io falls below some threshold. This threshold level is left up to the
mobile manufacturer. This requirement along with diversity combining PCBs during softer
handoff can help reduce the required PCB gain.
3.1.2.2 Outer Loop
The outerloop threshold is controlled as a function of frame quality. The goal is to maintain a
consistent call quality level. One possible implementation is to degrade the threshold until
erasures occur and then increase it up by some step size depending on whether the erasure was
considered a full rate or sub-rate frame.
3.1.2.3 Initialization & RPC Parameter Discussion
After a mobile has originated using the access channel the maximum, nominal, and minimum outer
loop thresholds are set to maxpwr, NomPwr, and minpwr. For example,
RPCMaxEbNo = 9.0 dB (per Antenna) (3435)
RPCNomEbNo = 8.0 dB (2810)
RPCMinEbNo = 5.0 dB (1646)
pwrctl_threshold = RPCNomEbNo
The maximum threshold variable (RPCMaxEbNo) restricts any particular mobile from requiring
too much Eb/No (power) to achieve its desired call quality. The minimum threshold
(RPCMinEbNo) serves to keep fingers in lock at slow speeds and avoids consecutive full rate
frame erasures. A nominal threshold variable (RPCNomEbNo) is used for initializing the power
control threshold at call origination/termination. The step sizes updating the outerloop threshold
are given as:
Motorola Confidential Proprietary 24
RPCUpPFull = 750 (1.3 dB - based on Eb/No reference of 8.0 dB)
RPCUpPNFull = 500 (0.9 dB)
RPCDownP = 8 (0.014 dB)
Note that the step sizes can be specified in terms of Eb/No (dB) values or energy values as given
above
2
. The mapping is based on the Winning Walsh symbol energy (M) vs. Eb/No relationship
(see Figure 3). A nominal Eb/No value is chosen as a reference when using this relationship
(which is realized as a set of tables) to set the above parameters from the database.
2 4 6 8 10 12
0
2000
4000
6000
8000
10000
Eb/No (dB)
Power Control Threshold Table
M
2 fingers
Figure 3. Relationship between winning walsh symbol metric (M) and Eb/No given two
paths (BSM chip set).
The desired call quality in terms of full rate FER is approximated by the relation
FR FER = 100
RPCDown
RPCUpPFull
and hence is sensitive to the step sizes chosen, especially the step down size.
For example, if the full rate step up size (RPCUpPFull) is equal to 750 energy units and step
down size (RPCDownP) is 8 units then it would take RPCUpPFull/RPCDownP (= 750/8 in
Walsh Symbol Units or 1.3/0.014 in dB E
b
/N
o
) frames for the outerloop threshold to relax to its
previous level at which the frame erasure occurred. Assuming another erasure occurs when the

2.
. The Eb/No values can be converted to finger energy values by indexing the Winning Walsh Symbol Energy (M) versus Eb/No table value using a
nominal value in the normal operating range (in this case we use the nominal threshold of 8.0 dB). Computing the difference energy between 8.014
and 8.000 dB Eb/No for two antennas results in the step down energy value of 8 (=57*0.014/0.10) decimal. Using a 7 dB reference maps 750 to 1.8
dB and 1% of 1.8 = 0.018 dB. The difference between 7.018 and 7.000 maps to a step down energy value of 8 (=44*0.018/0.10).
Motorola Confidential Proprietary 25
original level is achieved, the mean number of frames between erasures will be 94, giving a full
rate frame erasure rate of about 100/94 =1.1%. Useable delay spread improves this relationship.
The larger the full rate step up size the more excess interference is created. If the step up size is
set too small then the larger the chance of consecutive full rate frame erasures. Simulations, Lab
tests and field results indicate that the size should be in the range (500,750) or approximately 1.0
to 2.0 dB.
3.2 Parameter Impacts on System Performance
The explanation of the power control execution is shown below (from a joint technical meeting
note). There are very few suggested field changeable reverse power control settings. The default
gain settings have been set so that capacity is maximized while individual full rate frame erasure
rates are still at an average of 1%. Operators might be willing to trade capacity in the early stages
in order to have lower frame erasure rates.
Reverse bursts should only occur if the maximum set point requirements are exceeded or due to a
stop sign effect during a ramp up from the minimum target set point. Usually the first choice is to
raise the maximum Eb/No set point. Raising the set of Max-Nom-Min should eliminate all bursts.
Reverse average FER can be reduced by decreasing the step down rate (RPCDownP). However,
these changes are not recommended.
In general, with voice traffic the reverse power control settings have been lab/field verified to
provide better than 1% full rate when power control bits are being received at the mobile (good
forward link conditions). Reverse composite FER will typically range from 2 to 4% while still
achieving 1% full rate FER and acceptable voice quality.
3.2.1 Parameter Descriptions
Closed Loop Power Control Parameters
RPCMaxEbNo Reverse Power Control Maximum Eb/No. Reverse power control
algorithm parameter which specifies maximum Eb/No the power control
threshold is allowed to rise to. This data is used to derive the actual
threshold used by the algorithm. Range 2.0 - 14.9 dB, in 0.1 increments.
Optional parameter; if skipped, uses current value. Current recommended
value 12.0. All mobile station reverse power control parameters are set
using the EDIT SECTOR MSRRPC command.
Open Loop Power Control Parameters
NomPwr Access Channel Nominal Transmit Power Offset. The correction factor the
mobiles are to use in the open loop power estimate. Sent to the mobile in
Motorola Confidential Proprietary 26
the Access Parameters Message, Please refer to IS-95A / J-STD-008 for
the complete definition. Range -8 to 7 dB. Optional parameter; if skipped,
uses current value. Initial standard value 0.
InitPwr Initial Power for Access. The correction factor to be used by mobile
stations in the open loop power estimate for the initial transmission on an
access channel. Sent to the mobile in the Access Parameters Message,
Please refer to IS-95A / J-STD-008 for the complete definition. Range -16
to 15 dB. Optional parameter; if skipped, uses current value. Initial
standard value 0. Current recommended value -4.
Closed Loop Power Control Parameters
All closed loop power control parameters are edited using edit SECTOR BTSRPC.
RPCNomEbNo Reverse Power Control Nominal Eb/No. Reverse power control algorithm
parameter which specifies the Eb/No starting point of the power control
threshold used in the algorithm. Range 2.0 - 14.9 dB, in 0.1 increments.
Optional parameter; if skipped, uses current value. Current recommended
value 11.0.
RPCMinEbNo Reverse Power Control Minimum Eb/No. Reverse power control
algorithm parameter which specifies the minimum Eb/No the power control
threshold is allowed to fall to. This data is used to derive the actual
threshold used by the algorithm. Range 2.0 - 14.9 dB, in 0.1 increments.
Optional parameter; if skipped, uses current value. Current recommended
value 8.0.
RPCEraLim Reverse Power Control Frame Erasure Count Limit. Reverse power
control algorithm parameter specifying the number of consecutive sub-rate
frame erasures allowed before an adjustment to the power control
threshold is made. Range 0-255 frames. Optional parameter: if skipped,
uses current value. Current recommended value 2.
RPCUpPFull Reverse Power Control Power Increment Step Full Rate. Reverse power
control parameter algorithm parameter which specifies the amount the
power will have to be increased due to a frame error which was likely to
have been a full rate frame. This data is used to derive the threshold step
used in the algorithm. Range 0.00 to 5.00 dB, in 0.01 increments. Optional
Motorola Confidential Proprietary 27
parameter: if skipped, uses standard value. Current recommended value
1.30.
RPCUpPNFull Reverse Power Control Power Increment Step Not Full Rate. Reverse
power control parameter algorithm parameter which specifies the amount
the power will have to be increased due to a run of frame errors which
were not likely to have been full rate frames. This data is used to derive
the amount the power control threshold will be increased due to a run of
errors which were not likely to have been full rate frames. Range 0.00 to
5.00 dB, in 0.01 increments. Optional parameter: if skipped, uses current
value. Current recommended value .90.
RPCDownP Reverse Power Control Down Step Size. Reverse power control algorithm
parameter which specifies the amount the power will be decreased due to a
good frame. This data is used to derive the threshold step used in the
algorithm. Range 0.00 to 5.00 dB, in 0.01 increments. Optional parameter:
if skipped, uses current value. Current recommended value 0.014.
Motorola Confidential Proprietary 28
Chapter 4 Cell Size Parameters
4.1 Parameter Impacts on System performance
As a general philosophy, access and traffic channel window sizes should be kept to their minimum
in order to allow maximum searcher performance (multiple scans) for both the BTS-MCCCE
(channel element) and mobile station. In addition, smaller access windows allow for reduced
preamble size that can increase the paging throughput and paging response time by reducing the
slot size. Rere to the call flow chapter to see where these parameters effect the calls setup and
possible drop rates. After release 5 the PamSz and AchPamWinSz is derived from the cell radius
parameter. However, the TchAcWinSz still needs to manually be set so that the softhandoffs
from large surrounding cells will function properly.
See Doug Bohrers documentation on the searcher algorithm at
(http://scwww.cig.mot.com/~bohrer/)
There are a few parameter that are effected for systems with cells radii greater than 7-9
kilometers (75 chips). See the following chart for specific settings. The groups are:
Cell Radius - For big cells the default of 8.1 km must be increased to compensate for the
increased cell range.
Traffic Window - For big cells the default of 125 for TchAcqWinSz must be increased to
compensate for the increased cell range. This window should always be as large or larger than
the AchPamWinSz in order to be able to aquire the traffic channel. Use the table below to
convert cell radius to chips.
Mobile Search Windows - For big cells the defaults of SrchWinN, SrchWinR must be
increased so that mobile can acquire cells with large differential time-distance separations.
PNInc - For big cells larger PN increments must be used in order avoid confusing PSMMs.
This is set in conjunction with the mobile neighbor/remaining search windows.
Cell Radius vs. PamSz and Preamble window size
Cell radius window size PamSz
0.0 to 0.9 12 0
1.0 to 2.9 25 0
3.0 to 3.9 37 0
4.0 to 5.9 50 0
6.0 to 6.9 62 1
7.0 to 8.9 75 1
9.0 to 9.9 87 1
10.0 to 11.9 100 1
Motorola Confidential Proprietary 29
12.0 to 12.9 112 2
13.0 to 14.9 125 2
15.0 to 15.9 137 2
16.0 to 17.9 150 2
18.0 to 18.9 162 2
19.0 to 20.9 175 3
21.0 to 21.9 187 3
22.0 to 23.9 200 3
24.0 to 24.9 212 3
25.0 to 26.9 225 3
27.0 to 27.9 237 4
28.0 to 29.9 250 4
30.0 to 30.9 262 4
31.0 to 32.9 275 4
33.0 to 33.9 287 4
34.0 to 35.9 300 5
36.0 to 36.9 312 5
37.0 to 38.9 325 5
39.0 to 39.9 337 5
40.0 to 41.9 350 5
42.0 to 42.9 362 6
43.0 to 44.9 375 6
45.0 to 45.9 387 6
46.0 to 47.9 400 6
48.0 to 48.9 412 7
49.0 to 50.9 425 7
51.0 to 52.9 437 7
53.0 to 53.9 450 7
54.0 to 55.9 462 7
56 475 8
4.2 Parameter Descriptions
To see how these parameters effect the call success rate during access, setup or stable calls see
the call flow chapter.
Access and Traffic Windows (see chart for values).
CellRadius This parameter (as of release six) defines the radius of the cell and
automatically sets the PamSz and AchPamWinSz described below. The
Motorola Confidential Proprietary 30
units are in kilometers and can be adjusted in increments of one-tenth of a
kilometer.
PamSz This parameter defines the number of access channel frames that the
mobiles are to send preamble on when attempting to access the system. It
is automatically set by CellRadius.
AchPamWinSz This parameter defines the access channel preamble in PN chips. This can
be adjusted with field data to provide the minimum window size, allowing
the access channel to provide maximum sensitivity(multiple searches). See
the field optimization section for the recommended methods. It is
automatically set by CellRadius.
TchAqcWinSz This parameter defines the traffic channel acquisition in PN chips. This
parameter is used during handover acquisition during a call. It should be at
least as large as the AchPamWinSz.
Access and Traffic Windows (see chart for values)
AchMpthWinSz This parameter defines the access channel multi-path window size in PN
chips. It is not being used in the current MCC-4 implementation.
TchMpthWinSz This parameter defines the traffic channel multi-path window size in PN
chips. It does not change for larger cell sizes.
TchPamWinSz This parameter defines the traffic channel preamble in PN chips. It does
NOT depend on the cell size due to the window centering feature. This
feature provides the MCC traffic channel the PN offset of the access probe
so that the traffic channel acquisition window can be smaller for increased
sensitivity due to faster searching performance.
Motorola Confidential Proprietary 31
Chapter 5 Handover Parameters
5.1 Handover Types
IS-95 allows for several types of handoff to take place. The following list elaborates and
summarizes each possible type of supported handoff. Some of the handoff types reflect the
implementation of CDMA rather than IS-95. Note that there are always two types of soft and
softer handoff. One type called an add is used to instruct the mobile to include a new pilot in its
active set. The other type called a drop is used to instruct the mobile to exclude an old pilot
from its active set.
Inter BTS, intra transcoder (XC) Soft Handoff: This handoff type is expected to be the
highest percentage of handoffs in CDMA systems as this type contributes to the greatest
amount of reverse channel interference reduction and capacity increase. A mobile station has
simultaneous connections to two or three cells and receives power control orders (for reverse
link closed loop power control) from each cell in the soft handoff.
Intra BTS, Inter Sector, and Intra XC Softer Handoff: This handoff type denotes a state
where a mobile station maintains connections to multiple sectors all based at the same cellsite
location.

Inter CBSC soft handoff where the new additional link is an XC Sector neighbor from an
adjacent CBSC. Calls progresing into the new CBSC, dropping all legs from the original
CBSC, will be hard handed off into best pilot on the new CBSC.
Inter or Intra BTS Hard Handoff: This handoff type denotes either a change in operating
frequency, a change in 1.25 ms frame offset, or a handoff in which the intersection of old
active set pilots with new active set pilots is the null set.
Hard Handoff to N/AMPS: This handoff type is used to transition a dual/tri mode mobile
station from CDMA operation to operation on an analog system.
A complex handoff in a CDMA system is defined as a handoff instruction to the mobile station
which makes more than one change to the mobiles active set. For example, MAHO
measurements from the mobile station may indicate that it is desirable to enter into a state where
new connections are supported from both the current cellsite location (softer handoff) and from
another cellsite location (soft handoff).
This type of handoff is not supported by the current system. The BSS will only send RF:
Extended Handoff Direction Messages that add or drop a single pilot from a mobile stations
active set. Some documentation on handoff issues from good starting site by Sam Fernandez
http://www.pamd.cig.mot.com/~sfdez/handoffs.htm
Motorola Confidential Proprietary 32
DAHO Application Note
http://scwww.cig.mot.com/people/cdma/PjM/product/white_papers/main.html
DAHO Product Launch Information
http://www.acpg.cig.mot.com/w3/apd/PIOI/new/launch.html
SC-2.5.1 Pilot Beacon Application Note
[Note that this applies to Release 2.5.]
http://scwww.cig.mot.com/people/cdma/PjM/product/white_papers/main.html
Inter-CBSC SHO (Trunking) Home Page
http://www.sc.cig.mot.com/~pedzi/inter_cbsc/ic_deployment.html
Multi-Carrier Application Note (Preliminary)
http://www.pamd.cig.mot.com/nds/NDShomepage.html, under App Notes
CDMA Call Processing SFS
http://scwww.cig.mot.com/~sherwink/DOC/SFS.pdf.html, under
SCELL-CDMA-CP-SFS-001, v 6.0
CDMA Handoff & Power Control SFS
http://scwww.cig.mot.com/~sherwink/DOC/SFS.pdf.html, under
SCELL-CDMA-HOPC-SFS-003, v 6.0
5.1.1 Handover Modes
The system is required to support various handoff modes. The handoff mode defines how the
handoff detection algorithm and execution procedures operate. The mode defines what triggers
the system to add a pilot to the mobile stations active set. Two modes are defined - TAdd and
TComp. When operating in the TAdd mode, any time a pilot rises above the TAdd threshold or
the TComp threshold (i.e. a pilot has risen TComp + 0.5dB above any active set pilot), the system
will attempt to add that pilot to the mobile stations active set via a soft or softer handoff. When
operating in the TComp mode, a pilot must rise above the TComp threshold before the system
attempts to add it to the mobile station active set.
5.1.2 Inter-CBSC Soft Handoff
Introduced in release seven is inter-CBSC SHO. This refers to a method of performing soft
handoffs between cells under different CBSCs. It eliminates the need for pilot beacons at CBSC
borders and allows much more reliable handoffs to occur between CBSCs on the same frequency
than the past hard handoff method.
Adjacent CBSCs must be connected to each other with spans which carry signalling and traffic for
handoff legs on the other CBSC. The ability to add soft handoff legs is done with XCSECTs in
the source CBSCs sectop list. When a sector from an adjacent CBSC is added to the active set,
the traffic and signalling information is backhauled to the source CBSC via the spans which
interconnect CBSCs. At some point while the mobile is moving from one CBSC to another,
control of the call will need to be moved to the target CBSC. This is done by moving the
vocoding function of the call from one CBSC to the other, called an anchor handoff. At the point
Motorola Confidential Proprietary 33
where the anchor handoff is determined to be attempted, a hard handoff will occur, transitioning
the mobile from its current N-way handoff state down to 1-way where the active sector is the
strongest of the current actives.
When a call is in inter-CBSC sho, and information has to be backhauled through another CBSC,
an extra delay is incurred in completing soft handoff adds and drops, approximately 100ms. This
is one reason why it is beneficial to eventually move the anchor to the other CBSC once the
mobile is sufficiently inside its coverage. In addition, inter-CBSC shos will cause a slight
reduction in MM capacity with respect to intra-CBSC shos, so the quicker the anchor is moved,
the less of an impact there will be on MM utilization.
Anchor Handoff Methods
There are four methods for completing the anchor handoff, configurable on a per cbsc basis
(Legs_Remote, No_Legs_Wait, No_Legs, and Keep_Soft). Below is a description of the
methods along with some reasoning behind the usage of each.
Keep_Soft inhibits all anchor handoffs. It never allows control of the call to be transfered to the
target CBSC and would eventually cause the call to be dropped if the mobile moves through the
target CBSC and into the coverage of a third. It eliminates the risk of moving the call from N-
way to 1-way.
The Legs_Remote method performs the anchor handoff when there are no XCSECTORs or
anchor sectors in the active set from the perspective of the source CBSC. In other words, when
all the active set pilots are on the target CBSC and are not XCSECTORs of the source CBSC,
this criterion is met. Next to Keep_Soft, this is the slowest of the methods at moving the anchor.
This is also the most conservative method with respect to avoiding ping-pong of the anchor back
to the original CBSC because the mobile will be deep inside the coverage of the target.
No_Legs refers to a method where the anchor handoff is completed when no anchor sectors from
the source CBSC are in the active set. The active set needs to include only sectors that are not
local to the source CBSC. This is the quickest of all the anchor handoff methods and has the
potential of causing ping-pong of the anchor between CBSCs in rapidly changing pilot
environments. It could be advantageous, however, in a scenario where multiple CBSC boundaries
are geographically close together requiring a quicker anchor handoff to facilitate inter-CBSC sho
with another CBSC.
The No_Legs_Wait method will cause an anchor handoff once the No_Legs criteria is met and
one of the following occurs: the call goes into one-way sho, the best active pilot is tcomp above
the second best active pilot, or the Legs_Remote criteria is met. This is the only method that
includes any type of dominance criteria for deciding when to move the anchor.
Each method varies on the timing in which it will attempt the anchor handoff. Attempting the
handoff too early may cause ping-pong between CBSCs especially in environments of rapidly
changing pilots. At the same time, waiting excessively long to move the anchor will cause
Motorola Confidential Proprietary 34
additional delay in soft handoffs while the information is backhauled through the the target CBSC.
No_Legs_Wait will generally provide the best compromise between these two issues.
5.1.3 Fast Pilot Shuffle
This feature will reduce the number of dropped calls in the CDMA system under the following
conditions:
The call is in three-way soft handoff
None of the current pilots is a candidate to be dropped
A better candidate pilot is available.
In the current implementation, a new pilot will not be added to the handoff until one of the active
pilots falls below the TDrop threshold for the corresponding TTDrop time interval. By the time
this happens, a candidate pilot may have created such a strong interference that a RF loss results
and the call is consequently dropped. In order to reduce the number of dropped calls in this
situation, a mechanism is needed to drop one of the active pilots and replace it with the strong
candidate pilot. This can be accomplished by recognizing when the scenario described above is
taking place, and taking action to drop the weakest active pilot so that the strong (or strongest, if
more than one) candidate pilot is added to the handoff. Specifically, the following needs to be
implemented: If a call is in three-way handoff and the CDMA System receives a Pilot Strength
Measure Message (PSMM) from the mobile containing only add events (TAdd and/or TComp
events), the CDMA System shall reevaluate the active pilot set as follows: If the strongest
candidate pilot is a TComp event, the CDMA System shall initiate a drop of the weakest active
pilot. If the strongest candidate pilot is a TAdd event, the CDMA System shall compare the Ec/Io
of the candidate to the Ec/Io of the current active pilots. If the candidate Ec/Io is greater than the
Ec/Io of two or more of the active pilots, the CDMA System shall initiate a drop of the weakest
active pilot. Upon completion of the drop, a PSMM shall be solicited. As a result of PSMM
request, the candidate pilot set will be reevaluated and the strongest pilot will be added to the
handoff if appropriate (already implemented, but mentioned here for completeness).
T_COMP, which previously had seen little utility in soft handoff operations, will be a primary
concern. Any candidate set pilot that is T_COMP dB better than an active set pilot (when in 3-
way SHO) will be used to trigger a pilot shuffle. This should generally be set as high as possible
in order to inhibit Tcomp shuffle events over the worst pilot. The better alternitive is to force the
shuffle to be a better than 2 active pilots than Tcomp over the worst since a small fade will cause
excessive shuffling.
5.1.4 Practical Considerations
SifPilotPwr
Increase from system design settings to maintain coverage, become a dominant server, or change
SHO corners for good metric route numbers. Decrease to allow another pilot to dominate or
because of shared or limited LPA concerns in an otherwise good area. This setting can range
from a standard value of 33-34 to 39 dBm at the top of the frame.
Motorola Confidential Proprietary 35
TAdd/TDrop/TTDrop (TTT)
Handoff Mode - The handoff mode will determine the system optimization that follows, i.e. a
system that has been optimized while set to TComp mode will not behave the same as a
system in TAdd mode. New or different trouble corners appear and SHO locations shift.
During the initial design phase, the amount of effective channel elements per call helps to
target the desired mode. TComp will allow the reduction of channel elements, but in the field
has compared poorly for increased RF loss rates and frame erasure rates. TAdd mode has
been able to provide higher call metrics at the expense of increased channel element use
provided by the extra diversity.
Considerations - There are two effects that should be taken into consideration when setting
TTT. The first is the messaging rate. Messaging should be minimized in order to save
XC/CPP utilization and to minimize extra signaling for both voice quality and chances of layer
2 failures (missing ACK Required messaging). For instance, TComp mode will have reduced
PSMM rates (60-80%). The second item to balance is the channel/subscriber ratio, which can
range from 1.3 - 2. TComp mode will have a reduced number of channels per subscriber as
well. One of the main considerations in providing CPP(s) requirements is the call model
which in part depends on the handoff mode.
Typical Ranges - Tadd ranges from -10 to -14 dB in our current systems. Tdrop ranges from
a range of -11 to - 16 dB. One important aspect of these two parameters is the difference
between the two settings. There will be more messaging/SHO transitions for a delta (TAdd-
TDrop) of 1 as opposed to 2 dB. TTDrop ranges from 1 (1 second) to 4 (6 seconds). This
should be set as long as possible to slow down messaging and Ping-Pong effects. From field
experience, TTDrop of 3 seems to require less cell site level optimization, but results in about
increase of 33% PSMMs and about 20% SHOs over a TTDrop setting of 4.
Real Life Target Setting - For lowered TAdd/TDrops more channel elements will be used and
initially the system will have lower FER due to diversity. Two examples, illuminate the issues
involved in this problem. The first network is at Tadd of -14 and Tdrop of -16, these values
were chosen after drive testing many tight corners - small cells, where the pilots would shift
strength rapidly requiring earlier PSMM(s). These settings caused some problems due to the
low thresholds, which forced the optimization issue of getting out of 3-way situations. The
best way to accomplish this is the reduction of TTDrop to bounce out of 3-way handoffs. The
channel element usage is higher than was originally designed due to this optimization. In a
second network, where these intense RF problems did not exist. TAdd is-12 and TDrop is -
13 by using these parameters the system has been much easier to optimize and the channel
utilization is lower, at about around 1.4 channel/subscriber. TTDrop for both systems is at 3
or 4 seconds for most of the cells.
System Deployment - For ease of deployment it is best to start with the same TAdd, TDrop,
TTDrop settings on all cells. First of all, it is simpler because after an SHO add occurs
between different cells, with different TTT settings the mobile will have a new set of TTT.
The algorithm used to combine TTT optimizes the parameters in order to allow the fast cell to
Motorola Confidential Proprietary 36
stay fast - lowest TAdd, highest TDrop, shortest TTDrop. If care is not taken when making
changes with respect to surrounding cells the mobile can be left in a state of soft handoff
Ping-Pong. This will occur when TAdd is lower than TDrop. A better method is to first
decrease TTDrop in situations where pilots get stuck in the active set during rapidly changing
conditions. For non-urban/high rise canyon environments, TAdd mode with TAdd of -12 and
TDrop of -13 with TTDrop of 3 is a good starting point.

After shuffle is introduced MAHO settings should be set to standard settings. This will ease
optimization and reduces messages after SHOs (In-Traffic-System message). Also, it does
work better to use a lower Tadd setting. See chapter on common optimization problems.
5.2 Parameter Descriptions
The following are the system database parameters which apply to handover. These are provided
in this document as a convenience to the reader. Please refer to the spreadsheet for default
values.
TAdd Pilot Detection Threshold - The threshold above which a pilot must rise in
order for the MS to transmit a pilot strength measurement message. The
system sends this parameter to the mobile station in the RF: System
Parameters Message, RF: Extended Handoff Direction Message, and the
RF: In Traffic System Parameters Message.
TComp Active Versus Candidate Set Comparison Threshold - The threshold which
a candidate set pilot strength must rise above an active set pilot to cause
the MS to transmit a pilot strength measurement message. The system
sends this parameter to the mobile station in the RF: System Parameters
Message, RF: Extended Handoff Direction Message, and the RF: In Traffic
System Parameters Message.
TDrop Pilot Drop Threshold - The threshold below which a pilot strength must
drop in order for the MS to transmit a pilot strength measurement message.
The system sends this parameter to the mobile station in the RF: System
Parameters Message, RF: Extended Handoff Direction Message, and the
RF: In Traffic System Parameters Message.
TTDrop Active or Candidate Set Drop Timer - The amount of time in seconds the
MS will allow an active or candidate set pilot strength to remain below the
drop threshold before action is taken to remove the pilot from the active or
candidate set. The system sends this parameter to the mobile station in the
RF: System Parameters Message, RF: Extended Handoff Direction
Message, and the RF: In Traffic System Parameters Message.
HandOffMode Specifies to the XC which handoff mode to use. Currently two modes are
defined. TAdd mode and TComp mode. TAdd mode tells the system to
Motorola Confidential Proprietary 37
add a pilot to a call as soon as it crosses the TAdd threshold. TComp mode
tells the system to wait for a pilot to rise above the TComp threshold
before it is added to a call. This data exists in the XC database, not in the
MIB.
PilotInc Pilot PN Sequence Offset Index Increment - The mobile station uses this
field to determine how remaining set pilots should be searched. It is set to
the largest increment such that the pilots of the neighboring sectors are
integer multiples of the increment. This data is sent to the mobile station in
the RF: Neighbor List Message and the RF: Neighbor List Update
Message. The XC must use the same value as is contained in the MIB.
This should be set as large as possible to speed up the search time for the
mobiles remaining set neighbors. Also, large PilotInc values allow for
large cells to be used without concern for PN-Offset ambiguity in PSMM
reports. However, the complications of re-using PN-Offsets (PN-Offset
Planning) pulls the PilotInc down to lower values. See Sams presentation
on this issue at http://www.pamd.cig.mot.com/~sfdez/pn.pdf
NeighborList Neighbor List - This list contains all of the neighbor sector PN offsets for
the current call. This parameter is passed to the XC in both the SCAP:
CDMA Update Parameters Message and the SCAP: CDMA XC Channel
Assigned Message. The neighbor list should be input in order. The order
is sorted by source to target handoff likely hood (or hits). The hit list is the
number of times that the neighbors in the target list were handoff
candidates for that source. Having the correct order will allow the mobile
to maintain the best neighbor list which greatly speeds up the search speed
for the best neighbor set. The list can be created with simulation or during
FOA activities. The maximum list for each sector is 20. However, the lists
should be minimized in order to allow the best combined lists to be sent in
the Update Neighbor list message, which is sent after a handoff addition.
Mobile Search Windows
*
SrchWinA The active pilot set search window size. This size is made large enough to
incorporate 95% of the expected delay spread energy. From delay spread
surveys this number was found to be 8 us. The window size has been set
to 5 which corresponds to 20 PN chips or 16 us. Since the active set
search window is based on the earliest arriving "usable" delay spread
component (IS-95A 6.6.2.1.4.1 / J-STD-008 2.6.2.1.4.1) for a given pilot
then we account for +- 8 us about that ray and hence would acquire about
95% of all delay spread energy. In some extreme cases for some sectors in
some cities usable rays will exist outside this window. Hence, this window
size also needs to be set on a per sector basis. This will be extremely
difficult to do without knowing the delay spread environment for each

3*
From a Motorola Internal Memo by Bob Love, 9/5/95.
Motorola Confidential Proprietary 38
sector. Just increasing all active pilot search window sizes would reduce
the likelihood of missing pathlogical rays (usable rays >8 us from earliest
arriving "usable" delay spread component) but at the expense of increasing
PN hypothesis search time. Increasing PN hypothesis search time would
increase soft handoff delay. Unless specific information is known for a
given site then I would still recommend using a SrchWinA size of 5 (+-8
us). If the site is on a waterfront across from other sites or is near
mountains then the size should probably be increased to 6 (+-11 us) or
more.
SrchWinN The Neighbor pilot set search window size. This size is made large enough
to account for differential time delay between the mobile and a potential
handoff cell given in the mobile's neighbor list. The worst case differential
delay would be the case when the mobile is next to a serving site and tries
to handoff to another distant site. Currently, the neighbor window size is
set to 6 (28 PN chips) which allows for a worst case separation of about 2
miles (3300 meters) between cells. If the mobile was "n" miles from its
serving site before going into handoff with a site slightly less than 2 miles
away from the mobile then the current setting would still work. There are
some sites in Hong Kong and Los Angeles that appear to handoff to sites
that are up to 4 miles away. For these sites, the SrchWinN size should be
increased to 8 (see (5) below) to account for the worst case SHO mobile
position possibility.
Window Size in terms of Distance (assume loss of 2 PN chips due to inaccuracies)
6 1.95 miles (3175 meters)
7 2.86 miles (4640 meters)
8 4.36 miles (7082 meters)
9 5.86 miles (9524 meters)
SrchWinR Similar to SrchWinN except the sites will typically be further away. Our
current infrastructure does not promote remaining set pilots to the
candidate set.
Motorola Confidential Proprietary 39
Chapter 6 Access and Setup Parameters
The call flow progression can be broken into idle, access, setup and stable traffic operation.
These generic catogories can be used in order to understand how the correct parameterization of
the system will effect the success rate and capacity of calls in a CDMA system. The most time
critical portion of a call is the transition from access to stable traffic since the mobile is
unprotected from interference from other pilots in the time before the system is able to add them
to the active set by means of handoff operations after arriving on the traffic channel.
6.1. Idle Parameters
The parameters that effect the performance of the mobile during its time spent on in idle mode are
shown. The success of good idle settings effects the ability of the system to respond to the first
probe. This quiets the mobile which is not under closed loop power control and allows for a
faster call setup, reducing the latency. The worst case occurs when the mobile has exhausted its
probe sequences or lost the paging channel during the origination attempt. The neighbor list is
used in idle mode to help the mobile search the best pn offsets. The correct active search
window allows the mulitpath to be used to enhance the current pilots Ec/Io as opposed to
causing self interference. The correct neighbor list window size allows the mobile to see new
pilots. The chart explains how each parameter plays is associated with successful idle settings
such that the mobile is on the best pilot during the origination.
Parameter Set High Set Low Set Correctly
Neighbor list order important
SrchWinA slows searcher misses multipath balance to get
multipath/speed
SrchWinN slows searcher misses neighbors must see far neighbors
SrchWinR slows searcher misses neighbors should be added to the
neighbor list
6.2 Access Parameters
The access attempt success is dependent on the strength of the probe received at the base station
and the window used by access channel. They key customer changable parameter is the cell
radius. Although the default value of 10 km covers 95% of urban cells adjustment may be
necessary for larger cells. In general , the access channel is set to provide the most rapid response
probe and probe response due to the importance of getting the mobile onto the traffic channel and
into n-way. The chart explains how each parameter plays is associated with successful access
settings such that the mobiles first probe is received by the access channel.
Parameter Set High Set Low Set Correctly
Cell Radius slows searching miss probes always pick larger than expected
cell size
AchPamEbNo miss good probes excessive falsing rate set to target falsing rate
AchPamIPer NA NA must match AchPamEbNo
Motorola Confidential Proprietary 40
AchPamWinSz slows searching miss probes always pick larger than expected
cell size
NumStep adds delay will not get full mobile tx
range
full range of mobile power
quickly
MaxCapSz adds delay multiple probes all dialing sequences should fit
into one probe
PamSz adds delay miss probes hardcoded/derived
Psist0To9 adds delay NA set to minimize delays
Psist10 adds delay NA set to minimize delays
Psist11 adds delay NA set to minimize delays
Psist12 adds delay NA set to minimize delays
Psist13 adds delay NA set to minimize delays
Psist14 adds delay NA set to minimize delays
Psist15 adds delay NA set to minimize delays
MsgPsist NA NA set to minimize delays
RegPsist NA NA set to minimize delays
ProbePnRan adds delay probe collisions set to minimize delays
ProbeBkoff adds delay probe collisions set to minimize delays
Bkoff adds delay probe collisions set to minimize delays
MaxReqSeq adds to delay of setup possible lower send-
connection ratios
set to minimize delays
MaxRspSeq adds to delay of setup possible lower send-
connection ratios
set to minimize delays
AccTmo excessive delay to 2nd probe NA set to response time of BS Ack
NomPwr excessive interference won't see first probe correctly set for highly loaded
sytem
InitPwr excessive interference won't see first probe correctly set for highly loaded
sytem
PwrStep full range of mobile power will not exercise range balance interference/power range
The following call flow shows a successful access attempt. Once the MM is aware of the call
activity, it will be logged for system statistics.
Motorola Confidential Proprietary 41
MSC MM FEP GPROC XCDR KSW GLI PG-ACC TCH MS
[1] Origination Message



[2] Base Station Ack Order
[3] Start T42m (12 sec)
[4] CHI: Channel Required


[5] LAPD: Channel Required
[6] LAN: Channel Required
MOBILE ACCESS PARAMETERS
Strength
OpenLoop + Nom + Init
Number of Probes


NumStep - number per sequence
MaxRespSeq,MaxReqSeq
Step up for each subseqent probe
PwrStep
Probe Size
PamSz - preamble size
MaxCapSz - maximum capsule size
Persistance Settings
Psist0-15
ProbePnRan, ProbeBkOff
BackOff
BTS RX ACCESS PARAMETERS
Access Threshold
AchPamEbNo
AchPamIPer
Cell Radius
BTS TX ACCESS PARAMETERS

Paging Channel Gain
PM PEG
PMC 10-1
PMC 20-5
6.3 Setup Parameters
The setup portion of the call flow begins with after the base station has acknowledged the
mobiles origination sequence. At this point, the system will record the success or failure of the
call in both the call detail logs and performance management system at the operations and
maintainance center (OMCR). The delay incurred in receiving the probe acknowledment and
the probe strength are the two reminents of the access channel that will effect call setup
performance. A fast channel assigment time is key to reducing the latency associated in placing
the mobile on the traffic channel. The parameters associated with call setup are shown below.
Parameter Set High Set Low Set Correctly
XC State 2 reserves mcc resource cause CFC6 set high enough to not get
CFC6
XC State 3 reserves mcc resource cause CFC7 set high enough to not get
CFC7
XC State 4 will not peg correct CFC cause CFC9 set high enough to not get
CFC9
XC State 7 will not peg correct CFC cause CFC13 set high enough to not get
CFC13
Acquistion Count delays XC state change
from invalid to valid
possible false set for minimal delay on
XC state change also used
to transition rf loss counter
MccCpT1 reserves mcc resource will cause no tch preamble set high enough to not get
CFC5
Orig Gain NA NA hardcoded to 127
Orig Delay excessive interference setup failures allow mobile to get into
SHO state
Motorola Confidential Proprietary 42
TchPamEbNo excessive interference high falsing rate set to target in lab
TchPamWinSz slows searching lock to multipath outside of
main ray
set to expected mulitpath
window
TchPamlPer NA NA tied to PamEbNo
The parameters are shown in the call flow. The first portion shows the parameters used up to the
point of sending out preamble to the mobile before the mobile has received the channel assign.
Note that some of the A+ and MM timers have been removed in order to reduce the complexity
of the call flow. The MM/A+ timers are used in order to remove resources in error legs and are
not usually triggered.
MSC MM FEP GPROC XCDR KSW GLI PG-ACC TCH MS
[22] LAPD: XC Channel Assigned
[23] Start XcCpT1
[24] MCAP: Traffic Channel BTS Link Request
XC PARAMETER
starts XC state 1,2 timer
PM PEGS
PMC 01-1
PMC 10-2
PMC 20-1
PMC 20-2
PMC 20-3
PMC 20-4
PMC 20-7
PMC 20-8
PMC 25-7
PMC 60-2
PMC 01-3
PMC 71-1
[30] MCAP: Traffic Channel State Change
[XCDR channel,New_State=MCC_idle, Invalid_Speech, or Valid_Speech]
[31] Stop XcCpT1
[32] LAPD: Channel Assigned
XC PARAMETER
state 2 complete
if XC state 2 expires
CFC=6 results
start state 3 timer
[34] CHI: Channel Assigned
[35] Start MccCpT1
[36] IS-95 frames
[37] CHI: Target Channel Designation
[CDMA Freq, WC, encryption mode=0,
frame offset=0,MIN, ESN, Band Class,
MSID Type, MS Prot. Rev., Transmit Addr]
BTS SETUP PARAMETERS
Transmit Preamble




Orig Gain
Timer MccCpT1 starts, after this
point if the mobile does not arrive on
TCH with premable a CFC will result
[33] LAPD: Channel Assigned
The next step is to send the channel assignment message on the paging channel and hope that he
mobile will be able to see the preamble frames being sent on the traffic channel. If the mobile
receives 2 frames in 200 ms it will transmit preamble back on the reverse link on the traffic
channel. If no mobile response is received in MccCpT1 the call final class CFC5 is pegged.
Motorola Confidential Proprietary 43
MSC MM FEP GPROC XCDR KSW GLI PG-ACC TCH MS
[34] CHI: Channel Assigned
[35] Start MccCpT1
[36] IS-95 frames
[37] CHI: Target Channel Designation
[CDMA Freq, WC, encryption mode=0,
frame offset=0,MIN, ESN, Band Class,
MSID Type, MS Prot. Rev., Transmit Addr]
[38] CHI: Target Channel Designation
[39] Start T200 * N200 retx
[40] Channel Assignment Message
[41] Stop T42m
BTS SETUP PARAMETERS
Transmit Preamble




Orig Gain
Timer MccCpT1 starts, after this
point if the mobile does not arrive on
TCH with no thc preamble a
[43] IS-95 frames
TCH Preamble
BTS SETUP PARAMETERS


Receive
TchPamEbNo, TchPamIPer
TchPanWinSz
Window centered at X chip delay
Search 125X before extending the
window size to TchAcqWinSz
After acquisition
TchMpthWinSz
TchMpthEbNo, TchMpthIPer
is used to control the finger
CFC5 will result
[45] Stop MccCpT1
BTS SETUP PARAMETERS
If timer MccCpT1 expires




CFC=5 results
which is a no TCH preamble
assignments
Once the mobile has shown his presence on the traffic channel by triggering the receivers
preamble threshold its time to start setting up the channel to the correct service option. Layer 2 is
used as the mechanism to repeat ack required messages until the various state timers expire if the
link is not performing well.
Motorola Confidential Proprietary 44
MSC MM FEP GPROC XCDR KSW GLI PG-ACC TCH MS
[50] MCAP: Traffic Channel State Change
[XCDR channel,New_State=Invalid Speech]
[51] Start XcCpT4
XC PARAMETER
state 3 completes
if XC state 3 expires
CFC=7 results
start state 4 timer
[52] MCAP: Layer 3 Message Request
[XCDR Channel,Magic Number,ackr=1,Base Station Acknowledgment Order]
[53] Base Station Acknowledgement Order
[ack_req]
[54] Mobile Station Ack Order
[55] IS-95 frames
Null TCH Data
[56] STRAU Speech frames
Eighth-rate, inner & outer CRC = 00
[57] PCM silent tone generated by XCDR
BTS SETUP PARAMETERS
Start Orig Delay timer which
XC PARAMETER
Acqusition Count
XC PARAMETER
ack required will use
the max retry count
for the number of retires
if expires CFC=3 results
will enable normal forward power
control after a fast ramp down
[59] MCAP: Traffic Channel State Change
[XCDR channel,New_State=Valid Speech ]
XC PARAMETER
state 4 complete
if XC state 4 expires
CFC=9 results
[60] Stop XcCpT4
which is cp timeout
awaiting acquisition
XC PARAMETER
After valid speech the rf loss
count will start XC state timer 9
and it will stop upon reception of
acquisition count frames CFC=4
The mobile is tied to one channel until after service option negociation is complete. The number
of pilots in the mobiles immediate area and the associated delays in setting up the channel will
result in CFC5,9,13s as the mobile losses a viable pilot due to fading/interference from the other
pilots.
Motorola Confidential Proprietary 45
MSC MM FEP GPROC XCDR KSW GLI PG-ACC TCH MS
[65] MCAP: Layer 3 Message Request
[XCDR Channel,Magic Number,ackr=1,
Service Option Response Order or Service Connect Message,
(ack_req,service option)]
[66] Service Option Response Order/Service Connect Message
[67] IS-95 frames
[68] Mobile Station Ack Order
[69] MCAP: Layer 3 Message Confirm

(Indicates that Service Option Response Order/Service Connect Message was acked)
[70] Service Connect Complete Message
(Sent if XCDR sent a Service Connect Message)
XC PARAMETER
if XC state 7 expires
CFC=13 results
which is no service option
acknowledgement
Motorola Confidential Proprietary 46
Chapter 7 Migration To a New Software Release
When a new software release is loaded onto the infrastructure, there will generally be parameter
changes that go along with that release due to algorithm changes, further testing, etc. Care
should be taken when doing these changes to ensure a smooth transition from one release to the
next. The following section is a general description of the order in which these changes should be
made and what statistics should be monitored for each. Its always recommended to complete at
least a one to two hour metric route drive after each step and analyze mobile logs for messaging
rates, FER, etc. The time frame of completing all of the changes will affect the appropriate soak
period of each step, but at least one day is needed to get a large enough sample size, preferably
three days or more.
Step 1 : Necessary Changes
The first step is taken immediately after the load. It includes all changes necessary to keep system
performance consistent with the previous load. These may include timers, database modifications,
or newly created parameters due to new features.
Monitor dropped call rate, access failure rate, soft handoff failure rate, and mm utilization
percentage through performance management statistics. Also, keep a close eye on CFC
percentages as timer changes can cause odd CFCs to occur (6, 80, 255, etc.) if not done properly.
See chapter six of this document for details on what CFCs are affected by the expiration of
particular timers.
Step 2 : Forward Power Control
Modifications of power control on the forward link should be done next. This should be done
second for a couple of reasons. First, the forward link is generally most sensitive to change
compared to the reverse link. There is obvious value to doing these changes early in order to
gauge their effects as soon as possible. Additionally, most CDMA systems are overwhelmingly
forward link limited. Therefore, the benefits of forward link parameter changes will be seen
earlier rather than later.
Categories of forward power control parameters are forward traffic channel gains (tchgain),
mobile station forward power control (msfpc), and base station forward power control (btsfpc).
It is generally recommended that tchgain changes be done first to ensure that the new settings do
not cause the gain to settle too low or have an undesired effect on the frame erasure rate. Msfpc
and btsfpc modifications will affect the speed of power control and can be completed after tchgain
changes.
Dropped call rate and soft handoff failure rate should be monitored. Forward FER and PMRM
rate are the most likely things to be affected by these changes and should be analyzed via a drive
test.
Motorola Confidential Proprietary 47
Step 3: PPS Powers
Next in line for possible changes, if recommended, are the ppsgains. These include the gain of the
pilot, paging, and sync channels. Sifpilotpwr is normally changed on a per sector basis and would
not be included in the modifications. These should come after the forward power control changes
because modifications of the power in the overhead channels can create holes if set too low and
cause excess interference if set too high.
Dropped call rate and access failure rate should be closely monitored after these changes. If
modifications are made to the paging channel, a drive test should include a before and after
analysis of the paging CRC error rate.
Step 4: Reverse Power Control
RPC changes (btsrpc) can be done later in the migration because small changes in the EbNos will
have little noticeable effect on system performance and are normally less critical due to most
systems forward link limitation. Lower nominal and minimum values will help to reduce
interference in reverse link limited scenarios.
Dropped call rate and access failure rate should be monitored via pm stats. If SMAP is available,
it would be valuable to compare reverse link FER performance.
Step 5: Other Changes
This step may include modifications of mobile initial power (msrpc), access channel (pachgen,
macc), reverse traffic channel (tchgen), timers (cpparms, aparms), or global handoff parameters
(maho). These will usually be minimal in number and may need to be changed in additional steps
depending on the volume and particular changes being made.
What to monitor will depend upon what changes were made. In case it isnt obvious yet, access
failure rate and dropped call rate are good things to keep an eye on. Additional statistics will
vary.
Motorola Confidential Proprietary 48
Chapter 8 Field Optimization Work Catogories
Unloaded CDMA system optimization is fairly straightforward. Here are the main activities that
comprise a thorough optimization process.
Coverage
Description/Purpose - A grid drive to show Ec/Io, mobile Tx power and other physical layer
quantities that will provide statistics in support of the margin that the system will have for
growth. It will not be able to predict call success rate.
Staff - 1 van driver, 1 mobile-dm /GPS operator, 1 BSC-SMAP operator.
Output - Ec/Io, forward/reverse erasure rates, mobile Tx power, SHO states all associated
with position. Poor coverage locations can be located. System design assumptions about
coverage, capacity, cell ownership can be confirmed.
Performed - Performed initially to spot equipment calibration, antenna problems, poor
coverage locations. Performed after optimization is complete. Performed after system is
commercial during busy hour to locate effects of cell breathing/loading.
Metric Route
Description/Purpose - A metric route is used to predict call success rate. It will also confirm
access windows/thresholds/performance. The metric route should consist of a drive
containing the highest automobile traffic highways/roads covering the city and be about one
hour in length. If you can not create a single Metric Route that requires less than one hour to
drive, then it is advisable to divide the metric route into smaller routes that meet the time
criteria.
Staff - 1 van driver, 1 mobile-dm /GPS operator, 1 BSC-SMAP operator.
Output - Call statistics including: origination attempt success rates, L-M and M-L success
rates, failure causes/locations, audio quality verification. Metric for commercial date
prediction.
Performed - Repeated until results are stable. Re-driven after SifPilotPwr changes or SHO
optimizations to check for unknown effects. And re-driven after tape upgrades.
Friendly User(s)
Description/Purpose - Allow either operator employers/friendly users or temporary worker
worker people to drive the system to make calls. Provides the quantity of calls and variability
in location required to optimize access windows (reduction), traffic acquisition windows, and
order neighbor lists.
Staff - 50 to 200 users, or 5-10 power users (paid to dial) for a total of at least 1000 calls a
day.
Output - Optimized access windows (reduction) from CDL logs, traffic acquisition windows
from SHO drops RF Losses, and order neighbor lists from the Call Proc-SCAP debug logs.
Call final cause (CFC) call metrics for system improvement metrics. Test physical hardware
(MCC/BBX) to purge poorly performing boards as represented in statistics from CDLs.
Performed - Ongoing, as soon as a cluster of cells is put on the air.
Motorola Confidential Proprietary 49
Motorola Confidential Proprietary 50
Trouble Shooting Team
Description/Purpose - Fix call drops, regions with poor frame erasure rates. Respond to
friendly user complaints. Track system performance-improvement milestones towards
commercialization goals. Prepare and train operator personnel for ongoing system
optimization/data collection.
Staff - 1 van driver, 1 mobile-dm /GPS operator, 1 BSC-SMAP operator.
Output - Analyze metric route statistics and coverage data. Provide recommendations for
parameter changes, cell site modifications, new cell sites backed with maps/statistical data.
Here is a flow chart showing one troubleshooting process for repeatable call drop or poor FER
regions.
Repeatable Call Drop or Poor FER
Good
Ec/Io
Yes
Stuck in
3-Way
Slow/No
ADD
Yes
Decrease
TTDrop on
Smallest
Cell
No
Try First
Second
Try
Change
SifPilotPwr
for Dominant
Server
Third
Try
Raise
TDrop
Yes
In
Neighbor
List
No
Add
Neighbor
Yes
Check
Neighbor
Order-Neighbor in
Combined list
No
Check reverse RSSI
Equipment-SPANS
ALARMS
No
Turn
Up Best
Server
2-3 dB
Not Fixed
Turn
off Possible
Interfering
Cells
Fixed
Start Adjusting SifPilotPwr
iin surrounding cells to uncover
cause of interference/See if
max levels hurt other reqions
Not Fixed
Turn
Up Serving
Cell to
Max
Not
Fixed
Look
for AMPS
Towers
Yes
Add a Colocated Site
Add a new cell or
change Metric Route
No
Fixed
Done
Done
No
Change Order
Redrive
Yes
Decode Mobile PSMM
and Searcher Datadetermine
where the mobile is searching-
Force dominate server
Check
mobile
window
sizes
Increase to see
neighbors
small
ok
Circle-your done or redrive until done
Rectangle-Trouble shooting tip, redrive if not fixed, start at top
Motorola Confidential Proprietary 51
Chapter 9 Field Optimization Procedures
There are a number of problems that Motorola CDMA systems encounter over and over during
the optimization process. The following section brakes down these issues into two parts: general
optimization problems and unique scenarios.
9.1 Common Problems with General Optimization
9.1.1 No Dominant Pilot
Background
The overwhelming cause of dropped calls and setup failures in CDMA systems is the lack of a
dominant pilot in the area of the mobile. A lack of dominance is revealed in low Ec/Io levels,
numerous pilots with similar values of Ec/Io, and four or more pilots above the TAdd threshold.
Optimization Techniques
The best options for creating a dominant pilot in an area are antenna adjustments and modification
of the sifpilotpwr. In most cases, antenna downtilt will be the best fix for eliminating overshoot
from a second-tier cell. Downtilt, along with antenna azimuth changes are a good ways to focus
the energy of the sector into or out of a problem area. If these solutions are not an option or do
not work, the power of the sector can be modified by changing the sifpilotpwr.
The tendency seems to be to increase pilot powers all around the area until a solution or until all
the cells are up to their max sif-pilot power level. Its better to try to pull back SHO boundaries
by reducing the power. This has the benefit of keeping forward link power at a minimum, thus
reducing overall interference and saving room for the LPA. One method to see which pilot would
best cover a region is to pick the hoped for best server and turn back the other cells. This will
check to see if the cell can cover the region if the others cells are out of the way. If this step is
successful, the other cells can be turned up slowly to see which set of pilots works best in the
local area.
Systems that have the fast pilot shuffling feature (release 2.5.2 and later) will rarely require
optimization of handoff parameters on a sector by sector basis. Its a common mistake to try to
speed up handoffs in areas with a lack of dominance. This technique does not usually help the
dropped call rate and only causes additional handoffs, exacerbating issues of MM capacity. The
default values of -14/-16/4/3 for TAdd/TDrop/TComp/TTDrop should work fine for nearly all
scenarios and should not require optimization.
Implementation
The following command will change the power:
edit sector-x-y ppsgain sifpilotpwr=33
Monitoring
Motorola Confidential Proprietary 52
Well chosen metric routes are key to understanding how the changes that are made affect the
performance of the network as a whole. Metric statistics on access failure rate and dropped call
rate will paint a good picture. Also, mobile logs can analyzed for dominance criteria by evaluating
the contents of the PSMMs. See a description of the npar_parser script in the Scripts and Tools
chapter of this document.
9.2 Unique Optimization Cases
9.2.1 Origination and Handoff to Far (>4 miles) Away Sites
Background
There are several search windows that may need to be increased for sites that have a greater
radius than four or five miles. Refer to the chapter on Cell Size Parameters for detailed
descriptions of the parameters and tables correlating window size to distance.
Optimization Techniques
The access channel range is determined by the cell radius. Calls that are attempted beyond this
range will fail and will not show up in the call stats from the CBSCs perspective. In addition, the
tchacqwinsz needs to be set at least as large as this radius to get the mobile onto the traffic
channel. Additionally, the mobile search windows for the active, neighbor, and remaining set
pilots need to be large enough such that the mobile will search far enough in time to see rays from
far away sights. Otherwise, the mobile will never scan these rays and hence, could not enter into
soft handoff with these sectors.
Implementation
The following commands will make the necessary changes:
edit sector-x-y secgen radius=8.1 to set the radius of the cell in kilometers
edit sector-x-y tchgen acqwinsz=75 to set the SHO window size
edit sector-x-y maho srchwinn=8 to set the mobile neighbor search window
Monitoring
CDL statistics can be analyzed to determine the need to enlarge or shrink the radius of a cell. Use
the access.c script detailed in chapter 12 to tell if there are access attempts near the edge of the
cell. If this is the case, the radius can be enlarged, and subsequent CDL analysis will reveal
whether or not further tweaking is necessary.
9.2.2 Hard Handoff Optimization
Non-Beacon
Background
The initial rollout of inter-cbsc hard handoff quickly revealed poor performance along the seams.
There is not a good method to avoid a ping/pong except to use pilot beacons. However, if
beacons are not used, here is how to give calls a chance at success.
Motorola Confidential Proprietary 53
Optimization Techniques
Once given the geographic contraints the best chance to succeed is to increase Tcomp to a larger
value than 4dB. This only works, however, if the overlapping pilots on the opposing HHO seam
meet at strong Ec/Io values (there exists enough overlap). The rule of thumb is that if Tcomp
can be made to force the HHO direction message to come in at values above -13 to -14 at the
source site the message has a fairly good chance of making it through. If the overlapping zone
meets at -12 to -13 Ec/Ios the Tcomp value must be lower in order to allow the target pilot to
become better while the source is still above -13/-14 dB.
Implementation
Use the following command to make the change:
edit sector-x-y maho tcomp=4
Monitoring
This scenario is difficult to determine the success rate of using CDLs. The reason is that a CDL is
created each time the mobile exits the CBSC. Therefore, the number of CFC01s will be inflated if
the mobile ping/pongs back and forth between CBSCs even though the call may eventually drop.
It is more appropriate to use drive routes over the seam to evaluate performance.
Pilot Beacon Optimization
Background
The problem of ping/pong described above is helped dramatically by the implementation of pilot
beacons on the seam between CBSCs. Cells along the seam are deployed with pilot beacons that
are on the same frequency as the carrier of the other CBSC. The pilot level of the beacon iset
significantly lower than that of the actual carrier to cause the mobile to be well inside the coverage
of the target CBSC before the hard handoff is attempted. The diagram below shows the relatively
large hysteresis zone that helps to mitigate ping/pong.
Motorola Confidential Proprietary 54
Optimization Techniques
If a coverage hole exists, follow these steps to rectify the problem. The overlap at the seam
should provide a handoff region where the source Ec/Io is > -10 dB and the target is > -10 dB
after the transition has taken place. The first step is to adjust the source TCH sifpilotpwr level to
provide coverage into the beacon spot. The range for this adjustment is 33-37 dBm. This should
only be done after analysis shows poor coverage. After increasing the Sifpilot power the neighbor
lists should be re-examined to insure that newly created neighbor pairs are placed in the neighbor
lists. If the coverage across the seam is still inadequate, the beacon sifpilotpwr should be
increased, but care should be taken not to increase it so much as to cause ping/pong to occur.
Finally, if the region is still not satisfactory, lower Tcomp from the standard value in order to
trigger the hard handoff quicker.
To decrease bouncing (ping/pong), the first step is to adjust the source TCH sifpilotpwr level to
provide coverage into the beacon spot. The range for this adjustment is 27-33 dBm. This should
only be done after analysis shows too much coverage (excessive overlap). The region should be
re-driven in order to insure that coverage still exists for the entire sector. The second method is
to decrease the sifpilotpwr of the pilot beacon in the inwardly pointing sector. The region should
be redriven in order to insure that the overlap still occurs at good Ec/Io levels. The third method
is to increase Tcomp from the standard value in 1 dB steps. This will only be effective if the
overlapping coverage is good (in which case method 1-2 should provide effective reduction of the
bounces).
Implementation
Extent of F2 Coverage
Extent of F1 Coverage
X
X
X
X
X
X
F2 Beacons @ F1 Cells
F1 Beacons @ F2 Cells
F2 Cells->
<- F1 Cells
Motorola Confidential Proprietary 55
Use the following commands to optimize the border:
edit sector-x-y maho tcomp=4
edit sector-x-y ppsgain sifpilotpwr=33
Monitoring
It is still best to use drive routes to evaluate performance along the seam. However, it can be
fairly accurate to additionally use CFCs if there is confidence that ping/pong has been eliminated.
9.2.3 Controlling Soft Handoffs
Slow MAHO
Background
The current MAHO defaults of -14/-16/4/3 (tadd/tdrop/tcomp/ttdrop) combined with the fast
pilot shuffling algorithm cause excessive soft handoff transitions to occur. Many of these are
unnecessary for maintaining successful calls. These excess handoffs can significantly increase
MM utilization and hence decrease capacity.
The current fast pilot shuffling algorithm will cause a soft drop and subsequent soft add to occur
while in three-way soft handoff for two reasons. If a candidate pilot is greater than tadd and
better than two of the actives (figure one) or is tcomp better than one of the actives (figure two),
a shuffle will start. The scenario which often occurs but is not needed is that a mobile is in three-
way sho with a strong active pilot at Ec/Io > -8dB and an additional active at tdrop or lower.
With only a 4dB threshold of tcomp, a relatively weak pilot can easily trigger a shuffle if the worst
active falls to a low level. Raising tcomp to its maximum database value of 7.5dB will
significantly dampen the number of occurances similar to the one in figure two.
Motorola Confidential Proprietary 56
TADD PILOT SHUFFLE
-20
-18
-16
-14
-12
-10
-8
-6
-4
-2
0
A (active) B (active) C (active) D (candidate)
Pilot
E
c
/
I
o
Figure One
TCOMP PILOT SHUFFLE
-20
-18
-16
-14
-12
-10
-8
-6
-4
-2
0
A (active) B (active) C (active) D (candidate)
Pilot
E
c
/
I
o
Figure Two
Motorola Confidential Proprietary 57
Implementation
It is recommended that this change is rolled out on an incremental basis across the system. Start
with a ten to twenty cell cluster in a relatively flat geographic area, i.e. suburban as opposed to
dense urban. The are two situations where caution should be taken in raising tcomp. One is
dense urban areas where severe cornering scenarios may require a very quick addition of a pilot.
A higher value of tcomp will tend to slow the mobiles reporting of a candidate pilot, and
therefore could cause drop calls in severe environments. The other situation is along hard handoff
borders where a high tcomp may not allow an easy transition between CBSCs. Preliminary
driving should be done to test the higher tcomp in these areas.
The following command will commence MAHO changes for the appropriate sites: edit sector-
bts#-sector# tcomp=7.5. This should be executed from a CLI prompt on the OMC-R.
Monitoring
There are a number of options available for determing the effects of the changes. They include
mobile DM logs, PM statistics, and CDL logs. Analysis of statistics should only be done on cells
and/or sectors that are completely embedded within the test area. Sectors which border cells with
a different tcomp value will not show nearly as much of a change in sho transitions since the
mobile uses the lowest value of tcomp when in soft handoff.
Before and after PM data that should be considered are soft and softer target handoffs as well as
channel element usage. If these are not already generated on a daily basis, the following
commands can be used to create the reports on either a bts or sector basis:
generate pmreport softtgt bts=bts# sector=sector#
generate pmreport softertgt bts=bts# sector=sector#
generate pmreport mccceusage bts=bts# sector=sector#
Divide the total number of handoffs and the channel element usage by the total number of
completed calls to determine the delta in handoff transitions per call and element usage per call,
respectively.
Use call detail logs to compare access failure and dropped call performance. Ggrep or browse
CDLs for the access bts/sector of the embedded cells and tabulate the CFCs. CFC04s, 05s, and
09s will reflect any change.
Its also suggested that a before and after drive test is done within the test area not only to have
another measure of the delta in handoff transitions but also to check for particular areas that may
have been adversely affected by the changes. Count the number of soft handoffs via DM logs.
Transcoder Filter
Background
The transcoder filter provides a means of filtering PSMMs based on the Ec/Io values of the active
and candidate pilots. It is meant to increase the capacity of the MM by reducing the total number
of handoffs. The contents of each PSMM are analyzed by the transcoder to determine whether to
pass it along to the MM or discard it. It only filters Tadd and Tcomp events, not drop events.
Motorola Confidential Proprietary 58
Four parameters are associated with its operation: one_two_way, two_three_way, xc_thresh, and
act_state. The filter will discard a PSMM if any of the following are true:
If one active and active pilot > one_two_way
If two actives and one active > two_three_way
If current number of actives >= act_state and all candidates < xc_thresh
The combination of xc_thresh and act_state is meant to not allow tcomp events to trigger
handoffs with a candidate below tadd. The one_two_way and two_three_way parms cause adds
to be rejected by the XC if a dominant pilot is already in the active set.
General Guidelines
The filters purpose is to increase capacity on the MM. If this is not an issue, it does not need
to be used.
The following results can be expected, depending on the filter settings:
Decrease in handoffs per call
Increase in FER, PMRM rate
Slight decrease in SHO factor
Performance may differ by mobile manufacturer. Its important to monitor statistics on each.
The algorithm used has exposed deficiencies in certain non-Qualcomm mobiles to date.
Implementation
There are two MMI commands related to the filter. To display the current settings, type
disp_xc_thresh_params. Since the filter is defaulted off, the following should result:
The XC Threshold Negotiation Parameters:
One-Two Way parameter = 0
Two-Three Way parameter = 0
XC Threshold parameter = 63
Active State parameter = 3
To change the settings, type set_xc_thresh_params. No outage is required for the new settings to
take affect. Prompts will come up one at a time to allow the parameters to be modified. The
thresholds are set in half dB increments. It is recommended that the filter parameters are put in
slowly to ensure that dropped call performance and call quality remain acceptable. The table
shows the recommended settings for each step.
Capacity benefits and the effects on performance will vary depending on a few factors, namely
current MAHO settings and the RF environment (dominance). The messaging gains in each step
are estimates over the initial settings based on the FOA of the feature. Capacity benefit in the
MM relative to the reduction in soft handoffs may also vary, but the FOA revealed that the 40%
sho reduction corresponded to about 20% lower MM CPU utilization (from 85% to 65%).
Implementation Steps
one_two_way two_three_way xc_thresh act_state est. sho reduction
Motorola Confidential Proprietary 59
Initial 0 0 63 3 N/A
Step 1 0 0 28 (-14dB) 1 15%
Step 2 9 (-4.5dB) 11 (-5.5dB) 28 (-14dB) 1 17%
Step 3 11 (-5.5dB) 13 (-6.5dB) 28 (-14dB) 1 20%
Step 4 13 (-6.5dB) 15 (-7.5dB) 28 (-14dB) 1 30%
Step 5 14 (-7dB) 16 (-8dB) 28 (-14dB) 1 35%
Step 6 15 (-7.5dB) 17 (-8.5dB) 28 (-14dB) 1 40%
Step one should not show any degradation in performance. In fact, the frame erasure rate should
be slightly better because unnecessary shuffling from three to two to three way soft handoff will
be somewhat mitigated. The value of -14 is chosen because that is the default value of tadd. If a
different default of tadd is being used, set xc_thresh to the same value, but please note that -14 is
strongly recommended for optimal system performance with or without the filter. The effects of
this step are similar to that of slowmaho (7.5dB tcomp) both in the type of handoffs that will not
occur and in the MM capacity benefit. If MM capacity is not an issue for the particular market,
stop here. There is no reason to go on to additional steps.
Before completing step two, the value of tcomp for all sectors should be set to 4dB. This is
extremely important because higher or lower values of tcomp may result in poor dropped call
performance. The following command will need to be run on each sector: edit sector-bts#-
sector# maho tcomp=4. Now the filter can be set to 9/11 for one_two_way/two_three_way.
This is a very conservative step and will not likely yield much benefit, but it will help ensure that
performance does not degrade.
Steps three through six will incrementally reduce the number of soft handoffs. The FER will
likely begin to rise with each step. Follow the instructions in the monitoring section to determine
acceptable performance. Step six contains the most aggressive settings that could be used in the
FOA without seeing a measurable increase in the overall dropped call rate. More aggressive
settings than this will yield additional MM capacity benefit, but will likely cause the dropped call
rate to increase.
Monitoring
At a bare minimum, CFC04s should be monitored after each step to ensure there is no
degradation outside of normal day-to-day variations. Watching MM CPU utilization will show
the overall benefit received by the changes. Its also important to break out CFCs by mobile
manufacturer as some may respond diffently to the filter than others. Critical is the speed of the
mobile in reporting PSMMs.
Its also recommended that PM statistics and DM logs are analyzed to fully understand the affects
of the filter. Mobile logs from a system metric route should be used to determine the delta in FER
caused by the filter. This is expected to rise. Other useful information that can be obtained from
these logs includes number of handoff transitions (measured by handoff completion messages) and
soft handoff factor. Both of these should decrease.
Motorola Confidential Proprietary 60
Before and after PM data that should be considered is soft handoffs per call. This can be
measured by looking at soft and softer target handoffs and comparing to total successful
originations and terminations. If these are not already generated on a daily basis, the following
commands can be used to create the reports:
generate pmreport softtgt
generate pmreport softertgt
generate pmreport cbscsum
Divide the total number of handoffs (adds and drops) by the total number of completed calls to
determine the delta in handoff transitions per call.
9.2.4 2nd Carrier Implementation
Motorolas Multiple Carrier Cellular Application Note contains much more detail on what, why,
and how to set up additional carriers. It is recommended reading before starting to plan for a
second carrier. This section is meant to be a quick explanation on how to set up the database
tables and some key performance concepts.
The following is a theoretical setup where frequency 550 is a ubiquitous carrier across the entire
system and frequency 525 is overlaid on a group of core cells. This configuration requires
mobiles that have calls up on 525 in the core to be handed down to 550 as they exit the core. One
of two methods can be used to make the transition, MAHO and DAHO. Both obviously require a
hard handoff. The MAHO method also requires implementing pilot beacons on the border cells
on each side of the seam.
This example goes through a DAHO setup. The cell/sector used here is set up as follows: on
cbsc-2, sector-18-1, primary carrier-1 (550), secondary carrier-2 (525). Carrier-18-1-2 is
designated as DAHO so that it will throw calls down to carrier-18-1-1 on a hard hand-in.
Handing off in this fashion from one carrier to another on the same sector is really the only way to
ensure decent performance. The key is that when the handoff is attempted, the sector/carrier that
is the target must be able to provide a good enough link to the mobile to prevent a dropped call.
This requires the footprint of the target to be similar to that of the source.
There are two sections that are used for making the transition. One for the outroute and one for
the inroute.
The application note includes a table that is used to make a determination on when to transition
from one carrier to another. The appropriate number of active links must be DAHO sectors to
trigger a jump. Once the criterion is met, a hysterysis timer, shown in table one, is started. Upon
expiration of the timer, an attempt will be made to hand off to another carrier. Ten seconds is the
recommended length of the timer and is set on a cbsc basis.
COMMAND="DISPLAY CBSC-2 DAHOHYST "
CBSC DAHOHYSTIMER
(sec)
PNHYSMARGIN
(100 ns)
Motorola Confidential Proprietary 61
CBSC-2 10 0
Table 1
Since carrier 2 is used for transition to hand out, the DAHO flag is set to yes in the dahoparms
table below (table 2). The ORI is the out route index which points to outroute-2-1 in the
outroute table.
COMMAND="DISPLAY CARRIER-18-1-2 DAHOPARMS "
CARRIER FLAG ORI PHASETHOLD
(100ns)
CARRIER-18-1-2 Y 1 0
Table 2
The outroute can have up to four possible targets. Each target will eventually point to an external
sector. Theres only one target specified in table 3 because the intention is to handoff from carrier
two to carrier one of sector-18-1.
COMMAND="DISPLAY CBSC-2 OUTROUTE "
OUTROUTE ORI TARGET1 TARGET2 TARGET3 TARGET4
OUTROUTE-2-
1
1 1 - - -
Table 3
Each target above corresponds to a route number in the routenum table below. So target1 = 1
from table 3 corresponds to routenum = 1 in table 4 which specifies an external sector.
COMMAND="DISPLAY CARRIER-18-1-2 ROUTENUM ROUTE="
CARRIER ROUTENUM EXTERNAL SECTOR
CARRIER-18-1-2 1 XCSECT-2-49
Table 4
The external sector is specified in the xcsect table (table 5). The cellid is the bts and sector
number combined into one hex number. To convert sector-18-1 to hex, convert decimal 18 -->
binary 010010 and decimal 1 --> binary 001. Tack the 001 on to the end to get binary 010010001
and convert this number to hex 0x0091. Fill in the pn, hard for hard/soft since this is a hard
handoff, correct service option, and the rest of the pertinent information.
COMMAND="DISPLAY CBSC-2 XCSECT "
XCSECT ID CELL ID ... PILOT
PN
SOFT/
HARD
SERV
OP1
...
XCSECT-2-49 0x0091 ... 107 HARD 0X8000 ...
Table 5
Motorola Confidential Proprietary 62
The inroute path begins at the call distribution table. Since we want hard hand-ins to fall to the
primary carrier, the hhandindist is set to current carrier. New calls are set to round robin to
alternate accesses from one carrier to the other regardless of the carrier that the mobile is paging
on. The decision on whether to direct new calls (originations and terminations) to the current
carrier or use a round robin format will depend on what distribution of mobiles on each carrier is
desired.
COMMAND="DISPLAY CBSC-2 CALLDIST "
CBSC NEWCALLDIST HHANDINDIST
CBSC-2 ROUNDROB CURCAR
Table 6
The carrier select table (table 7) below contains information on which inroute index (IRI) is to be
used for both current carrier and round robin formats. In this case, both will use inroute-2-1.
COMMAND="DISPLAY CARRIER-18-1-1 CARRSELECT "
CARRIER CURRENT-CARRIER TEST-MOBILE ROUND-ROBIN
CARRIER-18-1-1 1 0 1
Table 7
Up to four carriers can be specified for use in the inroute table (table 8). If current carrier is being
used, the first carrier will always be chosen. If round robin is utilized, each carrier in the table will
be used in sequence. In this example, hard hand-ins always go to carrier 1, and new calls alternate
between carrier 1 and carrier 2.
COMMAND="DISPLAY CBSC-2 INROUTE "
INROUTE IRI FIRSTCAR SECCAR THIRDCAR FOURTHCAR
INROUTE-2-1 1 1 2 - -
Table 8
It will again be important for different carriers on the same sector to have very similar footprints.
If the sizes are different, originations may fail due to a poor forward link when the call is
redirected to the other carrier.
Motorola Confidential Proprietary 63
Chapter 10 N-Way and You
10.1 Background
The introduction of n-way soft handoff in release 8.1 represents a major change in the handoff
algorithm. There are three major components: Pilot Dominance (XC filtering), MM handoff
processing (shuffles), and complex soft handoffs.
10.1.1 Pilot Dominance
The XC filtering feature is modified from the release 7 version. The goal of the filter is two-fold:
lower soft handoff factor and lower soft handoff rate. Previously, the filter would look at
individual pilot strengths, and decide to discard the PSMM based on the call state and Ec/Io value
of the strongest active pilot. In the R8.1 version, also called pilot dominance, the PSMM may be
discarded if the aggregate Ec/Io of the active set exceeds a certain value. In addition, the new
version adds a back door where the PSMM may be passed on if a candidate pilot is sufficiently
strong. More detail is provided in the XC filtering section of this document.
10.1.2 MM Handoff Processing
Prior to release 8.1, a maximum active set size of three pilots was supported. Due to this
limitation, a feature was implemented to move pilots in and out of the active set more quickly.
Called Fast Pilot Shuffling, FPS allowed a relatively strong candidate pilot to trigger a shuffle
where the worst active pilot is dropped, then the best candidate is subsequently added. While this
feature was a significant improvement, its relative slowness in completing the full shuffle process
combined with the inability to support more than three active set pilots at any one time has
resulted in higher RFLoss rates than desired.
The shuffling, or MM filtering, method of R8.1 adds some complexity. Up to six pilots can now
be supported in the active set from a maximum of three base stations. The transcoder has a
limitation of handling up to three channel elements in a call at any one time; hence, the three BTS
limit. A set of parameters is available to limit the number of legs and elements used in a call.
Based on these parameter settings, one of three different shuffles may be attempted in order to
keep the active set within those settings: soft shuffle, BTS shuffle, and soft shuffle. Algorithm
details are provided in the MM Filtering section.
10.1.3 Complex SHO
This release also introduces the ability to do complex adds and drops. Complex soft handoff is
the ability to add or drop more than one pilot with a single handoff direction message. Multiple
pilots from the same BTS can be either added or dropped in one operation. If, in the handoff
determine process in the MM, it is determined that more than one pilot should be added to the
active set, and those pilots are from the same BTS, they will be added in one operation. The same
is true if two pilots from the same BTS are to be dropped from the active set.
Motorola Confidential Proprietary 64
This paper will cover the details of the n-way feature. Included are the following:
New parameters introduced in the constraint tables
Pilot dominance
MM handoff processing with softer, BTS, and soft shuffles
Migration plan
Recommended parameter sets and performance trends
Interaction with other features
CDL and PM indicators
10.2 N-Way Components and Algorithms
10.2.1 Enable vs. Disable
The n-way feature is enabled at the CBSC level: display cbsc-x softhoparms. Enabling and
disabling this feature only controls the MM filtering portion of the feature. It does not turn on
and off the XC filtering. To turn this part off, it must be parameterized out. Details on how to
turn off the filtering are included in the migration section. Disabling complex SHO will cause the
following:
Complex soft handoffs, i.e. multiple adds and drops, are not allowed.
MaxActiveSetSize and MaxCEPerCall are hardcoded to three.
A maximum of two softer legs per channel element is supported.
If a shuffle is needed, the previous fast pilot shuffling algorithm is used.
COMMAND = DISPLAY CBSC-1 SOFTHOPARMS
CBSC (cbsc#) COMPLEXSHOENA SENDHOPERFORMMSG
1 ENABLE OFF
Setting ComplexSHOEna to enable will cause the following:
Complex soft handoffs are allowed.
Active set is constrained by MaxActiveSetSize, MaxCEPerCall, and MaxBTSLegsN.
If a shuffle is needed, a softer, BTS, or soft shuffle will be attempted.
Individual shuffle types must be enabled to be attempted.
Fast pilot shuffling is not used.
10.2.2 Constraint Tables
The database contains sixteen constraint tables that define the parameters for this feature. Each
carrier-sector must point to one of the constraint tables using the following table: display cbsc-x
hoconstrusers. In the example below, carrier-111-1-1 points to constraint table 1-1. This table is
only a display it cannot be edited. The sectors constraint table is set in the maho table: display
bts-111 maho. Also, note that each ictrkgrp must point to a constraint table. This is used when a
call is utilizing inter-cbsc soft handoff. The trunk group will always use this constraint table. It is
Motorola Confidential Proprietary 65
set in the following table: display cbsc-1 ictrkconf. If no constraint table is entered for a particular
carrier-sector or ictrkgrp, it will default to constraint table 1. Also, note that when a call is in
SHO, the constraint table for the strongest active leg will be used.
COMMAND = DISPLAY CBSC-1 HOCONSTRUSERS
HOCONSTR
(cbsc#-
hoconstr#)
HOCONSTR USER
(bts#-sec#-car#)
1-1 CARRIER-111-1-1
1-1 CARRIER-111-2-1
1-1 CARRIER-177-3-1
1-2 ICTRKGRP-1-1
1-3 none
1-4 none
1-5 CARRIER-100-1-1

1-16 none
The constraint tables are displayed with two commands: display cbsc-x detection and display
cbsc-x shuffle. Using these tables, a different set of parameters can be populated in each. In
SHO, the table pointing to the strongest active pilot will be used.
COMMAND = DISPLAY CBSC-1 DETECTION
HOCONSTR
(cbsc#-
hoconstr#)
MAXACTIVE-
SETSIZE
(dB)
MAXCE-
PERCALL
(dB)
MAXBTS-
LEGS1
(dB)
MAXBTS-
LEGS2
(dB)
MAXBTS-
LEGS3
(dB)

1-1 6 3 3 2 2
1-2 6 3 3 2 2

1-16 6 3 3 2 2
TCOMPENA-
THRSH
XC-
TCOMP
AGG-
STRENGTH1
AGG-
STRENGTH2
AGG-
STRENGTH3
NUM-
CANDIDATE
-14.5 4.5 -5 -7 -9 10
-14.5 4.5 -5 -7 -9 10

-14.5 4.5 -5 -7 -9 10
COMMAND = DISPLAY CBSC-1 SHUFFLE
HOCONSTR
(cbsc#-
hoconstr#)
SOFTER-
SHUFFLE-
COMP
(dB)
BTS-
SHUFFLE-
COMP
(dB)
SOFT-
SHUFFLE-
COMP
(dB)
ENA-
SOFTER-
SHUFFLE
ENA-BTS-
SHUFFLE
ENA-SOFT-
SHUFFLE
Motorola Confidential Proprietary 66
1-1 3 3 3 ENABLE ENABLE ENABLE
1-2 3 3 3 ENABLE ENABLE ENABLE

1-16 3 3 3 ENABLE ENABLE ENABLE
Each parameter is described later in the document. They are used in the following functions:
XC Filtering - AggStrength1, AggStrength2, AggStrength3, TCompEnaThrsh, XCTComp
MM Filtering - MaxActiveSetSize, MaxCEPerCall, MaxBTSLegs1, MaxBTSLegs2,
MaxBTSLegs3
Softer Shuffle EnaSofterShuffle, SofterShuffleComp, TCompEnaThrsh
BTS Shuffle EnaBTSShuffle, BTSShuffleComp
Soft Shuffle EnaSoftShuffle, SoftShuffleComp, TCompEnaThrsh
10.2.3 Pilot Dominance
The transcoder filtering function - also referred to as pilot dominance - aims to lower the soft
handoff rate and soft handoff factor by reducing unnecessary additions of pilots to the active set.
By filtering PSMMs at the XC level, MM utilization is reduced by eliminating unnecessary
handoff activity. Often in a call, PSMMs are generated by the mobile with add requests, but the
Ec/Io level is relatively poor. In this case, adding the pilot to the active set would contribute little
help to the call, but would increase activity in the MM by requiring a handoff operation and would
raise the soft handoff factor.
Upon receiving a PSMM, there are three conditions under which the CPP will send a handoff
recognized message to the mobility manager:
Aggregate strength of the keep active pilots is less than AggStrengthN
Strongest candidate is XCTComp greater than any keep active and greater than
TCompEnaThrsh
TDrop event
*A keep active refers to an active pilot in a PSMM with the keep flag set to one.
The aggregate strength check is done to eliminate the need to add more pilots when the active set
already exceeds a certain Ec/Io value. If the active set does not meet this value, a handoff
recognized message is passed to the MM for handoff consideration. However, if the active set
does meet this threshold, a second back door check is done to allow a strong candidate to be
added even though the active set is relatively strong. It requires that the candidate be stronger
than a minimum threshold (TcompEnaThrsh), and that it exceeds the strength of the weakest
active pilot by some level (XCTComp). This back door check helps to ensure that the filter does
not cause more dropped calls to occur under rapidly changing pilot conditions.
To help guard against dropped calls due to discarded PSMMs, an enhancement is added to the
pilot dominance algorithm. The enhancement uses PMRMs (Power Measurement Report
Messages) generated by the mobile to trigger additional PSMMs. When a PSMM is discarded by
the transcoder, a flag is set. If a PMRM is subsequently received and the flag is set, the aggregate
Motorola Confidential Proprietary 67
strength of the pilots in the PMRM is compared to the appropriate AggStrengthN threshold. If
the aggregate strength is below this threshold, a PMRO (Pilot Measurement Request Order) is
sent to the mobile requesting another PSMM, and the flag is reset.
AggStrength1 Aggregate strength threshold used for filtering PSMMs when 1 BTS is active.
The aggregate strength of the active pilots must be less than this value for the PSMM to be
passed to the MM. A lower setting will cause more PSMMs to be discarded. Range: -31.5dB to
8.0dB in 0.5 dB increments.
AggStrength2 Aggregate strength threshold used for filtering PSMMs when 2 BTSs are active.
The aggregate strength of the active pilots must be less than this value for the PSMM to be
passed to the MM. A lower setting will cause more PSMMs to be discarded. Range: -31.5dB to
8.0dB in 0.5 dB increments.
AggStrength3 Aggregate strength threshold used for filtering PSMMs when 3 BTSs are active.
The aggregate strength of the active pilots must be less than this value for the PSMM to be
passed to the MM. A lower setting will cause more PSMMs to be discarded. Range: -31.5dB to
8.0dB in 0.5 dB increments.
TCompEnaThrsh Minimum threshold for a candidate to be considered for addition to the active
set. Used in the back door portion of the XC filter, it requires that the candidate pilot is greater
than this value to be passed along to the MM. This parameter is also used in a similar role in the
MM for soft and softer shuffle checks. A higher setting will cause more PSMMs to be discarded.
Range: -31.5dB to 0.0dB in 0.5dB increments.
XCTComp Also used in the back door portion of the XC filter, this parameter is the threshold
for which a pilot must be greater than the weakest active to be passed to the MM. A higher
setting will cause more PSMMs to be discarded. Range: 0.0dB to 31.5dB in 0.5dB increments.
Motorola Confidential Proprietary 68
Figure 1: Pilot Dominance Flow
PMRM from
Mobile
PMRO Flag
Set?
Agg Str of
Actives <
AggStrengthN
Yes
Yes
Send PMRO to Mobile
and Reset PMRO Flag
Drop Event?
PSMM from
Mobile
Calculate Aggregate
Strength of Active Pilots
Agg Str of
Actives <
AggStrengthN
Send Handoff Request to
MM
Cand > tcomp-
ena-thresh & xc-
tcomp > weakest
keep active?
Discard PSMM
No No
No
Yes
Yes Yes
Set PMRO Flag
Reset PMRO Flag
Motorola Confidential Proprietary 69
10.2.4 MM Filtering
The purpose of filtering handoff requests at the MM is to balance the need of maintaining good
call quality with minimizing the soft handoff factor and soft handoff rate. A set of parameters is
available to achieve this goal by limiting the maximum size and structure of the active set.
When a handoff request is received by the MM, its analyzed to determine if adding the strongest
candidate to the active set would violate one of the constraints: MaxBTSLegsN, MaxCEPerCall,
or MaxActiveSetSize. If there is no violation, the candidate is put in the add list. The aggregate
strength of the active set plus the add list is then recalculated. If this new aggregate strength
value exceeds the aggregate strength threshold (the same threshold used in the XC filter), no
more candidates are processed. If it does not exceed the aggregate strength threshold, all
candidates not at the same BTS are discarded, the next remaining candidate is chosen, and the
constraint checks are repeated. Once either the aggregate strength threshold is exceeded or there
are no candidates remaining, the handoff direction message is sent to the transcoder.
If one of the constraints is violated by the addition of a candidate, one of three shuffle checks is
done (softer, BTS, or soft) if the shuffle type is enabled. The check will result in the candidate
being placed in the add list or discarded. In addition, if none of the candidates can be added, but
there is a drop event, it will be executed. If the shuffle type is disabled, the check will not be done
and the candidate will be discarded.
EnaSofterShuffle Switch to allow softer shuffle checks to be performed. If this is set to
disabled, softer shuffles will not be attempted.
EnaBTSShuffle Switch to allow BTS shuffle checks to be performed. If this is set to disabled,
BTS shuffles will not be attempted.
EnaSoftShuffle Switch to allow soft shuffle checks to be performed. If this is set to disabled,
soft shuffles will not be attempted.
MaxBTSLegs1 Maximum number of active legs allowed when only one BTS is in the active set.
If adding a candidate pilot to the active set would cause this parameter to be exceeded and
EnaSofterShuffle is set to enable, a softer shuffle check is performed. Range: 1 to 6.
MaxBTSLegs2 Maximum number of active legs allowed when exactly two BTSs are in the
active set. If adding a candidate pilot to the active set would cause this parameter to be exceeded
and EnaSofterShuffle is set to enable, a softer shuffle check is performed. Range: 1 to 6.
MaxBTSLegs3 Maximum number of active legs allowed when exactly three BTSs are in the
active set. If adding a candidate pilot to the active set would cause this parameter to be exceeded
and EnaSofterShuffle is set to enable, a softer shuffle check is performed. Range: 1 to 6.
MaxCEPerCall Maximum number of channel elements allowed per call. If adding a candidate
pilot to the active set would cause this parameter to be exceeded and EnaBTSShuffle is set to
enable, a BTS shuffle check is performed. Range: 1 to 3.
Motorola Confidential Proprietary 70
MaxActiveSetSize Maximum number of active legs allowed per call. If adding a candidate pilot
to the active set would cause this parameter to be exceeded and EnaSoftShuffle is set to enable, a
soft shuffle check is performed. Range: 1 to 6.
Figure 2: MM Filtering Flow
Add violates
max-ce-per-call?
Add violates
max-active-set-
size?
Add violates
max-bts-legsN?
Handoff Request
from CPP
Put Candidate in Add
List
Perform Soft Shuffle
Check
Perform BTS Shuffle
Check
Perform Softer Shuffle
Check
No
No
No
Yes
Yes
Yes
Recalculate Aggregate
Strength
Agg Str of
Actives >
Agg_StrN?
Send Handoff Direction
Message to XC
Discard All Candidates
not at same BTS
More
Candidates
No
No
Yes
Yes
Ena-softer-
shuffle set
to enable?
Ena-BTS-
shuffle set
to enable?
Ena-soft-
shuffle set
to enable?
Yes
Yes
Yes
Discard Candidate
No
Discard Candidate
No
Discard Candidate
No
Motorola Confidential Proprietary 71
10.2.4.1 Softer Shuffle
A softer shuffle is the process of adding one and dropping another pilot at the same BTS,
controlled by the same channel element. It is done to keep the active set from exceeding the
maximum number of softer legs allowed on each channel element (MaxBTSLegsN). An essential
component of the algorithm is that once it is determined that a softer shuffle should be done, the
candidate pilot will be added before the active pilot is dropped. This keeps the call from dropping
down to a lower handoff state and losing diversity benefit. In this case, the MaxBTSLegsN
parameter will be exceeded shortly until the drop operation is completed. The MM sends the add
instruction to the XC and cues the drop operation until the add is complete.
Once the MM has decided to do the check, a softer shuffle will be completed if one of the
following is true:
Candidate pilot is SofterShuffleComp greater than strongest active leg.
Candidate pilot is greater than TCompEnaThrsh and SofterShuffleComp greater than weakest
active leg at the same BTS.
The checks help ensure that the candidate pilot is sufficiently strong to warrant being added to the
active set. If one of the criteria is satisfied, the pilot will first be added, and then the weakest pilot
at the same BTS will be subsequently dropped.
SofterShuffleComp Comparison value to determine whether to perform a softer shuffle. It
requires a candidate to be relatively stronger than an active pilot to be added. A lower setting will
cause more softer shuffles to occur. Range: 0.0dB to 31.5dB in 0.5dB increments.
TCompEnaThrsh Minimum threshold for a candidate to be considered for addition to the active
set. Used in the second check for a softer shuffle, it requires that the candidate pilot is greater
than this value to be added. This parameter is also used in the soft shuffle check and XC filtering.
A lower setting will cause more softer shuffles to occur. Range: -31.5dB to 0.0dB in 0.5dB
increments.
Motorola Confidential Proprietary 72
Figure 3: Softer Shuffle Flow
Incoming Handoff
Request
Six pilots in
active set?
Add Candidate Pilot
Drop Weakest Pilot
Cand softer-
shuffle-comp >
strongest active
Cand > tcomp-ena-
thrsh & softer-
shuffle-comp >
weakest active?
Discard Candidate
No
No
Yes
Yes
Discard Candidate
Yes
No
Motorola Confidential Proprietary 73
10.2.4.2 BTS Shuffle
A BTS shuffle is the process of dropping one and adding another BTS to the call. This may
involve the adding and/or dropping of multiple legs from the same BTS. It is done to keep the
active set from exceeding the maximum number of channel elements allowed (MaxCEPerCall). If
the check passes, all pilots from the active BTS with the lowest aggregate strength will be
dropped, and then the candidate(s) will be added. Unlike the softer shuffle, the drop must come
before the add because the transcoder cannot support more than three active channel elements in a
call. The MM sends the drop instruction to the XC and cues the add operation until the drop is
complete.
Once the MM has decided to do the check, a BTS shuffle will be completed if the candidate pilot
is BTSShuffleComp greater than strongest active leg. If this criterion is satisfied, all pilots from
the weakest active BTS will first be dropped, then the candidate pilot will be subsequently added.
***Changed in R8.1 and R8.3:
Once the MM has decided to do the check, a BTS shuffle will be completed if one of the
following is true:
Candidate pilot is greater than TCompEnaThrsh and greater than or equal strongest active
pilot.
Candidate pilot is greater than TCompEnaThrsh and greater than or equal to
BTSShuffleComp plus the strongest pilot from the weakest active aggregate BTS.
BTSShuffleComp Comparison value to determine whether to perform a BTS shuffle. It
requires a candidate to be relatively stronger than an active pilot to be added. A lower setting will
cause more BTS shuffles to occur. Range: 0.0dB to 31.5dB in 0.5dB increments.
Motorola Confidential Proprietary 74
Figure 4a: BTS Shuffle Flow
Figure 4b: Modified BTS Shuffle Flow
Cand bts-shuffle-
comp >
strongest active
Incoming Handoff
Request
Discard Candidate
Drop All Pilots from
Weakest BTS
Add Candidate
No
Yes
Incoming Handoff
Request
Cand >
tcompenathrsh? Discard Candidate
Drop All Pilots from
Weakest BTS
Add Candidate
No
Yes
Cand >=
strongest active
pilot?
Cand >= bts-shuffle-
comp + strongest
pilot from weakest
bts?
Yes
No No
Discard Candidate
Yes
Motorola Confidential Proprietary 75
10.2.4.3 Soft Shuffle
A soft shuffle is the process of adding one and dropping another pilot, possibly at different BTSs.
It is done to keep the active set from exceeding the maximum number of pilots
(MaxActiveSetSize). An essential component of the algorithm is that once it is determined that a
soft shuffle should be done, the candidate pilot will be added before the active pilot is dropped.
This keeps the call from dropping down to a lower handoff state and losing diversity benefit. In
this case, the MaxActiveSetSize parameter will be exceeded shortly until the drop operation is
completed. The MM sends the add instruction to the XC and cues the drop operation until the
add is complete. The only exception to this rule is if the active set already contains six pilots, the
candidate will be discarded.
Once the MM has decided to do the check, a soft shuffle will be completed if one of the following
is true:
Candidate pilot is SoftShuffleComp greater than strongest active leg.
Candidate pilot is greater than TCompEnaThrsh and SoftShuffleComp greater than weakest
active leg.
The checks help ensure that the candidate pilot is sufficiently strong to warrant being added to the
active set. If one of the criteria is satisfied, the pilot will first be added, and then the weakest pilot
will be subsequently dropped.
SoftShuffleComp Comparison value to determine whether to perform a soft shuffle. It requires
a candidate to be relatively stronger than an active pilot to be added to the active set. A lower
setting will cause more soft shuffles to occur. Range: 0.0dB to 31.5dB in 0.5dB increments.
TCompEnaThrsh Minimum threshold for a candidate to be considered for addition to the active
set. Used in the second check for a soft shuffle, it requires that the candidate pilot is greater than
this value to be added. This parameter is also used in the softer shuffle check and XC filtering. A
lower setting will cause more soft shuffles to occur. Range: -31.5dB to 0.0dB in 0.5dB
increments.
Motorola Confidential Proprietary 76
Figure 5: Soft Shuffle Flow
Incoming Handoff
Request
Six pilots in
active set?
Add Candidate Pilot
Drop Weakest Pilot
Cand soft-
shuffle-comp >
strongest active
Cand > tcomp-ena-
thrsh & soft-shuffle-
comp > weakest
active?
Discard Candidate
No
No
Yes
Yes
Discard Candidate
Yes
No
Motorola Confidential Proprietary 77
10.3 Migration
The following is an excerpt from Bogdans migration plan. Refer to the complete migration plan
for further details. It is available via the web at http://www.cig.mot.com/~dillon.
10.3.1 Step 1 - Must Check
SendHOPerformMsg
(At this point, your CBSC(s) has already been upgraded to R8.1. BTSs subtended by the CBSC
can be on R7 or (exclusive) R8.0)
Turn OFF this parameter, unless features E911 and CALEA Wiretap are activated, in which case
it should be ON. By turning this parameter OFF, we are not adding extra processing in the MM.
Command: EDIT cbsc-x softhoparms sendhoperformmsg=off
Indicators: check the MM utilization during the busy hour. If it is higher than the previous day(s)
at the same time, then one of the reasons might be that this parameter is ON. In addition, a new
PM indicator has been introduced to account for this parameter workload: pmc_52_hr,
peg_count_13. You will find an indication of the extra load by monitoring the variations of this
peg count.
10.3.2 Step 2 Must Do
Introduction of feature 1020A (N-way Complex Soft HandOff) will bring a huge impact in the way we
perform SHO. In order to migrate the system as smoothly as possible with no performance
degradation, several steps are needed during the software upgrade process. Before executing the
following steps, your system should be in R8.1 for the CBSC and R7.0 or R8.0 for the BTSs. You
must execute these steps as soon as the CBSC comes in service.
10.3.2.1 ComplexSHOEna=DISABLE
Remember that Constraint table #1 is the default table. We are going to use only this table to update
the parameters for all different cases (during inter-CBSC SHO operation the IcTrkGrp also points to
Constraint table #1). First step will be to disable the Complex SHO operation when BTSs are still in a
previous release.
Command: EDIT cbsc-x softhoparms ComplexSHOEna=off
10.3.2.2 Change the TComp value
Make sure that the TComp value for all BTSs is 4dB.
Command: EDIT carrier-bts #-sector #-carrier # maho tcomp=4
10.3.2.3 Change Constraint Table #1
By disabling the Complex SHO operation, we do not disable the pilot dominance portion of the feature.
Because the MS is not allowed to go to more than 3-way (when ComplexSHOEna=DISABLE), a
shuffle is performed as per R7. The parameters are as follows:
Command: EDIT hoconst-cbsc #-table # shuffle
Softer Shuffle Comp = 3dB Soft Shuffle Comp=3dB BTS Shuffle=3dB
Enable Softer Shuffle=E Enable Soft Shuffle=EEnable BTS Shuffle=E
Motorola Confidential Proprietary 78
Command: EDIT hoconst-cbsc #-table # detection
MaxActSetSz=6 MaxCEPerCall=3 TcompEnaThresh=-16dB
MaxBTSLegs1=3 MaxBTSLegs2=2 MaxBTSLegs3=2
Aggregate Active Set Strength Threshold 1=0dB
Aggregate Active Set Strength Threshold 2=0dB
Aggregate Active Set Strength Threshold 3=0dB
XCTComp=0dB Num Candidate=10
Note: If your MM utilization was up to 80% and you were using the old version of the XC filter (up to
R8.0) then set the Aggregate Thresholds to the following values:
Aggregate Active Set Strength Threshold 1=-5dB
Aggregate Active Set Strength Threshold 2=-7dB
Aggregate Active Set Strength Threshold 3=-9dB
TcompEnaThresh=-14.5dB XCTComp=4.5dB
10.3.2.4 Check that all sector-carriers point to Constraint table #1.
Command: DISP cbsc-x HOCONSTRUSERS
At the end of this step, we recommend to monitor the system performance for about 24 hours
before proceeding with step 3.2.5. This is to ensure that no major performance degradation is
experienced. The state of the system after this step can be used as reference for further steps (if
performance is similar to previous software release).
10.3.2.5 Enable Complex SHO
Now that we achieved stability in system performance, the next step in software upgrade is to
load all BTSs with R8.1. At this stage, your system should be on R8.1 for CBSC, R8.1 for all
BTSs subtended by the CBSC, and R8.1 for neighbor (IcTrunk) CBSCs. An example set of n-
way parameters is also shown. See the next section on performance trends for the proper choice
for your market.
Command: EDIT cbsc-x softhoparms
ComplexShoEna=ENABLE
Command: EDIT hoconst-cbsc #-table # shuffle
Softer Shuffle Comp = 3dB Soft Shuffle Comp=3dB BTS Shuffle=3dB
Enable Softer Shuffle=E Enable Soft Shuffle=EEnable BTS Shuffle=E
Command: EDIT hoconst-cbsc #-table # detection
MaxActSetSz=6 MaxCEPerCall=3 TcompEnaThesh=-14.5dB
MaxBTSLegs1=3 MaxBTSLegs2=2 MaxBTSLegs3=2
Aggregate Active Set Strength Threshold 1=-5dB
Aggregate Active Set Strength Threshold 2=-7dB
Aggregate Active Set Strength Threshold 3=-9dB
XCTComp=4.5dB Num Candidate=10
Motorola Confidential Proprietary 79
10.4 Performance Trends
There are three basic parameter sets recommended for the n-way feature. The choice will vary
depending on the markets needs. This section is meant to describe the three sets and the
tradeoffs for each.
Complex Off RFLoss Set SHO Factor/Rate Set
SofterShuffleComp 3 3 3
SoftShuffleComp 3 3 3
BTSShuffleComp 3 (0)* 3 (0)* 31.5 (0)*
EnaSofterShuffle Enable Enable Enable
EnaBTSShuffle Enable Enable Enable
EnaSoftShuffle Enable Enable Enable
MaxActiveSetSize 6 6 6
MaxCEPerCall 3 3 3
MaxBTSLegs1 3 3 3
MaxBTSLegs2 2 2 2
MaxBTSLegs3 2 2 2
TCompEnaThrsh -16.0 -14.5 -14.5
AggStrength1 0 0 -5.0
AggStrength2 0 -7.0 -7.0
AggStrength3 0 -9.0 -9.0
XCTComp 0 3.0 4.5
ComplexSHOEna Disable Enable Enable
* Use BTSShuffleComp = 0 if you do not have MR sc991274 and sc994314
The following table illustrates the change in performance from the test markets. The percentage
reductions are based on a comparison of the performance of those settings compared to R7/R8.
It should be noted that results will vary depending on the degree of multipilot-ness in the
system. If the optimization and design is such that the mobile does not see more than three pilots
above tadd very often, little change will be seen in the FER and SHO factor. The reduced call
setup feature in this release has caused a shift in the setup failure CFCs (3, 5, 9, 13, and 15). The
delta shown is based on the combination of these.
Complex Off RFLoss Set SHO Factor Set
Setup Fail Percent Dec 45% Dec 45% Dec 45%
RFLoss Percent Dec 30% Dec 30% Dec 20%
SHO Factor None None Dec 5%
SHO Rate None Dec 20% Dec 40%
MM Utilization None Dec 12% Dec 20%
Motorola Confidential Proprietary 80
10.4.1 Complex Off
This set should cause no change in performance over the previous release. However, other non-
n-way features included in R8.1 will cause a reduction in the dropped call rate and setup failure
rate. Complex is disabled and the XC filter is parameterized off. These parameters should be
used if the goal is keep identical system performance to the previous software release. It is
recommended that this set be used to baseline the system immediately after the R8.1 upgrade.
10.4.2 RFLoss Set
These settings are meant to exploit the ability of the n-way feature by allowing the active set to go
to the maximum of six pilots while filtering minimally. This step will cause a decrease in the
frame erasure rate and may decrease the dropped call rate. MM utilization will also decrease.
Because the active set is allowed to go up to six pilots, shuffling will be dramatically decreased,
hence less soft handoffs will occur. This, combined with the filtering at the XC, causes the
reduction in MM utilization. While this step has not caused a reduction in the RFLoss rate over
the complex off settings in 3-sectored systems to date, regions with multipilot problems may
benefit. In addition, while the soft handoff factor has not increased substantially with this step,
particular regions with high levels of multipilot activity may see an increase in channel element
usage. Sites with busy hour channel element loading greater than 90% should be monitored
closely for blocking (CFC20).
The filter settings in this parameter set help keep the SHO factor and SHO rate down, but they
are benign when it comes to the RFLoss rate for two reasons. First, the AggStrength1 is turned
completely off (set to zero), so the mobile is not inhibited from getting out of one way into soft or
softer handoff which is particularly important from the initial state. Second, the XCTComp is set
to 3dB, less than the mobiles TComp (all sectors should have TComp set to 4dB). This means
that virtually all TComp events generated by the mobile will pass through the back door of the
filter, assuming the candidate is greater than TCompEnaThrsh. This is why it is so important to
have the TComp for each sector set to 4dB. Otherwise, TComp events will be generated by the
mobile without having the proper combination of pilot Ec/Io levels to allow the PSMMs to pass
the filter.
10.4.3 SHO Factor Set
The SHO factor set of parameters strives to filter PSMMs more heavily at the transcoder. The
benefits are further reductions in the soft handoff factor (saves channel elements) and soft handoff
rate (saves MM utilization). The drawback is a possible slight elevation in RFLoss, although the
RFLoss rate will still be substantially better than in R7/R8. In addition, the reduction in SHO
factor tends to reduce the overall forward power out of the base station, which may increase
forward link capacity. The filter settings are tightened when compared to the RFLoss set by
lowering the AggStrength1 parameter and raising the XCTComp to a setting above the mobiles
TComp. This will cause PSMMs to be filtered by the transcoder in one way and many of the
mobiles TComp events to be filtered, where they were passing through with the XCTComp at 3.
Motorola Confidential Proprietary 81
10.4.4 BTS Shuffle (MR sc991274 and sc994314)
The BTS shuffle check changes in later versions of R8.1 and R8.3. Consult the release notes to
determine if the MR is included in your tape. The FOA of the new algorithm has been completed.
The R8.1 version of the BTS Shuffle algorithm was found in the field to cause dropped calls
under certain conditions. Since the shuffle was triggering off the strongest active pilot, it was
being started too late in some geographic locations where pilots from four or more BTSs were
present. The new algorithm allows the shuffle to start earlier by triggering off the weakest BTS.
The number of calls adversely affected by the current algorithm will vary by market. While the
dropped call rate is expected to improve in these areas, it may not be measurable on the system as
a whole.
Start with BTSShuffleComp = 31.5dB (maximum database value). This will effectively shut off
the new check and cause identical performance to the prior algorithm (if previous setting was
BTSShuffleComp = 0). It can subsequently be lowered from 31.5 to cause more shuffling. As
the value is lowered, more shuffling will occur causing a tradeoff of an increased SHO rate (MM
utilization) for a decreased dropped call rate in certain areas. A value of 3dB was found to be the
optimal setting for this parameter with respect to dropped call performance.
The FOA showed no measurable difference in dropped call rate, handoff rate, or MM utilization
over the entire system. It did, however, reduce the FER and drops in the before mentioned
multipilot environments.
10.5 Interaction with Other Features
Inter-CBSC SHO operation should be seamless with the n-way feature, assuming that all CBSCs
have been upgraded to release 8.1. Refer to Bogdans migration plan to ensure compatibility. In
short, the source CBSC controls the operation of n-way. As stated earlier, the source CBSC
must have the inter-CBSC trunk group pointing to the appropriate constraint table. All sectors on
the target CBSC will refer to that constraint table regardless of whether or not complex SHO is
enabled at the target CBSC or what constraint table the sector point to on its own CBSC.
The Database Assisted Handoff (DAHO) validation table has changed. Note that there is no
change in the decision making process for one, two, and three active pilots, but a DAHO will not
be attempted with four or more pilots in the active set. The assumption is that a DAHO will not
be necessary in regions where four or more strong pilots are present.
1
Active
Pilot
2
Active
Pilots -
Differen
t Sites
2
Active
Pilots -
Same
Site
3
Active
Pilots
4
Active
Pilots
5
Active
Pilots
6
Active
Pilots
0 DAHO Sector-Carrier
Active Pilots
N N N N N N N
1 DAHO Sector-Carrier Y N Y N N N N
Motorola Confidential Proprietary 82
Active Pilots
2 DAHO Sector-Carrier
Active Pilots
Y Y Y N N N
3 DAHO Sector-Carrier
Active Pilots
Y N N N
4 DAHO Sector-Carrier
Active Pilots
N N N
5 DAHO Sector-Carrier
Active Pilots
N N
6 DAHO Sector-Carrier
Active Pilots
N
Motorola Confidential Proprietary 83
10.6 Call Detail Logs (CDLs)
With the new feature comes a number of new CDL fields to aid in analyzing call performance.
This section will cover the essential new fields. Note: there are other new fields in the CDL, not
specific to the n-way feature, that are not described here. See the CDL SFS for the complete list.
Fields Description Usage
NUM_SR_SHUFFLE
NUM_BTS_SHUFFLE
NUM_S_SHUFFLE
Number of softer, BTS, and
soft shuffles, incremented
each time a shuffle is
attempted. Maximum: 15
Shows activity of each
shuffle type. Indication of
how often parameter
settings are causing shuffles
to occur.
FIRST_SHO_POST_AGST
LAST_SHO_POST_AGST
Aggregate strength of the
active set after the handoff is
attempted.
LAST_SHO_SHUFFLE_TYPE Shuffle type and point in the
last SHO process.
not a shuffle
soft, first half
soft, second half
bts, first half
bts, second half
softer, first half
softer, second half
Use to analyze what shuffle
types are being attempted
when calls are dropping.
The CDL analysis tool has been updated for R8.1; it should be used for daily statistical trending.
The code is available on the web at http://www.cig.mot.com/~wheelrts.
PM statistics have also been added for n-way. Detail on all peg changes and available reports is
on the web at http://www.cig.mot.com/~palom.
Chapter 11 WiLL Systems
11.1 Overview
This document will very quickly discuss the following tasks:

drive test procedure - polygon approach, choosing thresholds
recommended installation for system deployment - dependence on polygons of drive coverage
optimization Tcomp/XC filter recommendations - implementation stages
a beta trial example - data analysis required
Motorola Confidential Proprietary 84
11.2 Drive test procedure
The main purpose of the drive test procedure in WiLL systems is to establish known levels of
coverage, which may be slightly different than Netplan predictions. This will enable the
installation teams to have an expectation of what they will need to do at each FWT location, i.e.
how far into the optimization do they need to go and what antennas/equipment might be
necessary in order to solve the issues. The installation procedure mostly details the expected
output of the drive test. A few of the assumptions are listed:
1. cross hatch drives covering entire area
2. correct service option 8k markov or 13k markov to match system mode
3. long or short calls can be used
4. 1 watt pilots in general, unless pumped to fill forward holes
5. in van whip used for CAMPS/DM Qualcom
6. use of SMAP for reverse link FER
7. use of GPS for location data of mobile drive test data
8. allow SHO to neighboring cells (have neighbors)
9. use default MAHO setting for drive test data -14/-16 add and drop settings
10. turn off XC filter settings if they are being used
11. Tadd mode in the XC with defaults for the mobile system -14/-16 tadd and tdrop values.
The drive test data, in addition to the basic transmit and receive levels, can provide the neighbor
list verification as well as general performance of each sector which can verified by checking the
transmit gain adjust in the plots. At minimum the drive testing should produce RSSI and Tx level
plots for the entire system. More detail is provided in the next section.
11.3 Installation procedures
The system deployment will hopefully involve a reduced number of steps from that of the beta
trial in order to speed up the installation process. There is definitely a compromise between the
optimized FWT placement and the time required to perform the installation. To help solve this
problem, the regions can be split into three stages depending on the expected pathloss (mobile
transmit power and RSSI levels) that is measured during the drive testing. FWT transmit power
is a better measure of absolute pathloss since RSSI is a composite of the forward link interference
(BTS powers). The key is to use a DM for real time and immediate validation of the FWT
antenna placement.
Prior to system deployment drive testing consisting of a crosshatch drive inclusive of the expected
FWT placement for that region. As in mobility drive testing this is only valid if the surrounding
cells are in service (INS) and in included into each others neighbor lists. This drive test data
should be run through COMPAS to provide plots in which rough polygons of expected coverage
surrounding each cell for Tx and RSSI power levels. This drive testing assumes that both the
FWT unit and CAMPS or DM units have normal whip antenna located within the van. The exact
RSSI and Tx numbers used to classify the levels might change depending on the beta testing that
will be going on in Poland in 2-3 weeks and discussions with staff engineers in AH. We will
Motorola Confidential Proprietary 85
monitor the data collection with them in order to help further correlate CDL/DM data points with
drive test street level average polygon RSSI/Tx levels.
Level 1 - good coverage, transmit power less than 5 dBm average, light gray
Level 2 - possibly marginal, transmit power 5-15 dBm average, darker gray
Level 3 - marginal coverage, transmit power >= 15 dBm average, black (hole)
Most of the FWT placement questions will fall into the level 2-3 zones of coverage. It is
assumed that by careful placement most of the Level 2 locations, and many of the Level 3 can be
covered if good antenna placement criteria are used. The options for antenna choices are
assumed to be indoor desk mount whip, wall mount unit with whip, outdoor whip, outdoor Yagi
in order of preference/cost. In level 1 areas, it should be possible to use the desktop whip. In the
other areas it will require additional consideration depending on the proposed location. There are
two methods proposed here is order to optimize the FWT location. Regardless of level, if the
FWT shows a solid or quickly flashing green light indicating good RSSI than the location is
probably ok (assuming the FWT is calibrated for solid at -80 to -85 dBm), so move on to the next
location. Otherwise,
11.3.1 Method 1
This method assumes DM equipment is deemed to hard to obtain/use/complicated/expensive for
the installation teams, thus only CDLs are used in order to verify link quality and ability to sustain
reverse loading effects.

1. 10-20 FWT calls of 30 seconds will be placed with a 6-10 dB pad in line, note the
starting/stopping time.
2. 10-12 FWT calls of 30 seconds will be placed without any attenuation, note the
starting/stopping time.
3. Browse and analyze the cdllogs for the two cases, the quality pegs should be similar for the
reverse link for calls with and without the pad, and the number of origination sites should be 2
or less.
4. Nail down the FWT antenna in the location used to assure that the customer does not change
it to a spot with more pathloss.
The faster dirty method is to just use the only do step 1 with 10 dB pads and if 5-10 calls are
successful than go to step 4.
Motorola Confidential Proprietary 86
11.3.2 Method 2
This method assumes DM equipment is being used in order to verify link quality and ability to
sustain reverse loading effects. This will make installation quicker since the placement can be
done real time, very quick response time due to feedback directly on the information from the
DM.

1. Plug in Qualcom DM into the FWT antenna connection with the special adapter kit.
2. Optimally place the FWT antenna for minimum mobile Tx power, if it is close to meeting level
1 criteria (average transmit power <10 dBm) and/or can find a dominant pilot, i.e. one above
the other by 3 dB and/or one pilot better than -7 or 8 Ec/Io, go to step 6.
3. 10-20 FWT calls of 30 seconds will be placed with a 6 dB pad in line, note the
starting/stopping time.
4. 10-12 FWT calls of 30 seconds will be placed without any attenuation, note the
starting/stopping time.
5. Browse and analyze the cdllogs for the two cases, the quality pegs should be similar for the
reverse link with and without the pad, and the number of origination sites should be 2 or less.
6. Nail down the FWT antenna in the location used to assure that the customer does not change
it to a spot with more pathloss.
At step 2, other options that might be tried should include: raising location of antenna, move to
different sides of the building structure, close to larger windows, changing to outside whip,
changing to outside Yagi. Most locations should be able to be covered if they are level 1-2 with
indoor whip antennas. This should allow for many more cases to be handled with the DM, since
the optimal locations are being swept for by moving the antenna around looking for the best
placement rather than leaving it up to chance. Poor level 3 drive locations or RSSI levels of
closer to -100 dBm might require outdoor whips. Locations with less than -100 dBm of street
level RSSI might require Yagi antennas in order to sustain load from forward/reverse.
The CDL information provides a good indication of the SHOF and dominance of certain FWT
locations that can be used in order to predict the ability of the sector to absorb more or less load.
Use of a DM allows for ability to create summary files on the PC for each location showing the
ability of the edge cells to sustain calls during loading. Both can be used in busy vs. non-busy
hour comparisons to find which locations might need to be upgraded (more gain/isolation)once
loading effects occur.
11.4 Optimization
There are two basic issues for WiLL systems. They are forward link interference (multi-pilot
problem) and reverse link pathloss. The multiple pilot problem will present itself more in urban
locations, which they did not have any good examples in Poland to verify the following expected
forward link methods. Limiting the soft handoff factor does not help reduce the multipilot
condition, but will help to slow the degradation caused by having loaded on unnecessary forward
links. It would not be expected to clear up any areas that contain more than 4-5 pilots above
Tadd level unloaded as seen in the PSMMs.
Motorola Confidential Proprietary 87
11.4.1 Forward link
Soft handoff factor -SHOF
Limiting the soft handoff factor is a key to retaining good Ec/Io and RF link capacity as well as
good management of the limited number of walsh codes. This can be achieved by use of TComp
mode or the XC filter feature (in release 7), which limits adding of candidates based on the quality
of the active pilots. The XC filter can be set much more aggressively for a WiLL system than for
a mobile system due to the lack of motion. Pick one or the other. TComp is generally
recommended because its a bit simpler. However, the R8.1 version of the XC Filter can be
controlled per sector/carrier, so a mixed mobile/WiLL system may need to use this method.
TAdd Mode TComp Mode Filter 1 Filter 2
Handoff Mode TAdd TComp TAdd TAdd
TComp 4 1 4 4
1_2_Way 0 0 16 (-8dB) 20 (-10dB)
2_3_Way 0 0 16 (-8dB) 20 (-10dB)
XC_Thresh 63 63 28 (-14dB) 28 (-14dB)
Act_State 3 3 1 1
The performance is similar on either TComp mode or the XC filter. Data is from a loaded WiLL
test market.
TAdd Mode TComp Mode Filter 1 Filter 2
SHO Factor 1.5 1.10 1.31 1.12
SSHO Factor 1.8 1.15 1.46 1.18
SSHO Rate 2.0 0.3 0.9 0.3
Forward FER setting
For systems using 8k vocoders change the FER target from B to C or if needed to D. This will
raise the average FER allowing for a more even distribution of FER across all FWTs. It will
decrease the effect of coverage holes and high levels of degraded forward FER opening up during
heavy loading.
11.4.2 Reverse link
There are less optimization choices involved in the reverse link since its more of a basic
pathloss/link budget issue. Thus, the key is to decrease the pathloss by optimal placement
(higher/outdoors) decreasing pathloss or increase the effective FWT power by increasing the
antenna gain.
Decreasing the Maximum Eb/No and/or reducing the minimum Eb/No settings is another method
of squeezing out some more reverse link capacity, but does not effect the unloaded pathloss. So
unless the issue is busy hour vs. non-busy hour performance the reverse Eb/No settings should not
be changed. The Eb/No settings are fairly well optimized from lab testing and are harder to
measure than forward link issue due to SMAP and basic complexity of the algorithms. Thus, they
generally should not be changed.
Motorola Confidential Proprietary 88
11.4.3 Analysis Script
Descriptions of the fields that come from the WLL perl script are shown below. Its still in the
beta test itself, I noticed a few bugs in the output that I still have to fix. Also, some of the
maximums seem to be averaged out by the use of only 0.XX two digits in resolution which might
need to be increased. Anyhow,
cat browsed_CDLS | perl wll > output_file
**** SWITCHs ****
-help # produces this output
-fwt # produces only the ESN output no cell listing
-cell # produces only the CELL output no ESN listing
-sum # produces only the summary output for all CDLs
This perl script calculates some call stats from browsed CDL data.
It will allow the operator some insight to the FWT placement.
The script output is both ESN/FWT and CELL-SECTOR based. If lat/lon
are associated to these ESN/Cells a Map-Info/NetPlan or COMPAS can plot them, along with the
underlying RSSI polygons.
**** FIELDS ****
good % = percentage of good calls > 90%
100* CFC1/total CFCs
drop % = percentage of calls that got to traffic and dropped
100* CFC4/total CFCs-Setup Failures
setfls % = percentage of calls that failed before getting to traffic
100* CFC5,9,13/total CFCs
FwdQ = average measure of forward audio/link quality
60* forward quality pegs/total time on TCH
a forward peg is 3 (=PMRM_COUNT) PMRMs in 10 (=XcCpT5) seconds
thus this is a peg count per minute
FwdM = average max gain count normalized per minute on TCH
60* CDL parameter HiGain/total time on TCH
only valid if the number of SHOs is low
RevQ = average measure of reverse audio/link quality
60* reverse quality pegs/total time on TCH
a reverse peg is 14 (REVERSE_ERASURE_THRESHOLD) out of 128 frames
thus this is a peg count per minute
Motorola Confidential Proprietary 89
RevM = average max Eb/No normalized per minute on TCH
60* CDL parameter LAST_RF_SETP1-2-3/total time on TCH
only valid if the number of SHOs is low
lowest link max is taken since reverse
links are independent (in r7/r8)
Domin = average dominance
average of active vs. best candidate
hopefully active > candidate thus higher the better
calculated in dB, i.e act=-10 cand=-13 domin = 3 dB
taken from the CDL fields for INIT_MAHO
ActEc/Io = average reported active pilot
taken from the INIT_MAHO fields
Range = average range
taken from the ACCESS_PN_OFFSET field/12.28-fixed_offset chips per mile
Motorola Confidential Proprietary 90
Chapter 12 Timers
Timers are generally used to capture error legs and free up resources or to allow for the correct
performance statistic to be pegged. The default values are usually ok although perhaps not
optimimal. This section is included to more fully explain the short spread sheet explainations.
12.1 Timers in the MM
MmCpT3 Expiry
This timer is started when one or more SCAP Release Radio Channel messages are sent to the
MCC TCHs involved in a call, in order to release them. The timer is stopped when each SCAP
Release Radio Channel message sent has been acknowledged by a SCAP Radio Channel
Released. Expiry implies that at least one of the MCC TCHs has failed to correctly respond.
This timer is required because there is no other event, other than its time-out, that will cause the
MM to clean up the call should an MCC TCH fail to respond to the SCAP Release Radio Channel
message. When an MCCce fails to respond to a release, the MM puts the MCCce and any Walsh
Codes allocated to the MCCce back on the idle list, and issues an exception report
MmCpT9 Expiry
The non-slotted page response timer, which is the time that the MM will wait for a response after
sending non-slotted Page message., in the case where repaging is turned on.
MmCpT10 Expiry
This timer is set when the MM sends an A+ Clear Request to the MSC, and is stopped when an
A+ Clear Command is received from the MSC.
MmCpT11 Expiry
This timer is started when the MM sends a SCAP XC Release Radio Channel message to the CPP
(because the MM has received an A+ Release message from the MSC), and is stopped when the
MM receives a SCAP XC Radio Channel Released message in response from the CPP. This timer
is required so that if the SCAP XC Radio Channel Released is not received, the TC will be idled
by the MM so that it can be allocated to a new call by the MSC. This timer can time-out during
Release procedures, prior to sending a Release Complete to the MSC, or during abnormal MSC
clearing, prior to sending a Clear Complete to the MSC.
MmCpT14 Expiry
Timer MmCpT14 is started in the MM upon transmission of an A+ CM Service Request message
or Page Response message to the MSC, and is stopped upon transmission of an A+ Assignment
Complete message to the MSC. This timer guards against errors in call setup sequencing that may
cause a call process to hang, such that no outstanding event will cause the call to either
successfully complete or to terminate and release allocated resources. Upon expiry after an
SCCP Connection Confirm message from the MSC is received, the MM will send an A+ Clear
Request to the MSC to initiate release of all resources associated with the call. A Clear Request is
sent instead of an Assignment Failure in order to cover cases where MmCpT14 expires prior to
receipt of an Assignment Request. Upon expiry prior to receipt of an SCCP Connection Confirm
Motorola Confidential Proprietary 91
message from the MSC, the MM will send a SCCP Released to the MSC and will release XC
resources and the TCH MCC. Note that if MmCpT14 expires after transmission of a SCAP XC
Channel Assigned (i.e. before receipt of a SCAP XC Assignment Successful or SCAP XC
Unsuccessful Assignment), the MM shall send a SCAP XC Release Radio Channel to the CPP
and send a SCAP Release Radio Channel message to the TCH MCC at the appropriate points in
the clearing procedure
MmIcHoT02 Expiry During Call Release
Timer MmIcHoT02 is started by a source MM call during call release procedures, upon
transmission of SCAP IC Disconnect messages to all inter-CBSC soft handoff (trunking) MMs
associated with the call. This timer supervises for the receipt of a SCAP IC Disconnect Ack or
SCAP IC Disconnect Nack from all the target MMs associated with the call. Expiry of this timer
indicates that there is some type of signalling anomaly between the source MM and a target MM.
Either a SCAP IC Disconnect message from the source MM to a target MM was corrupted,
delayed, or lost, or a SCAP IC Disconnect Ack or SCAP IC Disconnect Nack message from a
target MM to the source MM was corrupted, delayed, or lost.
T20Ap Expiry
This timer is started when the MM sends an A+ Assignment Failure message to the MSC, and is
stopped when the MM receives an A+ Release message from the MSC. An A+ Assignment
Failure message is sent to the MSC either upon receipt by the MM of a SCAP XC Unsuccessful
Assignment message from the CPP, or upon an assignment request reject condition, such as TC
unacceptable, et
T300Ap Expiry
This timer is set when an A+ Release Complete message is sent to the MSC, in the case of a land
initiated release, or when an A+ Release Complete message is received from the MSC, in the case
of an MS initiated release. It is stopped when an A+ Clear Command message is received from
the MSC. This timer can expire either before or after call setup has completed.
T303Ap Expiry
This timer is set for mobile originations when an A+ CM Service Request is sent to the MSC, and
is stopped when an A+ Call Proceeding is received from the MSC.
This timer will only expire before mobile originated call setup has completed. When this timer
expires, the MM sends an A+ Clear Request to the MSC. Upon subsequent receipt of an A+
Clear Command, the MM performs the appropriate disconnect procedures. This includes
instructing the XC subsystem to release its part of the call (the XC subsystem will not have
already been released on T303Ap expiry), instructing the TCH MCC to release, deallocating
resources at the MM (a terrestrial circuit will not have been assigned by the MSC in this
scenario), and clearing the A+ connection and the SCCP connection.
T308Ap Expiry
This timer is set when an A+ Release message is sent to the MSC, and is stopped when an A+
Release Complete message is received from the MSC. This timer can expire either before or after
call setup has completed. The A+ specification states that if T308Ap expires, then the MM
Motorola Confidential Proprietary 92
should resend the A+ Release message, and if T308Ap times out a second time, then the MM
should send an A+ Clear Request to the MSC. This retry mechanism is not supported. Instead,
upon the first expiry of T308Ap, the MM will send an A+ Clear Request. When this timer
expires, the MM sends an A+ Clear Request to the MSC. Upon subsequent receipt of an A+
Clear Command, the MM performs the appropriate disconnect procedures. The XC subsystem
will already have been released, however the TCH MCC must be released, resources at the MM
must be deallocated (a terrestrial circuit may or may not have been marked busy), and the A+ and
SCCP connections must be released.
T3230Ap Expiry
This timer is set when an A+ CM Service Request is sent to the MSC, and is stopped when any
response, including an SCCP Connection Confirmed, is received from the MSC.
The A+ specification states that the BSC shall send a Reorder message to the MS upon expiry of
this timer. This is not supported.
T313Ap Expiry
This timer is set upon transmission of an A+ Connect message to the MSC, and cancelled upon
receipt of an A+ Connect Acknowledgment message from the MSC.
12.2 XC Timers
For a exhaustive call flow document showing the timers and their place in our world, see Doug
Bohrs document. (http://scwww.cig.mot.com/~bohrer/xc_flow_version0.6.pdf)
XcCpT1
The time that the CPP will wait for a Traffic Channel State Change Indication message from the
XCDR indicating that the XCDR and the TCH MCC have achieved STRAU frame
synchronization following the receipt of the XC Channel Assigned message from the MM.
XcCpT2
RF Loss declaration timer. Set upon receipt of a Traffic Channel State Change indicating Invalid
Speech, received after the first BTS Ack Order is sent to the MS during call setup and a Traffic
Channel State Change indicating Valid Speech has been received. Cancelled upon receipt of a
Traffic Channel State Change indicating Valid Speech. If the timer expires, the call is
disconnected. Recommended default value is 5 seconds.
XcCpT3
The time that the CPP will wait for reception of a Release Order message from the mobile station
in response to transmission of a Release Order to the mobile station, for MSC initiated and CBSC
initiated release procedures.
XcCpT4
Timer for the period during call setup between receiving an indication that the MS has been
acquired (Traffic Channel State Change indicating Invalid Speech, timer is set), and when the MS
has received the initial BTS Ack Order and started transmitting Null TCH Data (Traffic Channel
State Change indicating Valid Speech, timer is cancelled). This timer compensates for the systems
Motorola Confidential Proprietary 93
inability to detect RF Loss during this period. If the timer expires, the call is disconnected.
Recommended default value is 2.5 seconds.
XcCpT5
This timer covers the time that a count of PMRM messages with error above a threshold will be
incremented. This time is MMI configurable and displayable. Its default value is 10 seconds.
XcCpT6
This timer covers the time between transmission of an MCAP Call Summary Request to the
XCDR, and receipt of an MCAP Call Summary Response from the XCDR. Its default value is
800 milliseconds.
XcCpT7
This timer covers the time between transmission of Service Option Request Order using quick
repeat, the forward traffic channel delay, the mobile response delay, the reverse traffic channel
delay, and the reception of the Service Option Request Order, Service Option Response Order or
neither. Its default value shall be 700 ms.
Note that this timer is used in handoff if service option negotiation is required during handoff
procedure. Note that this parameter is also used to calculate ACTION_TIME of Service Option
Request Order; therefore, it should be greater than 80 ms.
XcCpT9
This timer covers the time between transmission of Status Request Order/Status Request message
using quick repeat, the forward traffic channel delay, the mobile response delay, the reverse traffic
channel delay, and the reception of the Status message / Status Response message. Its default
valus shall be 700 ms.
XcCpT10
This timer is used to guard against failure to receive Service Response message in response to the
Service Request message that the CPP sends to the mobile or Service Request message in
response to Service Response message that the CPP sends to the mobile, or Mobile Station Reject
Order (ORDQ=00000010) in response to service request message or service response message
the CPP sends to the mobile. The timer is set to 5 seconds.
XcCpT11
This timer is used to supervise the call setup sequence in the CPP. It is started upon receipt of the
SCAP XC Channel Assigned message and is stopped upon transmission of a SCAP XC
Assignment Successful, SCAP XC Unsuccessful Assignment, SCAP XC Radio Channel Released,
or upon receipt of a SCAP XC Release Radio Channel received before a SCAP XC Assignment
Successful or SCAP XC Unsuccessful Assignment message has been transmitted.
12.3 BTS Timers
MccCpT1
Motorola Confidential Proprietary 94
The time that the TCH MCC will wait to detect the arrival of a MS on an assigned CDMA Traffic
Channel. This timer will be started when the TCH MCC receives the Channel Assigned message
from the XC subsystem.
T200*N200
The time that the Paging/Access Channel MCC will re-transmit the Channel Assignment air
interface message to the MS until a Suspend TCH Assignment message is received instructing it
to stop.
Motorola Confidential Proprietary 95
Chapter 13 Call Detail Logs
CDLs are generally used to answer questions about a specific call that has completed and about
which some question has arisen. They are also used to spot large numbers of call failures or short
duration calls that are associated with specific equipment (TERCKTs or MCC channel elements),
and are also used to provide an indication as to why specific types of call failures (e.g. RF Losses)
occurred.
A Call Detail Log (CDL) is generated by the MM when its participation in a call ends with the
generation of one of a set of designated call final classes (CFCs). The designated set is recent
changeable, and ranges between all CFCs and no CFCs. When the MMs participation in a call
does not end with one of the designated call final classes, the CDL will not be generated. The
MMs participation in a call may be initiated by a mobile origination, a mobile termination, or a
hard handoff from another BSC.
For other papers on this topic:
CFC Resolution documentation
(http://scwww.cig.mot.com/~bohrer/cfc1.1.pdf)
13.1 Analyzing Setup Failures using CDLs
There are a few key fields CDLs that show far the call has progressed. The location and
strength of the probe are shown in the fields,
ACCESS_PN_OFFSET
The number of chips that the MS access burst is offset from the zero offset pilot PN sequence.
ACCESS_STRENGTH
Strength of the MS access burst. ACCESS_STRENGTH must be mapped to dB via the power
control threshold lookup table.
The type of call is given by the
ENTRY_TYPE
0 - Origination,
1 - Termination,
2 - CDMA to CDMA hard handoff,
3 - CDMA to CDMA soft handoff (A+)
The call flow can be followed from the GPROC (CPP/XC) or from the MM point of view,
LAST_MM_SETUP_EVENT
MO events, in decimal:
01 - A+ CM Service Request sent
02 - SCCP CC rx
03 - 08 - Reserved for authentication/ciphering events.
10 - A+ Setup sent
11- A+ Call Proceeding rx
Motorola Confidential Proprietary 96
15 - A+ Assignment Request rx
16 - Assignment of the MS to a TCH was initiated (SCAP Channel Assigned sent to channel
element)
16 - Assignment of the MS to a TCH was initiated (SCAP XC Channel Assigned sent)
17 - The MS was successfully assigned to a TCH (SCAP XC Assignment Successful rx)
18 - A+ Assignment Complete tx
19 - A+ Alerting rx
22 - A+ Connect rx
23 - A+ Connect Ack sent
24 - Assignment of XC resources was initiated (SCAP XC Channel Assigned sent to XC)
25 - Connection of the terrestrial circuit was initiated (SCAP XC Terckt Assignment sent to XC)
MT events, in decimal:
01 - A+ Page Response sent
03 - 08 - Reserved for authentication/ciphering events.
10 - A+ Setup rx
11 - A+ Call Confirmed sent
15 - A+ Assignment Request rx
16 - Assignment of the MS to a TCH was initiated (SCAP Channel Assigned sent to channel
element)
17 - The MS was successfully assigned to a TCH (SCAP XC Assignment Successful rx)
18 - A+ Assignment Complete sent
19 - The MS was instructed to alert (SCAP XC Alert w/Info sent)
20 - A+ Alerting sent
21 - The MS went offhook (SCAP XC Connect rx)
22 - A+ Connect sent
23 - A+ Connect Ack rx
24 - Assignment of XC resources was initiated (SCAP XC Channel Assigned sent to XC)
25 - Connection of the terrestrial circuit was initiated (SCAP XC Terckt Assignment sent to XC)
Target MM Hard Handoff events, in decimal:
01 - Setup TCH resources (SCAP XC Hard Handoff Channel Assigned sent)
02 - TCH Ready (SCAP CDMA XC Target Channel Ready rx)
03 - A+ Handover Request Acknowledge sent
04 - MS on TCH (SCAP CDMA Handoff Successful rx)
05 - A+ Handover Complete sent
(5 bits, display in decimal)
GPROC_SETUP_EVENTS
This is a bitmap of the CPP GPROC setup events. Event applicability is: HHO - Hard Handoffs;
MO - Mobile Origination; MT - Mobile Termination; Setup - Both Mobile Origination and Mobile
Termination; All - Event can occur for any CPP GPROC setup sequence. Events and their bit
positions, with 0 being the least significant bit, are:
00 = STRAU synch achieved w/Valid Speech (All)
01 = STRAU synch achieved w/Invalid Speech (All)
Motorola Confidential Proprietary 97
02 = STRAU synch achieved w/MCC Idle (All)
03 = SCAP Terckt Assignment rx (Setup)
04 = MS acquired (All)
05 = BTS ack order sent (Setup) (Response to event 4 for Setup only)
06 = Setup valid speech (All)
07 = Service Option Response Order/Service Connect message sent (Setup)
08 = L2 Ack to Service Option Response Order/Service Connect received (Setup)
09 = Set Service Option to XCDR sent (All)
10 = XC Alert w/Info rx (MT only)
11 = Alert w/Info sent (MT only)
12 = Alert w/Info acked (MT only)
13 = Connect Order rx (MT only)
14 = XC Connect sent (MT only)
15 = Synched to remote xcdr indication rx (M-M call only) (Setup)
16 = negotiation during setup
17 = Service Request received before CBSC starts Service Negotiation
18 = Status Request Order/Status Request Message sent by CBSC
19 = Status message / Status Response message received by the CBSC
20 = CBSC sends first Service Request message
21 = CBSC sends first Service Response message
22 = CBSC receives Service Request message during Service Negotiation
23 = CBSC receives Service Response message during Service Negotiation
24 = Mobile Station Reject Order received during setup
25 = Last-attempt Service Connect message sent
26 = SCAP: Service Configuration Change Request sent
27 = Service Connect Completion message received
28 - 31 = Spare
For instance, a successful mobile originated call would show a
SETUP_EVENTS=0x000003fc
where 3fc, bits 2-9 set. This means the call went through these steps,
02 = STRAU synch achieved w/MCC Idle (All)
03 = SCAP Terckt Assignment rx (Setup)
04 = MS acquired (All)
05 = BTS ack order sent (Setup) (Response to event 4 for Setup only)
06 = Setup valid speech (All)
07 = Service Option Response Order/Service Connect message sent (Setup)
08 = L2 Ack to Service Option Response Order/Service Connect received (Setup)
09 = Set Service Option to XCDR sent (All)
The call final class (CFC) also indicates the cause of the setup failure.
CFC Type Definition
05 No TCH Preamble Detected
06 No STRAU Synch
Motorola Confidential Proprietary 98
07 No MCC Response at HHO Target
09 No Valid Speech from MS During Call
Setup
10 No Valid Speech from MS During Hand
Handoff
13 CP Timeout awaiting Service Option Ack
20 No Radio Resource Available
21 Requested Terrestrial Re-source
Unavailable
22 Terrestrial Circuit Already Allocated
27 MSC Disconnect with SCCP Connection
Refused
28 MSC Disconnect with SCCP RLSD
60 Protocol Error between BSC/MSC
In addition, other CFCs are considered to be in the setup failure category if they meet the
following conditions. If (CFC=3) and (gproc setup_events=60) A Layer2 failure for BS Ack
during call setup is considered a call setup failure as opposed to a setup failure while on Tch.
13.2 Analyzing RF Losses using CDLs
A CDL indicates a call is an rfloss by setting the CFC equal to 4. There are further details which
can help to show why the experienced an rfloss. These can be examined in order to more fully
understand if the rfloss rate at its minimum. The environment can be seen with the last MAHO
events. One common issue with rflosss is if the last handoff is blocked.
LAST_HO_BLOCKED_CAUSE
Reason that the most recent handoff, hard or soft, was blocked. These are either soft/softer adds
or hard handoffs out that were blocked. A handoff is considered blocked if conditions are met
that would normally cause a handoff to be initiated, but due to other influences do not. Events
that occur that do not result in a handoff being attempted (i.e. pilot does not meet TAdd or
TComp threshold) are not considered a block. If, during a handoff attempt, multiple blocks
occur, the first block cause is saved, as well as the pilot PN associated with the first block. The
values below are the same as those defined in the Detailed Cause element.
00 - No blocked handoffs or no handoffs attempted
01 - Reserved
02 - MSC Rejected Handoff Request
03 - No Response from MSC
04 - Call in Hold
05 - Target Pilot not in Neighbor List
06 - No Mutual Service Option/Configuration
07 - Handoff not Allowed
08 - Service Option not Supported at Target
Motorola Confidential Proprietary 99
09 - No Channel Available
10 - No local inter-CBSC subrate channel available
11 - External CBSC nacked inter-CBSC soft(er) handoff request
12 - No response from external CBSC
13 - Max legs
LAST_HO_BLOCKED_TIME
Time that the most recent handoff was blocked. (32 bits, display only HH:MM:SS)
INIT_MM_REL_EVENT
Events, in decimal:
01 - Normal land party release (A+ Release rx)
03 - Normal MS release (SCAP XC Radio Channel Released rx)
04 - External hard handoff from source
05 - Abnormal MSC initiated disconnect (A+ Clear Command rx, SCCP Connection Refused rx,
SCCP RLSD rx)
07 - Abnormal CBSC initiated disconnect (A+ Clear Request sent)
08 - Abnormal external CBSC initiated disconnect (SCAP IC Target Failure)
Along with the release conditions the last handoff event is an important factor in an abnormal
release.
LAST_SHO_TIME
LAST_SHO_CAUSE
LAST_SHO_RESULT
LAST_SHO_MM_SYSID
LAST_SHO_BTS
LAST_SHO_SECTOR
LAST_SHO_MCC
LAST_SHO_ELEMENT
Last SHO Information from the last handoff instruction sent to the MS. (in SCAP Handoff
Direction message) If the first handoff instruction is also the last, the information is saved in this
element.
LAST_SHO_TIME is time when handoff instruction is sent (when MM sends SCAP Handoff
Direction message) - 32 bits, only HH:MM:SS is displayed.
LAST_SHO_CAUSE - 7 bits, displayed in decimal:
08- soft handoff add
09- soft handoff drop
11 - hard handoff
12 - softer handoff add
13 - softer handoff drop
LAST_SHO_RESULT (2 bits):
0 - call was disconnected before success or failure occurred
1 - handoff was executed (SCAP Handoff Successful received)
2 - time-out, SCAP Handoff Unsuccessful or IC Handoff Request Nack received - handoff was
not executed
Motorola Confidential Proprietary 100
MM_SYSID - 8 bits, displayed in hex.
BTS - 11 bits, displayed in decimal.
Sector - 3 bits, displayed in decimal.
MCC - 7 bits, displayed in decimal.
Channel Element - 6 bits, displayed in decimal.
Along with the last handoff the pilots available to the mobile can also provide information on the
immediate environment at the time of the rfloss. If the call in in 3 way and the active pilots
strengths are low while the candidate fields are all also fairly low then the mobile might be in a
non-dominate pilot region which would require further optimization.
LAST_MAHO_TIME
LAST_MAHO_CAUSE
7 bits, displayed in decimal:
08- soft handoff add
09- soft handoff drop
11 - hard handoff
12 - softer handoff add
13 - softer handoff drop
Information on the up to three active set pilots is saved in the LAST_MAHO_ACT fields.
Information on up to three of the strongest candidate set pilots is saved in the
LAST_MAHO_CAND fields.
LAST_MAHO_ACT1_BTS
LAST_MAHO_ACT1_SECTOR
LAST_MAHO_ACT1_STR
Last MAHO Information top 3Active, and top 3 candidates. PN Index Offsets from the Handoff
Recognized message are converted to a BTS and Sector. MM_SYSID - 8 bits, displayed in hex.
BTS - 11 bits, displayed in decimal. Sector - 3 bits, displayed in decimal. STR is the Ec/Io
Measurement as received from the MS - 8 bits, displayed in hex
13.3 Analyzing Call Performance with CDLs
Steady state call performance pegs within the CDLs can help to indicate:
softhandoff rates, number of average softhandoffs per call
softhandoff factor (SHOF)
forward and reverse link quality
The use of local and external handoff pegs allows the operator to keep track of the inter-cbsc
border counts for various CBSC borders. By counting the 1-2-3 pilot pegs for certain call final
clasess the SHOF can be determined. The pegs used to indicate these are shown below.
1_PILOT
2_PILOT
3_PILOT
Motorola Confidential Proprietary 101
LOC_PILOT_ADDED_SOFT
LOC_PILOT_ADDED_SOFTER
LOC_PILOT_DROPPED_SOFT
LOC_PILOT_DROPPED_SOFTER
EXT_PILOT_ADDED_SOFT
EXT_PILOT_ADDED_SOFTER
EXT_PILOT_DROPPED_SOFT
EXT_PILOT_DROPPED_SOFTER
Soft handoff transition pegs, pegged when call moves successfully into the given soft or softer
handoff state. Pegs are not to overflow to zero. The maximum peg value is 15. The initially
allocated MCCce does not count against any pegs. 1, 2, or 3 Pilot(s) are incremented when the
new handoff state contains that number of active pilots. Local and external pilots are counted.
Pilot added/dropped soft(er) are incremented when the handoff transition involved one of these
actions.LOC refers to pilots local to the CBSC, EXT refers to inter-CBSC soft(er) (trunking)
pilots.
Mulitpilot pollution or the number of excessive pilots causes both excessive softhandoff rates and
can deminishes call quality.The amount of pilots requiring pilot shuffles is one indication of this
environment.
3WAY_BETTER_ACTIVE
Handoff peg, pegged when a drop was initiated out of a 3 way state because a candidate pilot was
determined to be better suited for the active set (pilot shuffle). Pegs are not to overflow to zero.
The maximum peg value is 15
The forward and reverse quality of the call(s) can be calculated from by time averaging the call
lengths with the forward and reverse quality pegs. These pegs occur when possible audio
anomlies (usually blanking) might occur.
ACCESS_TIME
RELEASE_TIME
FWD_QUALITY
The count of excess PMRMs (fwd_quality) during a configurable interval can provide an
indication that excessive forward channel frame erasures occurred, close enough together and for
a long enough duration to possibly impact perceptible call quality. The timestamp associated with
the last occurrence of this event can be correlated with the release time. If they are closely
associated, this might be an indication that one or the other party abandoned the call because the
channel degraded to an unacceptable level. In XcCpT5 (10 seconds), if pmrm_threshold (3)
PMRMs are seen then the peg will increment.
RVS_QUALITY
The Reverse TCH Call Quality Indicator will count the number of 2.56 second intervals (128
frames), over the duration of the call, that reverse TCH FER has exceeded a threshold. This can
provide an indication of the number of times over the duration of the call that the channel quality
Motorola Confidential Proprietary 102
has degraded below an acceptable level. For example, if the threshold is set to 14, then at the end
of a call the count will be the number of 2.56 second intervals that the reverse TCH FER
exceeded 10% (14/128).
Motorola Confidential Proprietary 103
Appendix A: List of Terms and Acronyms
BBX Base Band Transceiver Card
BTS Base Transceiver Site
CDL Call Detail Logs, show call final causes, range, audio quality, last state
information, number of SHOs during call, number of peak forward gain
indications, number of peak reverse gain indications, lots more.
CDL Logs Call detail logs created during a CLI session from the OMCR with the
browse CDLLOG command
CDMA Code Division Multiple Access
E
b
/N
o
Energy-per-bit-to noise-per-hertz ratio.
E
c
/I
o
The ratio of average transmit energy per PN chip for the Pilot Channel,
Sync Channel, Paging Channel, Forward Traffic Channel, power control
sub channel, or OCNS to the total transmit power spectral density
FER Frame Erasure Rate
FPC Forward Power Control
IS-95A Mobile Station-Base Station Compatibility Standard for Dual-Mode
Wideband Spread Spectrum Cellular Mobile Stations
J-STD-008 Personal Station-Base Station Compatibility Requirement for 1.8 to 2.0
GHz Code Division Multiple Access (CDMA) Personal Communications
Systems.
L-M Land to Mobile Call
M-L Mobile to Land Call
MAHO Mobile Assisted Handoff
MCC Multi-Channel Card
OMCR Operations and Maintenance Center - Radio
PCB Power Control Bit
PMRM Power Measurement Report Message
PSMM Pilot Strength Measurement Message
RPC Reverse Power Control
SIF Site Interface Frame (SC9600 element)
Trouble Corner An effect in an urban environment where a subscriber unit is shadowed
from a neighbor pilot different than the active pilot. When the shadow is
eliminated the neighbor pilot rapidly increases in power interfering with
the active set pilots.
XC Transcoder
XLOS A tool used to estimate path loss.
Motorola Confidential Proprietary 104
Appendix B: System Monitoring Application Process
Motorola Confidential Proprietary 105
XC FEP CPP
MM
OMC
FER
L2
L3
SHO
BTS-N
SMAP
Reverse Frame Erasures
IS-95 L2- BS/MS ACKs
sequence numbers IS-95 L3
Internal
Channel Assignments
SHO Assignments
Each BTS shows:
RSSI, Eb/No, Forward Gain, Sector Forward Power
SMAP Messages
Call Detail Logs
Performance Management
Call Detail Logs - show Call Final Classes, call length, SHO
completions, last link information, forward and reverse burst pegs, access distance,
access strength, and much more.
Performance Management
ACTCALL - TCH pegs per cell-sector 1-2-3
completions CALLSETUP - call setup attempts/completions per cell-
sector CARSECGRP - usage time per cell-
sector
Motorola Confidential Proprietary 106
Appendix C: Performance Managament - Short Review of Contents
The following reports can be used to generate loading rates, call success rate, good/bad cell/MCC
statistics. Trends can be noted, busy hour performance examined, cell loading per plan/per
parameterization analyzed.
MCC usage channel element report
MCCUSAGE BTS-MCC-CE: Call setups,Origination Assigns, Termination Assigns,
Origination Completions, Termination Completions, 1-2-3 Way RF Losses
Call setup report
CALLSETUP BTS-MCC-CE: Origination attempts, failure due to -
RF/MSC/Assignment, termination attempt, failures due to
RF/MSC/Assignment
Sector Soft Handoff Source/Target
Softersrc/tar BTS-MCC-CE: Add attempt, add complete, drop attempt, drop complete
(total, 1-2, 2-3, 3-2, 2-1)
Sector Active Call Report
ACTCALL BTS-MCC-CE: 1-2-3 way connections, 1-2-3 way occupancy, 1-2-3 way
RF Losses
Sector Registration Report
REGISTRATION BTS-MCC-CE: slotted, non-slotted accepted/failed registrations, power
up, parameter, misc registration counts success/failures.
Sector Inter-CBSC hard handoff Source/Target Report
HARDSRC BTS-MCC-CE: Attempt/complete for CDMA hard and analog
Carrier Site Group Report
CARSECGRP BTS-Channel group: Max member equipped, group usage minutes, OOS
minutes, all channel busy minutes, group assigment, attempt, overflow
MM Page Report
MMPAGE CBSC: Pages, slotted, non-slotted, ack/not ack