Upload
dodnikova
View
216
Download
0
Embed Size (px)
Citation preview
7/30/2019 07-Features 3 v&V
1/78
209
2.14 Handoff Procedures1
2.14.1 Handoff via MSC2
2.14.1.1 Introduction3Handoffs (both Intra-BS and Inter-BS) can occur for one of several reasons including radio4
propagation, traffic distribution, OAM&P activity, and equipment failure. See also sections 2.11.4,5
and 2.11.5 for packet data scenarios.6
Inter-BS Handoff: An Inter-BS handoff is attempted whenever a potential target may be outside7
of the domain of the source BS. The MSC may optionally use inter-BS hard handoff procedures to8
perform handoffs where the source BS and target BS are the same. Hard handoff includes inter-9
MSC hard handoff in which the source BS and the target BS are controlled by different MSCs.10
Intra-BS Handoff: An intra-BS handoff is a handoff performed under the domain of one BS. As11
such, the MSC is not involved in the execution of the handoff. Once an intra-BS hard handoff is12
successfully completed, the BS shall inform the MSC if the old cell is no longer involved in the13
call. Once an intra-BS soft/softer handoff is successfully completed, the BS shall inform the MSC14unless the designated cell concept is used, see section 2.14.1.1.3 (Concept of Designated Cell").15
2.14.1.1.1 Recognition That a Handoff is Required by a BS16
The BS shall be able to generate an indication that a hard handoff may be required to the MSC17
using the protocols defined.18
No additional guidance is given within this specification concerning the algorithm within the BS19
that generates either an Intra-BS handoff, or an indication to the MSC that an Inter-BS hard20
handoff is required.21
2.14.1.1.2 Recognition That a Handoff is Required by the MSC22
For this version of the standard, the MSC may not autonomously precipitate a handoff.23
2.14.1.1.3 Concept of Designated Cell24
A designated cell is a cell identifier (cell + sector) that is chosen by the BS to represent the25
mobile stations location. The initial cell identifier associated with the mobile stations activity26
(origination, termination, etc.) is by definition the first designated cell. When the air interface27
only supports connection of the mobile station to a single sector at a time, the designated cell is28
the currently connected sector. When the air interface supports connection of a mobile station to29
multiple sectors (possibly on different cells) simultaneously, e.g., CDMA soft/softer handoff, a30
single designated cell is to be identified to the MSC.31
As long as the original cell identifier that was provided to the MSC to identify the initial32
designated cell remains on the call, it may remain the designated cell. When the sector33
identified as the designated cell is removed from the call, the BS currently serving as the source34
BS for the call chooses a new designated cell from the set of sectors serving the call and shall35
provide the appropriate cell identifier to the MSC. The source BS may choose a new designated36
cell at any time from the set of cells currently serving the call. The technique for choice of a37
designated cell is an operator/manufacturer concern.38
7/30/2019 07-Features 3 v&V
2/78
210
The notification to the MSC can be implicit through the use of the inter-BS handoff procedure1
(Handoff Required, Handoff Request, Handoff Request Acknowledge, Handoff Command2
messages), or explicit through the use of the Handoff Performed message. The implicit3
notification occurs when the handoff type is a hard handoff. The change of designated cell occurs4
upon receipt of the Handoff Complete message.5
2.14.1.2 Inter-BS Hard Handoff 6
This section discusses the protocol to support hard handoff transitions where the source and target7
cells are under the domain of different BSs. For this version of the standard, it is assumed that the8
only CDMA traffic channels that may be transferred via inter-BS hard handoff are the9
Fundamental and Dedicated Control Channels (FCH and DCCH, resp.). Hard handoff of the10
Supplemental Channel is not supported in this version of the standard.11
For a MS operating on the CDMA traffic channel, an inter-BS hard handoff may occur while the12
MS is in the Conversation State, orWaiting for Answer State.13
2.14.1.2.1 Triggering Phase14
Hard handoff triggering is initiated by the MS or the source BS.15
2.14.1.2.2 Target Determination Phase16
Having received an indication from a BS that an Inter-BS hard handoff is required, the decision of17
when and whether an Inter-BS hard handoff is to take place shall be made by the MSC. Inter-BS18
soft/softer handoff decisions can be made by the source and target BSs involved, see section19
2.14.2 (Handoff via Direct BS-to-BS Signaling).20
Procedures for inter-BS hard handoffs are discussed in section 2.14.1.2(Inter-BS Hard Handoff),21
and the procedures for intra-BS handoffs are discussed in section 2.14.1.5 (Intra-BS Handoff).22
Procedures for multi-carrier (MC) inter-BS soft/softer handoff are discussed in section 2.14.223
(Handoff via Direct BS-to-BS Signaling). Message Transaction diagrams for each of these24
procedures can be found in section 2.14.3 (Handoff Call Flows). Message formats and definitions25of timers used within this chapter can be found in the associated interface documents.26
2.14.1.2.3 Resource Establishment27
28
2.14.1.2.4 Execution Phase29
30
2.14.1.3 Call Clearing31
The call clearing procedure is described in section 2.2. It is used in hard handoff scenarios to32
release the source RF channel and terrestrial resource after either the mobile has been acquired by33
the target BS or the call is dropped.34
The MSC may use call clearing to tear down either the source channel, the target channel, or both35
in the event of a failure in the handoff process. The call clearing messages are only used to clear36
full-rate circuits.37
7/30/2019 07-Features 3 v&V
3/78
211
The Clear Command message shall contain a cause field to inform the source or target cell of the1
success or failure of the handoff procedure. This indication can be used for statistics purposes.2
2.14.1.4 Handoff Failure Handling3
There are two messages that indicate a failure in the handoff process; the Handoff Required Reject4
and the Handoff Failure messages. These messages are discussed in this section. Also, refer to5section 2.14.3.1.4 (Hard Handoff With Return On Failure).6
When a traffic channel is not available at the target BS, several options are available:7
Option 1 Target can allocate AMPS channel8
Option 2 Target indicates failure to MSC, MSC attempts to allocate AMPS9
channel.10
Option 3 Target indicates failure then MSC passes it along to the source BS and11
lets the source BS decide.12
Option 3 shall be supported.13
NOTE: This standard does not specify the messaging required for Option 1. Support and14
implementation of this option is a vendor concern.15
2.14.1.5 Intra-BS Handoff 16
17
2.14.2 Handoff via Direct BS-to-BS Signaling18
Efficient inter-BS soft handoff is supported via direct BS to BS signaling and traffic connections19
between base stations. The A3 and A7 interfaces are used to support this form of inter-BS soft20
handoff which is based on packet technologies.21
The A3 interface, composed of signaling and user traffic subchannels, provides the ability to22 establish and remove A3 traffic connections. The A3 interface also provides support for23
operational procedures, such as turning on/off voice privacy or changing the service configuration24
of a call.25
The A7 interface provides direct BS to BS signaling for the support of efficient soft handoff. Only26
a call release procedure should interrupt any Handoff procedure. Multiple concurrent A7 Handoff27
Add procedures are prohibited for the same physical channel on the same call. Multiple concurrent28
A7 Handoff Drop procedures for the same physical channel on the same call are prohibited.29
2.14.2.1 A3 Interface Procedures and Messages30
This section contains the procedure definitions and message overviews for the A3 interface. It is31
organized into four subsections:32
A3 Interface Setup Procedures and Messages,33
A3 Interface Operational Procedures and Messages,34
A3 Interface Clearing Procedures and Messages, and35
A3 Interface Scenarios.36
7/30/2019 07-Features 3 v&V
4/78
212
2.14.2.1.1 A3 Interface Setup Procedures and Messages1
This section contains the messages used to set up an A3 connection.2
2.14.2.1.2 A3 Interface Operational Procedures and Messages3
This section contains messages used on the A3 connection to support an A3 call leg.4
2.14.2.1.3 A3 Interface Clearing Procedures and Messages5
This section contains messages used to clear an A3 connection.6
2.14.2.2 A7 Interface Procedures and Messages7
This section describes the messages and procedures used between base stations on an A78
connection to support direct BS to BS soft/softer handoff, access handoff, access probe handoff,9
and channel assignment into soft/softer handoff.10
2.14.2.2.1 A7 Interface Messages11
This section describes the messages and procedures used between base stations on an A712
connection to support direct BS to BS soft/softer handoff, access handoff, access probe handoff,13
and channel assignment into soft/softer handoff. These messages are:14
A7-Handoff Request15
A7-Handoff Request Ack16
A7-Drop Target17
A7-Drop Target Ack18
A7-Target Removal Request19
A7-Target Removal Response20
A7-Paging Channel Message Transfer21
A7-Paging Channel Message Transfer Ack22
A7-Access Channel Message Transfer23
A7-Access Channel Message Transfer Ack24
A7-Burst Request25
A7-Burst Response26
A7-Burst Commit27
The following A7 interface message may be received by any target BS if requested via the A7-28
Handoff Request Ack message using the A7-Control element:29
A7-Source Transfer Performed30
The A7-Source Transfer Performed message is used as part of an optional feature. This feature31
may only be needed for an IOS compliant BS that is integrated into a system that includes32
equipment that does internal source transfers, i.e., transfers of the control of a call from one source33
BS to another source BS. The source transfer procedure is not part of the IOS. See the informative34
Optional Features Annex B for more information.35
7/30/2019 07-Features 3 v&V
5/78
213
1
2.14.2.3 Soft/Softer Handoff Addition2
The source BS decides what cells are to be added to a call in soft/softer handoff. An A7-Handoff3
Request message is sent directly to the target BS across the A7 connection between the source and4
target BSs to request the addition of those cells to the call. The target BS allocates and connects5
the appropriate resources and responds directly to the source BS using an A7-Handoff Request6
Ack message once all expected A3-Connect Ack messages have been received.7
The A3-Connect message is used by the target BS to both create new A3 connections for a call,8
and to add cells to existing A3 connections. In either case, information on all cells attached to the9
A3 connection shall be included in the A3 Connect Information element, and there shall be an10
indication as to which cells were already existing and which cells were newly associated with the11
A3 connection.12
The A3-Connect message can be used to establish multiple A3 connections. To support this13
capability, multiple sets of cell information may be included. A single A3-Connect Ack message14
is used to respond to an A3-Connect message, regardless of the number of A3 connections being15
established via the A3-Connect message. The A3-Connect Ack message is returned to the address16from which the A3-Connect message was sent.17
In response to an A7 Handoff Request message that includes multiple cells to be added to the call18
association in soft or softer handoff, the target BS may send a single A3-Connect message19
including information for multiple connections, or it may send multiple A3-Connect messages20
where each message includes information for a single connection only. However, the target BS21
shall not send multiple A3-Connect messages that each include multiple connection information,22
nor any combination of such messages and A3-Connect messages that include information for a23
single connection. The requirements of this paragraph may be relaxed in a future revision of this24
standard.25
The A3-Connect Ack and A3-Traffic Channel Status messages support the ability of the source26
BS to request that the target BS send a notification that the target BS transmitter(s) and receiver(s)27are turned on.28
2.14.2.4 Soft/softer Handoff Removal29
Removal of cells in soft/softer handoff involves the sending by the source BS of an A7-Drop30
Target message to the target BS. The target BS removes the indicated cells and responds with an31
A7-Drop Target Ack message. If the last cell(s) attached to a particular A3 connection are32
removed, the target BS will initiate removal of that A3 connection also.33
2.14.2.5 Cell Removal by a Target BS34
For a variety of reasons, a target BS may need to request that one or more of its cells be removed35
from a call. This request can be for reasons of internal resource management, OA&M, internal BS36error situations, etc. The target BS, in these cases, sends an A7-Target Removal Request message37
to the source BS with appropriate information to indicate what cells need to be removed from the38
call, and for what reason(s). The source BS take the appropriate actions and respond with an A7-39
Target Removal Response message or it may indicate to the target BS that the target cell(s) are to40
remain in the call.41
7/30/2019 07-Features 3 v&V
6/78
214
1
2.14.2.6 Call Clearing2
Call clearing for calls using packet based soft/softer handoff is always accomplished via the source3
BS. If the call clearing is initiated by either the MS or source BS, a Clear Request message will be4
sent to the MSC to request call clearing. If the MSC initiates the call clearing, it sends a Clear5
Command message to the source BS. Clear Command messages are not sent to target BSs6
involved in the call. Instead, the source BS is responsible for using the A7 interface drop target7
procedure to remove all target BSs from the call.8
When the A7 target drop procedure is used during call release scenarios, the A7 drop target9
message shall contain the cell identify list with zero cells included. In this case, the source should10
wait some period of time to allow any in progress Adds or Drops to complete prior to sending the11
A7 Drop Message.12
2.14.2.7 Handoff Performed13
The source BS is responsible for sending Handoff Performed messages to the MSC to keep it14
informed of the identity of the cells currently involved in supporting the call.15
See also sections 2.14.1.1.3 Concept of Designated Cell and IS-2001-B-3 Inter-Operability16
Specification (IOS) for CDMA2000 Access Network Interfaces A1/A2/A5.the A Interface17
Document18
2.14.2.8 Access Handoff and Channel Assignment into Soft Handoff19
In addition to setting up soft handoff legs during a call, the soft handoff legs can also be setup20
during the establishment of the call. This procedure is required to support the access probe21
handoff, access handoff, and channel assignment into soft/softer handoff.22
The source BS decides what cells are to be setup in soft/softer handoff during the establishment of23
the call and the A7-Handoff Request procedure is used. That is, an A7-Handoff Request message24
is sent directly to the target BS across the A7 connection between the source and target BSs to25
request the setup of those cells to the call. The target BS allocates and connects the appropriate26
resources and responds directly to the source BS using an A7-Handoff Request Ack message once27
all expected A3-Connect Ack messages have been received.28
Cells that are likely candidates for access probe handoff and access handoff by the MS are29
included in the ACCESS_HO_LIST.30
For each message received on one of its access channels, the BS shall analyze the31
PILOT_RECORD if such a record is included in the message. If the BS does not correspond to the32
first attempted pilot in the record (i.e., is not the source BS), then it shall forward the access33
channel message on an inter-BS (i.e., A7) link corresponding to the first attempted pilot in the34
record. If the access channel message is an Origination or Page Response, the BS shall forward the35
message as indicated above and shall not send the corresponding CM Service Request message or36
Paging Response message to the MSC.37
The source BS sends A7-Paging Channel Message Transfer messages carrying an appropriate38
channel assignment information to selected BSs, usually chosen from those contained in the39
ACCESS_HO_LIST and OTHER_REPORTED_LIST, requesting that they send the channel40
assignment message on specific cells. The channel assignment message is used to assign the41
forward channel(s) to the MS.42
7/30/2019 07-Features 3 v&V
7/78
215
The set of BSs to which the source BS sends the A7 Paging Channel Message Transfer message1
may be different from the set of BSs that are set up in soft handoff.2
See section 2.1.2.2 for an example scenario showing access probe handoff, access handoff and3
channel assignment into soft/softer handoff.4
See also IS-2001-B-4 Inter-Operability Specification (IOS) for CDMA2000 Access Network5 Interfaces A3/A7the Ater Interface Document for information on the A7-Paging Channel6
Message Transfer, A7-Paging Channel Message Transfer Ack, A7-Access Channel Message7
Transfer, and A7-Access Channel Message Transfer Ack messages.8
2.14.2.9 Soft/Softer Handoff of High Speed Packet Data9
Support of high speed packet data (i.e., speeds greater than 14.4 kbps) may be accomplished10
through the use of multiple physical channels. These physical channels are supported in the11
infrastructure using A3 traffic connections during soft/softer handoff. Setup of an A3 connection12
for a traffic burst is accomplished using A7-Burst Request, A7-Burst Response, A7-Burst13
Commit, and A7-Burst Release messages. Establishment of the A3 connection for the14
supplemental channel (SCH) is accomplished via the A7-Handoff Request, A7-Handoff Request15
Ack, A3-Connect and A3-Connect Ack messages.16
In this version of this standard, it is assumed that any leg for a supplemental channel will be17
established on a cell that already supports a leg for the fundamental channel (FCH) or the18
dedicated control channel (DCCH) for the same mobile station. To minimize the time required to19
establish a traffic burst, the A3 connection for an SCH is established on the target BS at the20
transmission of the first data burst. When a leg is established for an SCH, only the terrestrial21
resources are allocated, i.e., the A3 connection. This involves choosing the traffic circuit to be22
used and establishing context between the target BS and the source BS/SDU function. Allocation23
of radio resources for the SCH is made each time that a traffic burst is set up.24
When the source BS realizes that it is necessary to allocate radio resources for a traffic burst in25
either the forward or reverse direction or both, it sends an A7-Burst Request message to each26
target BS to request reservation of specific radio resources. Each target BS responds with A7-27
Burst Response message(s) to indicate radio resource reservations for the requested cells. Once the28
source BS has received the A7-Burst Response messages, it sends either A7-Burst Commit or A7-29
Burst Release message(s) to each target BS to indicate the set of radio resources to be used. A30
burst time that requires the message to be pending for more that 7/8 of the modulo window in the31
future from its time of arrival be considered late and the message shall be processed immediately.32
End time shall still be calculated from the specified start time and duration. Each target BS33
receiving A7-Burst Commit then prepares the indicated cell, connects it to the pre-established A334
connection, and then participates in the burst. Each target BS receiving A7-Burst Release then35
releases the resources reserved at the indicated cell(s). Both cases are shown in examples in36
section 2.14.3.2.37
2.14.2.9.1 Soft/Softer Handoff of Forward Link Bursts of Data38
When a traffic burst is scheduled to begin, the SDU function begins to transmit forward link39
frames carrying user traffic on the A3 connection for the SCH. At the termination of a traffic burst40
in the forward direction, the SDU function ceases transmitting frames on the SCH A3 connection.41
The SDU function may begin to send idle frames on the forward A3 connection prior to the42
beginning of the burst to allow synchronization of the A3 connection. If the target BS receives43
forward idle frames and is not receiving reverse frames from the MS, it shall send reverse idle44
frames to the SDU function to allow packet arrival time error adjustments to occur.45
7/30/2019 07-Features 3 v&V
8/78
216
The SDU function shall send no more than 9144 bits (i.e., 3 frames of data for a burst at 153.61
KBPS) to the target BS prior to the beginning of a traffic burst in the forward direction.2
When a new traffic burst is initiated on an A3 connection for a SCH, the target BS shall wait for3
the first forward link frame before transmitting any reverse link frames. If the target BS receives a4
forward link Idle Frame, it shall calculate the packet arrival time error and transmit that5
information on the reverse link in an Idle Frame if it has no user traffic to transmit in a non-idle6
frame. The target BS shall not transmit any air interface frame when receiving a forward link Idle7
Frame. In this way, the SDU function can control precisely the beginning of forward link traffic8
bursts on physical channels.9
The source BS may suppress (i.e., not transmit) an A3-IS-2000 SCH Forward message with10
Forward Layer 3 Data elements containing Null or Idle frame contents. See the IS-2001-B-4 Inter-11
Operability Specification (IOS) for CDMA2000 Access Network Interfaces A3/A7Ater12
Interface Document (IS-2000 Frame Content) for Source and Target operations with Null and13
Idle frames.14
The target BS may suppress (i.e., not transmit) an A3-IS-2000 SCH Reverse message with15
Reverse Layer 3 Data information elements containing Null or Idle frame contents if, and only if,16
an A3-IS-2000 SCH Forward message was not received in the previous air-frame period. See IS-17
2001-B-4 Inter-Operability Specification (IOS) for CDMA2000 Access Network Interfaces 18
A3/A7the Ater Interface Document (IS-2000 Frame Content) for Source and Target operations19
with Null and Idle frames.20
2.14.2.9.2 Soft/Softer Handoff of Reverse Link Bursts of SCH Data21
When a traffic burst is expected by a target BS, the target BS shall wait as indicated above for the22
first forward link frame so that the packet arrival time error can be correctly calculated. Following23
reception of each forward link frame at the target24
BS, the target BS shall transmit a reverse link frame. Reverse link frames may contain user traffic25
(i.e., packet data), Idle Frames, Null Frames, Re-Acquiring Frames, or Erasure Frames. Reverse26
link frames containing user traffic, Re-Acquiring Frames, or Erasure frames (i.e., decoded from27
the air interface) may be sent without prior reception of forward link frames.28
The target BTS shall decide whether Erasure Frames, Re-Acquired Frames, or Null Frames should29
be sent to the SDU in the cases of DTX or loss of finger lock.30
7/30/2019 07-Features 3 v&V
9/78
217
1
2.14.3 Handoff Call Flows2
2.14.3.1 Hard Handoff (via MSC)3
4
2.14.3.1.1 Successful Hard Handoff5
The following call flow diagram provides an illustration for a successful hard handoff event. It is6
assumed that the call is not in inter-BS soft/softer handoff prior to the hard handoff, and thus no7
A3 connections need to be removed.8
MS Source BS MSC TimeComment
a
b
c
d
e
f
g
Handoff Required
Handoff Request
Handoff Command
Handoff Direction Message
MS Ack Order
Target BS
Null forward traffic channel frames
Handoff Request Ack
T7
T9
Handoff Commenced h
j
i
k
l
m
n
Reverse Traffic Channel Frames or Traffic Channel Preamble
Handoff Completion Message
Clear Command
Clear Complete
BS Ack Order
Handoff CompleteT306
T315
Twaitho
x
T11
9
Figure 2.14.3.1.1-1 - Successful Hard Handoff10
7/30/2019 07-Features 3 v&V
10/78
218
a. Based on an MS report that it crossed a network specified threshold for signal1
strength or for other reasons, the source BS recommends a hard handoff to one2
or more cells in the domain of the target BS. The source BS sends a Handoff3
Required message with the list of cells to the MSC and starts timer T7.4
b. The MSC sends a Handoff Request message to the target BS with the IS-955
Channel Identity element or the IS-2000 Channel Identity element present6
since the hard handoff bit was set and/or the Handoff Type element in the7Handoff Required message indicated hard handoff. The MSC starts timer T11.8
In the case of hard handoff for an async data/fax call, the Circuit Identity9
Code Extension element in the Handoff Request message indicates the Circuit10
Identity Code of the circuit to be connected to the SDU function at the target11
BS to support the A5 connection to the IWF.12
c. Upon receipt of the Handoff Request message from the MSC, the target BS13
allocates appropriate radio resources as specified in the message and connects14
the call. As the Handoff Request message can have multiple cell(s) specified,15
the target BS can also choose to setup multiple cell(s) for the handoff request.16
The target BS sends null forward traffic channel frames to the MS.17
d. The target BS sends a Handoff Request Acknowledge message to the MSC.18
The target BS starts timer T9 to wait for arrival of the MS on its radio19channel. The first cell in the cell identifier list element of the message will be20
treated as the new designated cell by the MSC. The change of designated cell21
occurs upon receipt of the Handoff Complete message. If the service option22
received in the Handoff Request message is not available at the target BS and23
the target BS selected a different service option for the handoff then the target24
BS shall include the service option it selected in the Service Configuration25
Record IE.26
e. Upon receipt of the Handoff Request Acknowledge message the MSC stops27
timer T11. The MSC prepares to switch from the source BS to the target BS28
and sends a Handoff Command to the source BS. The MSC shall include the29
service option it received from the Handoff Request Acknowledgement30
message in the Handoff Command message. The source BS stops timer T7.31
f. The source BS sends the handoff direction message1to the MS across the air32interface. If the MS is allowed to return to the source BS, then timer Twaitho33
is also started by the source BS.34
g. The MS may acknowledge the handoff direction message by sending a MS35
Ack Order to the source BS.36
If the handoff direction message is sent using quick repeats, the source BS37
might not request an acknowledgment from the MS.38
h. The source BS sends a Handoff Commenced message to the MSC to notify it39
that the MS has been ordered to move to the target BS channel. The source BS40
starts timer T306 to await the Clear Command message from the MSC. If41
timer Twaitho has been started, the source BS shall wait for that timer to42
expire before sending the Handoff Commenced message.43
i. The MS sends reverse traffic channel frames or the traffic channel preamble to44
the target cell(s).45
1 This may be a Handoff Direction Message, a General Handoff Direction Message, an
Extended Handoff Direction Message, or a Universal Handoff Direction Message as
appropriate.
7/30/2019 07-Features 3 v&V
11/78
219
j. The MS sends a Handoff Completion Message to the target BS.1
k. The target BS sends the BS Ack Order to the MS over the air interface.2
l. The target BS sends a Handoff Complete message to the MSC to notify it that3
the MS has successfully completed the hard handoff. The target BS stops4
timer T9.5
m. The MSC sends a Clear Command to the source Bs and starts timer T315. The6source BS stops timer T306. .7
In the case of hard handoff for an async data/fax call, clearing of all resources8
including the A5 connection at the old BS is accomplished via the Clear9
Command message.10
n. The source BS sends a Clear Complete message to the MSC to notify it that11
clearing has been accomplished. The MSC stops timer T315.12
2.14.3.1.2 Successful Hard Handoff to ANSI/TIA/EIA-553-A Systems13
For the purpose of this specification, the single MSC in the following figure represents the source14
and the target MSC connected by TIA/EIA IS-41. The message flows between the target MSC and15
the target BS in the figure are not required.16
The following call flow diagram provides an illustration for a successful hard handoff event to an17
ANSI/TIA/EIA-553-A system.18
MS MSC
time comment
a
b
c
d
e
f
g
h
Analog Handoff Direction Msg
Handoff Required
i
Handoff Request
Handoff Request Ack
Handoff Command
Handoff Commenced
Handoff Complete
Clear Command
Clear Complete
T7
T9
j
k
Acknowledge Order
Transponded SAT
T306
T315
Source
BS
Target
BS
T11
19
Figure 2.14.3.1.2-1 - Successful Hard Handoff to an ANSI/TIA/EIA-553-A System20
a. Based on an MS report that it has crossed a network specified threshold for21
signal strength, the source BS recommends a hard handoff to one or more22
cells in the domain of the target BS. The source BS sends a Handoff Required23
message with the Cell Identifier List to the MSC to find a target with available24
resources and starts timer T7. The source BS indicates a response requirement25
by including the Response Request element.26
7/30/2019 07-Features 3 v&V
12/78
220
b. The MSC sends a Handoff Request message to the target BS without theIS-951
nor the IS-2000 Channel Identity element present, since this is a CDMA to2
Analog hard handoff request. The MSC starts timer T11.3
c. The target BS determines that appropriate resources are available and returns4
a Handoff Request Acknowledge message to the MSC. The target BS then5
starts timer T9.6
d. Upon receipt of the Handoff Request Acknowledge message from the target7
BS, the MSC stops T11 and sends a Handoff Command message to the source8
BS to convey information from the target BS to the source BS. Timer T7 is9
stopped when a Handoff Command message is received.10
e. Upon receipt of the Handoff Command message from the MSC, the source BS11
transmits the Analog Handoff Direction Message to the MS and may request a12
Layer 2 acknowledgment.13
f. The MS returns an MS Ack Order to the source BS to confirm receipt of the14
Analog Handoff Direction Message.15
If the handoff direction message is sent using quick repeats the source BS16
might not request an acknowledgement from the MS.17
g. The source BS sends a Handoff Commenced message to the MSC to notify it18
that the MS has been ordered to move to the target BS channel. The source BS19
starts timer T306 to await the Clear Command from the MSC.20
h. The MS tunes to the target BS SAT and initiates transmission of transponded21
SAT. The target BS stops timer T9.22
i. Upon reception of the correct MS transponded Supervisory Audio Tone23
(SAT), the target BS sends a Handoff Complete message to the MSC to24
indicate that the MS has successfully accessed the target BS.25
j. The MSC releases the source BSs terrestrial circuit and instructs the source26
BS to release its radio resources by sending a Clear Command message to the27
source BS with the Cause element set to Handoff successful. The MSC28
starts timer T315. The source BS stops timer T306 when the Clear Command29 message is received.30
k. The source BS releases its source channel, clears any terrestrial resources, and31
then returns a Clear Complete message to the MSC to indicate that the32
transition is complete. The MSC stops timer T315 when the Clear Complete33
message is received.34
7/30/2019 07-Features 3 v&V
13/78
221
1
2.14.3.1.3 Unsuccessful Hard Handoff to ANSI/EIA/TIA-553: ANSI/TIA/EIA-553-A2Alternative Rejected3
For the purpose of this specification, the single MSC in the following figure represents the source4
and the target MSC connected by TIA/EIA IS-41. The message flows between the target MSC and5
the target BS in the figure are informative and are not required.6
The following call flow diagram provides an illustration of an unsuccessful Hard Handoff. In this7
example, the source BS determines that an ANSI/TIA/EIA-553-A alternative is not acceptable,8
rejects the Handoff Command and maintains the mobile.9
MS MSC
time comment
a
b
c
d
e
f
g
Handoff Required
Handoff Request
Handoff Request Ack
Handoff Command
Handoff Failure
Clear Command
Clear Complete
T7
T9
T315
Source
BS
Target
BS
T11
10
Figure 2.14.3.1.3-1 - Unsuccessful Hard Handoff to ANSI/EIA/TIA-553:11
ANSI/TIA/EIA-553-A Alternative Rejected12
a. Based on an MS report that it has crossed a network specified threshold for13 signal strength, the source BS recommends a hard handoff to one or more14
cells in the domain of the target BS. The source BS sends a Handoff Required15
message with the Cell Identifier List to the MSC to find a target with available16
resources. The source BS indicates a response requirement by including the17
Response Request element. The source BS then starts timer T7.18
b. The MSC constructs a preferred list of targets for polling and sends a Handoff19
Request message to the target BS with neither the IS-95 nor the IS-200020
Channel Identity element present since the hard handoff bit is set. The MSC21
starts timer T11.22
c. The target BS determines that a channel resource is not available and reserves23
or allocates an ANSI/TIA/EIA-553-A channel. The target BS sends a Handoff24
Request Acknowledge message to the MSC informing it of the availability of25
the ANSI/TIA/EIA-553-A channel and starts timer T9. The MSC stops timer26
T11.27
d. The MSC sends a Handoff Command message to the source BS to convey28
information from the target BS to the source BS. In the Handoff Command,29
the Handoff Type element, if present, shall be set to CDMA-Analog Hard30
HO.31
Timer T7 is stopped at the source BS when a Handoff Command message is32
received, or a Reset message is received.33
7/30/2019 07-Features 3 v&V
14/78
222
e. Upon receipt of the Handoff Command message from the MSC, the source BS1
recognizes that an ANSI/TIA/EIA-553-A channel has been supplied and2
decides to reject the assignment. The source BS keeps the MS and sends a3
Handoff Failure message to the MSC with the Cause element set to Alternate4
signaling type reject.5
f. The MSC releases the target BSs terrestrial circuit and instructs the target BS6
to release its radio resources by sending a Clear Command message to the7target BS and starts timer T315.8
The target BS stops timer T9.9
g. Upon receipt of the Clear Command message from the MSC, the target BS10
releases its radio resource. The target BS then returns a Clear Complete11
message to the MSC to indicate that the resource release operation is12
complete. The MSC stops timer T315 when the Clear Complete message is13
received.14
7/30/2019 07-Features 3 v&V
15/78
223
1
2.14.3.1.4 Hard Handoff With Return On Failure2
The following call flow diagram provides an illustration for a hard handoff event. In this scenario,3
the mobile station successfully returns to the source BS after hard handoff fails. It is assumed that4
the call is not in inter-BS soft/softer handoff prior to the hard handoff, and thus no inter-BS5
connections need to be removed.6
MS Source BS MSC TimeComment
a
b
c
d
e
f
g
Handoff Required
Handoff Request
Handoff Command
handoff direction message
MS Ack Order
Target BS
Null forward traffic channel frames
Handoff Request Ack
T7
T9
h
i
j
k
Clear Command
Handoff Failure
CF Search Report Message
Clear CompleteT315
Twaitho
T11
7
Figure 2.14.3.1.4-1 Hard Handoff With Return On Failure8
a. Based on an MS report that it crossed a network specified threshold for signal9
strength or for other reasons, the source BS recommends a hard handoff to one10
or more cells in the domain of the target BS. The source BS sends a Handoff11
Required message with the list of cells to the MSC and starts timer T7.12
b. The MSC sends a Handoff Request message to the target BS with the IS-9513
Channel Identity element or the IS-2000 Channel Identity element present14
since the hard handoff bit was set and/or the Handoff Type element in the15
Handoff Required message indicated hard handoff. The MSC starts timer T11.16
In the case of hard handoff for an async data/fax call, the Circuit Identity17
Code Extension element in the Handoff Request message indicates the Circuit18
Identity Code of the circuit to be connected to the SDU function at the target19
BS to support the A5 connection to the IWF.20
c. Upon receipt of the Handoff Request message from the MSC, the target BS21
allocates appropriate radio resources, as specified in the message, and22
connects it to the terrestrial circuit. The target BS sends null forward traffic23
channel frames to the MS.24
7/30/2019 07-Features 3 v&V
16/78
224
d. The target BS sends a Handoff Request Acknowledgment message to the1
MSC. The target BS starts timer T9 to wait for arrival of the MS on its radio2
channel. The MSC receives the Handoff Request Acknowledgment message3
from the BS and the MSC stops timer T11.4
e. The MSC prepares to switch from the source BS to the target BS and sends a5
Handoff Command to the source BS. The source BS stops timer T7.6
f. The source BS sends the handoff direction message2to the MS across the air7
interface. The source BS indicates in the message that the MS is permitted to8
return to the source BS if handoff to the target fails. The source BS starts9
timer Twaitho.10
g. The MS may acknowledge the handoff direction message by sending a MS11
Ack Order to the source BS.12
If the handoff direction message is sent using quick repeats, the source BS13
might not request an acknowledgment from the MS.14
h. The MS sends a Candidate Frequency (CF) Search Report Message to the15
source BS after handoff to the target has failed. The source BS stops timer16
Twaitho.17
i. Upon receipt of the CF Search Report Message from the MS the source BS18
detects that the MS has never accessed the target BS cell and sends a Handoff19
Failure message to the MSC with the Cause element set to Reversion to old20
channel.21
j. The MSC sends a Clear Command to the target BS. The target BS stops timer22
T9. The MSC starts timer T315.23
k. Upon receipt of the Clear Command message from the MSC, the target BS24
releases and deallocates radio and terrestrial resources.25
The target BS then sends a Clear Complete message to the MSC. The MSC26
stops timer T315.27
2 This may be a Handoff Direction Message, a General Handoff Direction Message, an
Extended Handoff Direction Message, or a Universal Handoff Direction Message as
appropriate.
7/30/2019 07-Features 3 v&V
17/78
225
1
2.14.3.1.5 Hard Handoff Failure Connection Refused2
The following call flow diagram provides an illustration for a hard handoff failure event. In this3
scenario, the target BS notifies the MSC that the handoff has failed by sending a Handoff Failure4
Message as a Connection Refused (CREF) message. It is assumed that the call is not in inter-BS5
soft/softer handoff prior to the hard handoff, and thus no inter-BS connections need to be6
removed.7
Source BS MSC TimeComment
a
b
c
d
Handoff Required
Handoff Request
Handoff Required Reject
Target BS
Handoff Failure
T7
T11
8
Figure 2.14.3.1.5-1 Hard Handoff Failure9
a. Based on an MS report that it crossed a network specified threshold for signal10
strength or for other reasons, the source BS recommends a hard handoff to one11
or more cells in the domain of the target BS. The source BS sends a Handoff12
Required message with the list of cells to the MSC and starts timer T7.13
b. The MSC sends a Handoff Request message to the target BS with the IS-9514
Channel Identity element or the IS-2000 Channel Identity element present15
since the hard handoff bit was set and/or the Handoff Type element in the16
Handoff Required message indicated hard handoff. The MSC starts timer T11.17
In the case of hard handoff for an async data/fax call, the Circuit Identity18
Code Extension element in the Handoff Request message indicates the Circuit19
Identity Code of the circuit to be connected to the SDU function at the target20
BS to support the A5 connection to the IWF.21
c. The target BS receives the Handoff Request message but is unable to22
accommodate the handoff request. The target BS then sends a Handoff Failure23
message as a SCCP Connection Refused message to the MSC.24
d. Upon receipt of the Handoff Failure message, the MSC stops timer T11. The25
MSC then sends a Handoff Required Reject message to the Source BS. Upon26
receipt of the Handoff Required Reject message, the Source BS stops timer27
T7. A new handoff procedure may be initiated if the condition of the call28
connection warrants immediate action.29
7/30/2019 07-Features 3 v&V
18/78
226
1
2.14.3.2 Soft/softer Handoff Using Direct BS to BS (A3 and A7) Connections2
3
2.14.3.2.1 Soft/softer Handoff Addition4
Soft/softer handoff addition occurs as shown in the following diagram. Soft/softer handoff5
addition includes both the creation of new A3 traffic connections, as well as the addition of cells to6
existing A3 traffic connections. In this section, A3-CEData Forward/Reverse messages7
represent A3-IS-95 FCH Forward/Reverse, A3-IS-2000 FCH Forward/Reverse, or A3-IS-8
2000 DCCH Forward/Reverse messages. For SCH soft/softer handoff addition, see Sections9
2.14.3.2.4 and 2.14.3.2.5.10
Source BS Target BSMS MSC
A7- Handoff Request
A3-Connect
A3-Connect Ack
A7- HandoffRequest Ack
A3-Traffic Channel Status
handoff direction message
Handoff Performed
a
b
c
g
h
i
j
Time Comment
Conditional:
(See AterInterface
Document)
MS Ack Order
Handoff Completion Message
BS Ack Order
k
l
m
Thoreq
Tconn3
dA3-CEData Forward (Forward Frames)
Forward Frames
e
f
A3-CEData Reverse (Idle Frames)
Conditional:
(See section
2.14.1.1.3)
11
Figure 2.14.3.2.1-1 - Soft/softer Handoff Addition12
a. The source BS decides that one or more cells at the target BS are needed to13
support the call in soft/softer handoff. The source BS sends an A7-Handoff14
Request to the target BS and starts timer Thoreq.15
b. The target BS initiates an A3 traffic connection (or adds to an existing one) by16
sending an A3-Connect message to the source BS and starts timer Tconn3.17
Note that a single A7-Handoff Request message may result in multiple A318
traffic connections being established, each using a separate A3-Connect19
message. This example shows only a single A3 traffic connection being20
established.21
7/30/2019 07-Features 3 v&V
19/78
227
c. The source BS replies with an A3-Connect Ack message to complete the A31
connection or to acknowledge the addition of cells to an existing A32
connection. The target BS stops timer Tconn3.3
d. The source BS begins to send forward frames to the target BS.4
d.The target BS begins to send reverse idle frames as soon as the first forward frame is5
received from the source BS. The reverse frames contain the timing adjustment6
information necessary to achieve synchronization.7
e.The target BS begins to transmit the forward frames as soon as synchronization has8
occurred.9
g. The target BS sends an A7-Handoff Request Ack message to the source BS to10
indicate the success of the cell addition(s). The source BS stops timer Thoreq.11
h. If the source BS has chosen to be notified of the start of transmission and12
reception at the target BS, when its SDU function and the target BS have13
synchronized the A3 traffic subchannel, the target BS replies with an A3-14
Traffic Channel Status message. See also IS-2001-B-4 Inter-Operability15
Specification (IOS) for CDMA2000 Access Network Interfaces A3/A7 the16
Ater Interface Document A3-Connect Ack. Note that this step may occur17
any time after step (d).18
i. The source BS sends a handoff direction message3to the mobile station to add19
the new cell(s) to the active set.20
j. The mobile station acknowledges receipt of the handoff direction message21
with an MS Ack Order.22
k. The mobile station indicates successful results of processing the handoff23
direction message by sending a Handoff Completion Message.24
l. The source BS acknowledges receipt of the Handoff Completion Message by25
sending a BS Ack Order.26
m. The source BS may send a Handoff Performed message to the MSC. See27
section 2.14.1.1.3 ("Concept of A "Designated Cell"). The Handoff28
Performed message may be sent any time after the Handoff Completion29Message is received by the BS.30
31
3 This may be a Handoff Direction Message, a General Handoff Direction Message, an
Extended Handoff Direction Message, or a Universal Handoff Direction Message as
appropriate.
7/30/2019 07-Features 3 v&V
20/78
228
1
2.14.3.2.2 Soft/softer Handoff Removal2
Soft/softer handoff removal occurs as shown in the following diagram. In this section, A3-3
CEData Forward/Reverse messages represent A3-IS-95 FCH Forward/Reverse, A3-IS-20004
FCH Forward/Reverse, or A3-IS-2000 DCCH Forward/Reverse messages.5
Conditional:
(See section
2.14.1.1.3)
MS Source BS Target BSMSC
A7-Drop Target
A3-Remove
A3-Remove Ack
A7-Drop TargetAck
handoff direction message
Handoff Performed
b
cMS Ack Order
Handoff Completion Message
BS Ack Order
e
f
k
g
h
i
j
Time Comment
Tdrptgt Tdiscon3
A3-CEData Forward (HO Dir. Msg.)
A3-CEData Reverse (MS Ack Order)
a
d
6
Figure 2.14.3.2.2-1 - Soft/softer Handoff Removal7
a. The source BS sends a handoff direction message4in an A3-CEData Forward8
message to the target BS to be sent to the mobile station to drop one or more9
cell(s) from the active set.10
b. The source BS and target BS transmit the handoff direction message to the11
mobile station.12
c. The mobile station acknowledges receipt of the handoff direction message13
with an MS Ack Order transmitted to both the source and target BSs.14
d. The target BS relays the MS Ack Order to the source BS in an A3-CEData15
Reverse message.16
e. The mobile station indicates successful results of processing the handoff17direction message by sending a Handoff Completion Message.18
f. The source BS acknowledges receipt of the Handoff Completion Message by19
sending a BS Ack Order.20
4 This may be a Handoff Direction Message, a General Handoff Direction Message, an
Extended Handoff Direction Message, or a Universal Handoff Direction Message as
appropriate.
7/30/2019 07-Features 3 v&V
21/78
229
g. The source BS sends an A7-Drop Target message to the target BS to request1
that the specified cells be removed from the call. The source BS starts timer2
Tdrptgt.3
h. The target BS, upon receipt of the A7-Drop Target message, deallocates4
internal resources related to the specified cells. The target BS sends an A3-5
Remove message to the SDU function of the source BS and starts timer6
Tdiscon3.7
i. The SDU function of the source BS replies with an A3-Remove Ack message8
and deallocates internal resources. The target BS stop timer Tdiscon3.9
j. The target BS sends an A7-Drop Target Ack message to the source BS to10
acknowledge the removal of the specified cells. The source BS stops timer11
Tdrptgt.12
k. The source BS may send a Handoff Performed message to the MSC. See13
section 2.14.1.1.3 Concept of A Designated Cell. The Handoff Performed14
message may be sent any time after the Handoff Completion Message is15
received by the BS.16
17
7/30/2019 07-Features 3 v&V
22/78
230
1
2.14.3.2.3 Cell Removal by a Target BS2
The example below shows a Target Removal initiated by a target BS, where the last cell attached3
to an A3 call leg is removed, thus causing the A3 call leg connections to be torn down. As can be4
seen in the example, the A7-Target Removal Request message initiates normal call leg removal,5
that is, between the A7-Target Removal Request and A7-Target Removal Response messages will6
be found the normal A7 interface call leg removal procedure.7
Source BS Target BSMS MSC
A7-Drop Target
A3-Remove
A3-Remove Ack
A7-Drop Target Ack
handoff direction message
Handoff Performed
b
cMS Ack Order
Handoff Completion Message
BS Ack Order
d
e
j
f
g
h
i
Time Comment
A7-Target Removal Requesta
A7-Target Removal Response
k
Ttgtrmv
Tdrptgt
Tdiscon3
Conditional:
(See section
2.14.1.1.3)
8
Figure 2.14.3.2.3-1 - Cell Removal Initiated by the Target BS9
a. The target BS decides that one or more of its cells can no longer be involved10
in the soft/softer handoff and sends an A7-Target Removal Request message11
to the source BS. The target BS starts timer Ttgtrmv.12
b. The source BS sends a handoff direction message5 to the mobile station to13drop the cell(s) from the active set.14
c. The mobile station acknowledges receipt of the handoff direction message15
with an MS Ack Order.16
d. The mobile station indicates successful results of processing the handoff17direction message by sending a Handoff Completion Message.18
e. The source BS acknowledges receipt of the Handoff Completion Message by19
sending a BS Ack Order.20
5 This may be a Handoff Direction Message, a General Handoff Direction Message, an
Extended Handoff Direction Message, or a Universal Handoff Direction Message as
appropriate.
7/30/2019 07-Features 3 v&V
23/78
231
f. The source BS sends an A7-Drop Target message to the target BS to request1
that the specified cells be removed from the call. The source BS starts timer2
Tdrptgt.3
g. The target BS, upon receipt of the A7-Drop Target message, deallocates4
internal resources related to the specified cells. In this example, it is assumed5
that all cells attached to an A3 connection are removed from the call. The6
target BS sends an A3-Remove message to the SDU function of the source BS7and starts timer Tdiscon3.8
h. The SDU function of the source BS replies with an A3-Remove Ack message9
and deallocates internal resources. The target BS stop timer Tdiscon3.10
i. The target BS sends an A7-Drop Target Ack message to the source BS to11
acknowledge the removal of the specified cells. The source BS stops timer12
Tdrptgt.13
j. The source BS may send a Handoff Performed message to the MSC. See14
section 2.14.1.1.3 Concept of A Designated Cell. The Handoff Performed15
message may be sent any time after the Handoff Completion Message is16
received by the BS.17
k. The source BS responds to the target BS with an A7-Target Removal18Response message. The target BS stops timer Ttgtrmv.19
7/30/2019 07-Features 3 v&V
24/78
232
1
2.14.3.2.4 Initial Traffic Burst Example A3 Connection Not Yet Established2
The example below describes the support of an initial traffic burst when the A3 connection has not3
yet been established.4
In this version of this standard, it is assumed that any leg for a supplemental channel will be5
established on a cell that also supports a leg for the fundamental channel (FCH) or the dedicated6
control channel (DCCH) for the same mobile station. To minimize the time required to establish a7
traffic burst, the A3 connection for the SCH is established on the target BS at the transmission of8
the first data burst. When a leg is established for a SCH, only the terrestrial resources are9
allocated, i.e., the A3 connection. This involves choosing the traffic circuit to be used and10
establishing context between the target BS and the source BS/SDU function. Allocation of radio11
resources for the SCH is made each time that a traffic burst is set up.12
i
A3 -Physical Transition Directive
Tconn3A3-Connect Ack
A3-Connect
A7-Burst Request
Thoreq
A7- Handoff Request Ack
A7- Handoff Request
Source BS Target BSMS
b
c
d
Time Comment
Tbstcom
e
A7-Burst Response
f
g
A7-Burst Commit
Forward and/or reverse traffic burstj
i
ESCAM
Layer 2 Ack
Tbstreq
SCRM Msg
PDSN
(data to be sent)a
h
k
l
13
Figure 2.14.3.2.4-1 - Initial Traffic Burst Example14
a. Either the source BS receives an indication from the MS (via a Supplemental15
Channel Request Message (SCRM)) or from the network (via data being16
received from the PDSN) that data needs to be sent to/from the MS. The17
source BS decides a traffic burst on one or more new cells at a target BS is18
required in support of a service instance in soft/softer handoff. This example19
assumes that a Fundamental Channel (FCH) or Dedicated Control Channel20
(DCCH) leg already exists on the selected cell(s) at the target BS. For21
simplicity, only one SCH is shown.22
b. The Source BS assigns an A7 Originating ID value and sends an A7 Handoff23
Request to the target BS to establish an A3 traffic connection to support a24
Supplemental Channel (SCH) for the call. This example shows only a single25
7/30/2019 07-Features 3 v&V
25/78
233
A3 connection being established. The Source BS is not required to assign a1
physical Frame Selector at this time. The Source BS starts timer Thoreq.2
c. The target BS assigns a traffic circuit and optionally a Channel Element ID3
(CE ID) for each A3 traffic connection and sends an A3-Connect message to4
the source BS indicating the Traffic Circuit ID, optional A3 Originating ID5
and CE ID to be associated with the specified cell. The source BS and target6
BS save the association of CE ID, Traffic Circuit ID, with Cell ID(s). The7source BS also saves the A3 Originating ID value, to be included in8
subsequent A3 messages to the target BS. The target BS starts timer Tconn3.9
This is only done at the initial burst.10
d. The source BS responds with an A3 Connect Ack message to complete the A311
connection. This may include an A3 Originating ID value assigned by the12
source BS, which will be included by the target BS in subsequent A313
messages to the source BS. The target BS stops timer Tconn3.14
e. The Target BS sends A7-Handoff Request Ack messages to the source BS to15
complete the A3 traffic circuit connection setup procedure for the specified set16
of cells. This may include an A7 Originating ID value assigned by the target17
BS, which will be included by the source BS in subsequent A7 messages to18
the target BS for this call association. Upon receipt of the A7-Handoff19Request Ack message, the Source BS stops timer Thoreq.20
f. The source BS sends an A7-Burst Request to the target BS to request the21
reservation of the needed radio resources at one or more cells for the22
supplemental channel. The source BS starts timer Tbstreq. Note that the23
source BS may send an A7-Burst Request to the target BS at any time after24
receiving the A3-Connect message in step c, and that the set of cells may be a25
subset of the cells assigned in steps a-e.26
g. The target BS determines that it can reserve part or all of the requested27
resources and sends A7-Burst Response message(s) to the source BS28
indicating the resources that have been reserved and committed to the traffic29
burst, and the cause value for any uncommitted cells. Each A7-Burst30
Response message can contain up to one committed cell and multiple31
uncommitted cells. Each reservation includes a physical Channel Element.32
Note that the physical Channel Element may be allocated any time after step33
(b). The target BS starts timer Tbstcom. The source BS stops timer Tbstreq.34
h. The source BS makes a final decision on the resources using the A7-Burst35
Response information from the target BSs, associates a frame selector with the36
physical channel, and sends an A7-Burst Commit message to the target BS37
indicating the cell resources that will actually be used for the traffic burst.38
Upon receipt of the A7-Burst Commit message, the target BS stops time39
Tbstcom. Note that the source BS may allocate the frame selector any time40
after step (b). The target BS sets up the burst.41
Note that the source BS is not required to wait for all A7-Burst Responses42
before committing the burst, but it shall not send A7-Burst Commit for a43
given cell until after receiving the corresponding A7-Burst Response for that44cell.45
i. The source BS commands the MS to prepare for the traffic burst via an46
Extended Supplemental Channel Assignment Message (ESCAM).47
j. The MS acknowledges the command from the source BS with a Layer 2 Ack.48
If the handoff direction message is sent using quick repeats, the source BS49
might not request an acknowledgment from the MS.50
7/30/2019 07-Features 3 v&V
26/78
234
k. The network and mobile station exchange forward and/or reverse traffic burst1
information for the specified duration, or until the source BS or target BS2
terminates or extends the traffic burst.3
l. The source BS sends an A3-Physical Transition Directive message if the old4
Power Control Mode is to be restored when the burst ends. This step may5
occur anytime after step h.6
2.14.3.2.5 Subsequent Traffic Burst Example7
The example below describes the support of a traffic burst when the A3 connection for the8
supplemental channel (SCH) has already been established. Note that this could be the initial data9
burst if the A3 connection for the SCH was established previously via the A7-Handoff Request10
procedure.11
Source BS Target BSMS
A7- Burst Request
A7- Burst Commit
b
c
d
Time Comment
Tbstcom
e
f
g
Forward and/or reverse traffic burst
ESCAM
Layer 2 Ack
SCRM Msg
PDSN
(data to be sent)a
A7- Burst Response
Tbstreq A7- Burst ResponseTbstreq
TbstcomA7- Burst Release
h
i
12Figure 2.14.3.2.5-1 - Subsequent Traffic Burst Example13
a. Either the source BS receives an indication from the MS (via a Supplemental14
Channel Request Message (SCRM)) or from the network (via data being15
received from the PDSN) that data needs to be sent to/from the MS.16
b. The source BS decides a traffic burst is required on one or more cells for17
which an A3 connection already exists in support of a supplemental channel.18
The source BS sends an A7-Burst Request to the target BS to request the19
reservation of the needed radio resources for the supplemental channel. The20
source BS starts timer Tbstreq.21
c. The target BS determines that it can reserve part or all of the requested22
resources at some of the cells and sends A7-Burst Response message(s) to the23
source BS indicating the resources that have been reserved and committed to24
the traffic burst, and the cause value for any uncommitted cells. Each A7-25
Burst Response message can contain up to one committed cell and multiple26
uncommitted cells. Each reservation includes a physical Channel Element.27
Note that the physical Channel Element may be allocated any time after step28
(b). The target BS starts an instance of timer Tbstcom for each committed cell.29
d. Upon receipt of the last A7-Burst Response message accounting for all30
requested cells, the source BS stops timer Tbstreq.31
7/30/2019 07-Features 3 v&V
27/78
235
e. The source BS makes a final decision on the resources using the A7-Burst1
Response information from the target BSs, associates a frame selector with the2
physical channel, and sends A7-Burst Commit messages to each target BS for3
each cell chosen to support the traffic burst, indicating the cell resources that4
will actually be used for the traffic burst. In this scenario, the source BS5
decides to use the resources reserved by the target BS. Upon receipt of the6
A7-Burst Commit message for a given cell, the target BS stops the7
corresponding timer Tbstcom and sets up the burst. Note that the source BS8
may allocate the frame selector any time after step (b).9
Note that the source BS is not required to wait for all A7-Burst Responses10
before committing the burst, but it shall not send A7-Burst Commit for a11
given cell until after receiving the corresponding A7-Burst Response for that12
cell.13
See the call flow in section 2.14.3.2.6 for any reserved resources that will not14
be used for the traffic burst.15
f. The source BS sends A7-Burst Release message(s) to target BS(s) for cells16
that reserved resources but that will not be used to support the burst. Upon17
receipt of A7-Burst Release for a given cell, the target BS stops the18
corresponding timer Tbstcom. The target BS frees the reserved resources.19Note that the source BS is not required to wait for all A7-Burst Responses20
before committing the burst, but it shall not send A7-Burst Release for a given21
cell until after receiving the corresponding A7-Burst Response for that cell.22
g. The source BS commands the MS to prepare for the traffic burst via an23
Extended Supplemental Channel Assignment Message (ESCAM).24
h. The MS acknowledges the command from the source BS with a Layer 2 Ack.25
If the handoff direction message is sent using quick repeats, the source BS26
might not request an acknowledgment from the MS.27
i. The network and mobile station exchange forward and/or reverse traffic burst28
information for the specified duration, or until the source BS or target BS29
terminates or extends the traffic burst.30
2.14.3.2.6 Source BS Releases Reserved Resources31
The example below describes how the source BS releases resources reserved at the target BS for a32
cell that will not be used to support the burst.33
Source BS Target BS
A7- Burst Request
A7- Burst Response
A7- Burst Release
b
c
Time Comment
Tbstreq
Tbstcom
a
34
Figure 2.14.3.2.6-1 - Source BS Releases Reserved Resources35
a. The source BS sends an A7-Burst Request to the target BS to request the36
reservation of the needed radio resources for the supplemental channel. The37
source BS starts timer Tbstreq.38
7/30/2019 07-Features 3 v&V
28/78
236
b. The target BS determines that it can reserve part or all of the requested1
resources and sends A7-Burst Response message(s) to the source BS2
indicating the resources that have been reserved and committed to the traffic3
burst, and the cause value for any uncommitted cells. The target BS starts a4
timer Tbstcom for each A7-Burst Response message sent. Upon receipt of the5
last A7-Burst Response, the source BS stops timer Tbstreq.6
c. In this scenario, the source BS decides not to use the resources reserved by the7target BS. The source BS sends A7-Burst Release(s) for the reserved cell(s)8
that will not be used for the traffic burst. Upon receipt of each A7-Burst9
Release message, the target BS stops the timer Tbstcom corresponding to the10
indicated cell(s) and releases its resources.11
2.14.3.2.7 Early Burst Termination Initiated by Source BS12
The example below describes how the source BS terminates a burst in progress.13
Source BS Target BS
A7- Burst Commit
A7- Burst Release
b
c
Time Comment
a
Forward and/or reverse traffic burst
MS
14
Figure 2.14.3.2.7-1 - Early Burst Termination Initiated by Source BS15
a. The source BS sends A7-Burst Commit messages to all target BSs indicating16
the set of committed resources that will actually be used for the traffic burst.17
The target BS sets up the burst.18
b. The network and mobile station exchange forward and/or reverse traffic burst19
information.20
c. While the burst is in progress, the source BS decides to terminate the burst21
early at one or more cells. The source BS sends A7-Burst Release to the cells22
which are to terminate the burst. The target BS releases all resources23
associated with the burst.24
7/30/2019 07-Features 3 v&V
29/78
237
1
2.14.3.2.8 Early Burst Termination Initiated by Target BS2
The example below describes how the target BS terminates a burst in progress.3
Source BS Target BS
A7- Burst Releaseb
Time Comment
aForward and/or reverse traffic burst
MS
4
Figure 2.14.3.2.8-1 - Early Burst Termination Initiated by Target BS5
a. The network and mobile station exchange forward and/or reverse traffic burst6
information.7
b. While the burst is in progress, the target BS decides to terminate the burst8early at one or more cells. The target BS sends A7-Burst Release(s) for the9
cells which are being removed from the burst. The source BS releases all10
resources associated with the cells that are being removed from the burst. If11
there are other cells supporting the SCH, then the burst continues on those12
cells.13
7/30/2019 07-Features 3 v&V
30/78
238
1
2.14.4 Fast Handoff Procedures2
3
2.14.4.1 Successful Operation4
5
2.14.4.1.1 Serving PDSN Reachable From Target RN6
When the target RN receives a handoff request message that includes the serving PDSN and the7
anchor PDSN addresses, it first determines reachability to the serving PDSN. In case the serving8
PDSN is reachable from the target RN, an RP connection is established between the target RN and9
the serving PDSN for each packet data service instance, by using a RP connection request message10
that includes the anchor PDSN IP address in an VSE and the S bit set to 1 as well as the pre-setup11
airlink record. The Lifetime field in the RP connection request message is set to a configurable12
value Tpresetup, that is sufficient to perform traffic channel handoff between the serving and the13target systems. If the connection setup request is acceptable, the serving PDSN updates mobiles14
binding record by including an association for the new RP connection from the target RN, and15
returns an RP connection reply message that includes the anchor PDSN address. At this stage, the16
user data flows from the serving PDSN to both, the serving RN and the target RN.User data is ,17
however, dropped at the target RN.Unlike conventional handoff operation, The presetup of the R-18
P link to the PDSN is performed on receiving the A9-setup-A8 message disregarding the setting of19
the hard handoff indicator.20
On handover of the traffic channel(s) to the target RN starts forwarding user data to the mobile21
station on receiving the A9-AL-Connected message. Target RN also sendsSETUP and START22
airlink records to the serving PDSN over the pre-setup RP connection, with RP connection23
Lifetime set up Trp,the S bit cleared. At this stage, the target RN starts periodically re-registering24
with the serving PDSN before the expiration of the RP connection Lifetime. On receipt of the25 active start airlink record, the serving PDSN stops transport of the user data stream to the serving26
RN.27
On receiving the active stop airlink record from the source RN, the PDSN proceeds with the28
tearing of the R-PA10 connection(s) with the source RN.29
In case the traffic channel is not handed over to the target RN, the pre-setup RP connection30
between the target RN and the serving PDSN is automatically released on expiry of timer31
Tpresetup.32
2.14.4.1.2 Serving PDSN Not Reachable From Target RN33
When the target RN receives a handoff request message that includes the serving PDSN and the34anchor PDSN addresses, it first determines reachability to the serving PDSN. In case the serving35
PDSN is not reachable from the target RN, another PDSN is selected and an RP connection is pre-36
established between the target RN and the target PDSN by using a RP connection request37
message(s) for each packet data service instance. RP connection request message includes the38
anchor PDSN IP address in a VSE and the pre-setup airlink record.The S bit is set. The Lifetime39
field in the RP connection request message is set to a configurable value Tpresetup, that is40
sufficient to perform traffic channel handoff between the serving and the target systems. The41
target PDSN may accept or reject the RP connection setup request. If the connection setup request42
7/30/2019 07-Features 3 v&V
31/78
239
is acceptable, it returns a RP connection reply message with an accept indication and anchor1
PDSN address received in the RP connection request message.2
On successful establishment of RP connection(s), the target PDSN initiates setup of a PP3
connection for every RP connection. If the PP connection setup request is acceptable, the serving4
PDSN updates the binding record for the mobile by creating an association between the IMSI5
address, MN-SRID and the PP Session Identifier, target-PDSN-Address and anchor-PDSN-6
Address information. User data, now flows both to the serving RN via the RP connection and the7
target PDSN over the just established PP connection. The target PDSN forwards the data to the8
target RN which discards the user data till such time the traffic channel(s) is/are successfully9
handed over to the target RN. PP tunnel establishment is performed independently from10
procedures in the RAN.11
On handover of the traffic channel(s) to the target RN, the target RN forwards the SETUP and12
START airlink records to the target PDSN over the pre-setup RP connection, with RP connection13
Lifetime set to Trp and S bit cleared. The target RN also starts periodically re-registering with the14
target PDSN before the expiration of the RP connection Lifetime.15
If the traffic channel is not handed over to the target RN, the pre-setup RP connection is16
automatically released on expiry of timer Tpresetup.17
If the PP connection has been established successfully by the time SETUP airlink record is18
received, the target PDSN forwards the START airlink record over the PP connection to the19
serving PDSN, when received over the RP connection. On receipt of the START airlink record,20
the target PDSN stops transport of the user data stream to the serving.Following the reception of21
the active stop airlink record the source PDSN can elect to initiate A10 tear down.22
With the PP connection in place, link layer framespass over this connection in both directions via23
GRE framing. The PDSNs use the target-PDSN-IP-Address and the anchor-PDSN-IP-Address as24
the PP connection end points for the transport of user traffic. The target-PDSN-IP-Address and the25
anchor-PDSN-IP-Address form the unique link layer ID for each PP connection. The target PDSN26
and the serving PDSN maintain an association of the mobiles IMSI address and MN Session27
Reference ID (MN-SRID) with the PP connection as well as the bindings for the R- P sessions.28
If the traffic channel is not handed over to the target RN, the pre-setup PP connection between the29
target PDSN and the serving PDSN is automatically released on expiry of timer Tpresetup.30
After release of the traffic channel at the target RN (either due to return to dormancy or possibly a31
hard handoff to another RN), the active stop airlink record is sent to the target PDSN which32
forwards it to the serving PDSN.33
On going dormant at the target RN, the target PCF forwards the ANIDs to the target PDSN in an34
A11 registration request which in this case will not contain the anchor PDSN IP address. This35
triggers PPP renegotiation and MIP registration.The target PDSN returns its own anchor PDSN IP36
address in the A11 registration reply.37
2.14.4.2 Failure Operation38
39
2.14.4.2.1 Serving PDSN Reachable From Target RN40
When the target RN receives a handoff request message that includes the serving PDSN and the41
anchor PDSN addresses, and it does not recognize/support anchor PDSN address (does not42
7/30/2019 07-Features 3 v&V
32/78
240
support fast handoff), then it does not proceed with pre-setup of the RP connection. The handoff1
procedures specified in 3GPP2 A.S0001-A apply.2
If the target RN recognizes/supports anchor PDSN address (supports fast handoff), it initiates pre-3
setup of the RP connection with the serving PDSN. If the serving PDSN does not support fast4
handoff or does not accept the connection for some other reason, it returns a RP connection reply5
with a reject result code.6
Depending on the result code, the target RN may attempt to re-try pre-setup of the RP connection.7
If the RP connection cannot be pre-setup, the target RN abandons RP connection pre-setup8
attempts, and proceeds with performing hard handoff as described in 3GPP2 A.S0001-A.9
2.14.4.2.2 Serving PDSN Not Reachable From Target RN10
When the target RN receives a handoff request message that includes the serving PDSN and the11
anchor PDSN addresses, and it does not recognize/support anchor PDSN address (does not12
support fast handoff), then it does not proceed with pre-setup of the RP connection. The handoff13
procedures specified in 3GPP2 A.S0001-A apply.14
If the target RN recognizes/supports anchor PDSN address (supports fast handoff), it initiates pre-15 setup of the RP connection with the target PDSN. If the target PDSN does not support fast handoff16
or does not accept the connection for some other reason, it returns a RP connection reply with a17
reject result code.18
Depending on the result code, the target RN may attempt to retry pre-setup of the RP connection.19
If the RP connection cannot be pre-setup, the target RN abandons RP connection pre-setup20
attempts, and proceeds with performing hard handoff as described in 3GPP2 A.S0001-A.21
If the RP connection is pre-setup successfully, the target PDSN initiates setup of the PP22
connection with the serving PDSN. If the serving PDSN does not accept the connection, it returns23
a PP-Handoff Reply with a reject result code.24
Depending on the result code, the target PDSN may attempt to retry setting up of the PP25
connection. If the PP connection cannot be established, target PDSN abandons PP connection26
setup attempts.27
At the time the SETUP airlink record is received from the target RN, if the PP connection with the28
serving PDSN has not yet been established successfully, the target PDSN initiates establishing the29
link layer connection with the mobile, if required. MIP registration is also performed and the30
packet data call continues with the call now being served by the target PDSN. The target PDSN31
returns its own anchor PDSN address in the RP connection reply message.32
2.14.4.3 Fast handoff Call Flows33
34
2.14.4.3.1 Serving PDSN Reachable from Target RN35
In order to obtain packet data services, the mobile performs registration with the packet data36
network. The traffic channel(s) is/are assigned and an RP connection(s) established between the37
serving RN and the serving PDSN on behalf of the mobile. For RP connections requiring PPP, it38
results in establishment of the link layer (PPP) connection at the serving PDSN and Mobile IP39
registration with the serving packet network. For RP connections that do not require PPP, the40
handling of the user data stream is determined from the protocol type field.41
7/30/2019 07-Features 3 v&V
33/78
241
The mobile roams into the coverage area of a target RN resulting in a hard handoff. The source1
RN sends a handoff request message to the target RN. The handoff request message contains the2
mobile identifier and information regarding associated RP connection(s). It also contains the3
address of the currently serving and anchor PDSNs. The serving PDSN is reachable from the4
target RN. RP connection(s) is/are established between the target RN and the serving PDSN which5
recognizes that fast handoff is solicited due to the presence of the anchor PDSN IP address VSE.6
The serving PDSN starts to deliver the user data to both, the serving RN and the target RN. User7
data is, however, dropped at the target RN. On handover of the traffic channel, the target RN starts8
forwarding user datato the mobile station.9
7/30/2019 07-Features 3 v&V
34/78
242
MS Source BSC MSC
Handoff Required
Handoff Request
T9
T306
T315
Twaitho
x
Source
PCFPDSN
A9-Setup-A8
A9-Connect-A8
Handoff Request Ack
Handoff Command
GHDM / UHDM
Handoff Commenced
T7
Handoff Completion
A9-AL Connected
A9-AL Connected Ack
Handoff Complete
Clear Command
A9-Release-A8
A9-Release-A8 Complete
Clear Complete
MS Ack Order
BS Ack Order
Target
PCFTarget BSC
Talc9
Twaitho9
A9-AL Disconnected
A9-AL Disconnected AckTald9
TA8-Setup
Tre19
a
b
d
e
c
f
g
h
i
m
l
k
j
A11 registration request(Tpresetup, S=1)
A11 registration reply (anchor PDSN)
A11 registration request (active start,Trp)
n
o
p
q
s
r
t
u
1
2
Figure 2.14.4.3-1 - Serving PDSN Reachable From Target PDSN3
a. User data flow is active using a PPP session between the mobile station and4
the currently serving PDSN (PDSNs). During the setup of the R-PA105
connection the selected PDSN (PDSNs) returned its anchor IP address in the6
7/30/2019 07-Features 3 v&V
35/78
243
A11 registration reply. The PCF in turn relayed both the serving PDSN IP1
address and its anchor IP address to the serving BSC.2
b. Based on an MS report that it crossed a network specified threshold for signal3
strength, changes to a different ANID or for other reasons, the source BSC4
recommends cdma2000 to cdma2000 hard handoff to one or more cells in the5
domain of the target BSC. The source BSC sends a Handoff Required6
message with the list of cells to the MSC and starts timer T7. The source BSC7includes the PANID information in the handoff required message. It also8
includes both the IP address of the serving PDSN as well as the IP address of9
the anchor PDSN.10
c. The MSC sends a Handoff Request message (which includes the PANID11
information previously communicated to the MSC via the Handoff Required12
message) to the target BSC with hard handoff indicator (e.g., Handoff Type13
element in the message indicating hard handoff).In this message it relays the14
IP address of both the serving PDSN and the anchor PDSN.15
d. The target BSC sends an A9-Setup-A8 message to the target PCF in order to16
establish the A8-Connection and sets timer TA8-Setup. In this case, the17
handoff indicator field of the A9-Setup-A8 message is set to 1 (during18
handoff).The target BSC includes the IP address of both serving and anchor19PDSN.20
e. Upon receipt of the A9-Setup-A8 message from the target BSC, the target21
PCF recognizes the anchor PDSN IP address information element and22
establishes an R-PA10 session with the serving PDSN whose IP address is23
contained in the A9-setup-A8 message. The lifetime field in the A1124
registration request in set to Tpresetup, the S bit is set indicating simultaneous25
binding and the anchor PDSN address VSE is attached (indicating Fast26
handoff request) . The PDSN accepts the connection by returning the A1127
registration reply with the same anchor PDSN address.28
f. The target PCF establishes the A8-Connection. The target PCF sends the A9-29
Connect-A8 message and starts timer Twaitho9. When the target BSC30
receives the A9-Connect-A8 message it stops timer TA8-Setup.At this point31
the target BSC has both the IP address ofthe serving PDSN and its anchor IP32
address as it has received them through the handoff request message.33
g. The target BSC sends a Handoff Request Acknowledgment message to the34
MSC. The target BSC starts timer T9 to wait for arrival of the MS on its radio35
channel.36
At this point in time, PDSN continues to forward packet data to the37
source BSC via source PCF. It also forwards user data down the target38
PCF which at this time discards it.39
h. The MSC prepares to switch from the source BSC to the target BSC and sends40
a Handoff Command to the source BSC. The source BSC stops timer T7.41
i. The PCF stops packet transmission to the source BSC upon receipt of A9-AL42
(Air Link) Disconnected from the source BSC. At this point of time, the43source BSC starts timer Tald9.44
j. The PCF sends A9-AL Disconnected Ack message as response of A9-AL (Air45
Link) Disconnected message. The BSC stops timer Tald9.46
k. The source BSC sends the General Handoff Direction Message or Universal47
Handoff Direction Message to the mobile station across the air interface. If the48
MS is allowed to return to the source BSC, then timer Twaitho is started by49
the source BSC.50
7/30/2019 07-Features 3 v&V
36/78
244
l. The MS may acknowledge the General Handoff Direction Message or1
Universal Handoff Direction Message by sending an MS Ack Order to the2
source BSC. If the General Handoff Direction Message or Universal Handoff3
Direction Message is sent using quick repeats, the source BSC might not4
request an acknowledgment from the MS.5
m. The source BSC sends a Handoff Commenced message to the MSC to notify6
it that the MS has been ordered to move to the target BSC channel. The source7BSC starts timer T306 to await the Clear Command message from the MSC.8
If timer Twaitho has been started, the source BSC shall wait for that timer to9
expire before sending the Handoff Commenced message.10
n. The MS sends a Handoff Completion Message to the target BSC.11
o. The target BSC sends the BSC Ack Order to the MS over the air interface.12
p. Upon the receipt of the Handoff Completion message from the MS, the target13
BSC sends A9-AL (Air Link) Connected message to the target