Handoff

Motorola Confidential Proprietary
1.0 Definitions 7
2.0 Issues and Solutions 11
2.1 Hard Handoff after Soft Handoff 13
2.1.1 Background 13
2.1.2 DAHO Trigger Review 13
2.2 AHHO Trigger 14
2.3 Seam Location 14
2.4 Optimization Strategy 15
2.5 AHHO Enhancements 18
2.6 Estimating Post-Seam HHO Performance 18
2.7 Joe’s Bullets 19
2.8 Inter-CBSC and Inter Carrier Hard Handoff 21
2.8.1 Use of Pilot Beacon 21
2.8.2 Use of Frequency Hopping Pilot Beacon 21
2.8.3 Traffic Planning 21
2.8.4 DAHO 21
2.8.5 PrimeCo Chicago Proposal 21
2.8.6 Hong Kong Configuration 22
2.9 Inter-CBSC and Inter Carrier Soft Handoff 27
2.10 InterCBSC and Intra Carrier Hard Handoff 29
2.10.2 DAHO 29
2.11 InterCBSC and Intra Carrier Soft Handoff 31
2.12 IntraCBSC and Inter Carrier Hard Handoff 33
2.12.4 DAHO 33
2.13 IntraCBSC and Inter Carrier Soft Handoff 35
2.14 IntraCBSC and Intra Carrier Hard Handoff 37
2.14.2 DAHO 37
2.15 IntraCBSC and Intra Carrier Soft Handoff 39
3.0 CDMA Handoff Deployment & Optimization 41
3.1 Summary 41
3.2 Statement of the Problem 41
3.3 Scope and Audience 41
3.4 Organization 41
3.5 Definitions 41
3.6 Hard Handoff General Operation 41
3.6.1 General Operation 41
Page 1 of 6
3.7 Pilot Beacon 42

3.7.1 Intra-Carrier Hard Handoff Optimization 42
3.8 Intra-Carrier Hard Handoff Deployment Tips 43
3.9 Inter-Carrier Hard Handoff With Pilot Beacons (Multi-Carrier) 44
3.10 Inter-CBSC Hard Handoff With Pilot Beacons 44
3.11 DAHO and Inter-CBSC Soft Handoff 46
3.11.1 Single Cell Intra-Carrier Hard Handoff 46
3.11.2 Dual Cell Intra-Carrier Hard Handoff 46
3.12 Nondominant PN 49
3.13 Idle mode handoff 51
3.14 PN Planning 55
3.14.1 micro-cell 55
3.14.2 in-building 55
3.15 Neighbor Window Search Planning 81
3.16 Microcell 83
3.16.1 When to Deploy 83
3.16.2 Intercarrier issues 83
3.17 InterVender Hard Handoff 85
3.17.1 IS-634 85
3.18 InterVender Soft Handoff 87
3.18.1 IS-634 87
3.19 Customer Specific Issues 89
3.19.1 KTF 89
3.19.2 Hong Kong MTR 89
3.19.3 Singapore 89
3.20 HHO as soon as One-Way 91
3.21 CDMA Soft Handoff Optimization 93
3.21.1 Introduction 93
3.21.2 General Mechanics of Soft Handoff 93
3.21.3 Mobile Station/Base Station Data Analysis 100
3.21.4 General Conclusion 105
4.0 Present Tools 127

4.1 Pilot Beacon 129
4.2 Qualcomm solution 129
4.3 Motorola solution 129
4.3.1 Integrated Solution 129
4.3.2 Stand alone solution 130
4.3.3 Paging and Sync Channel Requirements 130
4.3.4 how to set up paging and sync channels to redirect idle mode mobiles 131
5.0 CDMA Pilot Beacon Applications 133

5.1 Scope 133
5.2 Objective 133
5.3 PILOT BEACON CONCEPT OVERVIEW 133
5.4 PILOT BEACON DEPLOYMENT SCENARIOS 134
5.4.1 Scenario A: Inter-Carrier HHOs for Partial Overlay Multi-Carrier 135
Page 2 of 6
5.5 Scenario B: Pilot Beacon to Perform Inter-CBSC Hard Handoffs 137

5.5.1 Primary Deployment Option (“Spot Beacon” Approach) 137
5.5.2 Requirement for Broadcasting Pilots in all Beacon Sectors 139
5.6 KNOWN LIMITATIONS 140
5.6.1 Idle Mode Handoffs 140
5.6.2 Mobile Re-direction with CDMA Channel List Message 140
5.6.3 Mobile Behavior with Loss of Service 141
5.6.4 Recommendations 141
5.7 Subscriber Capacity Limits 142
5.8 IMPLEMENTATION 142
5.8.1 Hardware Requiremets 142
5.9 Installation and Optimization 143
5.10 Beacon Span Requirements 143
5.11 REFERENCES 143
5.12 SC-2.5.1 Pilot Beacon Installation 145
5.12.1 BTS Modifications - Beacon Settings 145
5.12.2 BTS Calibration File Description. 146
5.12.3 Step-by-step procedure to change Bay Level Offsets with Script: 147
5.13 Database Provisioning 147
5.13.1 GENERAL ADD SECOND CARRIER COMMANDS 147
5.13.2 Mobile Programming 149
5.13.3 Source Database Configuration 149
5.13.4 Neighourlist Additions 149
5.13.5 External Sector Topology 149
5.13.6 Optimization Techniques 151
6.0 Idle Handoff Solution Description 155

6.1 Idle Handoff Equipage Procedural Detail 156
6.2 Pilot Beacon Output Power 157
6.3 Expectation for Empirical Results 158
6.4 Static Simulator 159
6.5 Partial Overlay 161
7.0 FutureTools 163
7.1 Frequency Hopping Pilot Beacon 165
7.2 N-Way SHO and Complex SHO (Barry’s paper or parts thereof 181
7.3 Umbrella Cell 209
7.4 Six Sector 211
7.5 DAHO optimization strategies 213
7.6 Back To Back Antennas 215
7.7 Mobile Specification Changes 217
7.8 Nokia/Qualcomm contribution. 217
7.9 DeClerck/Ashley improvements. 217
7.10 Pilot Dominance 223
7.11 Complex Handoff 225
7.12 Edge Sensing 265
7.13 Description and discussion. 265
Page 3 of 6
7.13.1 Tune TADD/TDROP/TTDROP to force the mobile into less soft-handoff. 265
7.13.2 Design the frequency seam using natural topological features, such as rivers, large open
tracts of land (less clutter).265
7.14 E911 techniques which may be used for hard-handoff detection. 266
7.14.1 Bruckert/Ghosh/ et. al. developments. 266
7.14.2 DeClerck/Harris improvements. 266
8.0 Background 269

8.1 CDMA Hard Handoff Problems & Solutions 271
8.1.1 Hard Handoff Topics 271
8.1.2 IS-95A Pilot Definitions 271
8.1.3 Pilot Status Transitions 271
8.1.4 Pilot Strength Measurement Message 271
8.1.5 Pilot Scan Algorithm 272
8.1.6 Pilot Scanning Basics 272
8.1.7 Pilot Scan Algorithm Implications 272
8.1.8 The Hard Handoff Problem 273
8.1.9 Multi-Carrier Handoff (“Wedding Cake” Example) 273
8.1.10 “Spot Capacity Relief” Example 273
8.1.11 Hard Handoff Algorithm 273
8.1.12 Intra-Carrier Hard Handoff 273
8.1.13 Pilot Beacons (Inter-Carrier Hard Handoff) 274
8.1.14 Pilot Beacon Deployment (Inter-CBSC Handoff Example) 275
8.1.15 Pilot Beacon Deployment (Multi-Carrier Example) 275
8.1.16 Pilot Beacon Optimization 275
8.1.17 Idle Mode Handoff Problems 275
8.1.18 Idle Mode Handoff Solutions 276
8.1.19 Capacity With Pilot Beacons 277
8.1.20 Additional HHO Solutions Under Study/Consideration 277
8.1.21 Edge Sensing (DAHO) 278
8.1.22 DAHO Deployment 279
8.1.23 Edge Sensing (Ec/Io Thresholding) 279
8.1.24 Edge Sensing (Ec/Io Thresholding Example) 279
8.1.25 CDMA Scan Receivers 279
8.2 Moving the Selector 307
9.0 Release Schedule 311
9.1 Release 5 311
9.2 Release 6 311
9.3 Release 7 311
9.4 Release 8 311
9.5 Release 9 311
9.6 Release 10 311
10.0 Competition 313
11.0 Summary 321
11.1 CDMA to Analog (AMPS/NAMPS/TACS) handoff, same service provider 321
11.2 N carriers to N-1 carriers handoff (CDMA carrier handoff). 321
11.2.1 Extra carrier for In-building or tunnel, spot coverage. 321
Page 4 of 6
11.2.2 Extra carrier for large scale changes in population density (Urban to suburban/ Suburban
to Rural)321
11.2.3 Notes on systems that have older non-adjacent frequency scanning mobiles. 321
11.3 Intersystem seam (where the Carrier bands do not intersect) 322
12.0 Vision 323
12.1 Timeline 323
13.0 System’s Engineering Recommendations 325
13.1 Criteria for Successful Feature Deployment and Operations: 325
13.2 New CDL format: 325
13.3 Trouble-Shooting Guide: 326
13.4 Inter-CBSC Planning Guide: 326
13.5 Inter-CBSC Application Note: 326
13.6 ATP for the Inter-CBSC SHO: 326
13.7 Inter-CBSC Customer Presentation: 326
14.0 Bibliography 329
Page 5 of 6
Page 6 of 6
1.0 Definitions
New terms for microcells and umbrella cells.
AHHO: see Anchor Hard Handoff
Anchor Hard HandOff. A technique used in R7 CBSC software to transfer transcoder control from one
CBSC to another CBSC after successful inter-CBSC soft handoff. The need for AHHO is deemed to be ter-
mporary in nature as future software functionality will obviate the need for AHHO by allowing subsequent
CBSC seam and multi-carrier transitions. R7 software needs the AHHO to allow CBSC seam and multi-
carrier transitions, etc.
Cell Swapping: An algorithm in the infrastructure that works with Partial N-Way SHO and actually per-
forms reverse link handoff (switching an XC connection) from one cell (BTS) to another. It is an operation
similar to Fast Pilot Shuffling, however performed at the BTS, rather than PN, level.
Cell Swapping: The exchange of all legs between a mobile and one BTS with one or more legs to a BTS
not currenlty serving the mobile.
Complex Handoff: A handoff instruction to the mobile station which makes more than one change to the
mobile’s active set.[3]
DAHO: see Data Base Assisted Handoff.
Data Base Assisted Handoff: handoff techniques that use information on cell configuration stored in the
CBSC/BTS along with the system’s knowledge of which cells/sectors control a particular call. DAHO tech-
niques may be used to trigger hard handoffs.[3]
Fast Pilot Shuffling. Also known as “FPS”, a technique used in R5, R6, and R7 whereby T_TDROP tim-
ers for active set pilots are preempted only in three way SHO when in the presense of a candidate set pilot
that meets the shuffle criteria. Fast Pilot Shuffling does not discriminate between soft and softer connec-
tions.
Full Complex Handoff: This feature implies the ability (on the part of the infrastructure) to perform multiple
add and/or drop operations within one Extended Handoff Direction Message. Because of the desire, at the
time of Extended Handoff Direction Message transmission to utilize the maximum number of currently
available forward and reverse links for the procedure transaction, this also implies 2N forward/reverse links
where N is the maximum expected size of the active set.
Full Complex Handoff: The infrastructure’s ability to perform a complex handoff with the maximum num-
ber of legs being changed that is allowed by the IS-95 Air Interface Specification. (During the full complex
handoff, the infrastructure should use all of the old legs and all of the new legs. For example, if the mobile
has 3 legs and the infrastructure wants to replace 1 of the legs with 2 different legs, the infrastructure
should use the 3 currently active legs and on the 2 new legs. If the mobile can support N legs, the infra-
structure should support 2N legs during the full complex handoff.)
Full Diversity N-Way: This feature implies everything contained with “Full N-Way” as well as subscriber
unit hardware with N demodulation elements.
Full N-Way: This feature implies XC hardware able to support 6 forward and 6 reverse links. Uses “Next
Generation” or “improved” XCDR circuitry that supports the ability to manage 6 MCCce’s.
HHO. Hard HandOff.
Page 7 of 10
HHO Complex: Also known as “complex HHO”, this feature implies the ability on the part of both sub-
scriber unit and infrastructure to connect the subscriber unit into at least 3-way soft/softer handoff immedi-
ately at the target following an Extended Handoff Direction Message. Thus, N forward links are transmitting
as the subscriber unit performs connection procedures at the target.
Infrastructure Assisted Pilot Dominance: This feature implies a handoff algorithm on the part of the
infrastructure that examines active set and candidate set pilot Ec/Io estimates in the Pilot Strength Mea-
surement Message and attempts to determine an optimal active set while simultaneously minimizing the
number of forward link transmitters to the minimum required for quality forward link reception.
Leg: A communications path between the infrastructure and a mobile that uses one PN offset and one
Walsh code in the forward direction.
MAHO: See Mobile Assisted Handoff
Mobile Assisted Handoff: handoff techniques that use measurements made by the mobile and returned
to the BTS. MAHO techniques may be used to trigger soft, softer and hard handoffs.[3]
Mobile Assisted Pilot Dominance: This feature refers to the recent Qualcomm proposal of using a sec-
ondary threshold that is a function of the sum of the active set SNRs as a technique to inhibit Pilot Strength
Measurement Messages. See appendix #B for clarification of the Qualcomm proposal.
Non-Dominant PN. This is a condition defined by good/excellent RF coverage (non-thermal noise limited
case, >-80 dBm) with poor pilot Ec/Io performance. Also described by some in the industry as “pilot pollu-
tion”.
Partial Complex: This feature implies those complex operations that may be accomplished by utilizing
existing XCDR hardware. These operations are defined by the Jim Aldrich matrix and constrained by the
number of forward and reverse links required to complete any given handoff operation1.
Partial N-Way: This feature implies the ability to support up to 6 forward (Walsh codes) and 3 reverse
links2. Uses currently available XCDR circuitry. Forward links are a mix of soft and softer connections such
that we are always constrained to 3 reverse links.
SHO. Soft HandOff.
Soft Handoff: a state where a mobile station is communicating with two or more cell sites simulta-
neously.[3]
Soft Shuffling. A technique used with Partial N-Way SHO whereby a pilot at one BTS is swapped out in
favor of another, superior performing, pilot at another BTS. Both BTSs currently serve the subscriber unit.
Soft Shuffling. A technique used with Partial N-Way SHO whereby a pilot at one BTS is swapped out in
favor of another, superior performing, pilot at another BTS. Both BTSs currently serve the subscriber unit.
1. As an example, consider the situation where a subscriber unit is in 3-way SHO between 3 different BTSs.
If we wanted to simultaneously add a new BTS while dropping one of the existing BTSs, we’d still want
to transmit the Handoff Direction Message via the transmitters of the 3 existing BTSs and receive the
Handoff Completion Message via the receivers of the 3 new BTSs. Due to current downlink combining
techniques, we can’t just decide to drop a transmitter from the active set without first informing the sub-
scriber unit, etc.
2. If the combining bit in the Extended Handoff Direction Message is used, then the mobile only responds to
3 sets of PCG puncture bits.
Page 8 of 10
Softer Handoff: similar to soft handoff except that two of the cell sites involved are sectors of the same
cell.[3]
Softer Handoff: two or more legs of a call are to the same cell.
Softer Shuffling. A technique used with Partial N-Way SHO whereby a pilot at one BTS is swapped out in
favor of another, superior performing, pilot at the same BTS.
Softer Shuffling: A handoff that involves adding or removing legs that are in softer handoff. An old leg is
removed before a new leg is added.
TADD: 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 station’s active set via a soft or softer handoff.[3]
TAdd (Database Parameter): 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.[3]
TCOMP: 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.[3]
XASECT (database parameter): eXternal Analog SECTor
XCSECT (database parameter): eXternal Cdma SECTor
TComp (Database Parameter): 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.[3]
TDrop (Database Parameter): 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.[3]
TTDrop (Database Parameter): 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 Parame-
ters Message, RF: Extended Handoff Direction Message, and the RF: In Traffic System Parameters Mes-
sage.[3]
HandOffMode (Database Parameter): 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 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.[3]
PilotInc (Database Parameter): 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
Page 9 of 10
and the RF: Neighbor List Update Message. The XC must use the same value as is contained in the
MIB.[3]
NeighborList (Database Parameter): This list contains all of the neighbor sector PN offsets for the cur-
rent call. This parameter is passed to the XC in both the SCAP: CDMA Update Parameters Message and
the SCAP: CDMA XC Channel Assigned Message.[3]
DAHO (Database Parameter): This parameter indicates whether a sector-carrier is near a border and
contains neighboring or overlapping sectors operating on another frequency and/or non-CDMA signalling
scheme.[3]
DAHOHysTimer (Database Parameter): This parameter is used to prevent ‘ping-pong’ handoffs between
two sectors which have been marked with the DAHO flag. After a hard hand-in, origination, or termination
in a border sector, majority border checks will be disabled for a period of time in seconds equal to the value
of this parameter.[3]
HandoffMethod (Database Parameter): This parameter specifies the method (none, hard, soft trunking,
soft aplus) to be used to hand the call off to a sector external to the CBSC. The scope of this parameter is
per external CDMA sector.[3]
Inter-CBSC Soft Handoff Override (Database Parameter): This parameter is used to ‘turn-off’ Inter-
CBSC soft handoffs between two MMs. It is checked by both source (in handoff detection) and target pro-
cedures. When override is allowed, the alternative action of either no handoffs or hard handoffs is indicated
(no handoffs, hard, no override). The scope of this parameter is per inter-CBSC trunk group.[3]
AnchorHoMeth (Database Parameter): this per CBSC parameter indicates the condition upon which trig-
ger the source MM to move a mobile in Inter-CBSC soft handoff from a source (or ‘anchor’) MM to a target
MM once all the source legs have been dropped (keep soft, on no source legs, on all legs remote). The
parameter can be used to keep calls in soft handoff, to execute a hard handoff when there are no source
legs in the call, and to execute a hard handoff when all the legs are remote, i.e. no known XCSECT repre-
sentations in the source CBSC.[3]
Page 10 of 10
2.0 Issues and Solutions

Each sub-section in Section 2.0 contains a problem description and a solution.
Page 11 of 12
Page 12 of 12
2.1 Hard Handoff after Soft Handoff

The Release 7 form of inter-CBSC soft handoff requires that some calls go through a
hard handoff. This hard handoff is alternatively known as “post seam HHO” or “AHHO”
(Anchor Hard HandOff). This document describes how to minimize the impact of the hard
handoff.
This document describes optimization strategies for improving the performance of the
AHHO.
2.1.1 Background
2.1.1.1 Hard Handoff Problem Description
The hard handoff is required to move the selector function (the software/hardware that
selects the best reverse link VCELP frames to be converted to PCM) from one CBSC to
another. See Section 8.2, “Moving the Selector,” on page 307.
2.1.1.2 Anchor HHO and DAHO - Database Assisted HandOff
DAHO uses cell configuration information stored in the CBSC/BTS along with the sys-
tem’s knowledge of which cells/sectors control a particular call. DAHO is typically used to
transition calls from one CDMA carrier to another (intra-CBSC case) or from a CDMA
carrier to an analog carrier (AMPS, NAMPS, TACS).
The AHHO (associated with ICBSC-SHO) is similar to DAHO in that the trigger criteria is
equivalent. In addition, the target selection (antenna) criteria is identical in that the stron-
gest active set pilot Ec/Io in the most recent Pilot Strength Measurement Message is
used. The departure between AHHO and DAHO is that AHHO is always intra-carrier in
nature. DAHO is always inter-carrier in nature.
2.1.2 DAHO Trigger Review
The DAHO handoff detection criteria is described in Section 7.5, “DAHO optimization
strategies,” on page 213. Note that the handoff is driven off of a table that describes the
number of soft handoff legs supporting the call from “handout” sectors (i.e. “border sec-
tors”). These sectors can also be omni-directional cellsites. Note also that the target
selection portion of the DAHO algorithm allows inter-cell hard handoff, however this is not
the preferred method. The preferred method uses an intra-cell hard handoff to a single
sector. The target is chosen from the current active set pilot list using that active set pilot
that demonstrates the “best” performance. “Best performance is defined by the strongest
Ec/Io measurement in the most recent Pilot Strength Measurement Message prior to sat-
isfaction of the detection criteria.
Based upon the above trigger criteria, and the target selection criteria, it is easy to spec-
ulate that the “safest” post-seam HHO (Hard HandOff) occurs on a soft handoff drop
event when the active set is reduced from 2 active pilots to 1 active pilot. In this scenario,
there is no ambiguity as to which target will perform best after the HHO as the target
“range” is limited to a single pilot.
Based upon the previous reasoning, it is also easy to speculate that the poorest perform-
ing post-seam HHO occurs upon completion of a pilot shuffle operation. In this particular
Page 13 of 20
scenario, there exist at least1 3 active set pilots that could potentially be used to desig-
nate a target sector. In situations where all pilots perform equally well and with excellent
FER margin, there is little probability of losing the call. More than likely, this will not be the
case, and the system engineer will be presented with additional optimization tasks to
attempt to improve the success of the handoffs.
2.2 AHHO Trigger
AHHO trigger criteria is somewhat similar to that of DAHO. The criteria for triggering the
AHHO occur when:
• No active set pilots originate from the “anchor-side” of the CBSC seam.
• No active set pilots originate from XCSECT sectors within the target CBSC that are associated with the “anchor-
side” of the CBSC seam.
The purpose of the two trigger criteria is to provide the system designer with tools to cre-
ate an inter-CBSC “hysteresis region”. It should be the obvious intent of the system
designer to minimize AHHO operations2. Consider Figure 1 below for a case of a sub-
scriber unit moving from left to right. AHHO is triggered when no active set pilots sup-
porting the call originate from either the “clear” or “striped” cells in the diagram. This
implies that all active set pilots, at the time of AHHO, originate from the “spotted” cells in
the diagram. Note that one of the “spotted cells” would be the (1-Way) target of the
AHHO.
Figure 1: Simplified AHHO Seam Construction Layout

CBSC #1 CBSC #2 Key
CBSC #1 “anchor-side” cell
“XCSECT” cell for CBSC #1
CBSC #2 Cell
(Not “XCSECT” cell for CBSC #1)
CBSC Seam
2.3 Seam Location
1. Note that plans currently exist for implementation of N-Way SHO (Soft HandOff) where N will be greater
than 3. This is expected to further complicate the situation being described.
2. This is due to the fact that any type of HHO has inherent risk relative to soft handoff operations. At the
time of this writing, SHO success rate is nominally greater than 99.5% while HHO success rate (Pilot Bea-
con, inter-carrier) is deemed to be on the order of 92%-97%.
Page 14 of 20
The primary goals of the AHHO deployment should be to simultaneously minimize

thrashing of the A+ interface (and related switching equipment) while minimizing the
number of RFLOSSs associated with AHHO. Due to the “width” of the target CBSC
region, it might not be possible to implement a hysteresis region to suppress ICBSC-
SHO “ping-ponging”. Thus, the former goal might be sacrificed in favor of the latter goal.
It is inevitable that the system designer will be presented with some number of patholog-
ical situations that are vexing in terms of optimality of seam placement. There may be
constraints due to CBSC traffic loading, frequency planning, BTS/CBSC span backhaul
or microwave concerns, or others. Given that none of these constraints is present, and
that the designer has freedom to choose, selection criteria should be based upon the fol-
lowing list:
• Gradual pathloss roll-off.
• Deployment restricted to “large” cells only1
• No quick NLOS to LOS or LOS to NLOS transitions.
• No low altitude antenna placements that increase the likelihood of NLOS to LOS (or vice versa) transitions.
• No seams in areas of weak RF coverage.
• No seams in areas of non-dominant PN.
• Avoid “distant” soft handoff connections where some probability exists of selecting the “distant” cell as the target
of the DAHO. This has to do with slew rate by the subscriber unit if the reference pilot needs to be changed (see
below).
2.4 Optimization Strategy
DAHO (Database Assisted HandOff) uses cell configuration information stored in the
CBSC/BTS along with the system’s knowledge of which cells/sectors control a particular
call. There are a host of issues that the system designer must be cognizant of when
designing an inter-CBSC SHO system. The following is a non-comprehensive list of
some issues that should be considered. Seam optimization is, no doubt, a multi-variable
optimization problem. The sensitivity of the problem to any particular variable is probably
location specific. It is up to the system designer to understand the issues pertinent to his/
her own market and prioritize these issues in rank order appropriate to the circum-
stances2 of that market.
• The RF system performance of power control and soft handoff across inter-CBSC seams. This topic is addressed
in slightly more detail below. In general, we expect handoff and power control operations to be slower in the inter-
CBSC case than in the intra-CBSC case.
• Load-balancing or “re-parenting” of cells under CBSCs. This has to do with providing equal growth for N CBSCs
in the system under consideration. Sometimes, re-parenting causes inter-CBSC seams to placed in locations that
are ideal for load-balancing but non-optimal for RF performance, etc.
1. This begs the question of urban deployments of ICBSC-SHO. The intent here is to provide a “stable” set
of Ec/Io measurements from which to base target selection. A high velocity subscriber unit moving through
a set of micro-, or pico-, cellular structures might be subject to rapidly changing rank ordering of the active
set Ec/Io measurements, causing lack of certainty in the target selection.
2. These could be some combination of customer preferences, constraints due to physical facilities, (future)
experience with inter-CBSC SHO performance, etc.
Page 15 of 20
• AHHO mode performance.

• Trunk hardware and other possible transmission or interconnect facilities constraints.
• Proximity to “other” CBSC seams. See Joe Pedziwiatr’s Inter-CBSC SHO web page for further information on
seam planning constraints relative to software capabilities in any given CBSC software release.
• Proximity to inter-carrier borders.
Our current assumptions regarding success of the DAHO procedure are as follows:
• The algorithm will work poorly in regions identified as being “non-dominant PN”1.
• The algorithm will work poorly in regions identified as being poor, or marginal, in terms of RF coverage.
• The algorithm will experience difficulties in handling regions identified as having high utilization of the Fast Pilot
Shuffling algorithm.
There are some techniques that the optimization engineer can use to enhance the suc-
cess of DAHO. Some enhancement techniques may be limited by the amount of freedom
associated with repositioning antenna mounts. As an example, consider the engineer
who is faced with the difficulty of improving DAHO success rates while maintaining suc-
cess rates for an analog service used by the same antennas, etc.
Some specific DAHO optimization tips/techniques:
• Keep soft handoff longer with non-border cells (general case) or source CBSC pilots (ICBSC-SHO case): This
might be useful in those instances where the optomizer has observed that nominal DAHO procedures are failing
due to the location of the handoff. This technique strives to move the handoff location by prolonging connection to
non-border cells for a longer period of time, possibly to a location that is more advantageous to the DAHO algo-
rithm. The inverse of the situation would be to try and promote early handoff if this was desired. Both methods
may be attempted by varying the T_TDROP timer and/or the value of T_DROP in the area2 of interest.
• Keep soft handoff longer with source CBSC pilots (ICBSC-SHO case): This has the benefit of allowing calls more
time terminate normally and avoid an AHHO altogether. Obviously, the technique where XCSECTs are used to
create a spatial hysteresis region works to much greater advantage in this case.
• Making areas of pilot dominance: Since the DAHO target selection process is dependent on Ec/Io measurements
contained within the Pilot Strength Measurement Message, it makes sense that the success rate will be dependent
on . . . make the handoff drop occur, or make pilot dominance from the target perspective. As an example, con-
sider target selection from a soft handoff state where several active set pilot Ec/Io’s are represented in the Pilot
Strength Measurement Message. The resulting target connection reliability would look something like the dia-
gram below.
1. The term “pilot pollution” has also been used, however this term is largely less descriptive as the real rea-
son for non-dominant PN is the amount, or volume, of CDMA “noise” in the area of interest. Only a portion
of this noise is due to actual pilot signals.
2. When in soft handoff, the CBSC chooses values for T_ADD, T_DROP, T_TDROP, and T_COMP from
amongst all the cells in soft handoff. Thus, the optomizer needs to be aware of exactly which cells support
the call prior to DAHO attempts. For more detail regarding selection of MAHO parameters when in SHO,
consult the Handoff and Power Control SFS.
Page 16 of 20
Figure 2: Target Reliability as a function of active set Ec/Io
Target Connection Reliability
Active Set Ec/Io

“Delta” dB
• Making soft handoff connections to cells that provide better diversity for the Extended Handoff Direction Mes-
sage: In some small number of circumstances, it may be that the cause of DAHO failure is inability the subscriber
unit, to correctly decode the Extended Handoff Direction Message. In general, these areas should have previously
been optimized for soft handoff, and this particular problem should appear at low rates. Change soft handoff
parms.
• Making soft handoff connections to cells that avoid significant subscriber unit slew activity in the event that the
reference pilot is changed because of the DAHO target selection. This could possibly result in some latency in the
subscriber unit sending preamble frames on the uplink at the target. The specification currently calls for a mini-
mum of two contiguous successful forward link frames at the target before the subscriber unit re-enables his trans-
mitter to send preamble (as an example, see section 2.6.6.2.8 of J-STD-008). Thus, we have the expectation that
timing slew should have ceased by then in those instances where the reference pilot changes1. Note however that
both IS-95A and J-STD-008 specify a slew rate range of 3/8 chip per second (slowest) to 1.25 chips per second
(fastest).
• Since AHHO takes place after completion of soft handoff drop or pilot shuffling operation, the PSMM might be
on the order of 0.5 to 1.0 seconds old (“stale”) by the time the information is used for target selection. This implies
that the handoff areas need to be stable2, non-multi-pilot areas if possible. In the worst of all scenarios, re-parent-
ing or cells under a CBSC (AHHO case) or moving of inter-carrier boundaries might be warranted.
• PCS optimization might be easier than cellular optimization in that the PCS engineer has more latitude in adjust-
ing antenna patterns3 to create coverage or pilot dominance.
1. It’s not really clear to me exactly what the subscriber unit does for timing correction as far as hard handoff
is concerned. At one time, CSS claimed they would “snap” to the new reference immediately and bypass the
slew rate numbers quoted in the specification. Since the specification is vague, it’s anybody’s guess what
Qualcomm, Samsung, Oki, Nokia, Japanese vendors, etc. will do.
2. An example of a “non-stable” pilot region might be an area where line-of-sight with a cellsite is impeded
by several buildings creating a “picket fence” pattern of pilot Ec/Io for that site. Disaster occurs when the
target selection is performed when the subscriber unit is illuminated by the target site and then execution
completes when the subscriber unit is shadowed from the target site.
3. Obviously within reason. There are limits to the amount of antenna adjustment in both vertical and hori-
zontal planes specifically for the purposes of optimization of ICBSC-SHO before problems appear in other
functionality.
Page 17 of 20
2.5 AHHO Enhancements

At this writing, an enhancement is being proposed for the R7 release of inter-CBSC that
is thought to improve the target selection portion of the AHHO. The enhancement basi-
cally treats the above mentioned AHHO triggers as “AHHO trigger enablers” and goes on
to further specify new trigger criteria. There are two new trigger criteria:
• AHHO trigger on any soft handoff operation that leaves the subscriber unit in a 1-way connection state (i.e. only 1
active set pilot).
• AHHO trigger on any soft handoff operation where the “imbalance” between active set pilot Ec/Io’s (as repre-
sented in the Pilot Strength Measurement Message) is above a certain threshold. For R7, the imbalance threshold
will be specified by using the T_COMP parameter1. Thus, in order to trigger the AHHO when in 2-way or 3-way
soft handoff, the differential (in dB) between the strongest active set pilot and any other active set pilot must be at
least T_COMP dB before the handoff is triggered/executed.
2.6 Estimating Post-Seam HHO Performance
The figure below demonstrates the correlation between origination and DAHO proce-
dures. The intent is to draw attention to the similarities between the two.
Some number of connections that attempt DAHO will be 1-way connections. As long as
these are not coverage limited scenarios, their success rate should be quite high.
As good as originations?
Figure 3: Origination and DAHO Procedure Comparisons
Mobile Origination Procedure DAHO Procedure
Idle mode cell selection Active Set pilot rank ordering
Mobile Origination Message Pilot Strength Measurement Message
Channel Assignment Message Extended Handoff Direction Message
1-Way Connection at target 1-Way Connection at target

Time
• Some probability that target sector/pilot will also be reference sector/pilot.

• Some probability that the AHHO will never occur as call may terminate normally. This is due to the fact that the
beacon handoff would always have occurred. Also, the mobile has some very small probability of stopping, or
even turning around, before AHHO.
1. Unfortunately, this presents the system designer/optimizer with the trade-off dilemma between using the
T_COMP parameter for optimization of soft handoff and AHHO. While a separate parameter that decouples
the two functions was desirable, it was not possible for the software organization to deliver this in time for
R7.
Page 18 of 20
See my slides!!!!
2.7 Joe’s Bullets
• Notes on Ec/Io statistics from Pilot Strength Measurement Message.
• HHO terms from Barry’s slides.
• New terms for microcells and umbrella cells.
Page 19 of 20
Page 20 of 20
2.8 Inter-CBSC and Inter Carrier Hard Handoff

2.8.1 Use of Pilot Beacon
2.8.2 Use of Frequency Hopping Pilot Beacon
2.8.3 Traffic Planning
2.8.4 DAHO
2.8.5 PrimeCo Chicago Proposal
As of 6/5/97, PrimeCo Chicago uses “bands” of alternating carriers as shown in Figure 4.
CBSC-1, F2
Lake
CBSC-2, F1
CBSC-4, F2
Figure 4: June 1997 PrimeCo Chicago Configuration
With the addition of another CBSC, the configuration will look like Figure 5.
These configurations provide isolation between like carriers. They also maximize the
number of Pilot Beacons between the CBSCs as the coverage areas are long and nar-
row. CBSC-2s coverage area is roughly 2 to 3 cells wide.
PrimeCo now needs multiple carriers because of call traffic. They also need to start con-
figuring their system for Release 7 which has InterCBSC SHO. The Release 7 version of
SHO requires three layers of BTSs to complete the SHO which presents a problem with
narrow coverage areas.
Page 21 of 26
CBSC-3, F1
Lake
CBSC-1, F2
CBSC-2, F1
CBSC-4, F2
Figure 5: Late 1997 PrimeCo Chicago Configuration
The Hong Kong Systems Engineers have tested? a configuration shown in Figure 6. This
strategy uses the Pilot Beacon frequency to carry traffic between the beacons.
The drawbacks with this configuration are:
1. The reduction in the number of carriers available to carry traffic at the seam
2. Two hard handoffs to cross a seam.
To minimize these drawbacks, the number of BTSs within the seams should be maxi-
mized while minimizing the number of BTSs on the seam. This requires a circular config-
uration.
Figure 7 shows a PrimeCo Chicago configuration that meets the objectives of minimized
seam cells and multiple carriers. CBSC-2’s coverage area would be made as large as
possible and still handle the load until Release 7 is available. A large coverage area may
allow the border with CBSC-1 to be at a low traffic area.
2.8.6 Hong Kong Configuration
Author: Lau Patrick Q13187 at icid
Date: 2/20/97 22:27
Page 22 of 26
F2 Beacon F2 Beacon
F2 PPS+TCH (PPS) F2 PPS+TCH (PPS) F2 PPS+TCH
F1 Beacon F1 Beacon
F1 PPS+TCH (PPS) F1 PPS+TCH (PPS)
CBSC #1 CBSC #2 CBSC #3
Figure 6: Wall-To-Wall Pilot Beacon
CBSC-3, F1
Lake
CBSC-2,
CBSC-1, F2 F1 & F2
CBSC-4, F1
Figure 7: Late 1997 PrimeCo Chicago Configuration
Priority: Normal
TO: Cheng TakLok Q12466M at #EMAIL
Page 23 of 26
TO: Ip Tim w10691 (Ip Tim W10691C)

TO: Tse Thomas CHK010 (Tse Thomas CHK010c)
TO: Dubberstein Steve CLXR04 at #EMAIL
TO: Chan Joe Q12656M at #EMAIL
TO: Chan Simon Q12202M at #EMAIL
TO: Kwok Dragon q12753 at #EMAIL
TO: Cheng Clement Q12472
TO: Wu William Q13681
TO: Ng WaiKeung Q12436
TO: Tong Simon W10557C at KT_PO
TO: Cheng Raymond Q12056c at KT_PO
TO: Chan KitWing Q12397 at KC_PO
TO: Wong Alex Q12457
CC: Ngan S.K. Q11669 at #EMAIL
Subject: Implementing Pilot Beacon with 2 Traffic carrier
Abstract
Based on Hutchison’s CDMA system requirement, there will be a need

for the HK CDMA system to support 120 - 150k with the current Rel 5
software. However, in order to have a good handover success rate across
the CBSC boundary, Pilot beacon seems to be the only solution at the
moment. Nonetheless, it seems like we cannot utilise this approach with 2
traffic carrier right now. However, with a different setup in the database, it
has been proven that we can idea have a 2 traffic carrier system while
using the beacon approach.
2.8.6.1 Database setting requirement
1. Configure Frequency F1 = 241 and F2 = 283 for one CBSC while the neighbor-
ing CBSC(s) will have F1 = 283 and F2 = 241. This change will require an outage
for the entire CBSC and its related sites.
2. All the cage mapping including paging, sync, and access channels must be
changed such that the first cage will always be transmitting the primary frequency.
This will require site outage should we elected to do this on a site by site basis.
2.8.6.2 Hardware/Calibration requirement
1. All cages need to be calibrated for a range of frequencies rather than one single
frequency. This will allow us to reconfigure different cages to transmit at different
frequencies more flexibly. With the calibration procedure right now, it seems we
can only guarantee to have clean CDMA carrier for one single frequncy per cage.
Page 24 of 26
2. Need to ensure both cages are functioning properly and traffic channel cards
are balanced between different frequencies in order to allow us to swap transmis-
sion frequency if required.
2.8.6.3 Systems engineering issues
1. All second cages must be verified and the degree of load sharing between dif-
ferent carriers must be monitored.
2. CBSC Boundary must be defined beforehand based on traffic pattern. This will
allow both the database and hardware to be re-located properly before implemen-
tation.
3. After cage remapping, call test must be performed to ensure that the right cage
is transmitting the right frequency.
2.8.6.4 Advantages
1. Reduction/Removal of Intra -CBSC inter carrier hard handoff : Currently, we
have to set our database such that those sites residing in the same CBSC must
do hard handoff into a beacon site. This will no doubt create some dropped calls.
By using the beacon carrier as a handoff only carrier, intra cbsc inter carrier hard
handoff is no longer required for those calls live in the same cbsc handing into the
beacon sites.
2. Blocking reduction : Blocking (origination and termination) has been recorded
for many of the beacon sites since its implementation, we suspect that this is due
to the Mobile origination algorithm. In having traffic channels for the beacon sites/
sectors, this problem may possibly go away.
3. Advantage of Pilot Beacon from the RF perspective can still be maintained as
most users will cross the boundary through an intercarrier approach.
4. Partial loading reduction for the non beacon carrier : Since handoff traffic can
still be allowed to access the beacon carrier, loading on the non beacon carrier
can be reduced. This can directly increase the capacity of our system especially
for those stationary or calls with low mobility.
2.8.6.5 Tradeoff
1. It seems only allowing users to access the Non beacon carrier will create some
imbalance between the carriers. Hardware installation and re-adjustment may be
necessary prior to implementation, creating some simple but extra hardware and
database reconfigurations due to boundary movement.
2. On crossing the boundary, users using the beacon carrier will experience one
intra carrier, inter CBSC Hard handoff first before he can be settled into a stronger
non beacon carrier. This will no doubt in increasing the chance drop call. However,
we need to evaluate the extent of this issue through some field trial later.
3. The beacon carrier will remain as soft handoff target mainly. Should Hutchison
decide to take the risk, we have the option to allow this beacon to be used as full
traffic carrier while minimising the impact of intra carrier hard handover.
Page 25 of 26
2.8.6.6 Conclusion
Since the implementation of this setup will require participation from all of the Hong Kong
operation departments. Each party should study the time frame involved and individual
needs e.g. practice on database preparation, call testing and verification of channel infor-
mation. Nonetheless, all effort involved for this change could well prove to be worthwhile
in meeting many of the Hutchison demand.
Regards
Patrick
Page 26 of 26
2.9 Inter-CBSC and Inter Carrier Soft Handoff

Page 27 of 28
Page 28 of 28
2.10 InterCBSC and Intra Carrier Hard Handoff

2.10.2 DAHO
Page 29 of 30
Page 30 of 30
2.11 InterCBSC and Intra Carrier Soft Handoff
Page 31 of 32
Page 32 of 32
2.12 IntraCBSC and Inter Carrier Hard Handoff

2.12.4 DAHO
Page 33 of 34
Page 34 of 34
2.13 IntraCBSC and Inter Carrier Soft Handoff

Page 35 of 36
Page 36 of 36
2.14 IntraCBSC and Intra Carrier Hard Handoff

2.14.2 DAHO
Page 37 of 38
Page 38 of 38
2.15 IntraCBSC and Intra Carrier Soft Handoff
Page 39 of 40
Page 40 of 40
3.0 CDMA Handoff Deployment & Optimization

3.1 Summary
With planning of hard handoff location and careful selection of hard handoff parameters,
the negative impacts of inter-CBSC hard handoffs can be minimized.
3.2 Statement of the Problem
The early versions of CBSC software do not support inter-CBSC soft handoff which
forces the use of hard handoffs between CBSC boundaries. Similarly, no CDMA vendors
currently support inter-vendor soft handoffs which forces hard handoffs between CDMA
vendor boundaries. Moving a call from one carrier to another carrier requires a hard
handoff.
Hard handoffs cause audio interruptions and increased dropped call rates in the hard
handoff regions. To minimize audio interruptions and dropped calls, the hard handoff
location and parameters must be carefully planned.
Motorola currently the following solutions to the hard handoff problem:
- Pilot Beacon (in development)
- Database Assisted HandOff (in development)
- XSect
- Intra-Carrier, Intra-Cell
3.3 Scope and Audience
This document provides general hard handoff guidelines to Motorola Systems Engineers.
3.4 Organization
The next section defines terms used in this document. After the definitins, the hard
handoff operation is described. Following that, each of Motorola’s hard handoff solutions
are described.
3.5 Definitions
Hard Handoffduring a call, the mobile station drops all if it’s current RF connections to the
infrastructure, possibly retunes it’s synthesizer to another carrier, and reestablishes at
least one RF connection with the infrastructure. The audio path is interrupted between the
dropping of the original paths and reestablishing the new paths. (Compare with Soft
Handoff.)
Inter-carrierbetween two different carriers. For example, handing off from F1 in Cell A to
F2 in Cell B.
Intra-carrierwithin the same carrier. For example, handing off from F1 in Cell A to F1 in
Cell B.
Soft Handoffadding and subtracting RF connections during a call between the mobile
station and the infrastructure without interrupting the audio.
3.6 Hard Handoff General Operation
3.6.1 General Operation
Intra-carrier hard handoff detection is accomplished when the CBSC receives a Pilot
Page 41 of 48
Strength Measurement Message that reveals a candidate pilot (which is an XSECT in the
database) appears T_COMP dB above all active set pilots. When this happens, a target
channel is set up in the target CBSC and then the mobile is instructed (via the Extended
Handoff Direction Message) to change the active set pilot(s). T_COMP is used as a
vehicle for hysteresis in the process with the amount of hysteresis proportionate to the
value T_COMP is assigned.
F1 Pilot Beacon
F1 Traffic Channels
BTS 1 BTS 2
CBSC 1 CBSC 2
3.7 Pilot Beacon

3.7.1 Intra-Carrier Hard Handoff Optimization
Given the philosophy above, the implications are that successful hard handoff is a strong
function of the deployment methodology. See below for more details. In addition, there
are several other factors which affect the success rate of hard handoff.
• T_COMP parameter: The Qualcomm mobile station demonstrates poor sensitivity (relative to simulated-
expected) in the seam region, especially at slow speeds. Thus, the amount of hysteresis used in combating the
“ping-pong” phenomenon must selected with care. In some instances, it may be that T_COMP cannot take on val-
ues any greater than 0.5 dB.
• Mobile station latency: Qualcomm has communicated to us that all versions of mobile station software are late in
reporting T_COMP events via the Pilot Strength Measurement Message. The quickest that a mobile will respond
with such an event is 250 milliseconds after the change has occurred in the RF domain. Lab measurements of
v1.34 and v1.60 phones indicate that the delay might be 2 to 3 times as long. Thus, situations where the time-rate-
of-change of the interfering pilot (i.e. target pilot) is large should be avoided.
• Infrastructure latency: Just as in soft handoff, there is a certain amount of processing and message passing on the
part of the CBSC that must occur upon each hard handoff execution. In addition to this, hard handoff also forces
the MSC and target CBSC to be involved as well. Future versions of CBSC and MSC software will attempt to par-
allelize the handoff process to the greatest extent possible, however inter-CBSC hard handoff execution times will
probably never be below 500 milliseconds.
• Extended Handoff Direction Message success rate: Given the discussion on mobile station sensitivity above, it is
apparent that successful delivery of the Extended Handoff Direction Message to the mobile station is difficult in
“high-noise” regions (i.e. the seam). There are a few things that can be tried to help this situation. The first is to
keep forward traffic channel gains as high as possible, and perhaps even at their maximum values, in the seam
Page 42 of 48
cells. This only works in low noise, low traffic conditions. The second is a drastic measure where the amount of
power devoted to the paging and synchronization channels is reduced, or even eliminated.
• Multiple handoff regions: Due to the nature of radio-wave propagation, it is possible that scenarios will present
themselves that allow for multiple handoff regions along a line, or road, separating two cellsites on either side of a
CBSC seam. Some handoffs may be completely unnecessary in the sense that a propagation condition that would
trigger a hard handoff comes and goes very quickly due to mobile (vehicle) movement. For fairly large cells, it
may be possible to use the neighbor search window to make the mobile station “blind” to the target pilot until the
mobile is well within the overlap region1. Once again, care must be taken in using this parameter as soft handoff
with cells/sectors on the same side of the CBSC seam is dependent on the value that the parameter takes.
• Number of L2 repeats: The current intra-carrier hard handoff algorithm specifies four “salvos” of Extended Hand-
off Direction Message attempts. The number of “salvos” will soon be increased to 7. Each “salvo” is 320 millisec-
onds long2 and contains a number of attempts equal to the L2 Num_Repeats count. Increasing the number of
repeats from 3 (default?) to 6 (maximum “sensible” value) may increase the message delivery rate in some slight
way.
3.8 Intra-Carrier Hard Handoff Deployment Tips
In general, successful intra-carrier hard handoff deployment is characterized by:
• Deployment restricted to “large” cells only.
• No quick NLOS3 to LOS4 transitions (target cell(s)). An example of this would be the Tai Po Harbor situation in
HK.
• No quick LOS to NLOS transitions (source cell(s)). An example of this would be the situation in Tate’s Cairn
Tunnel in HK where the entrance is blocked by a large vehicle and the source cell “goes away”.
• Cells far enough apart to make use of neighbor search windows to help in suppression of ping-ponging.
• Seams placed perpendicular to high traffic flow.
• No seams parallel to high traffic flow.
• No seams in high traffic areas.
• Seams in areas where traffic moves with relatively high speed such that the probability of ping-ponging due to
extended "straddling" of the handoff zone is reduced.
• Preferably one to one or many to one transitions. By this, we mean a single target cell. We all agree that the case
of being in soft handoff at the source cell(s) is advantageous in that we can use the site-to-site “macrodiversity”
side benefit of SHO to assist in increasing the probability that the Extended Handoff Direction Message will be
delivered successfully5. Unfortunately, going in the opposite direction, you’d have a situation where the transition
is one to many - definitely a situation we’d like to avoid. It might be that conditions would allow the usage of sec-
1. As a special note, DSD is considering basing hard handoff detection upon phase measurements made by
channel elements. While solutions of this type might fall into the “tractable” category, their implementation
is not in the near term.
2. See IS-95A section 6.6.4.1.3.2 and the value for timer T3m.
3. Non-line-of-sight.
4. Line-of-sight.
5. The “Fast Pilot Shuffling” feature will allow us to specify lower values for the T_ADD parameter in the
seam cells. This should increase the probability of 2-way and 3-way soft handoff in those border cells in
which the topology favors pilot coverage at T_ADD Ec/Io’s.
Page 43 of 48
torized sites at the CBSC borders to make the target cells unambiguous and to limit the amount of SHO at the bor-
der.
• Deployment scheme that makes use of natural or man-made terrain features to either limit the number of HHO
transitions or limit the amount of “other cell noise” coupling between the two CBSC service areas. This was the
tactic that the HK team was using (look at an elevation map of HK).
• No sector boundaries for a cell that cross high volume traffic paths in expected handoff locations.
• No seams in areas of weak RF coverage. The seam area should be “interference-limited” and not “noise-limited”.
• Seams should be optimized for soft handoff
3.9 Inter-Carrier Hard Handoff With Pilot Beacons (Multi-Carrier)
F1 Traffic Channels F1 Pilot Beacon F2 Traffic Channels
BTS 1 BTS 2
Path of mobile station Trigger Point
3.10 Inter-CBSC Hard Handoff With Pilot Beacons
Page 44 of 48
Figure #8.) Ideal Inter-CBSC Hard Handoff With 4 RF Carriers (R5)
F4 Beacon (PPS) F4 PPS+TCH
F3 PPS+TCH F3 Beacon (PPS)
CBSC Seam
CBSC #1 CBSC #2
The figure below shows the solution that the Hong Kong account team is proposing. Note
that carrier F1 is ubiquitous in the system due to the IS-95 “Primary” CDMA channel
requirement. In addition, 1/2 of all handoffs (assuming symmetrical mobility and carrier
distribution per CBSC) are intra-carrier in nature.
Figure #9.) Hong Kong R6 Inter-CBSC Solution
F1 PPS+TCH F1 PPS+TCH
CBSC Seam
CBSC #1 CBSC #2
Page 45 of 48
F2 Beacon
F2 PPS+TCH (PPS) F2 PPS+TCH
F1 Beacon
CBSC Seam
CBSC #1 CBSC #2
3.11 DAHO and Inter-CBSC Soft Handoff

3.11.1 Single Cell Intra-Carrier Hard Handoff
This memo serves to provide general guidelines regarding deployment of intra-carrier
(same RF carrier), inter-cell (between 2 different cells) hard handoff. Motorola currently
supports this type of handoff in an effort to preserve active calls that traverse (different)
CBSC service areas. The items in this memo are, to a great degree, common sense,
however some are gleaned from practical experience in our Hong Kong market. Note that
“seam” in this discussion designates an area where handoff needs to take place between
two different CBSCs.
In general, intra-carrier hard handoff performance is not as good as that of soft/softer
handoff. DSD is working on the problem, however no tractable solutions have presented
themselves. This should not be communicated to the customer.
3.11.2 Dual Cell Intra-Carrier Hard Handoff
Mony Hassid’s idea.
From: Menich Barry on Wed, May 7, 1997 9:30 AM
Subject: Mony Hassid Disclosure - May '97
To: Hulsebosch Tom
Cc: Bonta Jeff; Bruckert Gene; Campbell Neal; Kotzin Mike; Frank Miller; Jim Aldrich
GWI; Kowalewski Rolf; Menich Barry; Schuler Joe; Welk John
Tom,
This is just a little note to lobby you for a favorable treatment of Mony Hassid's patent dis-
closure for intra-carrier CDMA hard handoff up for review on the 15th. The business case
Page 46 of 48
here for Motorola is clear. This could be a stop-gap measure for some markets with inter-
CBSC handoff problems caused by lack of spectrum (Korea? AirTouch?). The business
downside is the need for some extra equipment, but as you know, we already have that
problem (to some degree) with pilot beacons.
The technical merits of the disclosure will obviously be judged by the committee mem-
bers at the time of the review. For what it's worth, my opinion is that this is a tractable
solution that requires no CBSC software modification and I support some kind of mini-
trial somewhere (LA?). Mony already has some preliminary spreadsheet results and will
follow-up with some static simulation ideas.
In addition, I'm available for technical consultation with any of the committee members
that want to discuss this.
-Barry
Page 47 of 48
Page 48 of 48
3.12 Nondominant PN
Page 49 of 50
Page 50 of 50
3.13 Idle mode handoff

TO: PCS PrimeCo, Ltd.
FROM: Motorola CDMA Development Group
RE: Idle-mode Handoff Problem at CBSC Seams and Possible “Work-around”
CC: Graham Haddock, Maria Martinez, John Thode
As you know, Motorola’s solution to inter-CBSC handoff was an inter-carrier solution

utilizing pilot beacon hardware. Because of the particular implementation, idle-mode
handoff problems have been observed that cause lapses in system acquisition by the
subscriber unit. This memo outlines a possible near term “work-around” for the problem.
The “work-around” proposed has already been tested by another Motorola CDMA
infrastructure customer and appears to provide relief from some idle-mode handoff
problems associated with the inter-CBSC deployment.
Solution Description
The nature of the solution involves a characteristic of the R5.1 CBSC software load that
requires that all carriers at a BTS/sector transmit identical parameter information on
synchronization and paging channels. In particular, the CDMA Channel List Message on
the paging channel and the Sync Channel Message body on the synchronization channel
can be used on pilot beacon carriers to force the subscriber unit to re-tune it’s frequency
synthesizer to the over-laid (non-beacon) RF carrier.
Consider the simple diagram below (Fig. 1) which depicts hypothetical control flow for
subscriber unit idle-mode activity. CBSC #1 (cell #1) and #2 (cell #2) are to the left and
right of the seam respectively. Traffic channel RF carriers F1 and F2 are also deployed to
the left and right of the seam respectively. A subscriber unit, in idle-mode, is traversing
the seam from left to right and is currently monitoring the paging channel for CBSC #1 on
F1.
The sequence of events is as follows:
• Subscriber unit monitors pilot Ec/Io and paging channel FER of current idle-mode active set1 cell (cell #1) on fre-
quency F1.
• Subscriber unit determines that coverage of current active set cell (cell #1) is no longer adequate and that beacon
cell pilot (also F1) is superior in terms of Ec/Io.
• Subscriber unit changes active set pilot to beacon cell (cell #2) and monitors synchronization channel.
• Subscriber unit recovers the CDMA_FREQ field from the synchronization Sync Channel Message body.
• The subscriber unit then begins monitoring the paging channel (on F1) at the beacon site (cell #2) and recovers the
CDMA_FREQ field from the CDMA Channel List Message body.
• Subscriber unit determines that CDMA_FREQ S ≠ CDMA_FREQ R such that a frequency retune is required.
1. J-STD-008 uses the identical terminology (e.g. “active set”, “neighbor set”, etc.) to describe both idle-
mode and tch-mode pilots.
Page 51 of 54
• Subscriber unit retunes from F1 (beacon) to F2 (TCH bearing pilot) at cell #2 and begins monitoring synchroniza-
tion channel, etc.
Figure #4 Subscriber Unit Traversing CBSC Seam
Start
Scan current Beacon

active paging cell coverage No
channel. established
(F1)?
Scan other PNs,

Yes possibly other
Current RF carriers.
No paging channel
coverage Acquire new cell
exhausted? synchronization channel
Yes
Acquire new cell
paging channel
Obtain
neighbor (F1 beacon)
cell sample
Current RF
No carrier.EQ. RF Yes
carrier in CDMA
Chan List Msg?
Subscriber Unit
retunes to RF
carrier in CDMA Subscriber Unit
Chan List Msg camps on beacon
and monitors signal (undesired
synch/paging outcome)
Equipage Procedural Detail

Given that the beacon sites are already provisioned, we will only have to add one
overhead MCC for each sector that is involved in the beacon hand-off. Below (in bold
font) is an example of commands that should be run in order to provision the new
overhead MCC's and alter the channel list:
add sch-bts#-sector#-carrier#-sch#
add pch-bts#-sector#-carrier#-pch#
Page 52 of 54
(Do not provision an ach as we do not want the mobile to access the beacons.)
add mcc-bts#-sector#-mcc# SRCHAN0= SRCHAN1= SRCHAN2=0-0-0-0 SRCHAN3=0-0-0-0
SRCHAN4=0-0-0-0 SRCHAN5=0-0-0-0 SRCHAN6=0-0-0-0 SRCHAN7=0-0-0-0 MODE=ONEOCG
MCCTYPE=MCC8
(By linking the srchan's to 0-0-0-0, the database is informed that we wish to add a card
without traffic channels, and will, in turn, inhibit all channel elements. This allows us to add
the card without using up valid timeslots.)
edit sch-bts#-sector#-carrier#-sch# link ce=bts#-mcc#-1
edit pch-bts#-sector#-carrier#-pch# link ce=bts#-mcc#-0
(This will link the paging and sync channels to MCC.)
edit carrier-bts#-sector#-carrier# channellist chan1=1 or 2 (depending on side)
If the site has traffic on F1 and the beacon is F2, then the above edit will link the channellist
to F1. Conversely, if the site has traffic on F2 and the beacon on F1, then the edit will link
the channellist to F2.
activate mcc
cutover mcc
enable mcc
There is a possibility that the MCC may not come INS. If that happens, it is most likely due
to the gli_dev_map not getting updated real-time. In order to "work-around" this problem
if it is seen, simply disable/enable the cage controlling gli (in this case, gli-3.)
The above changes will link the beacon's channellist to the frequency of the traffic cage
and allow the mobile to re-tune to the frequency specified in the message. In addition,
SyncCdmaFreq parameter in the Sync Channel Message will get set to the same
frequency as is specified in the Channellist Message. So, a mobile powering-up in the
zone could re-tune without having to acquire paging.
Pilot Beacon Output Power

Since the addition paging and synchronization channels to the beacon carriers will result
in an additional 2.67 dB of extra output power, it might be necessary in some situations to
reassess beacon output power and adjust (upward) accordingly. The expectation is that
this should be a rare occurrence given that beacon output powers in the PrimeCo markets
were adjusted by “feel” rather than by some analytical technique. Nevertheless, field
engineers should be alert for undesirable changes in handoff locations. These changes,
should they occur, will most probably manifest themselves between beacon sites.
Expectation for Empirical Results

The desired result from deployment of this technique is quicker response time by the
subscriber unit in acquiring the synch/paging channels of the TCH-bearing RF carrier at
the target cell during a seam transition. With the current deployment, the Qualcomm
subscriber unit will attempt to scan all PN-space on the current carrier (while at the beacon
site) before aborting and retuning to another carrier for system acquisition attempts. This
has been monitored by both customer and Motorola personnel and is estimated to take
Page 53 of 54
no less than several seconds. During this period, the subscriber is inhibited from placing
call attempts or receiving pages.
Motorola’s recommendation is that 2 seam transition areas be identified for testing
purposes. One area would serve as a control for purposes of data comparison. The other
area1 would be equipped with the relevant hardware and provisioned with synch/paging
channels as discussed previously. The goal of any testing is to observe decreased system
unavailability of the Pilot/Page/Synch beacon sites relative to the Pilot-only sites.
CFC5 Problem
Motorola field engineers have observed that higher occurrence of CFC5 problems
appears to be associated with CBSC seams. Motorola is still investigating this problem,
however one hypothesis offered attempts to explain the problem via the mechanism of the
“ping-pong” phenomenon associated with idle-mode scanning. The “ping-pong”
phenomenon may be exacerbated by the lack of paging and synchronization channels in
the beacon sites.
Because of the reduced beacon footprint relative to the over-laid TCH cell at the beacon
sites, mitigation, or elimination, or idle-mode “ping-pongs” should place the subscriber unit
well within the reverse link range of the over-laid TCH cell and hopefully reduce the CFC5
counts in these regions. There is, however, no guarantee that this will occur and Motorola
will continue to investigate.
1. If possible, the experimental area should be chosen from those seam cells that exhibit high CFC5 counts.
See next section “CFC Problem”.
Page 54 of 54
3.14 PN Planning
3.14.1 micro-cell
3.14.2 in-building
Sam Fernandez e-mail
Page 55 of 56
Page 56 of 56
DOCUMENT CLASSIFICATION:
PN Offset Planning
User Presentation
Samuel D. Fernandez
Abstract
This document provides an overview of factors impacting PN Offset Planning in a CDMA
System. The importance of the PILOT_INC parameter is explained.
Date: June 17, 1996 Version#: 1.0 Supersedes Version#:
Preliminary Reviewed Inspected Reviewed By:
Location: HP -> /usr/test/adv_sys/cdma/documentation/stolen/fernandez/pn_planning
MOTOROLA CONFIDENTIAL PROPRIETARY

This document and the information contained in it is CONFIDENTIAL INFORMATION of Motorola, and shall not be used, or published, or disclosed, or
disseminated outside of Motorola in whole or in 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 INTERNAL USE ONLY

This document and the information contained in it is for INTERNAL USE ONLY for Motorola, and shall not be used, or published, or disclosed, or dissem-
inated outside of Motorola in whole or in 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 CUSTOMER CONFIDENTIAL

Information contained herein is proprietary to Motorola and DSC, for whose benefit confidentiality shall be maintained.
GENERAL CELLULAR INFORMATION

Information contained herein is intended for use by Motorola and customers of Motorola (current or future).
Revision History
1.0 06/17/96 Samuel D. Fernandez
• First Release - contains the presentation as it was made to BANM on June 4, 1996. This was after
presentations to both PrimeCo and GTE. It is anticipated that further changes will be made
especially in consideration of planning on a border.
Consequences of poor offset plannin
■ Interference may occur for an active set pilot. This interference

in the ‘active’ area and involve the active search window (SRCH
■ A neighbor set pilot may falsely appear strong enough for the M
the pilot to the candidate set and recommend to the BS to p
handoff ‘add’ via the PSMM. This ‘falsing’ would occur in the ‘n
and involve the neighbor search window (SRCH_WIN_N).
■ A signal may travel far enough so as to be incorrectly identifie
when it translates the MS reported phase into a PILOT_PN.
Page 59 of 80
Co and Adjacent Offsets

The possible sources of interference and falsing include the ‘co’ and adjacent offset
In analog, co-channel interference was managed via the antenna configuration and the re-use patte
adjacent-channel interference was managed through the application of a simple frequency pla
With the CDMA channel, all sites reuse the same frequency. Interference isolation is obtained via sh
(inter-sector) and walsh codes (intra-sector).
2 4 6 8 1
The ‘valid’ set of offsets is limited to multiples of PILOT_INC (in this example, 2). Offset 4 can interfere w
4. If the PILOT_INC is chosen carefully, there should be little concern with 2 interfering w
Page 60 of 80
Impact of PILOT_INC
The setting of PILOT_INC is fundamental to the PN Offset Plan design.
What is the impact of changing PILOT_INC?
■ Remaining Set Pilot scanning rate
■ Mis-identification by the Base Station
■ Protects against falsing/interference associated with Adjacent

Co-offsets)
Page 61 of 80
Scan Rate for Remaining Set Pilots
• Remaining Set pilots are assigned a lower priority in the

order. All actives/candidates are scanned between neig
remaining. And all neighbors are scanned between rem
pilots. A remaining set pilot is scanned N times slower
neighbor (where N is the number of remaining pilots). [
facturer specific]
• IS-98 specifies no performance criteria for remaining se
• A remaining set pilot that appears strong enough (and l
enough) to recommend promotion to active needs analy
haps it should be a neighbor (or have its coverage adju
• Motorola does not currently honor any requests to ente
handoff with a remaining set pilot.
Page 62 of 80
Mis-identification by the Base Station
PILOT_INC = 3 = spacing between ‘v
0 3 6 9 12
pilot phase reported by MS in PSMM
0 3 6 9 12
SRCH_WIN_N
• The BS uses PILOT_INC to translate the pilot phase into a pilot pn offset. If a signal tra
greater than PILOT_INC/2 than it may be misidentified by the BS.
• Note the relationship between PILOT_INC and SRCH_WIN_N. It is a rule that SRCH
always smaller PILOT_INC.
• You may want to ask yourself whether it is expected for a MS to interact with a BS at a d
than PILOT_INC/2 away.
• For PILOT_INC = 3, PILOT_INC/2 = 3 x 64 chips / 2 = 96 chips = 23.4 km = 7.8 R (w/R
Page 63 of 80
Protection Against Adjacent Offsets
PILOT_INC
3 6
SRCH_WIN_N = +/- S
• An offset must traverse a minimum distance PILOT_INC

able to fall into the window of the adjacent offset.
• For PILOT_INC = 3 and SRCH_WIN_N = +/- 30 chips, thi
corresponds to 3 x 64 - 30 = 162 chips = 39.5 km = 24.5
= 13.2 R (w/R = 3 km).
Page 64 of 80
Table: PILOT_INC vs Distance
Distance Distance
Pilot_Inc
(km) (miles)
1 15.6 9.7
2 31.2 19.4
3 46.8 29.1
4 62.5 38.8
5 78.1 48.5
6 93.7 58.2
7 109.3 67.9
8 124.9 77.6
9 140.5 87.3
10 156.2 97.0
11 171.8 106.7
12 187.4 116.5
13 203.0 126.2
14 218.6 135.9
15 234.2 145.6
Page 65 of 80
Selecting PILOT_INC
PILOT_INC
LO HI
CO_OFFSET Good Protection ???
ADJACENT OFFSET ??? Good Protection
COMMENTS More Offsets Fewer Offsets
Larger Reuse Pattern Smaller Reuse Patte
Larger D/R Smaller D/R
marginal
co-offset?
1 2 3 4 5 6
only for small
marginal
adjacent
offset ?
Page 66 of 80
Approach with small PILOT_INC/large cl

■ Determine a PILOT_INC which delivers a sufficient interferen
against adjacent interference.
a ⁄ ( law × 10 )
m ≥ ( R + s ) × ( 10 – 1)
For a = 24 dB C/I and law = 3.0, m >= 5.31 x (R+s).
■ A smaller PILOT_INC delivers larger number of valid offsets

reuse pattern. As the D/R increases, the likelihood of co-offse
diminishes.
■ At this point, it may be possible to adopt any reuse pattern an

high degree of confidence that we are protected against both
adjacent offset interference.
■ Is there anything we can do to optimize the reuse pattern? A

of the reuse distance, D, and PILOT_INC may tell us.
Page 67 of 80
PILOT_INC determinations
Table 3-1: Pilot Sequence Offset Index Assignment
R R PILOT number
a (C/I in
(radius in (radius in s (chips) law m (chips) _INC of valid
dB)
km) chips) (offsets) offsets
7 29 10 24 3 207 4 128
5 21 10 24 3 165 3 170
3 12 10 24 3 117 2 256
2.5 10 10 24 3 106 2 256
2 8 10 24 3 96 2 256
Page 68 of 80
PN Offset Plan: PILOT_INC = 3
5 18 31 44 9
6 19 32 45 10 23
7 20 33 46 11 24 25
8 21 34 47 12 13 26 39
22 35 48 1 14 27 40
36 37 2 15 28 41 •48 cell cluster

38 3 16 29 42 •Alpha Sector Offset = 9N -
4 17 30 43 Beta Sector Offset =9N
Gamma Sector Offset =9N
•There are 26 remaining o
can be organized into 8 separate sites.
Page 69 of 80
PN Offset Plan: PILOT_INC = 2
45 53
38 46 54 62 70 •73 cell cluster

39 47 55 63 71 6 14
31 •Alpha Sector Offset = 6N - 4
32 40 48 56 64 72 7 15 23 Beta Sector Offset =6N
41 49 57 65 73 8 16 24 Gamma Sector Offset =6N
42 50 58 66 1 9 17 25 33
•There are 37 remaining of
51 59 67 2 10 18 26 34 can be organized into
52 60 68 3 11 19 27 35 43 sites.
61 69 4 12 20 28 36 44
5 13 21 29 37
22 30
Page 70 of 80
A different look at PILOT_INC = 3
5 15 25 35 5
16 26 36 9 53
6
7 17 27 37 10 20 54 4
8 18 28 1 11 21 31 47
19 29 2 12 22 32 4
•3-Ring, 37 cell cluster
30 3 13 23 33
4 14 24 34
•Alpha Sector Offset = 9N - 6
Beta Sector Offset =9N
Gamma Sector Offset =9N - 3
• There are 57 remaining offsets which can be organized
rate 2-ring cluster of 19 sites.
Page 71 of 80
Largest
i j N D/R PILOT_INC
1 0 1 1.73 15
1 1 3 3.00 15
Table: i & j coordinates for N-sized Clus

2 0 4 3.46 15 <--- 1 ring
2 1 7 4.58 15 <---
3 0 9 5.20 15
2 2 12 6.00 13 <---
3 1 13 6.24 12
4 0 16 6.93 10
3 2 19 7.55 8 <--- 2 ring

4 1 21 7.94 7
5 0 25 8.66 6
3 3 27 9.00 6
4 2 28 9.17 5
5 1 31 9.64 5
6 0 36 10.39 4
4 3 37 10.54 4 <--- 3 ring
5 2 39 10.82 4
6 1 43 11.36 3
4 4 48 12.00 3
5 3 49 12.12 3
7 0 49 12.12 3
6 2 52 12.49 3
7 1 57 13.08 2
5 4 61 13.53 2 <--- 4 ring
6 3 63 13.75 2
8 0 64 13.86 2
Page 72 of 80
7 2 67 14.18 2
8 1 73 14.80 2
5 5 75 15.00 2
6 4 76 15.10 2
7 3 79 15.39 2
8 2 84 15.87 2
6 5 91 16.52 1 <--- 5 ring
7 4 93 16.70 1
8 3 97 17.06 1
Comparison of different plans
INC = 6 INC = 3 INC = 3 INC = 2 INC = 1

Co
19 cells 48 cells 37 cells 73 cells 127 cells
D/R 7.55 12 10.54 14.8 19.5 co-offset
C/I (3km) 37.8 29.5 29.5 24.9 17.6 adjacent offset
C/I (6 km) 32.5 24.5 24.5 20.2 13.6 adjacent offset
PILOT_INC - s (chips) 354 162 162 98 34 adjacent offset
PILOT_INC - s (km) 86.4 39.5 39.5 23.9 8.3 adjacent offset
PILOT_INC - s (R) 28.8 13 13 8 2.8 adjacent offset
PILOT_INC (chips) 384 192 192 128 64 compare w/SR
PILOT_INC/2 (chips) 192 96 96 64 32 neighbor proxi
PILOT_INC/2 (km) 46.8 23.4 23.4 15.6 7.8 neighbor proxi
PILOT_INC/2 (R) 15.6 7.8 7.8 5.2 2.6 neighbor proxi
%Overhead Offsets 46 17 51 16 34 insurance
• Radius = 3km
• C/I = 30 × log ( m ⁄ ( R + s ) + 1 )
Page 73 of 80
PILOT_INC determinations (w/16 dB C
Table 3-1: Pilot Sequence Offset Index Assignment
R R PILOT number
a (C/I in
(radius in (radius in s (chips) law m (chips) _INC of valid
dB)
km) chips) (offsets) offsets
7 29 10 16 3 94 2 256
5 21 10 16 3 74 2 256
3 12 10 16 3 54 1 512
2.5 10 10 16 3 49 1 512
2 8 10 16 3 44 1 512
Page 74 of 80
Database Parameters
■ PILOT_INC
Set in the HO_pilot_inc field of the XC Subsystem
SET_HO_PARAMS. The range is 1 to 15 (defaults to 1).
■ PILOT_INC
Set in the pilotinc field of the DBCM CBSC Command,
EDIT CBSC CBSCGEN. The range is 1 to 15 (defaults to 1).
■ PILOT_PN
Set for each sector in the pilotpn field of the DBCM Sector Com
SECTOR SECGEN. The range is 0 to 511.
■ SRCH_WIN_A, SRCH_WIN_N
Set in the srchwina and srchwinn fields of the DBCM Sector C
EDIT SECTOR MAHO. The range is 0 to 15 (defaults to 6).
Page 75 of 80
Definitions
■ System Time
All base station digital transmissions are referenced to a com
system-wide time scale that uses the Global Positioning S
time scale, which is traceable to and synchronous with Univ
nated Time (UTC).
■ Time Reference
The mobile station shall establish a time reference which is u
system time. This time reference will be the earliest arriving m
ponent being used for demodulation. This reflects the assum
mobile station’s fix on system time is always skewed by dela
with the shortest active link.
■ PILOT_PN
The Pilot PN sequence offset (index), in units of 64 PN chip
from 0 to 511. Every transmit sector will have an offset assign
Page 76 of 80
Definitions
■ Active Set
The pilots associated with the Forward Traffic Channels assigned to
tion. It is the base station that assigns all active set pilots to mobile st
■ Candidate Set
The pilots that are not currently in the Active Set but have been r
mobile station with sufficient strength to indicate that the associated
Channels could be successfully demodulated. As a property of the M
HandOff (MAHO), the mobile station promotes a Neighbor Set or
pilot to the Candidate Set when certain pilot strength criteria are me
ommends the pilot to the base station for inclusion in the Active Set.
■ Neighbor Set
The pilots that are not currently in the Active Set or the Candidate Se
candidates for handoff. Neighbor Set pilots are identified by the b
Neighbor List and Neighbor List Update messages.
■ Remaining Set
The set of all possible pilots in the current system on the current CD
assignment, excluding pilots in the other sets. These pilots must be in
of PILOT_INC (defined below).
Page 77 of 80
Definitions
■ SRCH_WIN_N, SRCH_WIN_R
These parameters represent the search window sizes ass
Neighbor Set and Remaining Set pilots. The mobile station
search window for each pilot around the pilot’s PN sequence
timing defined by the mobile station’s time reference.
■ SRCH_WIN_A
This parameter represents the search window size associa
Active Set and Candidate Set pilots. The mobile station cente
window for each pilot around the earliest arriving usable mult
nent of the pilot. Note that in contrast to the neighbor or r
search windows, the active/candidate search windows are loc
signals. That is to say that the center position of the sear
updated every scan to track the new location of the earliest a
path component.
Page 78 of 80
Definitions
■ PILOT_ARRIVAL
The pilot arrival time is the time of occurrence of the earliest a
multipath component of a pilot relative to the mobile station
ence.
■ PILOT_PN_PHASE
The mobile station reports pilot strength and phase meas
each active and candidate pilot in the Pilot Strength Measu
sage when recommending a change in the handoff status
assisted handoff). The mobile station computes t
PILOT_PN_PHASE as a function of the PILOT_ARRIV
PILOT_PN. The pilot arrival component represents the time
pilot relative to the time reference or, in other words, how ske
is from the mobile’s concept of system time. Note also that the
not identify pilots by their offset index directly, but by their pha
ment. If the pilot arrival was larger than 32 chips (1/2 of a pilo
miles), then this could undermine the ability of the base statio
translate pilot phase into pilot offset index.
Page 79 of 80
Definitions
■ PILOT_INC
The pilot PN sequence offset index increment is the interval be
in increments of 64 chips. Its valid range is from 1 to 15. The m
uses this parameter in only one manner, to determine which
from among the Remaining set. Only valid pilots (i.e. those p
multiples of PILOT_INC) will be scanned. For the mo
PILOT_INC impacts only the scanning rate applied to Rema
accomplishes this by reducing the number of Remaining pilots
be scanned. For the base station, its affect is different. In the
it is used in properly translating pilot phase back into pilot offs
consequence is that the operator may artificially increase th
between valid time offsets. By selecting a PILOT_INC of 2, fo
operator chooses to limit the number of valid offsets to 256 (
508, 510) instead of 512. The increased separation means
arrival must be larger before adjacent offset ambiguity is poss
sequently the likelihood of a strong interferer is reduced.
Page 80 of 80
3.15 Neighbor Window Search Planning

From Dan DeClerck’s CDG IAT/TR45.4 WG III trip report
BCTel presented the idea that Search window size should be a function of each pilot that
needed to be scanned, and showed how there would be an improvement mobile pilot
scanning speed and thus handoff execution time. They showed examples of where the
setting of the search windows in their system was more than 200 chips.
Page 81 of 82
Page 82 of 82
3.16 Microcell
• Will Bayer’s comments on reverse link timing imbalance between microcells and macrocells (possible implemen-
tation in motion sim?).
3.16.1 When to Deploy

3.16.2 Intercarrier issues
Page 83 of 84
Page 84 of 84
3.17 InterVender Hard Handoff

3.17.1 IS-634
Page 85 of 86
Page 86 of 86
3.18 InterVender Soft Handoff

3.18.1 IS-634
Page 87 of 88
Page 88 of 88
3.19 Customer Specific Issues

3.19.1 KTF
plots
Mony’s HHO idea
3.19.2 Hong Kong MTR
3.19.3 Singapore
in-building sites with handoff to macrocell
leaky coax coverage
Page 89 of 90
Page 90 of 90
3.20 HHO as soon as One-Way

After an inter-CBSC SHO, perform the HHO as soon as the call goes into one-way on the
target CBSC. Otherwise, wait for DAHO.
Page 91 of 92
Page 92 of 92
3.21 CDMA Soft Handoff Optimization

3.21.1 Introduction
The soft handoff optimization is a continuous process that is required in maintaining an

acceptable1 system performance level in terms of call quality. This section of the docu-
ment focuses on the detailed approaches in recognizing the root cause of failed soft
handoffs as well as approaches in correcting the various types of common failures.
These common failures are typically encountered during the CDMA initial system opti-
mization phase or during system expansion (installing additional BTS).
Resolving the failed soft handoffs that result in an “RF Loss”2 is usually the main em-
phasis in the optimization process. Provided that the software of the handoff algorithm
is executed according to design3, there are basically two general categories that soft
1. 1% to 2% system RF Loss rate.

2. An event where either the Reverse or Forward Traffic Channel is lost.
handoff failures fall into: 1) RF coverage hole, and 2) non-optimal parameter settings.
This document will discuss approaches in recognizing the two types of failures by ana-
lyzing mobile station logs and base station logs.
This document also contains brief overviews of soft handoff related parameters and sys-
tem algorithms. This will provide a general understanding of the mechanics of soft
handoffs.
3.21.2 General Mechanics of Soft Handoff
3.21.2.1 Overview of Soft Handoff Parameters
Recommended settings for adjustable system parameters:

■ TADD = 24 ~ 28 (-12dB ~ -14dB)
■ TDROP = 26 ~ 32 (-13dB ~ -16dB)
■ TTDROP = 1 ~ 4 (1 sec ~ 6 sec)
■ TCOMP = 0 ~ 4 (0 ~ 4dB)
■ SrchWinA = 6 (28 PN chips)
■ SrchWinN = 8 (60 PN chips)
■ SrchWinR = 9 (80 PN chips)
3. There are instances where extra effort is required when encountering a possible infrastructure software bug.
An MR (Modification Request) is generated once the issue has been identified.
CDMA Soft Handoff Optimization

There are, however, exceptions where the parameters may be set outside the recom-
mended range. Examples of situations where parameters are set in an atypical fash-
ion are described below:
✥Tadd and Tdrop parameters could be adjusted relatively high in regions where pi-
lots become difficult to manage (no dominant pilot)
✥The mobile station Window Search Sizes could be increased when the site radius
is extremely large (8 to 15 miles)
✥Tcomp parameter could be set large to suppress Fast Pilot Shuffling1
✥TTdrop parameter could be set larger to “slow down” soft handoff activity
3.21.2.2 Soft Handoff Detection
All soft handoff decisions are based on the Ec/Io information and the “keep-flag”
status from the PSMM (Pilot Strength Measurement Message) sent by the mobile
station. The PSMMs are triggered when a Tadd, Tcomp, or a Tdrop event occurs.
The soft handoff parameters are set on a sector basis, and are sent to the mobile sta-
tion by the System Parameter Message on the Paging Channel or by the Extended
Handoff Direction Message on the Forward Traffic Channel.
The System Parameter Message is sent at least once every 1.28 seconds over the
Paging Channel. The Extended Handoff Direction Message is sent each time a
handoff criteria is met. If there are more than one sector in the Extended Handoff
Direction Message (i.e. calls that are instructed to transition into a soft handoff
state), the MM will use the following criteria in selecting the soft handoff parame-
ters in those instances when the values are different for each of the involved sectors
(refer to illustration 11.2.0.2-a):
1) The value of TDrop shall be the largest value from each of the sectors
involved5
2) The value of TAdd TComp and TTDrop shall be the smallest value from each
of the sectors2
3) The value of SrchWinA, SrchWinR, SrchWinN shall be the largest value from
each of the sectors involved
1. Fast Pilot Shuffle is a soft handoff algorithm triggered at the MM when it detects three pilots in the active
set and a candidate pilot that measures a stronger Ec/Io than at least one of the pilot in the active. The mech-
anism of this algorithm will be discussed later in the document.
2. Referring to Tdrop and Tadd: “These parameters, which actually represent fractions, are transformed into
their current values via a log function. Therefore, the largest actual value is represented by the smallest value
of the parameter,and vice-versa.”, HOPC SFS,ver6.0, HO_Exec_Preface, page 50.
Page Page 94 of 106

Sector-a Sector-b Extended Handoff Direction Message

Tadd - 14dB - 12dB - 14dB
Tdrop - 15dB - 16dB - 15dB
Tcomp 3 dB 1 dB 1 dB
TTdrop 4 sec 2 sec 2 sec
SrchWinA 7 chips 6 chips 7 chips
Assume that the Extended Handoff Direction Message includes 2 sectors, sector a
and sector b. The MM data base parameters are listed above according to each of
the sectors. The values listed under “Extended Handoff Direction Message” are the
values selected by the MM. This list will be included in the Extended HDM Message Figure 11.2.0.2-a
which is sent down to the mobile station on the Forward Traffic Channel.
For CBSC software release R7.x and earlier, a candidate pilot is added to the active
set via soft handoff execution when the Ec/Io reading from the PSMM is above the
Tadd threshold1 and when there are less than 3 active pilots in the active set2. Ideal-
ly, the Tadd parameter should be above the Tdrop parameter for any given sector.
The idea is to allow a hysteresis between the two thresholds so that once a pilot is
added into the active set, it does not immediately fall below the Tdrop threshold.
The hysteresis will prevent the mobile station from attempting unnecessary soft
handoffs. This not only reduces the CPU utilization time at the MM and the XCDR,
but will decrease the Traffic Channel message rate. If Traffic Channel messages are
reduced, it is less likely that a Dim-and-Burst frame will be sent over the air (main-
tain good speech quality).
In adding a pilot to the active set, the focus is to prevent the mobile station from
dropping a call caused by not having the correct set of pilots in the active set. Cur-
rently, the infrastructure is limited to having 3 pilots in the active set, therefore,
there will be instances where a fourth pilot is strong enough to be in the active set.
Extra effort is required in adjusting the soft handoff parameters such that the pilots
are “shuffled” in and out of the active set smoothly. This “shuffling” process is as-
sisted by an algorithm called the Fast Pilot Shuffle that is triggered at the MM when
it detects the scenario mentioned above.
The concept of Fast Pilot Shuffle is to detect a pilot in the candidate set that is mea-
sured to be relatively stronger (via the measurement of pilot Ec/Io in the PSMM)
than any of the three pilots in the active set, regardless of the “keep-flag” status con-
tained in the PSMM. The weakest pilot in the active set is dropped, and after the
1. The infrastructure has the capability of executing soft handoffs in either the Tcomp mode or the Tadd
mode. The recommended mode is Tadd.
2. There will be significant soft handoff algorithm changes in R8.1 (N-way complex handoff). This feature
will support up to 6 pilots in the active set.
Page Page 95 of 106

success of the soft handoff drop, a soft handoff is triggered to add the candidate pilot
that is the strongest as recorded in the subsequent PSMM.
The following is the Fast Pilot Shuffle detection criteria1:
1) The candidate Ec/Io is a TComp event.

2) The candidate’s Ec/Io is greater than at least two of the active pilot’s Ec/Io
3) The candidate Ec/Io is equal to or greater than the TAdd threshold, and the candi-
date’s Ec/Io is greater than at least two of the active pilot’s Ec/Io
Note: The third Fast Pilot Shuffle detection criterion will be applied in future CBSC
software releases starting from software release R8.x.
In many cases, driving the same route several times while adjusting the parameters is
necessary in order to perfect difficult locations. Caution must be taken when adjust-
ing the RF power or the soft handoff parameters, as it may improve the RF condi-
tion for the intended location, but possibly degrade other locations.
A pilot is dropped from the active set when an Ec/Io from the PSMM is below the Tdrop
threshold for a TTdrop period. The weight or the significance of information contained
in the PSMM is controlled by how the parameters are set.
For example, the weight of a PSMM triggered by a Tdrop of -15db and a TTdrop of 4
sec is more significant than a PSMM triggered by a Tdrop of -15db and a TTdrop of 1
sec. Naturally, if a pilot that is continuously below the Tdrop threshold for relatively a
long period (period controlled by TTdrop), the infrastructure may drop the pilot with a
relatively high level of confidence. In other words, the infrastructure will, more than
likely, never encounter a case where there is a sudden improvement of the pilot Ec/Io
measurement, via the PSMM, after deciding to drop from the active set. If the TTdrop
timer is relatively short, there is a high risk that the pilot Ec/Io will change (for the bet-
ter) by the time the infrastructure makes it’s decision to drop. This is commonly seen
when the system makes the decision to drop a reasonably strong pilot that may have
briefly been in a fade or may have been receiving a weak multi-path ray at the time the
PSMM was reported. It would appear that, from the PSMM, the pilot was very weak,
therefore, the system will drop the pilot not knowing that it would recover from the fade
or the weak multi-path.
The mobile station window search size parameters should be set such that the mobile
station searcher is capable of searching all multi-paths in the active set, and all neighbor
pilots without degrading the accuracy of locating a valid ray. The speed of the search
mechanism is dependent upon the search window size. The wider the search window,
the longer the mobile station takes to complete it’s search across the window. The exces-
sive window search size may cause “under-sampling” of the signal such that an inaccu-
rate measurement is made; therefore, optimization may be required to determine the
most effective window search size value.
1. HOPC SFS, Handoff Detection, Ver 6.0
Page Page 96 of 106

The following is an illustration (Figure 11.2.0.2-b) that may provide a visual under-
standing of how the window search parameter is associated with the distance rela-
tive to the surrounding BTS.
Earliest arriving ray s)

chip
(reference Pilot_A) 3.2
ro x. 1
app
iles (
2m
BTS # 1 PN_A BTS #2 PN_B

4 miles away from mobile station 6 miles away from mobile station
4 mile radius In order for the mobile station searcher
to be able to detect the ray from
BTS#2, the Neighbor window
search size must be at least
26.4 chips (+/- 13.2chips) since
the ray from BTS#2 has a delay
of 13.2 chips relative to the
earliest arriving ray (BTS#1).
Figure 11.2.0.2-b
IS-95A (in reference to the Neighbor search window size): “The mobile station
should center the search window for each pilot in the Neighbor Set around the pi-
lot’s PN sequence offset using timing defined by the mobile station’s time refer-
ence”. The mobile station’s time reference is typically the earliest arriving
component being used for demodulation. The above figure illustrates that with
PN_A, from BTS#1, as the earliest arriving ray, the Neighbor search window size
must be at least set to 26.4 chips (+/- 13.2 chips) in order for the mobile station to
detect PN_B, BTS#2, which is 6 miles away from the mobile station. The neighbor
search mechanism applies for when the mobile station is in the Idle State and the
Traffic State.
3.21.2.3 Neighbor List Configuration
Maintaining the correct set of neighbor list for each sector is crucial in the perfor-
mance of soft handoff. As stated in the HOPC SFS1, “The mobile station uses the
neighbor set as a way of reducing the amount of resources applied to searching for
handoff candidates. For this reason it is important that the mobile station’s neighbor
set is appropriate for its location within the system.”
With the current architecture of the infrastructure system, a soft handoff attempt
will be rejected if the pilot to be added is not listed in the neighbor list. Unfortu-
nately, an effective way in determining an accurate set of neighbor list during the
initial stages of system deployment is to drive test the handoff regions and analyze
which neighbor pilots are most likely to be used as active pilots. For each sector, all
neighbors must be sorted and listed in the system database in the order of decreas-
1. HOPC SFS. “HO_Exec_Preface”, ver 6.0, page 49
Page Page 97 of 106

ing priority . Developing such a list is a time consuming task. There have been
many suggestions on different approaches in developing an optimal neighbor list.1
One example is to have the general user generate data so that the CDL logs could be
manipulated.2 In each CDL record, there is a field that lists all the sectors from the
last Handoff Recognize Message received by the MM (LAST_MAHO_ACT)3.
With enough samples, the frequency of a given pilot, a reference pilot “A”, pairing
up with the rest of the pilots found in each of the CDL logs can be broken down.
This data can then be used to find the weight of each neighbor pilot relative to pilot
“A”, thus, developing a prioritized neighbor list for pilot “A”. This approach, how-
ever, is only valid for a system that is running at a significant load since large sam-
ples of CDL logs are required in calculating an accurate probability that a given
pilot “A” would be paired with another pilot “x”. Please refer to the illustration be-
low (Figure 11.2.0.2-c):
Extract Last_RF_Conn_Sector field listed in CDL (CDL Samples):

CDL #1: Pilot_A, Pilot_B, Pilot_C
CDL #2: Pilot_A, Pilot_C
CDL #3: Pilot_A, Pilot_D
CDL #4: Pilot_A, Pilot_B, Pilot_D
CDL #5: Pilot_A, Pilot_C, Pilot_D
CDL #6: Pilot_A, Pilot_D, Pilot_E
CDL #7: Pilot_A, Pilot_B
CDL #8: Pilot_A, Pilot_B, Pilot_C
CDL #9: Pilot_A, Pilot_B
CDL #10: Pilot_A, Pilot_E Figure 11.2.0.2-c
1. Ideally, an initial neighbor list (prioritized) is derived prior to system deployment by means of simulator.
2. Call Detail Log generated at the OMCR.
3. Last MAHO Information Active Pilot. PN Index Offsets from the Handoff Recognized message are con-
verted to a BTS (LAST_MAHO_ACT_BTS) and Sector(LAST_MAHO_ACT_SECTOR) . STR
(LAST_MAHO_ACT_STR) is the Ec/Io Measurement as received from the Mobile Station, displayed in
hex.
Page Page 98 of 106

From the above set of CDL samples the following numbers may be generated:
Pilot_A paired with Pilot_B = 5 counts (CDL#1, CDL#4, CDL#7, CDL#8, CDL#9)
Pilot_A paired with Pilot_C = 4 counts (CDL#1, CDL#2, CDL#5, CDL#8)
Pilot_A paired with Pilot_D = 4 counts (CDL#3, CDL#4, CDL#5, CDL#6)
Pilot_A paired with Pilot_E = 2 counts (CDL#6, CDL#10)
Neighbor list for Pilot_A in the order of decreasing priority as entered in the database:
1)Pilot_B
2)Pilot_C
3)Pilot_D
4)Pilot_E Figure 11.2.0.2-d
The neighbor list at the mobile station will be updated (via the Neighbor List Update
Message on the TCH) provided that one of the following condition is met:
✥Always send a Neighbor List Update on a handoff add situation (either soft or softer).
✥Send a Neighbor List Update on a handoff drop situation only if the last time the
list was sent to the mobile station had to be truncated (i.e. was > N8m, or 20, neigh-
bors)1.
The maximum amount of pilots in a neighbor list created by the base station is 20 neigh-
bor pilots2. The MM will enter the neighbor pilots into the list in the order of decreasing
priority, as determined by the order of the neighbors in the system database. In the case
of the mobile station having more than one pilot in the active set, the MM will “merge”
the database entries in a round robin order. When the total amount of neighbor pilots as-
sociated with each of the pilots in the active set exceeds 20, the lowest priority neigh-
bors will be truncated off the list. Please refer to the following Soft Handoff Neighbor
List “Merge” Example3 (Figure 11.2.0.2-e).
1. Refer to HOPC SFS for more information on the criteria in sending the Neighbor List Update Message.
2. (IS-95A: N8m = 20)
3. Barry J.Menich’s Internal Memo, MM Management of Neighbor Lists and Remaining Set Handoff (CDMA),
October 18, 1995.
Page Page 99 of 106

Soft Handoff Neighbor List “Merge” Example

Merge Assume:
A1 A1 = B3
B1 A2 = C4
Highest C1
Prob. A2
B2 B3 and C4 are not
A1 B1 C1 C2
included in the
A2 B2 C2 merged list as they
A3 are duplicates.
A3 B3 C3 C3
A4 B4 C4 A4
A5 B5 C5 B4 Ordered list sent to
A6 B6 C6 mobile in Neighbor
A5 List Update Message
A7 B7 C7 B5
A8 B8 C8 C5
Neighbor List
Cell A(Oldest)
Neighbor List
Cell B
Neighbor List
Cell C(Youngest)
Lowest A6 Note: B8 and C8 are
Prob. B6 not included in the list
C6 as they are truncated.
A7
B7
C7
A8
1)Merge neighbor lists in round-robin fashion starting with the oldest cell in the active set and
proceeding to the youngest cell.
2)Eliminate all duplicates from the merged list.
3)Truncate the list to 20 entries
Figure 11.2.0.2-e
The NGHBR_MAX_AGE parameter is recommended to be set to 0, as the list will al-

ways contain the most updated neighbors. This will prevent the mobile station from
leaving “aged” pilots in the neighbor list; thus, forcing a direct replacement.
3.21.3 Mobile Station/Base Station Data Analysis
There are many approaches in analyzing “RF Loss” cases. One common approach in
characterizing an “RF Loss” is to analyze the logs from the Qualcomm Mobile DM and
the base station CBSC SMAP. The useful mobile station information extracted from the
output of QC NPAR1 tool are: over-the-air IS-95A messages, FWD FER information,
TX/RX/RSSI levels, and FWD/REV frame rate and type. The useful information pro-
vided by the CBSC SMAP are the call processing messages at the XCDR CPP. There
are several non-commercial scripts that are located on the OMCR or the local work sta-
tion at the MTSO that will extract the call processing messages for SMAP. The com-
monly used decoding scripts are called “re” and “dmta”2. Other information from the
raw SMAP logs are available (i.e. rev FER, target Eb/No, FWD TCH gain), however, it
is not necessary to characterize all of the “RF Loss” calls in such great detail, as just the
messaging is sufficient in most cases.
The “RF Loss” calls are typically broken down to the following broad categories:
- poor forward link due to weak RSSI
- poor forward link due to weak Ec/Io in good RSSI (non-dominant pilot)3
1. Qualcomm NPAR decoding tool

2. usage: re <smap raw file> | dmta (script developed by Mike Lynch)
Page Page 100 of 106

- poor reverse link due to interference
The following are common characteristics for when a general “RF Loss” occurs:
■ RSSI level very low (weaker than -95dBm)
■ Ec/Io level very low (weaker than -13dB)
■ Neighbor pilots remain at a poor level (weaker than -13dB )
■ Forward erased frames detected (several Power Measurement Report Message)
■ Missed base station layer 2 acknowledgment message (logs will indicate several re-
peated messages
Although category #1, poor forward link due to weak RSSI, is not associated with soft
handoff failures, it is important to recognize that, in some cases, the mobile station will
find itself in an area where the soft handoff regions are not fully overlapped with adja-
cent sectors. This scenario may appear that the mobile station is at an edge of a system.
Figure 1-a is the Sparse AGC Power Control Information Message extracted from the
QC Mobile DM. This simply illustrates that the mobile station receive power (RSSI) is
very low indicating that either the output of the “RF_Pilot_PWR” at the base station
may be too low or the line of sight of the base station may be blocked. This RF charac-
teristic will also contribute to very poor pilot Ec/Io measurements as illustrated in figure
1-b. If an “RF Loss” occurs with data that is similar to figure 1-a and figure 1-b, it is safe
to conclude that the “drop call” was caused by poor forward link due to weak RSSI
(“RF Loss” category #1). A common method in correcting this problem is to carefully
increase the pilot power so that it forms a sufficient coverage area with an overlap with
the adjacent sectors such that it forms a stable soft handoff region. It is recommended
that the power is not transmitted too high to the point where it creates unwanted “non-
dominant pilot” regions in different unexpected locations. Caution must be taken
when adjusting the RF power or the soft handoff parameters, as it may improve
the RF condition for the intended location, but possibly degrade other locations.
Depending on the root cause of the problem, other methods may require a re-adjustment
of the antenna direction or possibly adding a BTS at the most optimal location.
“RF Loss” category #2, poor forward link due to weak Ec/Io in good RSSI (non-domi-
nant pilot), is a condition where the forward link is deteriorated, as there are no domi-
nant pilot in the vicinity. The RSSI, however, is at an acceptable level, unlike in category
#1. For the mobile station log in figure 1-b, it is apparent that the Ec/Io for both the ac-
tive set and the candidate set is measured to be very weak. In addition, as illustrated in
figure 1-c, the RSSI level is measured to be at an acceptable level indicating that the
poor pilot Ec/Io is not caused by the lack of base station “RF_Pilot_PWR” power. This
condition creates problems in soft handoffs as the mobile station finds itself in a region
that is commonly referred to as a “non-dominant pilot” region. The idea is to carefully
set the Tadd and Tdrop threshold such that the PSMMs are triggered at just the appropri-
ate time. For this particular non-dominant pilot case, the RSSI level at the mobile station
3. Non-dominant pilot is a term often used to describe a an RF condition where all of the surrounding Pilot Ec/Io
measures to be weak. The RSSI, however, is measured to be a an acceptable level.

is at an acceptable level (stronger than -90dBm) but all pilots in the vicinity measured at
the mobile station are poor ( pilot Ec/Io weaker than -13dB).1 The neighbor pilots acts
as interference to the point where a dominant pilot no longer exists. The soft handoff
procedures then becomes staggered as frame erasure rate between the mobile station
and the base station increases. There will be many message re-tries from both ends;
thus, an increased likelihood of a timer expiring (fade timer/message acknowledgment
timer). To alleviate this sort of behavior, the soft handoff parameters must be set opti-
mally in order to maintain the optimal pilot combination in the active set while the mo-
bile station passes through such harsh Ec/Io environment. Figure 1-d indicates that an
Extended Handoff Direction Message is sent multiple times from the base station with-
out an acknowledgment, which indicates that the message is not received at the mobile
station. Combining figure 1-b, figure 1-c along with figure1-d, it is suggests that the mo-
bile station was in an area where the forward link has deteriorated with the cause of poor
forward link due to weak pilot Ec/Io in a region with strong RSSI. Again, the key is to
set the parameters such that the mobile station does not attempt unnecessary soft
handoffs. This will decrease the risk of messages being missed; thus, decreasing the
chance of timing out either at the mobile station or the base station.
1. There is no scientific reasoning in determining what is “weak” and what is “strong”. The numbers mentioned
are strictly associated with the illustrated case.

08/04/1997 02:39:00.492 [18] Sparse AGC Power Control Information

adc_therm = 0x009c
batt_volt = 0x008d
tx_pwr_limit = 0x00e0 Note: very low RSSI level indicating that
Rx AGC Average = 0xffa0, Rx Power = -95.331 dBm the “RF_Pilot_PWR” at the base station
ADJ Average = 0x0002, ADJ = -1.430 dB may be too low
TX AGC Average = 0x00da, AGC Power = 20.703 dBm
TX Turnaround Power = 20.901 dBm
0: Rx/Tx/Adj = -95.915, 17.083, -4.000
1: Rx/Tx/Adj = -93.581, 22.083, 0.000 80: Rx/Tx/Adj = -96.248, 21.750, -1.000
2: Rx/Tx/Adj = -95.915, 15.750, -6.000 81: Rx/Tx/Adj = -96.915, 19.750, -3.000
3: Rx/Tx/Adj = -96.915, 19.750, -2.000 82: Rx/Tx/Adj = -94.248, 21.417, -1.000
4: Rx/Tx/Adj = -96.248, 22.417, 1.000 83: Rx/Tx/Adj = -96.581, 21.750, -1.000
5: Rx/Tx/Adj = -97.248, 20.417, -2.000 84: Rx/Tx/Adj = -95.248, 22.417, 0.000
6: Rx/Tx/Adj = -96.581, 21.083, -2.000 85: Rx/Tx/Adj = -96.248, 20.417, -2.000
7: Rx/Tx/Adj = -94.248, 18.750, -4.000 86: Rx/Tx/Adj = -95.581, 18.750, -4.000
8: Rx/Tx/Adj = -95.248, 18.083, -4.000 87: Rx/Tx/Adj = -95.915, 20.750, -2.000
9: Rx/Tx/Adj = -94.915, 18.083, -4.000 88: Rx/Tx/Adj = -94.915, 18.417, -4.000
10: Rx/Tx/Adj = -97.248, 17.750, -4.000 89: Rx/Tx/Adj = -95.248, 20.417, -2.000
11: Rx/Tx/Adj = -94.581, 19.750, -2.000 90: Rx/Tx/Adj = -94.915, 22.417, 0.000
12: Rx/Tx/Adj = -91.248, 22.083, 1.000 91: Rx/Tx/Adj = -94.248, 18.750, -3.000
13: Rx/Tx/Adj = -96.248, 17.417, -4.000 92: Rx/Tx/Adj = -96.581, 21.083, -1.000
14: Rx/Tx/Adj = -97.915, 20.750, -2.000 93: Rx/Tx/Adj = -96.915, 21.417, -1.000
15: Rx/Tx/Adj = -92.915, 20.417, -2.000 94: Rx/Tx/Adj = -95.581, 22.083, -1.000
16: Rx/Tx/Adj = -96.581, 20.417, -2.000 95: Rx/Tx/Adj = -95.915, 21.417, -1.000
17: Rx/Tx/Adj = -94.581, 20.417, -2.000 96: Rx/Tx/Adj = -95.915, 22.750, 1.000
18: Rx/Tx/Adj = -94.915, 22.083, 0.000 97: Rx/Tx/Adj = -94.581, 22.750, 1.000
19: Rx/Tx/Adj = -96.915, 22.750, 0.000 98: Rx/Tx/Adj = -92.581, 22.750, 1.000
20: Rx/Tx/Adj = -96.915, 19.083, -4.000 99: Rx/Tx/Adj = -94.915, 21.083, -1.000
Figure 1-a

08/04/1997 02:38:13.732 [0F] REVERSE TC CAI 08/04/1997 02:38:13.872 [11] REVERSE TC CAI
Pilot Strength Measurement Message Power Measurement Report Message
ack_seq 1, msg_seq 5, ack_req 1, encryption 0 ack_seq 1, msg_seq 0, ack_req 0, encryption 0
ref_pn 0x13a = 314 ( 314 ) Errors_detected 3
pilot_strength 25 ( -14.5 dB ) pwr_meas_frames 8
keep last_hdm_seq 2
pilot_strength 30
pilot_pn_phase[0] 0x76 = 118 ( 118 ) pilot_strength 33
pilot_strength[0] 28 ( -14.0 dB ) pilot_strength 26
keep
08/04/1997 02:38:11.872 [11] Markov
8Kpr 3 D1/2 0 D1/4 0 D1/8 9 SIGs 0
pilot_pn_phase[1] 0x1b81 => 110 + 1 chip ( 110 ) 4800 2 2400 0 1200 0 FERR 0 ERAs 86
pilot_strength[1] 36 ( -18.0 dB )
Note:the Markov information also indicate 86 erased frames
drop
out of 100 detected from 02:38:11.872 to 02:38:13.872.
08/04/1997 02:38:13.772 [10] REVERSE TC CAI

Pilot Strength Measurement Message
ack_seq 1, msg_seq 6, ack_req 1, encryption 0
ref_pn 0x13a = 314 ( 314 ) The Pilot Strength Measurement Messages indicate
pilot_strength 25 ( -14.5 dB ) very poor Ec/Io measurements for all listed pilots
keep (-13.5dB ~ -18.0dB). The Power Measurement Report Message
indicate very high fwd FER (3 frame erasures out of 8),
pilot_pn_phase[0] 0x1d82 => 118 + 2 chips ( 118 ) along with weak pilot Ec/Io measurements in the active
set (pilot_strength = -15dB,-16.5dB,-13dB).
keep
With the RSSI information from figure 1-a, it is safe
to assume that this particular region is considered to
pilot_pn_phase[1] 0x1b83 => 110 + 3 chips ( 110 )
pilot_strength[1] 36 ( -18.0 dB ) be lacking in power. The RF pilot power for the base
drop Station(s) that are designated to serve this particular
region should be adjusted to eliminate the RF hole.
pilot_pn_phase[2] 0x2686 => 154 + 6 chips ( 154 )
keep
Figure 1-b
Category #3 is an “RF Loss” caused by poor reverse link. Typically, the base station
will detect a Layer 2 failure or detect a fade time-out. When encountering very high
FER on the reverse link, the base station instructs the mobile station to increase it’s
power. This power control behavior is easily recognized as the mobile station TX
gain adjust is very large, as indicated in figure 1-c. The scenario will occur when
the power control parameters are not set according to the default settings. Occasion-
ally, after loading a new software release, the parameters are accidentally set in a
way that the mobile station transmits unusually high power. This creates a reverse
link noise rise that disrupts the reverse link for the surrounding mobile stations that
are in use. It is critical that all power control related parameters are set to the default
values.
Another source of reverse link degradation is in-band interference. This scenario

has been encountered close to local airports where signals are transmitted within
the CDMA band. Similarly, in-band signals may also be generated from other ana-
log infrastructure systems that are deployed near by. Unfortunately, there are no
technical approach in correcting the above two situations.

08/04/1997 02:38:28.632 [09] Sparse AGC Power Control Information

adc_therm = 0x009c
batt_volt = 0x0092 Note:High transmit gain adjust while
tx_pwr_limit = 0x00de maintaining a good RSSI level. This
Rx AGC Average = 0xffc0, Rx Power = -84.611 dBm is a clear indication that the base
station is receiving erased frames.
ADJ Average = 0xfffa, ADJ = 3.450 dB
TX AGC Average = 0x00c9, AGC Power = 14.840 dBm
TX Turnaround Power = 15.061 dBm
0: Rx/Tx/Adj = -87.248, 12.750, 0.000
1: Rx/Tx/Adj = -84.915, 14.750, 2.000 80: Rx/Tx/Adj = -88.248, 16.417, 4.000
2: Rx/Tx/Adj = -86.581, 17.083, 4.000 81: Rx/Tx/Adj = -84.248, 17.083, 4.000
3: Rx/Tx/Adj = -85.581, 16.417, 3.000 82: Rx/Tx/Adj = -84.248, 14.083, 2.000
4: Rx/Tx/Adj = -86.915, 21.750, 9.000 83: Rx/Tx/Adj = -84.915, 15.750, 4.000
5: Rx/Tx/Adj = -86.248, 21.750, 9.000 84: Rx/Tx/Adj = -87.248, 14.083, 2.000
6: Rx/Tx/Adj = -86.915, 21.083, 8.000 85: Rx/Tx/Adj = -85.581, 15.083, 2.000
7: Rx/Tx/Adj = -86.248, 18.750, 6.000 86: Rx/Tx/Adj = -86.581, 14.750, 2.000
8: Rx/Tx/Adj = -86.915, 16.417, 4.000 87: Rx/Tx/Adj = -84.581, 16.083, 4.000
9: Rx/Tx/Adj = -86.248, 14.750, 2.000 88: Rx/Tx/Adj = -86.581, 15.083, 2.000
10: Rx/Tx/Adj = -84.581, 14.417, 2.000 89: Rx/Tx/Adj = -84.915, 14.417, 2.000
11: Rx/Tx/Adj = -85.915, 11.417, 0.000 90: Rx/Tx/Adj = -86.581, 12.750, 0.000
12: Rx/Tx/Adj = -85.248, 13.083, 1.000 91: Rx/Tx/Adj = -84.915, 15.083, 2.000
13: Rx/Tx/Adj = -84.248, 14.083, 2.000 92: Rx/Tx/Adj = -84.581, 12.417, 0.000
14: Rx/Tx/Adj = -85.581, 16.750, 5.000 93: Rx/Tx/Adj = -84.915, 12.417, 0.000
15: Rx/Tx/Adj = -85.248, 15.417, 4.000 94: Rx/Tx/Adj = -83.581, 14.083, 2.000
16: Rx/Tx/Adj = -84.915, 15.417, 4.000 95: Rx/Tx/Adj = -82.581, 13.417, 2.000
17: Rx/Tx/Adj = -85.915, 14.083, 2.000 96: Rx/Tx/Adj = -83.915, 15.083, 4.000
18: Rx/Tx/Adj = -85.915, 13.083, 0.000 97: Rx/Tx/Adj = -84.248, 16.750, 6.000
19: Rx/Tx/Adj = -85.248, 9.083, -3.000 98: Rx/Tx/Adj = -85.915, 17.417, 6.000
20: Rx/Tx/Adj = -82.581, 13.750, 3.000 99: Rx/Tx/Adj = -84.915, 17.750, 6.000
Figure 1-c
10210 9f032b94 01 --- Ext Handoff Direction -----> 2 2 1 Tue Mar 18 1997 14:21:24:640
10225 9f032b94 DM_SOFT_ADD_FAILURE CIC= 1c12 Call Id= 1e5bCell Id= 0074
10231 9f032b94 DM_SOFT_ADD_START CIC= 1c12 Call Id= 1e5bCell Id= 002c
9f032b94 R_NORMAL Tue Mar 18 1997 14:19:36:320
10267 9f032b94 DM_RELEASE_START CIC= 1c12 Call Id= 1e5bCell Id= 002c
9f032b94 R_RF_LOSS Tue Mar 18 1997 14:19:40:160
CBSC SMAP Message Output
Figure 1-d
3.21.4 General Conclusion
This document provides sufficient background on the mechanics of the current Soft
Handoff algorithm, along with recommended methods in resolving common prob-

lems encountered in the system deployment phase or in the system expansion

phase. It is suggested that to be effective in optimizing a CDMA system, one must
be familiar with the Soft Handoff algorithms and logs mentioned in this document.
The methods recommended throughout this document are just one of several ways
in correcting common problems. It is, however, the most strongly recommended
methods. Other methods in correcting common field problems are attempting to re-
create the scenario in the test laboratory where it is in a controlled environment. Al-
so, using a variety of mobile station manufacturers in field testing to eliminate the
possibility of a defected mobile station. Referring to the simulation result for the
system that is being optimized may provide additional RF information. There are
also other debugging sources throughout the subsystems where detailed logs may
be captured (e.g. callproc1.out at the MM, XCDR CPP via MMI port, MCC data
via MMI port), however, most of which are strictly used in laboratory testing as it
impacts system performance when used on a commercial system. Nonetheless, the
recommendations described throughout this document is recognized to be the most
effective way in correcting common problems under the given circumstances1.
Currently, there is research effort in developing an algorithm which will allow the
optimization process to be automated. When this algorithm is integrated into the in-
frastructure system in the future software release, this document will be modified to
focus on automation. Unfortunately, the current optimization process must be exe-
cuted manually, in that one must drive test a system and analyze each problem one
by one. It is a time consuming task, however, it is the most accurate way in correct-
ing a problem.
1. Recommendations are based on the fact that the system is being optimized while stem deployment or sys-
tem expansion.

Traffic planning for HHO:

• DAHO
• Idle-mode and TCH.
• Where to place carrier boundaries as a function of traffic density or gradient? Reference my email on “tiering” and
John Voigt’s PowerPoint slide (probably not right).
PN planning for microcells and in-building sites contained within macrocell coverage.
• Reference Sam Fernandez email.
Inter-CBSC SHO
• Performance
• How to optimize
• Any consideration for inter-vendor?
KTF handoff between Motorola and Samsung
• Mony’s HHO idea feasability?
• Still need to look at plots after technique has been identified.
DAHO description and optimization strategies.
Pilot Beacons description and optimization strategies.
• Hong Kong input.
• Notes from Barry’s slides.
Future Possibilities and implications of spec changes, etc.
• Edge Sensing (note that edge sensing can be used to make DAHO more robust).
• TIA improvements a la Qualcomm/DeClerck method.
Time-line and future “vision” for HHO.
Ft. Worth tests on frequency-hopping pilot beacons.
Deployment “Special Situations”
• Hong Kong MTR deployment and optimization
• Singapore in-building sites with handoff to macrocell and coverage by leaky coax.
CDMA Umbrella Cells (Big Topic! Lots of IPR Potential!)
• John Toone slides from April ‘97 PrimeCo TEM
Note on Pilot Dominance and implications
N-Way SHO and Complex SHO (Barry’s paper or parts thereof?)
Special considerations for 6-sector systems
• Dennis Schaeffer 30 degree rotation idea.
• Barry’s alternating sector power idea.
Tom Ritchie email on partial overlays and notes about Singapore system.
AirTouch Back-to-Back Antenna Idea
Page 107 of 108

• Anything worth persuing here, or is this a dead issue?

Mony’s HHO Idea
• Possible modifications or motion simulations to support efficacy of design?
Start document with terminology list
• SHO terms from Barry’s N-Way document.
CDMA microcells
Page 108 of 108

MEMO: November 25, 1997
TO: Distribution Channels
FROM: Motorola CDMA Development Team
RE: CDMA Handoff Deployment & Optimization
CC:
New Stuff on 05/16/97

1.) Neighbor search window planning.
2.) Traffic planning for HHO:

• Beacons
• DAHO
• Idle-mode and TCH.
• Where to place carrier boundaries as a function of traffic density or gradient? Reference my
email on “tiering” and John Voigt’s PowerPoint slide (probably not right).
3.) PN planning for microcells and in-building sites contained within macrocell coverage.
• Reference Sam Fernandez email.
4.) Inter-CBSC SHO

• Performance
• How to optimize
• Any consideration for inter-vendor?
5.) KTF handoff between Motorola and Samsung

• Mony’s HHO idea feasability?
• Still need to look at plots after technique has been identified.
6.) DAHO description and optimization strategies.

7.) Pilot Beacons description and optimization strategies.

• Hong Kong input.
• Notes from Barry’s slides.
8.) Future Possibilities and implications of spec changes, etc.

• Edge Sensing (note that edge sensing can be used to make DAHO more robust).
• TIA improvements a la Qualcomm/DeClerck method.
9.) Time-line and future “vision” for HHO.
PAGE 109 OF 116

10.) Ft. Worth tests on frequency-hopping pilot beacons.
11.) Deployment “Special Situations”

• Hong Kong MTR deployment and optimization
• Singapore in-building sites with handoff to macrocell and coverage by leaky coax.
12.) CDMA Umbrella Cells (Big Topic! Lots of IPR Potential!)

• John Toone slides from April ‘97 PrimeCo TEM
13.) Note on Pilot Dominance and implications
14.) N-Way SHO and Complex SHO (Barry’s paper or parts thereof?)
15.) Special considerations for 6-sector systems

16.) Tom Ritchie email on partial overlays and notes about Singapore system.
17.) AirTouch Back-to-Back Antenna Idea

• Anything worth persuing here, or is this a dead issue?
18.) Mony’s HHO Idea

• Possible modifications or motion simulations to support efficacy of design?
19.) Start document with terminology list

• SHO terms from Barry’s N-Way document.
20.) CDMA microcells

Page 110 of 116

Inter-Carrier Hard Handoff With Pilot Beacons (Multi-Carrier)
Inter-CBSC Hard Handoff With Pilot Beacons

Figure #11.) Ideal Inter-CBSC Hard Handoff With 4 RF Carriers (R5)
CBSC Seam
CBSC #1 CBSC #2
The figure below shows the solution that the Hong Kong account team is proposing. Note that carrier F1 is ubiquitous
in the system due to the IS-95 “Primary” CDMA channel requirement. In addition, 1/2 of all handoffs (assuming
symmetrical mobility and carrier distribution per CBSC) are intra-carrier in nature.
Page 111 of 116

F1 PPS+TCH F1 PPS+TCH
CBSC Seam
CBSC #1 CBSC #2
F2 Beacon
F1 Beacon
CBSC Seam
CBSC #1 CBSC #2
Page 112 of 116

DAHO and Inter-CBSC Soft Handoff
Single Cell Intra-Carrier Hard Handoff

This memo serves to provide general guidelines regarding deployment of intra-carrier (same RF carrier), inter-cell
(between 2 different cells) hard handoff. Motorola currently supports this type of handoff in an effort to preserve
active calls that traverse (different) CBSC service areas. The items in this memo are, to a great degree, common
sense, however some are gleaned from practical experience in our Hong Kong market. Note that “seam” in this dis-
cussion designates an area where handoff needs to take place between two different CBSCs.
In general, intra-carrier hard handoff performance is not as good as that of soft/softer handoff. DSD is working on the
problem, however no tractable solutions have presented themselves. This should not be communicated to the cus-
tomer.
Hard Handoff Philosophy

Intra-carrier hard handoff detection is accomplished when the CBSC receives a Pilot Strength Measurement Message
that reveals a candidate pilot (which is an XSECT in the database) appears T_COMP dB above all active set pilots.
When this happens, a target channel is set up in the target CBSC and then the mobile is instructed (via the Extended
Handoff Direction Message) to change the active set pilot(s). T_COMP is used as a vehicle for hysteresis in the pro-
cess with the amount of hysteresis proportionate to the value T_COMP is assigned.
Intra-Carrier Hard Handoff Optimization

Given the philosophy above, the implications are that successful hard handoff is a strong function of the deployment
methodology. See below for more details. In addition, there are several other factors which affect the success rate of
hard handoff.
• T_COMP parameter: The Qualcomm mobile station demonstrates poor sensitivity (relative to simulated-
expected) in the seam region, especially at slow speeds. Thus, the amount of hysteresis used in combating the
“ping-pong” phenomenon must selected with care. In some instances, it may be that T_COMP cannot take on val-
ues any greater than 0.5 dB.
• Mobile station latency: Qualcomm has communicated to us that all versions of mobile station software are late in
reporting T_COMP events via the Pilot Strength Measurement Message. The quickest that a mobile will respond
with such an event is 250 milliseconds after the change has occurred in the RF domain. Lab measurements of
v1.34 and v1.60 phones indicate that the delay might be 2 to 3 times as long. Thus, situations where the time-rate-
of-change of the interfering pilot (i.e. target pilot) is large should be avoided.
• Infrastructure latency: Just as in soft handoff, there is a certain amount of processing and message passing on the
part of the CBSC that must occur upon each hard handoff execution. In addition to this, hard handoff also forces
the MSC and target CBSC to be involved as well. Future versions of CBSC and MSC software will attempt to par-
allelize the handoff process to the greatest extent possible, however inter-CBSC hard handoff execution times will
probably never be below 500 milliseconds.
• Extended Handoff Direction Message success rate: Given the discussion on mobile station sensitivity above, it is
apparent that successful delivery of the Extended Handoff Direction Message to the mobile station is difficult in
“high-noise” regions (i.e. the seam). There are a few things that can be tried to help this situation. The first is to
keep forward traffic channel gains as high as possible, and perhaps even at their maximum values, in the seam
cells. This only works in low noise, low traffic conditions. The second is a drastic measure where the amount of
power devoted to the paging and synchronization channels is reduced, or even eliminated.
• Multiple handoff regions: Due to the nature of radio-wave propagation, it is possible that scenarios will present
themselves that allow for multiple handoff regions along a line, or road, separating two cellsites on either side of a
Page 113 of 116

CBSC seam. Some handoffs may be completely unnecessary in the sense that a propagation condition that would
trigger a hard handoff comes and goes very quickly due to mobile (vehicle) movement. For fairly large cells, it
may be possible to use the neighbor search window to make the mobile station “blind” to the target pilot until the
mobile is well within the overlap region1. Once again, care must be taken in using this parameter as soft handoff
with cells/sectors on the same side of the CBSC seam is dependent on the value that the parameter takes.
• Number of L2 repeats: The current intra-carrier hard handoff algorithm specifies four “salvos” of Extended Hand-
off Direction Message attempts. The number of “salvos” will soon be increased to 7. Each “salvo” is 320 millisec-
onds long2 and contains a number of attempts equal to the L2 Num_Repeats count. Increasing the number of
repeats from 3 (default?) to 6 (maximum “sensible” value) may increase the message delivery rate in some slight
way.
Intra-Carrier Hard Handoff Deployment Tips

In general, successful intra-carrier hard handoff deployment is characterized by:
• Deployment restricted to “large” cells only.
• No quick NLOS3 to LOS4 transitions (target cell(s)). An example of this would be the Tai Po Harbor situation in
HK.
• No quick LOS to NLOS transitions (source cell(s)). An example of this would be the situation in Tate’s Cairn
Tunnel in HK where the entrance is blocked by a large vehicle and the source cell “goes away”.
• Cells far enough apart to make use of neighbor search windows to help in suppression of ping-ponging.
• Seams placed perpendicular to high traffic flow.
• No seams parallel to high traffic flow.
• No seams in high traffic areas.
• Seams in areas where traffic moves with relatively high speed such that the probability of ping-ponging due to
extended "straddling" of the handoff zone is reduced.
• Preferably one to one or many to one transitions. By this, we mean a single target cell. We all agree that the case
of being in soft handoff at the source cell(s) is advantageous in that we can use the site-to-site “macrodiversity”
side benefit of SHO to assist in increasing the probability that the Extended Handoff Direction Message will be
delivered successfully5. Unfortunately, going in the opposite direction, you’d have a situation where the transition
is one to many - definitely a situation we’d like to avoid. It might be that conditions would allow the usage of sec-
torized sites at the CBSC borders to make the target cells unambiguous and to limit the amount of SHO at the bor-
der.
1. As a special note, DSD is considering basing hard handoff detection upon phase measurements made by
channel elements. While solutions of this type might fall into the “tractable” category, their implementa-
tion is not in the near term.
2. See IS-95A section 6.6.4.1.3.2 and the value for timer T3m.
3. Non-line-of-sight.
4. Line-of-sight.
5. The “Fast Pilot Shuffling” feature will allow us to specify lower values for the T_ADD parameter in the
seam cells. This should increase the probability of 2-way and 3-way soft handoff in those border cells in
which the topology favors pilot coverage at T_ADD Ec/Io’s.
Page 114 of 116

• Deployment scheme that makes use of natural or man-made terrain features to either limit the number of HHO
transitions or limit the amount of “other cell noise” coupling between the two CBSC service areas. This was the
tactic that the HK team was using (look at an elevation map of HK).
• No sector boundaries for a cell that cross high volume traffic paths in expected handoff locations.
• No seams in areas of weak RF coverage. The seam area should be “interference-limited” and not “noise-limited”.
• Seams should be optimized for soft handoff
Dual Cell Intra-Carrier Hard Handoff

Mony Hassid’s idea.
From: Menich Barry on Wed, May 7, 1997 9:30 AM
Subject: Mony Hassid Disclosure - May '97
To: Hulsebosch Tom
Cc: Bonta Jeff; Bruckert Gene; Campbell Neal; Kotzin Mike; Frank Miller; Jim Aldrich GWI; Kowalewski Rolf;
Menich Barry; Schuler Joe; Welk John
Tom,
This is just a little note to lobby you for a favorable treatment of Mony Hassid's patent disclosure for intra-carrier
CDMA hard handoff up for review on the 15th. The business case here for Motorola is clear. This could be a stop-gap
measure for some markets with inter-CBSC handoff problems caused by lack of spectrum (Korea? AirTouch?). The
business downside is the need for some extra equipment, but as you know, we already have that problem (to some
degree) with pilot beacons.
The technical merits of the disclosure will obviously be judged by the committee members at the time of the review.
For what it's worth, my opinion is that this is a tractable solution that requires no CBSC software modification and I
support some kind of mini-trial somewhere (LA?). Mony already has some preliminary spreadsheet results and will
follow-up with some static simulation ideas.
In addition, I'm available for technical consultation with any of the committee members that want to discuss this.
-Barry
Page 115 of 116

Page 116 of 116

W H ITE PA P E R : Handoff Application Notes

November 25, 1997
Jim Aldrich
1 Introduction
This paper contains various application notes as pertaining to handoff operation within a
CDMA system.
2 Background
2.1 MAHO
MAHO, or Mobile Assisted Handoffs, are triggered by MS (Mobile Station) reporting
of neighboring signal strengths. Currently within IS-95-A and J-STD-008 an MS can
only scan and report on pilot PN sequences within the current in use CDMA frequency.
This is a substantial drawback where CDMA carriers are not ubiquitous. This includes
environments where multiple or differing carriers are used in a system, or where sys-
tems using differing carriers abut.
MAHO is what is normally used to add and drop pilots. It can also be used to trigger a
hard handoff.
2.2 DAHO
DAHO is the acronym for Database Assisted Handoff, originally called “last active pi-
lot” and sometimes called a “blind” handoff. It was specifically created to provide a
means to handoff to an underlying analog network when the MS appeared in a sector
near the edge of CDMA coverage. When a certain number of the active Forward Traffic
Channels (i.e. “legs”) are indicated (via the database) to be “DAHO” sectors (each for-
ward traffic channel corresponds to a sector) a handoff is triggered to the DAHO sector
Handoff Application Notes 117 of 126

/usr/test/adv_sys/cdma/documentation/stolen/aldrich/ho_notes
with the best signal strength. This capability has been extended to include CDMA
targets as well as analog.
Since a non-border (non-DAHO) pilot/sector may be dropped shortly after a mobile

arrives in a DAHO sector (thereby triggering the handoff), it is important that the
target’s coverage area completely overlaps that of the source. Where an underlaying
analog system exists, idle mobiles are sometimes redirected to the analog system
(via the Global Service Redirection Message on the paging channel), since a new
call may immediately be handed off to the analog system anyway.
In cases where an idle mobile is not redirected, and where a mobile is handed into
the system (i.e. CBSC), a hysteresis timer is employed to give the system time to
perform any soft or softer adds or drops which might result in the mobile remaining
in that sector-carrier (majority condition not met). Upon completion of a successful
hard hand-in, mobile origination or mobile termination to a border sector, the MM
will use the DAHOHysTimer database value to inhibit all subsequent DAHO bor-
der checks for a fixed length of time.
Ideally the MS would not handoff until it reached the periphery of the current sec-
tor(s), thus increasing the erlang capacity of the cell and reducing the overlap re-
quired. This “edge sensing” capability is currently under study but not yet planned
for any release. Another means of increasing the Erlang capacity is to suppress the
handoff by keeping non-DAHO sectors in the active set (of pilots) of the mobile as
long as possible. This can be accomplished by raising the drop timer value
(T_TDROP) and lowering the pilot drop threshold (T_DROP) for the DAHO
(hand-out) and adjacent sector/cells. As the mobile approaches the hand-out cells
from the adjacent cells, it becomes harder to drop pilots, thus delaying the handoff
until the mobile is more fully within the coverage zone of the DAHO capable sec-
tors.
Following are the exact majority criteria used when determining if a DAHO hand-
off should be attempted
Page 118 of 126

TABLE 1
1 Active Pilot 2 Active Pilots 2 Active Pilots 3 Active Pilots

Different Sites Same Site
0 DAHO Sector-Carrier Active Pilots N N N N
1 DAHO Sector-Carrier Active Pilot Y N Ya N
2 DAHO Sector-Carrier Active Pilots Y Y Y
3 DAHO Sector-Carrier Active Pilots Y

a. There is considerable debate at this point whether or not this should be a “N”. It has been decided to
allow this to be changed during process initialization via an environment variable.
3 MAHO and DAHO Techniques

When CDMA frequency coverage is not ubiquitous, or where CDMA coverage
ends, means other than the standard MAHO pilot reporting must be employed.
There are two basic methods that can be used, each with some variation. These are
the DAHO method, and the approach known as “Pilot Beacon”.
The Pilot Beacon approach uses a pilot channel only on an adjacent cell/sector
which is active on the same frequency that is in use on the source cell/sector. Al-
though there may be an access and paging channel as well, there are no traffic chan-
nels. This configuration thus enables the MS to report on these locations as in a
normal case. The end result is a handoff to an adjacent cell. This pilot beacon is
used at the periphery of coverage of a particular CDMA frequency. This method is
used mostly to trigger a handoff to a different CDMA frequency but could be used
for handoff to analog as well.
MAHO and DAHO methods may both be used in a BTS/Sector/Carrier, although

such combinations would require unusual circumstances.
3.1 Handoff to Analog

Both DAHO and MAHO trigger methods may be used to initiate a handoff to ana-
log.
3.1.1 DAHO Method
This method works best when a full overlay of the CDMA cells occurs, as shown in
Figure 14. However, to gain more usage out of the CDMA cells, specific sectors
may be overlayed (completely), as in Figure 15 (which shows one sector being
overlaid). Note that in both cases the analog cell may be an OMNI cell. In general
the transition may occur from a more sectorized cell to a less sectorized cell but not
vice-versa because the target cannot then be precisely determined. Also, the figures
Page 119 of 126

below show just two cells, usually there are groups of cells where frequency bound-
aries occur.
Figure 14
3 Sector BTS
on Carrier X
3 Sector Analog
BTS
Figure 15
3 Sector BTS
on Carrier X
3 Sector Analog
BTS
In the configurations above, a handoff to analog will occur when the conditions
stated in TABLE 1 occur. The target will be the external analog sector associated
with the DAHO (has the DAHO indicator enabled) sector with the strongest pilot
measurement.
3.1.2 MAHO Method
In this method a handoff to analog is triggered from a MS report of a pilot that is

considered external to the CBSC. The search for the target results in a handoff to
analog. Typically the pilot PN measured and reported by the mobile is a pilot bea-
con (else the target is a real CDMA cell in which case there would be no need to do
a handoff to analog). This configuration is depicted in Figure 16.
Figure 16
3 Sector BTS
on Carrier X
3 Sector Analog
BTS with Carrier X
Pilot Beacon
The advantage of this method is that the CDMA cell may be used for a longer peri-
od of time (more Erlangs) and less of an overlay of the analog cell is required. (It
may be that the normal overlap between cells is sufficient.) The disadvantage is
more equipment is required to populate the pilot beacon.
3.2 Handoff to CDMA
As in handoff to analog, both MAHO and DAHO methods may be used.
Page 120 of 126

3.2.1 DAHO Method
Since this method uses a rough geographic estimation of where the mobile is at us-
ing cell.sectors designated as DAHO, coverage between the source and target must
be complete. In fact, one of the best uses of this method is to use it to handoff from
one carrier (frequency) to another carrier within the same cell/sector. This is useful
when the MS is travelling towards the end of coverage of a particular carrier, but
there exists continuous coverage of another carrier.
An example is given in Figure 17 below. A MS on carrier Z is travelling from left to

right. As it travels it is able to soft handoff from BTS 1 to BTS 2. Carrier Zs cover-
age ends in BTS 2. In order to enjoy the benefits of soft handoff between cells,
when the MS is within majority DAHO coverage of the right-most sectors of BTS 2
(shown as shaded), a hard handoff is performed to carrier X. As the mobile passes
from BTS 2 to BTS 3 it can now do so using soft handoff.
Figure 17
Carriers X, Y, Z Carriers X, Y
BTS’s 1->4
Carriers Z Carrier Z->X Carrier X
Soft HO Hard HO Soft HO
3.2.2 MAHO Method
This is the normal method of performing handoffs. The MS reports on neighbors

(pilot PNs) it has measured and deemed to be adequate in strength. Sometimes
these Pilot PNs are resident on another CBSC, necessitating a hard handoff. When
this occurs the system will make every attempt to ensure the MS will be better
served by the neighboring cell. It accomplishes this by not executing the handoff
until the reported signal strength of the candidate pilot is a TComp event over each
of the current active pilots.
Another occasion for a MAHO initiated handoff is when the MS is in a location

where the current carriers coverage is about to end. Here the Pilot Beacon approach
is used. CDMA pilot channels are set up in adjacent cell/sectors where the current
carrier would not otherwise be present. This allows the MS to measure and report
on those neighbors as if the coverage were ubiquitous. Using the hard handoff trig-
ger criteria previously mentioned, a hard handoff will then be attempted to the
neighboring BTS. Since the neighbor will not have any traffic channels available
within the current carrier, it will allocate one where it does have some available.
Page 121 of 126

4 Miscellaneous
With release 6, handoff detection and handoff target selection are kept as separated
as possible. Either MAHO or DAHO detection schemes can be used to trigger a
handoff to analog or a handoff to CDMA. In addition, alternate targets are allowed.
Depending upon the type of failure, a retry of additional handoff targets may be
specified, up to a maximum of 4. For example, a failed handoff to a CDMA target
due to no resources available may be followed by an attempt to handoff to an ana-
log target.
Hard handoffs are always executed through the MSC, even if the source and target
CBSCs are the same.
5 Handoff/Database Interaction
The following sections within this chapter were part of the original design proposal
and are included here to provide a high level logical representation of how the
handoff algorithms and the database interact with each other to determine handoff
operation. Initial system access carrier selection is also included, as it closely re-
sembles the handoff method.
5.1 Initial System Access/Handin Carrier Selection
Figure 18 shows the inputs used for initial carrier selection following a mobile orig-
ination, page acknowledgement, or hard handin request. Input to the decision pro-
cess is either the source sector and carrier in the case of an origination/page ack
(also called sector and carrier of access) or the sector and carrier identified within
the A+ Handoff Request message, in the case of a hand-in. The type of access is
also used as an input. Note that in the case of a handin, the source carrier is optional
in A+ and may not always be present. In that event the first equipped carrier in the
database for that sector is used.
The source sector and source carrier are used to obtain a Carrier Selection List
from the carrier database. The access type is used in conjunction with the CBSC
level Call Distribution Technique parameters to return a Call Distribution Index.
These parameters are then utilized to return an Inward Route Index, or IRI.
The IRI is a number used to access the Inward Route Index Table. Output from the
Inward Route Index Table is a list of routes in preferred order of selection. The In-
ward Route Index Table is at a CBSC level, as the search strategy will likely be re-
peated across sectors having the same physical characteristics (i.e. carriers).
Page 122 of 126

Figure 18 Handoff/Access Target Carrier Selection

Carrier
Source Sector Carrier List Selection
Edit Carrier Carrier Selection List
Source Carrier Carrselect
CBSC
Access Type Call Distribution
Edit CBSC Call Distribution Index
Calldist
Inward Route Index (IRI)

CBSC
Inward Route Index Table
Edit Inroute
IRI Route List
(Carriers)
1 1,2,3,4
2 3,4
. .
. .
. .
Notes:
1.) Source Sector is sector of access for orig or page ack, target sector for HO
2.) Access Type is orig/page ack or handin
3.) Source Carrier is:
a) if orig or page ack, carrier of access
b) if handover:
if present in Handoff Request, source carrier
else is first equipped Carrier in database
Page 123 of 126

5.2 Handoff Target Selection, Source

This section outlines the handoff target selection algorithm on the source CBSC.
Once an external1 handoff has been triggered, either by MAHO or DAHO means,
the CBSC must select a target for the handoff.
The handoff target selection process is entered via either a PSMM (SCAP: Han-
dover Required received) (MAHO) or an indication of DAHO criteria being met.
Handoff Target Selection is based on where the MS is at and what initiated the
handoff. In particular, the following information is used:
1. Source Sector(s)
2. Source Carrier
3. PN of reported pilot (MAHO), or indication none was received (DAHO)
Please refer to Figure 19 for the following discussion.
For each sector/carrier there will be an associated list of PNs. For each PN in the
list there will be an Outward Route Index (ORI). There will be an additional entry
for the case where there is no PN.
The ORI is similar to the Inward Route Index, in that it specifies a list of logical
routes to try (to handoff to) in preferred order. Up to 4 may be specified. Each logi-
cal route identifies a XASect or XCSect object. These objects contain the data
needed to identify the target and execute the handoff. They are managed at the
CBSC level.
An alternate route (the next in the list) will be attempted when:

■ A handoff to the current route cannot be attempted. When attempting to hard
handoff to an XASect these reasons are:
- Hard handoff not allowed for current service option
- If MAHO initiated, reported signal strength is not TCOMP better than
all
active pilots
- Mobile not analog capable
When attempting to hard handoff to an XCSect the reasons are:
- Hard handoff not allowed for current service option
- No mutual service option between mobile and target system
- If MAHO initiated, reported signal strength is not TCOMP better than
all
active pilots
■ A handoff to the current route is rejected by the MSC and all retry attempts have
been exhausted (see HHORetryCnt parameter). Retries can only occur when the
MSC rejects the handoff for causes of “no resources available”, or “handoff
blocked”.
1. The method for adding (and dropping) of local neighbors does not change. The mobile re-
ported PN is looked for in the neighbor lists of the active sectors and if found, is added.
Page 124 of 126

Figure 19 Handoff Target Selection

Carrier
Outward Route Index
Source Sector Generator Table
Source Carrier Add/Edit Carrier/Sector
Sectop Outward Route Index (ORI)
PN (if via PSMM) Edit Carrier/Sector/BTS
DAHOParms (DAHOOri)
PN ORI
(noPN) 1
16 2
64 3
192 4
...
CBSC Carrier
Outward Route Index Table Outward Route Table
Edit Outroute Edit Carrier/Sector
ORI Route List Route List Routenum
1 1, 2 Route Target Info
2 3, 4 1 XCSECT-1-1
2 XCSECT-1-2
3 5
3 XCSECT-3-1
4 6, 7
. . 4
5
XCSECT-3-2
XCSECT-3-3
. . 6 XCSECT-3-4
. . 7
..
XASECT-2-1
..
. .
Page 125 of 126

Page 126 of 126

4.0 Present Tools
Page 127 of 128

Page 128 of 128

4.1 Pilot Beacon

from Dan Declerck’s taxonomy:
The definition of a pilot beacon will include a pilot channel, a sync channel, and optionally
a paging channel (for legacy IS-95A systems). This method is mobile assisted handoff
(MAHO) utilizing beacons to trigger the infrastructure to perform hard-handoff. The trig-
ger to handoff occurs when the mobile indicates to the base station when a pilot channel
(that is the beacon) is TCOMP above all active set pilots.This method is backward com-
patible with the 2 million CDMA phones that exist today. As we take our previous exam-
ple, and show which sites would contain beacons:
Two CDMA Carrier Domain
P P
P P P P
Cell 1 Cell 2 Cell 3
Single, Primary CDMA carrier domain

Figure 2
4.2 Qualcomm solution
Presently, Qualcomm sells a pilot beacon unit for approximately $20,000/sector/car-
rier which is controllable via modem. This is impractical in Japan due to: cost, the
nightmare of antenna combiners, inconsistent O&M interfaces
4.3 Motorola solution
Presently, there is a working group, chaired by Thomas Appiah, that is working on a
series of solutions. This group meets once a week on Fridays. Here are the following
options:
4.3.1 Integrated Solution
Page 129 of 132

This concept relies on designing a multi-carrier BBX with no receiver for

reducing cost, and utilizing an entire shelf (many BBX’s with one MCC) to
do multiple carrier beacons.
4.3.2 Stand alone solution
This concept is essentially an SC601 BTS with modified TRX’s which do
multiple carriers. There are difficult issues regarding low-cost O&M inter-
faces, with trade-offs in timeliness of delivery (drop-and-insert span vs. ana-
log modem interfaces).
4.3.3 Paging and Sync Channel Requirements
From: Menich Barry on Wed, May 28, 1997 6:17 PM
Subject: RE: Pilot Beacon - No Paging and Sync
To: Tenbrook Keith
Cc: Campbell Neal; Menich Barry
Keith,
Well, I understand Steve’s point of view and I’m all for reduced cost beacons.However,
we have J-STD-008 subscriber units to contend with. Some points:
1. I think we are getting the ability to set (via command line interface) more fields
in the Extended Neighbor List Message with the R6 load (I will check this with
Craig Reilly tomorrow morning). So, beyond the priority field, we can also specify
an RF carrier to be associated with a PN index offset. Thus, a J-STD-008 sub-
scriber unit in idle-mode should be able to scan across carriers. It’s anybody’s
guess if there are any perfomance issues associated with this. Note that ENLM is
not currently supported in IS-95A systems and subscriber units. When IS-95 and
J-STD-008 merge, we will still have the problem of supporting 1,000,000+ sub-
scriber units that do not have this feature. I think that this will always be a nagging
problem.
2. From what I understand of the spec., we’ll still need sync/paging to redirect to
AMPS/TACS/Other CDMA (Global Service Redirect Message). I am unaware of
any alternative way of doing this. Thus, at the outskirts of systems, or at operator
seams (where the operators have a service agreement) where a different technol-
ogy is supported, inter-technology idle-mode handoff will need to occur.
3. According to Bob Neely, Motorola subscriber units will search for synch/paging
on the RF carrier that was being used when a live call terminated. Thus, for those
(admittedly small) fraction of calls that end in the overlap region of a multi-carrier
transition, the mobile will hunt for synch/paging on the current RF carrier which
might not be the “best” PN (ie. reduced power beacon). Not finding synch/paging
just reproduces the problem we were trying to fix in the PrimeCo markets (eg.
Page 130 of 132

subscriber units taking a long time to search all PN space and make the decision
to slew to a different carrier) by adding the channel card to the cage with the bea-
con BBX. It’s possible that all, some, or none, of the other subscriber manufactur-
ers will also use the same implementation.
______________________________________________________________
From: Dubberstein Steve on Tue, May 27, 1997 7:21 PM
Subject: Pilot Beacon - No Paging and Sync
To: Haddock Graham
Cc: Appiah Thomas; Berghuis Tim; Campbell Neal; Cheng T L; Chuang Ching; Malone
Mike; Menich Barry; Ngan S K; Strong Dan; Tenbrook Keith; Thode John
Graham -
I know your team is working on Pilot Beacon issues as we speak. I think the results of a
test done here in Hong Kong last week may impact the design.
Last week the team in Hong Kong were able to successfully test R6 multi-carrier paging
using only the primary channel. In other words, they were successful in not using hash-
ing but distributing the traffic across the carriers upon origination on the primary carrier.
They were able to do this after carefully reading what R6 is capable of. This is the traffic
management issue that was the big barrier to removing paging and sync from the pilot
beacon.
The way I see it is that we can move forward to making a pilot beacon box with no pag-
ing/sync as we now have a method of avoiding the mobile in idle mode acquiring a bea-
con. All mobiles would be on the primary channel in idle mode, or hashed to carriers that
have no beacons as neighbours.
The system design will be a bit more difficult if you always must avoid beacons with no
paging/sync in idle mode, but I think it is a workable tradeoff for a much simpler beacon
product.
I solicit the opinions of all copied on this email to check my conclusion and make sure I
did not miss something.
regards, steve
4.3.4 how to set up paging and sync channels to redirect idle mode mobiles
use CDMA_FREQ field in the Sync Channel Message
Page 131 of 132

Page 132 of 132

5.0 CDMA Pilot Beacon Applications

SC-2.5.1 Application Note by Charlie Harrison
5.1 Scope
In the implementation of inter-carrier handoffs, a method is required to trigger the handoff
event as the Mobile System reaches the desired handoff zone. An adjacent Base Station
(BTS) broadcasting a pilot signal on the current MS carrier, known as a Pilot Beacon (PB),
is one method which has been tested, successfully deployed and is supported by Motor-
ola. The technique uses the Pilot Signal as interpreted by the MS Mobile Assisted Hand
Off [MAHO] feature to trigger the handoff.
A Pilot Beacon can be used as a handoff trigger in at least two specific inter-carrier appli-
cations. It has been successfully deployed as a means to trigger an inter-CBSC hard
handoff HHO at a seam between two CBSCs broadcasting on different frequencies. An
additional application of PB in future SC releases is as a trigger to handoff within a CBSC
broadcasting multiple carriers.
The functionality of Pilot Beacon is addressed in this paper only as it is supported by Su-
perCell Base Station System Release SC-2.5.1.
5.2 Objective
This document is intended to be used as a guide to evaluating the implementation of a
Motorola Pilot Beacon to facilitate handoff between frequencies. It is not intended as sys-
tem design guide or as an implementation manual. The Annexes to this document contain
some installation procedures which are useful in the planning and implementation of a
Pilot Beacon solution and can be used conjunction with the existing CDMA Command
Reference Manuals listed in the References Section (Section 5.11 on page 143).
5.3 PILOT BEACON CONCEPT OVERVIEW
To understand the concept of Pilot Beacon, refer to the simple case shown in Figure 20
on page 134. This is a depiction of a Pilot Beacon scenario independent of the method
of application. Consider a mobile station on the path (moving from left to right) as shown
initially being served on the left side of the diagram by carrier F1 on BTS 1. For this par-
ticular scenario, the parent CBSC of each BTS is not important.
Page 133 of 144

FIGURE 20: : Simple Pilot Beacon Scenario
F1 Traffic Channels F1 Pilot Beacon F2 Traffic Channels
BTS 1 BTS 2
Path of mobile station Trigger Point
As the mobile station nears BTS 2, it detects the F1 pilot broadcasted by BTS 2. The
MS will continue on its path until it detects the BTS 2 pilot strength at a definable threshold
above the MS active set, (Active Versus Candidate Set Comparison Threshold or
TComp). When the TComp threshold is reached, the MS reports the pilot strength to the
Mobility Manager (MM) via a Pilot Strength Message Measurement (PSMM). Within the
MM, the pilot PN Offset of the Beacon signal has been defined as an External CDMA Sec-
tor (XCSECT) neighbor pilot for the serving cell BTS 1. With TComp criteria satisfied and
the XCSECT defined, the MM executes a CDMA-CDMA HHO with the XCSECT data to
the target cell, BTS 2, via the Mobile Switching Center (MSC). As BTS 2 is not equipped
with traffic channels on carrier F1, the target MM will allocate a traffic channel (TCH) on
carrier F2 and the handoff occurs to BTS 2 - F2.
Once the mobile transitions to F2, there are no XCSECTs in that cell’s neighbor list that
could trigger a hard handoff back to the source BTS 2. Therefore eliminating multiple
handoffs (the ping-pong phenomenon), a scenario observed in inter-CBSC (HHOs) with
a high probability of dropping calls.
5.4 PILOT BEACON DEPLOYMENT SCENARIOS
There are several instances in the deployment of a CDMA system which may make use
of a Pilot Beacon to trigger a handoff. Figure 21 on page 135, provides a simple diagram-
matic representation of some of the possible scenarios.
Page 134 of 144

FIGURE 21: : Hard Handoff Scenarios
F1 F2
F1 & F2
Cells
F1 Cells Only
F2 Core With
A: F1 Ubiquitous B: Simple Seam
• Scenario A: F2 Core With F1 Ubiquitous

In densely populated areas, CDMA operators may deploy multiple carriers for additional
capacity in regions of heavy traffic. The additional carriers may only be required in the
heavy traffic areas and may not be deployed ubiquitously across the entire system, result-
ing in large clusters or islands of multiple carrier sites. Referring to Figure 21, if a mobile
is serviced by cells on carrier F2 and travels outside of the carrier F2 service area, a HHO
must occur from F2 to F1 or the call will drop.
• Scenario B: Simple Seam
This is the simplest of scenarios and represents two adjacent areas each serviced by a
different frequency. This may be as a result of a Telecommunications Carrier holding dif-
ferent frequency allocations/licences in different regions or at a transition between two Li-
cence holders. The Pilot Beacon is used to trigger the handoff at the boundary between
the two carriers.
This scenario may also exist intentionally in order to make use of a Pilot Beacon to im-
prove inter and intra-carrier inter-CBSC hard handoffs. There are several deployment
strategies which make use of this concept to overcome the problems inherent to making
intra-carrier handoffs at CBSC seams.
5.4.1 Scenario A: Inter-Carrier HHOs for Partial Overlay Multi-Carrier
In a multi-carrier system, additional carriers may be requierd only in areas of high traffic.
This type of deployment may result in a scenario such as shown in Figure 21 Scenario A,
and will require a method to initiate an inter-carrier handoff to the ubiquitous or primary
carrier.
Page 135 of 144

FIGURE 22: Partial Overlay Handoff Example
F2 Pilot Beacon
F1 Traffic Channels
F2 Traffic Channels
BTS 1 BTS 2
Hard Handoffs
Path of mobile station
The version of Multi-Carrier deployed in SC-2.5.1 (Multi-Carrier Phase I, Feature # 704)

is limited in versatility and configurable options. Specifically, all system database param-
eters for each Sector of each BTS are shared between the two carriers with the exception
of the CDMA Channel List Message.
In SC-2.5.1, External Sector topology is defined per sector regardless of the source car-
rier. A MS on carrier 1 uses the same sector/neighbour topology as a MS on carrier 2.
This limitation will cause unnecessary hard handoffs on the primary or ubiquitous carrier
if PBs are used in a partial overlay system.
Consider a system that deploys two carriers (F1 & F2), in the majority of its cells, however,
only requires one carrier (F1) in some isolated outer rural areas. If a PB were to be used
to trigger HHOs from F2 to F1 as the mobile leaves the F2 coverage area, a configuration
similar to the simple diagram shown in Figure 22 will occur at the end of F2 coverage.
In order to force a handoff from the F2 TCHs on BTS 1 to the F1 TCHs on BT2, the F2 PB
must be defined as an XCSECT in the F2 BTS 1 Neighbour List. Given the limitation in
SC-2.5.1, the BTS 2 F1 PN offset would also be defined as an XCSECT. This would force
unnecessary intra-carrier HHOs from BTS 1 to BTS 2 on carrier F1.
The success rate of the resultant intra-carrier BTS 1 to BTS 2 HHOs would likely be higher
than a normal inter-CBSC intra-carrier HHO as the MS will not attempt to HHO back to
BTS 1 and no ping-ponging will occur, however this configuration has never been tested.
In addition, as both carriers must share parameters, optimization for both the inter-carrier
and the intra-carrier HHOs may be difficult.
Pilot Beacon in SC-2.5.1 is not recommended for use to trigger and facilitate intra-CBSC
inter-carrier handoffs for partial carrier overlays. Please note that a full second carrier
overlay has always been recommended for SC-2.5.1.
Page 136 of 144

5.5 Scenario B: Pilot Beacon to Perform Inter-CBSC Hard Handoffs

There are several deployment strategies which make use of a Pilot Beacon to improve
inter-CBSC handoffs. All strategies require the use of extra spectrum. To date, only one
scenario has been tested in the field, and while plans are in progress at this time to begin
testing a more complicated option, only the Primary deployment option is discussed in this
document.
5.5.1 Primary Deployment Option (“Spot Beacon” Approach)
The Primary Inter-CBSC Inter-Carrier PB deployment option requires that a minimum of
two CDMA frequency channels are available to the operator. Each adjacent CBSC must
broadcast on a different frequency thereby facilitating an inter-carrier HHO at the CBSC
seam.
The diagram in Figure 23 on page 138, represents a CBSC seam area with carrier F1
TCHs deployed to the left and carrier F2 TCHs deployed to the right. The larger circles
represent cell site traffic coverage and the smaller circles represent the coverage of the
PBs with sufficient Signal to Noise Ratio (SNR) to trigger a handoff. F1 broadcasts are
indicated with a shaded pattern.
The PBs are transmitted using F1 when deployed on CBSC2 cells and F2 when deployed
on CBSC1 cells. The gain of the PB is reduced, limiting their coverage and providing
some hysteresis in the process by forcing a MS to travel closer to the target system before
the PB is detected. Thus, the hard handoff is delayed, ensuring that the signal strength of
the ADD leg on the target cell is sufficient to maintain the call. Please bear in mind that
the setting of the Pilot strength for the Pilot Beacon should consider cell “breathing”.
Page 137 of 144

FIGURE 23: : Primary Deployment Option
F1 Beacons
CBSC #2 F2 Traffic Channels
F1 Traffic Channels CBSC #2
CBSC #1
A B C D
F2 Beacons
CBSC #1
Hysteresis Zone
For example, a mobile moving from left to right in Figure 23, begins on traffic with CBSC
1 Cell A passes through Cell B (via Soft and Softer Handoff). As the mobile enters Cell
C, it is in the coverage area of both CBSC 1 and CBSC 2 as B and C overlap. The mobile,
however, does not see the pilot for the traffic channels on Cell C as it is transmitted on F2.
Once the mobile is well into Cell C, it detects the F1 Beacon pilot and a handoff occurs
to F2 where there is now strong coverage from Cell C.
The benefit from this approach is that the coverage of F1 in the CBSC2 coverage area
and F2 in the CBSC1 coverage area is increased. This occurs due to the fact that the “oth-
er cell” interference component (Ioc) for these frequencies is small in those coverage ar-
eas. Thus, calls can travel further before running out of coverage.
Advantages:
• Reduction, or elimination, of ping-ponging.
• Selection of pilot based on best performing candidate set pilot increases probability of suc-
cessful connection at target.
• Optimization parameters now include T_COMP value and power of target beacon.
• Pilot Shuffling feature should help in improving performance.
Page 138 of 144

• Possible relief from execution speed/latency issues. Because the handoff can take place at
lower T_COMP values (we no longer need to optimize to mitigate ping-ponging) and
because ping-ponging is greatly reduced, or completely eliminated, execution speed may
not end up being as critical as it is today with CDMA to CDMA intra-carrier hard handoff.
Disadvantages:
• No guarantee that coverage will extend far enough to make this work under all conditions.
Evaluation needs to be done on a case-by-case basis. Situations may arise where the tech-
nique completely fails.
• Extra antennas may be required at each site. While these antennas may be small in size, they
will nevertheless be subject to zoning and antenna mast wind-loading concerns.
• Requires pilot beacon hardware at seam sites/cells.
5.5.2 Requirement for Broadcasting Pilots in all Beacon Sectors
The diagram shown in Figure 23 is an extremely simplified representation of a Spot Bea-
con deployment. The diagram shows the reduction in Beacon coverage as result of the
reduced output power of the Beacon pilot and the resultant handoff hysteresis. When
planning and deploying beacons in the field, the requirement and power settings for bea-
cons in each of the three sectors of a sectorized cell must be considered to account for
hysteresis and coverage concerns.
Consider the two adjacent cells 2 and 5 shown in Figure 24 on page 140 and observe the
path of the mobile moving from right to left. The output power of the beacon pilot facing
the source cells has been attenuated to create the hysteresis. As a result of this attenu-
ation, it is possible for the MS to travel on the path shown between the adjacent cells miss-
ing the Beacon pilot on sectors 2-1 and 5-1. In order to use this hysteresis option, PBs
must also be broadcast on the sectors facing away from the source cells. The beacon
strength in sectors 2-2, 2-3, 5-2, 5-3 is increased beyond that of the source facing sector
to close the resultant gap. Increasing the pilot strength of these sectors has no adverse
affect on the beacon performance of the handoff. These requirements must be consid-
ered for each beacon cell, depending on its location and application.
Page 139 of 144

FIGURE 24: : Sectorized Beacon Deployment
Beacon Pilots on F1
Source Cells on F1
2-2 CBSC 1
Cell 2
2-1
2-3
Path of Mobile
5-2
Cell 5
5-1
5-3
Minimum Extent
of F1 Coverage
Target Cells on F2
CBSC 2
5.6 KNOWN LIMITATIONS

5.6.1 Idle Mode Handoffs
When a subscriber in idle mode moves into a Beacon site and detects that the beacon
pilot is sufficiently stronger than that of its current BTS, it will initiate an idle handoff to the
Beacon site. This handoff occurs with no infrastructure interaction and therefore there is
no opportunity for the infrastructure to actively direct the mobile to the traffic channel car-
rier on the target system.
The Beacon site can be configured to passively direct the mobile to the traffic channel car-
rier in SC-2.5.1 with the CDMA Channel List Message if the site is equipped with a Paging
and Synchronization Channel which require the addition of hardware. If the CDMA Chan-
nel List Message is implemented, the subscriber unit will quickly retune to the traffic chan-
nel frequency, if not it will temporarily lose service until the traffic channel frequency is
acquired. The details of each of each scenario are discussed below.
5.6.2 Mobile Re-direction with CDMA Channel List Message
A Paging Channel and a Sychronization Channel can be equipped for the Beacon site
with the addition of an overhead Multi-CDMA Channel (MCC) card to the CDMA Channel
Processor (CPP) PB shelf and subsequent traffic channel enabling. The CDMA Channel
Page 140 of 144

List Message on the paging channel and the Sync Channel Message body on the syn-
chronization channel can then be used on pilot beacon carriers to force the subscriber unit
to re-tune it’s frequency synthesizer to the TCH carrier.
After initiating an idle handoff, the subscriber unit has changed its active set pilot to the
beacon site and it will begin to monitor the beacon Sync Channel Message. The
CDMA_FREQ field is read from the Sync Channel Message body and the CDMA Channel
List Message Body. The Subscriber unit determines that CDMA_FREQ has changed
such that a frequency retune is required. The subscriber unit then retunes from the bea-
con pilot to traffic channel pilot within the current cell and begins monitoring synchroni-
zation channel, etc. This flow is described again in even further detail in Section 6, “Idle
Handoff Solution Description,” on page 153 of this document.
5.6.3 Mobile Behavior with Loss of Service
In the absence of any direction, the mobile is left to re-acquire the traffic channel equipped
carrier on its own. After the idle handoff, the mobile will attempt to acquire the paging
and synch channel on its current carrier (Beacon site), and will fail and enter the System
Determination Substate of the System Initialization State with a System Lost Indication as
defined in the IS-95A and ANSI-J-STD-008 specifications. Upon entering this state the
mobile should attempt to select the same system that was lost (PB frequency). The mo-
bile will successfully acquire the PB Pilot and will again fail with no Paging and Synchro-
nization Channels.
The number of times the mobile will cycle through this loop is not defined and is currently
unknown. Eventually, the mobile will enter the Custom System Selection Process which
is also very loosely defined in both specifications and is left to the mobile station manu-
facturer. From the Custom System Selection Process the mobile should identify the car-
rier equipped with traffic channels as the correct system to use.
In both the IS-95A and ANSI-J-STD-008 cases, the end result is a visible temporary loss
of service. The specifications do not stipulate minimum time requirements to regain ser-
vice and the length of the period of lost service will vary with system type and subscriber
unit model, version and configuration.
5.6.4 Recommendations
Reports from the current ANSI-J-STD-008 field implementations are that the mobile can
take from 3-10 seconds to re-acquire service after handing in to the PB site. These re-
sults are based on limited testing and it is therefore recommended that they be considered
approximate. It is highly recommended that before choosing to depend on the mobile to
re-acquire the traffic channel carrier, field testing be conducted on the specific system with
typical handsets in various configurations.
The advantage of deploying the Paging and Synch Channels is that idle handoffs occur
with no interruption of service to the user. This advantage, however, may be weighed
against the financial/business implications of equipping all beacon sectors with MCCs and
should be considered on a case by case basis.
Page 141 of 144

5.7 Subscriber Capacity Limits

Pilot Beacon makes use of second carrier capability of SC-2.5.1. If the second carrier is
required for traffic purposes, a Pilot Beacon implementation with Motorola equipment is
not possible with SC-2.5.1.
5.8 IMPLEMENTATION
Pilot Beacon has been implemented in various markets with Motorola equipment by mak-
ing use of the Multi-Carrier Phase I functionality in SC-2.5.1. The second carrier capability
of each CDMA BTS is used to transmit the beacon pilot. The source of the Pilot Signal in
a PB triggered handoff is unrelated to the active call and it is possible to make use of Pilot
Beacon Generator manufactured by a third party.
5.8.1 Hardware Requiremets
5.8.1.1 Motorola PB Hardware Requirements
Pilot Beacon is possible in SC-2.5.1 with Multi-Carrier Phase I functionality. The second
carrier capability of each CDMA BTS(4850, 2450 or 9600) is used to transmit the beacon
pilot signal. Hardware requirements for PB implementation, therefore, are the same as
those required for a second carrier installation with a few exceptions.
For use as a general guide, the following hardware is required for a BTS second cage/
second carrier installation:
• 1 CDMA Carrier HdW Kit (Includes CCP Shelf, GLIs, BDC etc)
• 1 BBX for Redundancy (if desired)
• 1 BBX for each beacon sector
• 1 Sector LPA for each beacon sector
• 1 Duplexer for each beacon sector
• Overhead MCCx8 cards as required per sector. Please refer to Section 5.6.1, Idle Mode
Handoffs to verify the requirement for Paging and Synchronization Channels.
• Appropriate cables and brackets.
In addition to the hardware for a second carrier installation listed above, attenuators are
required for each sector. Please refer to Annex 5.12.1 on page 143 for the details of the
requirement attenuators and the recommendations for setting beacon power levels.
Please refer to the CDMA Equipment Planning Guide, item [4] in the references section
for further details on BTS equipment planning.
5.8.1.2 PB Generator
The source of the Pilot Signal in a PB triggered handoff is unrelated to the active call and
it is possible to make use of Pilot Beacon Generator manufactured by a third party. The
source side MM database is configured no differently than if the Pilot Signal originated
from a Motorola BTS.
Any such PB Generator, however, would not be a Motorola CBSC managed device and
Page 142 of 144

would require external maintenance tools. In addition, unless the PB Generator can be
equiped to transmit Paging and Synchronization Channels with a configurable CDMA
Channel List Message or Global Service Redirect Message, the Idle Handoff Problem dis-
cussed in Section 5.6.1 on page 140 will prevail.
5.9 Installation and Optimization
The details of equipment installation, database provisioning and optimization are beyond
the scope of this document. Please refer to the documents in the references section or
the Annexes to this document for examples and details regarding these issues.
5.10 Beacon Span Requirements
An additional span is not required for PBs installed in the second CCP Shelf of the 2450,
4850 and 9600 BTSs. The existing implementations of PB use only one T1 in all sites.
The second CCP shelf transmits overhead channels only and there is no reason to add
additional timeslots (as all traffic is forced to the first cage). In addition, the pilot beacon
does not need it’s own LAPD, it is a slave to the MGLI that terminates the original span
and receives/sends all information to the Transcoder via that card.
In the implementation of true mini-multi carrier (both carriers used for traffic) timeslots can
be stripped from the original T1 and used in the second cage for traffic. A second span
is only required for the second carrier to relieve span congestion.
5.11 REFERENCES
[4] CDMA Equipment Planning Guide
[5] CDMA Second Carrier Installation SC2400/SC4800 Technical Education and Docu-
mentation (TED) 68P04245A14.
[6] CDMA System Commands Reference -TED 68P09226A24-3
[7] SC 2400/4800/9600 CDMA Cellular System Administration - 68P09226A21-6
[8] SC - 2.5.20.0. Release Notes Book Version 0.7
Please note:
• this document as well as items [4] and [8] can be found on the World Wide Web at the URL;
http://scwww.cig.mot.com/people/cdma/PjM/product/release_info/rel_5/rel_5.html
• items [5], [6] and [7] can be found on the World Wide Web at URL;
http://www.cig.mot.com/CIG/IviewDocs/cdrom2/cci/www/html/sc_pfa.html
Page 143 of 144

Page 144 of 144

5.12 SC-2.5.1 Pilot Beacon Installation

This section contains a collection of detailed notes which are useful in the implementa-
tion of Pilot Beacon. In general, the following steps are required to install Pilot Beacons
to a Motorola system.
• Install required Pilot Beacon hardware.
• Provision Pilot Beacon hardware in database (not required if external PB Box).
• Modify gain settings for pilot beacons.
• Define XCSECT devices and make database Neighbourlist and and Sector Topology
changes at Source CBSC.
• If required, migrate CBSCs to different frequencies (for Inter-CBSC, Inter-Carrier HHOs).
• Modify subscriber unit configurations with 2nd carrier capability
5.12.1 BTS Modifications - Beacon Settings

WPD Contact: Devesh Patel, pateldt@cig.mot.com, skypage 1570165
This section describes the procedure to change the Bay Level Offset which is required to
attenuate the Beacon Frequency Power out. It is recommended to attenuate the bea-
con sectors pointing away from the HHO seam by 6 dB and those towards the seam
by 20 dB. This will potentially reduce HHO ping-ponging by reducing hysteresis zone
near the seam while at the same time increasing beacon coverage area away from the
seam thereby minimizing the probability of MS failing to detect beacon pilot (please see
section 5.5.2 of the main document).
For proper functioning of “Pilot Beacon” aided HHOs, the second carrier (also known as
the Beacon Frequency) needs to be transmitted with lower power as compared to the Pri-
mary carrier. Since the current release allows changing “SIF Pilot Power” only on a per
sector basis, and not on a per carrier basis, an alternative method is needed to control
carrier power individually. Motorola has devised a procedure to accomplish this by chang-
ing the Bay Level Offsets (BLOs) in the downlink for each Tx branch (BBX). In order to
reduce power out for a carrier, the Bay level offsets need to be increased since they rep-
resent gain value. The BLOs reside in a calibration file that resides on MM.
What follows below is an outline on how these BLOs are stored in a cal file and how they
need to be changed. Thereafter, the various steps are listed in systematic order. The pro-
cedure is such that it can be applied without a need to know which of the two carriers is
primary or beacon. This should ease in the calibration procedure and facilitate automatic
scripting to implement changes.
Key Points
Page 145 of 154

• A 2-carrier BTS contains 8 BBXs. For the purpose of Pilot Beacon aided HHOs, for each 3
sector site, the first four BBXs are referred to as those supporting the Primary frequency and
the remaining 4 as those supporting the beacon frequency. It is essential that all of the eight
BBXs/Tx paths/slots are calibrated with the LMF for each 2 carrier BTS and that the corre-
sponding Cal files are uploaded on the MM for each 2 carrier BTS. It is also essential to
calibrate each of these eight slots with both the primary as well as the beacon frequencies.
• The uploaded Cal file for each BTS resides on the MM under /screl/active/loadable/bts-xxx
directory and is named with suffix ".cal" (eg, mm2:/screl/active/loadable/bts-108/bts-
108.cal)
The modification of the BLOs can be automated through the use of a script which, through
market implementation, has already been created. The script may be available from the
WPD contact for this section. What follows is a description of the BTS cal. file which is
useful if manual editing is required. In addition, a Step-by-Step procedure for editing the
cal files with the script is provided.
5.12.2 BTS Calibration File Description.
• For a 2-shelf SC 4850(E) frame, each Cal file contains Calibration data points for 8 different
BBX slots. Each slot contains 90 Calibration points - first 30 for the 3 Tx branches, next 30
for Main Rx branch for 3 sectors and last 30 for Diversity Rx branch for 3 sectors. Each cal
point is represented by two parameters -- Frequency and corresponding Bay Level Offset
(BLO). Hence the 90 cal points for each slot are arranged in an array of 180 elements. The
odd numbered elements represent Frequency and the even numbered ones represent BLO.
Each array element in the cal file is indicated as C[x]. So, 20 the array element will be
shown as C[20].
• Each BLO is entered in the cal file after translating the dB value to integer as follows:
BLO_in_cal_file = [(BLO_in_dB) + 150] * 100 (Eg, 45 dB <->19500)
• In a 2-carrier, 3-sector BTS cal file, for the slots 1 and 5, array elements 1 through 20 repre-
sent “valid” section to include Tx cal points. The remaining 21 through 60 are dummy
points. Similarly, for slots 2 and 6, array elements 21 through 40 represent “valid” section
while array elements 41 through 60 do so for slots 3 and 7. For slots 4 and 8 that are for the
redundant BBX, all 60 cal points from 1 through 60 represent “valid” section.
• For a 2 carrier BTS, it is essential to have at least first four cal point elements filled in with
cal data in each “valid” section to represent the two frequencies. It is also essential to
include the two frequencies in an ascending order. Eg, array elements C[21] and C[23] for
slots 2 and 6 should indicate 425 & 450 (and not 450 & 425). The next 16 cal points are
don't care within each valid section of a slot (these may become necessary for more than 2-
carriers per BTS)
• In order to reduce effective power out for a beacon frequency, only Tx cal points need to be
modified. The Rx cal points (i.e. elements C[61] through C[180] ) for each slot should be
left as they are. Further, these changes will have to be made only for slots 5-8. This is
Page 146 of 154

because beacon frequency is supported by second shelf (last 4 slots) of each BTS. First
shelf (first 4 slots) in each BTS supports Primary frequency and no changes are needed
there.
• For slot 5, 6 and 7, the BLO for both frequencies need to be increased by 600/2000 to effec-
tively decrease beacon power by 6/20 dB. In general, it is highly desirable to change all the
10 BLOs that are present in the òvalidó section for each of these slots(eg, alternate elements
from C[22] through C[40] for slot 6). The reason behind changing BLOs for both the fre-
quencies is that if, after making all the cal file changes, it were decided to move a 2-carrier
BTS from 1 CBSC to the other, it can be done so, transparently, without any need for a fur-
ther change in the cal files. For slot 8, all the BLOs corresponding to both frequencies need
to be increased by 600/2000 to effectively decrease beacon power by 6/20 dB (i.e., alternate
elements from C[2] to C[60]).
5.12.3 Step-by-step procedure to change Bay Level Offsets with Script:
• Each 2 carrier BTS need to be calibrated by a CFE with a LMF. All the 8 BBXs should be
calibrated with both the carrier frequencies.
• Place the cal files obtained from step1 on proper MM under /screl/active/loadable/bts-xxx.
• Open an xterm on the MM machine and change the directory to where the cal file to be
modified resides. Run the script provided to change the bay level offsets for the beacon car-
rier. The script will be provided with the applicable modification procedure.
5.13 Database Provisioning
WPD Contact: Mike Seymour, seymour@cig.mot.com, skypage # 1570196
5.13.1 GENERAL ADD SECOND CARRIER COMMANDS
This section describes the commands and arguments needed to provision a second car-
rier. The commands listed below do not form a procedure, they are simply provided as
a reference and should be used in conjunction with the CDMA Command Reference Man-
uals. Item [5] in the References Section of the Main Document (Section 5.11 on
page 141) provides details of a second Carrier installation and provisioning.
Each command section is listed in bold. The commands are to be entered via a CLI are
shown in italics. The commands are followed by verification command references and a
brief description.
DEFINE A NEW LOGICAL CARRIER FOR THE CBSC

>EDIT CBSC-x CARRIER!
>DISPLAY CBSC-cbsc# CARRIER
ADD CARRIER Command to SECTOR
>"ADD CARRIER-bts#-sector#-carrier#"
(A CARRIER defines an instance of a CDMA channel within a sector. The walsh codes for the
CDMA channel are provisioned as part of provisioning the CARRIER)
>"DISPLAY BTS-bts# CHANCONF"
Page 147 of 154

EDIT the CARRIER of each sector in the BTS Channellist

>EDIT CARRIER-bts#-sector#-carrier# CHANNELLIST CHAN1=carrier#
>DISPLAY BTS-bts# CHANNELLIST
ADD SCH Command
>"ADD SCH-bts#-sector#-carrier#-sch#",
Add a synch channel to the CDMA channel.
>"DISPLAY CARRIER-bts#-sector#-carrier# OVHDGRP"
ADD PCH Command
>“ADD PCH-bts#-sector#-carrier#-pch#”
Add a paging channel to the CDMA channel.
ADD ACH Command
>"ADD ACH-bts#-sector#-carrier#-pch#-ach#"
Add an access channel to the CDMA channel.
ADD MDM Procedure
>"ADD MDM-bts#-mdm#"
An MDM is added for each configured modem frame shelf. T2 CDMA only supports a single shelf
CDMA configuration. Adding the MDM provisions the
appropriate number of BDC's.
>"DISPLAY MDM-bts#-mdm# MDMCONF"
ADD BBX Procedure
>"ADD BBX/BBXR-bts#-bbx/bbxr#"
Add the BBX to a CDMA MDM.
>"DISPLAY MDM-bts#-mdm# MDMCONF"
EDIT MDM LINK Command
>"EDIT MDM-bts#-mdm# LINK CARRIER=carrier#”
Assign a logical carrier to the shelf.
>"DISPLAY CARRIER-bts#-sector#-carrier# CHANCONF"
ADD GLI (Remaining GLIs) Procedure
>"ADD GLI-bts#-gli#"
Add remaining GLIs (3 - 8 and 11 - 16) and/or MGLIs (9 - 10) to existing BTS. For a BTS,
BTSLINK #1 must be provisioned before any GLIs can be provisioned
within the site.
>"DISPLAY GLI-bts#-gli# GLICONF"
ADD MCC Procedure
>"ADD MCC-bts#-mcc#"
Add an MCC device to the MDM. The mode of the device (traffic only or traffic and overhead chan
nels) is specified on the command line.
>"DISPLAY MCC-bts#-mcc# MCCCONF"
EDIT Overhead Channel Linkages
Associate the overhead channels with a servicing MCC card.
EDIT SCH LINK Command
>"EDIT SCH-bts#-sector#-carrier#-sch# LINK CE=bts#-mcc#-1”
Associate the SCH with an MCC channel.
EDIT PCH LINK Command
Page 148 of 154

>"EDIT PCH-bts#-sector#-carrier#-pch# LINK CE=bts#-mcc#-0”

Associate PCH with an MCC channel.
EDIT ACH LINK Command
>"EDIT ACH-bts#-sector#-carrier#-pch#-ach# LINK CE=bts#-mcc#-0"
Associate ACH with an MCC channel.
5.13.2 Mobile Programming

All subscriber units to be used on the system must be programmed with all possible fre-
quencies on the system. This is to ensure that during the Mobile System Selection Pro-
cess, the Mobile recognizes and can select the traffic channel bearing carrier. For
example, if a PCS system with two CBSCs were to broadcast F=425 on CBSC 1 and
F=450 on CBSC 2 in order to facilitate Inter-CBSC Inter-Carrier HHOs, then both frequen-
cies/channels should be programmed in the phone.
The technique for programming mobiles will vary with system (IS-95A or PCS) and mobile
manufacturer.
5.13.3 Source Database Configuration
For each source sector it is important the following XCSECT and Neighbor list additions/
changes are made.
5.13.4 Neighourlist Additions
Due to the increased range of the border cells, additional neighbors must be added to the
neighbor lists. In general, all sectors from pilot beacon cells should be added to their
source neighbor lists. This will insure that mobiles initiating calls within the coverage of
the border cells can hard handoff to any cell after traffic channel assignment and that mo-
biles that travel past the reduced beacon spot beams are captured by the rear pointing
sectors (see Section 5.5.2 on page 137 in the main body of the document). This should
step occur before detailed drive testing and optimization.
It is imperative that the rear sectors of each beacon cell are included in the neigh-
bor list of hard-handoff cells and the XCSECT table reflects these additions.
5.13.5 External Sector Topology
As PB Handoffs make use of SC infrastructure CDMA-CDMA HHO Execution, XCSECT
objects must be established for the beacon pilot’s PN Offset Index.
Page 149 of 154

ANNEXES - FIGURE 25: XCSECT Example
Beacon Pilots on F1
Source Cells on F1
8-2 CBSC 1
BTS 8 23-1
8-1
BTS 23
8-3
5-2
BTS 5
5-1 24-1
BTS 24
5-3
Minimum Extent
of CBSC 1
F1 Coverage
Target Cells on F2
CBSC 2
Referring to Figure 25, consider that the cells equipped with Pilot Beacons on the target
side are configured as shown in Annexes Table 2 on page 150. Note that the PN settings
for this table are independent of the source of the Pilot signal (i.e. Motorola Beacon or PB
Box)
Table 2: Pilot Beacon PN Configuration

SECTOR - ID Pilot PN SECTOR - ID Pilot PN
bts-Sector (PILOTPN) bts-sector (PILOTPN)
SECTOR 8-1 230 SECTOR 5-1 240
Again referring to Annexes- Figure 25, the Source (CBSC 1) Side handover candidate
neighbour sectors (only external sectors are listed) for sectors 23-1 and 24-1 would be
configured as in Table 4 on page 151. Although this topology also contains internal sec-
tors/neighbours, they have not been included in this example.
For each HHO, the configuration data information required for each handover candidate
sector specified on the Topology Map must be accessible on the Source MM. In order to
Page 150 of 154

provide the accessing of this information at the source MM, the XCSECT device is creat-
ed. A XCSECT Device is a device which contains the configuration data information of
the CDMA handover candidates sector which are not under control by the Source MM.
The device provides some of the information required to execute the HHO via the A+ in-
terface. For example, the BTS and SECT fields are used to populate the Cell ID in the A+
Handoff Required message from the BSS to the MSC.
For each of the external sectors listed as neighbour candidates, there must be a corre-
sponding XCSECT DEVICE. For this particular example in Table 3 on page 151, only
target BTS and Sector are listed along with the XCSECT PN as the remaining fields in the
XCSECT tables are not relevant to this discussion.
Table 3: XCSECT Data

XSECT ID BTS SECT Pilot PN
XCSECT 2-1 8 1 230
XCSECT 2-2 8 2 232
XCSECT 2-3 8 3 234
XCSECT 2-4 5 2 242
XCSECT 2-5 5 1 240
XCSECT 2-6 5 3 244
Table 4: Source Side External Sector Topology

Source Neighbour Neighbour
Primary
SECTOR - ID SECTOR - ID Pilot PN
SECTOR 23-1 XCSECT 2-1 Yes 230
In SC-2.5.1, external sector topology is defined per sector regardless of the source carri-
er. A MS on carrier 1 uses the same sector/neighbour topology as MS on carrier 2.
5.13.6 Optimization Techniques
What follows are a few techniques that can be used to optimize hard handoff borders.
Page 151 of 154

5.13.6.1 Increasing Coverage/Overlap

4. First step is to adjust the source TCH Sifpilot power 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-exam-
ined to insure that newly created neighbor pairs are placed in the neighbor lists.
5. If the coverage across the seam is inadequate, the beacon power should be increased by use of
the beacon adjustment script in 2 dB increasing increments.
6. The overlap at the seam should provide a handoff region where the source is > -10 dB and tar-
get is >-10 dB after the transition has taken place.
7. Finally, if the region is still not satisfactory, lower Tcomp from the standard value.
5.13.6.2 Reducing Bouncing

1 First step is to adjust the source TCH Sifpilot power 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. The region should be re-driven in order to insure that coverage still
exists for the entire sector.
2 The second method is to decrease 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.
3 The third method is to increase the 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)
5.13.6.3 Drive Testing and Trouble-Shooting Suggestions
The section provides an outline of scenarios that may encountered during early drive test-
ing of recently installed PB sites. For the purposes of explanation, consider that there is
a seam between a “North/East CBSC” region and “South/West CBSC” region. Suppose
the North region operates on the “North frequency” and the South operates on the “South
frequency”.
To diagnose events at the seam, assume the mobile viewpoint and drive across the seam.
What you see will probably fall in to one of the following scenarios
5.13.6.3.1 Description Beginning
A mobile originates in the South/West region. It is able to do this because the mobile has
been programmed with the North/East frequency as primary and the South/West frequen-
cy as secondary or vice versa. The mobile proceeds in a North/East direction and ap-
proaches the seam area. The pn of a beacon (a pilot with offset index 51, or other, call
it “beacon pn index”) in the North/East region transmitting a pilot at the South/West fre-
quency becomes visible to the mobile and is reported on the DM F9 screen. Pilot “beacon
Page 152 of 154

pn index” exceeds Toad and the mobile sends a PSMM. There is no action taken by the
XC for this event. Several things may happen next:
Perfect outcome:
5.13.6.3.1.1 Soon pilot “beacon pn index” is T_comp higher than the best active set pilot,
and an inter-carrier hard handoff of the mobile to the same pn index but on the North/
East frequency takes place. The mobile is directed (via Ex. Handoff Direction) to the
North/East channel number and given a new walsh cover index for the forward channel.
A single moderate click may be heard on the mobile side. The mobile quickly goes into
soft handoff with various North/East site pns.
Not perfect, but acceptable:
5.13.6.3.1.2 The events of paragraph section 5.13.6.3.1 occur and then:
the new pilot on the North/East frequency falls T_comp below a now-visible South/West
region site transmitting a beacon on the North/East frequency. The XC sends the mobile
back via inter-carrier hard handoff to the South/West Site. Propagation conditions contin-
ue to change and the mobile sees the North/East site, South/West frequency beacon
again and inter-carrier hard handoffs back one more time, for a total of 3 HHOs in crossing
the seam region. From our mini-test area at I-355 and Lake, this seems to be a typical
occurrence.
Successful, but poorer audio:
5.13.6.3.1.3 The events of paragraph section 5.13.6.3.1 occur and there is no quick
evolution to the T_comp event. Instead, the mobile sees another distant South/West fre-
quency pilot (with traffic) along with the beacon. The mobile goes into SHO with this pilot
and is not close enough to the beacon site to trigger T_comp (the beacon is not T_comp
better than the active set). If inter-CBSC SHO were in place, the mobile would now be in
SHO with what is the North/East beacon site. Instead the North/East beacon interferes
with the mobile and causes multiple frame erasures. Finally, the beacon is T_comp bet-
ter than all active set members and the inter-carrier HHO takes place. The audio quality
may or may not immediately improve.
Unsuccessful, neighbor list:

5.13.6.3.1.4 The events of paragraph section 5.13.6.3.1 occur, followed by T_comp.
However, the beacon pn index is not in the neighbor list, so no HHO is allowed. Eventu-
ally, the mobile RF losses on it's South/West frequency active set.
Unsuccessful, beacon ok but traffic dead:

5.13.6.3.1.5 The events of paragraph section 5.13.6.3.1 occur, followed by a handoff
direction message to a channel on the North/East frequency. Unfortunately, in this sce-
nario, pilot, paging, sync and traffic at this sector on the North/East frequency are all
Page 153 of 154

dead because there is a site problem and there is no alarm to inform the system opera-
tor. The mobile HHOs to the North/East frequency but finds no live channel. It has been
suggested that this problem be avoided by shutting down the beacon if there is no power
on the traffic channel.
Unsuccessful, poor audio and no handoff:
5.13.6.3.1.6 The events of paragraph section 5.13.6.3.1 occur, followed by an evolution
similar to paragraph 3, but there is no T_comp event before the mobile fade timer expires
and the mobile RF losses. To avoid this, try lowering T_comp.
Page 154 of 154

6.0 Idle Handoff Solution Description

As described in Section 5.6.1, “Idle Mode Handoffs,” on page 138, idle-mode handoff
problems have been observed that cause lapses in system acquisition by the subscriber
unit. This section outlines the only solution for the problem in SC-2.5.1. The solution has
been tested in several Motorola CDMA markets and provides relief from the idle-mode
handoff problems associated with Pilot Beacon intiated handoffs..
The nature of the solution involves a characteristic of the SC-2.5.1 software load that re-
quires that all carriers at a BTS/sector transmit identical parameter information on syn-
chronization and paging channels. In particular, the CDMA Channel List Message on the
paging channel and the Sync Channel Message body on the synchronization channel can
be used on pilot beacon carriers to force the subscriber unit to re-tune it’s frequency syn-
thesizer to the over-laid (non-beacon) RF carrier.
Consider the simple diagram below (Figure 26, “Subscriber Unit Traversing CBSC
Seam,” on page 156) which depicts hypothetical control flow for subscriber unit idle-mode
activity. CBSC #1 (cell #1) and #2 (cell #2) are to the left and right of the seam respective-
ly. Traffic channel RF carriers F1 and F2 are also deployed to the left and right of the seam
respectively. A subscriber unit, in idle-mode, is traversing the seam from left to right and
is currently monitoring the paging channel for CBSC #1 on F1.
The sequence of events is as follows:
• Subscriber unit monitors pilot Ec/Io and paging channel FER of current idle-mode active
set1 cell (cell #1) on frequency F1.
• Subscriber unit determines that coverage of current active set cell (cell #1) is no longer ade-
quate and that beacon cell pilot (also F1) is superior in terms of Ec/Io.
• Subscriber unit changes active set pilot to beacon cell (cell #2) and monitors synchroniza-
tion channel.
• Subscriber unit recovers the CDMA_FREQ field from the synchronization Sync Channel
Message body.
• The subscriber unit then begins monitoring the paging channel (on F1) at the beacon site
(cell #2) and recovers the CDMA_FREQ field from the CDMA Channel List Message body.
• Subscriber unit determines that CDMA_FREQ S ≠ CDMA_FREQ R such that a frequency retune is
required.
• Subscriber unit retunes from F1 (beacon) to F2 (TCH bearing pilot) at cell #2 and begins
monitoring synchronization channel, etc.
1. J-STD-008 uses the identical terminology (e.g. “active set”, “neighbor set”, etc.) to describe both idle-
mode and tch-mode pilots.
Page 155 of 158

FIGURE 26. Subscriber Unit Traversing CBSC Seam
Start
Scan current Beacon

active paging cell coverage No
channel. established
(F1)?
Scan other PNs,

Yes possibly other
Current RF carriers.
No paging channel
coverage Acquire new cell
exhausted? synchronization channel
Yes
Acquire new cell
paging channel
Obtain
neighbor (F1 beacon)
cell sample
Current RF
No carrier.EQ. RF Yes
carrier in CDMA
Chan List Msg?
Subscriber Unit
retunes to RF
carrier in CDMA Subscriber Unit
Chan List Msg camps on beacon
and monitors signal (undesired
synch/paging outcome)
6.1 Idle Handoff Equipage Procedural Detail

Given that the beacon sites are already provisioned, we will only have to add one over-
head MCC for each sector that is involved in the beacon hand-off. The following is an
outline of the procedure to add and equipe the overhead MCC without equipping any traf-
fic channels (critical to the implementation of Pilot Beacon). After the MCC-8 card has
been physically installed in the CCP Shelf;
• Add a synch channel with the ADD SCH command, for example:
add sch-bts #-sector #-carrier #-sch #
Page 156 of 158

• Add a paging channel with the ADD PCH command, for example:
add pch-bts #-sector #-carrier #-pch #
• Add an access channel with the ADD ACH command:
add ach-bts #-sector #-carrier #-pch #-ach #
• Add the mcc with the ADD MCC command. The srchans should be linked to 0-0-0-0
which inhibits all channel elements. This allows the addition of the MCC without using
valuable timelslots.
add mcc-bts#-sector#-mcc# SRCHAN0=SRCHAN1=SRCHAN2=0-0-0-0 SRCHAN3=0-
0-0-0 SRCHAN4=0-0-0-0 SRCHAN5=0-0-0-0 SRCHAN6=0-0-0-0 SRCHAN7=0-0-0-0
MODE=ONEOCG MCCTYPE=MCC8
• Link the synch, paging and access channels to the MCCCE with the EDIT commands, for
example;
edit sch-bts #-sector #-carrier #-sch # link ce=bts #-mcc #-ce #
edit pch-bts #-sector #-carrier #-pch # link ce=bts #-mcc #-ce #
edit ach-bts #-sector #-carrier #-pch #-ach # link ce=bts #-mcc #-ce #
• Link the channel list of the PB site (for which the overhead channels were just equipped)to
the carrier equipped with the traffic channels. For example, if the site has traffic on F1 and
the beacon is on F2, then the channel list message on the beacon site should inlcude only
F2. This is done with the EDIT CARRIER command, for example;
edit carrier-bts#-sector#-carrier# channellist chan1=1
• Move the MCC from a PRECUT state to OOS_MANUAL by typing:
cutover mcc-bts #-mcc #
• Activate the MCC by typing:
activate mcc-bts #-mcc #
• Enable the MCC by typing:
ena mcc-bts #-mcc # unc
There is a possibility that the MCC may not come INS. If that happens, it is most likely due
to the gli_dev_map not getting updated real-time. In order to "work-around" this problem
if it is seen, simply disable/enable the cage controlling gli.
The above changes will link the beacon's channellist to the frequency of the traffic cage
and allow the mobile to re-tune to the frequency specified in the message. In addition,
SyncCdmaFreq parameter in the Sync Channel Message will get set to the same frequen-
cy as is specified in the Channellist Message. So, a mobile powering-up in the zone could
re-tune without having to acquire paging.
6.2 Pilot Beacon Output Power
Page 157 of 158

Since the addition of paging and synchronization channels to the beacon carriers, will re-
sult in an additional 2.67 dB of extra output power, it might be necessary in some situa-
tions to reassess beacon output power and adjust (upward) accordingly. The expectation
is that this should be a rare occurrence nevertheless, field engineers should be alert for
undesirable changes in handoff locations. These changes, should they occur, will most
probably manifest themselves between beacon sites.
6.3 Expectation for Empirical Results
The desired result from deployment of this technique is quicker response time by the sub-
scriber unit in acquiring the synch/paging channels of the TCH-bearing RF carrier at the
target cell during a seam transition. With the current deployment, the Qualcomm subscrib-
er unit will attempt to scan all PN-space on the current carrier (while at the beacon site)
before aborting and retuning to another carrier for system acquisition attempts. This has
been monitored by both customers and Motorola personnel and is estimated to take no
less than several seconds. During this period, the subscriber is inhibited from placing call
attempts or receiving pages.
Page 158 of 158

6.4 Static Simulator
Page 159 of 160

Page 160 of 160

6.5 Partial Overlay
Page 161 of 162

Page 162 of 162

7.0 FutureTools
Page 163 of 164

Page 164 of 164

7.1 Frequency Hopping Pilot Beacon
Page 165 of 166

Page 166 of 166

Frequency Hopping Pilot Beacon

May xx,1997
by
Scott M. HallSenior Staff Engineer

Jon St.Clair, Senior Staff Engineer
________________________________________________________________________
Abstract:
• Frequency Hopping Pilot Beacon reduces costs by eliminating multiple pilot beacons in
each sector of a BTS. The frequency hopping is very very slow and is not used to spread the signal
as in a CDMA-Frequency-Hopping system A single TX pilot beacon is scanned between all of
the pilot beacon frequencies in a sector. The time spent on each frequency is long enough (typi-
cally 2 seconds) to cause a hard handoff. The time to cover all frequencies is short enough (4 to
12 seconds for 2 to 6 frequencies) to cause mobiles traveling across the hard handoff boundary to
handoff before the mobiles are impaired. Idle mode handoff requires a sync channel for J-STD-
008. Idle mode handoff requires both sync and page channel for IS-95A and Japan-CDMA. Sync
and page information does not change as the pilot beacon hops frequences. Active calls do not use
sync or page channels.
Page 167 of 180

Table on Contents
• Introduction
• Theory
• Lab Test
• Field Test
• Where it does not apply
• Conclusion
• Appendix A:Hard Handoff explaination
• Appendix B:Initial Concerns
Introduction:
• Currently all hard handoffs in CDMA are caused by pilot beacons. Pilot beacons are typi-
cally 10 dB lower than pilots. As the mobile travels into the coverage area of the new cell with a
pilot beacon, the beacon will, at some point, get stronger than the pilot from the old cell. This trig-
gers a hard handoff to a new frequency. Please refer to Appendix A for more detaileds on pilot
beacon theory.
• Today, each frequency in the old cell requires a corresponding pilot beacon. Three CDMA
frequencies in the old cell would require three pilot beacons in the new cell. However, the new cell
can have one, three, or any number of CDMA frequencies.
• Frequency Hopping Pilot Beacon reduces costs by replacing multiple pilot beacon equip-
ment in each sector of a BTS with one peice of pilot beacon equipment. The single TX pilot beacon
is scanned amoung the old frequecies.
• The purpose of this document is to outline the plan to show proof of concept for scanning
pilot beacons. Theory, Lab Test, Field Test, and where it does not apply. A lot of information
presented in this paper applies to all pilot beacons independent of whether they are frequency hop-
ping or not. Appendex A covers the general Pilot Beacon theory. Appendex B has initial concerns
about frequency hopping pilot beacons
• This paperõs idealized examples use 3 hopping frequencies, 2 seconds dwell time per fre-
quency, 4 dB Tcomp and 0.2 watt pilot beacon power. The concepts shown by these idealized
examples can be easily transfered to real world CDMA systems that may have different number of
frequences, dwell time, Tcomp, or pilot beacon power.
Page 168 of 180

Use Wor
view Ma
Use Word 6.0c or

view Macintosh pi
Page 169 of 180

Use Word 6.0c

view Macintos
Page 170 of 180

General Hopping Beacon Theory

• The three figures on the previous page represent the generalize case for frequency hopping
pilot beacon.
• Figure 1 shows that pilot beacon does not imply that only pilot is transmitted. Sync and
page channels are also used except for J-STD-008 where only page channel is not needed. Pilot
beacons are set 10 dB lower (0.2 watts) than that typical pilot (2 watts) in a system. The lower
beacon power insures that when a mobile hard handoffs to the new frequency, that it is close to the
cell and well withing the cell range on the new frequency.
• Figure 1 implies that the only thing that changes over time is the frequency switch. It hops
between Freq 1, Freq 2, Freq 3, Freq 1, etc. Note how there is no change in the pilot, sync, or page
channels. However, the hopping beacon must use the same PN for all 3 frequencies. This arcuture
was chosen to simplify the software and hardward need for pilot beacon. Changing TX frequency,
keying and dekeying the LPA can easily be isolated to the BBX software. No CBSC software
modification is needed to change sync and page information as the beacon hops in frequency.
• Hard handoff during an active call is illustrated in Figure 2. A mobile has a call on Freq 1,
Freq 2, or Freq 3 in an old cell. As a mobile travels to a new cell with a beacon, the beacon (Beacon
1, Beacon 2 or Beacon 3 respectfully will get to point where it is 4 dB stronger than the old pilot.
At that point, after receiving a Tcomp PSMM (Pilot Strengh Measurement Message) from the mo-
bile, the CBSC will direct the mobile to hard handoff to Freq 4, Freq 5 or Freq 6 respectfully on
the new cell. No sync or page information is used for the handoff.
• Idle mode hard handoff is much different as shown in Figure 3. A true MAHO with no
CBSC involvment, the mobile monitors pilot and sync and maybe page to make its own hard hand-
off decision. A mobile monitoring Freq 1, Freq 2, or Freq 3 in an old cell. The exact frequency is
determined by a hashing algorithm. As a mobile travels to a new cell with a beacon, the beacon
(Beacon 1, Beacon 2 or Beacon 3 respectfully will get to point where it is stronger than the old pilot
. At that point, the mobile read the beacon sync channel. In J-STD-008, the CDMA_FREQ pa-
rameter in the sync message will cause the mobile to start to monitor Freq 4. For other CDMA
standards, the mobile must continue on to the paging channel to receive a CDMA Channel List
message to cause the change to Freq 4. A new hashing algorithm on the new cell will then direct
the mobile to monitor Freq 4, Freq 5 or Freq 6.
Page 171 of 180

Use Wor
view Ma
• Figures 4, 4 & 6 illustrate the slight differences between the standards. J-STD-008 does
not require a page channel. The CDMA_FREQ information at the end of the sync message directs
mobiles to the new frequency. IS-95A uses the CDMA Channel List on the page channel to direct
mobiles to the new frequency. The Global Service Redirest Message, which can also direct mobile
to new frequencys, is not currently available in Motorola CDMA systems. We know that both
sysc and page are need for Japan CDMA. However, we have deturmined the exact page message
used.
• Figure 7 shows an older implimentation of pilot beacon with no sync or page. Active call
hard handoff works fine, since it does not use sync or page. However, mobile idle mode handoff
had some out of service time. When a mobile receives a strong pilot beacon with no sync, it goes
Page 172 of 180

to its primary frequency. If the primary frequency was Freq 1, the mobile will then again detect a
strong pilot beacon with no sync. The mobile repeats this cycle 50 to 100 times.
Hard Handoff Flows
Active Call
1. Strongest Pilot in Old Cell
2. Pilot Beacon in Neighbor List
3. Pilot Beacon > Tadd
Mobile issues PSMM
CBSC denies Soft Handoff to New Pilot
Mobile may repeat step 3 several times
4. Pilot Beacon > Tcomp
Mobile issues PSMM
CBSC issues Hard Handoff for mobile to New Frequency
Idle Mode J-STD-008

3. Pilot Beacon > Old Pilot
4. Mobile receives Beacon Sync Message
CDMA_FREQ field in sync causes Mobile to change to New Frequency
5. Mobile receives new sync and page
6. CDMA Channel List message in page causes Mobile to hash to its
appropriate Frequency.
Idle Mode IS-95A

3. Pilot Beacon > Old Pilot
4. Mobile receives Beacon Sync Message
5. Mobile moves to Beacon Page Channel
CDMA Channel List message in page causes Mobile to change
to New Frequency.
6. Mobile receives new sync and page
7. CDMA Channel List message in page causes Mobile to hash to its
appropriate Frequency.
Page 173 of 180

Frequency Hop Timming
Use Word 6.0c or

view Macintosh p
* Typical Sync cycle is less than 240 mS. Give two cycles for the mobile to lock and complete a
complete cycles.
* Typical paging channel decode time is also estimated to be around 240 mS at 4800 BPS and this
assumes that there are no personal station directed messages.
* The paging channel is there to deliver the System Parameter Message, CDMA Channel List
Message, and most importantly , the Global Service Redirection Message.
* Call processing dictates that, if the Global Service Redirection Message is sent, it shall be sent
once every 1.28 Seconds (the T1b time period). *
• Idle Slotted Mode (1.28 or less timing)
• Origination (Originate, then get bommed) low prob event.
• Phone Power Up
Lab Test
• Soft Handoff if HH not available.
• handoff is one shot deal. HH. vary on time
• Call, idle
Page 174 of 180

Field Test
• Before and After data.
• 4 phones, 2 people van, 1 person land line.
• Drive one direction. Find handoff point. All tries except drops when mobile reaches the
point. (100 drive bys @ 10 per hour = 10 hours of testing.)
10 hour before data, 10 hour after data.
• Put programable atten on beacon. Adjust duty cycle to match. 2 seconds on, 10 seconds
off. Call Drops out of 100 calls. Idle mode, no valid system out of 100 tries. Call Termination out
of 100 calls. (with slotted if available) Call origination 100 calls. Call origination 100 calls.
Where does not apply

• Not test extreem situation. Over a hill the signal disappears rapidly.
2% of situations will not work. Require more pilot beacons.
• Rapid Change of pilots
• Cresting a hill
• Extreme shadowing
Categories of Personal Station Service States

1. Mobiles in the ACTIVE mode, engaged in a call.
These mobiles are constantly searching the neighbor list (and more infrequently the remainder list)
looking for neighbor cells and sectors for soft or softer hand-off. The Beacon pilot should always
be configured in adjacent cell neighbor lists. When a mobile search of the beacon neighbor coin-
cides with the multiplexed transmission on the mobile frequency, the mobile will detect the pilot
and take asses the signal strength.
If the signal strength is above the absolute T_ADD threshold, the mobile adds the pilot to the Can-
didate Set and sends up a Pilot Strength Measurement Message to the base. This soft handoff is
denied by the CBSC since it knows the beacon pilot does not support soft handoff.
Page 175 of 180

If the signal strength is above the relative T_COMP threshold, the mobile adds the pilot to the Can-
didate Set and sends up a Pilot Strength Measurement Message to the base. This message triggers
the base to perform a hard hand-off. The hard hand-off is performed and the Sync and Paging
channels are never decoded.
2. Mobiles in the IDLE mode, constantly monitoring the paging channel.
These mobiles are constantly looking for neighbors also to perform an Idle mode hand-off. When
an Idle mode mobile hands off to a pilot beacon, it proceeds to decode the Sync and Paging chan-
nels. If it is a PCS JS-STD-008 mobile, it will detect the CDMA_FREQ parameter at the end of
the Sync message and change to that frequency instantly.
If it is a IS-95A mobile, it will decode sync and proceed to decode the paging channel. When the
mobile reads the Global Service Redirection Message it performs an hard hand-off the specified
frequency. (Note: it has been proposed that the paging channel could be eliminated for IS-95A mo-
biles by setting the sync channel MIN_P_REV {minimum protocol revision} level to one level
above all mobiles in service.)
3. Mobiles in entering the System Determination Substate, recovering from a fade or powering on
within range of the beacon.
These mobiles come up into the IDLE mode first, so all of the above apply to them also. If the
mobile comes up during the period when the carrier is multiplexed off, then the mobile searches
for the secondary or tertiary CDMA carriers (or the AMPS signaling channel) automatically. This
is exactly what would happen if the mobile came up in a region just beyond the beacon, and is not
a problem.
Placing Sync and Paging on the beacon avoids the problem of the mobile chasing its tail by going
to the primary CDMA frequency, detecting a pilot, attempting sync detection, failing, going back
to system determination, being reassigned to the primary CDMA frequency, searching for pilot
etc. A process which can disrupt service for typically 15 to 20 seconds, until the beacon region
is crossed or the mobile gives up and tries another frequency.
Note, multiplexing a pilot only signal quickly, at a low duty cycle, may element the need for sync
and paging altogether.
•
•
Page 176 of 180

Appendix A:Pilot Beacon Theroy
Use Word
view Macin
Hard handoff from one CDMA frequency to another is illustrated in Figure 1. above. The
Cell 1, F1 (Frequency 1) pilot power and the Cell 2, F2 pilot power are 2 watts each. The Cell 1,
F2 pilot beacon and the
Cell 2, F1 pilot beacon are 0.2 watts each.
Assume a mobile starts a call at Cell 1 and travels to Cell 2. The mobile initiates the call
on F1. The MHO (mobile assisted handoff) algorithm will keep the mobile on F1 until the Cell 2
pilot beacon on F1 is received 4 dB higher at the mobile than the Cell 1 pilot on F1. The 4 dB
higher condition, which occurs at Point A, causes the mobile to hard handoff from F1 to F2.
A mobile traveling from Cell 2 to Cell 1 will hard handoff at
Point B.
Page 177 of 180

Use Word 6
view Macin
Figure 2 shows a scanning pilot beacon in a 6 frequency CDMA system. Cell 1 services
calls using odd frequencies. Cell 2 services calls using even frequencies. Hard handoff takes place
from odd and even frequencies and vice versa. (F1<--> F2, F3<-->F4, F5<-->F6)
Assume a van, at Cell 1, starts 3 calls on 3 phones, one call on F1, one call on F3, and one
call on F5. The van travels to Cell 2. Cell 1 and Cell 2 are 1 mile apart. The van is traveling 60
mph. Also, assume the Cell 2 pilot beacon is scanned between F1, F3 and F5, dwelling 2 seconds
on each frequency. Finally, assume a phone can lock onto a scanning pilot beacon and hard hand-
off in less than 2 seconds.
The van arrives at the Cell 1 & Cell 2 hard handoff boundary, at t=0 seconds, exactly when
the Cell 2 scanning pilot beacon starts to TX on F1. Less than 2 seconds latter, the F1 phone will
hard handoff to F2. At t=2 seconds, the scanning pilot beacon starts to TX on F3. Less than 2
seconds latter, the F3 phone will hard handoff to F4. At t=4 seconds, the scanning pilot beacon
starts to TX on F5. Less than 2 seconds latter, the F5 phone will hard handoff to F6. All the hard
handoffs occurred within 6 seconds, or 0.1 miles of the hard handoff boundary.
Page 178 of 180

• Attachment for Part 2: (State the problem(s) solved by the invention)
• The Pilot Beacon approach to managing hard handoff in a CDMA cellular system becomes
very costly in systems with more than three or four carriers. Lower capacity sites, with one or
two carriers must deploy a pilot beacon on every carrier sector supported by an adjacent high ca-
pacity with many more carriers.
• When handing down from a high capacity site, with more carriers than an adjoining lower
capacity site, mobile units must soft handoff on the intersecting carriers or receive a beacon to ini-
tiate a hard handoff on the carriers not covered at the lower capacity site. Various configurations
require many pilot beacons.
• For example, a JCDMA system has 10 carriers deployed in 6 sectors per site in a downtown
urban area. A site along a highway out of town or in a subway tunnel deploys 2 carriers in 3 sectors.
Even though the low capacity site has only 6 carrier sectors, it must provide pilot beacons for all 8
other carriers, on each of the 3 sectors. Total beacons required = 24. In this example a simple 6
carrier-sector site needs to broadcast another 24 pilot beacons just to support hard handoff. Po-
tentially a costly problem.
• The deployment of pilot beacons will vary widely from site to site depending upon where
the hard handoff boundaries are. It is not desirable to burden every cell site with the overhead of
pilot beacon hardware for the sake of the few sites that need it. A simple modular approach is need-
ed.
• Beacon provides a Sync channel for the primary CDMA_FREQ parameter and a paging
channel for the Global System Redirection Message. There are no Personal Station Directed Mes-
sages on the Paging Channel.
• Attachment for Part 5: (Improvements over known technology)
• Primary improvement: Integration of multiple pilot beacon carriers into one transmitter
significantly reduces device cost, size, and complexity. Issues with antenna combining methods
are reduced. No longer are multiple turned cavity power combiners necessary to combine all bea-
con carriers prior to connection to an antenna.
• The optimal trade-off between multiplexing channel gain and system performance remains
to be determined, but it is conceivable that from 3 to 1 up to 6 to 1 multiplexing may be feasible.
Appendex B:Scanning Beacon Initial Concerns

1. Scanning pilot would increase the handover detection time.
Page 179 of 180

This will increase dropped call rates.Joe Pettinger
2. When the scanning pilot comes up on a carrier, bursts of handoff on that carrier will oc-
cure. Joe Pettinger
3. Will mobiles get confused and not be able to receive pages because it's constantly locking/
unlocking on a time shared pilot?Joe Pettinger
4. We've always assumed that QC has tweaked their chipset and SW for some particular ve-
hicle speed. How could you build a matched filter for a fading process without knowing the vehicle
speed? Answer: You don't. You just try to build something that does a "reasonable" job at all
speeds. Coupled with this is some sampling scheme that is simultaneously "slow enough" to cap-
ture decorrelated data while "fast enough" not to miss interesting portions of the signal. It's the
sampling that has me worried.Barry Menich
5. I think the best thing we could do would be to actually test scanning under a variety of con-
ditions with QC, Motorola, Oki, Samsung, LG, and Nokia mobiles and see what they all would do.
Since, unlike GSM, none of this is in the spec., I can only warn against undesirable outcomes. It
would be unfortunate to design a hopping beacon and then find out that Nokia mobiles won't work,
etc.
Barry Menich
6. Slotted mode and idle handoff muddy the waters as to exactly when sectors need to be on
or off. Barry Menich
7. Different pilot Ec/Io filters implemented by different subscriber manufacturers make it dif-
ficult to speculate on a minimum energy requirement.
Barry Menich
8. The baseband portion of the hopping generator would need to be cognizant of sector spe-
cific information needed on the sync/paging channel (Global Service Redirect, Neighbor Lists,
etc.). Barry Menich
Page 180 of 180

7.2 N-Way SHO and Complex SHO (Barry’s paper or parts thereof
Page 181 of 182

Page 182 of 182

11/25/97
TO: Neal Campbell, Pat Connors
FROM: Barry J. Menich, Chris Schmidt, & Dennis Thompson
RE: Partial N-way, Minimal Complex Handoff Algorithm Strawman/Proposal
CC: Jim Aldrich, Anil Barot, Will Bayer, Matt Dillon, Marilyn Escue, Steve Dubberstein,
Ken Fujikawa, Roland Ho, John Kay, Randy Kohl, Gerry Labedz, Bob Love, John
Nolting, Devesh Patel, Joseph Pedziwiatr, Joseph Pettinger, Tom Ritchie, Gino
Scribano, Paul Steinberg, Keith Ten Brook, John Thode, John Voigt, Dan Willey
This memo will serve as a “strawman” proposal for our next round of soft
handoff upgrades which is centered around the “Partial N-Way SHO” algo-
rithm. We are soliciting feedback from the technical community regarding
the necessity for this feature as well as the algorithms that comprise the
feature. Please forward your comments to Barry Menich, Chris Schmidt, or
Ken Fujikawa.
Two algorithms will be discussed. One algorithm is a very simple extension
of today’s normal soft handoff algorithm with Fast Pilot Shuffling. The other
algorithm is more complicated and strives to minimize PN “thrashing” as
well as limiting pilot shuffling “exposure” during periods of poor RF or non-
dominant PN.
Per our previous discussions, it is assumed we are still targeting R8 as the
release for introduction. More specifically, this memo will contain proposals
for sub-algorithms known as “Cell Swapping1”, “Soft Shuffling”, and “Softer
Shuffling”. Obviously, simulation results of any algorithms propsed herein
are desirable prior to full committment to a particular release. However, this
document represents a “best shot guesstimation” of an N-Way SHO algo-
rithm. Note that the complexity of the algorithms derives partly from the
lack of HW available to support true 6-Way SHO.
Definitions:
Provided below are some definitions that we’ve adopted for the sake of this
document and to further facilitate internal discussion. Note that there are
no industry standards with regard to these. Thus, they should not be used
outside Motorola until such time that we are confident in the need for these
features and/or their implementation in a particular software release.
HHO. Hard HandOff.
SHO. Soft HandOff.
1. This algorithm will probably replace the current “Fast Pilot Shuffling” feature.
PAGE 183 OF 208

Full Complex: This feature implies the ability (on the part of the infrastructure) to per-
form multiple add and/or drop operations within one Extended Handoff Direction Mes-
sage. Because of the desire, at the time of Extended Handoff Direction Message
transmission to utilize the maximum number of currently available forward and reverse
links for the procedure transaction, this also implies 2N forward/reverse links where N is
the maximum expected size of the active set.
Partial Complex: This feature implies those complex operations that may be accom-
plished by utilizing existing XCDR hardware. These operations are defined by the Jim
Aldrich matrix and constrained by the number of forward and reverse links required to
complete any given handoff operation1.
HHO Complex: Also known as “complex HHO”, this feature implies the ability on the part
of both subscriber unit and infrastructure to connect the subscriber unit into at least 3-
way soft/softer handoff immediately at the target following an Extended Handoff Direction
Message. Thus, N forward links are transmitting as the subscriber unit performs connec-
tion procedures at the target.
Full N-Way: This feature implies XC hardware able to support 6 forward and 6 reverse
links. Uses “Next Generation” or “improved” XCDR circuitry that supports the ability to
manage 6 MCCce’s.
Partial N-Way: This feature implies the ability to support up to 6 forward (Walsh codes)
and 3 reverse links2. Uses currently available XCDR circuitry. Forward links are a mix of
soft and softer connections such that we are always constrained to 3 reverse links.
Full Diversity N-Way: This feature implies everything contained with “Full N-Way” as
well as subscriber unit hardware with N demodulation elements.
Mobile Assisted Pilot Dominance: This feature refers to the recent Qualcomm pro-
posal of using a secondary threshold that is a function of the sum of the active set SNRs
as a technique to inhibit Pilot Strength Measurement Messages. See appendix #B for
clarification of the Qualcomm proposal.
Infrastructure Assisted Pilot Dominance: This feature implies a handoff algorithm on
the part of the infrastructure that examines active set and candidate set pilot Ec/Io esti-
mates in the Pilot Strength Measurement Message and attempts to determine an optimal
active set while simultaneously minimizing the number of forward link transmitters to the
minimum required for quality forward link reception.
Cell Swapping: An algorithm in the infrastructure that works with Partial N-Way SHO
and actually performs reverse link handoff (switching an XC connection) from one cell
1. As an example, consider the situation where a subscriber unit is in 3-way SHO between 3 different BTSs.
If we wanted to simultaneously add a new BTS while dropping one of the existing BTSs, we’d still want to
transmit the Handoff Direction Message via the transmitters of the 3 existing BTSs and receive the Handoff
Completion Message via the receivers of the 3 new BTSs. Due to current downlink combining techniques,
we can’t just decide to drop a transmitter from the active set without first informing the subscriber unit, etc.
2. If the combining bit in the Extended Handoff Direction Message is used, then the mobile only responds to
3 sets of PCG puncture bits.
Page 184 of 208

(BTS) to another. It is an operation similar to Fast Pilot Shuffling, however performed at

the BTS, rather than PN, level.
Soft Shuffling. A technique used with Partial N-Way SHO whereby a pilot at one BTS is
swapped out in favor of another, superior performing, pilot at another BTS. Both BTSs
currently serve the subscriber unit.
Softer Shuffling. A technique used with Partial N-Way SHO whereby a pilot at one BTS
is swapped out in favor of another, superior performing, pilot at the same BTS.
Fast Pilot Shuffling. Also known as “FPS”, a technique used in R5, R6, and R7 whereby
T_TDROP timers for active set pilots are preempted only in three way SHO when in the
presense of a candidate set pilot that meets the shuffle criteria. Fast Pilot Shuffling does
not discriminate between soft and softer connections.
Non-Dominant PN. This is a condition defined by good/excellent RF coverage (non-ther-
mal noise limited case, >-80 dBm) with poor pilot Ec/Io performance. Also described by
some in the industry as “pilot pollution”.
Algorithm Requirements / Wish List

N-Way soft handoff will require modifications to the MM to determine when to “Cell
Swap”. Because of the current software limitation of 3 forward/reverse link pairs, the Fast
Pilot Shuffling algorithm does not discriminate between pilots that originate from the
same or different sites. Thus, FPS will no longer be useful. Instead, FPS concepts need
to be extended to “Cell Swapping”.
• Minimize the number of “Cell Swaps”. As with FPS, Cell Swapping is an undesirable additional burden on the
infrastructure as well as an additional handoff operation, with all it’s attendant messaging (and resulting voice
degradation due to lost speech content), to the end user. In addition, Cell Swaps have the potential to leave the
subscriber unit especially vulnerable on the forward link during swap transitions.
• Give the customer/system optimizer some control over “Cell Swaps”. The current FPS algorithm triggers off a
T_COMP event as well as an event defined by the candidate set pilot Ec/Io being stronger than 2 of 3 active set
pilot Ec/Io’s. This latter trigger is not directly1 under the control of the optimizer/operator. Should this become
known to the operators (right now this is not generally known - even within Motorola), it could be provoke ill
feelings.
• Suppress Cell Swapping under poor pilot conditions or conditions of non-dominant PN. One negative attribute
of the current FPS algorithm is that it is completely insensitive to absolute pilot Ec/Io values. Several people have
come forth to complain about the algorithms performance in poor RF and/or non-dominant PN conditions where
dropping down to 2 forward links (during the shuffle operation) is detrimental to the health of the call.
• Concurrent drop of multiple softer links. This is desirable to minimize the amount of “exposure time” while in a
marginal forward link diversity state due to the lack of Full Complex capability2.
• Full N-Way Softer Capability. Japan 6-sector will eventually be implemented with single BTS cellsites. Thus,
possibility exists for 3-way, 4-way, and possibly more, softer handoff.
1. Use of increasing values of T_ADD can be used to “weed out” the candidate set and thereby inhibit some
number of FPS operations. Unfortunately, this requires more skill than most operators and system operators
possess.
2. Chris believes that this is possible.
Page 185 of 208

• Provide at least some Pilot Dominance capability. It should be noted that the release date for an N-Way SHO
algorithm is sufficiently far enough into the future to warrant consideration of impact with respect to heavily
loaded CDMA systems1.
• Provide growth path for the eventuality of Full Complex, Full N-Way, and a full implementation of Infrastruc-
ture Assisted Pilot Dominance algorithm(s). The R8 implementation should not inhibit, or restrict, future soft
handoff algorithm evolution.
• Factor in consideration for IS-95/J-STD-008 Pilot Strength Measurement Message transmission rules. Both
specifications have clear rules for transmission of Pilot Strength Measurement Messages. This rules must be
adhered to.
• The implementation must be “achievable” by R8. This implies that the algorithm eventually selected lies within
the capabilities of current hardware configurations (including inter-CBSC soft handoff) and software development
availability (ie. not so complex that it cannot be completed within a release cycle).
• Provide “Fall-back” position in case of possible dissatisfaction with Qualcomm demodulator assignment/reas-
signment algorithm(s). This one’s gonna be tough2.
General Attributes of “Partial N-Way”

Partial N-Way soft handoff has the following attributes:
1.) General ADD/DROP Operations Preserved: Usage of T_ADD, T_DROP, T_COMP, and T_TDROP parameters
is preserved.
2.) Cell Swapping: Swap connections from one cell to one, or more, connections at another cell.
3.) Softer Shuffling: Fast Pilot Shuffling amongst pilots eminating from a single BTS.
4.) Soft Shuffling: Fast Pilot Shuffling amongst pilots eminating from two different BTSs.
5.) Softer Active Set Limiting: Limitation of the number of subscriber active set members by BTS (need better
description here.
6.) Multiple Softer ADD Operation: Adding more than 1 co-BTS pilot (softer connection) to the subscriber active
set.
7.) Multiple Softer DROP Operation: Dropping more than 1 co-BTS pilot (softer connection) from the subscriber
active set.
8.) Maximum number of softer handoff legs from any site is self-limited 3-sector or 6-sector deployments. In other
words, we would never implement a 6-sector site with MCCx8 HW and expect it to be capable of 4-Way softer, etc.
All 6-sector sites to be implemented by MCCx24 HW.
Cell Swapping Under “Partial N-Way”

Consider Figure #1 below where a subscriber unit is in 5-way soft handoff with cells A,
B, and C. In this figure, solid lines are indicative of forward link connections from the
cell(s) in question. Thus, the subscriber unit is in 2-way softer handoff with cell A, 2-way
1. As an example, consider the current subscriber growth rate for Hong Kong extrapolated to the R8 time-
frame.
2. Motorola has no experience with Qualcomm subscriber unit performance under N-Way SHO conditions
beyond N=3.
Page 186 of 208

softer handoff with cell C, and 1-way soft handoff with cell B. The dotted line eminating
from cell D and terminating at the subscriber unit denotes that one sector from cell D has
achieved candidate set status from the subscriber unit’s perspective.
Figure #27. 5-Way Soft Handoff via Partial N-Way
Cell A Cell C
Mobile
Cell B Cell D
For the purposes of our discussion, we shall assume that the soft handoff algorithm in
the MM has decided that cell D’s pilot will provide better forward link performance for the
subscriber unit than the composite forward link signals from cell A. This trigger is called a
“cell swap”, and the intermediate step is shown in Figure #2 along with the final result in
Figure #3. Notice in Figure #2 that all forward links from Cell A have been dropped simul-
taneously.
Notice the simularity between “Cell Swapping” and the current FPS algorithm. FPS does
not discriminate between soft and softer connections. Cell Swapping will need to have
this capability.
Figure #28. Intermediate Stage of “Cell Swap” Procedure
All forward links
associated with
Cell A have been
Cell A disconnected. Cell C
Mobile
Cell B Cell D
Page 187 of 208

Figure #29. Final Result of “Cell Swap” Procedure
Cell A Cell C
Mobile
Cell B Cell D
The execution aspects of cell swapping are obvious. They are soft handoff “add” opera-
tions that are identical to those currently performed. The soft handoff “drop” operation of
multiple forward links is a small stretch from today’s single forward link drops.
Softer Shuffling Under “Partial N-Way”

Consider Figure #4 below where a subscriber unit is in 5-way soft handoff with cells A,B,
and C. In this figure, solid lines are indicative of forward link connections from the cell(s)
in question. Dotted lines indicate transmission cells/sectors for candidate set pilots. In
this illustration, pilots #1 and #2 are active set pilots while pilot #3 is a pilot that has
achieved an Ec/Io level sufficient to trigger a softer shuffle.
Cell A
#1
Mobile #2 Cell C
#3
Cell B
In Figure #5, the intermediate step of a softer shuffle is depicted with the MM having cho-
sen pilot #1 as the pilot to be dropped from the active set. Note that pilot #1 and pilot #3
are co-BTS pilots.
Page 188 of 208

Figure #31. Intermediate Stage of Softer Shuffle Procedure
Cell A
#1
Mobile #2 Cell C
#3
Cell B
The procedure finally finished in Figure #6 which shows that pilot #3 has been “shuffled”
into the subscriber unit active set. Note that the mechanism used was not “Full Com-
plex”. Note also that Cell C was limited to 2 active set pilots only. This will be covered in
the section on “Pilot Dominance”.
Figure #32. Final Stage of Softer Shuffle Procedure
Cell A
#1
Mobile #2 Cell C
#3
Cell B
Soft Shuffling Under “Partial N-Way”

Consider Figure #7 below where a subscriber unit is in 6-way soft handoff with cells A,B,
and C. In this figure, solid lines are indicative of forward link connections from the cell(s)
in question. Dotted lines indicate transmission cells/sectors for candidate set pilots. In
this illustration, pilots #1 and #2 are active set pilots while pilot #3 is a pilot that has
achieved an Ec/Io level sufficient to trigger a soft shuffle. In this example, pilot #4 has
been chosen by the MM software as an underperforming pilot to be dropped from the
subscriber unit active set in favor of pilot #3.
Figures #8 and #9 depict intermediate and final stages of the soft shuffling operation.
Page 189 of 208

Cell A
#4
#1
Mobile #2 Cell C
#3
Cell B
Figure #34. Intermediate Stage of Soft Shuffle Procedure
Cell A
#1
Mobile #2 Cell C
#3
Cell B
Figure #35. Final Stage of Soft Shuffle Procedure
Cell A
#1
Mobile #2 Cell C
#3
Cell B
Implications of N-Way SHO Implementation

The CDMA Static Simulation (CSSS) may need to be ugraded. This upgrade work would
take into account the eventual partial N-Way algorithm chosen.
Page 190 of 208

Won’t have gains for 4, 5, and 6-way forward power control unless we specify. Not having
gains available will put us in a position of possibly delivering poorer capacity than would
be possible. Perhaps this is acceptable for 1, or 2, release cycles.
Algorithms
Proposed Simple Rules
The following proposed simple rules should always apply regardless of what algorithm is
finally chosen.
Rule #9.) The algorithms will follow the convention in Fast Pilot Shuffling whereby the XC and MM are not
required to have memory capability with regard to “add” pilots on any shuffle operations.
Rule #10.) Any T_COMP event for a candidate set pilot where the candidate’s Ec/Io in the Pilot Strength Measure-
ment Message is T_COMP dB greater than all active set pilot Ec/Io, from any BTS, shall be honored1. This event will
be referred to as “T_COMP Prime” in this document and will always invoke some response from the infrastructure.
Rule #11.) Any T_DROP event in a Pilot Strength Measurement Message will always result in at least one active set
pilot drop. Add events in PSMM always prioritized over drop events, except in cases where shuffling is required.
Algorithm Detail
The basic philosophy taken with the proposed approach is to minimize the number of
“highest risk” handoff operations. Beyond that, the algorithm is no more complicated than
making decisions of when to add candidate pilots and when to drop active pilots. Handoff
operation risk is proposed as Figure #10 below.
Figure #36. Handoff Risk Hierarchy
Cell Swap
Soft Shuffle
Increasing
T_COMP Prime
Softer Shuffle
Risk
Drop BTS (non-Cell Swap)

T_ADD (single or multiple)
T_DROP (single)
The current state of the call (which includes the number of active set pilots and their
associated BTS identities) and the current contents of the Pilot Strength Measurement
Message (active set and candidate set Ec/Io information and “keep” flags) defines the
future state space per Simple Rule #1.
The primary algorithm we are proposing (Algorithm #1) assumes sorting of Ec/Io for
active set and candidate set pilots as well as the ability to associate both with BTSs. This
statement is a gross oversimplification of the algorithm/software actually required to real-
1. Honoring this simple rule gets us past J-STD-008 section 2.6.6.2.5.2 and IS-95A section 6.6.6.2.5.2 which
specifies rules for transmitting T_COMP event information to the infrastructure.
Page 191 of 208

ize such a capability. The pre-processing portions of the algorithm are shown in Figure
#11 below as a process flow. Note that the entire flow need not be executed for all
events. For example, a simple single pilot drop event or a BTS with only one connection
need not invoke any Ec/Io sorting or any BTS Associations.
Figure #37. Handoff Pre-processing Example
BTS Associations with

PSMM Event Discrimination associated Handoff Events
Parallel Activity?
Ec/Io Sorting (Candidate Set) Ec/Io Sorting (Active Set)
Handoff
Decision
In terms of detection, Figure #10 can be expanded to yield the following criteria require-
ments:
• Single pilot drop.
• Single pilot add.
• Multiple pilot add (same BTS only).
• Multiple pilot drop (same BTS only).
• Softer Shuffle.
• Soft Shuffle.
• Cell Swap.
Finally, three algorithms are presented here. Algorithm #1 is extremely complicated.
Algorithm #2 is insensitive to soft versus softer connections. Algorithm #3 requires some
of the logic of Algorithm #1 but strives to minimize the active set via a form of “diversity”
calculation utilizing the information in each Pilot Strength Measurement Message.
Algorithm #1
Algorithm #1 is an intentionally complicated algorithm where a “superstructure” makes
decisions regarding add/drop/null events and then calls various sub-procedures (add,
drop, swap). The “superstructure” and sub-procedures are presented separately to
reduce visual complexity. Note the use of the “AddFlag”. If any “add” operations should
fail to produce a result, then any existing “drop” events in the PSMM will be honored. This
makes use of every opportunity to keep the active set “clean”. The algorithm also
assumes that Table #1 allows four BTS connections. The algorithms have also not been
reduced to their minimal logical expressions and may contain flaws at this point.
One point needs to be made with regard to the handoff “add” operation. It is the philoso-
phy of this document that new BTSs be added to a call instead of additional sectors at
existing servers in the case of multiple candidate pilots existing in a Pilot Strength Mea-
surement Message. The idea here is that the macrodiversity benefit to the call might be
Page 192 of 208

of more value than additional softer handoff legs due to high probability of decorrelated
shadowing between sites.
SuperStructure:
Perform Event Discrimination
For (i=0; i<All Candidate Set Pilots; i++)
If ( Candidate Ec/Io i > T_ADD )
Then CandidateScreened i = Candidate i
Endif
Endfor
Sort T_COMPPrime Pilot
Sort and count Drop pilot(s)
Sort and count candidate set pilot(s)
Sort and count T_COMP pilot(s)
Sort and count Add pilot(s)
AddFlag = 0
DropFlag = 0
N
Set #BTS = ∑ Active BTSi
i=1
If (((Event == ADD) || (Event == T_COMP) || (Event == T_COMPPrime)) && (#BTS == 3))
If ( Best Candidate Set Pilot ∉ Current Serving BTSs )
Then Call Cell Swap
Else
If ( Best Candidate Set Pilot ∈ Current Serving BTSs )
If ((active_set_size == 6) && (Candidate BTS currently at Table#1_Constraint))
Then Call Soft Shuffle
Else If ((active_set_size < 6) && (Candidate BTS currently at Table#1_Constraint))
Call Softer Shuffle
Else Call Add
Endif
Endif
Endif
Endif
If (AddFlag = 0)
If (((Event == ADD) || (Event == T_COMP) || (Event == T_COMPPrime)) && (#BTS < 3))
If (active_set_size < 6)
Then Call Add
Else Call Soft Shuffle1
Endif
Endif
Endif
If ((AddFlag == 0) && (DropFlag == 0) && (T_DROP Event))
Then Call Drop
End
1. This call should handle the situation of 2 BTSs with 3 forward links each. The other 2 BTS situation with
4 links and 2 links is not allowed given Table #1.
Page 193 of 208

Drop: The following is an example of a simple “drop” event where single or multiple
NoKeep1 pilots are involved. The precedence is to always try to drop an entire BTS worth
of forward links, then all NoKeep pilots, and finally a single pilot. Unfortunately, it is the
latter case that will occur with the greatest frequency. Note that this loop causes no shuf-
fling:
If (#Drop Events in PSMM > 1)
Count NoKeep Pilots per BTS
Sort Count
Find BTS with greatest count
If (All NoKeep Pilots In Same BTS)
If (Ec/Io of any NoKeep Pilot > Ec/Io of all Keep Act Pilot at same BTS)
If (#BTS > 1)
Then Drop ALL pilots at BTS
Else If (#BTS == 1)
If (# of Keep Act Pilots >= 1)
Then Drop all NoKeep pilots at BTS
Else
Drop weakest2 NoKeep pilot at BTS
Endif
DropFlag = 1
Endif
Else If (Ec/Io of any NoKeep Pilot ! > Ec/Io of all Keep Act Pilot at same BTS)
If (#BTS > 1)
DropFlag = 1
Endif
Endif
Else If (NoKeep Pilots Distributed Amongst Multiple BTSs)
If (Ec/Io of any NoKeep Pilot > Ec/Io of all Keep Act Pilot at same BTS)
Else Drop weakest (by Ec/Io) NoKeep pilot
Endif
DropFlag = 1
Endif
Endif
Else If ((#Drop Events in PSMM == 1) && (#Active_Pilots > 1))
If (Ec/Io of any NoKeep Pilot > Ec/Io of any Keep Act Pilot at same BTS)
If (#BTS > 1)
Then Drop ALL pilots at BTS
Endif
Else
Drop only NoKeep pilot
Endif
DropFlag = 1
Endif
1. “NoKeep” pilots are active set pilots represented in the Pilot Strength Measurement Message with keep
flag set to zero.
2. This is obviously an unfortunate situation to find ourselves in.
Page 194 of 208

Add: The following is an example of a simple “add” event where single or multiple candi-
date set pilots1 are involved. Note that this loop causes no shuffling. Also, the word “can-
didate” is underlined everywhere to draw attention to singular and plural forms. In the
case of adding multiple forward links from a new BTS, all candidate pilot Ec/Io associated
with that BTS must satisfy the composite2 T_ADD criteria in order to be added (i.e. a
form of pilot dominance):
Rank order pilot Ec/Io
If (#Candidates in PSMM > 1){
If (All Candidates in same BTS){
If (BTS == OLD_BTS){
Then add all candidates at OLD_BTS above composite T_ADD .AND. per Table#1_Constraint3 .AND.
such that #Actives < 7.
AddFlag = 1
Else If (BTS == NEW_BTS){
Then add all candidates at NEW_BTS above composite T_ADD .AND. per
Table#1_Constraint4 .AND. such that #Actives < 7.
AddFlag = 1
Endif
Endif
Else If (Candidates distributed over multiple BTSs){
If (BTS == NEW_BTS){
Then add all candidates at NEW_BTS above composite T_ADD .AND. per
Table#1_Constraint5 .AND. such that #Actives < 7.
AddFlag = 1
Else If (BTS == OLD_BTS){
If (#Candidates < Table#1_Constraint6)
Then add strongest candidate in PSMM.
AddFlag = 1
Endif
Endif
Endif
Else If (#Candidates in PSMM == 1){
If (BTS == OLD_BTS){
Then add candidate per Table#1_Constraint7
AddFlag = 1
Else If (BTS == NEW_BTS){
Else add candidate
AddFlag = 1
Endif
1. The probability of this occurring is probably higher than that of seeing multiple NoKeep pilots since
handoff add operations might be deferred in favor of drops/swaps/T_COMP events.
2. By this we mean the T_ADD value chosen by the MM algorithm that merges handoff parameters during
soft handoff operations.
3. Table constraint exception allowed under T_COMPPrime conditions.
Page 195 of 208

Endif
Endif
Softer Shuffle: The following is an example of testing for the Softer Shuffling criteria and
choosing a pilot to drop.
If (T_COMPPrime Event){
If (NoKeep pilots exist for this BTS)
Then drop all NoKeep pilots at this BTS
Else drop weakest pilot associated with this BTS.
Endif
Else
N
Calculate σ BTS = ∑ Ec/Ioi
i=1
If ( ( Candidate Ec/Io > σ BTS ) ) || (T_COMP Event)){
Endif
Endif
Endif
Soft Shuffle: The following is an example of testing for the Soft Shuffling criteria and
choosing a pilot to drop.
If (T_COMP Event on OLD_BTS){
Find weakest pilot on other 2 BTSs.
Endif
Else If (T_ADD Event on OLD_BTS){
N
Calculate σ BTS = ∑ Ec/Ioi for other 2 BTSs.
i=1
Sort to find σ Weakest BTS
If ( Candidate Ec/Io > σ Weakest BTS ) {
If (NoKeep pilots exist at σ Weakest BTS )
Then drop all NoKeep pilots at σ Weakest BTS
Else drop weakest pilot associated with σ Weakest BTS .
Endif
Endif
Endif
Cell Swap: The following is an example of testing for the Cell Swap criteria and choosing
a BTS to drop.
N
Calculate σ BTS = ∑ Ec/Ioi for all legs of all 3current BTSs.
i=1
Page 196 of 208

N
Calculate σ Cand = ∑ Ec/IoCand for all candidate set pilots at new BTSs1
i=1
Rank order σ Cand
Set σ Strongest Cand BTS from all σ Cand
Rank order σ BTS
Set σ Weakest BTS from all σ BTS
If (T_COMPPrime Event){
Drop all pilots at σ Weakest BTS
DropFlag = 1
Else If (T_ADD Event or Other T_COMP Event){
If ( σ Strongest Cand BTS > σ Weakest BTS ) {
Drop all pilots at σ Weakest BTS
DropFlag = 1
Endif
Endif
Non-Dominant PN or “Poor Coverage”: An algorithm extension to those shown above

would suppress softer shuffling, soft shuffling, or cell swapping under conditions of non-
dominant PN. The justification for this is that the shuffling/swapping procedures “expose”
the subscriber unit to unnecessary risk on the forward link as the number of available for-
ward links goes from N to (N-M) during the “drop” portion of the shuffle/swap. This is
more “true” in the cell swap case as cell swapping has the possibility of dropping several
forward links in one simultaneous procedure. One could argue that soft and softer shuffle
have less inherent risk than a cell swap.
A simple technique to limit cell swapping under conditions of non-dominant PN would be
to alter the trigger criteria (shown above) to eliminate T_ADD and T_COMP events.
Thus, the algorithm would only trigger on T_COMPPrime events and honor Simple Rule
#2. The disadvantage here is probably just a small capacity hit from having non-optimal
BTS connections (due to the lack of the T_ADD and T_COMP triggers) in areas of domi-
nant PN.
Another simple technique to limit cell swapping under conditions of non-dominant PN
would be to alter the values depicted in Appendix A to make cell swapping more difficult
as a function of decreasing σBTS . The problem here is in deciding on a scaling factor. The
problem is further compounded by noting that the algorithm will probably need to exist
during an epoch when subscriber manufacturers go from the QC ASIC to proprietary
designs that possibly support more than 3 demodulators. This has the effect of making it
difficult to decide on appropriate values of σBTS to use as forward link sensitivity is greatly
affected by the diversity available2.
1. This should handle the situation where a call is already engaged with 3 BTSs and candidate set pilots
appear for more than one new BTS.
2. In fact, we don’t even have forward link FER data available for anything beyond 3 demodulators.
Page 197 of 208

Algorithm #2
Algorithm #2 is much simpler than algorithm #1 in that it is insensitive to issues of soft
shuffling, softer shuffling, cell swapping, or non-dominant PN. The algorithm merely
examines each Pilot Strength Measurement Message received and makes add/drop
decisions based on the contents. There is also no concurrent add/drop of softer links. A
limit is placed such that only 3 BTS are used no matter how many forward links are in
SHO (just as in Algorithm #1). Fast Pilot Shuffling works in the same fashion as it does
today, with the only modification being that it triggers with 6 forward links instead of 3 for-
ward links and triggers with 3 BTSs in the presence of a 4th BTS candidate.
The advantage of Algorithm #2 is pure reduction in development effort making an R8 tar-
get date more “achievable”. There is certainly much smaller development associated with
error legs in this case. The disadvantage of Algorithm #2 is lack of handoff suppression
features (particularly cell swapping). It might be that the only way to achieve algorithm #1
would be to code algorithm #2 into release R8 and then “evolve” it into algorithm #1 in
release R9.
Algorithm #3
The suggestion has been made that the table in Appendix A be used to calculate a “com-
bined” Ec/Io value for the contents of every Pilot Strength Measurement Message using
both active and candidate set pilots and then using this value in a comparison function
with a target threshold. The algorithm would strive to add those candidates that assist in
achieving the threshold and dropping those active set pilots that do not. The goal of such
an algorithm is simplification wrt to Algorithm #1. Several points can be made:
• An algorithm of this type would possibly end up being insensitive to soft vs. softer connections and would not
favor the adding of softer legs over cell swapping as Algorithm #1 does.
• Some form of cell swapping (and decision criteria) would still be required.
• Choosing the target combined Ec/Io would be a subject of debate. Witness the variety Ec/Io and TCH Eb/No
required to reach 1% FER as a function of vehicle speed, delay spread, etc.
• Choosing the target combined Ec/Io makes the algorithm insensitive to TCH Eb/No. Note that our forward power
control algorithm changes gain as a function of the number of forward TCHs involved in the soft handoff. This
would require a combined Ec/Io threshold that is a function of soft handoff.
• Choosing the target combined Ec/Io would be further complicated by differences in RS1 and RS2 forward channel
performance. This might become especially vexing in a mixed vocoder system.
• As with Pilot Dominance, optimization choice is taken away from the field technician and instead, vested in the
algorithm. While this is prudent approach the vast majority of the time, we will probably be presented with some
number of situations where a number of handoff “knobs” will be useful.
Algorithm Summary (Algorithm #1 Specific)

As you can see, there’s a need for “add detection” and “drop target” algorithms at the
MM. This is merely an extension of algorithms implemented today with FPS. In other
words, you need to be able to detect a condition that would cause a shuffle or swap and
then decide on which pilot(s) to add. Since cell swapping is now the dominant feature
Page 198 of 208

that will put us at a disadvantage on the forward link (no availability of full N-way or full
complex), we make the following observations:
• Ec/Io values contained with Pilot Strength Measurement Messages are transient values present at the time the
message was sent. Care must be taken to develop confidence in these values as swap/shuffle triggers.
• Choice(s) of drop cells/pilots needs to be made with high confidence.
• Choice(s) of add cells/pilots needs to be made with high confidence. By this we mean that high confidence exists
that the cell(s) to be added will out-perform the cell(s) dropped.
• A mechanism needs to be implemented to ensure that a PSMM containing “add” information will be available
upon termination of the “drop” portion of any swap/shuffle operation.
What is not so obvious is the criteria for cell swap detection or pilot shuffling. Many have
made the observation wrt the FPS feature that we tend to perform an excessive number
of handoff operations, more so than is necessary to support the call. This is probably a
function of the secondary criteria for pilot shuffling that the candidate set pilot have stron-
ger Ec/Io than 2 out of 3 active set pilots. For Cell Swapping, we intend to put in place a
more rigorous criteria and attempt to reduce the amount of falsing associated with shuf-
fling/swapping. Appendix A shows a an Ec/Io Conversion look-up table composed of
integers that correspond to the Ec/Io values contained in a Pilot Strength Measurement
Message.The purpose of this table is to provide an integer-based means for dealing with
Ec/Io values without having to implement floating-point arithmetic (costly). There is also
some execution time savings in using a look-up table technique.
The table in Appendix A is used as input to the Cell Swapping algorithm.
• Each active set pilot Ec/Io in the Handoff Request Message is used to lookup the corresponding absolute value.
• Each candidate set pilot Ec/Io in the Handoff Request Message is used to lookup the corresponding absolute
value.
It should be noted that, with the inclusion of mechanisms to perform multiple simulta-
neous softer adds and softer drops, that the Cell Swapping is really no worse than the
current FPS algorithm while providing the benefits of more than 3 forward links.
Nature of Ec/Io Values in Pilot Strength Measurement Messages

The Ec/Io measurement made by the subscriber unit places Ec both in the numerator
and the denominator. Thus, when is Ec is large, and all other interference sources are
small (i.e. Ec >> Io), the Ec/Io ratio exhibits relatively small variance. When Ec is small
relative to Io (i.e. Io > Ec), the variance of the Ec/Io ratio increases and more of the fading
attenuation can be seen in the measurement. Thus, confidence in static, forward link
SNR for a subscriber unit wrt any given pilot measurement is a function of that measure-
ment. In addition, it seems realistic to expect that the stationarity of the Ec/Io frequency/
density function is only short in time duration for most subscriber cases and dependent
on the time rate of change of the pathloss.
Page 199 of 208

Figure #38. Ec/Io Confidence
Ec/Io
Measurement Increasing
Confidence
-3
-4
-5
-6
-7
-8
-9
-10
-11
-12
-13
-14
-15
-16
-17
-18
.
. Decreasing
. Confidence
The main point in the discussion above is one of having high confidence in Cell Swap
and Pilot Dominance operations. Both of these have high risk associated with them such
that triggers for both and ultimate active set composition decisions need either a lot more
study or sufficient parameterization such that we can “parameterize our way out of a
jam”. Figure #13 below shows select Ec/Io frequency distributions for the simple case1 of
ζ1 ⋅ E c
E c ⁄ I o = ------------------------------------------
- as an example of the variation of Ec/Io as a function of ambient
ζ 1 ⋅ E c + N Thermal
noise where the scaler ζ1 represents the fast fading process. This should reinforce the
notion in Figure #12 by asking to what distribution the value of -13 dB Ec/Io returned in a
Pilot Strength Measurement Message would be assigned2. Note that in this example the
9 dB and 15 dB Nth/Ec distributions overlap. The situation is further complicated by not-
ing that the above equation is extremely simplistic and that additional terms in the
denominator are present for increasing numbers of cells3.
1. NThermal is usually a gaussian random variate but is held constant in this experiment.
2. This observation has broad implications for target selection in DAHO deployments as well as possibly
influencing the soft handoff model in the CDMA Static Simulation.
3. For the sake of this simple demonstration, I choose to exclude delay spread, traffic channel energies, ener-
gies from interfering systems, paging and synchronization channel energies, etc.
Page 200 of 208

Figure #39. Example of Single Pilot Ec/Io as a function of Nth/Ec.
Single Pilot Ec/Io Frequency Distributions

(Thermal Noise relative to Ec, N=5000, 100 Hz, 0.02 Sampling)
20
0 dB
15 dB
9 dB
BJM 05/07/97
15
% of distribution 10
0
-25 -20 -15 -10 -5 0
Ec/Io dB
In general, the sum of several independent random variables (e.g. non-correlated fading
from several cells/sectors) should sum Var ( X 1 + X 2 + … + X N ) = Var ( X 1 ) + Var ( X 2 ) + … + Var ( X N ) .
These random variables actually make up the Io portion of the measurement and each
random variable has a scaling factor attributed to it’s transmission loss wrt the subscriber
unit. Thus, we would expect the variance of any Ec/Io measurement to increase as the
number of cells with “detectable” Ec increases1. Figure #14 below depicts a continuation
of the above simple experiment extended to 2 and 3 Ec values. This time, the graph is
drawn as a function of NTh/Ec.
The conclusion to be drawn is that any Ec/Io value represented in a single Pilot Strength
Measurement Message is probably a poor estimator of E[Ec/Io] (or SNR). This may be
why the Korean manufacturers have implemented their Pilot Dominance algorithm(s)
with periodic Power Measurement Report Message reporting. They have essentially
moved the filtering process for active set pilot drops (pre-empting the T_DROP/
T_TDROP process) out of the subscriber unit and into the infrastructure.
1. Of course, at some point excessive transmission loss renders the variance of any particular Ec irrelevant.
Page 201 of 208

Figure #40. Example Ec/Io variance as a function of number of pilot signals (all at equal transmission loss)
Ec/Io Variance as a function of Nth/Ec

and number of pilots (Ioc)
6
One Pilot
Two Pilots
5.5 Three Pilots
4.5
VAR(Ec/Io) dB
3.5
BJM 05/08/97
2.5
0 2 4 6 8 10 12 14 16
Nth/Ec dB
and Nth/Ec.
Also, provide diagram of subscriber combining. Should have a picture with basic SHO
theory and how you really want to make sure a pilot is dead before you take it out of the
active set. “When one pilot fades, the other pilot(s) get better!”.
Proposed (Simple) Algorithm Extensions for Pilot Dominance

While Pilot Dominance algorithms seek to maintain the minimum number of forward
links1, most of the work would be similar to algorithm #2 with additional parameters.
Obviously, Pilot Dominance would be optimized under conditions of Full Complex SHO
(which is not available).
It should be noted that adjusting handoff parameters is an indirect way of applying Pilot
Dominance. Adjusting the T_ADD parameter for higher Ec/Io values limits the usage of
the candidate set. Higher values of T_DROP and lower values of T_TDROP also limit the
candidate set size as well as “trimming” the active set.
1. Does Pilot Dominance also seek to optimize the reverse link?
Page 202 of 208

One possible extension to the algorithms proposed above to include minimizing the
active set size would be to drop all connections from a BTS in the event of T_TDROP
timer expiry and associated pilot Ec/Io being greater than all other pilot Ec/Io’s from that
same BTS (as represented in the same Pilot Strength Measurement Message). Note
that this proposal relies only on the ability to simultaneously drop all connections from a
BTS and does not rely on complex operations of the sort that produce simultaneous add
and drop operations. Note also that the MM would have to be cognizant of how many
pilots remain in the active set (under the assumption that the procedure would be suc-
cessful) and ensure that at least one active set pilot remains at the end of each proce-
dure execution.
In the case of adding multiple forward links, either for a new BTS or for an existing BTS,
the convention of only adding those candidates whose Ec/Io value in the current Pilot
Strength Measurement Message helps to limit the number of forward transmitters.
Another possible extension for Pilot Dominance would be to limit the amount of softer
handoff used by a subscriber unit as a function of the number of BTS connections. This
assumes that the primary mechanism by which forward links are added remains the sim-
ple T_ADD event. An example is given in the table below. This technique also serves the
function of keeping “open” active set slots for an emergency handoff situation. However,
Note that imposing constraints on the maximum number of softer handoff connections
allowed from a single BTS might cause us to perform more softer shuffling, etc.
Table #5.) Softer Handoff Inhibit for Pilot Dominance
Maximum Number of
Number of BTSs
Softer Connections
Involved in Soft
Allowed from One
Handoff
BTS
1 4a
2 3
3 2
a. Pending confirmation that current Channel Element
tracking algorithms can handle four simultaneous sec-
tors’ worth of activity.
Notes:
Argument for Pilot Dominance is expected loads on HK and PrimeCo by the time R8 hits.
How to play this off against QC proposal?
We are now implementing the opposite of handoff detection and target selection by
detecting when a pilot has gone bad and deciding how/whether to swap out.
Page 203 of 208

Do MCCx8 and MCCx24 really have full reverse link diversity, or is it only limited to trans-
mit sectors? Will?
Might have to send PMROs in those situations where the spec. precludes additional
transmission of PSMM.
Charles Nicoll idea! Vary soft handoff parameters as a function of the number of legs in
soft/softer handoff.
Page 204 of 208

Appendix A: Ec/Io Conversion Table
Ec/Io Actual
Absolute Value
Reported in Ec/Io
Function (Integer)
PSMM dB
0 0 15848
1 -0.5 14125
2 -1 12589
3 -1.5 11220
4 -2 10000
5 -2.5 8912
6 -3 7943
7 -3.5 7079
8 -4 6309
9 -4.5 5623
10 -5 5011
11 -5.5 4466
12 -6 3981
13 -6.5 3548
14 -7 3162
15 -7.5 2818
16 -8 2511
17 -8.5 2238
18 -9 1995
19 -9.5 1778
20 -10 1584
21 -10.5 1412
Page 205 of 208

Ec/Io Actual
Absolute Value
Reported in Ec/Io
Function (Integer)
PSMM dB
22 -11 1258
23 -11.5 1122
24 -12 1000
25 -12.5 891
26 -13 794
27 -13.5 707
28 -14 630
29 -14.5 562
30 -15 501
31 -15.5 446
32 -16 398
33 -16.5 354
34 -17 316
35 -17.5 281
36 -18 251
37 -18.5 223
38 -19 199
39 -19.5 177
40 -20 158
41 -20.5 141
42 -21 125
43 -21.5 112
44 -22 100
45 -22.5 89
Page 206 of 208

Ec/Io Actual
Absolute Value
Reported in Ec/Io
Function (Integer)
PSMM dB
46 -23 79
47 -23.5 70
48 -24 63
49 -24.5 56
50 -25 50
51 -25.5 44
52 -26 39
53 -26.5 35
54 -27 31
55 -27.5 28
56 -28 25
57 -28.5 22
58 -29 19
59 -29.5 17
60 -30 15
61 -30.5 14
62 -31 12
63 -31.5 11
64 -32 10
Page 207 of 208

Appendix B: Qualcomm Subscriber Unit Pilot Dominance Quick Summary

Qualcomm is proposing a modification to the current J-STD-008 and IS-95 rules for
transmission of Pilot Strength Measurement Messages. The technique forces the sub-
scriber unit to perform summation operations on active set SNR values and use those as
a basis for comparison with candidate set SNRs on and individual candidate set pilot
basis. In addition, the proposal also contains a point-slope inequality (depicted below)
with y-intercept and slope parameters under control of the infrastructure. This technique
should result in reduced PSMM messaging by the subscriber unit. It should also result in
reduced soft handoff factor under judicious selection of the aforementioned parameters1.
Note also that Qualcomm probably does not use the term “Pilot Dominance” to describer
the benefits provided by this proposal.
Candidate SNR
Send
PSMM
Do Not
Send
PSMM
N
∑ ActiveSet_SNRi
i=1
1. Obviously there’s trade-offs between forward link capacity and the integrity of the forward link.
Page 208 of 208

7.3 Umbrella Cell

John Toone slides from April ‘97 PrimeCo TEM
Page 209 of 210

Page 210 of 210

7.4 Six Sector

Page 211 of 212

Page 212 of 212

7.5 DAHO optimization strategies

DAHO uses cell configuration information stored in the CBSC/BTS along with the sys-
tem’s knowledge of which cells/sectors control a particular call.
Triggers on Active Set information from the last PSMM
Uses strongest Active Set pilot
Best trigger is two-way to one-way drop
Worst trigger is the completion of a pilot shuffle
From Dan Declerck’s taxonomy:
Database Assisted handoff (DAHO) is a hard handoff triggered by the active set of the
mobile station being comprised of a majority of sectors on a seam. It is triggered by the
TADD event of adding a pilot on the seam, or TDROP of a pilot not on the seam, where a
majority of the remaining pilots in the active set are on the seam. DAHO suffers from the
largesse required to deploy it. Typically, two rows of base stations outside the frequency
coverage area are required to handle all combinations of soft-handoff to trigger the hard
handoff. This is due to the TADD nature of DAHO, where the mobile biases the adding of
a pilot over the dropping of a pilot, due to the hysteresis of TTDROP used in soft/softer
handoff. This is illustrated in Figure 1. All DAHO marked sectors would include all neigh-
bor PN’s of Cells 1, 2, and 3. All DAHO sectors are indicated with a D.
Page 213 of 214

Two CDMA Carrier Domain
D D D
DD D D D D DD
D D D D
Cell 1 Cell 2 Cell 3
Single, Primary CDMA carrier domain

Figure 1
Page 214 of 214

7.6 Back To Back Antennas
Page 215 of 216

Page 216 of 216

7.7 Mobile Specification Changes

from Dan DeClerck’s taxonomy:
This technique basically involves the mobile station vacating the traffic channel for a
period of time to visit other frequencies to scan for pilots. This method will inherently
degrade speech quality for the period the mobile is scanning other pilots.
Typically a DAHO technique would be employed to trigger the scan of adjacent frequen-
cies, as it would not be prudent to degrade the speech quality constantly when the mobile
is not on a frequency seam. The trigger for hard handoff would include the target pilot
channel being TCOMP higher in strength than all active set pilots.
The advantage of this method over the others, is that the mobile actually samples the target
environment and it is used as a criteria for triggering a handoff.
7.8 Nokia/Qualcomm contribution.
This contribution set allows the subscriber unit to vacate the traffic channel to scan
adjacent frequencies, with two methods somewhat similar in execution.The down-
side to this method is the inherent degradation of speech quality.
7.9 DeClerck/Ashley improvements.
Motorola’s improvement over this method utilizes the same traffic channel frame
formats, and improves speech quality by allowing the subsciber unit to vocode ahead
of time, and provide a more consistent scan of the RF spectrum.
from Dan DeClerck’s CDG IAT/ TR45.5 WG III trip report:
Presently there are three methods for using MAHO techniques for CDMA hard
handoff:
1. 1) a one-shot method, where the mobile does a single scan of the pilots/chan-
nels on other frequencies and returns with a report.
2. a periodic method, where the mobile does repeated scans at approximate inter-
vals specified by the base station, and reports when those scans indicate a hand-
off might be required.
The pre-quel to the scan, the base gives the the mobile it’s scan list, and the
mobile reports it’s ability as a total time to scan all elements in the list, as well as
the longest number of consecutive frames it will be away.
The base then can adjust the periodic interval the mobile is away
to scan the adjacent frequency(s).
3. a method where the mobile is hard-handed off, and if it fails, it can be optionally
told by the base to do a complete scan of all pilots in the list and report it’s results.
Page 217 of 218

Page 218 of 218

TITLE:
Enhancements for inter-frequency hard handoff
SOURCE:
Motorola Inc.
Dan DeClerck
847-632-4596
declrckd@cig.mot.com
ABSTRACT:
This contribution provides a proposal to enhance the inter-frequency hard
handoff in a way that speech quality is not degraded for inter-frequency
search intervals.
RECOMMENDATION:
That the group review the proposed changes to inter-frequency hard hand-
off procedure.
Notice
©1997 Motorola, Inc.
The information contained in this contribution is provided for the sole purpose of promoting discussion
within the TIA and is not binding on the contributor. The contributor reserves the right to add to, amend
or withdraw the statements contained herein.
The contributor grants a free, irrevocable license to the Telecommunications Industry Association (TIA) to
incorporate text contained in this contribution and any modifications thereof in the creation of a TIA stan-
dards publication; to copyright in TIA's name any TIA standards publication even though it may include
portions of this contribution; and at TIA's sole discretion to permit others to reproduce in whole or in part
the resulting TIA standards publications.
The contributor may hold one or more patents or copyrights that cover information contained in this con-
tribution. A license will be made available to applicants under reasonable terms and conditions that are
demonstrably free of any unfair discrimination.
Nothing contained herein shall be construed as conferring by implication, estoppel, or otherwise any license
or right under any patent, whether or not the use of information herein necessarily employs an invention of
any existing or later issued patent, or copyright. The contributor reserves the right to use all material sub-
mitted in this contribution for their own purposes, including republication and distribution to others.
Page 219 of 222

Page 220 of 222

Introduction
The proposals that are currently being considered for inter-frequency hard handoff require a mo-
bile station to periodically scan adjacent CDMA channels for an indeterminate period of time.
During this period of time, the voice quality will degrade substantially. This contribution propos-
es a mechanism that ensures preservation of a reasonable level of voice quality by utilizing exist-
ing capabilities of IS-95 (such as Service Configuration and Negotiation). The contribution
utilizes the signaling method proposed by QUALCOMM.
Recommendations
Motorola proposes that the following key enablers for hard handoff be added to PN-3693:
1 .A mechanism (negotiated using Service Configuration procedure) that allows delaying the
sending of speech frames by 20 ms (one frame) and forcing the vocoder to the maximum cod-
ing rate of half-rate for two frames prior to an open frame. During the open frame, the mobile
station changes frequency to scan adjacent channels for stronger pilots. It indicates the re-
sult of the search to the base station, and the procedure for hard handoff continues as de-
scribed in other proposals. In a frame prior to the open frame (the frame where the mobile
station scans other frequencies), the base station and mobile station transmit two half-rate
frames in a single full-rate frame. Secondary Traffic is used for the second half-rate frame,
as allowed in IS-95. Such a mechanism should be negotiated when it is deemed necessary
by the base station, using Service Configuration and Negotiation procedure.
2.
3 .The base station should be allowed to specify the time-period between adjacent scanning pe-
riods. This gives the base station the flexibility in the trade-off between scan time and speech
degradation. This time period would be in frames, and would most likely be transmitted in
the Candidate Frequency Neighbor List Message (CFNLM) previously proposed.
4 .
5 .The specific frame used by the mobile station to scan adjacent frames may be derived using
a hash algorithm, similar to the one described in Section 6.6.7.1, with mobile stationõs ESN
as the HASH_KEY modulo divided by the number of frames in the scan period. The reason to
stagger the frames used is that this adjacent scanning method will probably be used in spe-
cific geographic regions, and that most of the mobile stations in this region would employ this
algorithm. Ensuring that all mobile stations do not vacate the traffic channel simultaneously
ensures a more uniform radio environment, similar to that of the traffic channel.
It is recommended that the above aspects be incorporated as part of an enhancement to the pro-
posal that is adopted for inter-frequency hard handoff.
Page 221 of 222

Page 222 of 222

7.10 Pilot Dominance
Page 223 of 224

Page 224 of 224

7.11 Complex Handoff
Page 225 of 226

Page 226 of 226

Page 227 of 264

Inter-CBSC Soft Handover 11/25/97 Digital Systems Division
Inter-CBSC Soft Handover
11/25/97
Digital Systems Division
Page 228 of 264

Cellular Infrastructure Group
Contents
❑ Introduction
❑ Architecture
❑ Call Processing
◗ HO Detection
◗ Procedures
◗ Inter-CBSC Trunk Group Resource Management
◗ Restrictions
◗ Example
❑ Operations and Maintenance

◗ Configuration Management
◗ Fault Management
➠ IC Trunk Group Mgmt.
➠ IC Link Mgmt.
➠ Global Reset
◗ Performance Management
Supercell Arc
PDS - 229 of 264 MOTOROLA CONFIDENTIAL PROPRIETARY
Introduction: Intra-CBSC Soft Handoff

❑ Intra-CBSC Soft Handoff
◗ Support of multiple active legs between the MS and Base Station within a com
➠ Mobility Control
✓ Handoff Detection and Determination
✓ MS Power Control
✓ RF Resource Allocation
➠ Physical Connectivity
✓ Control Messaging between MM, XCDR and MCCce(s)
✓ Traffic Frame Delivery to MCCce(s) (via Strau) and MSC (TerCkts)
◗ Unable to support Soft Handoff across CBSC Boundaries
◗ Requires Hard Handoff to External CBSC
➠ MAHO via Pilot Beacon Configuration
➠ DAHO via Configuration Parameters
Hard Handoff Seam 2-1-1

Source 2-1-3
Target
(CBSC-1) 1-1-1 2-1-2
(CBSC-2)
2-2-3
Carrier A Carrier B
1-1-3 2-2-2
1-2-1 1-1-2 2-3-1 2-2-2 2-4-3
1-2-3 2-3-3 2-4-2
= Pilot Beacons
1-2-2 1-3-1 2-3-2 1-1-1 2-4-1
MS 1-3-3 2-5-3
1-3-2 2-5-2 = Xcsectors
1-4-1 3-1-1 2-6-1
1-4-3 3-1-3 2-6-3 = Internal
1-4-2 1-5-1 3-1-2 3-3-1 2-6-2 sectors
(first ring in)
1-5-3 3-3-3 = Internal
1-5-2 3-2-1 Target sectors
1-6-1 3-3-2
1-6-3 3-2-3 (CBSC-3) A-B-C = A: CBSC #,
1-6-2 3-2-2 Carrier C B: BTS #,
C: Sector #
Supercell Arc
Introduction: Inter-CBSC Soft Handoff

❑ Inter-CBSC Soft Handoff
◗ Support of multiple active legs between the MS and Base Station within a com
and across CBSC Boundaries.
➠ Eliminates need for Pilot Beacons
✓ Frees CDMA Spectrum
✓ Eliminates need to purchase Pilot Beacon Hardware (BTS Shelf, GLIs, MCCces, B
➠ Introduces a buffer zone between Intra-Carrier SHO and Hard Handoff
✓ Reduces Hard Handoff Ping-Ponging between CBSCs
➠ Supports Inter-CBSC SHO simultaneously with Multiple CBSCs/MSC
IC SHO Handoff Seam
Hard Handoff Seam (CBSC-1) Hard Handoff Seam (CBSC-2)

2-1-1
Source Target
2-1-3
(CBSC-1) 2-1-2
(CBSC-2)
1-1-1 2-2-3
Carrier A Carrier A
1-1-3 2-2-2
1-2-1 1-1-2 2-3-1 2-2-2 2-4-3
1-2-3 2-3-3 2-4-2
1-2-2 1-3-1 2-3-2 1-1-1 2-4-1
1-3-3 2-5-3
MS
1-3-2 2-5-2
= Xcsectors
1-4-1 3-1-1 2-6-1
1-4-3 3-1-3 2-6-3 = Internal
1-4-2 1-5-1 3-1-2 3-3-1 2-6-2 sectors
(first ring
1-5-3 3-3-3 = Internal
1-5-2 3-2-1
sectors
1-6-1 3-3-2
1-6-3 3-2-3 A-B-C = A: CBSC
1-6-2 3-2-2 Target B: BTS
(CBSC-3) C: Secto
Carrier A
Supercell Arc
ICBSC SHO: Architecture
ICBSC SHO: Architecture

❑ Strategy
◗ Inter-connect CBSCs (that may collaborate in SHO) via
dedicated trunks
➠ Control: Inter-CBSC resource allocation, power control, add/drop HO
execution
➠ Traffic: 16 kbps STRAU
◗ Backhaul soft handoff legs via inter-CBSC trunks
◗ Anchor handoff (non-data calls) when MS is established
(via SHO) in another CBSC
◗ Inter-CBSC Soft Handoff detection via standard CDMA
MAHO
◗ MSC (A+) not involved except for anchor handoff
❑ Terminology
◗ Source: Anchor CBSC containing transcoding, frame
selection, and terckt to MSC
◗ Target: CBSC providing soft(er) handoff legs -
backhauled to source via inter-CBSC trunks
MSC-1 MSC-2
CBSC-2
CBSC-1
CBSC-4
CBSC-5
CBSC-3
= Inter-CBSC Trunks
= Inter-CBSC Trunks (Complex-KeepSoft only)
= Existing PCM Trunks
Page 232 of 264

Architectural Premise: Scope
MSC = Voice
= Contr
OMC-R NFS,TCP-IP
AP
NEC-A / J7
RNMP / TCP-IP
MM XC XC
Scap/TCP-IP Scap / LAPD
CBSC
Scap / LAPD
BTS BTS BTS BTS
Supercell Arc
ICBSH SHO: Architecture
ICBSH SHO: Architecture
MSC
PSTN
TERCKT (PCM)
CBSC-1 (Full DS0) CBSC-2
MM-1 MM-2
Callproc1 MSCSPAN Callproc1
Src Call Target
S-1 T-1
MSCSPAN
XC-1 ICSRCHAN XC-2

MSI ICTRKGRP (16kbps subrate) MSI
FEP-1-1 XCDR XCDR FEP-2-1

M M
S S
I I
FEP-1-2 FEP-2-2
ICSPANs ICLINKs
(Full DS0)
M M
CPP S S CPP
GPROC I I GPROC
MSI MSI MSI MSI
BTS-1 BTS-2 BTS-202 BTS-201
MS
: BTS Control Links / FEP connections = Control Path Exte
omitted for clarity
= Voice Path Extens
= CP Control Extens
Page 234 of 264

Handoff Determination and Detection

❑ HO Detection
◗ Performed on Anchor CBSC
◗ Use of existing Handoff Detection Algorithms (TAdd,
TComp)
❑ Mobile Scans all Neighbor Candidates

◗ Neighbor Set Pilot:
➠ Prior to entering Inter-CBSC SHO
✓ Local Neighbors (internal sectors)
✓ Selective Remote Neighbors (Xcsectors)-Path into remote CBSC
is only via source Xcsector
➠ During Inter-CBSC SHO
✓ Local Neighbors (internal sectors)
✓ Selective Remote Neighbors (Xcsectors)
✓ Neighbor list of remote sector (including “external” neighbors to
target)
◗ MS updated with merged neighbor list and parameters
using current algorithms
➠ On Remote Add, backhaul additional DB Information
✓ Neighbor list of remote sector (including “external” neighbor
target)
✓ Search and power control parameters
◗ “Fast pilot shuffle” supported for remote/local leg
mixtures
Page 235 of 264

Handoff Determination and Detection IC SHO Entry

IC SHO Entry
❑ Adding IC SHO (Initial and Subsequent IC SHO
ADDs)
◗ MAHO Indication used to Select SHO Candidate (Remote
or Local)
◗ Database parameter at IC Trunk Group level
(HOOverRide) specifies entry criteria
➠ No_Handoff
✓ Overrides XCSECTOR Handoff Method specification
(HandOffMeth)
✓ No Hard or Soft Handoffs allowed to remote CBSC.
➠ Hard
✓ Overrides XCSECTOR Handoff Method specification
(HandOffMeth)
✓ Inhibits IC SHO, new Active Leg added via Hard Handoff
(Must pass current Inter-CBSC Hard Handoff checks)
➠ No_OVERRIDE
✓ Use XCSECTOR Handoff Method specification
(HandOffMeth)None
◗ Database parameter at XCSECTOR level (HandOffMeth)
➠ None
✓ No Handoff Performed
➠ Hard
✓ Perform Hard Handoff
➠ Soft_Trunking
✓ Attempt IC SHO, could override via IC Trunk Group: HOOverRide
Setting
Page 236 of 264

Handoff Determination and Detection IC SHO Exit Criteria

IC SHO Exit Criteria
◗ Checked at completion of ADD or DROP Operation
✓ Fast Pilot Shuffling viewed as atomic operation
◗ Active Calls: Database parameter at source CBSC level
(AnchorHoMeth) controls exiting criteria
➠ “Legs_Remote”
✓ No HO legs are in source CBSC (NOTE: multiple targets may be
involved)
✓ No HO legs are “known” (i.e., correspond to an Xcsector) to the
source
✓ Hard handoff is not otherwise blocked (e.g., data call)
➠ “No_Legs”
✓ No HO legs are in source CBSC (NOTE: multiple targets may be
involved)
✓ Hard handoff is not otherwise blocked (e.g., data call)
➠ “Keep_Soft” (Simple)
✓ Support call with only MAHO backhauled information
◗ Anchor Handoff for Active Calls
➠ Leg with best signal strength (Ec/Io) is chosen for hard-handoff
candidate
➠ Conventional CDMA-to-CDMA hard handoff employed
◗ IC Target Failure
➠ Failure in Target Side Procedure
✓ Results in Call Teardown
◗ MS Re-enters Anchor CBSC
➠ No Remaining Active Legs on Target CBSC
◗ Call Release
➠ Normal Call Release (e.g., Land Release) or Abnormal Call Release
(e.g., Drop Call)
Page 237 of 264

ICBSC SHO: Call Processing - SHO Detection

2-1-1
Source 2-1-3 Target

2-1-2
(CBSC-1) 1-1-1 2-2-3 (CBSC-2)
1-1-3 2-2-2
1-2-1 1-1-2 2-3-1 2-2-2 2-4-3
1-2-3 2-3-3 2-4-2
1-2-2 1-3-1 2-3-2 1-1-1 2-4-1
1-3-3 1 2-5-3
1-3-2 2-5-2
= Xcsectors
1-4-1 3-1-1 2-6-1
1-4-3 3-1-3 2-6-3 = Internal
1-4-2 1-5-1 3-1-2 3-3-1 2-6-2 sectors
(first ring in)
1-5-3 3-3-3 = Internal
1-5-2 3-2-1
sectors
1-6-1 3-3-2
1-6-3 3-2-3 A-B-C = A: CBSC #,
1-6-2 3-2-2 Target B: BTS #,
(CBSC-3) C: Sector #
Neighbor Candidate List

Step Active Set (Assume: (1) sector’s neighbors are adjacent sectors and (2) ignore Comments
latent neighbor list from last drop)
1 1-3-1, 1-3-2 1-1-2, 1-3-3, 1-5-1, 2-3-3, 3-1-2 Initial Conditions
Supercell Arc

2-1-1
Source 2-1-3 Target

2-1-2
(CBSC-1) 1-1-1 2-2-3 (CBSC-2)
1-1-3 2-2-2
1-2-1 1-1-2 2-3-1 2-2-2 2-4-3
1-2-3 2-3-3 2-4-2
1-2-2 1-3-1 2 2-3-2 1-1-1 2-4-1
1-3-3 1 2-5-3
1-3-2 2-5-2
= Xcsectors
1-4-1 3-1-1 2-6-1
1-4-3 3-1-3 2-6-3 = Internal
1-4-2 1-5-1 3-1-2 3-3-1 2-6-2 sectors
(first ring in)
1-5-3 3-3-3 = Internal
1-5-2 3-2-1
sectors
1-6-1 3-3-2
1-6-3 3-2-3 A-B-C = A: CBSC #,
1-6-2 3-2-2 Target B: BTS #,

2 1-3-1, 1-3-2, 2-3-3 1-1-2, 1-3-3, 1-5-1, 2-3-1, 2-3-2, 3-1-3 Add 2-3-3
Supercell Arc

2-1-1
Source 2-1-3 Target

2-1-2
(CBSC-1) 1-1-1 2-2-3 (CBSC-2)
1-1-3 2-2-2
1-2-1 1-1-2 2-3-1 2-2-2 2-4-3
1-2-3 2-3-3 2-4-2
1-2-2 1-3-1 2 2-3-2 1-1-1 2-4-1
1-3-3 1 3 2-5-3
1-3-2 2-5-2
= Xcsectors
1-4-1 3-1-1 2-6-1
1-4-3 3-1-3 2-6-3 = Internal
1-4-2 1-5-1 3-1-2 3-3-1 2-6-2 sectors
(first ring in)
1-5-3 3-3-3 = Internal
1-5-2 3-2-1
sectors
1-6-1 3-3-2
1-6-3 3-2-3 A-B-C = A: CBSC #,
1-6-2 3-2-2 Target B: BTS #,

2 1-3-1, 1-3-2, 2-3-3 1-1-2, 1-3-3, 1-5-1, 2-3-1, 2-3-2, 3-1-3 Add 2-3-3
3 1-3-2, 2-3-3, 3-1-3 1-1-2, 1-3-1, 1-3-3, 1-5-1, 2-3-1, 2-3-2, 3-1-1, 3-1-2 Drop 1-3-1, Add 3-1-3
Supercell Arc

2-1-1
Source 2-1-3 Target

2-1-2
(CBSC-1) 1-1-1 2-2-3 (CBSC-2)
1-1-3 2-2-2
1-2-1 1-1-2 2-3-1 2-2-2 2-4-3
1-2-3 2-3-3 2-4-2
1-2-2 1-3-1 2 2-3-2 1-1-1 2-4-1
4
1-3-3 1 3 2-5-3
1-3-2 2-5-2
= Xcsectors
1-4-1 3-1-1 2-6-1
1-4-3 3-1-3 2-6-3 = Internal
1-4-2 1-5-1 3-1-2 3-3-1 2-6-2 sectors
(first ring in)
1-5-3 3-3-3 = Internal
1-5-2 3-2-1
sectors
1-6-1 3-3-2
1-6-3 3-2-3 A-B-C = A: CBSC #,
1-6-2 3-2-2 Target B: BTS #,

2 1-3-1, 1-3-2, 2-3-3 1-1-2, 1-3-3, 1-5-1, 2-3-1, 2-3-2, 3-1-3 Add 2-3-3
3 1-3-2, 2-3-3, 3-1-3 1-3-1, 1-3-3, 1-5-1, 2-3-1, 2-3-2, 3-1-1, 3-1-2 Drop 1-3-1, Add 3-1-3
4 2-3-2, 2-3-3, 3-1-3 1-1-2, 1-3-1, 1-3-2, 1-5-1, 2-3-1, 2-5-3, 3-1-1, 3-1-2 Drop 1-3-2, Add 2-3-2
Supercell Arc

2-1-1
Source 2-1-3 Target

2-1-2
(CBSC-1) 1-1-1 2-2-3 (CBSC-2)
1-1-3 2-2-2
1-2-1 1-1-2 2-3-1 2-2-2 2-4-3
1-2-3 2-3-3 2-4-2
1-2-2 1-3-1 2 2-3-2 2-5-1 2-4-1
4 5
1-3-3 1 3 2-5-3
1-3-2 2-5-2
= Xcsectors
1-4-1 3-1-1 2-6-1
1-4-3 3-1-3 2-6-3 = Internal
1-4-2 1-5-1 3-1-2 3-3-1 2-6-2 sectors
(first ring in)
1-5-3 3-3-3 = Internal
1-5-2 3-2-1
sectors
1-6-1 3-3-2
1-6-3 3-2-3 A-B-C = A: CBSC #,
1-6-2 3-2-2 Target B: BTS #,

2 1-3-1, 1-3-2, 2-3-3 1-1-2, 1-3-3, 1-5-1, 2-3-1, 2-3-2, 3-1-3 Add 2-3-3
3 1-3-2, 2-3-3, 3-1-3 1-3-1, 1-3-3, 1-5-1, 2-3-1, 2-3-2, 3-1-1, 3-1-2 Drop 1-3-1, Add 3-1-3
4 2-3-2, 2-3-3, 3-1-3 1-1-2, 1-3-1, 1-3-2, 1-5-1, 2-3-1, 2-5-3, 3-1-1, 3-1-2 Drop 1-3-2, Add 2-3-2
5 2-3-3, 2-3-2, 2-5-3 1-1-2, 1-3-1, 2-3-1, 2-5-1, 2-5-2 Drop 3-1-3, Add 2-5-3 (3-1-1 exclu
Supercell Arc

2-1-1
Source 2-1-3 Target

2-1-2
(CBSC-1) 1-1-1 2-2-3 (CBSC-2)
1-1-3 2-2-2
1-2-1 1-1-2 2-3-1 2-2-2 2-4-3
1-2-3 2-3-3 2-4-2
1-2-2 1-3-1 2 2-3-2 2-5-1 2-4-1
4 5 6
1-3-3 1 3 2-5-3
1-3-2 2-5-2
= Xcsectors
1-4-1 3-1-1 2-6-1
1-4-3 3-1-3 2-6-3 = Internal
1-4-2 1-5-1 3-1-2 3-3-1 2-6-2 sectors
(first ring in)
1-5-3 3-3-3 = Internal
1-5-2 3-2-1
sectors
1-6-1 3-3-2
1-6-3 3-2-3 A-B-C = A: CBSC #,
1-6-2 3-2-2 Target B: BTS #,

2 1-3-1, 1-3-2, 2-3-3 1-1-2, 1-3-3, 1-5-1, 2-3-1, 2-3-2, 3-1-3 Add 2-3-3
3 1-3-2, 2-3-3, 3-1-3 1-3-1, 1-3-3, 1-5-1, 2-3-1, 2-3-2, 3-1-1, 3-1-2 Drop 1-3-1, Add 3-1-3
4 2-3-2, 2-3-3, 3-1-3 1-1-2, 1-3-1, 1-3-2, 1-5-1, 2-3-1, 2-5-3, 3-1-1, 3-1-2 Drop 1-3-2, Add 2-3-2
5 2-3-3, 2-3-2, 2-5-3 1-1-2, 1-3-1, 2-3-1, 2-5-1, 2-5-2 Drop 3-1-3, Add 2-5-3 (3-1-1 exclu
6 2-3-2, 2-5-3 2-3-1, 2-3-2, 2-5-1, 2-5-2 Drop 2-3-3 (assume 2-5-3 has best E
Supercell Arc

2-1-1
Source 2-1-3 Target

2-1-2
(CBSC-1) 1-1-1 2-2-3 (CBSC-2)
1-1-3 2-2-2
1-2-1 1-1-2 2-3-1 2-2-2 2-4-3
1-2-3 2-3-3 2-4-2
1-2-2 1-3-1 2 2-3-2 2-5-1 2-4-1
4 5 67
1-3-3 1 3 2-5-3
1-3-2 2-5-2
= Xcsectors
1-4-1 3-1-1 2-6-1
1-4-3 3-1-3 2-6-3 = Internal
1-4-2 1-5-1 3-1-2 3-3-1 2-6-2 sectors
(first ring in)
1-5-3 3-3-3 = Internal
1-5-2 3-2-1
sectors
1-6-1 3-3-2
1-6-3 3-2-3 A-B-C = A: CBSC #,
1-6-2 3-2-2 Target B: BTS #,

2 1-3-1, 1-3-2, 2-3-3 1-1-2, 1-3-3, 1-5-1, 2-3-1, 2-3-2, 3-1-3 Add 2-3-3
3 1-3-2, 2-3-3, 3-1-3 1-3-1, 1-3-3, 1-5-1, 2-3-1, 2-3-2, 3-1-1, 3-1-2 Drop 1-3-1, Add 3-1-3
4 2-3-2, 2-3-3, 3-1-3 1-1-2, 1-3-1, 1-3-2, 1-5-1, 2-3-1, 2-5-3, 3-1-1, 3-1-2 Drop 1-3-2, Add 2-3-2
5 2-3-3, 2-3-2, 2-5-3 1-1-2, 1-3-1, 2-3-1, 2-5-1, 2-5-2 Drop 3-1-3, Add 2-5-3 (3-1-1 exclu
6 2-3-2, 2-5-3 2-3-1, 2-3-2, 2-5-1, 2-5-2 Drop 2-3-3 (assume 2-5-3 has best E
7 2-5-3 2-3-2, 2-5-1, 2-5-2, 3-1-1 Anchor Handoff to CBSC-2-5-3
Supercell Arc
ICBSC SHO: Call Processing - Procedure

❑ Orchestrated via Inter-CBSC SCAP Messaging (Approx. 20 new/mo
❑ Inter-CBSC Initial Soft Handoff Add
◗ Establish first Soft HO leg, for a given call, on a particular target CBSC
◗ Allocates Target MM, Target XC CPP GPROC, IC-SRCHAN, Target MCCce / TC
❑ Inter-CBSC Subsequent Soft/Softer Handoff Add

◗ Establish second or third Soft[er] HO legs, for a given call, on a particular ta
◗ Softer HO only requires allocation of target BTS TCHwc, (no IC-SRCHAN / ta
❑ Inter-CBSC Soft/Softer Handoff Drop

◗ Remove a remote Soft[er] HO leg, for a given call, from a particular target CB
◗ Soft HO drop deallocates IC-SRCHAN and target MCCce / TCHwc
◗ Softer HO drop deallocates target BTS TCHwc
❑ Inter-CBSC Disconnect
◗ Remove all target Soft[er] HO legs and Target State
➠ Deallocate Target XC CPP
➠ Deallocate Target BTS MCCce(s) and TCHwc(s)
➠ Deallocate IC-SRCHAN(s)
◗ Applies to Last Soft HO drop on Target and Call Release/Teardown
❑ Inter-CBSC Target Failure

◗ Indication from Target to Source of non-Recoverable Failure (e.g., Equipmen
◗ Results in Source-initiated Call Teardown
Supercell Arc
ICBSC SHO: Call Processing - Inter-CBSC Trunk Group Resource Mgmt.
ICBSC SHO: Call Processing - Inter-

CBSC Trunk Group Resource Mgmt.
❑ Single ICBSC Trunk Group Between two CBSCs
❑ Provisions for two-way trunks (recommended)
◗ A given IC-SRCHAN may be Allocated from either CBSC
◗ Simple “Opposite End” Allocation Policy
◗ Glare Hold/Release Arbitration Needed (CP Retry: Similar
to Handling of other Errors)
❑ Provisions for one-way trunks (fallback)

◗ All IC-SRCHANs in a given IC SPAN may only be Allocated
by one of the two CBSCs
◗ Allocation Policy may be “Opposite End” or “Round
Robin”
◗ Glare Hold/Release Arbitration Not Required
❑ Detection/Cleanup of IC-SRCHANs in Inconsistent

State
◗ Detect and Automatically Recover from “Hung” IC-
SRCHANs
➠ Stranded Target CBSC (MM and XC)
➠ Stranded XC State (connection, GPROC, etc.)
◗ When CP Detects IC-SRCHAN in Inconsistent State
➠ IC-SRCHAN is marked “Unavailable” (removed from future allocation
considerations)
➠ Source/Target CP Messaging will force IC-SRCHAN “Unavailable” on
Both CBSCs
➠ Source CBSC will Trigger Fault Management IC-SRCHAN “reset” to
recover IC-SRCHAN
Page 246 of 264

ICBSC SHO: Call Processing - Restrictions
ICBSC SHO: Call Processing - Restric-

tions
❑ Anchor Handoff Required (except data calls)
❑ SHO Adds may not be performed to “3rd Party”
CBSC sectors
❑ Hard Handoffs Blocked while Call is Configured in
Inter-CBSC SHO
◗ CDMA to Analog
◗ CDMA to CDMA (except for anchor handoff)
Page 247 of 264

ICBSC SHO: Call Processing - Initial Conditions
ICBSC SHO: Call Processing - Initial Con-

ditions
MSC
PSTN
TERCKT (PCM)
MM-1 MM-2
Src Call
S-1
MSCSPAN
XC-1 ICSRCHAN XC-2


M M
S S
I I
FEP-1-2 FEP-2-2
ICSPANs ICLINKs
(Full DS0)
M M
CPP S S CPP
GPROC I I GPROC
MSI MSI MSI MSI
MS
: BTS Control Links / FEP connections
omitted for clarity
Page 248 of 264

ICBSC SHO: Call Processing - Inter-CBSC Initial Soft Add

CBSC Initial Soft Add
MSC
PSTN
TERCKT (PCM)
MM-1 MM-2
Src Call Target
S-1 T-1
MSCSPAN
XC-1 ICSRCHAN XC-2


M M
S S
I I
FEP-1-2 FEP-2-2
ICSPANs ICLINKs
(Full DS0)
M M
CPP S S CPP
GPROC I I GPROC
MSI MSI MSI MSI
MS
omitted for clarity
Page 249 of 264

SRC_MM TRG_MM SRC_XC TRG_XC ALL_TCH TARG_TCH MS

[1] RF: Pilot Strength Measurement Message
CBSC Initial Soft Add Procedure

[Pilot strengths, Pilot phases, reference pilot strength & phase]
[2] ICP: CDMA Handoff Recognized [Soft Add]
ICBSC SHO: Call Processing - Inter-CBSC Initial Soft Add Procedure

[3] ICP: CDMA IC Initial Handoff Request
1. Detects initial IC SHO add event
Procedure Unique to Inter-CBSC SHO

2. Allocates an ICsrchan]

[4] ICP: CDMA IC Handoff Request Ack
1. Allocate Target Call Job

2. ICsrchan Update-Mark Busy
3. Allocate MCCce and TCHwc from BTS/Carrier
[5] ICP: CDMA XC Connect Call
1. Establish Target Inter-CBSC Path Connect

[6] ICP: CDMA XC Connect Call Ack
1. Path Connect Complete
1. Establish
[7] ICP: CDMA Source Inter-CBSC Path Connect
XC Direction
2. Add New Active Pilot
[8] ICP: CDMA Handoff Channel Assigned
[9] ICP: CDMA Forward Channel Transmission Indication

Page 250 of 264
[10] RF: Extended Handoff Direction Message
1. Inform mobile of new Active Set
[11] RF: Handoff Completion Message
[12] RF: Base Station Acknowledgment Order
[13] ICP: CDMA Handoff State Change

ICBSC SHO: Call Processing - Inter-CBSC Subsequent Softer Add

CBSC Subsequent Softer Add
MSC
PSTN
TERCKT (PCM)
MM-1 MM-2
Src Call Target
S-1 T-1
MSCSPAN
XC-1 ICSRCHAN XC-2


M M
S S
I I
FEP-1-2 FEP-2-2
ICSPANs ICLINKs
(Full DS0)
M M
CPP S S CPP
GPROC I I GPROC
MSI MSI MSI MSI
MS
omitted for clarity
Page 251 of 264

ICBSC SHO: Call Processing - Source Dropped, Target Dropped & Added
ICBSC SHO: Call Processing - Source

Dropped, Target Dropped & Added
MSC
PSTN
TERCKT (PCM)
MM-1 MM-2
Src Call Target
S-1 T-1
MSCSPAN
XC-1 ICSRCHAN XC-2


M M
S S
I I
FEP-1-2 FEP-2-2
ICSPANs ICLINKs
(Full DS0)
M M
CPP S S CPP
GPROC I I GPROC
MSI MSI MSI MSI
MS
omitted for clarity
Page 252 of 264

CBSC Initial Soft Last Drop Procedure
SRC_MM TRG_MM SRC_XC TRG_XC ALL_TCH TRG_TCH MS
ICBSC SHO: Call Processing - Inter-CBSC Initial Soft Last Drop Procedure
[1] RF: Pilot Strength Measurement Message
[Pilot strengths, Pilot phases, reference pilot strength & phase]
[2] ICP: CDMA Handoff Recognized [Soft Drop]
[3] ICP: CDMA XC Direction

1. Remove Inter-CBSC Path Connect
2. Remove Pilot from Active Pilot Set
[4] ICP: CDMA Handoff State Change
[5] RF: Extended Handoff Direction Message
[6] RF: Handoff Completion Message
[7] RF: Base Station Acknowledgment Order
[8] ICP: CDMA Handoff Successful#
[9] ICP: CDMA IC Disconnect
1. Detects remove of last pilot from Target CBSC

2. Initiates Last Drop procedure on Target CBSC
Page 253 of 264
[10] ICP: CDMA XC Disconnect Call
Procedure Unique to Inter-CBS

1. Disconnect Inter-CBSC Path Connect
2. Terminate XC Call Job
[11] Execute Radio Channel Release Procedure
[12] Radio Channel Release Procedure Complete
1. Deallocate BTS Resource

ICBSC SHO: Call Processing - Anchor Handoff (CBSC-1 to CBSC-2) Completed
ICBSC SHO: Call Processing - Anchor

Handoff
(CBSC-1 to CBSC-2) Completed
MSC
PSTN
TERCKT (PCM)
MM-1 MM-2
Source
S-2
MSCSPAN
XC-1 ICSRCHAN XC-2


M M
S S
I I
FEP-1-2 FEP-2-2
ICSPANs ICLINKs
(Full DS0)
M M
CPP S S CPP
GPROC I I GPROC
MSI MSI MSI MSI
MS
omitted for clarity
Page 254 of 264

ICBSC SHO: O&M - Configuration Managem

❑ Trunk Groups Named From CBSC Perspective
◗ A Single Trunk Group Typically will have Two Distinct Names
◗ A Single Trunk Group may have the Same Name only if:
➠ The involved CBSCs have the same ID
➠ The involved CBSCs belong to different OMC-R
◗ Child Devices (ICSPAN, ICSRCHAN, ICLINK) named Consistent with Trunk G
◗ Contained Devices must be Provisioned/Named Symmetrically on Endpoint
❑ Trunk Group Unique ID Unambiguously Identifies Trunk Group

◗ Must be Provisioned Identically on Endpoint CBSCs
◗ ICTRKGRPUid and ICSRCHAN low IDs (ICSPAN-ICDS0-ICSRCHAN) Exchang
CBSC-1
ICTRKGRP-1-2 ICTRKGRP-1-1
1 6
ICTRKGRP-4-1 ICTRKGRP-2-1
ICTRKGRP-1-3
CBSC-4 CBSC-2
4
ICTRKGRP-4-2 2 ICTRKGRP-2-2
ICTRKGRP-3-3
ICTRKGRP-4-3 CBSC-3 ICTRKGRP-2-3
3 5
# = ICTRKGRPUid ICTRKGRP-3-2 ICTRKGRP-3-1
Supercell Arc
LEGEND:
OMC
Required Assoc. when Provisioned
Optional Assoc. when Provisioned
Non-Parental Assoc. enforced FRAME Add/Del
MM
when deleting MMI DEFAULTS
CBSC
MIB only object Add/Del Add/Del OMCR
CBSC
Craft only object MMI
INROUTE
ICBSC SHO- Configuration Managemen
ICBSC SHO- Configuration Management Provisioning Hierarchy

OUTROUTE
Add/Del
SERVOPT MMXCLAN

Add/Del Add/Del
XASECT XCSECT SERVOPT
XASECT MSC
XCSECT CBSC
Provisioning Hierarchy
FEP(R)
MSI
NCON Add/Del
BTS SPAN
MSI
XCLINK Add/Del BTSSPAN
Add/Del
BTS BTS (CPP)
BTS BTSDS0
Add/Del XCLINK MSC SPAN
(OMP)
XCLINK Add/Del
Add/Del
SRCHAN
FRAME FEP MSCSPAN
CSM BTSLINK C7LINK TERCKT

SECTOR RFDS
Add/Del Add/Del Add/Del Add/Del
CSM C7LINK TERCKT
RGLI BTSLINK
Page 256 of 264
CARRIER Add/Del MDM

MDM Add/Del ICTRKGRP
GLI
GLI Add/Del
Add/Del
CARRIER ICTRKGRP
Add/Del
BBX(R)
BBX
BDC*
TCHwc Add/Del
MCC
Add MDM or MCC
ICSPAN
Add CSM MCCCE
Add/Del
ICLINK ICSPAN
ICBSC SHO: O&M Fault Management - ICLINK

❑ ICLINK is Fundamental Fault Managed Device
◗ Control-Traffic-Carrying ICLINKs Managed Active/Standby (INS_ACT, INS_SB
➠ First Two ICSPANs in ICTRKGRP Contain Control-Traffic-Carrying ICLINKs
➠ Links are Aligned such that both CBSCs “Agree” on Active/Standby Link Status
➠ Single/Symmetric Active Link Eliminates Message Ordering Issues
◗ ICLINKs on ICSPANs 3 - N are for Span Monitoring Purposes Only (INS, OOS
◗ Standard DSM Operations Supported (Enable, Disable, Cutover, Uncut)
◗ Link Changeover (Failure/Disable) is Automatic
❑ ICSPAN and Contained ICSRCHANs Managed via ICLINK

◗ Every ICSPAN must contain one and only one ICLINK for Span Monitoring
◗ Status of Span and Availability of its Resources (ICSRCHANs) Follows ICLIN
CBSC-1 ICTRKGRP-1-1 ICTRKGRP-2-1 CBSC-2

M M FEP-2-1-1
S ICSPAN-1-1-1 ACTIVE ICSPAN-2-1-1 S
FEP-1-1-1
I ICSPAN-1-1-1 ICSPAN-2-1-1 I
M M
S ICSPAN-1-1-2 STANDBY ICSPAN-2-1-2 S FEP-2-1-2
FEP-1-1-2 I ICSPAN-1-1-2 ICSPAN-2-1-2 I
M M
S ICSPAN-1-1-3 MONITOR ICSPAN-2-1-3 S FEP-2-1-3
ICSPAN-2-1-3
FEP-1-1-3
I ICSPAN-1-1-3 I
FEP-2-1-4
M M
S ICSPAN-1-1-N MONITOR ICSPAN-2-1-N S
I ICSPAN-1-1-N ICSPAN-2-1-N I
Supercell Arc
ICBSC SHO: O&M Fault Management - ICTRKGRP Mgmt.
ICBSC SHO: O&M Fault Management -

ICTRKGRP Mgmt.
❑ ICSRCHAN is the “allocatable” Resource Derived
from ICTRKGRP
❑ ICSRCHAN Status for ICSPAN Reported via
associated ICLINK Status
◗ Reports ICSRCHAN: INS/OOS
◗ Reports ICSRCHAN: BUSY/IDLE/CPUNAVAIL
❑ RESCHAN Command Supported to “Reset”

ICSRCHAN
◗ Coordinated by FM between both Affected CBSCs
◗ Attempts to Release Call Associated with ICSRCHAN via
CP Clearing
◗ Forces XC Cleanup of ICSRCHAN Connection
◗ Upon Success, Idles ICSRCHAN
❑ RESCHAN Processing may be Initiated by “source”

CBSC when ICSRCHAN inconsistency is detected
Page 258 of 264

ICBSC SHO: O&M Fault Management - ICSRCHAN Status Mapping

ICSRCHAN Status Mapping
❑ ICSRCHAN Display Status Mapping
ICSRCHAN ICSRCHAN Allo- ICSRCHAN FM ICSRCHAN
ICLINK Status Type
Inhibit Status cation Status Status Display Statu
OT_EQUIPPED - - - - not displaye
PRE_CUT - - - - PRE_CUT
OOS_MAN, NON-TRAFFIC - - - NONE
OOS_PAR, TRAFFIC INHIBITED - - PRE_CUT
OOS_AUTO, NOT INHIBITED IDLE CAMPON OOS
OOS_FLTD OOS OOS
NON-TRAFFIC - - - NONE
TRAFFIC INHIBITED - - PRE_CUT
NOT INHIBITED IDLE NULL INS_IDLE
INS_CMPN, CAMPON OOS_AUTO
S_ACT, INS_SBY, OOS OOS_AUTO
INS BUSY NULL INS_BUSY
CAMPON INS_CMPN
CPUNAVAIL NULL OOS_AUTO
CAMPON OOS_AUTO
Page 259 of 264

ICSRCHAN Status Command Example
ICBSC SHO: O&M Fault Management - ICSRCHAN Status Command Example

tomahawk9-010001 > status iclink-1-2-4 add
010001-00005 COMMAND ACCEPTED
ICLINK-1-2-4 97-05-26 07:49:02 tomahawk9 MM-1 D010001.00005 00057

INFO:3 “Command in Progress”

STATUS=STARTED
ICLINK-1-2-4 97-05-26 07:49:03 tomahawk9 MM-1 D010001.00005 00057
INFO:35 “ICLINK Status Response”
TELSTATE=INS PROCEDURE=NONE PHYSTATE=NONE
HDWRTYPE=None
DS0 SUBRATE 0 SUBRATE 1 SUBRATE 2 SUBRATE 3
--- --------- --------- --------- ---------
1 NONE NONE NONE NONE
2 NONE INS_IDLE INS_IDLE INS_IDLE
Page 260 of 264

ICBSC SHO: O&M Fault Management - Global Reset (MM callproc1 Restart)

Global Reset
(MM callproc1 Restart)
❑ Procedure Executed when MM callproc1 process
restarts
◗ Coordinated by Fault Mgmt. as a “Global Reset” /
Restarting CBSC controls
◗ Clear all local Call State and all remote Call State (source/
target) dependent upon local CBSC
1. callproc1 restarts
2. Restarting callproc1 blocks new traffic (Originations.
Terminations, Hard Handins, IC SHO Handins)
3. callproc1 informs FM of Restart
4.1 callproc1 cleans up internal resource state (Radio Chnl Release,
CPPs, TerCkts)
4.2 FM camps-on all ICSRCHANs for all IC Trunk Groups
4.2.a FM initiates Global Reset to each ICTRKGRP
4.2.b.1 FM sends Go-Ins to XC (XC tears down all call state information)
4.2.b.2 Upon Go-Ins Complete (acknowledge msg received), new traffic
allowed
3. Remote CBSCs: FM Camps-on ICSRCHANs and “locally”
Releases Calls (target/source) using ICTRKGRP
3. After CP Cleanup Completes, FM on remote CBSCs execute
ICSRCHAN Reset for “stuck” ICSRCHANs
3. Upon completion, remote CBSCs Acknowledge Global Reset
3. When local cleanup is complete (step 5 & 7) and a remote CBSC
has ack’d, Signal Global Reset Complete to other CBSC
3. Remote CBSC uncamp-on ICSRCHANs
Page 261 of 264

ICBSC SHO: O&M Fault Management - Global Reset Diagram

Global Reset Diagram
2 Block New Calls C

process
restarts 1 Call
callproc Release callproc
ICSRCHAN
Idled 4a
3 CP informs FM
3c Global TRKGRP Reset
4 FM Camps On ICSrchans 3 8
XC Release
3a Global TRKGRP Reset Ack Radio Channel/
sc_devom sc_devom
XC Disconnect
XC Release 6
Call
adio Channel/ CPP
CPP
C Disconnect 5 ICSRCHAN
ICSRCHAN 5 4b 4c
Call Reset
Reset Global TRKGRP Reset Complete
7
alls XC XC
Release Release
Radio Channel Radio Channe
Page 262 of 264

ICBSC SHO: O&M - Performance Managem

❑ Traffic Engineering Measurements:
◗ ICTRKGRP Measurements
➠ Members Equipped
➠ All Channels Busy
➠ Out of Service Times
➠ Total Usage/Attempts/Overflows
➠ Anchor Usage/Attempts/Overflows
➠ Glare/Glare Retry/Glare Retry Success
◗ ICSRCHANs Measurements
➠ Out of Service Times (CP Unavail. or OOS)
➠ Total Usage/Attempts
➠ Glare
◗ Carrier Site Level
➠ IC Group Usage
◗ Carrier/Sector Level
➠ IC TCHwc Usage/Attempts/Overflows
◗ MCCce Level
➠ IC Usage
❑ Performance Measurements:
◗ Anchor Trunk Group, Anchor Sector/Carrier, Target Sector/Carrier Level
✓ Initial Req/Attempts/Failures
✓ Subsequent Soft Req/Attempts/Failures
✓ Subsequent Softer Req/Attempts/Failures
✓ Intermediate Soft Drop Attempts/Failures
✓ Intermediate Softer Drop Attempts/Failures
✓ Last Drop Attempt/Failures
✓ IC RF Loss (only at Sector/Carrier level)
Supercell Arc
ICBSC SHO: O&M - Call Detailed Log (CDL)
ICBSC SHO: O&M - Call Detailed Log

(CDL)
❑ Call Detail Log (CDL)
◗ Extension to Store Remote CBSC Identifiers for Remote
Call Leg Information
➠ ADD MM Sys_ID Number to various fields
➠ ID-10 New Release Event (INIT_MM_REL_EVENT) for IC Target
Failure
➠ ID-11 Modified “HO Summary”
➠ ID-12 “Last_HO_BLOCK_Cause” Extended to include IC SHO
Blocked causes.
➠ ID-13 (New) “IC SHO Summary Information
✓ Initial SHO Info: Initial external Target (target MM and Sector),
Local Source Information (Current Source Sector on Active Set)
✓ Last SHO Info: external Target (target MM and Sector), Local
Source Information (Current Source Sector on Active Set)
✓ Last Target
✓ Initial IC SHO Attempts/call
✓ IC SHO CBSC Interaction count (Number of different CBSCs MS
was in IC SHO with)
◗ Cleanup of Some Call Leg Information Fields
Page 264 of 264

7.12 Edge Sensing

from Dan DeClerck’s taxonomy:
7.13 Description and discussion.
This method uses whatever information is available to determine if the mobile sta-
tion is at the edge of a cell. This method has not been fully investigated, but there are
a number of techniques that can be employed to determine when the mobile has
come to the limit of a cell boundary. Typically, the information required might
include: PN phase measurements from the receiver of the base station (timing of ear-
liest arriving ray) to determine RF path distance to base station, mobile station’s
Pilot power measurements to get a rough approximation of reverse pathloss in the
presence of interference, and forward Frame Erasure Rate (FER). One of the diffi-
culties of using this method is in areas of excessive amounts of multipath and/or
non-dominant pilots. In this environment, the mobile station may be constantly
changing it’s reference PN, and thus slewing it’s transmit timing. This environment
of uncertain mobile station transmit timing would negate the ability of the base sta-
tion to use PN phase measurements effectively. Typically, in this environment
(excessive multipath) fading is more prevalent, and may vary from subscriber vendor
to subscriber vendor, dependent on receiver performance. To mitigate all these
effects, it is suggested to do the following:
7.13.1 Tune TADD/TDROP/TTDROP to force the mobile into less soft-handoff.
This would reduce the number of places where the mobile switches reference
PN’s, and thus make the RF path distance measurements more accurate.
7.13.2 Design the frequency seam using natural topological features, such as rivers,
large open tracts of land (less clutter).
This would make the effects of multipath less prevalent, and make the phase
measurements more accurate.
Page 265 of 268

Figure 3 depicts a deployment of edge-sensing, using a natural boundary. It depicts a

bridge over a river which is the intersection of two Major Trading Areas (MTA).
A Band MTA CDMA Carrier Domain
River
C Band MTA CDMA carrier domain

Figure 3
For sectors A and B, TADD and TDROP would be set appropriately to bias them
toward single-leg traffic channels (reduce the probability of soft handoff, and thus a
changing Reference PN). The river is chosen to reduce the amount of multipath to
make edge sensing more reliable.
7.14 E911 techniques which may be used for hard-handoff detection.
7.14.1 Bruckert/Ghosh/ et. al. developments.
This contribution is being evaluated (in a minor way) in Release 8 of Super-
cell software. This evaluation covers only timing of Access probes. If we
were to permanently use this trial, it would negate the use of Probe PN ran-
domization (which might not have a negative impact).
Presently the final contribution is being proposed to the TIA. In this contribu-
tion, The subscriber unit vacates the traffic channel and transmits a fixed
duration burst at a pre-defined power level on the alternate frequency. The
infrastructure equipment would employ scan receivers to determine location
of the mobile.
7.14.2 DeClerck/Harris improvements.
Page 266 of 268

The contributions of Bruckert, Ghosh, et.al. do not allow for the subscriber
units’ transmit timing slew, and can create grave error. Dan DeClerck and
John Harris are investigating the transfer of the mobiles’ timing slew infor-
mation to the base to more accurately determine the round-trip delay of sig-
nal, and thus improve estimates of edge detection. In the DeClerck/Harris
proposal, the mobile station would not vacate the traffic channel for edge-
detection techniques.
Page 267 of 268

Page 268 of 268

8.0 Background
The following sections provide handoff background information.
Page 269 of 270

Page 270 of 270

8.1 CDMA Hard Handoff Problems & Solutions

Presentation to DDI 01/23/97 by Barry J. Menich
Text version of a PowerPoint document. See original PowerPoint document for the many
missing pictures
8.1.1 Hard Handoff Topics
• CDMA Basics Regarding Handoff
• The Hard Handoff Problem
• Inter-CBSC and Inter-Carrier Hard Handoff
– Intra-Carrier Hard Handoff
– Associated Problems
– Pilot Beacons
» Deployment & Method
» Optimization
» Idle-mode Handoff Problems & Solutions
• Other Techniques
– Phase Measurements
– DAHO (Database Assisted HandOff)
– Ec/Io Thresholding
– Scan Receivers
8.1.2 IS-95A Pilot Definitions
• Active Set
– Those pilot signals used as phase references for purposes of demodulating forward
traffic channels.
• Candidate Set
– Those pilot signals displaying characteristics such that they have high probability of
being promoted to the Active Set.
• Neighbor Set
– Those pilot signals assigned to adjacent cells and/or sectors.
• Remaining Set
–
– PN index offsets need to be on PILOT_INC boundaries
8.1.3 Pilot Status Transitions
8.1.4 Pilot Strength Measurement Message
PSMM sent upon solicitation (demand driven) from infrastructure or according to IS-95A
section 6.6.6.2.5.2 (event driven). Requires L2 acknowledgment.
Page 271 of 280

• Pilot Ec/Io Information

– Ec/Io for active and candidate set pilots.
– Ec/Io for neighbor set pilots not included.
– Ec/Io for remaining set pilots not included.
• Pilot Identification
– PN Index Offset phase measurements (whole chip resolution).
– Identity of active set pilot providing timing reference.
• Event Information
– “Keep” flag for active and candidate pilots.
– Promotion of neighbor/remaining set pilot to candidate status signified by inclusion in
PSMM.
8.1.5 Pilot Scan Algorithm
• Active and candidate set pilots scanned with high priority due to increased probability of
need to demodulate.
Neighbor set pilots scanned in between scans of all active and candidate pilots. Thus,
neighbor scan interval is a function of the number of pilots in the active and candidate
sets.
Remaining set pilot scanned in between scans of all neighbor set pilots. Thus, remaining
set scan interval is a function of the neighbor set scan interval.
• Early scan termination if preliminary integration fails to satisfy threshold.
– Bad delay spread situation may cause fraction of early terminations to decrease, thus
increasing single pilot scan times.
8.1.6 Pilot Scanning Basics
Integration period commensurate with pilot status (ie. “active”, “candidate”, “neighbor”).
More integration for active/candidate, less for neighbor/remaining.
• Filtering of active and candidate set pilot Ec/Io measurements.
– Specifications on filtering accuracy are loose.
– See Chapter 9 of IS-98.
• Qualcomm mobile station defines a “pre-candidate” status for a pilot. Ec/Io > T_ADD
threshold.
8.1.7 Pilot Scan Algorithm Implications
• Scan rate for Neighbor and Remaining set pilots is non-deterministic
– Dependent on number of active and candidate set pilots
– Dependent on number of scan “sweeps” that terminate early
• Pilot scan filter parameters for any make/model subscriber unit are unknown by infra-
structure.
Page 272 of 280

– Corner frequency
– Skirt
• No restriction on the number of events contained within a PSMM.
• Events are not explicitly conveyed, they must be inferred.
Neighbor-->Candidate set transitions, T_TDROP and T_COMP events are lost with
PSMM rubout on reverse link (check out IS-95A section 6.6.6.2.5.2). Mobile stops trying
after 2 re-tries.
8.1.8 The Hard Handoff Problem
• Solution for current lack of inter-CBSC SHO.
• Multi-carrier needed for system-wide capacity relief.
• “Spot” Capacity Relief.
• Inter-vendor HHO.
• PCS inter-band HHO.
• CDMA to AMPS HHO.
Not much support for HHO in IS-95A and J-STD-008. Limited to frequency agility of sub-
scriber unit and CDMA channel number field in Extended Handoff Direction Message.
No analog to CDMA handoff technology available yet.

8.1.9 Multi-Carrier Handoff (“Wedding Cake” Example)
8.1.10 “Spot Capacity Relief” Example
8.1.11 Hard Handoff Algorithm
(Intra-Carrier and Pilot Beacon Techniques)
• Current algorithm for both “intra” and “inter” carrier HHO.
• Infrastructure examines contents of Pilot Strength Measurement Messages sent by
subscriber unit.
• If candidate set pilot in PSMM is
– Associated with an “external CDMA sector” (XCSECT), and
– T_COMP dB better than all active set pilots represented in PSMM, then
then Handoff to XCSECT is initiated.
• Extended Handoff Direction Message contains RF carrier identity of target.
8.1.12 Intra-Carrier Hard Handoff
• Implemented as bridge to inter-CBSC SHO.
• Inter-cell approach used.
Page 273 of 280

• Poor performance!
– High FWD FER in HHO areas both before and after HHO.
» Hysteresis scheme (ie. “T_COMP”) exacerbated Ior/Ioc problem.
– “Ping-pong” phenomena only makes audio quality worse.
» Not so bad in areas of “good” coverage.
– Susceptible to non-correlated shadowing between source and target.
» EX_HO_DIR_MSG reliability issue when source is shadowed.
– Success dependent on number of “ping-pongs”
» Always an odd number of HHOs for every seam transition.
» p(success) = (message_reliability)**X
• X = # ping-pongs
•
8.1.13 Pilot Beacons (Inter-Carrier Hard Handoff)
• Current solution for inter-CBSC handoff.
• Inter-cell handoff (CBSC boundaries don’t cross sector lines).
• Advantages:
– Allows multiple target discrimination.
– Shadowing between target and subscriber unit accounted for in target Ec/Io measure-
ment.
– Many optimization “knobs” relative to intra-carrier HHO.
» Much better hysteresis control.
» Minimizes, or eliminates, “ping-pong” phenomena.
– Many in industry consider this to be the “natural solution” to the HHO problem.
– Minimizes Ior/Ioc performance problems.
» Audio quality at target much better relative to intra-carrier HHO.
• Disadvantages:
– Requires extra spectrum or extra tier of spectrum in implementation area.
» Problem for cellular operators.
– Possible gaps due to reduced beacon footprint
» May require beacon deployment on sectors facing away from CBSC seam or source
cells.
– Requires beacon hardware and associated software and communications links/
resources.
» Possible increase in beacon HW complexity with increased number of carriers.
» Needs frequency agility in idle mode.
Page 274 of 280

» LPA type (multi-tone) and capacity now a concern.

» Needs GPS signals for downlink synchronization.
– Beacons required everywhere for inter-carrier HHO
» “Spot capacity relief” becomes expensive.
8.1.14 Pilot Beacon Deployment (Inter-CBSC Handoff Example)
8.1.15 Pilot Beacon Deployment (Multi-Carrier Example)
8.1.16 Pilot Beacon Optimization
• Optimization Parameters:
– Serving cell output power
» Extend range of serving pilot(s) into seam.
– Pilot Beacon output power
» Extend range of beacon signal into seam.
– Subscriber unit T_COMP parameter (“hysteresis”)
» Slow fading allowance.
» Message integrity margin.
– Forward Power Control
» Message integrity margin.
– Neighbor Search Window
» Additional hysteresis, but must be mindful of SHO effects on current side of seam.
Don’t play with this unless you have to.
If necessary, simplify to the 2-cell case (one source, one target) by turning off other bea-
cons in surrounding area. Make one case work, then build from that.
Adjust (in decreasing order of desirability) T_COMP, pilot beacon power, or serving cell
power to move handoff location away from an area that’s shadowed wrt to either serving
or target cells.
Use SHO thresholds and Fast Pilot Shuffling to acquire “macrodiversity” state when
going into the seam. Some situations might have multiple shadowing angles. Multiple
paths for the Extended Handoff Direction Message increase probability of successful
message delivery.
8.1.17 Idle Mode Handoff Problems
• Current Pilot Beacon implementation (12/96) has introduced inefficiencies in subscriber
unit System Determination at HHO seam:
Subscriber unit driving out of idle-serving system “A” will not idle HO to sys “B” (other RF
carrier) until loss of sys “A” PCH.
» Momentary lapse of service availability in idle mode.
» Algorithm not specified by J-STD-008.
Page 275 of 280

» Qualcomm algorithm is unknown.

• Search all “A” PN-space before attempt at another RF carrier?
• Pilot-based or FER-based?
– Subscriber unit may attempt System Determination on Pilot Beacon (“Pilot Beacon
Dwell”).
» Most typical occurrence on HHO RFLOSS.
» What is Qualcomm’s dwell time before abandoning SCH acquisition?
» Search all current carrier PN-space before attempt at another RF carrier?
• Three messages control process
– CDMA Channel List Message
– Extended Neighbor List Message
– Global Service Redirection Message
• No rigorous definitions or procedures in IS-95A or J-STD-008.
Just because Qualcomm will do something in a particular fashion doesn’t guarantee that
Motorola, Oki, Nokia, or Samsung, will do it the same way.
– Probably need to beef up IS-98 and PCS analogue.
8.1.18 Idle Mode Handoff Solutions
• Optimize inefficiency:
– Program subscriber units for limited carrier search.
– Continue to optimize current beacon signals for minimum output power such that sub-
scriber dwell problem is minimized.
• Equip Pilot Beacon sites with SCH and PCH capability:
– Transmit:
8.1.18.1 CDMA Channel List Message:
• Allows mobile knowledge of paging channel RF carrier hosts.
• Need for eventual implementation of “true” multi-carrier hash.
» Global Service Redirection Message:
• Prohibits subscriber unit dwell on pilot only carriers.
• Transmit Extended Neighbor List Message from handout sites:
• Parameterize subscriber unit with alternative RF carrier to scan for Pilot, PCH, and
SCH signals.
CDMA Channel List Message
• Lists all RF carriers at current cell/sector that are transmitting Paging Channels.
• Assumes all RF carriers utilizing same PN index offset as current carrier?
8.1.18.2 Extended Neighbor List Message
Page 276 of 280

• PILOT_PN (current serving site) and PILOT_INC

• Neighbor cell/sector:
– Search Priorities (not currently supported)
» Unknown how Qualcomm interprets this field.
– Neighbor Paging Channel configuration
» (000) Same num. of RF carriers, same num. or PCHs.
» (001) Same num. of RF carriers, possibly different num. of PCHS.
» (010) Different num. of RF carriers
» (011) Unknown configuration
– Neighbor RF carrier
» Qualcomm confirms they will scan other RF carrier, however we don’t know details.
– Neighbor RF Band Class (ie. PCS or cellular)
8.1.18.3 Global Service Redirection Msg.
• Direct subscriber units to other carrier or other service.
• Non-ESN specific (ie. point-to-multipoint)

• Serving cell/sector PN index offset
• Access Overload Class bit map (“ACCOLC”)
• Target RF Band Class (ie. PCS or cellular)
• Number of CDMA RF carriers
• CDMA RF carrier identities
8.1.19 Capacity With Pilot Beacons
• Question: What is the capacity degradation due to the pilot beacon implementation for
inter-carrier HHO across CBSC seams?
Answer: There is none. Why would there be? Since we use another RF carrier on the
other side of the seam, both FWD and REV other cell interference components (Ioc) are
greatly reduced.
8.1.20 Additional HHO Solutions Under Study/Consideration
• Edge Sensing
– Intra-cell handoff
– Techniques:
– Reverse Link Phase Measurement Technique
– Ec/Io thresholding
Page 277 of 280

– DAHO
• Inter-cell handoff
– Scan Receivers
NOTE: With the exception of DAHO, all edge sensing and scan receiver techniques are
still under scientific study. Thus, no firm plans/schedules have been adopted for their
deployment.
8.1.20.1 Edge Sensing (Phase Technique)
• Detect subscriber unit proximity to cell “edge” or coverage “edge”.
• Seen as potential solution to “spot capacity relief” problem.
• Use reverse link short code PN phase measurement offset (from system time) as trig-
ger criteria.
• Advantages:
– Allows load insensitive trigger.
– Always errors on safe side.
– Allows “grading” of incoming originations into carrier coverage at a cell (ie. use ACH
phase measurement).
– Minimizes, or eliminates, need for beacon equipment.
• Disadvantages:
– Algorithm complexity increases with need for SHO at border.
– Target discrimination increases complexity and is non-deterministic. Handoff is intrinsi-
cally intra-cell in nature.
– NLOS conditions may trigger false handoff detect.
8.1.20.2 Mobile Timing Basics
8.1.20.3 Phase Technique Example
8.1.21 Edge Sensing (DAHO)
• DAHO = “Database Assisted Handoff”
– Perform HHO based on identities of pilots in subscriber unit active set.
– Majority coverage by border sector pilots is HHO trigger criteria.
• Inter-CBSC HHO would require more than a single cell’s worth of overlap.
• Current CDMA to AMPS handoff technique for cellular customers:
– Customers happy with reliability, but unhappy with “wasted” CDMA Erlangs in border
cells/sectors.
Page 278 of 280

» Potential for optimization through lengthening of T_TDROP timer. This has already
been tried in one market with some success.
• Handoff to underlying cell with congruent (or better) coverage.
8.1.22 DAHO Deployment
8.1.23 Edge Sensing (Ec/Io Thresholding)
Use mobile station T_DROP and T_TDROP parameters to implement handoff detect at
edge of cell on single, remaining active set pilot.
– Minimal impact to current software architecture.
• Intra-cell hard handoff, continue SHO on other carrier.
• Some problems/concerns:
– Sector boundaries.
– Limited detect range (-6 dB to -13 dB).
– Increasing variance with increasing thermal noise.
– Ec/Io coverage collapse proportional to loading and inversely proportional to need!
– Needs to be optimized in unloaded case with most benign propagation in cell of inter-
est (ie. worst possible handout condition).
8.1.24 Edge Sensing (Ec/Io Thresholding Example)
8.1.25 CDMA Scan Receivers
• General Idea: Use a “locating receiver” as in analog systems to determine suitability for
acceptance into target cell.
• Advantages:
–?
• Disadvantages:
– Infrastructure does not control subscriber output power (open loop). Thus, absolute
measurement is impossible.
– Scan receiver has no a priori knowledge of reverse link noise.
– Needs reference cell PN from source cell.
– Implies Phase Technique required for source cell trigger.
– Timing “slew” suppression implies no soft handoff activity
• Interesting:
Requires moderate bandwidth connection (recurring expense) to source system which
would be orders of magnitude greater than that required for Pilot Beacons (probably lim-
ited to fault management & provisioning).
Page 279 of 280

Page 280 of 280

May 13, 1997 Motorola Confidential Proprietary
Version 7.0
Status: Released
C H A P TE R 6 CDMA Handoff
Detection and Target
Selection
6.1 General Discussion

For CDMA systems, handoff detection processing will take place in the XC and in
the MM. The XC will detect the need to handoff, perform handoff preprocessing
and identify events. The MM will determine the handoff type, perform target selec-
tion and perform channel allocation.
6.2 CDMA Handoff Types

IS-95 [3] allows for several types of handoff to take place. The following list elabo-
rates 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 al-
ways two types of soft and softer handoff. One type called an “add” is used to in-
struct 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.
Handoffs may be triggered by either Mobile Assisted Handoff (MAHO) or Data-

base Assisted Handoff (DAHO) techniques. MAHO techniques depend on mea-
surements made by the mobile and returned to the BTS. DAHO techniques depend
on information on cell configuration stored in the CBSC/BTS along with the sys-
tem’s knowledge of which cells/sectors control a particular call.
MAHO techniques may be used to trigger soft, softer and hard handoffs. DAHO
techniques may be used to trigger hard handoffs.
• Inter BTS, intra XC Soft Handoff: This handoff type is expected to be the high-
est 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. This term will be used fairly often within the body of the
SFS and can be used in a generic way.
System Functional Specification: Handoff and Power Control 281

/usr/test/adv_sys/cdma/documentation/stolen/hopc/Handover_Detection
Complex Handoffs
• Intra BTS, Inter Sector, 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 or Intra BTS Hard Handoff: This handoff type denotes either a change in
operating frequency, a change in 1.25ms 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 Analog: This handoff type is used to transition a multi-mode
mobile station from CDMA operation to operation on an analog system.
6.3 Complex Handoffs
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 mobile’s active set. For
example, MAHO measurements from the mobile station may indicate that it is de-
sirable to enter into a state where new connections are supported from both the cur-
rent 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 which add or drop a single pilot from a
mobile station’s active set.
6.4 Database Assisted Handoff (DAHO)

This handoff detection algorithm is used to determine when to transition a mobile
station to another frequency band and/or air interface other than CDMA. Since nor-
mal CDMA Mobile Assisted Handoff (MAHO) handoff detection methods cannot
be used to determine a suitable target, database-stored information concerning par-
tially or fully overlapping handoff targets must be used to carry out the handoff pro-
cess.
6.5 Inter-CBSC Soft Handoff (Trunking)
Soft and softer handoffs can be performed with a cell under another CBSC by using
inter-CBSC soft and softer handoff procedures to connect the target CBSC channel
element to the source CBSC transcoder via an inter-CBSC subrate channel. Refer
to the SSRR SFS [17] and DBCM SFS [4] for details on inter-CBSC connectivity.
The method of performing inter-CBSC soft/softer handoffs via subrate channels

and SCAP links between CBSCs is referred to as the trunking method, to distin-
guish it from the A+ method, using standardized IS-634 procedures, which may be
implemented in the future.
A call can be in inter-CBSC soft/softer handoff with multiple target CBSCs at the
same time. A call enters into inter-CBSC soft handoff when the mobile reports a vi-
able candidate pilot that points to an XCSECT (external sector data base) in the
Page 282 of 306

Handoff Modes
source CBSC, and this XCSECT has inter-CBSC soft handoffs via trunking en-
abled. Subsequent inter-CBSC soft and softer handoff operations may occur with
pilots that are in the neighbor list of a target CBSC cell. Target CBSC neighbor lists
are sent back to the source as part of the inter-CBSC soft/softer procedure. In these
‘remote neighbor lists’, the source checks target sectors, and non-target sectors that
are local to the source, for matches with candidates reported by the MS. The source
will ignore matches with other neighbors in the remote neighbor lists.
The source CBSC remains in control of the call until no source handoff legs remain.
At this point the source determines if it should transfer control to a target CBSC via
a hard handoff.
In general, all procedures and requirements specified for intra-CBSC soft and softer
handoffs apply to inter-CBSC soft and softer handoffs, unless otherwise noted.
However, separate handoff execution procedures have been specified for inter-
CBSC soft handoff (trunking).
6.6 Handoff Modes

The system is required to support various “handoff modes”. The handoff mode de-
fines how the handoff detection algorithm and execution procedures operate. The
mode defines what triggers the system to add a pilot to the mobile station 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 station’s 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.
6.7 Mobile Station Operation

It is assumed that the mobile station operates as follows (from IS-95 [3]):
• Any time a neighbor set or remaining set pilot rises above TAdd, the mobile sta-
tion sends an RF: Pilot Strength Measurement Message (PSMM) to the system.
This is referred to as a TAdd indication. The mobile station will add this pilot to
the candidate set and no further TAdd indications will be sent for this pilot. Sub-
sequent PSMMs will contain strength measurements for this pilot.
• Any time a candidate set pilot rises TComp × 0.5dB above any active set pilot,
the mobile station sends a PSMM to the system. This is referred to as a TComp
indication. After an RF: Extended Handoff Direction Message which does not
include the TComp pilot in the new active set, the mobile station will resend the
TComp indication for that pilot if the condition persists.
• The mobile station removes pilots from the candidate set as follows:
1) when the pilot falls below the TDrop threshold for TTDrop seconds (the
handoff drop timer has expired)
2) when the candidate set is full and the mobile station must add another pilot to
it, the mobile station will remove the pilot for which the handoff drop timer is
Page 283 of 306

Database Parameters
closest to expiring
3) a candidate pilot is added to the active set
• Any pilot which crosses TAdd and TComp thresholds simultaneously is treated
as a TComp indication by the mobile station. The mobile station only sends one
PSMM for that pilot1.
• Any time an active set pilot falls below the TDrop threshold for TTDrop sec-
onds, the mobile station sends a PSMM to the system. This is referred to as a
TDrop indication. After an RF: Extended Handoff Direction Message which
does not remove the TDrop pilot from the new active set, the mobile station will
resend the TDrop indication for that pilot if the condition persists.
6.8 Database Parameters

The following are the database parameters which apply to handoff detection. Refer
to the DBCM SFS [4] for further information and 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 sys-
tem sends this parameter to the mobile station in the RF: System Parameters
Message, RF: Extended Handoff Direction Message, and the RF: In Traffic Sys-
tem 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: Ex-
tended 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 mes-
sage. 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 can-
didate set. The system sends this parameter to the mobile station in the RF: Sys-
tem 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 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
1. At least this is how Motorola mobiles are understood to operate.
Page 284 of 306

RF Measurements Used in CDMA Handoff and Power Control Detection
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.
• 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 Chan-
nel Assigned Message.
• DAHO - DAHO Indicator - This parameter indicates whether a sector-carrier is
near a border and contains neighboring or overlapping sectors operating on an-
other frequency and/or non-CDMA signalling scheme.
• DAHOHysTimer - DAHO Hysteresis Timer - This parameter is used to prevent
‘ping-pong’ handoffs between two sectors which have been marked with the
DAHO flag. After a hard hand-in, origination, or termination in a border sector,
majority border checks will be disabled for a period of time in seconds equal to
the value of this parameter.
• HandoffMethod - Handoff Method - This parameter specifies the method
(none, hard, soft trunking, soft aplus) to be used to hand the call off to a sector
external to the CBSC. The scope of this parameter is per external CDMA sector.
• Inter-CBSC Soft Handoff Override - This parameter is used to ‘turn-off’ In-
ter-CBSC soft handoffs between two MMs. It is checked by both source (in
handoff detection) and target procedures. When override is allowed, the alterna-
tive action of either no handoffs or hard handoffs is indicated (no handoffs, hard,
no override). The scope of this parameter is per inter-CBSC trunk group.
• AnchorHoMeth - Anchor Handoff Method - this per CBSC parameter indicates
the condition upon which trigger the source MM to move a mobile in Inter-
CBSC soft handoff from a source (or ‘anchor’) MM to a target MM once all the
source legs have been dropped (keep soft, on no source legs, on all legs remote).
The parameter can be used to keep calls in soft handoff, to execute a hard hand-
off when there are no source legs in the call, and to execute a hard handoff when
all the legs are remote, i.e. no known XCSECT representations in the source
CBSC.
6.9 RF Measurements Used in CDMA Handoff and

Power Control Detection
While TDMA systems offer a plethora of RF related measurements to use in hand-
off detection, CDMA seems to be rather sparse in this regard. Nevertheless, there
appears to be some latitude for creativity in this area. The list below elaborates on
the usefulness of each measurement. Specific usage of measurements can be found
in the procedures sections dealing with handoff and power control. Due to the par-
ticulars of the CDMA air interface, it will not be possible to use the GSM 05.08 al-
gorithm to perform handoff detection. Instead, CDMA relies on the mobile station
to provide an event to the infrastructure equipment to serve notice that a threshold
has been crossed as well as provide MAHO measurements to assist in establishing
target suitability.
Page 285 of 306

CDMA Cellsite Receive Antenna Selection
For handoff, the main piece of data to contend with is the contents of the pilot
strength measurement message. The RF: Pilot Strength Measurement Message is
sent autonomously by the mobile station in response to a particular pilot crossing
the T_ADD, T_COMP, or T_DROP thresholds. The message contains PN phase
measurements and strengths of the pilots that the mobile station is monitoring. The
PN phase measurements are in chip offsets relative to the zero phase pilot offset
(i.e. relative to system time). The pilot strength measurement is actually a chip to
noise power ratio whose value is always less than 1.0. The mobile returns a loga-
rithmic compression of this measurement equal to
Ec
– 2 × 10 × log  ------ 

10 I 0

where Ec is the received pilot energy per chip and I0 is the total received spectral
density (note this results in the higher the value the lower the measurement, and
vice-versa). Thus, pilot strengths and PN phase will be used in tandem both to de-
termine the need to handoff as well as choose appropriate targets.
On the reverse link, frame errors or frame quality depending on the frame rate is de-
tected by the MCC. For full rate and half rate air interface frames, the MCC passes
the frame CRC pass/fail status and the Viterbi decoder symbol error rate to selector
in the uplink STRAU frames. For fourth and eighth rate frames, the MCC passes
only the symbol error rate to the selector. The selector determines frame erasures
from this information. A frame erasure rate (FER) can be generated in the XC after
a sufficient number of frames have been received to begin forming the statistic.
Typically, 1% of the frames in error will be tolerated in the system. Note that due to
soft handoff, the reverse FER for a call is not necessarily determined by an individ-
ual MCC circuit. Reverse FER is determined after frame selection from all MCCs
involved in the call.
On the forward link, frame errors are detected by the mobile station and reported to
the base station equipment in the RF: Power Measurement Report Message. This
message contains the number of errors detected over a certain number of frames.
This message may be sent by the mobile station either periodically or when a
threshold of bad frames has been reached. The message also contains a report of pi-
lot strengths for pilots included in the current mobile station active set.
6.10 CDMA Cellsite Receive Antenna Selection

During a call, and regardless of soft or softer handoff conditions, the MCC will
need to check for significant reverse channel energy on a per sector basis related to
the call (see FIGURE 41 on page 287). When finding a signal with significant ener-
gy that exceeds the energy being used by one of the fingers, the MCC shall dedicate
a finger to that new signal. If the signal drops below another threshold, then the fin-
ger is dropped from combining. The MCC is configured to operate in a sectored or
omni mode. This is to prevent wasted processing time looking for signals where
there are no sector inputs.
Page 286 of 306

Maintenance Command Interaction
FIGURE 41 Simplified Single Channel MCC Reverse Link Diagram
Search Processors
Demodulator
Reverse Link Preselection

Search Processors
Demodulator
Search Processors
Demodulator
Sector Search Processors

Antennas
Demodulator
Simplified single channel MCC reverse link diagram

showing finger management detail.
(120 sector site example)
6.11 Maintenance Command Interaction

Several maintenance commands are available to the craft which require handoff in-
teraction. The PADD command is used to add a soft or softer connection to a call.
PDROP performs the opposite function. HOLD maintains the current state of the
call by not allowing automatic adds, drops, or external handoffs. UNHOLD clears
the condition.
These commands are detailed in the CDMA CP SFS [5]. Also defined in that docu-
ment are several requirements pertaining to the execution of those commands. The
reader is referred to that document for general requirements, including CLI interac-
tion and resource management. This document will contain specific requirements
that impact handoff detection and target selection.
Page 287 of 306

Handoff Detection General Requirements
When a call is in a HOLD state, automatic handoffs will not be allowed. Soft and
softer handoffs will be initiated through the PADD and PDROP commands.
When a soft or softer add is specified through the PADD command, the MM shall
initiate the indicated action. Handoff type and target selection are determined by
parameters in the command. See the CDMA CP SFS [5] for specific requirements.
Note target selection may also indicate a specific MCC timeslot (MCCce).
When a soft or softer drop is specified through the PDROP command, the MM shall
initiate the indicated action. Handoff type determination is specified by parameters
in the command. See the CDMA CP SFS [5] for specific requirements.
Should a SCAP: Handoff Recognized message arrive while a PADD or PDROP

command is being processed, the message shall be discarded and not acted upon.
The CDMA CP SFS [5] contains requirements regarding actions to be taken when a
PADD or PDROP is requested during handoff execution.
There are some caveats for calls that are in inter-CBSC soft handoff (trunking).
Only source MM call jobs will provide a successful response to a maintenance
command. HOLD and UNHOLD commands apply to inter-CBSC soft handoff
(trunking) when performed on the source (controlling) CBSC. The target of the
command must be a local MCCce. PADD and PDROP may be used on the source
CBSC to add or drop a local sector/MCCce. A SNAP command performed on a
CBSC that is associated with the target side of an inter-CBSC soft handoff (trunk-
ing) connection will report an error. A USE command applies only to local CBSC
channel elements but on the local CBSC will apply to any type of channel alloca-
tion, including inter-CBSC soft handoff (trunking) target MM allocation. When
maintenance commands display a list of active call legs, inter-CBSC soft handoff
(trunking) legs are displayed but are not distinguished from local legs.
Note: Upon release of the HOLD condition (i.e. the UNHOLD command is per-
formed) it is not required to immediately determine if a handoff to analog should be
performed.
When an add is specified through the PADD command, a target MM call shall re-
turn an error. Refer to requirements in the Call Processing Maintenance Commands
chapter of the CDMA CP SFS [5].
When an drop is specified through the PDROP command, a target MM call shall re-
turn an error. Refer to requirements in the Call Processing Maintenance Commands
chapter of the CDMA CP SFS [5].
6.12 Handoff Detection General Requirements
6.13 CBSC Handoff Detection Algorithm

FIGURE 42 on page 289 shows control flow for handoff detection. The partitioning
of tasks within this document is not meant as an indication to an implementation,
but rather to facilitate understanding. The algorithm assumes that the mobile station
Page 288 of 306

CBSC Handoff Detection Algorithm
is already in one of several states. The diagram also shows valid events and valid
decisions that are output by the detection process. The software algorithm is split
between the MM and XC subsystems.
6.13.1 Procedures
The mobile station performs MAHO procedures in accordance with IS-95. When
the mobile station detects the occurrence of any events (such as the T_ADD thresh-
old being exceeded), it sends an RF: Pilot Strength Measurement Report Message
to the base station. Upon reception of this message by the XC, the L3 message is
routed to the handoff detection process. Note that the handoff detection process
shall store the contents of the last 16 RF: Pilot Strength Measurement Report Mes-
sages. This information can then (if desired) be retrieved by MMI or used in addi-
tional handoff detection processing.
FIGURE 42 Handoff Detection Control Flow
Pilot Strength
Measurement PN
Mobile Messages PN Offset Index Offsets Event
Station Determination Discriminator
Valid
Events
State Validation
& Detection
SCAP:
Handoff Recognized Messages
Handoff Target Handoff

Execution Selection Type
Type and Determination
target info
Handoff Detection Process Software
Valid Measurement Events: Valid Detection Outputs:

TAdd SHO ADD
TAdd + TComp SHO DROP
TDrop
Page 289 of 306

6.13.2 PN Offset Index Determination

The purpose of the PN Offset Index Determination subprocess is to identify the
base stations used in the RF: Pilot Strength Measurement Message. The XC sub-
system performs this function. The identity at this point in the control flow is just
defined as the PN offset index used by a particular base station. The algorithm ap-
plied shall be the exact algorithm that Qualcomm proposes in their Network Engi-
neering Handbook [2]. The algorithm is reproduced here for completeness.
The mobile station computes pilot PN phase øi = (Ti + 64 × PILOT_PN)mod215. Ti

is the arrival time of pilot i at the mobile station (relative to the mobile’s sense of
system time). øi is transmitted to the infrastructure equipment in the RF: Pilot
Strength Measurement Message.
The PN Offset Index Determination subprocess will apply the following equation to
each PN phase returned to determine the identity of the base station transmitting the
pilot:
15
( φ i + 32 × PilotInc )mod2
PilotPn i = --------------------------------------------------------------------- × PilotInc
64 × PilotInc
where the operator x denotes rounding the real value “x” to the largest integer
value less than or equal to x. PilotInc is a parameter supplied to the handoff detec-
tion process. It is assumed that all PN offset indices throughout the CDMA system
will be specified in increments of PilotInc and that PilotInc will be sufficiently large
(with respect to cell sizes) so as to avoid confusion between cell identities. Note
that PilotPn is constrained to values between 0 and 511 and this is assured because
of the way the mobile station calculates øi. Note also that if a PilotInc is used that is
not 1,2,4,or 8, the last PN offset should not be used due to overlap between PN off-
set 0 and the last PN offset.
The PN offset index determination subprocess shall also tag the pilot strength and
phases returned in the RF: Pilot Strength Measurement Message as to whether the
pilots are currently active or candidate pilots. In addition, the keep flag associated
with each pilot and the reference PN (the pilot that the mobile station is using to
gauge system time) shall be perpetuated to the next subprocess. Changes to the ref-
erence pilot are also noted.
Note: the XC gets the reference pilot PN directly from the RF: Pilot Strength Mea-
offset = ( phase + 32 × PilotInc )mod2 15 × PilotInc

---------------------------------------------------------------------------------
64 × PilotInc
surement Message.
6.13.3 Event Discrimination

The purpose of event discrimination is to decide what events have caused a mobile
station to send an RF: Pilot Strength Measurement Message to the infrastructure
equipment. This function is performed by the XC subsystem.
Page 290 of 306

In the current system, the only valid events are: TAdd threshold crossed, TComp
threshold crossed, and TDrop threshold crossed. Note also that multiple events may
be possible within each message (a complex handoff). In the current system, only a
single event will be processed. The precedence will be TComp, TAdd, and TDrop.
Essentially, event discrimination shall scan the list of pilots and their strengths. Pi-
lots in the active set can be tagged as drop if their pilot strengths are shown to be
below the TDrop threshold. The keep flag within the RF: Pilot Strength Measure-
ment Message is used to differentiate between those pilot signals that have fallen
below the TDrop threshold for TTDrop seconds as opposed to those pilot signals
that have momentarily dropped below TDrop at the time the RF: Pilot Strength
Measurement Message was sent by the mobile station. Thus, the first activity on the
part of the event discriminator is to scan the pilot strengths and their associated
keep flags to determine which (if any) pilots have truly met the criteria for TDrop.
This is done by noting which pilot strengths have fallen below TDrop and have
their associated keep flags set to zero. Pilots not in the active set are scanned to see
if their associated strengths have crested over the TAdd threshold, or if their
strengths have exceeded the TComp dB of one of these pilots. In either case, the
event will be a handoff.
Establishing a TAdd is done by applying the known TAdd threshold to the returned
measurements for candidate pilots. Any candidate pilot strength which is greater
than or equal to the current TAdd threshold is a TAdd event.
TComp can only be applied to the strength measurements of pilots that are not in
the active set. If a candidate set pilot has equaled or exceeded any active set pilot by
TComp × 0.5 dB, the event discriminator shall tag the candidate set pilot as a
TComp event.
Events which do not pass the event discrimination tests are not passed along to the
State Validation and Detection Process.
6.13.4 State Validation and Detection
State validation and detection determines which events are consistent with the mo-
bile stations active set state (i.e. the number of pilots in the active set). This function
is performed by the XC.
The tables below shows the allowed events depending on the mobile station’s active
set state. There is a table for both the TAdd and TComp handoff modes Refer to Ta-
ble 6: "TAdd Mode State Validation Table" on page 291, and Table 7: "TComp
Mode State Validation Table" on page 292. Each event is listed in the column head-
ings. The mobile station active set states are listed as row headings. Valid indicates
that the received event is valid for the active set state, not valid indicates that the
event is not valid and will not be processed further.
Table 6: TAdd Mode State Validation Table

TAdd Event TComp Event TDrop Event
Page 291 of 306

Table 6: TAdd Mode State Validation Table

1 Forward Link valid valid not valid
2 Forward Links valid valid valid
3 Forward Links valid valid valid
Table 7: TComp Mode State Validation Table

TAdd Event TComp Event TDrop Event
1 Forward Link not valid valid not valid
2 Forward Links not valid valid valid
3 Forward Links not valid valid valid
After determining that there is at least one valid event, the XC will formulate the
SCAP: CDMA Handoff Recognized Message and set the cause field as shown in
Table 8: "Handoff Cause Element Coding" on page 292.
Table 8: Handoff Cause Element Coding

TAdd TComp TComp & TDrop TAdd & TComp & TAdd &
events events TAdd events TDrop TDrop TComp &
events events events TDrop
events
1 Forward SHO add SHO add SHO add SHO add SHO add SHO add
Link one cell - one cell - one cell - one cell - one cell - one cell -
TAdd TComp TComp TAdd TComp TComp
2 Forward SHO add SHO add SHO add SHO drop SHO add SHO add SHO add
Links one cell - one cell - one cell - one cell one cell - one cell - one cell -
TAdd TComp TComp TAdd TComp TComp
3 Forward SHO add SHO add SHO add SHO drop SHO drop SHO drop SHO drop
Links one cell - one cell - one cell - one cell one cell one cell one cell
TAdd TComp TComp
Note: It can be assumed that active set pilots can only have drop events associated
with them, and that candidate set pilots can only have TAdd or TComp events asso-
ciated with them.
Note: In Table 8: "Handoff Cause Element Coding" on page 292, the blank entries
correspond to situations which are not possible because they were filtered out by
on page 292.
Page 292 of 306

Note: The Service Option List contains the mobile service option list obtained in
the Status message or the Status Response message. This list shall be send to the
MM if it is available.
6.13.5 Handoff Type Determination

The handoff type determination subprocess is used to determine the type of handoff
to be performed - either soft or softer and add or drop. This function is performed in
the MM. Its input is the SCAP: CDMA Handoff Recognized Message from the XC.
This message contains the latest pilot strength, active set and candidate information
from the mobile station, as well as a cause field which specifies the event which
triggered the message to be sent.
It also contains the Keep Pilot Indicator for each active pilot. When set, that pilot
should not be considered a drop candidate.
The MM determines if a handoff add or drop is required as specified in Table 9:

"Add/Drop Selection" on page 293. For an add case where the call already contains
3 forward links, a check is made to see if one of the forward links can be dropped so
that the candidate pilot can be added (fast pilot shuffle scenario). Before this check
is done, it must be verified whether a hard handoff to CDMA or analog is warrant-
ed.
Table 9: Add/Drop Selection

TAdd or TDrop Events
TComp Events Only
Only
1 Forward Attempt to add

Link the (strongest)
candidate pilot
2 Forward Attempt to add Drop the

Links the (strongest) (weakest)
candidate pilot active pilot
3 Forward Check: drop Drop the

Links the (weakest) (weakest)
active pilot?a active pilot
a. If (candidate Ec/Io is a TComp event) or

(candidate Ec/Io ≥ TAdd threshold and Ec/Io
is > 2 or more active pilots) drop the weakest
active pilot.
If an add is determined, the candidate pilots BTS and sector are determined by
searching the neighbor lists of the active pilots, and the neighbor lists of any active
pilots which were dropped after the last add. The neighbor lists could be in the local
database, for active pilots local to the MM, or they could be remote neighbor lists,
backhauled from a neighbor MM, for active pilots that are inter-CBSC soft handoff
legs.
Page 293 of 306

If the candidate pilots BTS and sector are found in a remote neighbor list, and it is
an external BTS and sector from the neighbor MMs perspective, then a check is
done to see if the BTS and sector are actually local to this MM. If yes, then the add
is treated as a local add. If no, this candidate is excluded from further processing.
Should the pilot strength be equal among two candidates for an add, the preference
is to process a local candidate, irrespective of the type of handoff that the local can-
didate requires. Local candidates (from a local neighbor list) get preference as they
typically result in local soft/softer adds. Candidates from external neighbor lists are
then given preference because they typically result in subsequent icbsc soft/softer
adds or local soft/softer adds. External candidates (from a local neighbor list) are
given lowest preference as they typically result in a hard handoff or an initial inter-
CBSC soft handoff.
If an add of a pilot is indicated, and 3 forward links are already active, it must be
determined if the candidate pilot should replace one of the currently active pilots. It
should replace an active pilot if either of the following conditions are true:
1) the candidate Ec/Io is a TComp event.
2) the candidate Ec/Io is equal to or greater than the TAdd threshold, and the candi-
date’s Ec/Io is greater than at least two of the active pilot’s Ec/Io.
If either condition is true a drop of the pilot with the weakest Ec/Io should be initi-
ated. After the drop is performed, the mobile should request another add event, and
the stronger candidate pilot should “win out” and be added. This means of replace-
ment is in lieu of complex handoffs and is referred to as “fast pilot shuffling”.
Because the SCAP: Handoff Recognized Message may contain multiple events,
Handoff Type Determination may be performed multiple times until either an event
can be acted upon, or until all events are eliminated due to unavailable resources, or
the events are not supported in the current system.
The MM must also determine if a handoff procedure should be soft or softer. If an

add is required, and the event is associated with a pilot which is in a BTS that does
not currently have a channel assigned to the call, the MM will attempt a soft hand-
off add, otherwise it will attempt a softer handoff add. If a drop is required, and the
event is associated with a pilot which is in a BTS that currently has two channels
assigned to the call, the MM will attempt a softer handoff drop, otherwise it will at-
tempt a soft handoff drop.
Handoff Type Determination During Call Setup
Ideally the functionality discussed above would apply to a call in progress at any
time from call initiation to disconnect. However, it is recognized that portions of the
system architecture do not allow this to be easily accomplished. In particular the
detection and initiation of a handoff, at the MM level during call setup, is difficult
to achieve. Therefore a relaxed minimum set of requirements will apply during call
setup which will provide the functionality that is currently perceived to be needed.
The basic functionality required is the ability to add at least one soft or softer local
(not inter-CBSC) leg to the call (during setup).
Page 294 of 306

From the MM perspective, this time is from when the channel assignment message
is sent (to the XC) to when the response is received (from the XC). At a minimum
the MM shall send a SCAP: CDMA XC Handoff Direction to the XC. Immediate
MM processing of the response (SCAP: CDMA Handoff Successful) does not det-
rimentally affect the handoff and is not a minimum requirement.
It should be noted that addition of another leg (the third), while not required at this
time, is next in perceived importance, followed by the dropping of an existing leg.
Hard, or inter-CBSC soft, handoffs, are not perceived as that critical during setup.
This is due in part to the hope that inter-CBSC seams will be carefully placed.
SCAP: Handoff Recognized messages received which cannot be immediately pro-

cessed (e.g. hard handoff indicated, handoff already in progress, etc.) should be
queued and processed when the call transitions into a stable state.
Indications of receiving, execution of, and completion of, a handoff during call set-
up shall be included in the CDL. See the CDMA CP SFS [5] (CDL section) for
more detail.
Any statistics normally pegged during handoff execution shall be pegged as well.
Any additional functionality which can be added at this time, or planned for, is en-
couraged.
Note: Handoff execution procedures may determine other Handoff Nack causes.
Refer to the failure scenarios in the various execution procedures. If the blocked
handoff is a soft/softer add or a hard handoff, the cause is stored in the CDL
LAST_HO_BLOCKED_CAUSE field. Refer to the CDMA CP SFS [5]. Refer also
to the SCAP document [6] for a list of all the Handoff Nack causes.
Note: The XC subsystem does not base any processing on the Handoff N’ACK
causes.
Note: In Table 9: "Add/Drop Selection" on page 293, the blank entries correspond
to situations which are not possible because they were filtered out by on page 292.
If this situation does occur, the MM will send a SCAP Handoff N’ACK with a de-
tailed cause of ‘Handoff not Allowed’, and issue an exception.
Note: The XC verifies that pilots with TDrop events are in the active set, therefore
the MM is not explicitly required to verify this. However, it may not be a bad idea
to do so.
6.13.6 DAHO Handoff Detection/Determination
6.13.6.1 Introduction
The detection algorithm is based upon determining when a multi-band and/or
multi-air-interface system - capable mobile has entered a sector-carrier that is par-
tially or completely overlaid by another CDMA carrier or carrier from another sys-
tem using a different air interface.
Page 295 of 306

At the edge of a CDMA carrier’s coverage, border cells (or sites) exist which pro-
vide both CDMA and other carrier/signalling system coverage. Mobiles may be di-
rected to handoff to the other system upon entering majority coverage by the border
cell(s). In the case of dual coverage by a system using an alternate air interface,
originations and terminations will be inhibited in the border cells by making use of
the IS-95A Global Service Redirection Message. This message will indicate to the
mobile station it is to acquire the non-CDMA system and not the CDMA system.
For further details on the issues surrounding DAHO handoffs, please refer to Barry
Menich’s paper, “CDMA to AMPS Handoff Proposal”, October 6, 1994 [9].
6.13.6.2 Algorithm
DAHO handoff detection is performed in the MM.
DAHO handoff detection will occur on any of the following events:

• soft add or drop
• softer add or drop
• mobile origination
• mobile termination
• hard hand-in
Upon completion of a successful hard hand-in, mobile origination or mobile termi-

nation to a border sector, the MM will use the DAHOHysTimer database value to
inhibit all subsequent DAHO border checks (as described below) for a fixed length
of time. In the case of mobile origination or termination, this will give the system
time to perform any soft or softer adds or drops which might result in the mobile re-
maining in that sector-carrier (majority condition not met). This helps take advan-
tage of the capacity of the border sector-carrier on which the origination or
termination occurs.
For hard hand-ins, the hysteresis timer prevents the call from “ping-ponging” back
to the source sector-carrier.
When one of the DAHO detection triggering events occurs, or immediately upon
expiration of the hysteresis timer, the MM then checks the sector-carrier associated
DAHO flag in the database to determine which active pilots (sectors) are border
cells (sectors), and determines whether a hard handoff to another CDMA carrier or
signalling system should be attempted.
The MM determines if a DAHO handoff is required by analyzing the total number

of pilots and the number of pilots that are border cells, as specified in Table 10:
"DAHO Handoff Validation Table" on page 297. In addition, if there are two active
pilots and only one is a border cell, whether or not they belong to the same cell site
is also taken into account.
Blank entries are impossible cases. Note some entries can only be reached through
previous error or unsuccessful attempts.
Page 296 of 306

If a DAHO is triggered, the MM determines the best DAHO sector, which is the
source sector with the strongest pilot measurement that has its associated DAHO
flag set. This is the “Best Source Sector”.
The target selection phase is entered next.

Table 10: DAHO Handoff Validation Table
1 Active Pilot 2 Active Pilots 2 Active Pilots 3 Active Pilots

Different Sites Same Site
0 DAHO Sector-Carrier Active Pilots N N N N
1 DAHO Sector-Carrier Active Pilot Y N Ya N
2 DAHO Sector-Carrier Active Pilots Y Y Y
3 DAHO Sector-Carrier Active Pilots Y

a. There is considerable debate at this point whether or not this should be a “N”. It has been decided to
allow this to be changed during process initialization via an environment variable. This will be removed
when the correct setting has been determined.
6.13.7 Inter-CBSC Soft (A+) to Hard Handoff Transition

When in inter-CBSC soft handoff and the last source leg is dropped, if the service
option allows it, a hard handoff to the target is performed.
The MM knows if a hard handoff is allowed for the call by acquiring the hard hand-
off flag associated with the service option the call is currently on.
Target identity information used in the A+: Handoff Required shall be the same as
that used in the request to initially set up the target leg (as a soft leg).
The handoff execution process is entered next.
6.13.8 Inter-CBSC Soft (Trunking) to Anchor Handoff Transition

When in inter-CBSC soft handoff (trunking) and the last source leg is dropped, the
MM checks if the transcoding and control of the call should be moved to a target
MM. If the MM so determines, an ‘anchor handoff’ is performed by executing
CDMA to CDMA hard handoff procedures.
While there are no active source legs in the call, then upon each inter-CBSC add
and drop, the MM shall check if an anchor handoff should be performed. This cov-
ers cases where the anchor handoff is not to be performed immediately upon drop-
ping the last active source leg, cases where the last source drop was performed
because of fast pilot shuffle, and cases where it is determined to perform an anchor
handoff but the handoff fails and the call remains in inter-CBSC soft handoff. Note
that if all active source legs are dropped, and then subsequently one or more source
legs are added, an anchor handoff is not performed.
Page 297 of 306

Target Selection
When in inter-CBSC soft handoff, after each local drop that was not initiated be-
cause of fast pilot shuffle, and after each inter-CBSC add or drop performed while
there are no source legs, the MM checks if there are any source legs left in the call.
If no, and the hard handoff flag associated with the current service option indicates
that the call is NOT allowed to be hard handed off, no further checking is done.
If the anchor handoff method indicates that the call is to remain in inter-CBSC soft
handoff, then no further checking is done.
If the anchor handoff method indicates that anchor handoff is to be performed as

soon as there are no source legs, then a target CBSC is selected and CDMA to
CDMA hard handoff procedures are initiated.
If the anchor handoff method indicates that anchor handoff is to be performed when
none of the target CBSC sectors supporting active call legs have a database repre-
sentation in the source CBSC, then the MM checks if this condition is true, and if it
is, then a target CBSC is selected and CDMA to CDMA hard handoff procedures
are initiated. This anchor handoff method applies hysteresis to the anchor handoff.
6.14 Target Selection

Target selection is essentially a database driven process which results in a target, or
list of targets, being selected. Please refer to the diagram below for reference during
the discussion of each handoff type.
Page 298 of 306

Target Selection
FIGURE 43 Handoff Target Selection Process
Neighbor
MAHO Inputs Associations
PN (via PSMM) Soft/Softer Handoff
PNx - ORI = 0
(ORI = 0)
DAHO Inputs PNy - ORI != 0 Hard Handoff

Best Source Sector noPN - ORI != 0 Inter-CBSC Soft Handoff
(ORI != 0)
Carrier Level
Outward Route Index List Outward Route Number Table

Target Info ORI Route List RouteNum Target
XCSect XASect
MCC MCC
MNC MNC
LAC Sctr1
Handoff MethodSctr2
Service Option SiteCon
. . . .
Cell ID SID
LAC
. . . .
MaxPL
MEM
. . . .
TACS/AMPS
Cell ID
CBSC Level CBSC Level Carrier Level
6.14.1 MAHO Target Selection
There are two types of MAHO target selection. The first results from finding a
neighbor with an Outward Route Index (ORI) of 0. The neighbor is defined as inter-
nal or local to the CBSC. An intra-CBSC soft or softer add will result.
The second type occurs when a non-zero ORI is found. This means the neighbor is
external to the CBSC, in which case further processing is required.
It is the intent to exhaust all handoff candidates, within reason, before ending the
search. The process is to find the best candidate from the MAHO list reported by
the mobile until the handoff can be attempted. Failures to attempt a handoff should
result in the next best candidate being attempted. Once a handoff is attempted (i.e.
the handoff execution process is entered), the MAHO list is not used again. If hand-
off execution was entered through the outward route traversal process, a failure in
execution shall result in the next best route being attempted.
Page 299 of 306

Target Selection
6.14.1.1 Internal Neighbor (ORI = 0)

The MAHO target selection subprocess is used to verify that the resources neces-
sary to perform the handoff specified by the handoff type determination process are
available, and then to start the execution procedure. This function is performed in
the MM. Target selection is an integral part of handoff detection as resource avail-
ability is one of the inputs into the handoff type determination process
The MAHO target selection process receives handoff types and sector information
from the handoff type determination process. If necessary (as in the case of add
events), target selection makes requests to the resource allocation function (as spec-
ified in the Call Processing SFS [5]). If the requested resources are available, target
selection will start the determined execution procedure. If resources are unavail-
able, target selection will indicate this to the handoff type determination process
where other handoff types or events may be processed.
The handoff execution process is entered next.
6.14.1.2 External Neighbor (ORI != 0)

The handoff type determination process resulted in a pilot PN, source sector and
source carrier found to be an external neighbor. The target selection process shall
now use that information to access the neighbor association and obtain the associat-
ed Outward Route Index.
The outward route traversal process is now entered.
6.14.2 DAHO Target Selection

Input into this process is the best target sector/carrier. The Outward Route Index as-
sociated with the DAHO event is obtained from the database.
The outward route traversal process is now entered. Note that when entering the
process via DAHO there is no returning to the handoff type determination process
(if no viable candidate was found) because there is no SCAP: CDMA Handoff Rec-
ognized message present.
6.14.3 Outward Route Traversal
As previously discussed and shown in FIGURE 43, a configurable, table-driven

process selects the primary target and associated parameters used to initiate a hand-
off request to the MSC for a hard handoff, or to a target MM for inter-CBSC soft
handoff (trunking). Source sector, source carrier, and (if available) the source PN
are inputs to this process. If a handoff is not attempted (i.e. was blocked for any rea-
son), the process allows multiple alternate targets to be specified and attempted.
6.14.3.1 Route Selection
At this point an Outward Route Index has been chosen and is used to index into the
Outward Route (Index) List, resulting in a list of logical routes, in priority order, to
attempt for the handoff. Each logical route will produce a pointer to either an exter-
nal CDMA sector (XCSECT) or to an external sector operating on another signal-
Page 300 of 306

Target Selection
ling system and/or carrier. Currently, only the analog (AMPS or TACS) signalling
systems are supported (XASECT). See the DBCM SFS [4] for further information.
Should the route choices be examined and no viable handoff candidate found, and
this process was entered with a MAHO indication, the process shall return to the
handoff type determination process to look for other candidates.
6.14.3.2 Hard Handoff Route
At this point, as a result of target selection, a digital to analog route, a MAHO initi-
ated digital to digital route, or a DAHO initiated digital to digital route has been de-
termined that maps to a hard handoff target, and so a hard handoff will be
attempted. The MM first performs some checks to make sure that a hard handoff is
allowed for the current call. If a hard handoff is allowed, all routes that are not hard
handoff routes or are not permissible hard handoff routes are removed from the
route list. This results in a list of permissible hard handoff routes to which a hard
handoff will be attempted.
The checks performed to make sure that a hard handoff is allowed are as follows.
They apply to a digital to analog hard handoff, to a MAHO initiated digital to digi-
tal hard handoff, and to a DAHO initiated digital to digital hard handoff.
1) hard handoff is allowed for the service option in effect for the call.
2) if the handoff was MAHO initiated its reported signal strength is a TComp event
over each of the active pilots.
3) the call is not in inter-CBSC soft handoff
If the checks do not pass, and target selection was entered with a MAHO indication,
the MM discards that candidate and moves on to the next best candidate. Other-
wise, the handoff procedure is ended. Note that this assumes that a hard handoff
route will not be followed by a soft handoff route in the route list.
If the checks all pass, then non-permissible routes are removed from the route list.
These are:
1) analog routes if the MS is not analog capable

2) digital routes that do not support the service option the MS is currently on
3) digital routes for which the handoff method does not indicate hard handoff
The MM then proceeds to attempt a hard handoff, using this list of permissible
routes.
The net result of the preceding steps is that for each of the hard handoff types, a set
of checks must pass before that type of hard handoff will be executed, as follows.
Digital to Analog (XASECT)

2) if the handoff was MAHO initiated its reported signal strength is a TComp event
over each of the active pilots.
3) the (analog) capability of the mobile is compatible with the target.
Page 301 of 306

Target Selection
MAHO initiated Digital to Digital (XCSECT)

2) the target system supports the current service option assigned to the MS.
3) its reported signal strength is a TComp event over each of the active pilots.
4) the handoff method of the target XCSECT indicates hard handoff.
DAHO initiated Digital to Digital (XCSECT)

2) the target system supports the current service option assigned to the MS.
3) the handoff method of the target XCSECT indicates hard handoff.
6.14.3.3 Inter-CBSC Soft Handoff (A+) Route
If the route maps to an XCSECT with a handoff method indicating inter-CBSC soft
handoff (A+), the MM must verify an A+ soft handoff to another system is appro-
priate.
The MM must verify the service option capabilities of the target system are com-
patible with the service option currently in use. If the service option currently in use
is not compatible with the target, the handoff is not allowed.
If the call is already in inter-CBSC soft handoff (A+), the candidate cell must be
verified to be under the control of the other CBSC. This is done by examining the
MNC and ExtCBSC of the candidate cell and comparing them to the MNC/ExtCB-
SC associated with the current portion of the call in inter-CBSC soft handoff (A+).
If this is true the handoff is initiated.
If the handoff is not allowed the MM shall discard that candidate and move on to
the next best candidate and continue as described in the previous section.
6.14.3.4 Inter-CBSC Soft (Trunking) Add, Local Trigger Route
If a MAHO event resulted in detection of a candidate pilot in a local neighbor list,

and in determination that an inter-CBSC (trunking) add of an external target should
be attempted (Handoff Type Determination indicated ‘external target, MAHO indi-
cation’ and the route maps to an XCSECT with Handoff Method set to Soft Trunk-
ing), the MM must determine if an inter-CBSC soft handoff with the target MM
already exists for this call.
If an inter-CBSC soft handoff with the target MM does not already exist for this
call, the MM must verify that the service option capabilities of the target system are
compatible with the service option currently in use. If the service option currently
in use is not compatible with the target, the handoff is not allowed.
If the handoff is allowed, the MM allocates an inter-CBSC subrate channel and ex-
ecutes the requirements specified in Section 4.14 of the HOPC..
Page 302 of 306

General Handoff Detection and Target Selection Requirements
If the handoff is not allowed, or an inter-CBSC subrate channel cannot be obtained,

the MM shall try the next route for the candidate, or if there is no next route, the
MM shall discard that candidate and move on to the next best candidate.
If an inter-CBSC soft handoff with the target MM already exists for this call, the
MM determines if this is a soft or softer add. If it is a soft add, an inter-CBSC sub-
rate channel is allocated and the requirements specified in Section 4.14 of the
HOPC are executed. If a subrate channel could not be allocated, the MM shall try
the next route for the candidate, or if there is no next route, the MM shall discard
that candidate and move on to the next best candidate.
If this is a softer add, the requirements specified in Section 4.14 of the HOPC are
executed.
Inter-CBSC soft vs. inter-CBSC softer add has already been determined by Handoff
Type Determination.
6.14.4 MAHO Target Selection, Inter-CBSC (Trunking) Add, External Trigger
If a MAHO event resulted in detection of a candidate pilot in an external neighbor

list, and in determination that an inter-CBSC (trunking) add of an external target
should be attempted (Handoff Detection indicated ‘icbsc add - external trigger’),
the MM must determine if an inter-CBSC soft/softer handoff with the target MM
already exists for this call.
If an inter-CBSC handoff with the target MM does not already exist, the MM allo-
cates an inter-CBSC subrate channel and executes the procedures specified in Sec-
tion 4.14 of the HOPC. If a subrate channel cannot be allocated, the MM shall
discard that candidate and move on to the next best candidate.
If an inter-CBSC soft handoff with the target MM already exists, and Handoff Type
Determination has detected a soft add, an inter-CBSC subrate channel is allocated
and the requirements specified in Section 4.14 of the HOPC are executed. If a sub-
rate channel could not be allocated, the MM shall discard that candidate and move
on to the next best candidate.
If this is a softer add, as detected by Handoff Type Determination, the requirements

specified in Section 4.14 of the HOPC are executed.
Since detection of the target on an external neighbor list means that an inter-CBSC
soft handoff to the target CBSC either currently exists or previously existed for this
call, it can be presumed that the service options are compatible.
6.15 General Handoff Detection and Target Selection

Requirements
Note: The HandOffMode is not required to be recent changeable within the XC, but
this would be desirable.
Page 303 of 306

Post Trial Phase 2 Issues
Note: Hard handoffs initiated but blocked by the MSC are considered blocked as
well. Error conditions such as database errors also constitute a block.
6.16 Post Trial Phase 2 Issues

Two other events for event discrimination that might be possible are vehicle loca-
tion (or distance) and excessive forward channel FER. The former would need to be
driven by some criteria for handoff based on a vehicle’s location. The latter event
would probably be a function of an advanced forward channel power control algo-
rithm that does not seek to evenly distribute available LPA power.
When the XC receives what it determines to be an RF: Pilot Strength Measurement

Message containing invalid information, it discards the message. Discarding the
message at this point is a rational strategy for the CDMA trial systems. Unfortu-
nately, the mobile station will not send another RF: Pilot Strength Measurement
Message until the relative pilot strengths change and a threshold is crossed. It is
probably a better tactic for commercial systems to query the mobile station as re-
gards his pilot measurement status after detection of a flaw in the current RF: Pilot
Strength Measurement Message.
The BBX will be equipped with an RSSI circuit to measure the signal power con-
tained in the 1.2288 MHz bandwidth of the frequency to which the BBX is as-
signed. This information will be useful in determining if a mobile station can close
the reverse link on handoff. This is especially critical in a hard handoff situation
where only one target cell is specified. Under this condition, there is no other cell
(diversity) to enhance the probability of reception on the reverse link. Currently,
there is no decision on how exactly to use RSSI measurements from the BBX, at
what rate they should collected, or even what subsystem will be processing these
measurements. BBX RSSI measurements are limited to being logged by the diag-
nostic monitor for the T1 system.
RSSI can be used to determine reverse channel rise which is useful for blocking.
The forward channel power control process could send a message indicating that no
more power could be allocated for the current connection.
The power control execution process will generate a forward channel gain for each
mobile connection at a base station. This gain is, of course, used in future decisions
on forward link power control, but may also be used by the handoff detection pro-
cess. For example, the pilot strengths reported by the mobile station may not indi-
cate handoff, but the FER experienced by the mobile would. This might happen
because of the adoption of a power control algorithm that adjusts gain as a function
of number of users rather than on a need basis. This type of power control, or even
the use of RF: Power Report Measurement Messages is not included in the T1 sys-
tem.
Page 304 of 306

Page 305 of 306

Page 306 of 306

8.2 Moving the Selector

The hard handoff is required to move the selector function (the software/hardware that
selects the best reverse link VCELP frames to be converted to PCM) from one CBSC to
another.
Figure 44 shows a mobile in soft handoff between CBSC-A and CBSC-B. The mobile’s
MSC
Inter-CBSC
CBSC A Trunks CBSC B
Selector
BTS BTS BTS BTS
BTS
VCELP Voice
PCM Voice
Inter-BSC Soft
Mobile Handoff Boundary
Figure 44: Inter-CBSC Soft Handoff
VCELP voice is routed through CBSC-B to CBSC-A’s selector function. As the mobile
moves toward CBSC-B, all of the mobile’s voice will be routed through CBSC-B as shown
in Figure 45.
If the mobile keeps moving away from CBSC-A, CBSC-A does not have adequate soft
handoff information to sustain the call. The selector function must be moved from CBSC-
A to CBSC-B (as shown in Figure 46) which currently requires a hard handoff.
This document describes the optimum methods for performing the hard handoff.
Page 307 of 310

MSC
Inter-CBSC
CBSC A Trunks CBSC B
Selector
BTS BTS BTS BTS
BTS
Inter-BSC Soft
Handoff Boundary
Mobile
VCELP Voice
PCM Voice
Figure 45: Inter-CBSC Soft Handoff, Backhaul
Page 308 of 310

MSC
Inter-CBSC
Trunks CBSC B
CBSC A
Selector
BTS BTS BTS BTS
BTS
Inter-BSC Soft
Handoff Boundary
VCELP Voice Mobile

PCM Voice
Figure 46: Inter-CBSC Soft Handoff, After Moving the Selector
Page 309 of 310

Page 310 of 310

9.0 Release Schedule

9.1 Release 5
Pilot Beacon, intra-carrier hard handoff, CDMA to analog handoff
9.2 Release 6
DAHO, SC601 support
9.3 Release 7
inter-CBSC SHO followed by N-Way to 1-Way HHO. MS can not cross a second CBSC
boundary until a HHO
9.4 Release 8
9.5 Release 9
inter-CBSC SHO followed by N-Way to N-Way HHO
Inter-CBSC SHO with the source CBSC continuously controlling the call. DAHO HHO
are allowed.
least-load
reserved channels for soft handoff
9.6 Release 10
Page 311 of 312

Page 312 of 312

10.0 Competition
Page 313 of 314

Page 314 of 314

Features:
-Complex Handoff (swap 1

for 1)
-Support 6 Way Handoff
-Pilot Shuffle
-Pilot Dominance
Page 315 of 320

Complex Handoff (swap 1

for 1)
Criteria:
•Active pilots must be in a “softer”
handoff call state
•Candidate must be >= to Tadd
•Candidate must be associated with
the “softer pair” BTS (otherwise, add
leg)
•Candidate must be > at least one
active pilot
note: capable of only dropping a single

pilot per HDM
Motorola plans to have multiple pilot
drops per HDM
Page 316 of 320

6 Way Handoff
•Limited to 3 reverse link path

Possible maximum handoff
combinations:
- 3 softer pairs (6 way)
- 2 softer pairs and 1 way (5 way)
- 1 softer pair and 2 way soft (4 way)
- 3 way soft (3 way)
•Maintains 3 way or less 87% of total
TCH time
Page 317 of 320

Pilot Dominance
•Do not add unless candidate > at least

one active pilot
•Pilot Shuffle must meet the Tcomp
and Tadd criteria (prevent adding a
pilot when active pilot is relatively
strong)
•Cannot add if reverse link path is at
maximum (3way)
Page 318 of 320

Pilot Shuffle
•Performs shuffle when in 3 way

reverse (unable to add additional leg)
•Candidate NOT associated with any of
the active BTS (cannot meet complex
handoff criteria)
•Pilot to be “shuffled in” must meet
Tadd and Tcomp (otherwise, ignores
PSMM)
•No PMRO
Page 319 of 320

Page 320 of 320

11.0 Summary
From Dan DeClerck’s taxonomy:
Each of the previously defined methods for hard handoff detection have various
tradeoffs.Various deployment examples are given below with the preferred method of
handoff detection.
11.1 CDMA to Analog (AMPS/NAMPS/TACS) handoff, same service provider
The preferred method would involve beacons, co-located with analog cell sites. This
is preferred for older mobiles (IS-95A and older), due to the large number of sub-
scriber units which do not have the necessary software upgrades to perform valid
location ranging/Edge detection or Subscriber adjacent cell scanning techniques.
Newer subscriber units (IS-95B) may have functionality to scan adjacent AMPS sig-
nalling channels. This could be used for very new 800 MHz CDMA deployments.
11.2 N carriers to N-1 carriers handoff (CDMA carrier handoff).
11.2.1 Extra carrier for In-building or tunnel, spot coverage.
Adjacent frequency scan by subscriber unit is the preferred method, due to
the large amount of multipath and a rapidly changing Reference PN, which
would reduce the effectiveness of location ranging/ edge detection tech-
niques. DAHO techniques would be difficult, since the size of the area would
be small, and DAHO requires at least two base stations overlap past the
boundary of the carrier’s coverage.
11.2.2 Extra carrier for large scale changes in population density (Urban to subur-
ban/ Suburban to Rural)
Location ranging/Edge detection, DAHO or pilot beacons are preferred over
other techniques, due to the inherent degradation of speech quality in the
Subscriber unit adjacent frequency scanning technique. It should be noted
that when using Edge Detection, the frequency seam should be chosen with
regard to natural topological boundaries, such as water or large open flat land
in order to reduce the amount of multipath and or frequent changes in Refer-
ence PN (non-dominant pilot scenario). The reduction of multipath and/or
elimination of a rapidly changing Reference PN by the mobile ensures a
more stable environment to utilize edge sensing via PN phase measurements.
11.2.3 Notes on systems that have older non-adjacent frequency scanning mobiles.
It is possible for the older mobiles to co-exist in a system with the newer
mobiles. The base station may indicate the ubiquitous frequencies to the
mobile in the Channel List Message. The newer mobile will use the Extended
Neighbor List Message to determine the larger set of frequencies it may use.
Also, the MOBILE_P_REV field in the Origination Message can indicate
the mobiles protocol revision level, and thus, if the mobile supports adjacent
frequency scanning. If the protocol revision level indicates the mobile does
Page 321 of 322

not have this capability, the mobile can be channel assigned to one of the
ubiquitously deployed carriers.
11.3 Intersystem seam (where the Carrier bands do not intersect)
In this scenario, it is not practical to put beacons transmitting in other service pro-
vider’s spectrum, nor is it practical to allow the mobile to transmit in this spectrum
for handoff detection(E911). DAHO is not practical, since it requires an overlap of at
least two base stations near the edge (which is not possible, since some other service
provider owns the spectrum). The most practical techniques would be: Edge sensing
if the topology of the landscape permits it, or the employment of the Adjacent Fre-
quency scan by subscriber unit.
Page 322 of 322

12.0 Vision
12.1 Timeline
Page 323 of 324

Page 324 of 324

13.0 System’s Engineering Recommendations
Stolen from Rebecca MacKenzie’s May 14, 1997 memo titled “Inter-CBSC SHO Deployment
Recommmendations: System Engineering”. Sections ending with an asterisk will be covered in
this document.
As promised in our discussions regarding the subject matter I have started a list of recommenda-
tions Systems Engineering would like to see implemented. Specifically, this list is developed by
the PrimeCo Systems Engineering Group. Some of the items where listed in your kickoff meeting
agenda but I wanted to include detail from our perspective.
13.1 Criteria for Successful Feature Deployment and Operations:
1. Must be at least as good as beacon HHO. Currently, ICBSC HHO system suc-
cess rate is approximately 95%. Under controlled drives across the HHO seam,
success rate is 97.5%.
2. We must have a method for tracking the performance - i.e. new CFC or PM
reports that measure Anchor HO success rate.
3. Minimum CBSC outage time.
4. Minimal service interruption.
5. Application note detailing:
white paper on operation of ICBSC SHO
required database commands
hardware/software requirements and implications
msc/cbsc/bts requirements
troubleshooting and optimization guide
rf implications of N-way to 1-way Anchor HO
additional sho delay measurements with anchor cbsc
specific performance measurement pm reports and cfc’s
future enhancements
new seam placement (traffic load placement)
6. Transitioning of inter-carrier seam supported via pilot beacons to inter-CBSC
seam.
7. Fallback strategy for seam transformation.
8. Transitioning of inter-carrier seam supported via DAHO to inter-CBSC SHO
seam.
9. Ability to implement 2nd carrier in hot spot areas along the seam.
13.2 New CDL format:
1. Perhaps pipe delimit the data (reduces file size).
2. Concentrate on reducing the file size.
3. Include new CFC for Anchor Handoff.
Page 325 of 328

4. Prior to removing any CFCs distribute the list to Systems Engineering.
13.3 Trouble-Shooting Guide:
Step by step guide to debugging of Inter-CBSC SHO features such as:

1. no audio on inter-CBSC calls
2. no inter-CBSC handoffs
3. poor audio on inter-CBSC calls
4. high failure rate of inter-CBSC Soft Handoff
5. high failure rate on inter-CBSC calls - procedural related
6. high failure rate on inter-CBSC calls - RF related
7. poor audio quality after anchor handoff
8. failures/dropped calls on anchor handoff
9. unexpected usage or blocking of BTS resources
10. increased latency of soft handoffs, adds and drops
13.4 Inter-CBSC Planning Guide:
Guide to planning the RF and infrastructure for the support the inter-CBSC feature.
1. seam placement rules*
2. MSC trunking rules
13.5 Inter-CBSC Application Note:
Information required by the customer for the deployment and maintenance of the inter-CBSC
SHO feature.
13.6 ATP for the Inter-CBSC SHO:
Define the acceptance test plan for the Inter-CBSC SHO feature.
13.7 Inter-CBSC Customer Presentation:
Presentation geared to customer base describing the inter-CBSC SHO feature.

1. Visuals on how the system will be laid out.
general seam placement procedures
MSC layout
CBSC to MSC connects
2. Present and future release expectations.
3. How we will track performance.
Page 326 of 328

4. General Anchor HO description/function.
Page 327 of 328

Page 328 of 328

14.0 Bibliography
1. Jim Marocchi’s LPA TEM
2. Dennis Schaeffer’s CDMA design tools
3. Handoff and Power Control System Functional Specification
Page 329 of 330

Page 330 of 330

I
Idle Handoff 155
Page 331 of 331

Handoff

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Handoff

Загружено:

Авторское право:

Доступные форматы

Motorola Confidential Proprietary

3.7 Pilot Beacon 42

4.0 Present Tools 127

5.0 CDMA Pilot Beacon Applications 133

5.5 Scenario B: Pilot Beacon to Perform Inter-CBSC Hard Handoffs 137

6.0 Idle Handoff Solution Description 155

8.0 Background 269

AHHO: see Anchor Hard Handoff

DAHO: see Data Base Assisted Handoff.

HHO. Hard HandOff.

MAHO: See Mobile Assisted Handoff

SHO. Soft HandOff.

XASECT (database parameter): eXternal Analog SECTor

XCSECT (database parameter): eXternal Cdma SECTor

2.0 Issues and Solutions

2.1 Hard Handoff after Soft Handoff

Figure 1: Simplified AHHO Seam Construction Layout

CBSC #1 “anchor-side” cell

“XCSECT” cell for CBSC #1

2.3 Seam Location

The primary goals of the AHHO deployment should be to simultaneously minimize

• AHHO mode performance.

Figure 2: Target Reliability as a function of active set Ec/Io

Target Connection Reliability

Active Set Ec/Io

2.5 AHHO Enhancements

Mobile Origination Procedure DAHO Procedure

Idle mode cell selection Active Set pilot rank ordering

Mobile Origination Message Pilot Strength Measurement Message

Channel Assignment Message Extended Handoff Direction Message

1-Way Connection at target 1-Way Connection at target

• Some probability that target sector/pilot will also be reference sector/pilot.

2.8 Inter-CBSC and Inter Carrier Hard Handoff

Figure 4: June 1997 PrimeCo Chicago Configuration

Figure 5: Late 1997 PrimeCo Chicago Configuration

CBSC #1 CBSC #2 CBSC #3

Figure 6: Wall-To-Wall Pilot Beacon

Figure 7: Late 1997 PrimeCo Chicago Configuration

TO: Ip Tim w10691 (Ip Tim W10691C)

Based on Hutchison’s CDMA system requirement, there will be a need

2.9 Inter-CBSC and Inter Carrier Soft Handoff

2.10 InterCBSC and Intra Carrier Hard Handoff

2.11 InterCBSC and Intra Carrier Soft Handoff

2.12 IntraCBSC and Inter Carrier Hard Handoff

2.13 IntraCBSC and Inter Carrier Soft Handoff

2.14 IntraCBSC and Intra Carrier Hard Handoff

2.15 IntraCBSC and Intra Carrier Soft Handoff

3.0 CDMA Handoff Deployment & Optimization

3.7 Pilot Beacon

3.9 Inter-Carrier Hard Handoff With Pilot Beacons (Multi-Carrier)

F1 Traffic Channels F1 Pilot Beacon F2 Traffic Channels

Path of mobile station Trigger Point

3.10 Inter-CBSC Hard Handoff With Pilot Beacons

Figure #8.) Ideal Inter-CBSC Hard Handoff With 4 RF Carriers (R5)

F4 Beacon (PPS) F4 PPS+TCH

F3 PPS+TCH F3 Beacon (PPS)

F2 PPS+TCH F2 Beacon (PPS)

F1 Beacon (PPS) F1 PPS+TCH

F3 Beacon (PPS) F3 PPS+TCH

F2 PPS+TCH F2 Beacon (PPS)

Figure #10.) Hong Kong R5 Inter-CBSC Solution

3.11 DAHO and Inter-CBSC Soft Handoff

3.13 Idle mode handoff