07-features 3 v&v

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







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





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



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



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







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





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 Performed

a

b

c

g

h

i

j

Time Comment

Conditional:

(See AterInterface

Document)

MS Ack Order


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



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 Performed

b

cMS Ack Order


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




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 Performed

b

cMS Ack Order


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




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



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



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


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


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

07-features 3 v&v

Documents