Tia 2001 C

TIA
DOCUMENT

Interoperability Specification (IOS) for
cdma2000 Access Network Interfaces
Release C

TIA-2001-C
(Revision of TIA-2001-B)

JULY 2003

TELECOMMUNICATIONS INDUSTRY ASSOCIATION

The Telecommunications Industry Association
represents the communications sector of

NOTICE

TIA Engineering Standards and Publications are designed to serve the public interest through eliminating
misunderstandings between manufacturers and purchasers, facilitating interchangeability and improvement of
products, and assisting the purchaser in selecting and obtaining with minimum delay the proper product for
their particular need. The existence of such Publications shall not in any respect preclude any member or
non-member of TIA from manufacturing or selling products not conforming to such Publications. Neither
shall the existence of such Documents preclude their voluntary use by non-TIA members, either domestically
or internationally.

TIA DOCUMENTS

TIA Documents contain information deemed to be of technical value to the industry, and are published at the
request of the originating Committee without necessarily following the rigorous public review and resolution
of comments which is a procedural part of the development of a American National Standard (ANS). Further
details of the development process are available in the TIA Engineering Manual, located at
http://www.tiaonline.org/standards/sfg/engineering_manual.cfm

TIA Documents shall be reviewed on a five year cycle by the formulating Committee and a decision made on
whether to reaffirm, revise, withdraw, or proceed to develop an American National Standard on this subject.
Suggestions for revision should be directed to: Standards & Technology Department, Telecommunications
Industry Association, 2500 Wilson Boulevard, Arlington, VA 22201 U.S.A.

(From Project No. 3-4545-RV3, formulated under the cognizance of the TIA TR-45.5 Subcommittee on
Radio to Switching Technology)
Published by

TELECOMMUNICATIONS INDUSTRY ASSOCIATION 2003
Standards & Technology Department
2500 Wilson Boulevard
Arlington, VA 22201 U.S.A.

PRICE: Please refer to current Catalog of
TIA TELECOMMUNICATIONS INDUSTRY ASSOCIATION STANDARDS
AND ENGINEERING PUBLICATIONS
or call Global Engineering Documents, USA and Canada
(1-800-854-7179) International (303-397-7956)
or search online at http://www.tiaonline.org/standards/search_n_order.cfm

All rights reserved
Printed in U.S.A.

NOTICE OF DISCLAIMER AND LIMITATION OF LIABILITY

The document to which this Notice is affixed (the Document) has been prepared by one or more
Engineering Committees or Formulating Groups of the Telecommunications Industry Association (TIA). TIA
is not the author of the Document contents, but publishes and claims copyright to the Document pursuant to
licenses and permission granted by the authors of the contents.
TIA Engineering Committees and Formulating Groups are expected to conduct their affairs in
accordance with the TIA Engineering Manual (Manual), the current and predecessor versions of which are
available at http://www.tiaonline.org/standards/sfg/engineering_manual.cfm. TIAs function is to administer
the process, but not the content, of document preparation in accordance with the Manual and, when appropriate,
the policies and procedures of the American National Standards Institute (ANSI). TIA does not evaluate, test,
verify or investigate the information, accuracy, soundness, or credibility of the contents of the Document. In
publishing the Document, TIA disclaims any undertaking to perform any duty owed to or for anyone.
The use or practice of contents of this Document may involve the use of intellectual property rights
(IPR), including pending or issued patents, or copyrights, owned by one or more parties. TIA makes no
search or investigation for IPR. When IPR consisting of patents and published pending patent applications are
claimed and called to TIAs attention, a statement from the holder thereof is requested, all in accordance with
the Manual. TIA takes no position with reference to, and disclaims any obligation to investigate or inquire into,
the scope or validity of any claims of IPR.
TIA does not enforce or monitor compliance with the contents of the Document. TIA does not certify,
inspect, test or otherwise investigate products, designs or services or any claims of compliance with the contents
of the Document.
ALL WARRANTIES, EXPRESS OR IMPLIED, ARE DISCLAIMED, INCLUDING WITHOUT
LIMITATION, ANY AND ALL WARRANTIES CONCERNING THE ACCURACY OF THE CONTENTS,
ITS FITNESS OR APPROPRIATENESS FOR A PARTICULAR PURPOSE OR USE, ITS
MERCHANTABILITY AND ITS NON-INFRINGEMENT OF ANY THIRD PARTYS INTELLECTUAL
PROPERTY RIGHTS. TIA EXPRESSLY DISCLAIMS ANY AND ALL RESPONSIBILITIES FOR THE
ACCURACY OF THE CONTENTS AND MAKES NO REPRESENTATIONS OR WARRANTIES
REGARDING THE CONTENTS COMPLIANCE WITH ANY APPLICABLE STATUTE, RULE OR
REGULATION, OR THE SAFETY OR HEALTH EFFECTS OF THE CONTENTS OR ANY PRODUCT OR
SERVICE REFERRED TO IN THE DOCUMENT OR PRODUCED OR RENDERED TO COMPLY WITH
THE CONTENTS.
TIA SHALL NOT BE LIABLE FOR ANY AND ALL DAMAGES, DIRECT OR INDIRECT, ARISING
FROM OR RELATING TO ANY USE OF THE CONTENTS CONTAINED HEREIN, INCLUDING
WITHOUT LIMITATION ANY AND ALL INDIRECT, SPECIAL, INCIDENTAL OR CONSEQUENTIAL
DAMAGES (INCLUDING DAMAGES FOR LOSS OF BUSINESS, LOSS OF PROFITS, LITIGATION, OR
THE LIKE), WHETHER BASED UPON BREACH OF CONTRACT, BREACH OF WARRANTY, TORT
(INCLUDING NEGLIGENCE), PRODUCT LIABILITY OR OTHERWISE, EVEN IF ADVISED OF THE
POSSIBILITY OF SUCH DAMAGES. THE FOREGOING NEGATION OF DAMAGES IS A
FUNDAMENTAL ELEMENT OF THE USE OF THE CONTENTS HEREOF, AND THESE CONTENTS
WOULD NOT BE PUBLISHED BY TIA WITHOUT SUCH LIMITATIONS.

PLEASE!

DON'T VIOLATE
THE
LAW!

This document is copyrighted by the TIA and may not be reproduced without prior
permission of the Telecommunications Industry Association. For information
consult our website at http://www.tiaonline.org/about/faqDetail.cfm?id=18

Organizations may obtain permission to reproduce a limited number of copies
through entering into a license agreement. For information, contact:

Global Engineering Documents
15 Inverness Way East
Englewood, CO 80112-5704 U.S.A. or call
U.S.A. and Canada 1-800-854-7179, International (303) 397-7956

TIA-2001.1-C
1
2
3
4
Interoperability Specification (IOS) for cdma2000
5
Access Network Interfaces Part 1 Overview 6

TIA-2001.1-C

1
(This page intentionally left blank.) 2
3

TIA-2001.1-C
i
Table of Contents 1
2
1.0 Introduction .....................................................................................................................................1 3
1.1 Overview.........................................................................................................................................1 4
1.1.1 Purpose............................................................................................................................................1 5
1.1.2 Scope...............................................................................................................................................2 6
1.2 References .......................................................................................................................................3 7
1.2.1 TIA / EIA ........................................................................................................................................3 8
1.2.2 3GPP2 .............................................................................................................................................4 9
1.2.3 Other................................................................................................................................................5 10
1.3 Terminology....................................................................................................................................5 11
1.3.1 Acronyms ........................................................................................................................................5 12
1.3.2 Definitions.......................................................................................................................................6 13
1.4 Organization....................................................................................................................................9 14
1.4.1 This Revision of the IOS.................................................................................................................9 15
1.4.2 Overall IOS Specifications..............................................................................................................9 16
1.5 Document Layout ..........................................................................................................................10 17
1.6 Documentation Conventions .........................................................................................................11 18
1.6.1 Procedural Descriptions ................................................................................................................12 19
2.0 Interface Model .............................................................................................................................13 20
2.1 Reference Points A, A
ter
, A
quinter
, and A
quater
..................................................................................13 21
2.2 Interface Reference Model ............................................................................................................13 22
3.0 Information Flows .........................................................................................................................15 23
4.0 MS Mobility for Packet Data Service............................................................................................17 24
25
26
27
TIA-2001.1-C
ii
List of Figures 1
2
Figure 1.6-1 Document Convention Example: Call Clear Initiated by MS ............................................. 12 3
Figure 2.2-1 Reference Model for cdma2000
Access Network Interfaces............................................. 14 4

Figure 4-1 Levels of Packet Data Mobility........................................................................................... 17 5
6
7
TIA-2001.1-C
iii
List of Tables 1
2
Table 1.4.2-1 IOS Cross References.......................................................................................................... 10 3
4
5
TIA-2001.1-C
iv
Foreword 1
2
(This foreword is not part of this standard.) 3
4
This document was produced by Working Groups TR45.4 of the Telecommunications Industry Association 5
and TSG-A of the Third Generation Partnership Project 2. This document was developed in accordance 6
with TIA/EIA and 3GPP2 procedural guidelines, and represents the consensus position of the Working 7
Groups. 8
9
The Working Groups acknowledge the contributions made by the following individuals in the development 10
of this standard: 11
12
Name Representing Position
Dale Baldwin Sprint PCS TIA TR45.4 Chair
George Turnipseed Sprint PCS 3GPP2 TSG-A Chair
Roger Edwards 3GPP2 Secretariat Professional Editor
David Ott Qualcomm Part 1 (Overview) Technical Editor
Scott Marin Motorola Part 2 (Transport) Technical Editor
Bill Semper Samsung Part 3 (Features) Technical Editor and
Chair for comment resolution
Mini Vasudevan and
Srini Rao
Nortel Networks and Winphoria,
respectively
Part 4 (A1/A2/A5) Technical Editors
Janice Wunsch Lucent Technologies Part 5 (A3/A7) Technical Editor
Shahab Sayeedi Motorola Part 6 (A8/A9) Technical Editor
Roger Gustavsson and
Erik Colban
Ericsson Part 7 (A10/A11) Technical Editors
13
14
Suggestions for improvement of this standard are welcome. They should be sent to: 15
Telecommunications Industry Association 16
Engineering Department 17
Suite 300 18
250 Wilson Boulevard 19
Arlington, VA 22201 USA 20
21
TIA-2001.1-C
1 Section 1
1.0 Introduction 1
2
1.1 Overview 3
This standard describes the overall system functions, including services and features 4
required for interfacing a base station (BS) with the Mobile Switching Center (MSC), 5
with other base stations, and with the Packet Control Function (PCF); and for interfacing 6
the PCF with the Packet Data Service Node (PDSN). 7
This standard is intended to provide sufficient specification of a set of interfaces to 8
support the interoperability of one vendors equipment with that of another. Which 9
interface(s) a vendor chooses to implement is dependent on business decisions, and is up 10
to each vendor. However conformance to any given interface specified within this 11
standard requires all of the messages and procedures for supported features on that 12
interface to be supported as specified within this standard. Establishing standard 13
interfaces allows the BS, PCF, PDSN, and MSC equipment to evolve independently and 14
to be provided by multiple vendors. 15
1.1.1 Purpose 16
The purpose is to provide the standard for: 17
interfacing an MSC with one or more BSs, 18
interfacing a BS with one or more BSs, 19
interfacing a PCF with one or more BSs, 20
interfacing one or more PDSNs with one or more PCFs. 21
This document defines the functional capabilities, including services and features, of the 22
specified interfaces. These services and features are the defining characteristics that are 23
the basis for the overall system standard. 24
The MSC-BS interface provides telecommunications services access between a Mobile 25
Switching Center and a base station. It specifically represents the demarcation point 26
between the MSC and the BS which coincides with the Reference Point A. This point 27
establishes the technical interface and designates the test points and operational division 28
of responsibility between the MSC and the BS. The MSC and BS interface is defined as 29
the A1/A2/A5 interface shown in Figure 2.2-1, Reference Model for cdma2000 Access 30
Network Interfaces
1
. 31
This standard fulfills the following criteria: 32
supports current [1]~[6], [7] and [10] air interfaces; 33
makes maximum use of existing standards from the TIA and other sources; 34
promotes reliability enhancement, technical innovation, network product availability, 35
and economic competition; 36

1
cdma2000
is a registered trademark of the Telecommunications Industry

Association (TIA USA).
TIA-2001.1-C
Section 1 2
allows connection of various manufacturers BSs to the same MSC; 1
supports future MSC and BS implementations; 2
allows the separate evolution of MSC and BS technology. 3
The source BS - target BS interface provides for inter-BS soft/softer handoffs. It 4
specifically represents the demarcation point between two base stations which coincides 5
with the Reference Point A
ter
. This point establishes the technical interface and 6
designates the test points and operational division of responsibility between the source 7
BS and target BS. The source BS and target BS interface is defined as the A3/A7 8
interface shown in Figure 2.2-1, Reference Model for cdma2000
Access Network 9
Interfaces. 10
The BS-PCF interface provides access between the base station and the Packet Control 11
Function for high speed packet data services. It specifically represents the demarcation 12
point between the BS and the PCF which coincides with the Reference Point A
quinter
. 13
This point establishes the technical interface and designates the test points and 14
operational division of responsibility between the BS and the PCF. The BS-PCF interface 15
is defined as the A8/A9 interface shown in Figure 2.2-1, Reference Model for 16
cdma2000
Access Network Interfaces. 17

The PCF-PDSN interface provides access between a Packet Control Function and a 18
Packet Data Serving Node for high speed packet data services. It specifically represents 19
the demarcation point between the PCF and the PDSN which coincides with the 20
Reference Point A
quater
. This point establishes the technical interface and designates 21
the test points and operational division of responsibility between the PCF and the PDSN. 22
The PCF-PDSN interface is defined as the A10/A11 interface shown in Figure 2.2-1, 23
Reference Model for cdma2000
Access Network Interfaces. 24

The PCF-PDSN interface definition fulfills the following criteria: 25
allows connection of various manufacturers PCFs to the same PDSN and vice versa; 26
makes maximum use of existing standards from the Internet Engineering Task Force 27
(IETF) and other sources; 28
promotes quality of service and accounting information exchange between the PCFs 29
and the PDSNs; 30
promotes reliability enhancement, technical innovation, network product availability, 31
and economic competition; 32
supports future PCF and PDSN implementations; 33
allows the separate evolution of PCF and PDSN technologies. 34
1.1.2 Scope 35
This standard provides the specification for the interfaces which coincide with the 36
Reference Points A, A
ter
, A
quater
, and A
quinter
defined in the TR45 Network 37
Reference Model shown in [18]. 38
The scope of this standard includes the following topics: 39
MSC-BS and BS-BS interfaces: 40
TIA-2001.1-C
3 Section 1
descriptions of the specified functional capabilities that provide wireless 1
telecommunications services across the MSC-BS and BS-BS interfaces as 2
defined in the TR45 Network Reference Model; 3
descriptions of the division of responsibility of the functions provided between 4
the BS and the MSC, and between the source BS and the target BS, without 5
prescribing specific implementations; 6
descriptions of the MSC-BS interface and the BS-BS interface standards that 7
support DS-41 and cdma2000
systems. 8
BS-PCF interfaces: 9
descriptions of the specified functional capabilities that provide packet data 10
services across the BS-PCF interface; 11
the BS and the PCF without prescribing specific implementations. 13
PCF-PDSN interfaces: 14
descriptions of the specified functional capabilities that provide packet data 15
services across the PCF-PDSN interface; 16
the PCF and the PDSN without prescribing specific implementations. 18
The interfaces defined in this standard are specified by a set of characteristics, including: 19
physical and electromagnetic parameters; 20
channel structures; 21
message types and contents; 22
network operating procedures; 23
user data framing and transport. 24
1.2 References 25
26
1.2.1 TIA / EIA 27
For ease of cross referencing, the Telecommunications Industry Association (TIA) / 28
Electronics Industry Association (EIA) references provided in this section are aligned 29
with the 3GPP2 references provided in section 1.2.2. For consistency within IOS parts, 30
the most commonly referenced documents [1]~[17] shall be the same as they appear here 31
in this part, or left as Reserved if not used in a particular IOS part. 32
[1] TIA/EIA/IS-2000.1-B, Introduction to cdma2000
Standards for Spread 33

Spectrum Systems, May 2002. 34
[2] TIA/EIA/IS-2000.2-B, Physical Layer Standard for cdma2000
Spread 35
[3] TIA/EIA/IS-2000.3-B, Medium Access Control (MAC) Standard for cdma2000
37
Spread Spectrum Systems, May 2002. 38
[4] TIA/EIA/IS-2000.4-B, Signaling Link Access Control (LAC) Standard for 39
cdma2000

[5] TIA/EIA/IS-2000.5-B, Upper Layer (Layer 3) Signaling Standard for 41
cdma2000

TIA-2001.1-C
Section 1 4
[6] TIA/EIA/IS-2000.6-B, Analog Signaling Standard for cdma2000
Spread 1
[7] TIA/EIA/IS-834, G3G CDMA-DS to ANSI/TIA/EIA-41, March 2000. 3
[8] TIA/EIA/IS-835-C, cdma2000
Wireless IP Network Standard, to be published. 4

[9] TIA/EIA-41-D, Cellular Radiotelecommunications Intersystem Operations; 5
December 1997. 6
[10] TIA/EIA-95-B, Mobile Station - Base Station Compatibility Standard for 7
Wideband Spread Spectrum Cellular Systems, March 1999. 8
[11] TIA-2001.1-C, Interoperability Specification (IOS) for cdma2000
Access 9
Network Interfaces Part 1 Overview, July 2003. 10
Access 11
Network Interfaces Part 2 Transport, July 2003. 12
Access 13
Network Interfaces Part 3 Features, July 2003. 14
Access 15
Network Interfaces Part 4 (A1, A2, and A5 Interfaces), July 2003. 16
Access 17
Network Interfaces Part 5 (A3 and A7 Interfaces), July 2003. 18
Access 19
Access 21
[18] TIA/EIA/TSB100-A, Wireless Network Reference Model, March 2001. 23
1.2.2 3GPP2 24
The 3GPP2 references are aligned with the TIA/EIA references of section 1.2.1 and are 25
provided here for information and cross reference purposes. 26
[1] 3GPP2 C.S0001-B, Introduction to cdma2000
Standards for Spread Spectrum 27

Systems, May 2002. 28
[2] 3GPP2 C.S0002-B, Physical Layer Standard for cdma2000
Spread Spectrum 29
[3] 3GPP2 C.S0003-B, Medium Access Control (MAC) Standard for cdma2000
31
[4] 3GPP2 C.S0004-B, Signaling Link Access Control (LAC) Standard for 33
cdma2000

[5] 3GPP2 C.S0005-B, Upper Layer (Layer 3) Signaling Standard for cdma2000
35
[6] 3GPP2 C.S0006-B, Analog Signaling Standard for cdma2000
Spread 37
[7] 3GPP2 C.S0007-0, Direct Spread Specification for Spread Spectrum Systems on 39
ANSI-41 (DS-41) (Upper Layers Air Interface), June 2000. 40
[8] 3GPP2 P.S0001-C, Wireless IP Network Standard, to be published. 41
[9-10] Reserved. 42
[11] 3GPP2 A.S0011-A, Interoperability Specification (IOS) for cdma2000
Access 43
Access 45
Access 47
TIA-2001.1-C
5 Section 1
Access 1
Access 3
Access 5
Access 7
[18] 3GPP2 S.R0005-B, Network Reference Model for cdma2000
Spread Spectrum 9
Systems, April 2001. 10
1.2.3 Other 11
12
[19] Internet Engineering Task Force, RFC 2002 IP Mobility Support Specification, 13
1996. 14
15
1.3 Terminology 16
17
1.3.1 Acronyms 18
19
Acronym Meaning
3GPP Third Generation Partnership Project
3GPP2 Third Generation Partnership Project 2
ANSI American National Standards Institute
BS Base Station
BSC Base Station Controller
BTS Base Transceiver System
CDMA Code Division Multiple Access
DS-41 Direct Spread (ANSI)-41
EHDM Extended Handoff Direction Message
EIA Electronics Industry Association
FA Foreign Agent
GHDM General Handoff Direction Message
HLR Home Location Register
IETF Internet Engineering Task Force
IOS Interoperability Specification
IP Internet Protocol
IS Interim Standard
ISDN Integrated Services Digital Network
IWF Interworking Function
kbps kilobits per second
TIA-2001.1-C
Section 1 6
Acronym Meaning
MIP Mobile Internet Protocol
MS Mobile Station
MSC Mobile Switching Center
MTSO Mobile Telephone Switching Office
NRM Network Reference Model
PCF Packet Control Function
PCM Pulse Code Modulation
PDSN Packet Data Serving Node
PSTN Public Switched Telephone Network
RLP Radio Link Protocol
SDU Selection/Distribution Unit
TIA Telecommunications Industry Association
TSB Telecommunications Systems Bulletin
UDI Unrestricted Digital Information
UMTS Universal Mobile Telecommunication System
UHDM Universal Handoff Direction Message
1
1.3.2 Definitions 2
Base Station. An entity in the public radio telecommunications system used for radio 3
telecommunications with MSs. 4
Base Station Controller. The control portion of the base station that includes call control 5
logic and interconnections to the MSC, the BTSs that are part of the BS, other BSCs, and 6
BTSs of neighboring BSs for purposes of soft/softer handoff. 7
Base Transceiver Station. A component of a base station that includes radio equipment. 8
A BTS is sometimes equated with the physical cell site of a wireless network. 9
Bearer Connection. A connection intended to provide a path for user traffic. 10
Call Association. The totality of the active communication between the MS and the 11
network, including all signaling and transfer of user information. 12
Cell. The unit of a base station having the ability to radiate in a given geographic area. In 13
this standard, a Cell ID refers to a particular cell and sector. 14
DS-41. An operational mode in which the BS and MS operate with the direct spread (DS) 15
radio layers of the UMTS system defined by 3GPP, and the upper layers defined in 16
[1]~[6] that conform to and interoperate with ANSI-41 based networks [9]. 17
Dormant Handoff: A handoff that occurs when an MS with a dormant packet session 18
determines that it has crossed a packet zone boundary. Dormant handoff results in A10 19
connection(s) being established between the target PCF and the target PDSN. A dormant 20
handoff may require exchange of higher layer protocol messages between the MS and the 21
TIA-2001.1-C
7 Section 1
PDSN, and thus, reactivation of the packet data session. Note that no air interface 1
channels are handed off or re-configured as the result of a dormant handoff. 2
Fast Handoff: Fast handoff is a particular type of hard handoff that applies only to 3
packet data sessions. Fast handoff allows the target PDSN to connect to an anchor PDSN 4
where the packet data session was first established, eliminating the need to re-establish a 5
PPP session while the packet data session is active. Fast handoff allows for early 6
establishment of the A10 connections on the target side. 7
Handoff. Handoff is the process by which an air interface circuit between an MS and a 8
base station is transferred from the current base station equipment and air interface 9
channel to either a different base station equipment and air interface channel or a 10
different air interface channel on the current base station equipment. Handoffs are an IOS 11
consideration insofar as user traffic and signaling paths through the RAN need to be 12
established, modified or released, information needs to be exchanged between the source 13
and target BSs, and air interface changes may need to be signaled to the core network. 14
Refer also to [13], section 3.19, for specific handoff considerations. The following types 15
of handoffs are supported: 16
1. Hard Handoff: A handoff characterized by a temporary disconnection of the Traffic 17
Channel. Hard handoffs occur when the MS is transferred between disjoint Active 18
Sets, when the CDMA Frequency Assignment changes, when the frame offset 19
changes, or when the MS is directed from a CDMA Traffic Channel to an analog 20
voice channel. For the IOS, a change in Selection Distribution Unit (SDU) across 21
BSs is considered to be a hard handoff. 22
2. Soft Handoff: A handoff occurring while the MS is in the Mobile Station Control on 23
the Traffic Channel State. This handoff is characterized by commencing 24
communications with a new BTS on the same CDMA Frequency Assignment 25
without terminating communications with an old BTS. For IOS considerations, the 26
same SDU function is used before and after the handoff is performed. 27
3. Soft Handoff with Pre-Selection: The configuration achieved when a BS internally 28
splits a single forward flow of coded user information from the frame selector to 29
send it to two or more cells controlled by that BS. In the reverse direction, the BS 30
joins the flows of coded user information frames from those cells, selects the best 31
quality frame (preselection), and forwards only that selected frame to the frame 32
selector. 33
4. Softer Handoff: A handoff involving two or more traffic channels on a call such that 34
in the forward direction the BS splits a single flow of traffic channel frames into two 35
or more forward flows to be sent to the MS with the power control combined bit set 36
to indicate that the same reverse power control information is to be used. In the 37
reverse direction the BS combines the traffic channel frames that are received from 38
two or more cells/sectors and forms a single reverse flow from this combination. 39
Interworking Function. The Interworking Function (IWF), used in the context of this 40
standard, provides a translation of the user traffic on a circuit data call between the fixed 41
network and the air interface. 42
Logical Channel. A logical path that can carry signaling, user traffic, or a combination 43
of the two between two entities such as the network and the MS. A logical channel can be 44
instantiated over one or more physical channels. Logical channels may also share 45
physical channels. 46
Mobile Station. An entity in the (cdma2000
) public cellular radio telecommunications 47

service intended to be used while in motion or during halts at unspecified points. Mobile 48
TIA-2001.1-C
Section 1 8
stations include portable units (e.g., hand-held personal units) and units installed in 1
vehicles. 2
Mobile Switching Center. The MSC switches MS-originated or MS-terminated traffic. 3
An MSC connects to one or more base stations. It may connect to other public networks 4
(PSTN, ISDN, etc.), other MSCs in the same network, or MSCs in different networks. (It 5
has been referred to as Mobile Telephone Switching Office, MTSO.) It provides the 6
interface for user traffic between the wireless network and other public switched 7
networks, or other MSCs. 8
Packet Control Function. An entity in the radio access network that manages the relay 9
of packets between the BS and the PDSN. 10
Packet Data Session. The set of one or more packet data service instances in use at any 11
time at the RAN/PDSN. A packet data session starts when the first service instance 12
transitions out of the Null/Inactive State, and ends when the last service instance 13
transitions to the Null/Inactive State. 14
Packet Data Serving Node. An entity that routes MS originated or MS terminated 15
packet data traffic. A PDSN establishes, maintains and terminates link layer sessions to 16
MSs. 17
Physical Channel. A physical path between the SDU function and the MS that consists 18
of any connecting A3 traffic channel(s) and radio channel(s). Depending on the radio 19
technology in use, a physical channel may be in soft handoff between the MS and the 20
SDU function. 21
SDU Function. The SDU function (Selection/Distribution Unit function) includes the 22
following functions: 23
Traffic Handler: This function exchanges traffic bits with the associated vocoder or 24
CDMA Radio Link Protocol (RLP) function, or is directly connected to the A5 25
interface. 26
Signaling Layer 2: This function performs the layer 2 functionality of the air 27
interface signaling protocol and is responsible for the reliable delivery of layer 3 28
signaling messages between the base station and the MS. This functionality may be 29
in the BTS in some situations. 30
Multiplex Sublayer: This function multiplexes and demultiplexes user traffic and 31
signaling traffic for the air interface. 32
Power Control: This function administers parts of the forward and reverse link power 33
control in a CDMA system. This function and the channel elements provide power 34
control functionality. This function generates or utilizes the power control 35
information in whole or in part that is exchanged over the air interface or with the 36
channel elements. 37
Frame Selection/Distribution: This function is responsible for selecting the best 38
incoming air interface reverse link frame from the channel elements involved in the 39
soft handoff. It also distributes forward air interface frames to all channel elements 40
involved in a call. 41
Backhaul Frame Handler: This function demultiplexes the control information and 42
the air interface reverse frame from the frame received over the backhaul network. It 43
also multiplexes the control information and the air interface frames in the forward 44
direction. 45
TIA-2001.1-C
9 Section 1
External Frame Handler: This function exchanges backhaul frames with channel 1
elements which are remote from the Selector. 2
Intra-BS Frame Handler: This function exchanges backhaul frames with channel 3
elements involved in intra-BS soft handoff. 4
Control: This function provides control functions. 5
Sector. A face of a of physical radio equipment implementation. 6
Signaling Connection. A connection intended to provide a path for signaling traffic. 7
Source Base Station. The BS that is in control of the call. 8
Target Base Station. Any BS that supports the call other than the source BS. 9
1.4 Organization 10
This section outlines the relationship of the current specification with neighboring 11
elements (air interface, packet data network and the core network) as well as with older 12
versions of the IOS itself. The cross reference of IOS specifications in section 1.4.2 is 13
provided for information and is not intended to indicate additional requirements for the 14
IOS. 15
1.4.1 This Revision of the IOS 16
This revision of the IOS specification describes the protocol necessary to provide to 17
wireless radio telephone subscribers certain services requiring interaction between the 18
Mobile Switching Center (MSC), the Packet Control Function (PCF), the Packet Data 19
Service Node (PDSN), and the base station (BS), and is based on interoperation with the 20
cdma2000
air interface [1]~[6], the wireless IP network [8] and the ANSI-41 core 21
network [9]. 22
1.4.2 Overall IOS Specifications 23
When addressing previous revisions of the Interoperability Specification, this revision of 24
the specification uses a common (historical) identifier, IOS v x.y.z, which can be cross 25
referenced as shown in Table 1.4.2-1. 26
27
TIA-2001.1-C
Section 1 10
Table 1.4.2-1 IOS Cross References 1
Common
2

CDG 3GPP2 TIA
Air Interface
3

- - - IS-634
December 1995
IS-95
July 1993
- - - IS-634-A
July 1998
IS-95-A
May 1995
- - - IS-634-B
April 1999
TIA/EIA-95-B
March 1999
IOS v2.0.1 IOS v2.0.1
Dec 1998
- - -
IOS v2.2 IOS v2.2
June 1999
- - -
IOS v2.3 IOS v2.3
Feb 2000
- - -
IOS v2.4 IOS v2.4
March 2000
- - -
IOS v3.0 IOS v3.0
Nov 1998
- - -
IOS v3.1.1 IOS v3.1.1
Aug 1999
- - -
IOS v3.2 IOS v3.2
March 2001
- - -
IOS v4.0 - A.S0001 v0.1
June 2000
IS-2001
December 2000
IS-2000
August 2001
IOS v4.1 - A.S0001-A v2.0
June 2001
IS-2001-A
August 2001
IS-2000-A
April 2002
IOS v4.2 - A.S0011~17 v2.0
May 2002
TIA-2001-B
May 2002
TIA-2000-B
May 2002
IOS v4.3 - A.S0011~17-A v2.0
July 2003
TIA-2001-C
July 2003
TIA-2000-B
May 2002
2
1.5 Document Layout 3
The Interoperability Specification is organized into seven parts, each published in a 4
separate document: 5
Overview general overview, published in [11] 6
Transport protocol definitions and transport requirements, published in [12] 7
Features descriptions of features, published in [13] 8
A1/A2/A5 Interfaces definition of the A1/A2/A5 interfaces, published in [14] 9
A3/A7 Interfaces definition of the A3/A7 interfaces, published in [15] 10

2
The Common identifier aligns with numbering used in the Software Version Information Element.
3
The relationship between air interface and IOS releases is provided for information and is not intend-
ed to be an absolute indication of features supported by an IOS release.
TIA-2001.1-C
11 Section 1
The interface documents define the individual interfaces this includes message 1
procedures, message bitmaps, information element definitions, and the definitions of 2
timers that are related to the interface. Note that some information elements are used on 3
multiple interfaces; in this situation, the information element is defined in each of the 4
associated interface documents. Changes to the definition of an information element in 5
one interface document do not imply changes to its definition in other interface 6
documents. However, insofar as possible, the same Information Element Identifier shall 7
be used in all definitions of the same information element. 8
The Features document provides descriptions of the features supported in the IOS and 9
Stage 2 text (e.g. call flows) for these features, which interfaces are used, which messages 10
are used, and how the feature is implemented using these messages. 11
1.6 Documentation Conventions 12
Shall and shall not identify requirements to be followed strictly to conform to the 13
standard and from which no deviation is permitted. Should and should not indicate 14
that one of several possibilities is recommended as particularly suitable, without 15
mentioning or excluding others; that a certain course of action is preferred but not 16
necessarily required; or (in the negative form) that a certain possibility or course of action 17
is discouraged but not prohibited. May and need not indicate a course of action 18
permissible within the limits of the standard. Can and cannot are used for statements 19
of possibility and capability, whether material, physical, or causal. 20
The scenarios and examples in this specification are not meant to be exhaustive, but are 21
only used to help explain some of the important procedures of the protocol. 22
Figure 1.6-1 is provided as an example of the call flow conventions used in this 23
specification. 24
Several points within the diagram are worthy of note. The circled numbers in the 25
following figure correspond to the numbered items below. 26
1. Horizontal dotted lines are used to indicate messaging that is not part of defined 27
interfaces specified in this specification. Not all air interface messages are shown, 28
and names may be generic. For example, the phrase handoff direction message is 29
meant to include Extended Handoff Direction Message (EHDM), General Handoff 30
Direction Message (GHDM), and Universal Handoff Direction Message (UHDM). 31
2. Vertical dotted lines between messages are used to indicate the span of timers. The 32
timer name is placed as close as possible to the line. Timer names begin with a 33
capital T followed by digits or alphabetic characters. If a timer expires prior to 34
reception of a message that stops the timer, the expiration is shown with an x at the 35
end of the vertical dotted line. 36
3. Horizontal solid lines are used to indicate messaging that is part of the interfaces 37
specified in this standard. 38
4. Lower case letters are associated with individual messaging instances in the diagram 39
in alphabetical order arranged vertically. These letters correlate the text below the 40
diagram with portions of the diagram. 41
5. Procedures that may involve the exchange of several messages are shown as an open 42
block arrow with the name of the procedure inside. 43
6. Comments related to parts of the diagram are located in a comment column on the 44
right side of the diagram. 45
TIA-2001.1-C
Section 1 12

1
MS BS MSC
time comment
Order
a
b
c
d
f
Message
Message
Message
Order
Tx
Ty
Comments
e Procedure
2
3
5
4
6
1
Figure 1.6-1 Document Convention Example: Call Clear Initiated by MS 2
a. The MS transmits an Order over the reverse link. 3
b. The BS sends a message to the MSC. The BS starts timer T
x
. 4
c. The MSC sends a message to the BS and starts timer T
y
. The BS stops timer T
x
. 5
d. The BS acknowledges the MS message by returning an Order over the forward link. 6
e. The BS and MSC execute the procedure. 7
f. The BS returns a message to the MSC. The MSC stops timer T
y
. 8
1.6.1 Procedural Descriptions 9
The procedural descriptions are broken into sections where each section describes one of 10
the messages in the procedure. The description for each procedure is written to flow 11
through each section devoted to the messages that make up the procedure. Each of these 12
sections has the following subsection breakdowns (as appropriate): 13
1. Successful Operation: this section is used to describe what the message is for, why 14
the sender is sending it, and what the receiver is expected to do with the message. It 15
may also provide a brief tutorial on the overall impact of this message regarding the 16
particular procedure. It includes invocation of any pertinent timers or discussion of 17
timing constraints. It may also provide subsections that describe the uses of the 18
elements within the message, particularly if they are not obvious. 19
2. Failure Operation: if applicable, this section is used to describe the actions of the 20
sender if the expected response is not received by the sender. This includes treatment 21
of timer expiration or receipt of failure messages stemming from the message that 22
was sent. 23
3. Abnormal Operation: if applicable, this section is used to describe out of sequence 24
events that could possibly occur and the treatment by the receiver of the message. 25
26
TIA-2001.1-C
13 Section 2
2.0 Interface Model 1
The logical reference model used for this standard is the Network Reference Model as 2
shown in [18]. 3
2.1 Reference Points A, A
ter
, A
quinter
, and A
quater
4
The Network Reference Model contains reference points A, A
ter
, A
quinter
, and A
quater
that 5
are implemented by the protocols and interfaces of this standard. 6
The A reference point is implemented by the A1, A2 and A5 interfaces. 7
The A
ter
reference point is implemented by the A3 and A7 interfaces. 8
The A
quater
The A
quinter
2.2 Interface Reference Model 11
The interfaces defined in this standard are described below. 12
A1 The A1 interface carries signaling information between the call control and 13
mobility management functions of the MSC and the call control component 14
of the BS (BSC). 15
A2 The A2 interface is used to provide a path for user traffic. The A2 interface 16
carries 64/56 kbps PCM information (for circuit-oriented voice) or 64 kbps 17
Unrestricted Digital Information (UDI, for ISDN) between the Switch 18
component of the MSC and the Selection/Distribution Unit (SDU) function 19
of the BS. 20
A3 The A3 interface is used to transport user traffic and signaling for inter-BS 21
soft/softer handoff when a target BS is attached to the frame selection 22
function within the source BS. The A3 interface carries coded user 23
information (voice/data) and signaling information between the source BS 24
SDU function and the channel element component (BTS) of the target BS. 25
This is a logical description of the endpoints of the A3 interface. The 26
physical endpoints are beyond the scope of this specification. The A3 27
interface is composed of two parts: signaling and user traffic. The signaling 28
information is carried across a separate logical channel from the user traffic 29
channel, and controls the allocation and use of channels for transporting 30
user traffic. 31
A5 The A5 interface is used to provide a path for user traffic for circuit- 32
oriented data calls between the source BS and the MSC. The A5 interface 33
carries a full duplex stream of bytes between the switch component of the 34
MSC and the SDU function of the BS. 35
A7 The A7 interface carries signaling information between a source BS and a 36
target BS for inter-BS soft/softer handoff. 37
A8 The A8 interface carries user traffic between the BS and the PCF. 38
A9 The A9 interface carries signaling information between the BS and the PCF. 39
A10 The A10 interface carries user traffic between the PCF and the PDSN. 40
A11 The A11 interface carries signaling information between the PCF and the 41
PDSN. 42
TIA-2001.1-C
Section 2 14
This is a logical architecture that does not imply any particular physical implementation. 1
For this standard the IWF for circuit-oriented data calls is assumed to be located at the 2
MSC, and the SDU function is considered to be co-located with the source BSC. Figure 3
2.2-1 shows the relationship among network components in support of mobile 4
originations, mobile terminations, and direct BS-to-BS soft/softer handoff operations. 5
6
Switch
A1 A2
Call Control,
Mobility
Management
MSC
A3 (user traffic)
A5
A7 (signaling)
A3 (signaling)
SDU
Function
BTS
BSC
A9 (signaling)
Source
BS
(This interface is not included
in this specification.)
A
ter
Reference
Point
PCF
PDSN
A10 (user traffic)
A11 (signaling)
A8 (user traffic)
A
quater Reference
Point
Target BS
BSC
User Traffic User Traffic Signaling
A
quinter Reference
Point
A Reference Point
BTS
SDU
Function
IWF
7
Figure 2.2-1 Reference Model for cdma2000
Access Network Interfaces 8

9
TIA-2001.1-C
15 Section 3
3.0 Information Flows 1
The interfaces defined in this standard provide: 2
bearer (user traffic) connections (A2, A3 (traffic), A5, A8, and A10); 3
a signaling connection between the channel element component of the BS and the 4
SDU function (A3 signaling); 5
a direct BS to BS signaling connection (A7); 6
a signaling connection between the BS and the MSC (A1); 7
a signaling connection between the BS and PCF (A9); and 8
a signaling connection between a PCF and PDSN pair (A11). A11 signaling 9
messages are also used for passing accounting related and other information from the 10
PCF to the PDSN. 11
In general, the functions specified on the interfaces are based on the premise that the 12
interfaces carry signaling information that traverses the following logical paths: 13
between the BS and MSC only (e.g., BS management information); 14
between the MS and the MSC via the BS (e.g., the BS maps air interface messages to 15
the A1 interface); 16
between the BS and other network elements via the MSC; 17
between the source BS and the target BS; 18
between the BS and the PCF; 19
between the PCF and the PDSN; and 20
between the MS and the PDSN (e.g., authorization information and Mobile Internet 21
Protocol (MIP) signaling). 22
These logical paths define all of the traffic that can exist on the defined interfaces. 23
24
25
TIA-2001.1-C
Section 3 16
1
3
4
5
6
7
TIA-2001.1-C
17 Section 4
4.0 MS Mobility for Packet Data Service 1
The Figure 4-1 provides a conceptual view of levels of packet data mobility. 2

Home Agent
PDSN PDSN
PCF
PCF PCF
BSC
BSC BSC
BSC
BTS BTS BTS BTS BTS BTS BTS
Mobility between PDSNs
(Mobile IP)
Mobility between PCFs
(A10/A11 Interfaces)
Mobility between BSCs
(A8/A9 Interfaces)
Mobility between BTSs
(Intra-BS Hard Handoff)
3
Figure 4-1 Levels of Packet Data Mobility 4
The A8/A9 interfaces support MS mobility between BSCs under the same PCF. 5
The A10/A11 interfaces support MS mobility between PCFs under the same PDSN. 6
MIP [19] supports MS mobility between PDSNs under the same Home Agent. The 7
PDSN provides the functionality of the Foreign Agent (FA). 8
Hard handoff, fast handoff, dormant handoff and soft handoff procedures realize MS 9
mobility between BTSs. 10
11
TIA-2001.1-C
Section 4 18
1
2
(This page intentionally left blank.)

TIA-2001.2-C
1
2
3
4
5
Access Network Interfaces Part 2 Transport 6

TIA-2001.2-C

1
3

TIA-2001.2-C
i
Table of Contents 1
2
1.0 Introduction ........................................................................................................................................ 1 3
1.1 Overview........................................................................................................................................ 1 4
1.1.1 Purpose ................................................................................................................................... 1 5
1.1.2 Scope ...................................................................................................................................... 1 6
1.2 References ...................................................................................................................................... 1 7
1.2.1 TIA / EIA................................................................................................................................ 1 8
1.2.2 3GPP2..................................................................................................................................... 2 9
1.2.3 Standards Committee T1 ........................................................................................................ 2 10
1.2.4 International Telecommunications Union - Telecommunications Sector (ITU-T)................. 3 11
1.2.5 Other ....................................................................................................................................... 3 12
1.3 Terminology ................................................................................................................................... 4 13
1.3.1 Acronyms................................................................................................................................ 4 14
1.3.2 Definitions .............................................................................................................................. 6 15
2.0 General Protocol Requirements.......................................................................................................... 7 16
2.1 Physical Layer (Layer 1) ................................................................................................................ 7 17
2.2 Link Layer (Layer 2) ...................................................................................................................... 8 18
2.3 Use of ATM.................................................................................................................................... 9 19
2.3.1 ATM Adaptation Layer .......................................................................................................... 9 20
2.3.2 Use of ATM AAL5 for Transmission of IP Datagrams.......................................................... 9 21
2.4 IP Transport Considerations ........................................................................................................... 9 22
2.4.1 IP Topologies.......................................................................................................................... 9 23
2.4.2 IP Network and Transport Specifications (Layers 3/4)......................................................... 10 24
2.4.2.1 Addressing........................................................................................................................ 10 25
2.4.2.2 Routing ............................................................................................................................. 10 26
2.4.2.3 Flow Association .............................................................................................................. 10 27
2.4.3 IP Performance Specifications.............................................................................................. 10 28
2.4.4 IP Quality of Service (QoS) Framework .............................................................................. 10 29
2.4.5 IP Security Framework Specifications.................................................................................. 11 30
2.5 Use of TCP................................................................................................................................... 11 31
2.5.1 Message Delimiting in TCP.................................................................................................. 11 32
2.5.2 TCP Connection Establishment ............................................................................................ 13 33
2.5.3 TCP Connection Release ...................................................................................................... 13 34
2.6 Use of GRE .................................................................................................................................. 13 35
2.6.1 Relationship of GRE tunnel to Quality of Service................................................................ 15 36
2.6.2 GRE Protocol Usage for VoIP SOs ...................................................................................... 15 37
3.0 Interface Specific Protocol Requirements ........................................................................................ 17 38
3.1 A1, A2, and A5 Interfaces............................................................................................................ 17 39
3.1.1 Base Station Application Part ............................................................................................... 17 40
3.1.1.1 The BS Management Application Part ............................................................................. 18 41
3.1.1.2 The Direct Transfer Application Part ............................................................................... 18 42
3.1.2 Signaling Connection Transport Protocol Options ............................................................... 18 43
3.1.3 User Traffic Connection Transport Protocol Options........................................................... 19 44
3.1.4 Use of ANSI SS7 Transport (Layer 2).................................................................................. 19 45
3.1.4.1 Field of Application.......................................................................................................... 20 46
3.1.4.2 Message Transfer Part ...................................................................................................... 20 47
3.1.4.2.1 General....................................................................................................................... 20 48
3.1.4.2.2 Level 1 (Chapter 2 of [23]) ........................................................................................ 20 49
3.1.4.2.3 Level 2 (Chapter 3 of [23]) ........................................................................................ 21 50
3.1.4.2.4 Level 3 (Chapter 4 of [23]) ........................................................................................ 21 51
3.1.4.2.5 Testing and Maintenance (Chapter 7 of [23]) ............................................................ 24 52
3.1.4.2.6 Interface Functions .................................................................................................... 24 53
3.1.4.2.7 Overload Control (Message Throughput Congestion) ............................................... 24 54
3.1.4.3 SCCP Transport Layer Specification (SCCP Functions).................................................. 24 55
TIA-2001.2-C
ii
3.1.4.3.1 Overview.................................................................................................................... 24 1
3.1.4.3.2 Primitives (Chapter 1 of [24]).................................................................................... 25 2
3.1.4.3.3 SCCP Messages (Chapter 2 of [24]) .......................................................................... 25 3
3.1.4.3.4 SCCP Formats and Codes (Chapter 3 of [24])........................................................... 27 4
3.1.4.3.5 SCCP Procedures (Chapter 4 of [24])........................................................................ 27 5
3.1.4.4 Use of the SCCP............................................................................................................... 29 6
3.1.4.4.1 Connection Establishment ......................................................................................... 29 7
3.1.4.4.1.1 Establishment Procedure - Case 1..................................................................... 29 8
3.1.4.4.1.2 Establishment Procedure - Case 2..................................................................... 31 9
3.1.4.4.2 Connection Release.................................................................................................... 32 10
3.1.4.4.3 Abnormal SCCP Release ........................................................................................... 32 11
3.1.4.4.3.1 SCCP Release by BS: Loss of SCCP Connection Information......................... 33 12
3.1.4.4.3.2 SCCP Release by MSC: Loss of SCCP Connection Information ..................... 33 13
3.1.4.4.4 SCCP Reference Generation Philosophy................................................................... 34 14
3.1.4.4.5 SCCP Transfer of DTAP and BSMAP Messages...................................................... 35 15
3.2 A3 and A7 Interfaces.................................................................................................................... 39 16
3.2.1 Performance Specifications .................................................................................................. 39 17
3.2.1.1 Performance Specification for IP Protocol Stacks............................................................ 40 18
3.2.2 A3 User Traffic Transport Requirements ............................................................................. 40 19
3.2.2.1 ATM-Based User Traffic Transport ................................................................................. 40 20
3.2.2.1.1 Physical Layer (L1) Specification.............................................................................. 41 21
3.2.2.1.2 Use of ATM............................................................................................................... 41 22
3.2.2.1.3 Use of AAL2.............................................................................................................. 41 23
3.2.2.2 IP-Based User Traffic Transport....................................................................................... 41 24
3.2.2.2.1 Physical Layer (L1) Specification.............................................................................. 41 25
3.2.2.2.2 Layer 2 Specification ................................................................................................. 41 26
3.2.2.2.3 Use of IP .................................................................................................................... 41 27
3.2.2.2.4 Performance Specifications ....................................................................................... 42 28
3.2.2.2.5 QoS Specifications..................................................................................................... 42 29
3.2.2.2.6 Security Specifications............................................................................................... 42 30
3.2.3 A3/A7 Signaling Transport Requirements............................................................................ 42 31
3.2.3.1 ATM-Based Signaling Protocol Stack.............................................................................. 43 32
3.2.3.1.1 Use of Physical Layer ................................................................................................ 43 33
3.2.3.1.2 Use of ATM............................................................................................................... 43 34
3.2.3.1.3 Use of AAL5.............................................................................................................. 43 35
3.2.3.1.4 Use of IP .................................................................................................................... 43 36
3.2.3.1.5 Use of TCP ................................................................................................................ 44 37
3.2.3.2 IP-Based Signaling Protocol Stack ................................................................................... 44 38
3.2.3.2.1 Use of Physical Layer ................................................................................................ 44 39
3.2.3.2.2 Layer 2 Specification ................................................................................................. 44 40
3.2.3.2.3 Use of IP .................................................................................................................... 44 41
3.2.3.2.4 QoS Specifications..................................................................................................... 45 42
3.2.3.2.5 Security Specifications............................................................................................... 45 43
3.2.3.2.6 Use of SCTP .............................................................................................................. 45 44
3.2.3.2.7 Use of TCP ................................................................................................................ 45 45
3.3 A8 and A9 Interfaces.................................................................................................................... 46 46
3.3.1 Use of TCP ........................................................................................................................... 47 47
3.3.2 Use of UDP........................................................................................................................... 47 48
3.3.3 Use of GRE........................................................................................................................... 47 49
3.4 A10 and A11 Interface ................................................................................................................. 47 50
3.4.1 Use of UDP........................................................................................................................... 48 51
3.4.2 Use of GRE........................................................................................................................... 48 52
53
54
TIA-2001.2-C
iii
List of Figures 1
2
Figure 2-1 Transport Network Reference Model ..................................................................................... 7 3
Figure 2.5.1-1 Delimiting Messages in an IOS Application TCP Byte Stream........................................ 12 4
Figure 2.6-1 GRE Encapsulated User Traffic........................................................................................ 14 5
Figure 2.6-2 GRE Header...................................................................................................................... 14 6
Figure 3.1.1-1 A1 Interface Signaling Protocol Reference Model ........................................................... 18 7
Figure 3.1.2-1 A1 Signaling Protocol Stack............................................................................................. 19 8
Figure 3.1.3-1 A2 User Traffic Protocol Stacks....................................................................................... 19 9
Figure 3.1.3-2 A5 User Traffic Protocol Stacks....................................................................................... 19 10
Figure 3.1.4.4.1.1-1 SCCP Connection Establishment ...................................................................... 30 11
Figure 3.1.4.4.1.1-2 SCCP Connection Establishment Refusal ......................................................... 30 12
Figure 3.1.4.4.1.2-1 SCCP Connection Establishment During Handoff ........................................... 31 13
Figure 3.1.4.4.1.2-2 SCCP Connection Refusal During Handoff...................................................... 32 14
Figure 3.1.4.4.3.1-1 BS Initiated SCCP Release: BS Lost SCCP Connection Information .............. 33 15
Figure 3.1.4.4.3.2-1 MSC Initiated SCCP Release: MSC Lost SCCP Connection Information ....... 34 16
Figure 3.1.4.4.4-1 SLR/DLR Usage ........................................................................................................ 35 17
Figure 3.2.2-1 A3 User Traffic Protocol Stack ........................................................................................ 40 18
Figure 3.2.3-1 A3 and A7 Signaling Protocol Stack ................................................................................ 43 19
Figure 3.3-1 A9 Signaling Protocol Stack............................................................................................. 46 20
Figure 3.3-2 A8 User Traffic Protocol Stack ........................................................................................ 46 21
Figure 3.4-1 A11 Signaling Protocol Stack........................................................................................... 48 22
Figure 3.4-2 A10 User Traffic Protocol Stack....................................................................................... 48 23
24
25
TIA-2001.2-C
iv
List of Tables 1
2
Table 3.1.4.4.5-1 Use of the User Data Field in SCCP Frames ............................................................. 35 3
Table 3.1.4.4.5-2 Use of SCCP for BSMAP and DTAP Messages........................................................ 36 4
Table 3.2.1-1 Delay Budget Requirements ............................................................................................. 39 5
Table 3.2.1.1-1 A3/A7 Mapping Between Traffic Classes and Service-Level QoS ........................... 40 6
7
8
TIA-2001.2-C
1 Section 1
1.0 Introduction 1
2
1.1 Overview 3
This document contains the protocol definitions and transport requirements for the 4
interfaces defined in this specification. 5
1.1.1 Purpose 6
The purpose of this document is to describe the transport protocols and protocol stacks 7
used on the interfaces, which make up the logical network model, and to indicate any 8
unique aspects of these protocols that are relevant to the Interoperability Specification 9
(IOS). 10
1.1.2 Scope 11
This document contains generic and specific requirements for the IOS interfaces. The 12
document contains the generic protocol descriptions that are used through all of the IOS 13
interfaces. In addition, protocol stack and transport network requirements for each IOS 14
interface are contained in this document. Details of the IOS application and signaling 15
layer messages are contained in the respective interface documents [14], [15], [16], and 16
[17]. 17
1.2 References 18
19
1.2.1 TIA / EIA 20
For ease of cross-referencing, the Telecommunications Industry Association (TIA) / 21
with the Third Generation Partnership Project 2 (3GPP2) references, provided in section 23
1.2.2. 24
[1] Reserved. 25
[2] Reserved. 26
[3] Reserved. 27
[4] Reserved. 28
[5] Reserved. 29
[6] Reserved. 30
[7] Reserved. 31
[8] TIA/EIA/IS-835-A, cdma2000
1
Wireless IP Network Standard, May 2001. 32
[9] Reserved. 33
[10] Reserved. 34

1
cdma2000

TIA-2001.2-C
Section 1 2
[11] TIA-2001.1-C, Interoperability Specification (IOS) for CDMA 2000 Access 1
[12] Reserved. 3
[18] TIA-923, Link-Layer Assisted Service Options for Voice-over-IP: Header 14
Removal (SO60) and Robust Header Compression (SO61), May 2003. 15
[19] TIA-728, Intersystem Link Protocol (ISLP), January 1, 2002. 16
1.2.2 3GPP2 17
[1] Reserved. 20
[2] Reserved. 21
[3] Reserved. 22
[4] Reserved. 23
[5] Reserved. 24
[6] Reserved. 25
[7] Reserved. 26
[8] 3GPP2 P.S0001-A, Wireless IP Network Standard, July 2000. 27
[9] Reserved. 28
[10] Reserved. 29
Access 30
[12] Reserved. 32
Access 33
Access 35
Network Interfaces Part 4 (A1, A2, and A5 Interfaces), July 2003 36
Access 37
Access 39
Access 41
[18] 3GPP2 C.S0047-0, Version 1.0, Link-Layer Assisted Service Options for Voice- 43
over-IP: Header Removal (SO60) and Robust Header Compression (SO61), 44
April 14, 2003. 45
[19] 3GPP2 N.S0019, Intersystem Link Protocol, January 28, 2000 46
1.2.3 Standards Committee T1 47
[20] ANSI T1.101-1987, Synchronization Interface Standards for Digital Networks, 48
1987. 49
[21] ANSI T1.102-1987, Digital Hierarchy Electrical Characteristics, 1987. 50
TIA-2001.2-C
3 Section 1
[22] ANSI T1.107-1988, Digital Hierarchy Formats Specifications, 1988. 1
[23] ANSI T1.111-1992, Signaling System No. 7 (SS7) - Message Transfer Part 2
(MTP), June 1992. 3
[24] ANSI T1.112-1992, Signaling System No. 7 (SS7) - Signaling Connection 4
Control Part (SCCP), October 1992. 5
[25] ANSI T1.403-1995, Network to Customer Installation DS1 Metallic Interface, 6
1995. 7
[26] ANSI T1.627 - 1993, B-ISDN - ATM Layer Functionality and Specification, 8
1993. 9
[27] ANSI T1.635 1995, Broadband ISDN Physical Layer Specification for User- 10
Network-Interface Including DS1/ATM, 1995. 11
[28] ANSI T1.105 1995, Synchronous Optical Network (SONET) Basic 12
Description Including Multiplex Structure, Rates and Formats, 1995. 13
1.2.4 International Telecommunications Union - 14
Telecommunications Sector (ITU-T) 15
[29] ITU-T Recommendation G.707, Network Node Interface for the Synchronous 16
Digital Hierarchy (SDH), 1996. 17
[30] ITU-T Recommendation I.366.1, Segmentation and Reassembly Service Specific 18
Convergence Sublayer for the AAL type 2, June 1998. 19
[31] ITU-T Recommendation Q.2931, Broadband-Integrated Services Digital 20
Network (B-ISDN) Digital Subscriber Signaling No. 2 (DSS2) User-Network 21
Interface Layer 3 Specification for Basic Call/Connection Control, 1995. 22
1.2.5 Other 23
[32] Internet Engineering Task Force, RFC 768 User Datagram Protocol (UDP), 24
1980. 25
[33] Internet Engineering Task Force, RFC 791 Internet Protocol (IP), 1981. 26
[34] Internet Engineering Task Force, RFC 793 Transmission Control Protocol 27
(TCP), 1981. 28
[35] Internet Engineering Task Force, RFC 1483 Multiprotocol Encapsulation over 29
ATM Adaptation Layer 5, 1993. 30
[36] Internet Engineering Task Force, RFC 2002 IP Mobility Support Specification, 31
1996. 32
[37] Internet Engineering Task Force, RFC 2225 Classical IP and ARP over ATM, 33
1998. 34
[38] Internet Engineering Task Force, RFC 2475, An Architecture for Differentiated 35
Services, December 1998. 36
[39] Internet Engineering Task Force, RFC 2784 - Generic Routing Encapsulation 37
(GRE), 2000. 38
[40] Internet Engineering Task Force, RFC 2890 - Key and Sequence Number 39
Extensions to GRE, September 2000. 40
[41] Internet Engineering Task Force, RFC 2960, Stream Control Transmission 41
Protocol, October 2000. 42
43
TIA-2001.2-C
Section 1 4
1.3 Terminology 1
2
1.3.1 Acronyms 3
4
Acronym Meaning
3GPP2 3rd Generation Partnership Project 2
AAL2 ATM Adaptation Layer type 2
ADDS Application Data Delivery Service
Ack Acknowledgement
ATM Asynchronous Transfer Mode
BS Base Station
BSAP Base Station Application Part
BSMAP Base Station Management Application Part
CC Connection Confirm
CIC Circuit Identity Code
CM Connection Management
CR Connection Request
CREF Connection Refused
DCCH Dedicated Control Channel
DiffServ Differentiated Services
DLR Destination Local Reference
DPC Destination Point Code
DS0 Digital Signal Level 0
DSCP Differentiated Services Code Point
DT1 Data Transfer 1
DT2 Data Form 2
DTAP Direct Transfer Application Part
E1 E1-type Digital Carrier
ESN Electronic Serial Number
FCH Fundamental Channel
GRE Generic Routing Encapsulation
IMSI International Mobile Subscriber Identity
TIA-2001.2-C
5 Section 1
Acronym Meaning
IS Interim Standard
ISD Interface Service Delay
ISL Interface Service Packet Loss
ISLP Intersystem Link Protocol
IT Inactivity Test
ITU-T International Telecommunications Union
Telecommunications Standardization Sector
L1 Layer 1 (Physical Layer)
L2 Layer 2 (Link Layer)
L3 Layer 3 (Network Layer)
LLC Logical Link Control
LSB Least Significant Bit
Mbps Million Bits per Second
MS Mobile Station
MSB Most Significant Bit
Msg Message
MTP Message Transfer Part
OAMP Operation Administration Maintenance Provisioning
OC3 Optical Carrier Level 3
PACA Priority Access and Channel Assignment
PLMN Public Land Mobile Network
PPP Point to Point Protocol
PVC Permanent Virtual Circuit
QoS Quality of Service
RAN Radio Access Network
RFC Request For Comment
RLC Release Complete (SCCP)
RLSD Release (SCCP)
SCCP Signaling Connection Control Part
SCH Supplemental Channel
SCTP Stream Control Transmission Protocol
SDU Service Data Unit (ATM), Selector/Distribution Unit
(IOS)
SI Service Instance
SID Session Identifier
TIA-2001.2-C
Section 1 6
Acronym Meaning
SLR Source Local Reference
SLTM Signaling Link Test Message
SOG Subsystem Out-of-service Grant
SOR Subsystem Out-of-service
SS7 Signaling System Number 7
SSN Subsystem Number
STP Signaling Transfer Point
T1 T1-type Digital Carrier
T3 T3-type Digital Carrier
TCP Transmission Control Protocol
UDP User Datagram Protocol
UDT Unit Data (SCCP)
UNI User Network Interface
VC Virtual Circuit
Ver Version
VoIP Voice over Internet Protocol
1.3.2 Definitions 1
Refer to [11]. 2
3
TIA-2001.2-C
7 Section 2
2.0 General Protocol Requirements 1
The Transport specification uses protocols and terminology for the interface in the IOS, 2
that conform to the transport network reference model as outlined in Figure 2-1. Layer 1 3
is the physical layer. Layer 2 is the link layer. Layer 3 is the network layer, which may 4
consist of several hops connected by routing or switching nodes. Figure 2-1 shows two 5
hops but a network can have none or many hops. The transport layer is above L3 and is 6
an end-to-end protocol. The transport layer (TL) is terminated at end nodes within the 7
Radio Access Network (RAN). From a RAN perspective, the application layer (AL) 8
consists of IOS signaling messages and bearer frames on the IOS interface. Note the 9
transport network reference model may not be applicable to describe the protocol stack 10
for user traffic. 11
L3
L1 L1
L2
L2
L2 L2
L3 L3
L3
Network Router
or Switch
End Station End Station
AL
TL TL
AL
12
Figure 2-1 Transport Network Reference Model 13
The nodes comprising the RAN (e.g. Base Station (BS), Packet Control Function (PCF), 14
Packet Data Service Node (PDSN) and Mobile Switching Centers (MSCs)) are often 15
geographically distributed across and between areas of the transport network. 16
2.1 Physical Layer (Layer 1) 17
The IOS interfaces are based on the use of: 18
T1 digital transmission system interfaces. Each 1.544 Mbps interface provides 24*56 19
kbps or 24*64 kbps channels or a 1.544 Mbps clear channel, which can be used for 20
traffic or signaling as the operator requires. This type of interfaces can be full-duplex 21
or half-duplex when it is used as a clear channel. 22
E1 digital transmission interfaces consisting of 30*64 kbps user channels can also be 23
used for traffic or signaling, as the operator requires, and as applicable to the 24
network. 25
T3 digital transmission interfaces supporting transmission rates of 43.232 Mbps. 26
Optical Carrier Level 3 (OC3) digital transmission interfaces supporting transmission 27
rates of 155.52 Mbps. 28
Synchronous Transfer Mode 1 (STM1) [29] digital transmission interfaces 29
supporting transmission rates of 155.52 Mbps. 30
TIA-2001.2-C
Section 2 8
Asynchronouslayer 1 protocols (e.g. 10/100BaseT) may be used on some IOS interfaces. 1
These types of L1 protocols can be full or half-duplex, shared or dedicated. These types 2
of L1 protocols may provide guaranteed bandwidth to the L2 protocol. 3
When the L1 protocol cannot guarantee the bandwidth to the L2 protocol, a mechanism 4
should be provided by the L2 protocol that enables compliance to the performance 5
specifications in this document if required. 6
Common physical interface standards are found in [20] and related references. For a list 7
of references, refer to section 1.2. 8
2.2 Link Layer (Layer 2) 9
This standard uses different link layers on different interfaces. Message Transfer Part 2 10
and Asynchronous Transfer Mode (ATM) are used as the link layer (L2) protocol on 11
some interfaces. For Internet Protocol (IP)-based protocol stacks in this specification, 12
Layer 2 is left unspecified. In these cases requirements on L2 are invoked on an interface- 13
by-interface basis as stated in the interface specific section of this document. 14
The following requirements may apply to an unspecified L2 implementation or protocol 15
for IP: 16
Bandwidth efficiency: The L2 protocol provides functions to improve the bandwidth 17
efficiency of transport network layer protocols when the physical layer (L1) consists 18
of narrow-band (i.e., T1/E1 or lower rate) circuits. Bandwidth efficiency is defined 19
here as the ratio of the total number of bits comprising a packet to the number of 20
information (or payload) bits contained within that packet. 21
Delay/jitter control: The L2 protocol provides functions to manage queuing delay 22
and inter-packet transmission time variation (jitter) for all packet sources (e.g., 23
queuing, scheduling, prioritization). Queuing delay is defined here as the amount of 24
time that a network layer (layer 3) packet waits at link layer (layer 2) for 25
transmission on the physical interface (e.g. source bit-rate exceeds the transmission 26
bit-rate of the destination connection associated with that packet). 27
Multiplexing: This function collects and concatenates eligible buffered 28
frames/packet into one larger frame/packet reducing the impact of the protocol 29
overhead for each frame. If the IP transport network employs this type of function, it 30
shall be implemented in the link layer (L2) protocol. The implementation shall also 31
permit enabling and disabling this feature on an L2 connection basis. 32
Compression: This function eliminates the need for transmission of certain header 33
information (e.g., User Datagram Protocol (UDP) header, IP header, Point to Point 34
Protocol (PPP) ID) for every packet in a given flow by making use of well-known or 35
pre-negotiated connection state information. If the IP transport network employs this 36
type of function, it shall be implemented in the link layer (L2) protocol. The 37
implementation shall also permit enabling and disabling this feature on an L2 38
connection basis. 39
Segmentation and re-assembly (SAR): This function segments a packet (from the 40
transport network or higher layers) into multiple packets/frames to control latency. If 41
the IP transport network employs this type of function, it shall be implemented in the 42
link layer (L2) or IP layer (L3) protocol. If implemented in L2, the implementation 43
shall permit enabling and disabling this feature and controlling the respective frame 44
size on an L2 connection basis as required by performance specifications of the 45
connection. 46
TIA-2001.2-C
9 Section 2
Error detection: The L2 protocol provides an error detection function for the L2 1
protocol fields. The L2 protocol may provide error detection for layer 2 payload data. 2
The implementation shall permit enabling and disabling of this feature, if required by 3
the L2 protocol, on a per L2 connection basis. 4
Addressing: L2 addressing (e.g. MAC, VCI/VPI) supports a means of translating an 5
IP address (unicast, multicast or broadcast) to an associated L2 address. 6
2.3 Use of ATM 7
The ATM Layer uses a basic 53 octet cell consisting of a 5 octet header and 48 octet 8
payload. This standard uses the ATM Layer as specified in [26] without modification. 9
2.3.1 ATM Adaptation Layer 10
To make use of the basic cell transfer capability of the ATM Transport Layer in specific 11
usages, various ATM Adaptation Layers (AALs) have been defined. 12
Within this standard, two AALs are used: 13
AAL5 for the transfer of signaling, and 14
AAL2 for the transfer of user traffic (voice/data) on A3 traffic subchannels. 15
Both ATM Adaptation Layer Type 5 (AAL5) and ATM Adaptation Layer Type 2 16
(AAL2) are used without modification in this standard. The Service Specific 17
Segmentation and Reassembly sublayer for AAL2, as specified in [29], is used for 18
segmentation and reassembly of AAL2 SDUs. 19
In this version of this standard, the functionality of other sublayers of AAL2 are not 20
supported. Specifically, Service Specific Transmission Error Detection and Service 21
Specific Assured Data Transfer are not included. 22
2.3.2 Use of ATM AAL5 for Transmission of IP Datagrams 23
Use of the AAL5 Permanent Virtual Circuit (PVC) and Switched Virtual Connection as 24
the link layer of IP protocol stack shall follow [37]. Specification of either Logical Link 25
Control (LLC) and Sub Network Attachment Point encapsulation or Virtual Channel 26
(VC) multiplexing as per [35] is left to the discretion of operators and manufacturers. 27
2.4 IP Transport Considerations 28
The standard IP protocol, as defined in [33], shall be used for routing Internet Protocol 29
packets. 30
2.4.1 IP Topologies 31
Within the IOS RAN, an IP transport network may be used to provide communication 32
between the end nodes. This IP transport network itself may consist of transport nodes 33
(routers, switches, etc) arranged into a number of different topologies (e.g. point-to-point, 34
hierarchical, meshed, hub-spoke, star, etc). The transport network may also consist of one 35
or more communication links that connect the end nodes to the transport network and the 36
transport nodes to each other. The IP transport network may also consist of edge transport 37
nodes that interface to other RANs or packet data networks providing security, address 38
TIA-2001.2-C
Section 2 10
translation and other functions specific to the type of network they are connected to. 1
There is no restriction on the number or types of topologies or devices that can be used to 2
implement this RAN transport network. 3
2.4.2 IP Network and Transport Specifications (Layers 3/4) 4
This section provides a minimum set of requirements on transport and network layer 5
(layer 3/4) interfaces to the BS, PCF, PDSN, or other network devices in the RAN. 6
2.4.2.1 Addressing 7
The IP transport network may support a class-less IP addressing scheme. This is 8
necessary to allow flexibility in both routing and network design. To support this, a 9
hierarchical addressing scheme shall be implemented with Variable Length Subnet 10
Masks. 11
2.4.2.2 Routing 12
An implementation may choose one or more IP routing protocols as needed for non 13
point-to-point network topologies. 14
2.4.2.3 Flow Association 15
Every logical element defined in an IOS interface that may be an information source or 16
target may be individually addressable (e.g., via an IP address and UDP port number). In 17
cases where logical sub-elements exist, the IP address and port number (such as for UDP, 18
Transmission Control Protocol (TCP), or Stream Control Transmission Protocol (SCTP)) 19
may be used to uniquely identify a sub-element. Specific addressing requirements are set 20
forth in the individual interface specifications. 21
A traffic flow (i.e., radio frame protocols, call control signaling, O&M, etc.) may be 22
uniquely identified by the IP address of the destination element. In cases where logical 23
sub-flows exist, the IP address and port number of the destination sub-element may be 24
used to uniquely identify a flow. Mapping application flows to transport flows is 25
specified by the individual IOS interfaces. 26
2.4.3 IP Performance Specifications 27
Each IOS interface may specify the performance it requires from the transport network. 28
The following parameters may be specified by IOS interfaces that require performance 29
specifications: 30
Interface Service Delay (ISD): This is composed of the cumulative queuing, 31
transmission, and propagation delays across the transport network between nodes 32
supporting an IOS interface. 33
Interface Service Packet Loss (ISL): This is the packet loss across the transport 34
network between nodes supporting an IOS interface. 35
2.4.4 IP Quality of Service (QoS) Framework 36
To ensure that the transport network provide the necessary performance characteristics, 37
the end nodes and transport network interfaces which require QoS shall support the 38
TIA-2001.2-C
11 Section 2
Differentiated Services (DiffServ) framework as specified in [38], with the following 1
clarifications: 2
The A3/A7, A8/A9 and A10/A11 network portions of the RAN transport network 3
may be over-provisioned in comparison to the air interface (BS to MS) capacity, the 4
A3/A7, A8/A9 and A10/A11 network traffic loads, or both. In case a RAN transport 5
network is over-provisioned, the QoS framework in this section is not applicable to 6
that transport network. 7
Transport nodes (e.g., interior routers) shall support the following: 8
Per packet classification according to the Type of Service (TOS)/Differentiated 9
Services Code Point (DSCP) field in the IPv4 header 10
One or more queuing disciplines to meet the interfaces delay/jitter 11
requirements. 12
Edge transport nodes (e.g., border routers) shall support the following: 13
Policing disciplines to meet the traffic flow requirements. 14
End host nodes (e.g., BS, PCF, PDSNs) shall support the following when required: 15
Per packet marking of a DSCP via the IPv4 TOS octet according to the 16
prescribed DSCP value 17
Four or more traffic classes as defined by the relevant interface. The parameters 18
of each class include mandatory and optional traffic types, service delay, and 19
packet loss rate. 20
2.4.5 IP Security Framework Specifications 21
The IOS RAN is realized as a managed network. In this network, it is assumed that all 22
interfaces are physically secured as a minimum. For security measures specific to 23
particular IOS interfaces, refer to [13]. Any additional security measures are beyond the 24
scope of this standard. 25
2.5 Use of TCP 26
The standard TCP protocol, as described in [34], shall be used for establishing, using, and 27
clearing TCP connections. 28
TCP connections for signaling may be set up on a per-call basis or signaling messages for 29
multiple calls may be multiplexed on a single TCP connection. 30
The TCP protocol provides a reliable byte stream transfer. Therefore, a means needs to be 31
provided for two application entities to delimit the messages sent between them. The 32
technique for such delimitation is given below. 33
2.5.1 Message Delimiting in TCP 34
TCP provides a reliable byte stream between two application entities. Because the 35
protocol in this standard uses messages to communicate, these messages shall be 36
delimited in the TCP byte stream. Such delimitation shall be done by means of a two byte 37
flag field and a two byte length field inserted at the beginning of each message sent over 38
a TCP connection. The flag field shall contain the hex value F634. The purpose of the 39
flag field is to facilitate verification of message boundaries and to speed up 40
reestablishment of synchronization if synchronization of message boundaries is lost. 41
Refer to Figure 2.5.1-1. 42
TIA-2001.2-C
Section 2 12
7 6 5 4 3 2 1 0
Flag 1 1 1 1 0 1 1 0
Flag 0 0 1 1 0 1 0 0
Length (MSB)
Length (LSB)
First Octet of IOS Application Message
Second Octet of IOS Application Message
Msg Third Octet of IOS Application Message

Last Octet of IOS Application Message
Flag 1 1 1 1 0 1 1 0
Flag 0 0 1 1 0 1 0 0
Length (MSB)
Length (LSB)

Last Octet of IOS Application Message
Flag 1 1 1 1 0 1 1 0
Flag 0 0 1 1 0 1 0 0
Length (MSB)
Length (LSB)

Figure 2.5.1-1 Delimiting Messages in an IOS Application TCP Byte Stream 1
2
TIA-2001.2-C
13 Section 2
2.5.2 TCP Connection Establishment 1
A new TCP connection is established when a signaling message is required to be 2
exchanged over an interface and no such connection exists for that interface. Normal 3
active-passive TCP connection establishment procedures are used. 4
2.5.3 TCP Connection Release 5
An existing TCP connection over an interface may be released when there are no more 6
signaling messages to be exchanged over the interface. Normal TCP connection release 7
procedures are used. 8
2.6 Use of GRE 9
The upper layer for the A8 and A10 interfaces is the Generic Routing Encapsulation 10
(GRE) protocol as defined in [39] and extended in [35]. 11
The A10 connection and A8 connection are used for the transport of user data for a 12
packet data session. Link layer/network layer frames are carried between the BS, PCF 13
and the PDSN encapsulated in GRE packets, which in turn are carried over IP. The BS 14
Address, PCF-Address and the PDSN-Address are used in the source address and 15
destination address fields of the IP header used with the GRE packet. 16
In the bearer traffic direction from the PDSN to the PCF, the key field in the GRE header 17
contains the PCF Session Identifier (SID) that indicates which A10 connection a 18
particular payload packet belongs to. 19
In the bearer traffic direction from the PCF to the PDSN, the key field in the GRE header 20
contains the PDSN SID. 21
When the PDSN SID is unique within the PDSN, the PDSN can use it to identify which 22
A10 connection the packet belongs to. Otherwise, the PDSN may use the combination of 23
the PCF Address and the PDSN SID parameters of each received packet to identify the 24
associated A10 connection. 25
In the bearer traffic direction from the PCF to the BS, the key field in the GRE header 26
contains a unique BS identifier that indicates which A8 connection a particular payload 27
packet belongs to. 28
In the bearer traffic direction from the BS to the PCF, the key field in the GRE header 29
contains a unique PCF identifier that indicates which A8 connection a particular payload 30
packet belongs to. 31
With the A10 connection and A8 connection in place, link layer/network layer packets 32
pass over these connections in both directions between the BS and the PDSN using GRE 33
framing. In the direction towards the BS, the PDSN encapsulates the link/network layer 34
frames in GRE frames and sends them on the IP connection between the PDSN and PCF. 35
The PCF decapsulates the link/network layer frames in GRE frames before forwarding 36
them on the IP connection between the PCF and the BS. The BS accepts these GRE 37
frames, strips the GRE headers, and processes the link/layer frames as normal incoming 38
frames by passing them to the upper layer. The other direction behaves analogously: The 39
BS encapsulates the link layer/network layer frames in GRE frames and sends them on 40
the IP connection between the BS and the PCF, the PCF decapsulates the link/network 41
TIA-2001.2-C
Section 2 14
layer frames received from the IP connection and re-encapsulates the link/network layer 1
frames in GRE frames before forwarding them on the IP connection between the PCF and 2
the PDSN. The PDSN accepts the GRE frames, strips the GRE headers, and processes the 3
link/layer frames as normal incoming frames by passing them to the upper layer. 4
GRE encapsulates user traffic as shown in Figure 2.6-1. 5

GRE Header User Traffic
6
Figure 2.6-1 GRE Encapsulated User Traffic 7
Figure 2.6-2 shows the structure of the GRE header. 8
9
0
0
3
0
2
0
1
0 1 2 1 1 1 2 2 3 3 3 4 4 4 5 5 5 6 6 6 7 8 7 7 8 8 9 9 9
Key
Sequence Number (optional)
C S K r Ver reserved Protocol Type
10
Figure 2.6-2 GRE Header 11
The GRE header shall be encoded as follows: 12
C (Checksum Present) 0 13
r (reserved) 0 14
K (Key Present) 1 15
S (Sequence Number Present) 0 or 1 16
reserved 000000000 17
Ver (Version Number) 000 18
Protocol Type Hex 88 81 for Unstructured Byte Stream. 19
The BS shall set the Key field in the GRE header to the value in the Key field in the A8 20
Traffic ID element in the A9-Connect-A8 message received from the PCF indicating that 21
the PCF accepts the A8 connection. The PCF shall set the Key field in the GRE header to 22
the value in the Key field in the A8 Traffic ID element in the A9-Setup-A8 message 23
received from the BS requesting the establishment of the A8 connection. Refer to [16] for 24
details on these A9 messages. 25
The PCF shall set the Key field in the GRE header to the value in the Key field in the 26
Session Specific Extension in the A11-Registration Reply message received from the 27
PDSN indicating that the PDSN accepts the A10 connection. The PDSN shall set the Key 28
field in the GRE header to the value in the Key field in the Session Specific Extension in 29
the A11-Registration Request message received from the PCF requesting the 30
establishment of the A10 connection. Refer to [17] for details on these A11 messages. 31
If the link layer/network layer protocol requires that the GRE packets be delivered in 32
sequence (e.g. if a state-full compression mechanism is in use) over the connection, the S 33
indicator shall be set to 1 and the sequence number field shall be included in each GRE 34
packet sent over the connection. The sequence number field is used by the BS and PDSN 35
to deliver the GRE packets to the destination entity in sequence (e.g. over-the-air to the 36
TIA-2001.2-C
15 Section 2
MS, from the GRE to PPP layer in the PDSN). When the sequence number field is 1
included, the sender and receiver shall perform the following: 2
The sequence numbers shall be set to zero after the connection is established. 3
The sequence number shall be incremented according to [40] in each subsequent 4
packet sent on the same connection 5
Receipt of an out-of-sequence packet on a connection shall be handled according to 6
[40]. 7
2.6.1 Relationship of GRE tunnel to Quality of Service 8
The users IP traffic associated with the packet data service is tunneled across the RAN 9
using GRE/IP transport. The inner IP packet is the packet transmitted between the user 10
(e.g. Mobile Station (MS)) and its correspondent node (e.g. Internet server). The outer IP 11
packet transports (or tunnels) a portion of the inner packet between the RAN components 12
(i.e. BS, PCF, PDSN). Thus, the inner and outer packets may have inner and outer DSCP 13
values whose usage is described as follows. 14
To support QoS on the A8/A9 and A10/A11 interfaces, the RAN shall have a local RAN 15
transport network QoS policy which indicates which outer DSCP values can be used by 16
the PDSN, PCF and BS for traffic. These DSCP values shall be made available to the 17
PDSN (e.g. via O&M functions) to enable QoS for the RAN transport network. 18
When QoS is required for GRE tunnels across the A8/A9/A10/A11 transport network, the 19
IOS shall implement Diffserv as described in section 2.4.4 to support intra-network QoS 20
requirements. In addition, the BS, PCF and PDSN shall follow specific mapping rules as 21
follows: 22
1. The PDSN shall mark packets in the GRE tunnel (outer DSCP value) according to 23
the policy in use by the RAN transport network (refer to section 24.4) connecting the 24
PDSN to the PCF. This policy is local and specifies the DSCP values for use on each 25
GRE tunnel (i.e. service instance) instantiated on the PDSN. 26
2. The PCF and BS shall use the local QoS policy (refer to section 2.4.4) to set the 27
outer DSCP value of the packets in the GRE tunnels (i.e. service instance). Since the 28
PCF and BS are not required to inspect the encapsulated IP packets to derive the 29
inner DSCP value, the PCF and BS may mark all GRE packets in the same service 30
instance (SI) with the same DSCP value. The PCF and BS may also set the DSCP 31
value of all GRE packets associated with the same user to the same value if this is 32
the local policy. 33
3. The BS may use the outer DSCP value for RAN QoS functions (e.g. RLP frame 34
prioritization). However, the BS is not required to differentiate between packets in 35
the same SI or between users. 36
2.6.2 GRE Protocol Usage for VoIP SOs 37
GRE encapsulation is used to transport Voice over Internet Protocol (VoIP) frames. Like 38
the A8/A10 connections for ordinary packet data, the GRE Key field is used to 39
demultiplex these connections in the BS, PCF and PDSN. The GRE frame shall be 40
encapsulated in an IP packet sent between the PCF and PDSN on the A10 interface. The 41
GRE frame shall be encapsulated in an IP packet sent between the BS and PCF on the A8 42
interface. The VoIP SOs define their own format for the GRE payload and may make use 43
of the GRE sequence number or may require the sequence number to be absent. Refer to 44
the SO specification [18] for more details. 45
46
TIA-2001.2-C
Section 2 16
1
3
4
5
6
7
TIA-2001.2-C
17 Section 3
3.0 Interface Specific Protocol Requirements 1
This section provides specific requirements for various protocol layers used in the IOS 2
interfaces. 3
3.1 A1, A2, and A5 Interfaces 4
The MSC-BS interface consists of user traffic channels and signaling channels. In 5
general, user traffic channels are independent of signaling channels. Different paths and 6
different underlying transport technologies can be employed for each. 7
The A1 interface shall use one of the channelized physical layer protocols T1 or E1 8
interface from section 2.1. The T1 and E1 may be mapped into one of the higher digital 9
hierarchy protocols (e.g., T3, OC3, or STM1) specified section 2.1. 10
As a BS/MSC agreed option, Dedicated Signal Level 0 (DS0) signaling link(s) may be 11
used instead of the T1/E1 interface. 12
The A2 and A5 interface shall use one of the channelized physical layer protocols T1 or 13
E1 interface from section 2.1. The T1 and E1 may be mapped into one of the higher 14
digital hierarchy protocols (e.g., T3, OC3, or STM1) specified section 2.1. 15
This standard assumes the use of Signaling System Number 7 (SS7) signaling for the 16
transport protocol on the A1 interface. 17
3.1.1 Base Station Application Part 18
The Base Station Application Part (BSAP) is the application layer signaling protocol that 19
provides messaging to accomplish the functions of the A1 interface component of the 20
MSC - BS interface. BSAP is split into two sub-application parts; the BS Management 21
Application Part (BSMAP), and the Direct Transfer Application Part (DTAP). 22
A distribution function located in the BSAP, which is reflected in the protocol 23
specification by the layer 3 (A1) header, performs the discrimination between BSMAP 24
and DTAP messages. Refer to [14] for more information. 25
Refer to Figure 3.1.1-1 A1 Interface Signaling Protocol Reference Model for an 26
illustration of this structure. 27
TIA-2001.2-C
Section 3 18
Physical Layer
Transport
Protocols
BSAP
BS Side
MSC Side
A1 Interface
Transport
Protocols
BSAP
DTAP BSMAP
DTAP BSMAP
1
Figure 3.1.1-1 A1 Interface Signaling Protocol Reference Model 2
3.1.1.1 The BS Management Application Part 3
The BSMAP supports all Radio Resource Management and Facility Management 4
procedures between the MSC and the BS or a cell(s) within the BS. BSMAP messages 5
are not passed to the MS, but are used only to perform functions at the MSC or the BS. A 6
BSMAP message (Complete Layer 3 Information) is also used together with a DTAP 7
message to establish a connection for an MS between the BS and the MSC, in response to 8
the first layer 3 air interface message sent by the MS to the BS for each MS system 9
request. The description of the layer 3 protocol for the BSMAP information exchange is 10
contained in [14]. 11
The A1 messages that are considered BSMAP are listed in Table 3.1.4.4.5-2 and 12
specified in [14]. 13
3.1.1.2 The Direct Transfer Application Part 14
The DTAP messages are used to transfer call processing and mobility management 15
messages between the MSC and BS. DTAP messages carry call processing and mobility 16
management information that is primarily used by the MS. The BS shall map the DTAP 17
messages going to the MSC from the appropriate air interface signaling protocol. 18
The A1 messages that are considered DTAP are listed in Table 3.1.4.4.5-2 and specified 19
in [14]. 20
3.1.2 Signaling Connection Transport Protocol Options 21
Signaling over the A1 interfaces requires a reliable transport protocol and appropriate 22
addressing and routing mechanisms to deliver messages from source to destination. The 23
IOS application is independent of the underlying transport, which is left to the discretion 24
of operators and manufacturers. The signaling protocol stack options available to 25
operators and manufacturers for the A1 interface is shown in Figure 3.1.2-1. 26
TIA-2001.2-C
19 Section 3
1

Physical Layer
MTP 1
MTP 2
MTP3
SCCP
IOS Application
2
Figure 3.1.2-1 A1 Signaling Protocol Stack 3
3.1.3 User Traffic Connection Transport Protocol Options 4
The protocol stack options for transport of user traffic that are available to operators and 5
manufacturers are shown in Figure 3.1.3-1 and Figure 3.1.3-2. The link layer for the A5 6
interface uses the Intersystem Link Protocol (ISLP) [19]. 7

DS0
56/64 kbps PCM
DS0
64 kbps UDI
or
8
Figure 3.1.3-1 A2 User Traffic Protocol Stacks 9
DS0
ISLP
Data Octet Stream
10
Figure 3.1.3-2 A5 User Traffic Protocol Stacks 11
3.1.4 Use of ANSI SS7 Transport (Layer 2) 12
This standard specifies multiple protocols for the transport of signaling and user 13
information. Refer to sections 3.1.2 and 3.1.3. 14
TIA-2001.2-C
Section 3 20
When SS7 is used to provide signaling transport, the underlying transport mechanism 1
defined to carry signaling information between the BS and the MSC is the Message 2
Transfer Part (MTP) and the Signaling Connection Control Part (SCCP) SS7. 3
The MTP and SCCP are used to transport the application layer signaling protocol, which 4
is defined as the BSAP. 5
Information for this section was excerpted from [23] and [24]. Section 3.1.4.2 deals with 6
the MTP. Section 3.1.4.3 deals with SCCP and its use. 7
The MTP provides a mechanism giving reliable transfer of signaling messages. Section 8
3.1.4.2 deals with the subset of the MTP that can be used between a BS and a MSC, 9
which is compatible with a full MTP. 10
SCCP is used to provide a referencing mechanism to identify a particular transaction 11
relating to, for instance, a particular call. Section 3.1.4.3 identifies the SCCP subset that 12
shall be used between a BS and an MSC. SCCP can also be used to enhance the message 13
routing for operations and maintenance information. 14
3.1.4.1 Field of Application 15
This section is applicable to the signaling between BSs and MSCs in Public Land Mobile 16
Networks (PLMNs). It provides a minimum set of MTP requirements that may be 17
implemented at a BS or MSC, while maintaining compatibility with the implementation 18
of a full specification of the MTP. 19
This section defines the interfaces at the 56 or 64 kbps boundary to the BS or MSC and 20
applies primarily to digital access arrangements. The use of analog arrangements is not 21
supported. 22
The reliability of signaling links is an administrative concern. It is recommended that in 23
the case where more than one multiplex system is required and reliability reasons dictate 24
the use of multiple link sets, then each signaling link should be assigned in a different 25
multiplex system. 26
Only the associated mode of signaling is applicable to the BS. 27
3.1.4.2 Message Transfer Part 28
The American National Standards Institute (ANSI) recommendations concerning MTP 29
shall be taken as being requirements unless covered by a statement in this section. 30
3.1.4.2.1 General 31
The MTP functions as specified in [23] are applicable. However, the following 32
exceptions and modifications to those recommendations may be applied for the MSC to 33
BS signaling. Refer to section 3.1.4.2.2 through section 3.1.4.2.4. 34
3.1.4.2.2 Level 1 (Chapter 2 of [23]) 35
Chapter 2, Figure 2 36
These figures are for information only. For the A1 interface, interface point C is 37
appropriate. 38
TIA-2001.2-C
21 Section 3
Chapter 2, Section 1.4 Analog Signaling Link 1
The use of analog signaling links is not an available option. 2
Chapter 2, Section 2 General 3
A signaling rate of 56/64 kbps is assumed. 4
Chapter 2, Section 3 Error Characteristics and Availability 5
Error characteristics and availability are an operator concern. Excessive errors could lead 6
to inefficient use of the signaling links. 7
Chapter 2, Section 5 Digital Signaling Link 8
The standard arrangement is to derive the signaling link from a T1/E1 digital path. 9
However, dedicated DS0 signaling link(s) may be used as a BS/MSC agreed option. 10
Chapter 2, Section 6 Analog Signaling Data Link 11
Only digital signaling data links are supported. 12
3.1.4.2.3 Level 2 (Chapter 3 of [23]) 13
Chapter 3, Section 1.4 Signal Unit Error Correction 14
Only the basic error correction protocol is required. 15
Chapter 3, Section 7 Signaling Link Initial Alignment Procedure 16
In the initial alignment procedure specified in Chapter 3 of [23], only the emergency 17
proving period is applicable for the BS. Thus, in states 02 and 03 of the initial alignment 18
procedure status indication N is not sent from the BS. The BS should be capable of 19
recognizing status indication N if received in order for the alignment procedure to 20
complete. 21
3.1.4.2.4 Level 3 (Chapter 4 of [23]) 22
Chapter 4, Section 1.1.2 End Point of a Signaling Link 23
The BS is only implemented as the end point of a signaling link. There are no Signaling 24
Transfer Point (STP) network management features in the BS. 25
Chapter 4, Section 2 26
Since STP functions are not required for discrimination and routing, MTP functions used 27
between the MSC and the BS can be simplified. Since the implementation of this 28
interface is intended only for point-to-point applications, the routing function within MTP 29
is preset to select the point code appropriate to the parent MSC. 30
Chapter 4, Section 2.2 Routing Label 31
Load sharing is performed on the BS with more than one signaling link by means of the 32
Signaling Link Selection field. 33
TIA-2001.2-C
Section 3 22
Chapter 4, Section 2.3 Message Routing Function 1
Load sharing between link sets is not required since there can only be one link set 2
between the BS and MSC. 3
Chapter 4, Section 2.3.5 Handling of Messages under Signaling Link Congestion 4
The procedures for handling message congestion priority levels as defined for U. S. 5
Signaling Networks in Chapter 4, section 2.3.5.2 of [23] shall be followed. The message 6
priorities given in Appendix B (of Chapter 5 of [23]) for SCCP and MTP messages shall 7
be used. The remaining message priorities for BSMAP and DTAP messages are provided 8
in [14]. 9
Chapter 4, Section 2.4 Message Discrimination 10
At the BS, only messages with a correct Destination Point Code (DPC) are accepted. 11
Other messages are discarded. It is recommended that discarding a message because of an 12
incorrectly set point code should cause an incident report to be generated. 13
At an MSC (which has the capability of acting as an STP), administration procedures 14
may determine that each message received from a BS signaling link is passed through a 15
screening function that checks that the DPC of the message is the same as the Signaling 16
Point code of the exchange. If that is the case, the message is sent to the normal MTP 17
message handling functions. Otherwise, the message is discarded and an incident report is 18
made. 19
Chapter 4, Section 3 Signaling Network Management 20
Since the A1 interface utilizes point to point signaling between the BS and the MSC, the 21
Signaling Route Management procedures, including the status of signaling routes, 22
signaling route restricted, signaling route unavailability and availability, are not required. 23
Chapter 4, Section 3.8 Signaling Network Congestion 24
The procedures defined for U. S. Networks shall be followed for handling congestion on 25
signaling links. 26
Chapter 4, Section 4 Signaling Traffic Management 27
Since the A1 interface utilizes point to point signaling, the Traffic Management 28
procedures supporting signaling routes, including signaling route restricted, signaling 29
route unavailability and availability, are not required. 30
Chapter 4, Section 4.2 31
The normal routing situation is that there are one or more signaling links available 32
between the BS and MSC, and these links constitute a link set. They are run in load 33
sharing mode and changeover and change back procedures are supported between these 34
signaling links. 35
Chapter 4, Section 4.3.3 36
There is no alternative link set. 37
TIA-2001.2-C
23 Section 3
Chapter 4, Section 5 Changeover 1
Changeover between link sets is not applicable. 2
Chapter 4, Section 6 Change back 3
Change back between link sets is not applicable. 4
Chapter 4, Section 7 Forced Rerouting 5
Forced rerouting is not applicable since there is only one signaling route existing between 6
the BS and the MSC. 7
Chapter 4, Section 8 Controlled Rerouting 8
Controlled rerouting is not applicable since there is only one signaling route existing 9
between the BS and the MSC. 10
Chapter 4, Section 9 MTP Restart 11
The MTP Restart procedure is not required. 12
Chapter 4, Section 11 Signaling Traffic Flow Control 13
The Signaling Route Management procedures supporting signaling traffic flow control 14
including signaling route unavailability and signaling route set congestion are not 15
applicable for the A1 interface. 16
Chapter 4, Section 12 Signaling Link Management 17
Only basic link management procedures are applicable. 18
Chapter 4, Section 13 Signaling Link Management 19
Signaling Route Management procedure is not applicable for the A1 interface since it is a 20
point to point connection. No action is required upon reception of a Transfer-Prohibited 21
Signal, Transfer-Restricted Signal, Transfer-Allowed Signal, Signaling Route Set Test, 22
Signaling Route Set Congestion Test, or Transfer Control message. 23
Since all messages are passed using the SCCP, the service indicator is: D=0, C=0, B=1, 25
A=1. 26
The sub service field is always set to D=1, C=0, to indicate a national network. 28
The formats and codes listed are only relevant to the messages that are required. 30
TIA-2001.2-C
Section 3 24
3.1.4.2.5 Testing and Maintenance (Chapter 7 of [23]) 1
Chapter 7, Section 2.1 Signaling Data Link Test 2
The Signaling Data Link Test procedure is not required for the A1 interface. 3
The generation of a Signaling Link Test Message (SLTM) is not applicable at the BS; 5
however the BS shall be capable of responding with an acknowledgment message to an 6
SLTM. 7
3.1.4.2.6 Interface Functions 8
The method of interfacing to the higher layers is by the primitives defined in Chapter 1 of 9
[23]. 10
The primitives defined are: 11
MTP Pause indication 12
MTP Resume indication 13
MTP Status indication 14
MTP Transfer request 15
MTP Transfer indication 16
3.1.4.2.7 Overload Control (Message Throughput Congestion) 17
MTP overload control is not required. 18
3.1.4.3 SCCP Transport Layer Specification (SCCP Functions) 19
20
3.1.4.3.1 Overview 21
The purpose of this section is to identify the subset of the SCCP functions that are 22
necessary to achieve the management of the MS transactions in the A1 interface, and to 23
provide addressing facilities. If this subset of SCCP functions is implemented, 24
compatibility with a full ANSI SCCP shall be maintained. Only the needs of the BSAP 25
are taken into account in this section. 26
The following simplifications are applicable to the signaling between BS and MSC in 27
PLMNs: 28
To limit the complexity of the procedures, a BS exchanges signaling messages only 29
with its MSC, where a protocol conversion may be needed in some cases. Therefore, 30
no SCCP translation function is required in the MSC between the national and the 31
local SCCP and MTP within the MSC area. 32
Several functions of the SCCP are not used on the A1 interface: error detection, 33
receipt confirmation, and flow control. 34
The segmenting/reassembling function shall be used if the total message length 35
exceeds the maximum allowed message length that can be carried by the MTP. 36
TIA-2001.2-C
25 Section 3
Chapters 1 through 4 of [24] are considered as the basis for elaboration of this 1
document. 2
3.1.4.3.2 Primitives (Chapter 1 of [24]) 3
Chapter 1, Table 1 4
Two primitives of the table are not used: 5
N-INFORM DATA 6
N-RESET 7
The following parameters of the N-CONNECT primitive are not used: 9
Responding address 10
Receipt confirmation selection 11
Expedited data selection 12
The following parameter of the N-DATA primitive is not used: 14
Confirmation request 15
The following parameter of the N-DISCONNECT primitive is not used: 17
Responding address 18
Permanent signaling connections are not applicable. 20
The primitive N-NOTICE is not used. 22
Chapter 1, Table 8A 23
The following parameter of the N-UNITDATA primitive is not used: 24
Return option 25
Functions for permanent signaling connections are not applicable. 27
3.1.4.3.3 SCCP Messages (Chapter 2 of [24]) 28
The Data Acknowledgment message is not used. 30
TIA-2001.2-C
Section 3 26
The Data Form 2 (DT2) message is not used. 2
The Expedited Data message is not used. 4
The Expedited Data Acknowledgment message is not used. 6
The Protocol Data Unit Error message is not used; the inconsistent messages of the SCCP 8
protocol are discarded. 9
The Reset Confirm message is not used. 11
The Reset Request message is not used. 13
The Subsystem-Out-Of-Service-Grant (SOG) message is not used. 15
The Subsystem-Out-Of-Service (SOR) message is not used. 17
The Unit Data Service message is not used. 19
The credit parameter field is not used for protocol class 2. However, the parameter 21
shall still be included in the Inactivity Test (IT) message for syntax reasons. 22
The error cause parameter field is not used. 24
The receive sequence number parameter is not used. 26
The reset cause parameter field shall not be used. 28
TIA-2001.2-C
27 Section 3
The sequencing/segmenting parameter field is not used for protocol class 2. However, 2
the parameter shall still be included in the IT message for syntax reasons. 3
3.1.4.3.4 SCCP Formats and Codes (Chapter 3 of [24]) 4
For point-to-point network structures (i.e., direct connections between the MSC and BS), 6
the called party address may consist of the single element: subsystem number. 7
No global title is used. The signaling point code which is coded in the MTP routing label 8
and the Subsystem Number (SSN) in the called party address allow the routing of the 9
message. 10
Chapter 3, Section 3.4.2.2 11
SSN Values: BSAP = 11111100, (252) 12
Use of alternative values is an administrative concern. 13
Note: It was determined that the IOS A1 interface should use its own SSN value and this 14
was selected as BSAP = 11111100 (252). 15
Global title: refer to Chapter 3, section 3.4 of [24]. 17
Protocol Class: the classes 1 and 3 are not used. 19
Chapter 3, Sections 3.8, 3.9, 3.10, 3.13, 3.14 20
Parameters are not used. 21
Chapter 3, Sections 4.8, 4.9, 4.11, 4.12, 4.13, 4.14, 4.15, 4.16 22
Messages are not used. 23
SOR and SOG are not needed. 25
3.1.4.3.5 SCCP Procedures (Chapter 4 of [24]) 26
Chapter 4, Sections 1.1.2.2, 1.1.2.4 27
Protocol classes 1 and 3 are not used. 28
TIA-2001.2-C
Section 3 28
A signaling connection consists of a single connection section. No intermediate nodes are 2
defined in the A1 interface. 3
The use of multiple connections sections is an administrative concern. 4
Chapter 4, Section 1.2.1 (b) 5
Not applicable for single connections. 6
Chapter 4, Section 2.1 (1.) 7
Global title not used for single connections. 8
SSN is only present in the called party address for single connections. 10
The addressing information may take the following form in the N-CONNECT request 12
primitive: DPC+SSN (for single connections). 13
No SCCP translation function is required for single connections. 15
Chapter 4, Section 2.3.1 (3) 16
Chapter 4, Section 2.3.2 (4) 18
Not applicable: no protocol class and flow control negotiations. 21
Not applicable. 23
Not applicable. 25
Not applicable. 27
Not applicable. 29
TIA-2001.2-C
29 Section 3
Not applicable. 2
Chapter 4, Sections 3.6, 3.7, 3.9, 3.10 3
Not applicable. 4
Message return is not applicable. 6
Only those messages and procedures relating to non-replicated subsystems or nodes are 8
required. At the BS the concerned point is the parent MSC. The subsystem involved is 9
the BSAP. 10
3.1.4.4 Use of the SCCP 11
The SCCP is used to support signaling messages between the MSC and the BS. BSAP 12
(refer to section 3.1.1) uses one SCCP signaling connection for the transfer of layer 3 13
(A1) messages per MS. 14
The SCCP uses both connectionless (Class 0) and connection-oriented (Class 2) 15
procedures to support the BSAP. The procedures in this specification identify whether 16
connection-oriented or connectionless procedures are to be used for each layer 3 (A1) 17
procedure. 18
3.1.4.4.1 Connection Establishment 19
The initial messages exchanged in call setup are used to establish an SCCP connection 20
for subsequent signaling communications relating to the call. A new connection is 21
established when individual information related to an MS transaction is required to be 22
exchanged between a BS and an MSC, and no such transaction exists between the MSC 23
and that BS. 24
Two connection establishment cases are distinguished: 25
Case 1. A new transaction (e.g., Location updating, incoming or outgoing call 26
refer to [13]) is initiated on the radio path. Following an Access 27
Request made by the MS on the Access Channel, the connection 28
establishment is then initiated by the BS. 29
Case 2. The MSC decides to perform an inter-BS handoff (refer to [13]). The 30
connection establishment is then initiated by the MSC. 31
3.1.4.4.1.1 Establishment Procedure - Case 1 32
In this case, the connection establishment is initiated at the reception by the BS of the 33
first layer 3 message from the MS. Generally, such a message contains the Mobile 34
Identity parameter (Electronic Serial Number (ESN), or International Mobile Subscriber 35
Identity (IMSI)). The BS then constructs the first A1 interface BSMAP message 36
(Complete Layer 3 Information), which includes one of the appropriate DTAP messages 37
(Location Updating Request, Connection Management (CM) Service Request, or Paging 38
Response) depending on whether the MS is accessing the network for the purpose of 39
TIA-2001.2-C
Section 3 30
registration, call origination, or termination. The Complete Layer 3 Information message 1
is sent to the MSC in the user data field of the SCCP Connection Request message (refer 2
to [14]). The Complete Layer 3 Information message includes the cell identity and the 3
layer 3 message that was received from the MS. The exact coding of the BSMAP 4
message is specified in [14]. 5
Upon the reception of the SCCP Connection Request message, the MSC may check, 6
based on the received identity, whether another association already exists for the same 7
MS. If this is the case, the connection establishment is refused. Otherwise, an SCCP 8
Connection Confirm message is sent back to the BS. This message may optionally 9
contain a BSMAP or DTAP message in the user data field. 10
The diagram in Figure 3.1.4.4.1.1-1 shows a successful SCCP connection establishment 11
procedure. 12
Time
a
b
BS MSC
SCCP Connection Confirm
SCCP Connection Request: Complete Layer 3 Info
T3230
Comment
13
Figure 3.1.4.4.1.1-1 SCCP Connection Establishment 14
a. The BS sends an SCCP Connection Request message, including a user data field, to 15
the MSC. The BS starts timer T
3230
. Refer to [14] for the T
3230
timer definition. 16
b. Upon receipt of the SCCP Connection Request message, the MSC sends an SCCP 17
Connection Confirm message, which may contain a Layer 3 application message, to 18
the BS. Upon receipt of this message, the BS stops timer T
3230
and establishes the 19
connection. 20
The procedures in case of connection establishment refusal are shown in Figure 21
3.1.4.4.1.1-2. 22
Time
a
b
BS MSC
SCCP Connection Refused
SCCP Connection Request: Complete Layer 3 Info
T3230
Comment
23
Figure 3.1.4.4.1.1-2 SCCP Connection Establishment Refusal 24
a. The BS sends an SCCP Connection Request message, including a user data field, to 25
the MSC. The BS then starts timer T
3230
. 26
b. Upon receipt of the SCCP Connection Request message, the MSC sends an SCCP 27
Connection Refused message to the BS. Upon receipt of this message, the BS stops 28
timer T
3230
. 29
TIA-2001.2-C
31 Section 3
If the user data field of the SCCP Connection Request message contains a Complete 1
Layer 3 Info message with a Location Updating Request application message, the MSC 2
shall respond with an SCCP Connection Refused message with a Location Updating 3
Accept or Location Updating Reject message in the user data field. 4
3.1.4.4.1.2 Establishment Procedure - Case 2 5
In this case, the connection establishment is initiated by the MSC as soon as the MSC 6
decides to perform an inter-BS handoff. 7
An SCCP Connection Request message is sent to the BS. The user data field of this 8
message may contain the BSMAP Handoff Request message (refer to [14]). If the layer 3 9
message is included, it shall be transferred in the user data field of the SCCP Connection 10
Request to complete the establishment of the relation between the radio channel 11
requested and the SCCP connection as soon as possible. The exact structure of the user 12
data field is explained in [14]. If the BS received the SCCP Connection Request message 13
without the Handoff Request message in the user data field, the BS establishes the SCCP 14
connection by sending an SCCP Connection Confirm message. In this case, the Handoff 15
Request and Handoff Request Ack messages are sent as DT1 messages after the SCCP 16
connection is established. 17
When a BS receives an SCCP Connection Request message that contains a Handoff 18
Request message in the user data field, the BS performs the necessary checking and 19
reserves, in the successful case, a radio channel for the requested handoff. If the BS fails 20
to reserve a radio channel, it may send an SCCP Connection Refuse message with a 21
Handoff Failure message in the user data field to the MSC. Otherwise, an SCCP 22
Connection Confirm message is returned to the MSC that may contain the BSMAP 23
Handoff Request Acknowledge message in the user data field. 24
The diagram in Figure 3.1.4.4.1.2-1 shows a successful SCCP connection establishment 25
procedure during handoff. 26
Time
a
b
BS MSC
SCCP Connection Confirm
SCCP Connection Request: Handoff Request
Comment
T3231
27
Figure 3.1.4.4.1.2-1 SCCP Connection Establishment During Handoff 28
a. The MSC sends an SCCP Connection Request message, including a user data field 29
that contains a Handoff Request application message, to the BS. The MSC starts 30
timer T
3231
3231
timer definition. 31
b. Upon receipt of the SCCP Connection Request message, the BS sends an SCCP 32
Connection Confirm message, which shall contain the Layer 3 application message 33
Handoff Request Acknowledge, to the MSC and establishes the connection. Upon 34
receipt of this message, the MSC stops timer T
3231
. 35
The diagram in Figure 3.1.4.4.1.2-2 shows an SCCP connection refusal during handoff. 36
TIA-2001.2-C
Section 3 32
Time
a
b
BS MSC
SCCP Connection Refused
Comment
SCCP Connection Request: Handoff Request
T3231
1
Figure 3.1.4.4.1.2-2 SCCP Connection Refusal During Handoff 2
a. The MSC sends an SCCP Connection Request message, including a user data field 3
that contains a Handoff Request application message, to the BS. The MSC starts 4
timer T
3231
. 5
b. Upon receipt of the SCCP Connection Request message, the BS sends an SCCP 6
Connection Refused message, which contains the Layer 3 application message 7
Handoff Failure, to the MSC. Upon receipt of this message, the MSC stops timer 8
T
3231
. 9
3.1.4.4.2 Connection Release 10
This procedure is normally initiated at the MSC side but in the case of abnormal SCCP 11
connection release (refer to 3.1.4.4.3), the BS may initiate connection clearing. 12
The MSC initiates this procedure with respect to the source BS in normal conditions for 13
all calls supported by A1 connections. 14
A connection is released when a given signaling connection is no longer required. This 15
may occur in normal cases: 16
at the end of a transaction (call, location updating); 17
after completion of a successful hard handoff: the connection with the source BS is 18
released. 19
When either the MSC or the BS sends an SCCP Released (RLSD) message, the user data 20
field is optional and may contain a transparent layer 3 message (e.g., DTAP) or be empty. 21
The structure of the user data field, if any, is explained in [14]. 22
When receiving this message, the BS releases or the MSC initiates release of all the radio 23
resources allocated to the relevant MS, if there are still any left, and returns an SCCP 24
Release Complete (RLC) message. 25
For abnormal cases a connection failure may be detected by the connection supervision 26
service provided by SCCP. If so, the Reset Circuit procedure described in [14] is used. 27
For other abnormal SCCP connection releases, refer to section 3.1.4.4.3, Abnormal 28
SCCP Release. 29
3.1.4.4.3 Abnormal SCCP Release 30
The normal release of SCCP A1 connections is initiated by the MSC. Under abnormal 31
conditions, an SCCP connection may be released by the BS to clear resources. 32
TIA-2001.2-C
33 Section 3
Whenever an SCCP connection is abnormally released, all resources associated with that 1
connection shall be cleared. Abnormal release can result from, for example, resource 2
failure, protocol error, or unexpected receipt of the SCCP RLSD or SCCP RLC 3
command. 4
3.1.4.4.3.1 SCCP Release by BS: Loss of SCCP Connection Information 5
Figure 3.1.4.4.3.1-1 demonstrates release of an SCCP connection by the BS due to loss of 6
SCCP connection information. Note that when a circuit(s) is associated with the call at 7
the MSC, Reset Circuit/Reset Circuit Ack [14] messages need to be exchanged between 8
the MSC and BS to guarantee release of the circuit by both the MSC and BS. 9

BS MSC
time comment
a
b
SCCP RLSD
c
d
SCCP RLC
Reset Circuit
T12
Reset Circuit Ack
Conditional
Conditional
10
Figure 3.1.4.4.3.1-1 BS Initiated SCCP Release: BS Lost SCCP Connection Information 11
a. An unexpected SCCP RLSD message (under abnormal termination) is received by 12
the MSC from the BS. 13
b. The MSC sends an SCCP RLC message to the BS to indicate that the SCCP RLSD 14
message has been received and that the appropriate procedures have been completed. 15
c. If a circuit was involved with the call at the MSC, the MSC sends a Reset Circuit 16
message to inform the BS that had sent the SCCP RLSD to clear its call data and 17
starts timer T
12
3231
timer definition. The Reset Circuit 18
message carries the Circuit Identity Code (CIC) of the trunk whose corrupted 19
connection was released. 20
d. The Reset Circuit Ack message informs the MSC that the Reset Circuit has been 21
received and acted upon. The MSC stops timer T
12
. 22
3.1.4.4.3.2 SCCP Release by MSC: Loss of SCCP Connection Information 23
Figure 3.1.4.4.3.2-1 demonstrates release of an SCCP connection by the MSC due to loss 24
of SCCP connection information. Note that when a circuit(s) is associated with the call at 25
the BS, Reset Circuit/Reset Circuit Ack messages [14] need to be exchanged between the 26
MSC and BS to guarantee release of the circuit by both the MSC and BS. 27
TIA-2001.2-C
Section 3 34

BS MSC
time comment
a
b
SCCP RLSD
c
d
SCCP RLC
Reset Circuit
T12
Reset Circuit Ack
Conditional
Conditional
1
Figure 3.1.4.4.3.2-1 MSC Initiated SCCP Release: MSC Lost SCCP Connection Information 2
a. An unexpected SCCP RLSD message (under abnormal termination) is received by 3
the BS from the MSC. 4
b. The BS sends an SCCP RLC message to the MSC to indicate that the SCCP RLSD 5
message has been received and that the appropriate procedures have been completed. 6
c. If a circuit was involved with the call at the BS, the BS sends a Reset Circuit 7
message to inform the MSC which had sent the SCCP RLSD to clear its call data and 8
starts timer T
12
. The Reset Circuit message carries the CIC of the trunk whose 9
corrupted connection was released. 10
d. The Reset Circuit Ack message informs the BS that the Reset Circuit has been 11
received and acted upon. The BS stops timer T
12
. 12
3.1.4.4.4 SCCP Reference Generation Philosophy 13
Referring to Figure 3.1.4.4.4-1 SLR/DLR Usage, the SCCP local reference number 14
(source/destination) is a three byte element internally chosen by the MSC or BS to 15
uniquely identify a signaling connection. In the direction MSC to BS, the source local 16
reference is chosen by the MSC and the destination local reference is chosen by the BS. 17
In the direction BS to MSC, the source local reference is chosen by the BS and the 18
destination local reference is chosen by the MSC. In the direction MSC to BS, the MSC 19
always echoes the BS Source Local Reference (SLR) in the Destination Local Reference 20
(DLR) field. In the direction BS to MSC, the BS always echoes the MSC SLR in the 21
DLR field. Note that it is the responsibility of the BS and MSC to insure that no two calls 22
have identical SCCP local reference numbers. 23
TIA-2001.2-C
35 Section 3
SLR (MSC), DLR (BS)
SLR (BS), DLR (MSC)
SLR = Source Local Reference
DLR = Destination Local Reference
MSC
BS
1
Figure 3.1.4.4.4-1 SLR/DLR Usage 2
MSC generation of SCCP local reference numbers shall conform to [24]. 3
3.1.4.4.5 SCCP Transfer of DTAP and BSMAP Messages 4
The DTAP and BSMAP messages on the A1 interface are contained in the user data field 5
of the exchanged SCCP frames. Table 3.1.4.4.5-1 below summarizes the use of the User 6
Data Field in SCCP frames. 7
Table 3.1.4.4.5-1 Use of the User Data Field in SCCP Frames 8
SCCP Frame User Data Field
(BSMAP/DTAP)
Connection Oriented Protocol Class 2
SCCP Connection Request (CR) Optional
SCCP Connection Confirm (CC) Optional
SCCP Connection Refused (CREF) Optional
SCCP Released (RLSD) Optional
SCCP Release Complete (RLC) Not Applicable
SCCP Data Transfer 1 (DT1) Mandatory
Connectionless Protocol Class 0
SCCP Unit Data (UDT) Mandatory
For connection oriented transactions, a connection is requested, obtained or refused using 9
the following SCCP messages (protocol class 2): 10
SCCP Connection Request (CR) 11
SCCP Connection Confirm (CC) 12
SCCP Connection Refused (CREF) 13
SCCP Released (RLSD) and SCCP Release Complete (RLC) messages are used to 14
break a connection. 15
The use of the User Data Field in SCCP frames in the various establishment and release 16
cases is described in section 3.1.4.4.1, Connection Establishment and section 3.1.4.4.2, 17
Connection Release. 18
TIA-2001.2-C
Section 3 36
For connection oriented (protocol class 2) transactions, once the signaling connection is 1
confirmed between the MSC and the BS, all A1 interface messages are transported in the 2
SCCP Data Transfer 1 (DT1) message until the connection is to be dropped. 3
For Connectionless (protocol class 0) transactions, where there is no SCCP connection, 4
A1 interface messages are transported in the SCCP Unit Data (UDT) message. 5
Table 3.1.4.4.5-2 below indicates which SCCP messages shall be used to transport each 6
of the application messages on the A1 interface. 7
8
Table 3.1.4.4.5-2 Use of SCCP for BSMAP and DTAP Messages

Application Message
Message
Discriminator
SCCP
Message
Call Processing Messages
Complete Layer 3 Information BSMAP CR
a

CM Service Request DTAP CR
a,b

Paging Request BSMAP UDT
a

Paging Response DTAP CR
a,b

CM Service Request
Continuation
DTAP DT1
c

Connect DTAP DT1
Progress DTAP DT1
Service Release DTAP DT1
Service Release Complete DTAP DT1
Assignment Request BSMAP CC
d
, DT1
Assignment Complete BSMAP DT1
Assignment Failure BSMAP DT1
Clear Request BSMAP DT1
Clear Command BSMAP DT1
Clear Complete BSMAP DT1
Alert With Information DTAP DT1
BS Service Request BSMAP UDT
BS Service Response BSMAP UDT
Additional Service Request DTAP DT1
Additional Service Notification BSMAP DT1
Supplementary Services Messages
Flash with Information DTAP DT1
Flash with Information Ack DTAP DT1
Feature Notification BSMAP UDT
a

Feature Notification Ack BSMAP UDT
a

Priority Access Channel BSMAP CC
d
, DT1
TIA-2001.2-C
37 Section 3

Application Message
Message
Discriminator
SCCP
Message
Assignment (PACA) Command
PACA Command Ack BSMAP DT1
PACA Update BSMAP UDT
PACA Update Ack BSMAP UDT
Radio Measurements for Position
Request
BSMAP DT1
Response
BSMAP DT1
Mobility Management Messages
Authentication Request DTAP/BSMAP DT1, UDT
e

Authentication Response DTAP/BSMAP DT1, UDT
e

SSD Update Request DTAP DT1
Base Station Challenge DTAP DT1
Base Station Challenge Response DTAP DT1
Status Request DTAP/BSMAP DT1, UDT
e

Status Response DTAP/BSMAP DT1, UDT
e

SSD Update Response DTAP DT1
Location Updating Request DTAP CR
a,b

Location Updating Accept DTAP CREF
Location Updating Reject DTAP CREF
Mobile Station Registered
Notification
BSMAP DT1
Parameter Update Request DTAP DT1
Parameter Update Confirm DTAP DT1
Privacy Mode Command BSMAP DT1
Privacy Mode Complete BSMAP DT1
Registration Request BSMAP UDT
User Zone Reject DTAP/BSMAP DT1, UDT
e

User Zone Update DTAP DT1
User Zone Update Request DTAP DT1
Handoff Messages
Handoff Required BSMAP DT1
Handoff Request BSMAP CR, DT1
h

Handoff Request Acknowledge BSMAP CC, DT1
f

Handoff Failure BSMAP DT1
f
, CREF
g

Handoff Command BSMAP DT1
Handoff Required Reject BSMAP DT1
TIA-2001.2-C
Section 3 38

Application Message
Message
Discriminator
SCCP
Message
Handoff Commenced BSMAP DT1
Handoff Complete BSMAP DT1
Handoff Performed BSMAP DT1
Facilities Management Messages
Block BSMAP UDT
Block Acknowledge BSMAP UDT
Unblock BSMAP UDT
Unblock Acknowledge BSMAP UDT
Reset BSMAP UDT
Reset Acknowledge BSMAP UDT
Reset Circuit BSMAP UDT
Reset Circuit Acknowledge BSMAP UDT
Service Redirection DTAP DT1, CREF
Transcoder Control Request BSMAP DT1
Transcoder Control
Acknowledge
BSMAP DT1
Application Data Delivery Service (ADDS) Messages
ADDS Page BSMAP UDT
ADDS Transfer BSMAP UDT
ADDS Deliver DTAP DT1
ADDS Page Ack BSMAP UDT
ADDS Deliver Ack DTAP DT1
ADDS Transfer Ack BSMAP UDT
Error Handling Messages
Rejection DTAP/BSMAP DT1, UDT
e

Following are the footnotes referred to in Table 3.1.4.4.5-2. 1
a. Required, SCCP DT1 is not an option. 2
b. Sent within Complete Layer 3 Information, which is a BSMAP message. 3
c. This message may be used in addition to the CM Service Request. 4
d. May be used if responding to a CM Service Request or Paging Response. 5
e. Used only when the procedure is done on a paging channel. 6
f. May be used after an SCCP connection has been established. 7
g. May be used if responding to an SCCP Connection Request/Handoff Request. 8
h This message is sent as DT1 if it is too large to fit into the User Data field of the 9
Connection Request. 10
TIA-2001.2-C
39 Section 3
3.2 A3 and A7 Interfaces 1
Two protocol stacks are defined for the A3 and A7 signaling interface, and two protocol 2
stacks are defined in this standard for the A3 user traffic interface. 3
As a mandatory requirement, the BS shall implement the ATM-based protocol stack. As 4
an option, the IP-based protocol stack may be implemented at the BS. 5
3.2.1 Performance Specifications 6
The following parameters shall be specified by the required performance specifications 7
on the A3/A7 interfaces: 8
ISD: This is composed of the cumulative queuing, transmission, and propagation 9
delays across the transport network between nodes supporting the A3/A7 interface. 10
ISD is specified as a statistical variable (e.g. 99.9
th
percentile) allowing for delay 11
variation (e.g. jitter). The delay budget for each hop in the transport network is not 12
specified but rather each deployment or implementation should be engineered to 13
meet the ISD using, for example, the link rate and technology at L1/L2. 14
ISL: This is the packet loss across the transport network between nodes supporting 15
the A3/A7 interface. ISL includes two components of packet loss in IP transport 16
networks, queue overflow and errors on the transmission media. An implementation 17
may choose to specify a packet loss rate that does not significantly impact the overall 18
performance of the system while enabling a practical physical layer transmission 19
network to be employed. 20
The performance of the A3/A7 interfaces has a significant impact on a subscribers 21
service quality. The RAN components supporting the fundamental channel (FCH), 22
dedicated control channel (DCCH), and supplemental channel (SCH), on the A3/A7 23
interface shall conform to the delay budget requirements in Table 3.2.1-1. 24
The delay between the source BS and target BS (channel element) includes the ISD and network entity 25
processing delays. The forward delay is the 99.9 percentile delay measured from the time the first bit of the 26
frame is transmitted from the source BS to the time the first bit of the frame is transmitted over the air 27
interface at the channel element for any soft handoff leg. The reverse delay is the 99.9 percentile delay 28
measured from the time the last bit of the frame is received on the air interface at the channel element of 29
any soft handoff leg to the time the last bit of the frame is received at the source BS. 30
Table 3.2.1-1 Delay Budget Requirements 31
Traffic type IOS BSC-BTS IOS BSC-BTS
w/Turbo coding
A3 ISD
IS-95/IS-2000
FCH/DCCH
forward
50 ms N/A 10 ms
IS-95/IS-2000
FCH/DCCH
reverse
60 ms N/A 10 ms
IS-2000 SCH
forward
55 ms 55 ms 15 ms
IS-2000 SCH
reverse
65 ms 75 ms 15 ms
TIA-2001.2-C
Section 3 40
3.2.1.1 Performance Specification for IP Protocol Stacks 1
If QoS is required (refer to section 2.4.4), the BSs on the A3/A7 interfaces shall employ 2
Diffserv [38] marking for traffic as per the classes in Table 3.2.1.1-1. The transport 3
network shall use this class information to meet the specified ISD and ISL on the 4
particular interface, as given in Table 3.2.1.1-1. 5
Table 3.2.1.1-1 A3/A7 Mapping Between Traffic Classes and Service-Level QoS 6
Traffic Classes Mandatory
Traffic Types
Optional Traffic
Types
99.9 %-tile
Interface
Service Delay
(includes
jitter)
Interface
Service Packet
Loss Rate
Class 1 FCH and DCCH
frame protocols
Very low latency
control and/or
signaling messages
10 ms 1.e-5
Class 2 SCH frame
protocol
Low latency control
and/or signaling
messages
15 ms 1.e-4
Class 3
a
None. Normal signaling
Messages
100 ms 1.e-4
Class 4
a
None. OAMP messages 2 sec 1.e-3
a. The ISD and ISL values for these classes are suggested values. 7
3.2.2 A3 User Traffic Transport Requirements 8
manufactures are shown in Figure 3.2.2-1. 10

Physical Layer
ATM
AAL2
SSSAR
User Traffic
Physical Layer
Link Layer
IP
UDP
User Traffic
a) ATM-Based Protocol Stack
(Mandatory)
b) IP-Based Protocol Stack
(Optional)
11
Figure 3.2.2-1 A3 User Traffic Protocol Stack 12
3.2.2.1 ATM-Based User Traffic Transport 13
The A3 user traffic interface, when implementing an ATM-based protocol stack, shall 14
contain the layers shown in a) of Figure 3.2.2-1. 15
TIA-2001.2-C
41 Section 3
3.2.2.1.1 Physical Layer (L1) Specification 1
The A3 user traffic interface shall use one of the L1 specifications in section 2.1. 2
3.2.2.1.2 Use of ATM 3
For this specification only ATM PVCs shall be required for the A3 user traffic interface. 4
These virtual circuits shall be configured through administrative procedures and no 5
special signaling interface procedures, e.g., ATM User Network Interface (UNI) [31], 6
shall be required. 7
3.2.2.1.3 Use of AAL2 8
When ATM is used to provide user traffic (voice/data) transport, the AAL2 protocol is 9
used. The procedures defined in [15] determine the allocation and use of the logical 10
channels, i.e., the connection identifiers (CIDs) that AAL2 provides over an ATM virtual 11
circuit. 12
Each BS has one or more ATM virtual circuits that connect it to other BSs (regardless of 13
whether switched or permanent virtual circuits are used). These virtual circuits are 14
comprised of one or more virtual circuits using AAL2 for the user traffic connections. 15
3.2.2.2 IP-Based User Traffic Transport 16
The A3 user traffic interface, when implementing an IP-based protocol stack, shall 17
contain the protocol layers shown in b) of Figure 3.2.2-1. 18
The requirements of this section shall apply to the transport layer for the A3 user traffic 19
frames. 20
3.2.2.2.1 Physical Layer (L1) Specification 21
The A3 user traffic interface shall use one of the L1 specifications in section 2.1. 22
3.2.2.2.2 Layer 2 Specification 23
The A3 user traffic L2 requirements as specified in section 2.2 shall apply for the 24
following areas: 25
Bandwidth efficiency 26
Delay/jitter control 27
Multiplexing 28
Compression 29
Segmentation and re-assembly (SAR) 30
Error detection 31
Addressing 32
3.2.2.2.3 Use of IP 33
The following requirements are valid for the IP network, when it is used for A3 user 34
traffic: 35
TIA-2001.2-C
Section 3 42
The A3 bearer transport topology options are specified in section 2.4.1. 1
The standard IP protocol, as defined in [33], shall be used for routing A3 user traffic. 2
The A3 bearer transport network addressing shall support a class-less IP addressing 3
scheme as specified in section 2.4.2.1. 4
The A3 bearer transport network routing requirements are specified in section 5
2.4.2.2. 6
The A3 bearer flow association guidelines are specified in section 2.4.2.3. Specific 7
flow association requirements for A3 bearer frames are as follows: 8
Every unidirectional soft handoff leg (i.e. logical A3 bearer path between a 9
Selector/Distribution Unit (SDU) frame selector and a BTS channel element) 10
shall be addressed via an IP address and a UDP port number. 11
Unique IP addresses and UDP port numbers may be assigned in the forward and 12
reverse directions. 13
The target side IP address and UDP port number pair shall uniquely identify a 14
connection. 15
3.2.2.2.4 Performance Specifications 16
The A3 bearer performance requirements are specified in sections 3.2.1. 17
The A3 bearer source BS-target BS (channel element) delay budget requirements are 18
specified in Table 3.2.1-1. 19
3.2.2.2.5 QoS Specifications 20
The A3 bearer QoS requirements are specified in sections 2.4.4 and 3.2.1.1. 21
The A3 bearer mapping between Traffic Classes and Service-Level QoS requirements are 22
specified in Table 3.2.1.1-1. 23
3.2.2.2.6 Security Specifications 24
The A3 bearer Security Framework requirements are specified in section 2.4.5. 25
3.2.3 A3/A7 Signaling Transport Requirements 26
The two signaling protocol stack options that are available to operators and 27
manufacturers for the A3 and A7 signaling interfaces include: 28
TIA-2001.2-C
43 Section 3
1
Physical Layer
ATM
AAL5
IP
TCP
IOS Application
Physical Layer
L2
IP
SCTP
IOS Application
a) ATM-Based Protocol Stack
(Mandatory)
b) L2-Independent Protocol Stack
(Optional)
2
Figure 3.2.3-1 A3 and A7 Signaling Protocol Stack 3
3.2.3.1 ATM-Based Signaling Protocol Stack 4
The A3/A7 Signaling interfaces, when using an ATM-based protocol stack, shall contain 5
the layers shown in a) of Figure 3.2.3-1. 6
3.2.3.1.1 Use of Physical Layer 7
The A3/A7 signaling interfaces shall use one of the specification defined in section 2.1. 8
3.2.3.1.2 Use of ATM 9
For this specification only ATM PVC shall be required for the A3 and A7 signaling 10
interfaces. These virtual circuits shall be configured through administrative procedures 11
and no special signaling interface procedures, e.g., ATM UNI [31], shall be required. 12
When ATM is used to provide signaling transport, the AAL5 protocol is employed. 13
Each BS has one or more ATM virtual circuits that connect it to other BSs (regardless of 14
whether switched or permanent virtual circuits are used). These virtual circuits are 15
comprised of one or more virtual circuits using the AAL5 protocol for signaling. 16
3.2.3.1.3 Use of AAL5 17
The AAL5 requirements are specified in section 2.3.1. 18
3.2.3.1.4 Use of IP 19
The IP requirements are specified in section 2.3.2. 20
TIA-2001.2-C
Section 3 44
3.2.3.1.5 Use of TCP 1
The standard TCP, as described in [34] and shown in section 2.5 shall be used on the A3 2
(signaling subchannel) and A7 interfaces. 3
All response messages associated with the handoff procedures shall be sent back to the 4
same TCP connection where the first A3 or A7 message initiating the procedure is 5
received. For example, the A3-Connect Ack (refer to [15]) message is sent back to the 6
same TCP connection from which the A3-Connect message is received. 7
Any A3 or A7 signaling link disconnection during a handoff procedure may result in a 8
failure of the handoff procedure. Optionally, a connection recovery may be performed for 9
continuation of the handoff procedures. If a connection recovery is performed, the same 10
active-passive TCP establishment procedure shall be used. 11
The following TCP port values are reserved for signaling across A7 interfaces: 12
A7: (BS-to-BS) 5602 This is the registered TCP port at a BS used for signaling 13
interconnection to another BS. 14
3.2.3.2 IP-Based Signaling Protocol Stack 15
The A3/A7 Signaling interfaces, when implementing the L2-independent protocol stack, 16
shall contain the layers shown in b) of Figure 3.2.3-1. 17
3.2.3.2.1 Use of Physical Layer 18
The A3/A7 signaling interface shall use one of the L1 specifications in section 2.1. 19
3.2.3.2.2 Layer 2 Specification 20
The A3/A7 signaling transport L2 requirements are specified in section 2.2 shall apply 21
for the following areas: 22
Bandwidth efficiency 23
Delay/jitter control 24
Multiplexing 25
Compression 26
Segmentation and re-assembly (SAR) 27
Error detection 28
Addressing 29
3.2.3.2.3 Use of IP 30
The following requirements are valid for the IP network, when used for A3/A7 signaling 31
transport: 32
The A3/A7 signaling transport topology options are described in section 2.4.1. 33
The standard IP protocol, as defined in [33], shall be used for routing A3/A7 34
signaling. 35
The A3/A7 signaling transport IP network shall support a class-less IP addressing 36
scheme as specified in section 2.4.2.1. 37
TIA-2001.2-C
45 Section 3
The A3/A7 signaling transport network routing requirements are specified in section 1
2.4.2.2. 2
The A3/A7 signaling transport flow association guidelines are specified in section 3
2.4.2.3. Specific flow association requirements for A3/A7 signaling are as follows: 4
Every logical signaling (i.e., BS) point defined in A3 or A7 interfaces that may 5
be a signaling source or target (e.g., BS source or target) shall be individually 6
addressable via an IP address and TCP or SCTP port number. 7
When using the SCTP-based protocol, messages associated with individual 8
traffic connections shall contain unique SCTP stream identifiers. 9
3.2.3.2.4 QoS Specifications 10
The A3/A7 signaling transport QoS requirements are specified in sections 2.4.4 and 11
3.2.1.1. 12
The A3/A7 signaling transport mapping between Traffic Classes and Service-Level QoS 13
requirements are specified in Table 3.2.1.1-1. 14
3.2.3.2.5 Security Specifications 15
The A3/A7 signaling transport security Framework requirements are specified in section 16
2.4.5. 17
3.2.3.2.6 Use of SCTP 18
SCTP provides a reliable message transport in IP networks. SCTP is used without any 19
modifications and is defined in [41]. 20
An SCTP connection between two endpoints is called an association. One SCTP 21
association can be considered as a logical aggregation of streams. A stream is a 22
unidirectional logical channel between two endpoints. To achieve bi-directional 23
communications, two streams are necessary, one in each direction. Each user message 24
(i.e., a message originated from the user application above SCTP) handled by SCTP has 25
to specify the stream to which it is attached. A stream identifier exists for each stream 26
within an association. Therefore, each SCTP stream can be considered as an independent 27
flow of user messages from one node to another. This stream independence characteristic 28
provides a mechanism to avoid and/or manage blocking between streams. 29
Between BSs (e.g., A3 and A7), one or several SCTP associations may exist. A BS may 30
select an SCTP association at creation of a user session context. However, it may not be 31
very efficient to consider each association as a signaling connection because typical 32
requirements of signaling application transport can be fulfilled by an SCTP stream pair. 33
Therefore, it should be assumed that one SCTP association is an aggregation of signaling 34
application connections. As such, each signaling application connection shall be mapped 35
to a pair of SCTP streams (one in downlink and one in uplink). The choice of stream 36
identifiers should be a function of the user application. One simple solution is to choose 37
the same stream identifier for each of the two streams comprising the connection. 38
SCTP port value 5604 is used for A7 signaling. 39
3.2.3.2.7 Use of TCP 40
Refer to section 3.2.3.1.5. 41
TIA-2001.2-C
Section 3 46
3.3 A8 and A9 Interfaces 1
The A8 and A9 interfaces are based on the use of IP. IP can operate across various 2
physical layer media. The specific layer 1 media and layer 2 link protocols to be used for 3
these interfaces are not specified in this standard. 4
Signaling over the A9 interface requires a reliable transport protocol and appropriate 5
signaling protocol stack option available to operators and manufacturers for the A9 7
interface is shown in Figure 3.3-1. 8

Physical Layer
Link Layer
IP
TCP/UDP
A9 Signaling
9
Figure 3.3-1 A9 Signaling Protocol Stack 10
manufacturers is shown in Figure 3.3-2. 12

Physical Layer
Link Layer
IP
GRE
13
Figure 3.3-2 A8 User Traffic Protocol Stack 14
TIA-2001.2-C
47 Section 3
3.3.1 Use of TCP 1
When TCP is used for transferring the A9 interface messages, the standard TCP, as 2
described in [34] and shown in section 2.5, shall be used. The following TCP port value 3
is reserved for signaling across the A9 interface: 4
A9: (BS-to-PCF) 5603 This is the registered TCP/UDP port at a BS used for 5
signaling interconnection to a PCF. 6
3.3.2 Use of UDP 7
When UDP is used for transferring the A9 interface messages, the standard UDP, as 8
described in [32], shall be used. 9
UDP Port value 5603 is reserved for signaling use on the A9 interface. The initiator 10
(BS) of an A9 link picks an available source UDP port, and sends an A9-Setup-A8 11
message (refer to [16]) to the destination (PCF) at port 5603. The PCF responds with an 12
A9-Connect-A8 message to the UDP port of the BS that initiated the A9-Setup-A8 13
message (refer to [16]). 14
3.3.3 Use of GRE 15
The BS shall set the Key field in the GRE header to the value in the Key field in the A8 16
Traffic ID element in the A9-Connect-A8 message received from the PCF indicating that 17
the PCF accepts the A8 connection. The PCF shall set the Key field in the GRE header to 18
the value in the Key field in the A8 Traffic ID element in the A9-Setup-A8 message 19
received from the BS requesting the establishment of the A8 connection. 20
3.4 A10 and A11 Interface 21
The A10 and A11 interfaces are based on the use of IP. IP can operate across various 22
physical layer media. The specific layer 1 media and layer 2 link protocols to be used for 23
these interfaces are not specified in this standard. 24
Mobile IP based messages are used for A11 interface call control signaling and for 25
passing accounting related and other information from the PCF to the PDSN (refer to [17] 26
for details). Each signaling exchange consists of a request message and a reply message. 27
When a message is sent by the PCF, the PCFs A11 IP address shall be used as the IP 28
Source Address and the PDSNs A11 IP shall be used as the IP Destination Address. 29
When a message is sent by the PDSN, the PDSNs A11 IP address shall be used as the IP 30
Source Address and the PCFs A11 IP address shall be used as the IP Destination 31
Address. Each message is transported within a UDP datagram. The initiator of the request 32
message shall pick an available UDP source port, and set the UDP destination port to 699 33
in the request message it sends to the selected receiver. In the reply message it sends to 34
the initiator, the receiver shall pick an available UDP source port (it can use the UDP 35
destination port in the request message) and set the UDP destination port to the UDP 36
source port in the request message. 37
Signaling over the A11 interface requires a reliable transport protocol and appropriate 38
signaling protocol stack option available to operators and manufacturers for the A11 40
interface is shown in Figure 3.4-1. 41
TIA-2001.2-C
Section 3 48
1

Physical Layer
Link Layer
IP
UDP
A11 Signaling
2
Figure 3.4-1 A11 Signaling Protocol Stack 3
The protocol stack option for transport of user traffic that are available to operators and 4
manufacturers is shown in Figure 3.4-2. 5

Physical Layer
Link Layer
IP
GRE
6
Figure 3.4-2 A10 User Traffic Protocol Stack 7
3.4.1 Use of UDP 8
The use of UDP over the A11 interface conforms to the use of UDP for Mobile IP, as 9
specified in [36] with the exception of the UDP port number. 10
3.4.2 Use of GRE 11
The PCF shall set the Key field in the GRE header to value in the Key field in the Session 12
Specific Extension in the A11-Registration Reply message received from the PDSN 13
indicating that the PDSN accepts the A10 connection. The PDSN shall set the Key field 14
in the GRE header to the value in the Key field in the Session Specific Extension in the 15
A11-Registration Request message received from the PCF requesting the establishment 16
of the A10 connection. 17
TIA-2001.3-C

1
2
3
4
5
Access Network Interfaces Part 3 Features 6

TIA-2001.3-C

1
3

TIA-2001.3-C

i

Table of Contents 1
2
3
1.0 Introduction ........................................................................................................................................ 1 4
1.1 Overview........................................................................................................................................ 1 5
1.1.1 Purpose ................................................................................................................................... 6 6
1.1.2 Scope ...................................................................................................................................... 6 7
1.2 References ...................................................................................................................................... 6 8
1.2.1 TIA / EIA................................................................................................................................ 6 9
1.2.2 3GPP2..................................................................................................................................... 7 10
1.2.3 International Telecommunications Union Telecommunications Sector (ITU-T) ................ 9 11
1.2.4 Other ....................................................................................................................................... 9 12
1.3 Terminology ................................................................................................................................. 10 13
1.3.1 Acronyms.............................................................................................................................. 10 14
1.3.2 Definitions ............................................................................................................................ 12 15
1.4 Call Processing and Supplementary Services Assumptions ......................................................... 13 16
1.4.1 Call Control .......................................................................................................................... 13 17
1.4.1.1 A2/A5 Terrestrial Circuit Allocation................................................................................ 13 18
1.4.1.2 Radio Channel Allocation................................................................................................. 13 19
1.4.1.3 Traffic Channel Release.................................................................................................... 13 20
1.4.1.4 A3 User Traffic Subchannel Allocation ........................................................................... 13 21
1.5 Radio Resource Management Assumptions ................................................................................. 14 22
1.5.1 Radio Channel Supervision .................................................................................................. 14 23
1.5.1.1 Traffic Channel Radio Link Supervision.......................................................................... 14 24
1.5.1.2 Idle Channel Observation ................................................................................................. 14 25
1.5.2 Radio Channel Management................................................................................................. 14 26
1.5.2.1 Radio Channel Configuration Management ..................................................................... 14 27
1.5.2.2 Radio Traffic Channel Management................................................................................. 14 28
1.5.2.2.1 Radio Channel Allocation.......................................................................................... 14 29
1.5.2.2.2 Radio Traffic Channel Release .................................................................................. 14 30
1.5.2.2.3 Radio Traffic Channel Power Control ....................................................................... 14 31
1.5.2.2.4 Channel Encoding and Decoding............................................................................... 14 32
2.0 Feature Descriptions......................................................................................................................... 15 33
2.1 Call Setup of Voice and Circuit Data Calls .................................................................................. 15 34
2.2 Call Clearing of Voice and Circuit Data Calls ............................................................................. 15 35
2.2.1 Call Clearing Initiated by the MS or BS............................................................................... 15 36
2.2.2 Call Clearing Initiated by the MSC ...................................................................................... 16 37
2.3 TFO Support................................................................................................................................. 16 38
2.4 Test Calls...................................................................................................................................... 17 39
2.5 Support of DTMF......................................................................................................................... 17 40
2.6 Support of Supplementary Services ............................................................................................. 18 41
2.6.1 Feature Activation and Deactivation .................................................................................... 18 42
2.6.2 Call Waiting.......................................................................................................................... 18 43
2.6.3 Three Way Calling................................................................................................................ 19 44
2.6.4 Message Waiting Notification .............................................................................................. 19 45
2.6.5 Call Barring .......................................................................................................................... 20 46
2.6.6 Calling Number ID Presentation / Restriction ...................................................................... 20 47
2.6.6.1 CNIR for Mobile Originated Calls ................................................................................... 20 48
2.6.6.2 CNIP/CNIR for Mobile Terminated Calls........................................................................ 20 49
2.6.7 Distinctive Ringing............................................................................................................... 21 50
2.6.8 Answer Holding.................................................................................................................... 21 51
2.6.9 User Selective Call Forwarding............................................................................................ 21 52
2.7 Mobile Registration...................................................................................................................... 22 53
2.8 Global Emergency Call Origination............................................................................................. 22 54
2.9 E911 Phase 1 and Phase 2 ............................................................................................................ 22 55
TIA-2001.3-C

ii
2.10 Short Message Service ................................................................................................................. 23 1
2.11 Priority Access and Channel Assignment (PACA) ...................................................................... 23 2
2.12 Over-The-Air Service Provisioning (OTASP) and Over The Air Parameter Administration 3
(OTAPA) ...................................................................................................................................... 24 4
2.12.1 OTASP Support .................................................................................................................... 24 5
2.12.2 OTAPA Support ................................................................................................................... 25 6
2.13 Mobile Position Determination .................................................................................................... 25 7
2.13.1 Support of Position Location Service (MS PDE Approach).............................................. 25 8
2.13.2 Software Calculation Position Determination (BS-MSC Approach).................................... 25 9
2.14 User Zone ..................................................................................................................................... 26 10
2.15 ISDN Interworking....................................................................................................................... 26 11
2.16 Circuit Data Calls ......................................................................................................................... 26 12
2.17 3G Packet Data Calls.................................................................................................................... 27 13
2.17.1 Packet Data Assumptions ..................................................................................................... 28 14
2.17.2 Previous and Current Access Network Identifiers (PANID/CANID)................................... 29 15
2.17.3 PDSN Selection Algorithm................................................................................................... 30 16
2.17.4 A8/A9 Interface Descriptions ............................................................................................... 30 17
2.17.5 A10/A11 Interface Descriptions ........................................................................................... 30 18
2.17.6 Version Interoperability Control........................................................................................... 30 19
2.17.7 Short Data Bursts.................................................................................................................. 31 20
2.17.8 Common Channel Packet Data (CCPD) ............................................................................... 31 21
2.17.9 Packet Data Security Considerations .................................................................................... 32 22
2.17.10 Support for AAA-Based Radio Network Packet Data Inactivity Timer (RN-PDIT)............ 32 23
2.17.11 Support for Always-on Mobile Stations ............................................................................... 32 24
2.18 Concurrent Services (Circuit Voice and Packet Data).................................................................. 33 25
2.19 Handoff......................................................................................................................................... 33 26
2.19.1 Handoff via MSC.................................................................................................................. 33 27
2.19.2 Handoff via Direct BS-to-BS Signaling................................................................................ 33 28
2.19.3 Inter-BS Hard Handoff into Intra-BS Soft Handoff.............................................................. 34 29
2.19.4 Fast Handoff ......................................................................................................................... 34 30
2.19.5 Intergeneration Packet Data Handoff.................................................................................... 38 31
2.19.6 Alternate Dormant Handoff .................................................................................................. 38 32
2.20 Security Features .......................................................................................................................... 39 33
2.20.1 Terminal Authentication....................................................................................................... 39 34
2.20.2 Signaling Message Encryption ............................................................................................. 40 35
2.20.3 Voice/Data Privacy............................................................................................................... 40 36
2.21 Flex Rate ...................................................................................................................................... 41 37
2.22 Status Inquiry ............................................................................................................................... 41 38
2.23 3X Multi-Carrier Operation.......................................................................................................... 41 39
2.24 5 ms Messaging............................................................................................................................ 41 40
2.25 Enhanced Rate Adaptation Mode (ERAM) .................................................................................. 42 41
2.26 Code Combining Soft Handoff (CCSH)....................................................................................... 42 42
2.27 Rescue Channel ............................................................................................................................ 42 43
2.28 Terrestrial Circuit Management.................................................................................................... 43 44
2.28.1 Terrestrial Circuit Management for the A2/A5 Interface...................................................... 43 45
2.28.2 Terrestrial Circuit Management for the A3 Interface ........................................................... 43 46
2.29 Vocoder Support........................................................................................................................... 43 47
2.30 Reverse FCH Gating..................................................................................................................... 44 48
2.31 Voice-over-IP (VoIP) ................................................................................................................... 44 49
2.31.1 Voice over IP Handoff Considerations ................................................................................. 45 50
2.32 Network Directed System Selection (NDSS) ............................................................................... 45 51
2.33 Features Supported Transparently in this Standard ...................................................................... 45 52
2.33.1 Emergency Service (Basic) via Specific Dialed Number ..................................................... 45 53
2.33.2 Carrier Access....................................................................................................................... 46 54
2.33.3 Call Forwarding.................................................................................................................... 46 55
2.33.3.1 Call Forwarding Unconditional ........................................................................................ 46 56
TIA-2001.3-C

iii

2.33.3.2 Call Forwarding When Busy ............................................................................................ 46 1
2.33.3.3 Call Forwarding - No Answer .......................................................................................... 46 2
2.33.3.4 Call Forward Default ........................................................................................................ 47 3
2.33.4 Call Delivery......................................................................................................................... 47 4
2.33.5 Advice of Charge.................................................................................................................. 47 5
2.33.6 Call Transfer ......................................................................................................................... 47 6
2.33.7 Lawfully Authorized Wiretap............................................................................................... 48 7
2.33.8 Access Control by Call Type (ACCT).................................................................................. 48 8
3.0 Feature Call Flows............................................................................................................................ 49 9
3.1 Call Setup of Voice and Circuit Data Calls .................................................................................. 49 10
3.1.1 Mobile Origination Examples............................................................................................... 49 11
3.1.1.1 Mobile Origination ........................................................................................................... 49 12
3.1.1.2 Mobile Origination with Access Probe Handoff, Access Handoff and Channel 13
Assignment into Soft/Softer Handoff ............................................................................... 52 14
3.1.1.3 Mobile Origination Failure Call Clearing with Local Tone Generation........................ 56 15
3.1.2 Mobile Termination Examples ............................................................................................. 57 16
3.1.2.1 Mobile Termination.......................................................................................................... 58 17
3.1.2.2 Mobile Termination, Assignment Retry ........................................................................... 60 18
3.2 Call Clearing of Voice and Circuit Data Calls ............................................................................. 62 19
3.2.1 Call Clearing Initiated by the MS or BS............................................................................... 62 20
3.2.2 Call Clearing Initiated by the MSC ...................................................................................... 63 21
3.2.2.1 Clear from the Network .................................................................................................... 63 22
3.2.2.2 Call Clearing when Tones/Announcements are Provided ................................................ 63 23
3.2.3 Call Clearing Collision ......................................................................................................... 63 24
3.2.4 Call Flows for Call Clear Operation ..................................................................................... 64 25
3.2.4.1 Call Clear via Clear Request (MS Initiated) ..................................................................... 64 26
3.2.4.2 Call Clear via Clear Request (BS Initiated) ...................................................................... 65 27
3.2.4.3 Call Clear via Clear Command......................................................................................... 65 28
3.3 TFO Support................................................................................................................................. 66 29
3.3.1 Call Flows for Transcoder Control ....................................................................................... 66 30
3.4 Test Calls...................................................................................................................................... 67 31
3.5 Support of DTMF......................................................................................................................... 67 32
3.6 Support of Supplementary Services ............................................................................................. 67 33
3.6.1 Feature Activation and Deactivation .................................................................................... 67 34
3.6.1.1 Feature Activation/Deactivation in Idle Mode.................................................................. 67 35
3.6.1.2 Feature Activation/Deactivation While in a Call .............................................................. 67 36
3.6.2 Call Waiting.......................................................................................................................... 68 37
3.6.3 Three Way Calling................................................................................................................ 69 38
3.6.3.1 Three-Way Calling (Method 1) ..................................................................................... 69 39
3.6.3.2 Three-Way Calling - (Method 2) ...................................................................................... 70 40
3.6.4 Message Waiting Notification .............................................................................................. 71 41
3.6.4.1 Message Waiting Notification on the Paging Channel ..................................................... 71 42
3.6.4.2 Message Waiting Notification on the Traffic Channel ..................................................... 71 43
3.6.5 Call Barring .......................................................................................................................... 72 44
3.6.5.1 Call Barring Incoming ...................................................................................................... 72 45
3.6.5.2 Call Barring Outgoing ...................................................................................................... 72 46
3.6.6 Calling Number ID Presentation/Restriction ........................................................................ 73 47
3.6.7 Distinctive Ringing............................................................................................................... 73 48
3.6.8 Answer Holding.................................................................................................................... 73 49
3.6.8.1 Answer Holding of a Mobile Terminated Call ................................................................. 73 50
3.6.8.2 Answer Holding of Call Waiting ...................................................................................... 74 51
3.6.9 User Selective Call Forwarding............................................................................................ 75 52
3.6.9.1 User Selective Call Forwarding of a Mobile Terminated Call.......................................... 75 53
3.6.9.2 User Selective Call Forwarding of Call Waiting .............................................................. 75 54
3.7 Mobile Registration...................................................................................................................... 76 55
3.7.1 Mobile Initiated Location Registration................................................................................. 77 56
TIA-2001.3-C

iv
3.7.2 Power Down Registration at the End of a Call ..................................................................... 77 1
3.7.3 Network Initiated Location Registration .............................................................................. 77 2
3.7.4 Mobile Station Registered Notification ................................................................................ 78 3
3.8 Global Emergency Call Origination............................................................................................. 79 4
3.9 E911 Phase I and Phase 2............................................................................................................. 79 5
3.10 Short Message Service ................................................................................................................. 79 6
3.10.1 SMS Feature Description...................................................................................................... 79 7
3.10.1.1 SMS - Mobile Originated Point-to-Point .......................................................................... 79 8
3.10.1.2 SMS - Mobile Terminated Point-to-Point......................................................................... 80 9
3.10.1.3 SMS - Broadcast ............................................................................................................... 80 10
3.10.2 SMS Delivery on a Common Channel.................................................................................. 80 11
3.10.2.1 SMS Broadcast Delivery over a Common Channel.......................................................... 81 12
3.10.2.2 SMS Receipt from an MS on the Access Channel............................................................ 81 13
3.10.2.3 SMS Delivery to an MS on a Common Channel - Example 1.......................................... 82 14
3.10.2.4 SMS Delivery to an MS on a Common Channel - Example 2 (without Early Traffic 15
Channel Assignment)........................................................................................................ 82 16
3.10.2.5 SMS Delivery to an MS on a Common Channel - Example 3 (with Early Traffic Channel 17
Assignment)...................................................................................................................... 84 18
3.10.2.6 SMS Delivery to an MS on a Common Channel - Example 4 using Registration 19
Procedures ........................................................................................................................ 85 20
3.10.3 SMS Delivery on the Traffic Channel .................................................................................. 87 21
3.10.3.1 SMS Delivery to an MS on a Traffic Channel .................................................................. 87 22
3.10.3.2 SMS Receipt from an MS on a Traffic Channel ............................................................... 88 23
3.11 Priority Access and Channel Assignment (PACA) ...................................................................... 88 24
3.11.1 Mobile Origination with PACA Service............................................................................... 89 25
3.11.1.1 Mobile Origination with PACA Service Radio Resources not Available...................... 89 26
3.11.1.2 Mobile Origination, Idle Handoff with PACA Active...................................................... 90 27
3.11.1.3 Mobile Origination with PACA Active, Consecutive PACA Calls.................................. 91 28
3.11.2 PACA Call Cancellation Initiated by the MS....................................................................... 92 29
3.11.3 PACA Call Cancellation Initiated by Either MSC or BS ..................................................... 92 30
3.12 Over-The-Air Service Provisioning (OTASP) and Over The Air Parameter Administration 31
(OTAPA) ...................................................................................................................................... 93 32
3.12.1 OTASP Support .................................................................................................................... 93 33
3.12.1.1 OTASP Call Setup............................................................................................................ 94 34
3.12.1.2 OTASP Data Exchanges................................................................................................... 94 35
3.12.1.3 SSD Update Procedure ..................................................................................................... 94 36
3.12.1.4 Privacy Mode Procedure................................................................................................... 94 37
3.12.1.5 Rejection........................................................................................................................... 94 38
3.12.1.6 OTASP Call Clear ............................................................................................................ 94 39
3.12.1.7 OTASP Call Flow............................................................................................................. 94 40
3.12.2 OTAPA Support ................................................................................................................... 96 41
3.13 Mobile Position Determination .................................................................................................... 96 42
3.13.1 Call Flows for Position Location Service (MS-PDE) ........................................................... 97 43
3.13.1.1 Mobile Originated Position Location Service on the Traffic Channel.............................. 97 44
3.13.1.2 Mobile Terminated Position Location Service on the Traffic Channel ............................ 99 45
3.13.1.3 Position Location Service over Common Channels Mobile Terminated..................... 101 46
3.13.1.4 Position Location Service over Common Channels Mobile Originated ...................... 102 47
3.13.2 Call Flows for Software Calculation Position Determination (BS-MSC) .......................... 103 48
3.14 User Zone ................................................................................................................................... 104 49
3.14.1 Invoking User Zone at Registration.................................................................................... 105 50
3.14.2 Use of User Zones During Call Setup................................................................................. 106 51
3.14.3 Changing User Zone During a Call (Mobile initiated) ....................................................... 107 52
3.14.4 Changing User Zone During a Call (Network initiated) ..................................................... 107 53
3.15 ISDN Interworking Service........................................................................................................ 108 54
3.16 Circuit Data Calls ....................................................................................................................... 108 55
3.17 3G Packet Data Calls.................................................................................................................. 109 56
TIA-2001.3-C

v

3.17.1 Data Ready to Send (DRS) Indicator.................................................................................. 109 1
3.17.2 Previous and Current Access Network Identifiers (PANID/CANID)................................. 109 2
3.17.3 PDSN Selection Algorithm................................................................................................. 111 3
3.17.4 A8/A9 Interface Call Flows................................................................................................ 112 4
3.17.4.1 MS Initiated Packet Data Service Instance Setup........................................................... 112 5
3.17.4.1.1 MS Initiated PDSI Setup - Packet Data Session is Dormant or Inactive ................. 112 6
3.17.4.1.2 Mobile Initiated Setup of a Packet Data Service Instance when the Packet Data 7
Session Already Is Active Successful Operation ................................................... 114 8
3.17.4.2 BS Initiated Packet Data Service Instance Release to Dormant State ............................ 115 9
3.17.4.2.1 BS Initiated Packet Data Service Instance Release to Dormant State when no other 10
packet data service instance is active....................................................................... 116 11
3.17.4.2.2 BS Initiated Packet Data Service Instance Release to Dormant State When Other 12
Packet Data Service Instances Are Active ............................................................... 117 13
3.17.4.3 MS Initiated Packet Data Service Instance Release to Dormant State............................ 118 14
3.17.4.3.1 MS Initiated Packet Data Service Instance Release to Dormant State when no other 15
Packet Data Service Instance is Active.................................................................... 118 16
3.17.4.3.2 MS Initiated Packet Data Service Instance Release to Dormant State when other 17
Packet Data Service Instances are Active ................................................................ 120 18
3.17.4.4 Active MS Power Down................................................................................................. 121 19
3.17.4.5 PDSN Initiated Packet Data Service Instance Release to Inactive/Null State ................ 122 20
3.17.4.5.1 PDSN Initiated Release of a Dormant Packet Data Service Instance ...................... 122 21
3.17.4.5.2 PDSN Initiated Release of an Active Packet Data Service Instance Packet Data 22
Session Remains Active........................................................................................... 123 23
Session Becomes Dormant or Inactive .................................................................... 124 25
3.17.4.6 MS Initiated Packet Data Service Instance Re-Activation from Dormant State (intra-PCF) 26
125 27
3.17.4.7 Network Initiated PDSI Re-Activation from Dormant State .......................................... 125 28
3.17.4.7.1 Network Initiated Packet Data Service Instance Reactivation when the Packet Data 29
Session is Dormant .................................................................................................. 126 30
3.17.4.7.2 Network Initiated Packet Data Service Instance Reactivation when the Packet Data 31
Session is Active...................................................................................................... 128 32
3.17.4.8 Mobile Terminated Packet Data Rejection During a Voice Call .................................... 129 33
3.17.4.9 Dormant Handoff (Inter-BS/Inter-PCF) - Mobile Served by Same PDSN..................... 129 34
3.17.4.9.1 Intra-PDSN Dormant Handoff of a PDSI, While the Packet Data Session is Dormant 35
130 36
3.17.4.9.2 Intra-PDSN Dormant Handoff, while the Packet Data Session is Active................ 132 37
3.17.4.10 Dormant Handoff of a PDSI (Inter-BS/Inter-PCF) - Mobile Served by a Different PDSN 38
134 39
3.17.4.11 Dormant Handoff of a PDSI (Inter-BS/Inter-PCF), Packet Data Session is Dormant - 40
Mobile Served by Same PDSN, Failed Authentication in MSC Following Session 41
Establishment (PDSN Has Data to Send) ....................................................................... 136 42
3.17.4.12 Dormant Handoff of a PDSI (Inter-BS/Inter-PCF) -. Mobile Served by Same PDSN, 43
Failed Authentication in MSC Following Session Establishment (PDSN Does Not Have 44
Data to Send) .................................................................................................................. 138 45
3.17.4.13 Soft / Softer Handoff Packet Data .................................................................................. 140 46
3.17.4.14 Inter-BS Hard Handoff (Within the Same PCF) ............................................................. 140 47
3.17.4.15 Inter-PCF Hard Handoff (Within Same PDSN) ............................................................. 143 48
3.17.4.16 Inter-PCF Hard Handoff (Within Same PDSN) With Return On Failure....................... 146 49
3.17.4.17 MS Initiated Call Release to Null State .......................................................................... 149 50
3.17.4.17.1 MS Initiated Packet Data Service Instance Release to the Inactive/Null State when no 51
other Packet Data Service Instance is Active........................................................... 149 52
3.17.4.17.2 MS Initiated Packet Data Service Instance Release to the Inactive/Null State 53
when other Packet Data Service Instance(s) are Active........................................... 151 54
3.17.4.18 Dormant MS Power Down, A10 Release Initiated by the MSC/BS............................... 152 55
TIA-2001.3-C

vi
3.17.4.19 Mobile Initiated Initial Packet Data Service Instance Setup Successful Operation with 1
Delayed Accounting Information ................................................................................... 153 2
3.17.4.20 Accounting Parameters Update Event Procedure ........................................................... 155 3
3.17.4.21 Packet Data Session Clearing MSC Initiated............................................................... 156 4
3.17.4.22 MS Initiated Reactivation from Dormant State; MS not Registered with New PDSN... 158 5
3.17.5 A10/A11 Interface Call Flows............................................................................................ 160 6
3.17.5.1 Mobile Originated Packet Data Service Instance Setup Successful Operation............ 161 7
3.17.5.1.1 Mobile Initiated Setup of a Service Instance when the Packet Data Session Is 8
Dormant or Inactive Successful Operation ........................................................... 162 9
3.17.5.1.2 Mobile Initiated Setup of a Service Instance when the Packet Data Session Is Active 10
Successful Operation ............................................................................................ 164 11
3.17.5.2 Mobile Originated Packet Data Service Instance Setup Failure Operation ................. 165 12
3.17.5.3 Mobile Originated Packet Call Setup With Registration to Alternate PDSN.............. 167 13
3.17.5.4 Packet Data Service Instance Clearing PDSN Initiated............................................... 169 14
3.17.5.5 Packet Data Session Clearing MSC Initiated............................................................... 171 15
3.17.5.6 Packet Data Service Session Clearing MS Initiated .................................................... 172 16
3.17.5.7 Packet Data Service Instance Clearing PDSN Initiated (Crossing A11-Registration 17
Request and A11-Registration Update) .......................................................................... 172 18
3.17.5.8 Inter-PCF Dormant Handoff Mobile Continues to be Served by the Same PDSN...... 174 19
3.17.5.9 Inter-PCF Dormant Handoff Mobile Served by a Different PDSN............................. 178 20
3.17.5.10 Inter-PCF Hard Handoff Mobile Continues to be Served by the Same PDSN............ 180 21
3.17.5.11 Inter-BS Hard Handoff Mobile Served by a New Target PDSN................................. 184 22
3.17.5.12 Accounting Update Due to Parameter Changes.............................................................. 189 23
3.17.5.13 MS Initiated Reactivation from Dormant State; MS not Registered with New PDSN... 189 24
3.17.6 Version Interoperability Control......................................................................................... 191 25
3.17.6.1 Example of a Successful BS initiated A9 Version Control Procedure............................ 191 26
3.17.6.2 Example of a Successful PCF Initiated A9 Version Control Procedure ......................... 192 27
3.17.7 Support of Short Data Bursts .............................................................................................. 192 28
3.17.7.1 Mobile Originated Short Data Burst Call Flows............................................................. 192 29
3.17.7.2 Mobile Terminated Short Data Burst Call Flows ........................................................... 194 30
3.17.7.2.1 Short Data Delivery from the PDSN to the MS....................................................... 194 31
3.17.7.2.2 Short Data Delivery from the PDSN BS Refuses SDB Request........................... 196 32
3.17.8 Support for Common Channel Packet Data (CCPD).......................................................... 198 33
3.17.8.1 Mobile Originated CCPD Mode Packet Data Call Setup Request.................................. 198 34
3.17.8.2 Mobile Terminated Packet Data for CCPD.................................................................... 201 35
3.17.8.3 CCPD Mode Packet Data Handoffs................................................................................ 201 36
3.17.8.3.1 CCPD MS Handoff - Mobile Served by the Same PDSN ....................................... 202 37
3.17.8.3.2 Dormant Handoff of a CCPD Mobile: Mobile Served by a New PDSN................. 204 38
3.17.9 Packet Data Security Considerations .................................................................................. 206 39
3.17.10 Support for PDSN Initiated Packet Data Session Updates ................................................. 207 40
3.18 Voice and Packet Concurrent Service ........................................................................................ 208 41
3.18.1 Concurrent Service Examples - Mobile Origination........................................................... 208 42
3.18.1.1 Mobile Initiated Packet Data Service Connection, Packet Data Session is Null or 43
Dormant, Voice Service is Already Active..................................................................... 208 44
3.18.1.2 Mobile Initiated Voice Service Connection, Packet Data Session is Already Active..... 210 45
3.18.1.3 Mobile Initiated Packet Data Service Connection, Packet Data Session is Already Active, 46
Voice Service is Already Active..................................................................................... 211 47
3.18.1.4 Mobile Initiated Voice Service Connection, Packet Data Session is Dormant ............... 211 48
3.18.2 Concurrent Service Examples - Mobile Termination ......................................................... 211 49
3.18.3 Concurrent Service Examples - BS Initiated Packet Data Service Instance Re-Activation 213 50
3.18.3.1 Network Initiated PDSI Re-Activation from Dormant State, MS is Already Active with 51
Voice Service, Packet Data Session is Dormant ............................................................. 213 52
3.18.3.2 Network Initiated PDSI Re-Activation from Dormant State, MS is Active with a 53
Concurrent Voice Service (and Dormant Packet Data Session) and has Performed an 54
Inter-BS/Intra-PCF Voice Call Handoff ......................................................................... 215 55
TIA-2001.3-C

vii

3.18.3.3 Network Initiated Service Instance Reactivation When There is Another Active Packet 1
Data Service Instance and MS is Already Active with a Voice Service......................... 217 2
3.18.4 Concurrent Services: Call Clearing Examples.................................................................... 217 3
3.18.4.1 Call Clear via Service Release MS Initiated................................................................ 217 4
3.18.4.2 Call Clear via Service Release - MSC Initiated.............................................................. 218 5
3.18.4.3 PDSN Initiated Service Instance Release, Voice Service is Active................................ 220 6
3.18.4.3.1 PDSN Initiated Release of Last Active Packet Data Service Instance, Voice Service is 7
Active....................................................................................................................... 220 8
3.18.4.4 BS Initiated Release to Dormant State of a Packet Data Service Instance, Voice Service is 9
Active.............................................................................................................................. 221 10
3.18.4.4.1 BS Initiated Release to Dormant State of Last Active Packet Data Service Instance, 11
Circuit Voice Service is Active................................................................................ 221 12
3.18.5 Concurrent Service - Handoff............................................................................................. 223 13
3.18.5.1 Concurrent Service (Active Voice and Packet Data Services) - Hard Handoff .............. 223 14
3.18.5.1.1 Successful Inter-BS Hard Handoff Call Flows (Within the Same PCF).................. 223 15
3.18.5.1.2 Successful Inter-PCF Hard Handoff Call Flows (Mobile Served by the Same PDSN) 16
223 17
3.18.5.1.3 Successful Inter-PCF Hard Handoff Call Flows (Mobile Served by New PDSN) .. 223 18
3.18.5.2 Concurrent Service (Active Voice and Dormant Packet Data Services) - Handoff........ 223 19
3.18.5.2.1 Successful Inter-PCF Handoff Call Flows (Mobile Served by the Same PDSN) .... 223 20
3.18.5.2.2 Successful Inter-PCF Handoff Call Flow (Mobile Served by New PDSN)............. 226 21
3.18.5.3 Concurrent Service - Soft / Softer Handoff .................................................................... 228 22
3.19 Handoff....................................................................................................................................... 229 23
3.19.1 Handoff via MSC................................................................................................................ 229 24
3.19.1.1 Introduction .................................................................................................................... 229 25
3.19.1.1.1 Recognition That a Handoff is Required by a BS.................................................... 229 26
3.19.1.1.2 Recognition That a Handoff is Required by the MSC............................................. 229 27
3.19.1.1.3 Concept of Designated Cell.................................................................................. 229 28
3.19.1.2 Inter-BS Hard Handoff ................................................................................................... 230 29
3.19.1.2.1 Triggering Phase ...................................................................................................... 230 30
3.19.1.2.2 Target Determination Phase..................................................................................... 230 31
3.19.1.2.3 Resource Establishment ........................................................................................... 230 32
3.19.1.2.4 Execution Phase....................................................................................................... 230 33
3.19.1.3 Call Clearing................................................................................................................... 231 34
3.19.1.4 Handoff Failure Handling............................................................................................... 231 35
3.19.1.5 Intra-BS Handoff ............................................................................................................ 231 36
3.19.2 Handoff via Direct BS-to-BS Signaling.............................................................................. 231 37
3.19.2.1 A3 Interface Messages.................................................................................................... 231 38
3.19.2.2 A7 Interface Messages.................................................................................................... 232 39
3.19.2.3 Soft/Softer Handoff Addition ......................................................................................... 233 40
3.19.2.4 Soft/Softer Handoff Removal ......................................................................................... 233 41
3.19.2.5 Cell Removal by a Target BS ......................................................................................... 233 42
3.19.2.6 Call Clearing................................................................................................................... 234 43
3.19.2.7 Handoff Performed ......................................................................................................... 234 44
3.19.2.8 Access Handoff and Channel Assignment into Soft Handoff......................................... 234 45
3.19.2.9 Soft/Softer Handoff of High Speed Packet Data............................................................. 235 46
3.19.2.9.1 Soft/Softer Handoff of Forward Link Bursts of Data .............................................. 235 47
3.19.2.9.2 Soft/Softer Handoff of Reverse Link Bursts of SCH Data ...................................... 236 48
3.19.3 Handoff Call Flows............................................................................................................. 236 49
3.19.3.1 Hard Handoff via MSC Call Flows ................................................................................ 236 50
3.19.3.1.1 Successful Hard Handoff ......................................................................................... 236 51
3.19.3.1.2 Successful Hard Handoff to ANSI/TIA/EIA-553-A Systems.................................. 238 52
3.19.3.1.3 Unsuccessful Hard Handoff to ANSI/EIA/TIA-553: ANSI/TIA/EIA-553-A 53
Alternative Rejected................................................................................................. 240 54
3.19.3.1.4 Hard Handoff With Return On Failure .................................................................... 241 55
3.19.3.1.5 Hard Handoff Failure............................................................................................... 243 56
TIA-2001.3-C

viii
3.19.3.2 Soft/Softer Handoff via Direct BS-to-BS Signaling Call Flows..................................... 244 1
3.19.3.2.1 Soft/Softer Handoff Addition................................................................................... 244 2
3.19.3.2.2 Soft/Softer Handoff Removal .................................................................................. 246 3
3.19.3.2.3 Cell Removal by a Target BS .................................................................................. 248 4
3.19.3.2.4 Initial Traffic Burst Example A3 Connection Not Yet Established...................... 249 5
3.19.3.2.5 Subsequent Traffic Burst Example .......................................................................... 252 6
3.19.3.2.6 Source BS Releases Reserved Resources ................................................................ 253 7
3.19.3.2.7 Early Burst Termination Initiated by Source BS ..................................................... 254 8
3.19.3.2.8 Early Burst Termination Initiated by Target BS...................................................... 255 9
3.19.4 Fast Handoff Call Flows..................................................................................................... 255 10
3.19.4.1 Anchor PDSN Reachable from Target PCF ................................................................... 255 11
3.19.4.2 Anchor PDSN Not Reachable from Target PCF............................................................. 259 12
3.19.4.3 Fast Handoff Superseded by Another Fast Handoff ....................................................... 264 13
3.19.5 Intergeneration Packet Data Handoff.................................................................................. 270 14
3.19.5.1 Hard Handoff from 2G System to 3G System................................................................ 270 15
3.19.5.2 Hard Handoff from 3G System to 2G System, PCF not used in the 2G system............. 273 16
3.19.5.3 Intra-PCF Hard Handoff from 3G BS to 2G BS............................................................. 276 17
3.19.5.4 Dormant Handoff from 2G System to 3G System.......................................................... 279 18
3.19.5.5 Dormant Handoff from 3G System to 2G System.......................................................... 279 19
3.19.6 Alternate Dormant Handoff ................................................................................................ 279 20
3.19.6.1 Intra-PDSN Alternate Dormant Handoff of a PDSI, While the Packet Data Session is 21
Dormant .......................................................................................................................... 279 22
3.19.6.2 Alternate Dormant Handoff of a PDSI (Inter-BS/Inter-PCF) - Mobile Served by a 23
Different PDSN .............................................................................................................. 282 24
3.19.6.3 Alternate Dormant Handoff of a PDSI (Inter-BS/Inter-PCF) - with Concurrent 25
Authentication Mobile Served by Same PDSN, Failed Authentication in MSC Following 26
session establishment (PDSN Does Not Have Data to Send) ......................................... 285 27
3.20 Security Features ........................................................................................................................ 287 28
3.20.1 Authentication and Privacy................................................................................................. 287 29
3.20.1.1 SSD Update Procedure - Successful Case ...................................................................... 288 30
3.20.1.2 Terminal Authentication................................................................................................. 290 31
3.20.1.3 Parameter Update............................................................................................................ 290 32
3.20.1.4 Privacy Mode Procedure................................................................................................. 291 33
3.21 Flex Rate .................................................................................................................................... 292 34
3.22 Status Inquiry ............................................................................................................................. 292 35
3.22.1 Status Inquiry Example....................................................................................................... 292 36
3.23 3X Multi-Carrier Operation........................................................................................................ 293 37
3.23.1 Hard Handoff Support ........................................................................................................ 293 38
3.23.2 Soft Handoff Support.......................................................................................................... 294 39
3.24 5 ms Messaging.......................................................................................................................... 294 40
3.24.1 Forward Link ...................................................................................................................... 294 41
3.24.2 Reverse Link....................................................................................................................... 294 42
3.25 Enhanced Rate Adaptation Mode (ERAM) ................................................................................ 295 43
3.26 Code Combining Soft Handoff (CCSH)..................................................................................... 295 44
3.27 Rescue Channel .......................................................................................................................... 295 45
3.27.1 Rescue Channel Network and MS Select the Same Rescue Cell(s)................................. 296 46
3.27.2 Rescue Channel Network and MS Selected Different Rescue Cell(s) ............................. 298 47
3.28 Terrestrial Circuit Management.................................................................................................. 300 48
3.28.1 Terrestrial Circuit Management for the A2/A5 Interfaces .................................................. 300 49
3.28.1.1 A2/A5 Terrestrial Circuit Allocation.............................................................................. 300 50
3.28.1.2 A2/A5 Terrestrial Circuit Blocking/Unblocking ............................................................ 301 51
3.28.1.2.1 Block Procedure Scenario Diagram......................................................................... 301 52
3.28.1.2.2 Unblock Procedure Scenario Diagram..................................................................... 301 53
3.28.1.3 Reset Circuit Procedure .................................................................................................. 302 54
3.28.1.3.1 Reset Procedure at the BS Scenario Diagram.......................................................... 302 55
3.28.1.3.2 Reset Circuit Procedure at the MSC........................................................................ 302 56
TIA-2001.3-C

ix

3.28.1.3.3 Reset Circuit Procedure at the MSC with BS Block Response................................ 303 1
3.28.1.4 Global System Reset ....................................................................................................... 303 2
3.28.1.4.1 Successful Reset at the MSC ................................................................................... 304 3
3.28.1.4.2 Successful Reset at the BS....................................................................................... 304 4
3.28.1.4.3 Reset Glare Noted at the MSC................................................................................. 305 5
3.28.1.4.4 Reset Glare Noted at the BS .................................................................................... 306 6
3.28.1.4.5 Reset Glare Noted at Both the MSC and the BS...................................................... 307 7
3.28.2 Terrestrial Circuit Management for the A3 Interface ......................................................... 308 8
3.28.2.1 Successful Reset at a BS................................................................................................. 308 9
3.28.2.2 A7-Reset Glare Noted at the First BS............................................................................. 309 10
3.28.2.3 A7-Reset Glare Noted at Both BSs................................................................................. 310 11
3.29 Vocoder Support......................................................................................................................... 311 12
3.29.1 Mobile Originated Calls...................................................................................................... 311 13
3.29.2 Mobile Terminated Calls .................................................................................................... 313 14
3.29.3 Service Option Change During Handoff............................................................................. 314 15
3.30 Reverse FCH Gating................................................................................................................... 316 16
3.31 Voice over IP (VoIP).................................................................................................................. 316 17
3.32 Network Directed System Selection (NDSS) ............................................................................. 316 18
3.32.1 Redirection During Mobile Origination.............................................................................. 316 19
3.32.2 Redirection During Mobile Registration ............................................................................ 317 20
3.32.3 Re-Origination Upon Failed Re-Direction.......................................................................... 318 21
3.32.4 Re-Registration Upon Failed Re-Direction......................................................................... 320 22
23
24
TIA-2001.3-C

x
List of Figures 1
2
Figure 2.17-1 Packet Data Session State Transitions .............................................................................. 28 3
Figure 2.19.4-1 General Configuration Prior to a Fast Handoff.......................................................... 34 4
Figure 2.19.4-2 Configuration Without Prior Fast Handoff Target PDSN Identical to Source/Anchor 5
PDSN 35 6
Figure 2.19.4-3 Configuration Without Prior Fast Handoff Target PDSN Different from 7
Source/Anchor PDSN........................................................................................................................... 36 8
Figure 2.19.4-4 Configuration With Prior Fast Handoff - When the Target BS/PCF Can Reach the 9
Anchor PDSN 36 10
Source PDSN 37 12
Figure 2.19.4-6 General Configuration During a Fast Handoff, Step 1............................................... 37 13
Figure 2.19.4-7 General Configuration During a Fast Handoff, Step 2............................................... 38 14
Figure 3.1.1.1-1 Mobile Origination .................................................................................................... 50 15
Figure 3.1.1.2-1 Mobile Origination with Access Probe Handoff, Access Handoff and Channel 16
Assignment into Soft/Softer Handoff ................................................................................................... 53 17
Figure 3.1.1.1-1 Call Clearing with Local Tone Generation ................................................................ 57 18
Figure 3.1.2.1-1 Mobile Termination ................................................................................................... 58 19
Figure 3.1.2.2-1 Mobile Termination: Assignment Retry .................................................................... 60 20
Figure 3.2.4.1-1 Call Clear Initiated by MS......................................................................................... 64 21
Figure 3.2.4.2-1 Call Clear Initiated by BS (via Clear Request) .......................................................... 65 22
Figure 3.2.4.3-1 Call Clear Initiated by MSC (via Clear Command) ................................................... 66 23
Figure 3.3.1-1 Transcoder Control Call Flow.......................................................................................... 66 24
Figure 3.6.1.2-1 Feature Activation/Deactivation While in a Call ....................................................... 68 25
Figure 3.6.2-1 Call Waiting...................................................................................................................... 68 26
Figure 3.6.3.1-1 Three-Way Calling (Method 1).................................................................................. 69 27
Figure 3.6.3.2-1 Three-Way Calling (Method 2).................................................................................. 70 28
Figure 3.6.4.1-1 Message Waiting Notification on the Paging Channel .............................................. 71 29
Figure 3.6.4.2-1 Message Waiting Notification on the Traffic Channel .............................................. 71 30
Figure 3.6.5.2-1 Call Barring Outgoing................................................................................................ 72 31
Figure 3.6.8.1-1 Answer Holding of a Mobile Terminated Call .......................................................... 73 32
Figure 3.6.8.2-1 Answer Holding of Call Waiting ............................................................................... 74 33
Figure 3.6.9.1-1 User Selective Call Forwarding of Mobile Terminated Call ..................................... 75 34
Figure 3.6.9.2-1 User Selective Call Forwarding of Call Waiting ....................................................... 76 35
Figure 3.7.1-1 Location Registration - Successful Case........................................................................... 77 36
Figure 3.7.3-1 Network Initiated Location Registration - Successful Case.............................................. 78 37
Figure 3.7.4-1 Mobile Station Registered Notification ........................................................................... 79 38
Figure 3.10.2.1-1 SMS-Broadcast Delivery to MSs over a Common Channel ..................................... 81 39
Figure 3.10.2.2-1 SMS-MO Delivery on the Access Channel .............................................................. 81 40
Figure 3.10.2.3-1 SMS-MT Delivery to an MS on a Common Channel - Example 1........................... 82 41
Figure 3.10.3.1-1 SMS Message Delivery to an MS on a Traffic Channel ........................................... 87 45
Figure 3.10.3.2-1 SMS Receipt from an MS on a Traffic Channel ....................................................... 88 46
Figure 3.11.1.1-1 Mobile Origination with PACA Service................................................................... 89 47
Figure 3.11.1.2-1 Mobile Origination, Idle Handoff with PACA Active.............................................. 90 48
Figure 3.11.1.3-1 Mobile Origination with Consecutive PACA Call Requests .................................... 91 49
Figure 3.11.2-1 PACA Call Cancellation Initiated by the MS ............................................................ 92 50
Figure 3.11.3-1 PACA Call Cancellation Initiated by the MSC.......................................................... 93 51
Figure 3.12.1.7-1 OTASP Message Flow: CDMA................................................................................ 95 52
Figure 3.13.1.1-1 Mobile Originated Position Location Service on a Traffic Channel ......................... 98 53
Figure 3.13.1.2-1 Mobile Terminated Position Location Service on a Traffic Channel...................... 100 54
Figure 3.13.1.3-1 Position Location Service over Common Channels Mobile Terminated............. 102 55
TIA-2001.3-C

xi

Figure 3.13.1.4-1 Position Location Service over Common Channels Mobile Originated .............. 103 1
Figure 3.13.2-1 Software Calculation for Position Determination .................................................... 104 2
Figure 3.14.1-1 Location Registration using User Zones.................................................................. 105 3
Figure 3.14.2-1 Mobile Call Setup Using User Zone ........................................................................ 106 4
Figure 3.14.3-1 Updating the User Zone During a Call (Mobile Initiated) ....................................... 107 5
Figure 3.14.4-1 Updating the User Zone During a Call (Network initiated) ..................................... 107 6
Figure 3.17.4.1.1-1 MS Initiated PDSI Setup - Packet Data Session is Dormant or Inactive ........ 113 7
Figure 3.17.4.1.2-1 Mobile Initiated Setup of a Packet Data Service Instance When the Packet Data 8
Session is Already Active Successful Operation.............................................................................. 114 9
Figure 3.17.4.2.1-1 BS Initiated Packet Data Service Instance Release to Dormant State When No 10
Other Packet Data Service Instance is Active .................................................................................... 116 11
Figure 3.17.4.2.2-1 BS Initiated Packet Data Service Instance Release to Dormant State When 12
Other Packet Data Service Instances are Active................................................................................. 117 13
Figure 3.17.4.3.1-1 MS Initiated Packet Data Service Instance Release to Dormant State When No 14
Other Packet Data Service Instance is Active .................................................................................... 118 15
Figure 3.17.4.3.2-1 MS Initiated Packet Data Service Instance Release to Dormant State When 16
Figure 3.17.4.4-1 Active MS Power Down .......................................................................................... 121 18
Figure 3.17.4.5.1-1 PDSN Initiated Service Release of a Dormant Packet Data Service Instance 122 19
Figure 3.17.4.5.2-1 PDSN Initiated Service Release of an Active Packet Service Instance Packet 20
Data Session Remains Active............................................................................................................. 123 21
Figure 3.17.4.5.3-1 PDSN Initiated Release of an Active Packet Data Service Instance Packet 22
Data Session Becomes Dormant or Inactive....................................................................................... 124 23
Figure 3.17.4.7.1-1 Network Initiated Packet Data Service Instance Re-Activation from Dormant 24
State Packet Data Session is Dormant ............................................................................................. 126 25
Figure 3.17.4.7.2-1 Network Initiated Packet Data Service Instance Re-Activation from Dormant 26
State Packet Data Session is Active................................................................................................. 128 27
Figure 3.17.4.8-1 Mobile Terminated Packet Data Rejection During a Voice Call ............................. 129 28
Figure 3.17.4.9.1-1 Dormant Handoff of a PDSI (Inter-BS/Inter-PCF) - Mobile Served by Same 29
PDSN, Packet Data Session Dormant ................................................................................................ 131 30
PDSN, Packet Data Session Active.................................................................................................... 133 32
Figure 3.17.4.10-1 Dormant Handoff of a PDSI (Inter-BS/Inter-PCF) - Mobile Served by a Different 33
PDSN 135 34
Figure 3.17.4.11-1 Dormant Handoff of a PDSI (Inter-BS/Inter-PCF) - Mobile Served by Same PDSN, 35
Failed Authentication in MSC Following Session Establishment (PDSN Has Data to Send)............ 137 36
Figure 3.17.4.12-1 Dormant Handoff of a PDSI (Inter-BS/Inter-PCF) - Mobile Served by Same PDSN, 37
Failed Authentication in MSC Following Session Establishment (PDSN Does Not Have Data to Send) 38
139 39
Figure 3.17.4.14-1 Inter-BS Hard Handoff (Within the Same PCF) ...................................................... 141 40
Figure 3.17.4.15-1 Inter-PCF Hard Handoff (Within Same PDSN)....................................................... 144 41
Figure 3.17.4.16-1 Inter-PCF Hard Handoff (Within Same PDSN) With Return On Failure................ 147 42
Figure 3.17.4.17.1-1 MS Initiated Packet Data Service Instance Release to Null State When No Other 43
Packet Data Service Instance is Active .............................................................................................. 149 44
Figure 3.17.4.17.2-1 MS Initiated Packet data Service Instance Release to Inactive/Null State When 45
Figure 3.17.4.18-1 Dormant MS Power Down, A10 Release Initiated by the MSC/BS........................ 152 47
Figure 3.17.4.19-1 Mobile Initiated Initial Packet Data Service Instance Setup Successful Operation 48
with Delayed Accounting Information ............................................................................................... 154 49
Figure 3.17.4.20-1 Accounting Parameters Update Event Procedure .................................................... 156 50
Figure 3.17.4.21-1 Packet Data Session Clearing MSC Initiated........................................................ 157 51
Figure 3.17.4.22-1 MS Initiated Reactivation from Dormant State; MS not Registered with New PDSN 52
158 53
Figure 3.17.5.1.1-1 Mobile Initiated Packet Data Service Instance Setup When the Packet Data 54
Session Is Dormant or Inactive Successful Operation..................................................................... 162 55
TIA-2001.3-C

xii
Figure 3.17.5.1.2-1 Mobile Originated Packet Data Service Instance Setup when the Packet Data 1
Session Is Active Successful Operation........................................................................................... 164 2
Figure 3.17.5.2-1 Mobile Originated Packet Data Service Instance Setup When the Packet Data Session 3
is Dormant or Inactive Failure Operation........................................................................................ 166 4
Figure 3.17.5.3-1 Mobile Originated Packet Service Instance Setup With Registration to Alternate 5
PDSN 168 6
Figure 3.17.5.4-1 Packet Data Service Instance Clearing PDSN Initiated ........................................ 170 7
Figure 3.17.5.5-1 Packet Data Session Clearing MSC Initiated........................................................ 171 8
Figure 3.17.5.6-1 Packet Data Service Session Clearing MS Initiated.............................................. 172 9
Figure 3.17.5.7-1 Packet Data Service Instance Clearing PDSN Initiated (Crossing A11-Registration 10
Request and A11-Registration Update) .............................................................................................. 173 11
Figure 3.17.5.8-1 Inter-PCF Dormant Handoff of a PDSI While Packet Data Session is Dormant 12
Mobile Continues to be Served by the Same PDSN........................................................................... 176 13
Figure 3.17.5.9-1 Inter-PCF Dormant Handoff of a Service Instance Mobile Served by a Different 14
PDSN 179 15
Figure 3.17.5.10-1 Inter-PCF Hard Handoff Mobile Continues to be Served by the Serving PDSN.. 182 16
Figure 3.17.5.11-1 Inter-BS Hard Handoff Mobile Served by New Target PDSN............................. 186 17
Figure 3.17.5.12-1 Accounting Update Due to Parameter Change ........................................................ 189 18
Figure 3.17.5.13-1 MS Initiated Reactivation from Dormant State; MS Not Registered with New PDSN 19
190 20
Figure 3.17.6.1-1 Successful BS Initiated A9 Version Control Procedure........................................... 191 21
Figure 3.17.6.2-1 Successful PCF Initiated A9-Version Control Procedure........................................ 192 22
Figure 3.17.7.1-1 cdma2000
Short Data Burst from an MS to the PDSN ......................................... 193 23

Figure 3.17.7.2.1-1 cdma2000
Short Data Burst from the PDSN to the MS ............................... 195 24

Figure 3.17.7.2.2-1 Short Data Burst from the PDSN to the MS BS Refuses SDB Request....... 197 25
Figure 3.17.8.1-1 MS Initiated CCPD Mode Setup and Data Transfer ................................................ 199 26
Figure 3.17.8.3.1-1 MS in CCPD Mode Handoff (Inter-BS/Inter-PCF) - Mobile Served by Same 27
PDSN 203 28
Figure 3.17.8.3.2-1 MS in CCPD Mode Handoff (Inter-BS/Inter-PCF) - Mobile Served by Different 29
PDSN 205 30
Figure 3.17.10-1 PDSN Initiated Packet Data Session Update ........................................................... 207 31
Figure 3.18.1.1-1 Mobile Initiated Packet Data Service Connection, Packet Data Session Null or 32
Dormant, Voice Service is Already Active ........................................................................................ 209 33
Figure 3.18.1.2-1 Mobile Initiated Voice Service Connection, Packet Data Session is Already Active. 34
210 35
Figure 3.18.2-1 Mobile Termination for Voice Service, Packet Data Session is Already Active ..... 212 36
Figure 3.18.3.1 Network Initiated PDSI Re-Activation from Dormant State, Voice is Already Active, 37
Packet Data Session is Dormant ......................................................................................................... 214 38
Figure 3.18.3.2-1 Network Initiated PDSI Re-Activation from Dormant State, MS is Active with a 39
Concurrent Voice Service (and Dormant Packet Data Session) and Has Performed an Inter-BS/Intra- 40
PCF Voice Call Handoff..................................................................................................................... 216 41
Figure 3.18.4.1-1 Releasing a Service That Is Not the Only One Connected (MS Initiated) ............... 218 42
Figure 3.18.4.2-1 Releasing a Service That Is Not the Only One Connected (MSC Initiated) ........... 219 43
Figure 3.18.4.3.1-1 PDSN Initiated Service Release of the Last Active Packet Data Service Instance 44
Voice Service Active....................................................................................................................... 220 45
Figure 3.18.4.4.1-1 BS Initiated Service Instance Release to Dormant State of Last Active Packet 46
Data Service Instance, Voice Service Active ..................................................................................... 222 47
Figure 3.18.5.2.1-1 Successful Inter-PCF Handoff (Mobile Served by the Same PDSN) ............. 224 48
Figure 3.18.5.2.2-1 Successful Inter-PCF Handoff (Mobile Served by New PDSN)..................... 227 49
Figure 3.19.3.1.1-1 Successful Hard Handoff ................................................................................ 237 50
Figure 3.19.3.1.2-1 Successful Hard Handoff to an ANSI/TIA/EIA-553-A System...................... 239 51
Figure 3.19.3.1.3-1 Unsuccessful Hard Handoff to ANSI/EIA/TIA-553: ANSI/TIA/EIA-553-A 52
Alternative Rejected 240 53
Figure 3.19.3.1.4-1 Hard Handoff with Return On Failure ............................................................ 242 54
Figure 3.19.3.1.5-1 Hard Handoff Failure ...................................................................................... 243 55
TIA-2001.3-C

xiii

Figure 3.19.3.2.1-1 Soft/Softer Handoff Addition.......................................................................... 245 1
Figure 3.19.3.2.2-1 Soft/Softer Handoff Removal ......................................................................... 247 2
Figure 3.19.3.2.3-1 Cell Removal Initiated by the Target BS........................................................ 248 3
Figure 3.19.3.2.4-1 Initial Traffic Burst Example .......................................................................... 250 4
Figure 3.19.3.2.5-1 Subsequent Traffic Burst Example ................................................................. 252 5
Figure 3.19.3.2.6-1 Source BS Releases Reserved Resources........................................................ 254 6
Figure 3.19.3.2.7-1 Early Burst Termination Initiated by Source BS............................................. 254 7
Figure 3.19.3.2.8-1 Early Burst Termination Initiated by Target BS ............................................. 255 8
Figure 3.19.4.1-1 Anchor PDSN Reachable From Target PCF............................................................ 256 9
Figure 3.19.4.2-1 Anchor PDSN Not Reachable From Target PCF..................................................... 260 10
Figure 3.19.4.3-1 Fast Handoff Superseded by Another Fast Handoff ................................................ 265 11
Figure 3.19.5.1-1 Hard Handoff from 2G System to 3G System......................................................... 271 12
Figure 3.19.5.2-1 Hard Handoff from 3G System to 2G System......................................................... 274 13
Figure 3.19.5.3-1 Intra-PCF Hard Handoff from 3G BS to 2G BS...................................................... 277 14
Figure 3.19.6.1-1 Alternate Dormant Handoff of a PDSI (Inter-BS/Inter-PCF) - Mobile Served by Same 15
PDSN, Packet Data Session Dormant ................................................................................................ 280 16
Figure 3.19.6.2-1 Alternate Dormant Handoff of a PDSI (Inter-BS/Inter-PCF) - Mobile Served by a 17
Different PDSN 283 18
Figure 3.19.6.3-1 Alternate Dormant Handoff of a PDSI (Inter-BS/Inter-PCF) with Concurrent 19
Authentication - Mobile Served by Same PDSN, Failed Authentication in MSC Following Session 20
Establishment (PDSN Does Not Have Data to Send)......................................................................... 286 21
Figure 3.20.1.1-1 SSD Update - Successful Case................................................................................. 289 22
Figure 3.20.1.2-1 Terminal Authentication .......................................................................................... 290 23
Figure 3.20.1.3-1 Parameter Update.................................................................................................... 291 24
Figure 3.20.1.4-1 Privacy Mode Procedure.......................................................................................... 291 25
Figure 3.22.1-1 Status Inquiry........................................................................................................... 293 26
Figure 3.27.1-1 Rescue Channel Network and MS Select the Same Rescue Cell(s)...................... 296 27
Figure 3.27.2-1 Rescue Channel Network and MS Selected Different Rescue Cells..................... 299 28
Figure 3.28.1.2.1-1 Block Procedure.............................................................................................. 301 29
Figure 3.28.1.2.2-1 Unblock Procedure.......................................................................................... 301 30
Figure 3.28.1.3.1-1 A1 Reset Circuit Procedure at the BS............................................................. 302 31
Figure 3.28.1.3.2-1 Reset Circuit Procedure at the MSC ............................................................... 302 32
Figure 3.28.1.3.3-1 Reset Circuit Procedure at the MSC with BS Block Response....................... 303 33
Figure 3.28.1.4.1-1 Successful Reset at the MSC........................................................................... 304 34
Figure 3.28.1.4.2-1 Successful Reset at the BS.............................................................................. 305 35
Figure 3.28.1.4.3-1 Reset Glare Noted at the MSC........................................................................ 306 36
Figure 3.28.1.4.4-1 Reset Glare Noted at the BS............................................................................ 307 37
Figure 3.28.1.4.5-1 Reset Glare Noted at Both the MSC and the BS............................................. 308 38
Figure 3.28.2.1-1 Successful A7-Reset at a BS.................................................................................... 309 39
Figure 3.28.2.2-1 A7-Reset Glare Noted at the First BS...................................................................... 309 40
Figure 3.28.2.3-1 A7-Reset Glare Noted at Both BSs.......................................................................... 310 41
Figure 3.29.1-1 Vocoder Selection Mobile Originated Case.......................................................... 312 42
Figure 3.29.2-1 Vocoder Selection Mobile Terminated Case ........................................................ 313 43
Figure 3.29.3-1 Vocoder Selection Handoff Case.......................................................................... 314 44
Figure 3.32.1-1 Service Redirection During Mobile Origination...................................................... 317 45
Figure 3.32.2-1 Service Redirection During Mobile Registration..................................................... 318 46
Figure 3.32.3-1 Re-Origination Upon Failed Re-Direction............................................................... 319 47
Figure 3.32.4-1 Re-Registration Upon Failed Re-Direction.............................................................. 321 48
49
50
TIA-2001.3-C

xiv
List of Tables 1
2
Table 3.20.1-1 Authentication and Voice Privacy Requirements .................................................... 287 3
4
5
TIA-2001.3-C

1 Section 1

1.0 Introduction 1
This document contains the procedures and call flows associated with the features that 2
are supported by this release of the IOS specification. 3
1.1 Overview 4
This document includes a description of the protocol and some generic procedures to 5
support the following features and functions. Conformance to this standard may be 6
claimed on a feature by feature and/or interface by interface basis. If conformance on a 7
given interface is claimed for a feature, it shall be supported as defined in this standard. 8
The following features have been added in this revision of the standard: 9
Access Control by Call Type (ACCT) 10
Network Directed System Selection (NDSS) 11
Reverse FCH Gating 12
Vocoder Support 13
Selectable Mode Vocoder (SMV) 14
Voice over IP (VoIP) Service 15
Alternate Dormant Handoff Procedures 16
17
In addition, the following enhancements were made to IOS functions: 18
IP Transport 19
Support for Origination Continuation Message 20
Support for network initiated registration 21
Support for AAA-Based Radio Network Packet Inactivity Timer (RN-PDIT) 22
Support for Multiple Service Instances 23
24
Features and Functions Explicitly Supported in this Standard: 25
3G Packet Data Calls 26
Call Setup (mobile originated) 27
Reactivation (mobile initiated and network initiated) 28
Handoffs (dormant, alternate dormant, hard, fast) 29
Call Clearing (mobile initiated and network initiated) 30
Transition to Dormancy 31
Accounting 32
Common Channel Packet Data (CCPD) 33
Short Data Bursts 34
3X Multi-Carrier 35
5 ms Messaging 36
Access Control by Call Type (ACCT) 37
TIA-2001.3-C

Section 1 2

Call Clearing of Voice and Circuit Data Calls (mobile initiated and network 1
initiated) 2
Call Setup for Voice and Circuit Data Calls (mobile originated and mobile 3
terminated) 4
Circuit Data Calls (asynchronous data and group-3 fax) 5
Circuit Voice and Packet Data Concurrent Services 6
Code Combining Soft Handoff (CCSH) 7
E911 Phase 1 and Phase 2 8
Enhanced Rate Adaptation Mode (ERAM) 9
Flex Rate 10
Global Emergency Call Origination 11
Handoff 12
Handoff via MSC 13
Handoff via direct BS-to-BS signaling 14
Fast Handoff 15
Hard Handoff into Soft Handoff 16
Intergenerational Packet Data Handoff 17
Alternate dormant handoff 18
ISDN Interworking 19
Mobile Position Determination 20
Mobile Registration 21
Network Directed System Selection (NDSS) 22
Over the Air Service Provisioning (OTASP) 23
Over the Air Parameter Administration (OTAPA) 24
Priority Access and Channel Assignment (PACA) 25
Rescue Channel 26
Reverse FCH Gating 27
Security Features 28
Terminal Authentication 29
Signaling Message Encryption 30
Voice/Data Privacy 31
Short Message Service (mobile originated, mobile terminated, and broadcast) (SMS) 32
Status Inquiry 33
Support of DTMF 34
Support for DS-41 base stations 35
Support of Supplementary Services 36
Feature Activation/Deactivation: Idle and In-Call 37
Call Waiting 38
Three-Way Calling 39
Message Waiting Notification 40
TIA-2001.3-C

3 Section 1

Call Barring 1
Calling Number ID Presentation (CNIP) and Calling Number ID Restriction 2
(CNIR) 3
Distinctive Ringing 4
Answer Holding 5
User Selective Call Forwarding 6
Terrestrial Circuit Management 7
Test Calls 8
TFO Support 9
User Zone 10
Vocoder Support 11
13K 12
Enhanced Variable Rate Codec (EVRC) 13
Selectable Mode Vocoder (SMV) 14
Voice over IP (VoIP) Service 15
16
Features and Functions Transparently Supported in this Standard: 17
Advice of Charge 18
Call Delivery 19
Call Forwarding 20
Call Forwarding Unconditional 21
Call Forwarding When Busy 22
Call Forwarding No Answer 23
Call Forwarding Default 24
Call Transfer 25
Carrier Access 26
Emergency Service (Basic) via specific dialed number (e.g., 911) 27
Lawfully Authorized Wiretap 28
29
TIA-2001.3-C

Section 1 4

Active Handoff (MC-41 to MC-41 and DS-41 to DS-41): the following types of handoffs 1
are supported: 2

Type of Handoff
Voice
calls
Async Data
and G3 Fax
Packet Data
Calls (up to
2 Mbps)
ISDN
Interworking
Calls
Intra-BS, Intra-MSC Soft Handoff Yes Yes Yes Yes
e

* Intra-BS, Intra-MSC Hard Handoff Yes Yes Yes Yes
e

Inter-BS, Intra-MSC Soft Handoff Yes Yes Yes Yes
e

* Inter-BS, Intra-MSC Hard Handoff Yes Yes Yes
a
Yes
e

Inter-BS, Inter-MSC Soft Handoff Yes Yes Yes Yes
e

* Inter-BS, Inter-MSC Hard Handoff Yes No Yes
b
Yes
e

Intergenerational Handoff
c
Yes Yes Yes
d
No
e

Active Handoff (DS-41 hard handoff to/from MC-41): the following types of handoffs 3
are supported: 4

Type of Handoff
Voice
calls
Async Data
and G3 Fax
Packet Data
Calls (up to
2 Mbps)
* Inter-BS, Intra-MSC Hard Handoff Yes Yes Yes
a

* Inter-BS, Inter-MSC Hard Handoff Yes No Yes
b

* Hard handoff does not apply to Supplemental Channels 5
a. Inter-BS, intra-MSC hard handoff may result in handoff across PDSN boundaries. 6
b. Inter-BS, inter-MSC hard handoff may result in handoff across PDSN boundaries. In 7
addition, this requires extensions to ANSI-41 for packet data services. 8
c. Intergenerational handoff describes handoff of a mobile between a system that 9
supports packet data service as specified in [11]~[17] and a system that supports a 10
packet data service as specified in [10]. 11
d. The Service Option changes in this scenario. 12
e. Not applicable for DS-41 to DS-41 handoffs. 13
Soft handoff enhancements as specified in [10] are supported by this specification. 14
Access Handoff, Access Probe Handoff and CDMA Channel Assignment into Soft 15
Handoff and Access Entry Handoff as specified in [10] are supported in this 16
specification. 17
Access Entry Handoff is transparent to this standard. 18
Mobile-Assisted CDMA-to-CDMA Inter-Frequency Handoff Enhancement is supported 19
as specified in [10]. 20
Circuit mode voice service assumptions: 21
The following assumptions are made: 22
All mobiles are capable of executing a service option change and a hard handoff 23
simultaneously. That is, the Action Time for both of these activities may be the 24
same. 25
TIA-2001.3-C

5 Section 1

For inter-vendor hard handoff, the source BS knows the service option capabilities of 1
the target BS. 2
For inter-vendor soft handoff, all target BS channel elements are capable of 3
supporting 13K, EVRC, and SMV service options (i.e., rate set 1 and rate set 2). 4
A default service configuration shall be used at all target BSs for hard handoff. 5
The MSC is aware of the service options supported by each of the BSs attached to it. 6
Hard handoff from 13K to EVRC is disallowed for TIA/EIA/IS-95B mobiles. 7
For cdma2000
1
mobiles, if the target BS does not have the proposed service option 8
available, the target BS may send a new service option to the source BS. 9
Currently, only 13K (8000H and 0011H), EVRC, and SMV voice service options are 10
supported. 11
The default service option for IOS networks is operator configurable. 12
13
All mobile stations are capable of supporting the default voice service option. 14
Service negotiation is between the Base Station (BS) and the Mobile Station (MS). 15
Service negotiation only depends on the capabilities of the BS and of the MS. 16
Based on these assumptions, a source BS always know what vocoder types (EVRC / 17
13K/SMV) are supported at the target BS, and what service configuration is to be used at 18
the target BS. If a change of vocoder type is necessary, the source BS can accomplish it 19
by commanding the MS to execute a service option change and a hard handoff 20
simultaneously. Thus, service negotiation messaging is not needed on either the A1 or A3 21
interfaces. 22
The following procedures are to be followed: 23
If the BS receives a Paging Request from the MSC specifying a service option valid 24
for this version of the IOS but not supported by the BS, the BS pages the MS with 25
the service option in the Paging Request message. 26
If the BS receives an Origination Message / Paging Response Message from an MS 27
specifying a service option not valid for this standard, the BS may deny the request. 28
In the case of an originating call, the BS may order the MS to generate a local 29
Reorder signal. 30
Otherwise, if the BS receives an Origination Message / Paging Response Message 31
from an MS specifying a supported service option that is not supported on the 32
particular BS, the BS shall send a CM Service Request message / Paging Response 33
message to the MSC containing the service option received from the MS. 34
The MSC sends the service option that was received in the CM Service Request / 35
Paging Response message in the Assignment Request message. 36
Otherwise, the call is handled using the call setup procedures of this specification. 37
In all cases, if a call is successfully set up, the BS shall inform the MSC of the agreed 38
service option in the Assignment Complete message. 39
In the intra-MSC hard handoff scenario, if the source BS asks for a service option not 40
supported by the target BS, then the MSC may reject the handoff request. 41

cdma2000
is a registered trademark of the Telecommunications Industry Association

(TIA USA).

TIA-2001.3-C

Section 1 6

1.1.1 Purpose 1
The purpose of this document is to provide IOS Feature Description (Stage 1) and IOS 2
Feature Call Flows (Stage 2) for the Access Network Features. 3
1.1.2 Scope 4
This document provides user level descriptions and access network call flows designed to 5
assist in the development of the interfaces that coincide with the Reference Points: A, 6
A
ter
, A
quater
, and A
quinter
, as defined in the Network Reference Model. Refer to 7
[28]. Refer to [11]~[17] for definitions of messages and timers used in this document. 8
1.2 References 9
10
1.2.1 TIA / EIA 11
with the 3GPP2 references, provided in section 1.2.2. For consistency within IOS parts, 14
[1] TIA/EIA/IS-2000.1-B, Introduction for cdma2000

Spread 19
21
cdma2000

cdma2000

Spread 27
[7] Reserved. 29

[9] TIA/EIA-41-D, Cellular Radio-Telecommunications Intersystem Operations; 31
December 1997. 32
[10] TIA/EIA-95-B; Mobile Station Base Station Compatibility Standard for Dual- 33
Mode Wideband Spread Spectrum Cellular Systems; March 1999. 34
Access 35
Access 37
Access 39
Access 41
TIA-2001.3-C

7 Section 1

Access 1
Access 3
Access 5
[18] TIA/EIA-553-A, Mobile Station Base Station Compatibility Specification; 7
November 1999. 8
[19] Reserved. 9
[20] TIA/EIA/IS-637-B, Short Message Service for Wideband Spread Spectrum 10
Systems, January 2002. 11
[21] TIA/EIA-664-A, Wireless Features Description; December 2000. 12
[22] TIA/EIA/IS-683-B, Over the Air Service Provisioning of Mobile Stations in 13
Spread Spectrum Systems, December 2001. 14
[23] TIA/EIA/IS-707-A-3, Data Services Option Standard for Spread Spectrum 15
Systems Addendum 3 cdma2000 High Speed Packet Data Device Option 33, 16
February 2003. 17
[24] TIA/EIA/IS-725-A, TIA/EIA-41-D Enhancements for Over-The-Air Service 18
Provisioning (OTASP) & Parameter Administration (OTAPA), March 1999. 19
[25] TIA/EIA/IS-728, InterSystem Link Protocol, April 1998. 20
[26] TIA/EIA/IS-801-1, Position Determination Service Standard for Dual Mode 21
Spread Spectrum Systems, March 2001. 22
[27] TIA/EIA-895-A, CDMA Tandem Free Operation, October 2002. 23
[29] Common Cryptographic Algorithms, Revision D.1, September 2000. An Export 25
Administration Regulations controlled document subject to restricted 26
distribution. Contact the Telecommunications Industry Association, Arlington, 27
VA. 28
[30] Interface Specification for Common Cryptographic Algorithms, Revision D.1, 29
September 2000. Contact the Telecommunications Industry Association, 30
Arlington, VA. 31
[31] TIA-923, Link-Layer Assisted Service Options for Voice-over-IP: Header 32
Removal (SO 60) and Robust Header Compression (SO 61), May 2003. 33
[32] TIA/EIA/IS-880, TIA-41-D based network enhancements for CDMA packet data 34
service (C-PDS), phase 1, July 15, 2002. 35
[33] Reserved. 36
[34] Reserved. 37
[35] Reserved. 38
[36] Reserved. 39
[37] TIA TIA/EIA/IS-848, Enhanced Charging Services, November 2000. 40
41
42
1.2.2 3GPP2 43

[2] 3GPP2 C.S0002-B-1, Physical Layer Standard for cdma2000
Spread Spectrum 48
[3] 3GPP2 C.S0003-B-1, Medium Access Control (MAC) Standard for cdma2000
50
TIA-2001.3-C

Section 1 8

[4] 3GPP2 C.S0004-B-1, Signaling Link Access Control (LAC) Standard for 1
cdma2000

[5] 3GPP2 C.S0005-B-1, Upper Layer (Layer 3) Signaling Standard for 3
cdma2000

[6] 3GPP2 C.S0006-B-1, Analog Signaling Standard for cdma2000
Spread 5
[7] Reserved. 7
[8] 3GPP2 P.S0001-B, Wireless IP Network Standard, September 2002. 8
[9] Reserved. 9
[10] Reserved. 10
Access 11
Access 13
Access 15
Access 17
Access 19
Access 21
Access 23
[18] Reserved. 25
[19] Reserved. 26
[20] 3GPP2 C.S0015-A, Short Message Service (SMS) for Wideband Spread 27
Spectrum Systems, Release A, January 2002. 28
[21] 3GPP2 S.R0006-0, Wireless Features Description, December 1999. 29
[22] 3GPP2 C.S0016-0, Over the Air Service Provisioning of Mobile Stations in 30
Spread Spectrum Systems, June 1998. 31
[23] 3GPP2 C.S0017-0 Version 5, Data Service Options for Spread Spectrum 32
Systems Addendum 3, February, 2003. Refer also to TIA/EIA/IS-707-A-3. 33
[24] 3GPP2 N.S0011-1, OTASP and OTAPA, January 1999. 34
[25] 3GPP2 N.S0019-0, InterSystem Link Protocol, April 1998. 35
[26] 3GPP2 C.S0022-0, Location Services (Position Determination Service), 36
December 1999. 37
[27] 3GPP2 A.S0004-B, CDMA Tandem Free Operation, August 2002. 38
Spread Spectrum 39
[29] 3GPP2, S.S0053, Common Cryptographic Algorithms, January 2002. 41
[30] 3GPP2 S.S0054, Interface Specification for Common Cryptographic Algorithms, 42
January 2002. 43
[31] C.S0047-0, Link-Layer Assisted Service Options for Voice-over-IP: Header 44
Removal (SO 60) and Robust Header Compression (SO 61) April 2003. 45
[32] 3GPP2 N.S0029-0, TIA/EIA-41-D Based Network Enhancements for CDMA 46
Packet Data Service (C-PDS), Phase I, Revision 0, June 2002. 47
[33] Reserved. 48
[34] Reserved. 49
[35] Reserved. 50
[36] Reserved. 51
[37] 3GPP2 N.S0004-0, WIN Phase 2, - Trigger for Preferred Language, Advice of 52
Charge, Rejection of Undesired Annoying Calls, Premium Rate Charging, 53
Freephone, April 2001. 54
TIA-2001.3-C

9 Section 1

1.2.3 International Telecommunications Union 1
[38] Reserved. 3
[39] Reserved. 4
1.2.4 Other 5
[40] Reserved. 6
[41] Internet Engineering Task Force, RFC 2002 IP Mobility Support, October 7
1996. 8
[42] Internet Engineering Task Force, RFC 3115 Mobile IP Vendor/Organization- 9
Specific Extensions, April 2001. 10
[43] Reserved. 11
[44] Internet Engineering Task Force, RFC 2784 Generic Routing Encapsulation 12
(GRE), September 2000. 13
14
TIA-2001.3-C

Section 1 10

1.3 Terminology 1
2
1.3.1 Acronyms 3
4
Acronym Meaning
2G Second Generation
3G Third Generation
AAA Authentication, Authorization and Accounting entity
AC Authentication Center
ACCOLC Access Overload Class
ACCT Access Control by Call Type
AH Answer Holding
AMPS Advanced Mobile Phone System
APM Access Parameters Message
AUTHBS Authentication
AUTHR Authentication Response
AUTHU Unique Challenge Authentication Response
BCD Binary Code Decimal
BS Base Station
CANID Current Access Network Identifiers
CCPD Common Channel Packet Data
CCSH Code Combining Soft Handoff
CNIP Calling Number Identification Presentation
CNIR Calling Number Identification Restriction
COUNT Call History Count
CW Call Waiting
DRS Data Ready to Send
DS0 Digital Signal Level 0
DTMF Dual Tone Multi-Frequency
EAPM Enhanced Access Parameters Message
TIA-2001.3-C

11 Section 1

Acronym Meaning
EPSMM Extended Pilot Strength Measurement Message
ERAM Enhanced Rate Adaption Mode
ESCAM Extended Supplemental Channel Assignment Message
EVRC Enhanced Variable Rate Codec
FER Frame Error Rate
IE Information Element
IS Interim Standard
ISLP Intersystem Link Protocol
LAC Link Access Control
LLA-ROHC Link Layer Assisted Robust Header Compression
MAC Medium Access Control
MC Message Center (alternatively: Mobile Client)
MC-41 Multi-Carrier (ANSI)-41
MIP Mobile IP
MS Mobile Station
MSIN Mobile Station Identifier Number
MWI Message Waiting Indication
NID Network Identification
NDSS Network Directed System Selection
NVSE Normal Vendor Specific Extension
OAM&P Operations, Administration, Maintenance, and
Provisioning
OTAF Over The Air Function
OTAPA Over The Air Parameter Administration
OTASP Over The Air Service Provisioning
PANID Previous Access Network Identifiers
PCM Pulse Coded Modulation
PDE Position Determination Entity
TIA-2001.3-C

Section 1 12

Acronym Meaning
PDSI Packet Data Service Instance
PIN Personal Identification Number
PLD Position Location Data
PPP Point to Point Protocol
PZID Packet Zone Identifier
RAN Radio Access Network
RAND Random Variable
RANDSSD Random SSD
RANDU Random Variable Unique Challenge
RLP Radio Link Protocol
RN-PDIT Radio Network Packet Data Inactivity Timer
RTP Real Time Protocol
SAT Supervisory Audio Tone
SDB Short Data Burst
SID System Identification
SIP Session Initiation Protocol
SME Signaling Message Encryption
SMS Short Message Service
SMS-MO SMS Mobile Originated
SMS-MT SMS Mobile Terminated
SMV Selectable Mode Vocoder
SO Service Option
SOCI Service Option Connection Identifier
SPI Security Parameter Index
SR_ID Service Reference Identifier
SSD Shard Secret Data
TCH Traffic Channel
TDSO Test Data Service Option
TFO Tandem Free Operation
VoIP Voice over IP
1.3.2 Definitions 1
2
TIA-2001.3-C

13 Section 1

Refer to [11] for additional definitions. 1
DS-41: An operational mode in which the BS and MS operate with the direct 2
spread (DS) radio layers of the UMTS system defined by 3GPP, and 3
the upper layers defined in IS-2000 that conform to and interoperate 4
with ANSI-41 based networks. 5
MC-41: An operational mode in which the BS and MS operate with the multi- 6
carrier (MC) radio layers and the upper layers defined in IS-2000 that 7
conform to and interoperate with ANSI-41 based networks. 8
origination message: 9
In this document, origination message is used to indicate either an 10
Origination or Enhanced Origination air interface message. 11
1.4 Call Processing and Supplementary Services Assumptions 12
This section contains assumptions for call processing and supplementary services. 13
In some of the call processing and services functions, it is possible that an inter-BS hard 14
handoff may occur during the process. In such an event, the target BS (i.e., the BS to 15
which the MS has been handed off) shall assume responsibility for functionality ascribed 16
to the BS as defined herein. 17
1.4.1 Call Control 18
Call control shall be primarily the responsibility of the MSC. The BS provides message 19
transmission and interworking between the particular air interface and the MSC. 20
1.4.1.1 A2/A5 Terrestrial Circuit Allocation 21
Terrestrial Circuit allocation is handled in the following manner: 22
The MSC considers the interface to the BS as a route of n circuits. The MSC shall 23
therefore ensure that the terrestrial circuit chosen is able to support the type of call 24
involved. 25
The BS may suggest a preferred terrestrial circuit to the MSC, in which case, the MSC 26
shall use the suggested terrestrial circuit if available. Refer to section 2.28 for the 27
definition of available. 28
1.4.1.2 Radio Channel Allocation 29
The BS allocates the radio channel to be used. This may be based on information 30
received from the MSC. 31
1.4.1.3 Traffic Channel Release 32
The release of a dedicated resource is primarily controlled by the MSC. However, for 33
radio propagation reasons, the BS may request that the MSC release a call. 34
1.4.1.4 A3 User Traffic Subchannel Allocation 35
The target BS considers the interface to the SDU as a route of multiple A3 User Traffic 36
Subchannels. The target BS chooses an A3 User Traffic Subchannel from the idle A3 37
TIA-2001.3-C

Section 1 14

User Traffic Subchannels connected to the SDU where the call being processed is 1
anchored. 2
1.5 Radio Resource Management Assumptions 3
This section contains assumptions about radio resource management. 4
1.5.1 Radio Channel Supervision 5
1.5.1.1 Traffic Channel Radio Link Supervision 6
Radio link supervision of dedicated radio resources shall be the responsibility of the BS. 7
If communication with the MS is lost then the BS can request that the call be cleared. 8
1.5.1.2 Idle Channel Observation 9
The quality of idle radio channels may be measured by the BS. 10
1.5.2 Radio Channel Management 11
1.5.2.1 Radio Channel Configuration Management 12
The channel configuration management shall be controlled between the BS and the 13
Operations System (OS) over the O interface. The BS shall be able to support one cell 14
or multiple cells. The O interface is beyond the scope of this specification. 15
1.5.2.2 Radio Traffic Channel Management 16
17
1.5.2.2.1 Radio Channel Allocation 18
The BS shall always choose the radio channel to be used. 19
1.5.2.2.2 Radio Traffic Channel Release 20
The release of a dedicated radio resource is primarily controlled by the MSC. However, 21
for radio propagation reasons the BS can request of the MSC that a call be released. 22
1.5.2.2.3 Radio Traffic Channel Power Control 23
All power control functions shall be performed between the MS and the BS. 24
1.5.2.2.4 Channel Encoding and Decoding 25
The radio channel encoding and decoding, and interleaving shall be performed by the BS. 26
The type of radio channel coding and interleaving is derived from the information in the 27
air interface messages from the MS and the Assignment Request message from the MSC. 28
Refer to [14] for information on this message. 29
30
TIA-2001.3-C

15 Section 2

2.0 Feature Descriptions 1
2
2.1 Call Setup of Voice and Circuit Data Calls 3
Call setup is a process where a sequence of messages is used to advance the call to a 4
stable condition where the parties involved may communicate. 5
The call setup may be a normal call setup, emergency call setup, SMS, OTAPA, PACA 6
call setup, or other supplementary service invocation. 7
Call Setup messages are defined in [14]. 8
Refer to section 3.1.1 for mobile originated call flows and section 3.1.2 for mobile 9
terminated call flows associated with this feature. An MS-to-MS call is handled as a 10
combination of a mobile originated and a mobile terminated call. Tandem Free Operation 11
(TFO) may be applied for MS-to-MS calls to enhance speech quality, refer to section 2.3. 12
2.2 Call Clearing of Voice and Circuit Data Calls 13
Call clearing is a process where a sequence of messages is used to free in a controlled 14
manner all resources in the network associated with one or all service instances of an MS. 15
There are two types of call clearing over the A1 interface: 16
1. Call clearing of a single service, when other services are connected. 17
2. Call clearing of all services connected (including the case where only one service is 18
connected). 19
Call clearing may be initiated by either the BS, the MS, or the MSC. 20
Call clearing collision occurs when two entities independently initiate the call clearing 21
procedures; refer to section 3.2.3 for description of cases of call clearing collisions. 22
Refer to section 3.2 for call flows related to this feature. Refer to section 3.18 for call 23
flows related to concurrent services. 24
2.2.1 Call Clearing Initiated by the MS or BS 25
When the MS initiates a normal clearing of all services including the only service 26
connected, the MS sends a Release Order to the BS. The BS shall send a Clear Request 27
message to the MSC and wait for the Clear Command message from the MSC. The call 28
flow scenario is illustrated in section 3.2.4.1. 29
The MSC is responsible for clearing A1, A2, and/or A5 connections associated with the 30
call. To release all allocated resources associated with all services, the MSC shall send a 31
Clear Command message to the BS. The call flow scenario is illustrated in section 32
3.2.4.3. 33
The MS may also initiate a release of a service that is not the only service connected to 34
the MS. The scenario is illustrated in section 3.18.4.1. 35
TIA-2001.3-C

Section 2 16

If for any reason the radio channel failed between the MS and the BS or if some internal 1
BS failure occurs, then the BS initiates call clearing. The BS sends a Clear Request 2
message to the MSC. The scenario is illustrated in section 3.2.4.2. 3
2.2.2 Call Clearing Initiated by the MSC 4
When the MSC chooses to deny call setup initiated by the reception of a CM Service 5
Request or Paging Response message contained in an SCCP Connection Request, the 6
MSC may send an SCCP Connection Refused containing no user data. Refer to [10]. 7
When the MSC initiates a normal clearing of a single service that is not the only service 8
connected, the MSC sends a Service Release message to the BS. This normal call 9
clearing scenario is illustrated in section 3.18.4.2. 10
In case the MSC initiates a normal clearing of all services, the MSC shall send a Clear 11
Command message to the BS. This normal call clearing scenario is illustrated in section 12
3.2.4.3. 13
Call clearing messages are not affected if the network provides either tones or 14
announcements immediately before clearing a call. 15
2.3 TFO Support 16
MS-to-MS calls are handled as a combination of mobile originated and mobile terminated 17
calls. For information on Tandem Free Operation, refer to [27]. 18
It is generally known that tandeming of vocoders results in noticeable audio degradation. 19
Although some vocoders handle tandeming better than others, all suffer from this effect. 20
Such tandeming occurs in an MS-to-MS digital call. 21
For an MS-to-MS digital call, vocoding currently takes place at both the originating and 22
terminating SDUs. Encoded audio received at the SDU is decoded and subsequently 23
routed to the terminating SDU via the MSC(s). At the terminating SDU, the decoded 24
voice is encoded again prior to transmission over the air. This tandem vocoding results 25
in an audio quality degradation and increased throughput delay compared to an MS-to- 26
land or land-to-MS call. 27
The TFO feature enhances current operation by bypassing the vocoding process at the 28
SDU(s) for MS-to-MS calls. If both MS parties are using the same voice service option, 29
the encoded voice received from the BTS is not decoded at the SDU. Instead the encoded 30
voice is converted to the appropriate MSC/BS signaling format (e.g., rate adapted to a 31
64K DS0 timeslot, but not decoded) for transmission through the MSCs. The terminating 32
MSC in turn routes the encoded speech to the appropriate SDU where it is converted 33
back to the appropriate signaling format for routing to the BTS. 34
TFO setup operation relies on inband signaling exchange between the SDUs. The SDUs 35
use inband signaling to determine when it is appropriate to establish TFO operation. 36
Refer to [27] for complete details regarding the inband signaling protocol. 37
The TFO feature also provides the capability of controlling TFO operation via out-of- 38
band signaling. Specifically, the Transcoder Control Request and Transcoder Control 39
Acknowledge messages could be used over the A1 interface to disable/enable the inband 40
signaling mechanism at the SDUs. Disabling the inband signaling mechanism, forces the 41
call to revert to tandem vocoding mode. These same messages can also be used to re- 42
TIA-2001.3-C

17 Section 2

start/enable the inband signaling protocol at the SDUs. This capability is beneficial for 1
supplementary feature interaction scenarios (e.g.,, Answer Hold and Three Party 2
Conferencing). 3
Refer to section 3.3 for call flows associated with this feature. 4
2.4 Test Calls 5
The purpose of test calls is to generate test data (e.g., frame error rate (FER), forward and 6
reverse link capacity estimates, etc.) for performance analysis. These calls need not 7
require any trunks (DS0 circuits) on the A2 or A5 interfaces. The MS or the MSC may 8
initiate a test call. 9
The test data service option (TDSO) provides for the generation of an arbitrary 10
(preselected or random) data source for transport over forward and reverse traffic 11
channels while following an arbitrary (preselected or random) transmission frame 12
activity. The test is performed at a fixed data rate. The MS and the BS generate test data 13
frames for the configured and allocated traffic channels. The frame generation processes 14
are synchronized between the MS and the BS. This permits the receiving station to 15
reproduce the transmitted frames and compare them to the received frames. 16
The Markov service option provides pseudo-random data for testing the Fundamental 17
Channel between the MS and the BS. The test can be performed at a fixed data rate or at 18
a variable data rate. A pseudo-random process governs the selection of the data rate for 19
each data block in a variable rate test. A pseudo-random process also generates the 20
content of each data block. The pseudo-random processes are synchronized between the 21
MS and the BS. This permits the receiving station to reproduce the transmitted data 22
blocks and compare them to the received data blocks. 23
The loopback service options provide a loopback of primary traffic information bits 24
through the MS. These service options provide the means for a BS to supply a known 25
data stream on both the Forward and Reverse traffic channels so that an MSs receiving 26
and transmitting performance can be measured. In addition, these service options provide 27
a convenient means of setting up calls and generating traffic for system testing. 28
When the test call uses a TDSO, Markov, or loopback operation, reception of any 29
supplementary service messages or inter-BS hard handoff requests may be considered 30
unexpected and may be ignored. 31
Hard handoff is not supported for test calls. 32
2.5 Support of DTMF 34
DTMF digit transmission can be sent using in-band tones between the MS and MSC once 35
a call is in Conversation State. No action is required by the BS for transmission of in- 36
band DTMF signals. 37
Alternatively, DTMF digits may be sent in a Send Burst DTMF Message over the air 38
interface, refer to [5]. In the MS to network direction, the BS is required to generate the 39
DTMF tones and inject them into the 64 kbps PCM stream towards the MSC. In the 40
network to MS direction, the BS may extract the DTMF signal from the 64 kbps PCM 41
TIA-2001.3-C

Section 2 18

stream received from the MSC and generate the Send Burst DTMF Message to be 1
delivered over the air interface. 2
There are no call flows associated with this feature. 3
2.6 Support of Supplementary Services 4
Overview descriptions of these features are given in the following subsections. 5
2.6.1 Feature Activation and Deactivation 6
Feature Activation/Deactivation is invoked by the MS by sending either the Flash With 7
Information Message, Origination Message, or Enhanced Origination Message to the 8
network. The mobile subscriber activates, deactivates, registers, and erases a 9
supplementary service by entering a digit string at the MS which is sent to the MSC. The 10
MSC performs digit analysis on the dialed digits to determine that the subscriber requires 11
a supplementary service operation and processes the request. 12
Feature activation/deactivation in idle mode is accomplished by the sending of a string of 13
digits and end marks (*, #) that identify the feature to be activated/deactivated, along with 14
any additional PIN information, called party number, etc. in a mobile origination. The 15
MSC, after doing digit analysis, determines that the request is for feature 16
activation/deactivation, processes the request, and gives the MS an indication of the 17
acceptance or rejection of the request using normal call setup procedures. After taking 18
appropriate action (e.g., setting up a call and playing a tone or announcement), the MSC 19
or MS may initiate call clearing. No special action is required at the BS to process 20
supplementary service requests using this method. Refer to the message flow diagrams 21
for the mobile originated call setup (section 3.1.1) for an illustration of this message 22
handling. 23
Feature activation/deactivation while in a call is accomplished by sending a string of 24
digits and end marks (*, #) that identify the feature to be activated/deactivated, along with 25
any additional PIN information, called party number, etc. in an air interface Flash with 26
Information message or Enhanced Origination message from the MS to the BS and in a 27
Flash with Information message or Additional Notification message from the BS to the 28
MSC. Any response by the MSC to the BS is via in-band signals provided by the MSC. 29
Such actions are treated as activities that are independent of the Flash with Information 30
messages going in the other direction. 31
Refer to section 3.6.1 for the call flow associated with this feature. 32
2.6.2 Call Waiting 33
Call Waiting provides notification to a subscriber of an incoming call while the 34
subscriber is in the Conversation State. Subsequently, the subscriber can either answer or 35
ignore the incoming call. If the subscriber answers the second call, it may alternate 36
between the two calls. For additional description, refer to [21]. 37
The Call Waiting notification of the incoming call is sent as Flash with Information 38
messages to the MS from the MSC via the BS, or, alternatively, the Call Waiting 39
notification is sent as an in-band tone between the MS and the MSC. 40
TIA-2001.3-C

19 Section 2

The second call (Call Waiting call) is answered by the MS by sending a Flash with 1
Information message to the MSC via the BS. The MS may alternate between the two calls 2
by sending Flash with Information messages to the MSC via the BS. 3
This feature is activated according to Feature Activation described in section 2.6.1. 4
Call flows associated with this feature can be found in section 3.6.2. 5
2.6.3 Three Way Calling 6
Three Way Calling provides the controlling subscriber the capability of adding a third 7
party to an established two-party call, so that all three parties may communicate in a call. 8
If either of the two non-controlling parties in an established three-party call disconnects, 9
the remaining party is reconnected to the controlling subscriber as a normal two-party 10
call. If the controlling subscriber of a three-party call disconnects, all other parties are 11
released. 12
An MS requests a three-way calling by sending a Flash with Information message to the 13
BS, which forwards this request to the MSC. This message puts the remote party on hold. 14
This request may include the address of the third party that is to be included in the three- 15
party call. If the initial Flash with Information message does not included the address of 16
the third party, the MS sends a subsequent Flash with Information containing the third 17
party address. 18
A call is established to the third party address. When the call is answered, the MS 19
establishes the three-way call by sending a Flash with Information to the BS, which 20
forwards it to the MSC, which places all three parties in a conference call. 21
For further description, refer to [21]. 22
2.6.4 Message Waiting Notification 24
Message Waiting Notification (MWN) informs a subscriber when a voice message is 25
available for retrieval. The MWN may use different types of indications to inform a 26
subscriber of an unretrieved voice message. 27
The Feature Notification message is used to deliver a Message Waiting Indication (MWI) 28
to the MS while it is idle. There is a possible race condition when the Feature 29
Notification message is sent while an MS is originating a call. If this occurs, the message 30
waiting indication may not be successfully delivered. It is recommended that the MSC 31
request an acknowledgment with the Feature Notification, and resend the MWI 32
information on the traffic channel, if necessary. 33
The Flash with Information message is used to deliver a Message Waiting Indication 34
while the MS is on a traffic channel, i.e., after an Assignment Complete message has 35
been received at the MSC. 36
Refer to section 3.6.4 for the call flows associated with this feature. 38
TIA-2001.3-C

Section 2 20

2.6.5 Call Barring 1
Call Barring provides the possibility to bar a subscriber from originating calls and 2
receiving calls. This may exclude emergency numbers. The reason a subscriber is barred 3
from originating or receiving calls is defined as an implementation issue. Call Barring 4
can be of the following types: 5
Origination denied. 6
Termination denied. 7
Local calls only. 8
Selected leading digits of directory number. 9
Selected leading digits of directory number and local calls only. 10
National long distance (including local calls and may include neighboring counties). 11
International calls (includes national long distance and local calls). 12
Single Directory Number (only number allowed). 13
Call Barring Incoming is transparent to the IOS interfaces. 14
Call Barring Outgoing requires the MSC to assign a channel to the originating MS, apply 15
call treatment (e.g. announcement to mobile subscriber on the traffic channel) and then 16
clear the call after treatment has been applied. Note that the subscriber may also initiate 17
call clearing upon hearing the announcement or other appropriate treatment (e.g., tones). 18
2.6.6 Calling Number ID Presentation / Restriction 20
Calling Number ID Presentation provides the number identification of the calling party to 21
the called subscriber. 22
Calling Number ID Restriction restricts presentation of the subscribers Calling Number 23
Identification to the called party. The Calling Number ID Restriction may be made 24
permanently or temporary on the subscribers request. 25
The following subsections describe the support for: 26
Calling Number Identification Presentation (CNIP). 27
Calling Number Identification Restriction (CNIR). 28
2.6.6.1 CNIR for Mobile Originated Calls 29
For CNIR, the calling party can request CNIR on a per call basis by including the feature 30
code before the Called Party Number digits in the Called Party BCD Number or Called 31
Party ASCII Number in the CM Service Request message. 32
2.6.6.2 CNIP/CNIR for Mobile Terminated Calls 33
There are two types of CNIP/CNIR supported: 34
1. If the MS is idle, for mobile terminated calls, the CNIP/CNIR information is sent in 35
the Assignment Request message. The call flows for this feature are identical to the 36
call flows for a mobile terminated call, refer to section 3.1.2. 37
TIA-2001.3-C

21 Section 2

2. If the MS user subscribes to the Call Waiting (CW) feature and is engaged in a call, 1
the CNIP/CNIR information is sent in the Flash with Information message. The call 2
flow for this feature is identical to the call flow for Call Waiting, refer to section 3
3.6.2. 4
The MSC codes the presentation restriction information as presentation allowed when 5
providing text, e.g., Unknown Number or Private Number, corresponding to the 6
cases when the number is not available or is presentation restricted. When the screening 7
indicator is not provided or can not be determined, a default value of network 8
provided is recommended. 9
2.6.7 Distinctive Ringing 10
Distinctive Ringing provides the MS with the possibility to receive information from the 11
MSC to create a distinctive ring signal. 12
The A1 interface uses the Signal element or the MS Information Records element to carry 13
information to the MS concerning the specific ringing pattern to be used. Refer to [14]. 14
The call flows for this feature are identical to the call flows for a mobile terminated call, 15
refer to section 3.1.2. 16
2.6.8 Answer Holding 17
Answer Holding (AH) provides a called subscriber the capability to answer the call, but 18
selectively delay the conversation (e.g., calls in the alerting or Call Waiting State). The 19
incoming call is provided an appropriate network announcement to notify the calling 20
party to please hold. 21
AH is also applicable to incoming calls being delivered to called AH authorized 22
subscribers as Call Waiting (CW) calls. 23
The MS uses the Flash with Information message to invoke Answer Holding in the 25
Alerting and Call Waiting State. The Flash with Information message is also used to 26
toggle between two calls, one of which in Answer Holding State, while in Call Waiting 27
State. 28
Call flows for Answer Holding are shown in section 3.6.8. 29
2.6.9 User Selective Call Forwarding 30
User Selective Call Forwarding provides a called subscriber the capability to selectively 31
redirect unanswered, incoming calls to an alternate destination (e.g., to a voice mail 32
system, to a network registered Directory Number, or to a Directory Number stored in the 33
MS). User Selective Call Forwarding is applicable both to calls being offered to a 34
subscriber via alerting and to calls being offered to a subscriber via Call Waiting 35
Notification. 36
This feature is activated according to the Feature Activation described in section 2.6.1: 37
The Forward-To-Number registration is handled by the regular Feature Activation 38
feature. 39
TIA-2001.3-C

Section 2 22

When an MS is in the alerting state, or in the Conversation State and receiving a Call 1
Waiting Notification, the MS sends a Flash with Information to invoke this feature. 2
Call flows for User Selective Call Forwarding are shown in section 3.6.9. 3
2.7 Mobile Registration 4
Mobile registration is a process whereby MS characteristics such as location or status are 5
provided to the network. Registration may be initiated by the MS, by the network, or 6
implied during an MS access. 7
The MSC may infer registration information based on an MSs system access. This form 8
of registration is transparent to the BS and the MS, and requires no additional message 9
passing over the A1 interface. 10
The MS may initiate registration for a number of reasons. The types of registration 11
performed are enabled and controlled through parameters transmitted by the BS on the 12
forward (downlink) control channels. Selection of control channel parameters and 13
enabling of specific registration types are beyond the scope of this specification. 14
The network may initiate an ordered registration procedure. The ordered registration 15
procedure allows a BS to request the MS to register. 16
Network may autonomously register an MS (refer to [32]) and direct the BS to notify the 17
MS that the network has registered it. 18
2.8 Global Emergency Call Origination 20
The phone number required to access a Public Safety Answering Point (emergency 21
assistance) in a given geographic area may not be known to the user. In fact, there may be 22
different access numbers for difference agencies (e.g., police, fire, medical). 23
Global Emergency Call Origination is a mechanism whereby the user initiates an 24
emergency service call via some vendor specific means. The MS Origination Message 25
includes an indication that this is an emergency service request and the network handles 26
the call accordingly. 27
The MS Origination Message may include user dialed digits. The network may use the 28
dialed digits, if present, to determine more specific information regarding the type of 29
emergency support requested. 30
Normal mobile originated call setup call flows apply to this feature; refer to section 3.1.1. 31
2.9 E911 Phase 1 and Phase 2 32
For E911 phase 1, the CM Service Request message provides the location of the E911 33
MS and also provides the MSID (IMSI) of the MS to be used for the callback number. 34
For E911 phase 2, this standard supports delivery of the mobile location data from the 35
network to a Position Determining Entity (PDE). Procedures and protocols used on the 36
interface between the PDE and other network entities are outside the scope of this 37
standard. Further, this standard assumes that all involved elements (i.e. MS, BS, MSC 38
TIA-2001.3-C

23 Section 2

and PDE) conform to [26]. The PDE functionality resides in the core network. The MSC 1
conveys BS-supplied, position related information for an MS to the PDE.. 2
Call back feature is transparently supported by the normal call establishment procedures. 3
Refer to section 3.13 for call flows associated for this feature. 4
2.10 Short Message Service 5
The Short Message Service (SMS) provides for the transfer of short messages between an 6
application residing on an MS and an application within the network, e.g., at a Message 7
Center (MC). The MSC and BS provide a conduit for these short messages. Other 8
network procedures carried out by entities providing an SMS, are beyond the scope of 9
this standard (refer to [9]). 10
Three types of basic short messaging are supported: mobile originated point-to-point, 11
mobile terminated point-to-point, and broadcast. Both mobile originated and mobile 12
terminated point-to-point short messaging may require that messages be exchanged in 13
both directions on the air interface. 14
Short messages can be exchanged between the MS and BS on both the control and traffic 15
channels. Thus, an active MS is able to send and receive short messages at any time. The 16
maximum number of short message characters that can be handled varies with the air 17
interface and teleservice type employed. Each short message shall be carried within a 18
single message on the A1 interface. No provision is made for segmentation and 19
reassembly of short messages. 20
The Short Message Service is divided into a number of protocol layers: the SMS 21
teleservice layer, the SMS transport layer, and the SMS relay layer (refer to [20]). The 22
relay layer may sit on top of other air interface layers. Not all air interfaces may support 23
the full range of SMS capabilities and layers. All of these layers are transparent to the A1 24
interface, and are carried as part of the SMS user part element in the A1 interface 25
messages. 26
For point-to-point delivery, the MSC can request that the BS report that a Layer 2 Ack 27
was received from the MS. This indicates that the MS received the short message. In 28
addition, both the transport and teleservice layers may generate acknowledgments (refer 29
to [20]) but these acknowledgments are transparent to the A1 interface. 30
The scope of the requirements and specifications outlined in this document are limited to 31
the A1 interface, as defined in the Network Reference Model ([28]). Descriptions of 32
operations at other interfaces are included for information only. 33
2.11 Priority Access and Channel Assignment (PACA) 35
PACA (Priority Access Channel Assignment) allows a user to have priority access to 36
traffic channels on call origination. When the traffic channel is not available, the BS can 37
queue the MS and update the queue position subsequently. When a traffic channel 38
becomes available, the BS serves the MS based on first come first served within a 39
priority. 40
The subscriber has two options for invocation of PACA: Permanent or Demand (refer to 41
[21]). In the permanent option, the feature is always available and is used automatically 42
TIA-2001.3-C

Section 2 24

whenever the user attempts to originate a call. In the demand option, the feature is 1
available only on request via dialing the feature code before the telephone number at the 2
time of origination for that specific call. 3
By sending the PACA Message over the air-interface, the BS can notify the user that the 4
call is queued, the queue position is updated, or the PACA call should be re-originated. 5
When the PACA call is enabled, the MS shall operate in non-slotted mode. If the MS is 6
directed by the user to cancel the queued PACA call, the MS shall send the PACA Cancel 7
Message. 8
Two conditions may occur on a call origination with PACA service. In the first condition, 9
the BS can not determine the availability of radio resources before sending the CM 10
Service Request to the MSC. Thus, the BS sends the Radio and Environment Resources 11
Information element (without indicating the availability of its radio resources) in the CM 12
Service Request message to the MSC. Refer to [14] for further explanations of this 13
message and information element. In this case, the origination call flow shown in section 14
3.1.1.1 is followed. 15
In the second case, the BS determines that radio resources are not available before 16
sending the CM Service Request. The BS sends an indication in the CM Service Request 17
message to notify the MSC that the radio resources are unavailable. In this case, the 18
origination call flow shown in section 3.11.1.1 is followed. 19
The PACA Service feature is defined based on the following principles: 20
The PACA queue is maintained and managed at the BS. 21
The MSC assigns the priority level and time of a PACA eligible call and informs the 22
BS in the Assignment Request or PACA Command message. 23
The MSC manages the timestamp information for the PACA call and assists in 24
maintaining the priority while the MS is roaming within the system by passing the 25
timestamp information to the new BS in the Assignment Request or PACA Update 26
message. 27
The BS may keep the MS informed of the updated queue position. 28
The BS informs the MSC in case of re-origination of a PACA call using the CM 29
Service Request message. 30
The PACA call can be canceled implicitly or explicitly by the MS, the BS or the 31
MSC. 32
2.12 Over-The-Air Service Provisioning (OTASP) and Over The Air 34
Parameter Administration (OTAPA) 35
Overviews and descriptions of these features are given in the following subsections. 36
2.12.1 OTASP Support 37
Normal call setup procedures for voice calls are used to establish an OTASP call. The 38
mechanism for transporting OTASP data messages over the air interface is defined in 39
[22]. The processing of OTASP data messages at the MSC or BS is the responsibility of 40
the vendors. OTASP data messages are transported on the A1 interface via the ADDS 41
Deliver/Ack messages. The MSC interface to the network is addressed in [24]. 42
TIA-2001.3-C

25 Section 2

2.12.2 OTAPA Support 2
OTAPA is supported in this specification by the ADDS Deliver/Ack set of messages. A 3
specific Service Option (18 or 19) is required to set up the call. No specific messages or 4
information are required beyond the messages necessary to set up a mobile terminated 5
call and to transfer ADDS messages. The only requirement for the BS is to provide 6
interworking between the air interface and the A1 interface for these messages. The use 7
of these messages by the MS and the MSC is beyond the scope of this specification. 8
2.13 Mobile Position Determination 9
This section includes descriptions of how to support determination of the MSs position. 10
Various approaches are possible. The supported approaches are discussed in the 11
following subsections. 12
2.13.1 Support of Position Location Service (MS PDE Approach) 13
The Position Location Service provides for the transfer of Position Location Data 14
between an application residing on an MS and an application within the network (i.e. 15
Position Determining Entity (PDE)). Normal call setup procedures for voice calls are 16
used to establish a Position Location Service call. The mechanism for transporting 17
Position Location Data (PLD) over the air interface is defined in [22]. Other network 18
procedures carried out by entities providing PLD are beyond the scope of this standard. 19
Position Location Data is transferred between the MSC and BS using ADDS procedures 20
and between the BS and the MS on both the control and traffic channels. Normally the 21
ADDS messages are used to carry application data between the MS and the MSC which 22
is transparent to the BS; however, for PLD applications a BS may trigger the position 23
determination process. Thus, an active MS is able to send and receive Position Location 24
Data messages at any time. The Position Location Data and associated messaging is 25
defined in [26]. This data is transparent to the A1 interface, and is carried as part of the 26
ADDS User Part element in the A1 interface messages. 27
Refer to section 3.13.1 for call flows associated with this feature. 28
2.13.2 Software Calculation Position Determination (BS-MSC 29
Approach) 30
Through the use of software calculation techniques, a network based position 31
determination process can take advantage of the radio interface parameters and 32
measurements to determine the location of an MS that is on a traffic channel. These 33
messages support both network based and mobile-assisted position determination. The 34
MSC requests certain measurements and parameters from the BS, and the BS provides 35
those measurements in a response message. Calculations then take place to determine the 36
location of the MS. 37
For PLD applications that have a base station based position determination process, the 38
BS may return the Geographic Location IE in the Radio Measurements for Position 39
Response message. 40
TIA-2001.3-C

Section 2 26

2.14 User Zone 1
The concept of User Zones is important to the operation of CDMA Tiered Services; refer 2
to [5]. It is via User Zones that the network offers custom services based upon the MS 3
location. 4
User Zones are associated with a set of features and services, plus a geographic area in 5
which the User Zone features/services are made available to the customers that have 6
subscribed to that User Zone. The boundary of the User Zone geographic area may be 7
established based on the coverage area of a BS, or it may be established independent of 8
RF topology. Refer to [5] for further details on User Zones. 9
The MS User Zone may be indicated at registration time in the Location Updating 10
Request message, or at call setup in the CM Service Request or Paging Response 11
messages sent by the BS to the MSC. The User Zone may also be changed during the call 12
by using the User Zone Update Request message. User Zone Reject and User Zone 13
Update messages are sent by the MSC to the BS to reject or change the MSs active User 14
Zone. 15
2.15 ISDN Interworking 17
ISDN interworking service provides interoperable communications between an MS and 18
an existing ISDN subscriber terminal operating in the public ISDN as well as between 19
MSs. The procedures and interfaces are specified in [23]. 20
For all calls supporting ISDN interworking services, the MSC shall provide a function of 21
protocol conversion between upper layer signaling over the A1 interface and ISDN 22
signaling, and the SDU shall construct Unrestricted Digital Information (UDI) data/RLP 23
frames from RLP frames/UDI data respectively. 24
Refer to section 3.15 for more details on this feature. 25
2.16 Circuit Data Calls 26
Circuit Data calls include Asynchronous Data and Group-3 Fax services. These services 27
allow the MS to send and receive asynchronous data and facsimiles. Refer to [14] for 28
information on valid service options. The procedures and interfaces are specified by [23]. 29
For all calls supporting circuit-oriented data services, an Interworking Function (IWF) 30
exists that interfaces between the transmission of the data in the fixed network and the 31
transmission of the data over the air interface. For this standard, the IWF for circuit- 32
oriented data calls is considered to be located at the MSC. The A5 interface connects the 33
SDU to the IWF. The A5 interface carries a duplex stream of user traffic between the 34
MSC and SDU. Once an IWF has been allocated for a circuit-oriented data call, it shall 35
remain anchored for the duration of the call. 36
According to [23], RLP is terminated in the SDU. The A5 interface in this case carries 37
the output of the RLP function specified in [23] from the SDU function to the IWF. The 38
protocol currently defined in this standard for the A5 interface is ISLP. Refer to [25]. 39
Both mobile origination and mobile termination applications of this service shall be 40
Data Only. 41
TIA-2001.3-C

27 Section 2

Normal call origination, call termination, and call clearing procedures apply. 1
Call flows associated with this feature are described in sections 3.1.1, 3.1.2, and 3.2. 2
This standard supports handoffs for Asynchronous Data and Group 3 fax calls as 3
indicated in section 1.1. 4
2.17 3G Packet Data Calls 5
This section applies to packet data calls only. It is assumed that no circuit switched 6
services are present. For packet data interaction with circuit switched services, refer to 7
section 2.18, Concurrent Services. 8
Packet data calls allow users to exchange data between the MS and an IP data network. 9
This section describes IOS support for 3G packet data services. These services are 10
primarily identified with service option 33, as defined in [23], or service options 60 and 11
61, as defined in [31]. Other service options also may be used (refer to [14]) for 12
intergeneration handoff (handoff between systems supporting packet data services based 13
on ANSI/TIA/EIA/95-B and systems supporting packet data service based on 14
cdma2000
). Intergeneration handoffs are described in section 2.19.5. 15

For all calls supporting packet data services, a Packet Data Serving Node (PDSN) exists 16
that interfaces between the transmission of the data in the packet data network and the 17
transmission of the data (via the Radio Access Network (RAN)) over the air interface. 18
The PDSN interfaces to the BS through a Packet Control Function (PCF), which may or 19
may not be co-located with the BS. 20
In a 3G packet data call, the MS may initialize one or several packet data service 21
instances. Each service instance is a separate connection between the MS and the PDSN, 22
used to exchange user data. Each packet data service instance is associated with a packet 23
data service option and identified by a Service Reference Identifier (SR_ID). The first 24
service instance established by the MS is of service option type 33. The states of a 25
packet data service instance associated with service option 33 are defined in [23]. For the 26
purposes of this standard, distinction is made between the Null/Inactive State, the 27
Active/Connected State and the Dormant State of packet data service instances. Voice- 28
over-IP service instances (service option 60 and 61) do not have a Dormant State, only 29
Null/Inactive State and Active/Connected State. 30
When the MS initializes the first packet data service instance, a packet data session is 31
started. Associated with the packet data session is a PPP session. For every packet data 32
session, there is at least one service instance, referred to as the main service instance, 33
which is used to negotiate the PPP session. Other service instances established 34
subsequently, if any, are referred to as auxiliary service instances and may be of service 35
option type 33, 60 or 61. The packet data session ends when all service instances are 36
released. 37
For purposes of the protocol of this standard, there are three packet data session states: 38
Active/Connected, Dormant, and Null/Inactive. In the Active/Connected State, at least 39
one service instance is active and a physical traffic channel exists between the MS and 40
the BS, and either side may send data on the active service instances. In the Dormant 41
State, all service instances are dormant and no physical traffic channel exists between the 42
MS and the BS, but the PPP link between the MS and the PDSN is maintained. In the 43
Null/Inactive State, all service instances are in the Inactive/Null State and there is no 44
traffic channel between the MS and the BS and no PPP link between the MS and the 45
TIA-2001.3-C

Section 2 28

PDSN. Figure 2.17-1 shows the possible transitions between the states of a packet data 1
session. 2
Active /
Connected
State
Dormant
State
Null/Inactive
State
3
Figure 2.17-1 Packet Data Session State Transitions 4
The transition of the packet data session from the Null/Inactive State to the Dormant 5
State entails the transition of one service instance from the Null/Inactive State to the 6
Dormant State.. The transition has been added in anticipation that a transition from the 7
Null/Inactive State to the Dormant State will be defined for SO 33 in the next revision of 8
[23]. The MS may cross packet zone boundaries while the packet data session is in the 9
Dormant State. This is referred to as dormant handoff. The dormant handoff procedures 10
specified in this standard allow the A10 connections between the PCF and PDSN to be 11
moved (or established) for the MS when it enters a new packet zone. 12
The packet data session may transition to Active State (e.g., if the user has data to send) 13
at any time. This transition is referred to as Re-Activation from Dormant. 14
Packet data is typically transmitted over the air on dedicated traffic channels. 15
Mechanisms also exist for transmitting data over the common channels. Short Data Burst 16
is a part of the 3G Packet Data feature that enables small amounts of data to be 17
transmitted over the common channels. Common Channel Packet Data is a mode of 3G 18
Packet Data where all data is transmitted using Short Data Bursts. 19
An A1 connection is maintained during the Active / Connected State of the packet data 20
session and released during transition to Dormant or Null/Inactive State of the packet 21
data session. An A8 connection is maintained for each active packet data service instance 22
and released when the service instance transitions to the Dormant or Null State. The BS 23
may maintain a packet data inactivity timer for each packet data service instance 24
associated with a service option that supports dormancy. An A10 connection is 25
maintained for each service instance during the Active/Connected and the Dormant State 26
of the service instance. Each A10 connection is assigned a separate Key to be used in the 27
GRE header and also a separate lifetime; refer to [12]. 28
Refer to section 3.17 and accompanying subsections for call flows associated with packet 29
data. 30
2.17.1 Packet Data Assumptions 31
The following assumptions are made regarding packet data. 32
1. Each PCF corresponds to a packet zone, each PCF is uniquely identified by the 33
Current Access Network Identifiers (CANID) and every PCF knows its CANID 34
value. The MS initiates a dormant handoff when it moves into a new packet zone and 35
TIA-2001.3-C

29 Section 2

it determines that it needs to notify the packet data network. Refer to [23]. No 1
dormancy knowledge is required by the PDSN. 2
2. The set of PDSNs that a PCF may connect to is known at the PCF. 3
3. The PDSN selection algorithm specified in section 3.17.3 is used for initial PDSN 4
assignment and PDSN reselection. 5
4. When connecting to a PDSN during an active session handoff or during dormant 6
handoff, if the target PDSN recognizes the session, it does not require a restart of 7
PPP. 8
5. Links between PCFs and PDSNs support both the signaling and traffic channels. 9
6. The signaling channels support call connects, disconnects, as well as signaling for 10
QoS, accounting information etc. 11
7. The traffic channels support in-sequence delivery of data payload. 12
8. A PCF initiates an A10 connection, but either the PCF or the PDSN may drop it. 13
9. The A8/A9 and A10/A11 interfaces are assumed to be supported on a private IP 14
network for security considerations. 15
10. When IP is used as the network layer for the A8 or A10 bearer, standard IP QoS 16
mechanisms may be employed. 17
11. The BS contacts the MSC so that the MS (IMSI/ESN) can be authenticated and the 18
access to the PDSN can be authorized during traffic channel setup. 19
12. The packet core network authenticates the user (NAI) and authorizes each packet 20
data service instance. 21
13. When the MS is on the traffic channel, the BS contacts the MSC when the packet 22
data session is not active and the MS sends an origination message for a packet data 23
service instance. This is done so that the use of concurrent services can be 24
authorized. 25
14. When the MS is on the traffic channel, the BS does not contact the MSC when the 26
packet data session is active and the MS sends an origination message for an 27
additional packet data service instance. This is because the MSC needs to be aware 28
only of the state of the packet data session and not the state of each packet data 29
service instance. 30
2.17.2 Previous and Current Access Network Identifiers 31
(PANID/CANID) 32
An Access Network Identifier (ANID) consists of a packet zone identifier 33
(PACKET_ZONE_ID, or PZID), a system identifier (SID), and a network identifier 34
(NID). The ANID defines a packet zone. Each PCF is uniquely identified by an ANID 35
and knows its ANID value. The ANID of the current PCF (PCF to which the MS is 36
currently connected to) is referred to as the CANID. The ANID of the PCF that the MS 37
was previously connected to is referred to as the PANID. The PDSN uses the PANID and 38
CANID to determine if an inter-PDSN handback has occurred. 39
When an MS moves into a new packet zone and determines that it needs to notify the 40
packet data network, it initiates a dormant mode handoff (refer to [23]). The MS sends an 41
origination message which may include ANID information. The ANID information may 42
include the previous Packet Zone (PREV_PZID), System Identification (PREV_SID) or 43
Network Identification (PREV_NID) parameters (or any combination of these fields), 44
which the BS uses to determine the ANID of the previous PCF (PANID). The BS sends 45
TIA-2001.3-C

Section 2 30

the PANID to the PCF if the MS sent any ANID information to the BS. The PCF sets the 1
PANID to zero if no ANID information was received from the BS. The PCF sets the 2
CANID to its own ANID and passes the PANID and CANID to the PDSN. 3
In a hard handoff, the ANID of the source PCF is sent from the source BS to the target 4
PCF via the MSC and the target BS. The target PCF forwards the received ANID as the 5
PANID together with its own ANID as the CANID to the PDSN. 6
Refer to section 3.17.2 for more details. 7
2.17.3 PDSN Selection Algorithm 8
The PDSN selection algorithm specified in this standard shall be used for initial PDSN 9
selection of the first service instance and PDSN re-selection initiated by dormant handoff. 10
This algorithm increases the likelihood that the MS will be re-connected to the same 11
PDSN upon dormant handoff, thereby avoiding possible PPP and MIP re-establishment 12
on a new PDSN. The algorithm is based upon the MSs IMSI, which is assumed to be 13
known at the PCF at the time of A10 establishment. 14
Refer to section 3.17.3 for details of this algorithm. 15
2.17.4 A8/A9 Interface Descriptions 16
The A9 interface provides for signaling to initiate establishment and release of the A8 17
connection for packet data services. The A8 interface provides the user traffic path 18
between the BS and the PCF. A9 signaling is also used to provide new or updated session 19
parameters to the BS, notify the PCF of successful handoff completions, pass Accounting 20
Parameters to the PCF, and to acknowledge A9 messages as required. 21
2.17.5 A10/A11 Interface Descriptions 23
The A11 interface provides for signaling to request establishment, refresh, update and 24
release of an A10 connection for packet data services. The A10 interface provides the 25
user traffic path between the PCF and the PDSN. When an A10 connection is active, A11 26
signaling is also used to provide new or updated accounting parameters between the PCF 27
and the PDSN, forward airlink records to the PDSN and to acknowledge A11 messages 28
as required. 29
2.17.6 Version Interoperability Control 31
The architectural assumptions for the A10-A11 interface version control scheme for a 32
communicating PDSN-PCF pair are: 33
The architectural principle in [41] on which the A10-A11 interface is based shall not 34
be violated. 35
The latest IOS version shall be backward compatible with older supported IOS 36
versions. 37
TIA-2001.3-C

31 Section 2

The structure of the mandatory elements shall not change in revisions of the IOS 1
standard. Version control on the A10/A11 interface is accomplished by the forward 2
compatibility guidelines specified in [17]. 3
Refer to section 3.17.6.1 for a description of the call flow demonstrating how version 4
control is implemented on the A8/A9 interface. 5
2.17.7 Short Data Bursts 6
cdma2000
defines short data bursts as messages or data associated with a data service 7
that consist of a small number of frames that are transmitted to or from an MS with a 8
dormant packet data service instance. Short Data Bursts are not supported across packet 9
zone boundaries. Data may be lost if an MS moves to a new packet zone shortly after 10
transmitting a Short Data Burst (SDB). Mobile terminated data may also be lost if a short 11
data burst is sent to the BS/PCF from the PDSN, but the MS moves to a new packet zone 12
before the data is transmitted to the MS. The BS shall ensure that multiple mobile 13
originated short data bursts from the same MS shall be sent to the PCF in the order in 14
which they were received from the MS. 15
Refer to section 3.17.7 for call flows describing this feature. 16
2.17.8 Common Channel Packet Data (CCPD) 17
The Common Channel Packet Data (CCPD) feature supports packet data call setup, 18
dormant mode handoffs, and data transmission using Short Data Bursts over Common 19
Channels. This is referred to as CCPD Mode. Short Data Bursts are specified in [23]. 20
A CCPD capable MS is a cdma2000
MS that supports CCPD Mode. A CCPD capable 21

MS may request CCPD Mode from the network when the amount of data to be 22
transmitted is expected to be small and infrequent. The BS may deny CCPD Mode to a 23
CCPD capable MS by either rejecting the call or allocating a traffic channel to it. 24
A CCPD capable MS requests Common Channel Packet Data (CCPD) Service from the 25
network by setting the SDB_DESIRED_ONLY bit in the Origination Message to 1. If the 26
BS agrees to support the MSs request for CCPD Mode, PPP connection setup and MIP 27
registration (if required) are performed over common channels using Short Data Bursts. 28
An A8 bearer connection is not required. Upon successful completion of these 29
procedures, the packet data service instance transitions from the Null to the Dormant 30
State. 31
A CCPD capable MS originating a CCPD Mode call setup or CCPD Mode dormant mode 32
handoff is authenticated by the network at the start of the procedure. A CCPD capable 33
MS may be authenticated again upon subsequent Short Data Burst transmissions in 34
support of the CCPD Mode call setup or CCPD Mode dormant mode handoff procedures. 35
The BS may initiate CCPD Mode to support a dormant mode handoff, even though a 36
CCPD capable MS may not have explicitly requested CCPD Mode from the network. 37
The BS responds to the MSs Origination Message with a Release Order rather than 38
assigning a traffic channel for the call. Subsequent communication between the MS and 39
the network occurs using Short Data Bursts over Common Channels. 40
For call flows associated with this feature, refer to section 3.17.8. 41
TIA-2001.3-C

Section 2 32

2.17.9 Packet Data Security Considerations 1
The PCF-PDSN interface is designed for use over a protected, private network between 2
the PCFs and the PDSNs. Pre-arranged security associations, in the style of IP Mobility 3
Support ([41]) are assumed to exist among every PCF and PDSN pair that forms an A10 4
connection. 5
Several potential vulnerabilities exist in the absence of such security associations. If an 6
A10 connection is accessible to an attacker, the GRE encapsulated user traffic may be 7
intercepted and/or spoofed if end-to-end security mechanisms are not in place. Such end- 8
to-end security issues are outside the scope of this standard. However, all A11 signaling 9
messages are authenticated to prevent an A10 connection setup and tear down by an 10
unauthorized node. Mobile-Home Authentication Extension and Registration Update 11
Authentication Extension provide a means of protecting the A11 signaling messages. If 12
registration messages are not authenticated, a denial-of-service attack is possible. If a 13
PCF sends an A11-Registration Request message to the PDSN with a spoofed Session 14
Specific Extension, the PDSN would then send an explicit tunnel tear down to the 15
previous PCF, causing user traffic to be misdirected to the new PCF. This would cause a 16
loss of service and possibly interception of traffic, depending on what other security 17
measures are in place. 18
The A8/A9 interfaces are assumed to be supported on a private IP network for security 19
considerations. 20
For details on packet data security, refer to section 3.17.9. 21
2.17.10 Support for AAA-Based Radio Network Packet Data Inactivity 22
Timer (RN-PDIT) 23
Each packet data service instance is associated with a packet data inactivity timer, which 24
the BS uses to limit the time that a service instance may be active while no data is being 25
sent to or received from the MS. When the inactivity timer expires, the BS transitions the 26
service instance to the Dormant State. Refer to [23] for further details. This feature allows 27
the value of the inactivity timer associated with a service instance to be determined by the 28
packet data network and stored at the Authentication, Authorization, and Accounting 29
(AAA) infrastructure. For example, RN-PDIT may be based on the realm(s) accessed 30
through the service instance, the application(s) using the service instance, QoS of the 31
service instance, or other parameters. 32
A pre-provisioned default inactivity timer value stored at the BS is used until an 33
inactivity timer value associated with the service instance is passed from the PDSN to the 34
BS. The inactivity timer value passed from the PDSN to the BS may be overwritten by 35
the BS due to RAN resource considerations. 36
How the inactivity timer value is determined in the packet data network is outside the 37
scope of this standard. This standard only specifies the procedure for passing this 38
parameter from the PDSN to the BS. The transfer of the inactivity timer value from the 39
PDSN to the BS is supported by the PDSN Initiated Packet Data Session Update 40
procedure (refer to section 3.17.10). 41
2.17.11 Support for Always-on Mobile Stations 42
The packet data network supports Always-on MSs. The PDSN provides an indication of 43
an Always-on MS to the PCF. 44
TIA-2001.3-C

33 Section 2

Paging of an MS occurs as part of network initiated re-activation from dormant when the 1
MS is not on a traffic channel. No response from an Always-on MS is interpreted as the 2
Always-on MS being temporarily out of radio coverage; this event should not trigger 3
release by the PCF of dormant packet data service instances of Always-on MSs. 4
Refer to section 3.17.10 for call flows associated with the transfer of the Always-on 5
information from the PDSN to the PCF. 6
2.18 Concurrent Services (Circuit Voice and Packet Data) 7
Concurrent service provides support for one circuit voice and one packet data session 8
(which may be comprised of one or more packet data service instances) simultaneously. 9
Other service combinations may be supported by a future release. 10
In addition, refer to section 3.2 when clearing all service instances. 12
2.19 Handoff 13
14
2.19.1 Handoff via MSC 15
Handoffs (intra-BS, inter-BS and inter-MSC) can occur for one of several reasons 16
including radio propagation, traffic distribution, OAM&P activity, and equipment failure. 17
Refer to [11] for handoff definitions. Refer also to sections 3.17.4 and 3.17.5 for packet 18
data scenarios. 19
Intra-BS Handoff: An intra-BS handoff is a handoff performed under the domain of one 20
BS. As such, the MSC is not involved in the execution of the handoff. Once an intra-BS 21
hard handoff is successfully completed, the BS shall inform the MSC if the old cell is no 22
longer involved in the call. 23
Inter-BS Handoff: An inter-BS handoff is attempted whenever a potential target may be 24
outside of the domain of the source BS. The MSC may use inter-BS hard handoff 25
procedures to perform handoffs where the source BS and target BS are the same. 26
Inter-MSC Handoff: An inter-MSC handoff is attempted when the source BS and the 27
target BS are controlled by different MSCs. Refer to [32]. 28
Refer to section 3.19.1 for more information on handoffs. 29
2.19.2 Handoff via Direct BS-to-BS Signaling 30
Efficient inter-BS soft handoff is supported via direct BS-to-BS signaling and traffic 31
connections between base stations. 32
The A3 interface, composed of signaling and user traffic subchannels, provides the ability 33
to establish and remove A3 traffic connections. The A3 interface also provides support 34
for operational procedures, such as turning on/off voice privacy or changing the service 35
configuration of a call. 36
TIA-2001.3-C

Section 2 34

The A7 interface provides direct BS-to-BS signaling for the support of efficient soft 1
handoff. Only a call release procedure should interrupt any handoff procedure. Multiple 2
concurrent A7 Handoff Add procedures are prohibited for the same physical channel on 3
the same call. Multiple concurrent A7 Handoff Drop procedures for the same physical 4
channel on the same call are prohibited. 5
Refer to section 3.19.2 for more information on BS-to-BS handoff. 6
2.19.3 Inter-BS Hard Handoff into Intra-BS Soft Handoff 7
Hard handoff into (i.e. coincident with) soft handoff can increase the probability of 8
successful handoff of a call. This feature allows the source BS to specify a list of target 9
cells for the handoff by including these cells in the Cell Identifier List in the Handoff 10
Required message sent to the MSC. The cell list is forwarded by the MSC to the target 11
BS in the Handoff Request message. The target BS decides which cells are included in 12
the handoff and allocates resources on these cells. The target BS then indicates these cells 13
to the MSC in the Cell Identifier List of the Handoff Request Ack message, and this cell 14
list is forwarded to the source BS in the Handoff Command message. The source BS 15
directs the MS to these cells using a handoff direction message. It is the target BSs 16
responsibility to set up the soft handoff. Refer to section 3.19.3.1.1 for a call flow related 17
to this feature. 18
2.19.4 Fast Handoff 19
Fast handoff provides a low interruption packet data service hard handoff mechanism by: 20
1. Maintaining an MSs PPP session as long as the MS has an active packet data 21
session, and 22
2. Transmitting the forward data stream to the source and target PCFs during the 23
handoff procedures (bicasting). 24
The general configuration and nomenclature for fast handoff are shown in Figure 2.19.4- 25
1. Note that the general configuration illustrates the scenario where a prior fast handoff 26
has taken place during the current Active State of the MS from the anchor PDSN to the 27
source PDSN and a P-P connection exists between the source and the anchor PDSNs. 28

Source
PDSN
A10/A11
Anchor
PDSN
MS
A10/A11 A10/A11
Target
PDSN
A10/A11
Target
BS/PCF
Anchor PDSN
Address
Source PDSN
Address
Anchor P-P
Address
Source
BS/PCF
P-P Connection
29
Figure 2.19.4-1 General Configuration Prior to a Fast Handoff 30
The anchor PDSN is defined to be the PDSN that terminates the PPP connection, and the 31
anchor P-P Address is the anchor PDSNs P-P (PDSN to PDSN) interface IP address. 32
TIA-2001.3-C

35 Section 2

The source PDSN is defined to be the PDSN connected to the source BS/PCF and the 1
target PDSN is defined to be the PDSN connected to the target BS/PCF. 2
The source BS initiates hard handoff of an active packet data session by sending a 3
Handoff Required or Handoff Request message via the MSC to the target BS. Inclusion 4
of the Anchor P-P Address indicates to the target BS that fast handoff is requested. The 5
Handoff Required or Handoff Request messages also include the source PDSN Address 6
and the anchor PDSN Address. 7
When selecting the target PDSN, the target BS/PCF should use the anchor PDSN address 8
or else the source PDSN address provided in the Handoff Request message if possible. If 9
both anchor and source PDSNs are not reachable the PDSN selection algorithm applies. 10
The target PDSN uses the Anchor P-P Address to establish a P-P connection to the 11
anchor PDSN for each packet data service instance of the MS (both active and dormant). 12
During fast handoff, the anchor PDSN remains fixed. 13
14
Depending on the handoff situation, any pair of PDSNs among the anchor, source and 15
target PDSNs, or all three of them, may be identical. The target BS recognizes these cases 16
based on comparing the addresses included in the Handoff Request message with each 17
other and with the target PDSN address. For instance: 18
If no fast handoff has taken place previously during the current active phase of the 19
MS, then the Anchor and the source PDSN are identical, and no P-P connection(s) 20
exist prior to the handoff. If the target BS/PCF can reach the source/anchor PDSN, 21
then the target BS/PCF should select the target PDSN to be identical to the 22
source/anchor PDSN. Note that this will result in an intra-PDSN handoff where the 23
source, anchor and target PDSNs are identical (Figure 2.19.4-2). If the target 24
BS/PCF is unable to reach the source/anchor PDSN, then the target BS/PCF selects a 25
target PDSN that is different from the source/anchor PDSN (Figure 2.19.4-3). 26

Source/Anchor/ Target
PDSN
A10/A11
MS
A10/A11 A10/A11 A10/A11
Target
BS/PCF
Source/Anchor/Target
PDSN Address
Source/Anchor /Target
P-P Address
Source
BS/PCF
27
Figure 2.19.4-2 Configuration Without Prior Fast Handoff Target PDSN Identical to 28
Source/Anchor PDSN 29
TIA-2001.3-C

Section 2 36

Source/Anchor
PDSN
A10/A11
MS
A10/A11 A10/A11
Target
PDSN
A10/A11
Target
BS/PCF
Source/Anchor
PDSN Address
Source/Anchor
P-P Address
Source
BS/PCF
1
Figure 2.19.4-3 Configuration Without Prior Fast Handoff Target PDSN Different from 2
Source/Anchor PDSN 3
If a prior fast handoff has taken place, a P-P connection exists between the source 4
and the anchor PDSNs. In this case, if the target BS/PCF can reach the anchor 5
PDSN, then the target BS/PCF should select the target PDSN to be identical to the 6
anchor PDSN (Figure 2.19.4-4). 7

Source
PDSN
A10/A11
MS
A10/A11 A10/A11
Anchor/Target
PDSN
A10/A11
Target
BS/PCF
Source PDSN
Address
Anchor/Target P-P
Address
Source
BS/PCF
P-P Connection
8
Anchor PDSN 10
If a prior fast handoff has taken place and ifthe target BS/PCF cannot reach the 11
anchor PDSN, but can reach the source PDSN, then the target BS/PCF should select 12
the target PDSN to be identical to the source PDSN. 13
TIA-2001.3-C

37 Section 2

Source/ Target
PDSN
Anchor
PDSN
MS
Target
BS/PCF
Anchor PDSN
Address
Source PDSN
Address
Anchor P-P
Address
Source
BS/PCF
P-P Connection
1
Source PDSN 3
If a prior fast handoff has taken place, and the target PCF can reach neither the 4
anchor PDSN nor the source PDSN, then the target PCF will connect to a target 5
PDSN, and the target PDSN will set up a P-P connection to the anchor PDSN. In this 6
case, all three PDSNs are distinct (Figure 2.19.4-1). 7
Prior to handing off the MS, the target BS/PCF selects a target PDSN and initiates pre- 8
setup of a transmission path for each service instance between the target BS/PCF and the 9
anchor PDSN via the target PDSN. The transmission path between the source BS/PCF 10
and the anchor PDSN is maintained. Data from the anchor PDSN is bicast to the source 11
and the target BS/PCFs. This is shown in Figure 2.19.4-6. 12

Source
BS/PCF
Source
PDSN
A10/A11
Anchor
PDSN
MS
A10/A11 A10/A11
Target
PDSN
A10/A11
Target
BS/PCF
A10/A11
P-P connection
P-P connection
13
Figure 2.19.4-6 General Configuration During a Fast Handoff, Step 1 14
If the target and source PDSN are identical, but distinct from the anchor PDSN, then the 15
P-P connection(s) existing prior to the handoff are reused and the data stream(s) are 16
bicast at the source PDSN. When the target PDSN is distinct from the source and the 17
anchor PDSN, new P-P connection(s) are set up between the Anchor and the target 18
PDSN. When the target PDSN is identical to the anchor PDSN, no new P-P connection(s) 19
are set up. 20
After the MS connects to the target BS, the transmission path(s) between the anchor 21
PDSN and the source BS/PCF is (are) torn down (except for the P-P connection(s) when 22
the existing P-P connection(s) are reused for the target PDSN). This is shown in Figure 23
2.19.4-7. 24
TIA-2001.3-C

Section 2 38

Source
BS/PCF
Source
PDSN
Anchor
PDSN
MS
Target
PDSN
Target
BS/PCF
A10/A11
P-P connection
1
Figure 2.19.4-7 General Configuration During a Fast Handoff, Step 2 2
If the target PDSN is the same as the anchor PDSN, then the fast handoff is completed; 3
i.e., the P-P connection(s) are released and no new ones are created. 4
Otherwise, the fast handoff stays up until one of the following events occurs: 5
It is superseded by another fast handoff (i.e., the target BS/PCF and target PDSN in 6
Figure 2.19.4-3 becomes the source BS/PCF and source PDSN in Figure 2.19.4-1. 7
All packet data service instances on the MS are dormant. Completion of the fast 8
handoff entails the target PDSN releasing all P-P connections to the anchor PDSN, 9
which triggers PPP session renegotiation between the target PDSN and the MS. To 10
minimize impact, this is done when the MS has no active packet data service 11
instances. 12
If a target BS/PCF that does not support fast handoff receives a Handoff Request message 13
from the MSC indicating fast handoff, then the basic hard handoff procedures specified in 14
sections 3.17.4 and 3.17.5 apply. 15
Call flows for this feature are provided in section 3.19.4. Refer to [8] for details on the P- 16
P interface. 17
2.19.5 Intergeneration Packet Data Handoff 18
Intergenerational handoff is defined to be the handoff of an MS between a system that 19
supports packet data service as specified in [11]~[17] (referred to as 3G in this section) 20
and a system that supports a packet data service as specified in [10] (referred to as 2G 21
in this section). Note that packet data service based on [10] is not explicitly supported in 22
this version of the standard. A packet data service instance needs to be re-established 23
following an intergeneration packet data handoff. Refer to section 3.19.5 for details on 24
this feature. 25
2.19.6 Alternate Dormant Handoff 26
This feature provides alternate procedures for performing dormant handoffs of PDSIs. 27
Refer to section 2.17. It differs from the default dormant handoff method by using 28
connectionless signaling on the A1 interface. Fewer messages are exchanged and no 29
SCCP connection is established unless the handoff results in a reactivation of the PDSI 30
and a traffic channel needs to be set up. The alternate dormant handoff procedures are not 31
applied when the MS is already on a traffic channel, i.e., during a concurrent voice call or 32
when other PDSIs are active. 33
TIA-2001.3-C

39 Section 2

The alternate dormant handoffs procedures may be more efficient in networks with small 1
packet zones where MSs initiate dormant handoffs frequently and when dormant 2
handoffs rarely result in the establishment of a traffic channel. 3
When the BS receives an Origination Message from an MS initiating a dormant handoff, 4
the BS may opt for the alternate dormant handoff method by sending an ADDS Transfer 5
message to the MSC including parameters for authentication, authorization, and 6
registration. The BS shall not send the ADDS Transfer message for dormant handoffs 7
unless the MSC supports this feature. The MSC authorizes the BS to initiate the setup of 8
the A10 connection at the target PCF by returning an ADDS Transfer Ack message. 9
Refer to [14] for details on the ADDS Transfer / ADDS Transfer Ack message 10
procedures. 11
Refer to section 3.19.6 for call flows for this feature. 12
2.20 Security Features 13
The security features supported by this version of the IOS comprise: 14
Terminal Authentication, 15
Signaling Message Encryption, and 16
Voice/Data Privacy 17
These features are supported using Shared Secret Data (SSD). SSD is a 128-bit pattern 18
stored in the MS and readily available to the network. SSD is not passed across the air 19
interface between the MS and the network or across the A1 interface. The first 64 bits of 20
the SSD are defined as SSD-A and are used to support the authentication procedures. The 21
last 64 bits of the SSD are defined as SSD-B and are used to support voice/data privacy 22
and signaling message encryption. Air interface procedures are defined to update SSD at 23
the MS. New SSD is generated at the HLR/AC, which initiates the SSD update 24
procedure. Invocation of the SSD update procedure is an HLR/AC or OAM&P concern. 25
The SSD update procedure can take place on traffic channels for MSs capable of 26
authentication and the related security procedures. 27
Usually, the entity controlling the authentication in the network initiates the Unique 28
Challenge procedure as specified in the section 3.20.1.2 after an SSD update procedure is 29
completed. 30
2.20.1 Terminal Authentication 31
Terminal Authentication is the process by which information is exchanged between an 32
MS and network for the purpose of confirming the identity of the MS. A successful 33
outcome of the authentication process occurs only when it can be demonstrated that the 34
MS and network possess identical sets of secret provisioning information called Shared 35
Secret Data (SSD). In the case of authentication failure, service providers may deny 36
network access to invalid MSs and thereby deter fraud. The method involves a common 37
algorithm in the network and MS, and a parameter unique to each MS, and known only to 38
the MS and the network, called the A-key. The common cryptographic authentication 39
algorithms are described in [29] and the interface (input and output parameters) for the 40
algorithms is described in [30]. 41
The SSD is derived from the A-key and a random challenge (RANDSSD) as described in 42
section 3.20.1.1. The A-key and the SSD are never broadcast across the air interface. 43
Instead, a publicly available random number (RAND) is sent to the MS. The RAND and 44
TIA-2001.3-C

Section 2 40

SSD are used as input to the authentication algorithm at both the MS and the network. 1
The authentication response result (referred to as AUTHR) is computed by the MS and 2
returned to the network. It is compared to the networks computed result AUTHR. If the 3
results match, the authentication procedure was successful. If authentication procedures 4
fail, the MSC may initiate call clearing per section 3.2.2. 5
Two forms of authentication are available for use with MSs capable of authentication and 6
the related security procedures. In the first form, the RAND value is broadcast on the 7
forward control/Paging Channel and common to all MSs accessing the cell. The MS 8
computes AUTHR using this RAND, and provides it in its initial access message, which 9
may be a location registration, origination, or page response. Refer to section 3.1.1 for 10
details on the use of this form of authentication for mobile origination and page 11
responses. Also refer to section 3.7. 12
In the second form of authentication, the MSC initiates an explicit authentication 13
procedure, with messaging separate from that used for call setup and registration. The 14
MSC issues a challenge to the MS containing a specific (unique) RANDU value, and the 15
MS responds with its computed AUTHU value. This is referred to as the unique 16
challenge/response procedure. This procedure is always initiated and controlled by the 17
MSC. The MSC may initiate this procedure at any time on either control or traffic 18
channels. The call flow for this form of authentication is described in section 3.20.1.2. 19
2.20.2 Signaling Message Encryption 20
If provided by the air interface, Signaling Message Encryption (SME) protects certain 21
fields within selected air interface signaling messages. SME enhances the authentication 22
process and protects sensitive subscriber information (e.g. PINs). 23
To provide this protection, the relevant device used for the signaling message needs to be 24
loaded with the appropriate key. This is supplied by the MSC over the A1 interface. 25
Refer to the definition of the information element Encryption Information in [14]. 26
Signaling Message Encryption cannot be invoked unless broadcast authentication is 27
activated in the system. 28
2.20.3 Voice/Data Privacy 30
If provided by the air interface, voice/data privacy is between the BS and the MS
2
. To 31
provide this protection, the relevant device used for the voice privacy needs to be loaded 32
with the appropriate key. This is supplied by the MSC over the A1 interface. Refer to the 33
definition of the information element Encryption Information in [14]. Voice/Data 34
Privacy cannot be invoked unless broadcast authentication is activated in the system. 35

2
In CDMA systems, all calls are initiated using the public long code mask for PN
spreading. The mobile station user may request voice privacy during call setup using
the Origination Message or Page Response Message, and during traffic channel
operation using the Long Code Transition Request Order. Voice privacy is then
provided by transitioning to the private long code mask used for PN spreading.

TIA-2001.3-C

41 Section 2

2.21 Flex Rate 1
Flex Rate provides the user the ability to assign data rates to the MS with greater 2
granularity than previously allowed in cdma2000
. To use Flex Rate, the MS is required 3

to download a table (or series of tables) from the BS as part of the Non-Negotiable 4
Service Configuration Record (NNSCR). The NNSCR contains a mapping of physical 5
channels to tables; the tables contain a 4-bit index to each row and an associated bits-per- 6
frame value. There is a default table that is standardized. In addition, the NNSCR 7
contains a one-bit Flex Rate indicator. To assign a data rate for a data burst, the BS sends 8
a 4-bit index into the table for each Supplemental Channel (SCH) in use 9
(REV_SCH_NUM_BITS_IDX and FOR_SCH_NUM_BITS_IDX). If the Flex Rate 10
indicator is turned off, the index refers to the standardized table, and this is used to 11
determine the number bits per frame. If the Flex Rate indicator is turned on and the 12
channel is mapped to a table other than the default table, the index and this Flex Rate 13
table are used to determine the bits per frame for this channel and this burst. 14
Since the NNSCR is passed to the target base stations during establishment of soft 15
handoff legs, there is no need to explicitly pass the Flex rate tables or the Flex Rate 16
indicator to the target base stations. If the MS is in soft handoff, and a burst is being 17
assigned using Flex Rate, the 4-bit index into the Flex Rate table shall be passed to the 18
target BS. 19
2.22 Status Inquiry 20
This procedure is performed on a CDMA traffic channel or control channel to query 21
certain capabilities of the MS. The MSC sends the Status Request message to the BS to 22
instruct the MS to report parameters such as call mode, terminal information, roaming 23
information, security status, etc. For details on the various information records that the 24
MSC may request from MS, refer to [5]. 25
When the MSC sends the Status Request message to the BS, it shall indicate the type of 26
information requested from the MS. The MSC may include the qualification information 27
of the requested capabilities in the message. The MS responds by sending the requested 28
information to the BS. Consequently, the BS responds by sending the Status Response 29
message to the MSC. 30
This operation shall not be applied to DS-41 systems. 31
2.23 3X Multi-Carrier Operation 33
In this standard, 3X Multi-Carrier implementation affects handoff procedures. 3X 34
parameters are required to be properly passed in the handoff messages for the feature to 35
be successfully used. Section 3.23 describes how this feature can be implemented using 36
existing messages and information elements. 37
2.24 5 ms Messaging 38
5 ms messaging allows for faster signaling between the BS and the MS. The only IOS 39
impact is on the A3 traffic frames, which are used to carry the 5 ms messages during soft 40
handoff. Section 3.24 outlines how this feature is implemented. 41
TIA-2001.3-C

Section 2 42

2.25 Enhanced Rate Adaptation Mode (ERAM) 1
Enhanced Rate Adaptation Mode (ERAM) enhances the flexible and variable rate 2
features by using low rate turbo coding schemes. When flexible or variable data rate 3
transmission is used for the Supplemental Channel with turbo codes, low rate turbo codes 4
are used instead of pure code symbol repetition to match the length of the encoder output 5
with the interleaver size of the maximum assigned data rate. By doing this, a performance 6
gain can be achieved due to the inherent low rate coding gain. 7
The source BS indicates the use of ERAM to the target BS (in either a hard handoff or 8
soft handoff scenarios) in the Non-Negotiable Service Configuration IE. To indicate MS 9
support for this feature, the sender sets the ERAM Supported bit in the IS-2000 Mobile 10
Capabilities information element. 11
2.26 Code Combining Soft Handoff (CCSH) 13
This feature only applies to packet data service. Code Combining Soft Handoff (CCSH) 14
utilizes iterative turbo decoding, which can achieve coding diversity gain in addition to 15
the conventional diversity gain during the soft-handoff process. CCSH is a soft handoff 16
method where certain cells encode and transmit the data with the default turbo encoder, 17
whereas other cells use the complementary turbo encoder. The MS combines the code 18
symbols transmitted by each BS for turbo decoding. This is only used for forward link 19
data bursts. 20
The target BS indicates support for this feature to the source BS by setting the CCSH bit 21
in the A3 Connect Information IE of the A3 Connect message. When a Supplemental 22
Channel is assigned for a data burst, the source BS informs the target BS of the turbo 23
encoder type to be used on the Supplemental Channel for each cell in the active set by 24
setting the CCSH Encoder Type bit in the Forward Burst Radio Info IE in the Burst 25
Commit message. 26
2.27 Rescue Channel 28
The Rescue Channel feature supports the use of pre-allocated radio resources at 29
neighboring base stations to attempt to recover a voice call in danger of being dropped. 30
An MS disables its transmitter upon detection of a loss of forward frames from the 31
network. Once the source BS detects a loss of transmission from the MS, it may attempt 32
to re-establish communication with the MS by performing soft handoff additions to 33
rescue cells at neighboring base stations. These base stations are selected based on the 34
MSs neighbor list, last reported Extended Pilot Strength Measurement Message 35
(EPSMM), and possibly other factors. 36
Rescue Channel procedures require reserved A3 connections be provisioned between the 37
source and target base stations. When the source BS adds a BS to the neighbor list of the 38
MS, it indicates to the MS if that neighbor supports a rescue channel. Later, if a call 39
rescue is required, the MS may autonomously promote the neighbor cell into its active set 40
and begin to use the pre-allocated rescue channel. 41
Refer to section 3.27 for call flows describing this feature. 42
TIA-2001.3-C

43 Section 2

2.28 Terrestrial Circuit Management 1
This section describes management of terrestrial circuits between the MSC and the BS 2
and between BSs. 3
2.28.1 Terrestrial Circuit Management for the A2/A5 Interface 4
Terrestrial circuits in the context of this section are those DS0 facilities that are used to 5
carry traffic (voice or data) (A2/A5) between the MSC and the BS. 6
The terrestrial circuit management message structures and the information elements in 7
these messages are described in [14]. 8
The following definitions are to be used when considering the condition of a terrestrial 9
circuit: 10
Available The condition of a terrestrial circuit (A2/A5) that is available for 11
selection by the MSC. 12
Blocked The condition of a terrestrial circuit (A2/A5) which the BS has 13
identified as out of service, and is therefore not available for selection 14
by the MSC. 15
Idle The condition of a terrestrial circuit (A2/A5) that is not carrying traffic. 16
The idle condition does not imply availability. 17
Refer to section 3.28.1 for more details on this feature. 18
2.28.2 Terrestrial Circuit Management for the A3 Interface 19
Terrestrial circuits in the context of this section are ATM virtual circuits (A3) that are 20
used to carry traffic (voice or data) and signaling information between the SDU and the 21
BTS. 22
The following definitions are to be used when considering the condition of a terrestrial 23
circuit: 24
Available The condition of a virtual circuit connection (A3) that is available for 25
selection by the BTS. 26
Blocked The condition of a virtual circuit connection (A3) which the SDU has 27
identified as out of service, and is therefore not available for selection 28
by the BTS. 29
Idle The condition of a virtual circuit connection (A3) that is not carrying 30
traffic. The idle condition does not imply availability. 31
For call flows associated with this feature, refer to section 3.28.2. 32
2.29 Vocoder Support 33
This version of the IOS supports three vocoder types: 34
13K (SO=8000H, 0011H) 35
EVRC (SO=0003H) 36
SMV (SO=0038H) 37
TIA-2001.3-C

Section 2 44

Section 3.29 describes the IOS messaging required to support vocoder assignment by the 1
BS. 2
2.30 Reverse FCH Gating 3
This feature is intended to increase MS talk time and reverse link capacity by using 4
discontinuous transmission mode operation for 1/8 rate frames on the reverse 5
Fundamental channel. The transmission of the Reverse Fundamental Channel with Radio 6
Configuration 3, 4, 5, or 6 may be gated when no other reverse traffic channel is assigned 7
and the data rate is 1500 bps for Radio Configurations 3 and 5, or 1800 bps for Radio 8
Configurations 4 and 6. The MS performs reverse Fundamental Channel gating on the 9
reverse 1/8th rate frames by gating off for 10 ms per one frame. The reverse Fundamental 10
Channel gating operation is synchronized with the Reverse Pilot Channel gating 11
operation when there is no reverse traffic channel other than the FCH. The forward power 12
control bits on the Reverse Pilot Channel are transmitted at half rate (400 Hz) during 13
gated mode operation. 14
This feature is supported in this standard by use of A1, A3 and A7 messages. For hard 15
handoff scenarios, the source base station indicates the use of FCH gating by setting the 16
REV_FCH_GATING bit to 1 in the IS-2000 Channel Identity information element. The 17
Reverse Power Control Delay is indicated in the Hard Handoff Parameters information 18
element. 19
For soft handoff scenarios, the source base station indicates the use of FCH gating by 20
setting the REV_FCH_GATING bit to 1 in the Physical Channel Info information 21
element (sent in the A7 Handoff Request message). The target base station can indicate 22
cell support for this feature by setting the REV_FCH_GATING bit to 1 in the A3 23
Connect Info information element (sent in the A3 Connect message). The Reverse Power 24
Control Delay is indicated in the IS-2000 Power Control Info information element. 25
If the cell being added for soft handoff does not support this feature, the target base 26
station sets the REV_FCH_GATING bit in the A3 Connect Info information element to 27
0. In this situation, the source base station does not add this soft handoff leg. 28
2.31 Voice-over-IP (VoIP) 29
Efficient Voice-over-IP (VoIP) service requires minimizing transmission overhead over 30
the air. Two service options are currently supported that reduce RTP/UDP/IP headers for 31
VoIP service: Link-Layer Assisted Header Removal and Link-Layer Assisted Robust 32
Header Compression (SOs 60 and 61, respectively); refer to [31]. These service options 33
are supported over a fundamental channel on the air interface. 34
Establishing a VoIP session requires a SO 33 packet data service instance to exchange 35
Session Initiation Protocol (SIP) messages (or an equivalent signaling protocol) between 36
the MS and a remote VoIP peer. This exchange establishes the vocoder and transport 37
endpoints (IP addresses and UDP ports) that are used by the Real Time Protocol (RTP) 38
flow. Note that this signaling may be initiated either by the MS or by the remote VoIP 39
peer as long as a SO 33 packet data service instance exists. To establish a VoIP packet 40
data service instance, the MS sends an origination message to the BS to request the VoIP 41
service instance. The MS always initiates the request since there is no provision for 42
network-initiated establishment of a packet data service instance. A packet data service 43
instance used for the VoIP session signaling may transition to the Dormant State once 44
VoIP setup is complete. 45
TIA-2001.3-C

45 Section 2

To release a VoIP session gracefully, and consequently the VoIP packet data service 1
instance, a packet data service instance used for VoIP session signaling is reactivated (if 2
necessary) and the MS and the remote peer use SIP (or an equivalent signaling protocol) 3
over this packet data service instance. 4
Refer to section 3.17 for packet data service call flows (e.g., section 3.17.4.1 and 3.17.5.1 5
for call setup). 6
2.31.1 Voice over IP Handoff Considerations 7
There is no Dormant State defined for the VoIP service options; a VoIP SO is either 8
active or inactive. Therefore, all handoffs of VoIP service instances are active (hard or 9
soft) handoffs. The procedures for active packet data handoff, including those procedures 10
termed fast handoff in section 2.19.4, which involve pre-establishment of A10 and P-P 11
connections, are followed. 12
2.32 Network Directed System Selection (NDSS) 13
The Network Directed System Selection (NDSS) feature provides a network-based 14
mechanism for a service provider, based on various customer and service provider 15
specified criteria, to automatically re-direct an MS origination or registration to a desired 16
serving system. The desired serving system may be any system, regardless of frequency 17
band, technology (e.g. analog or digital) or generation (2G or 3G). 18
This feature is intended to re-direct the origination or registration of the MS from a 19
cdma2000
1X system to another system (e.g., IS-95 A/B system, Analog system). When 20
the MSC re-directs the registration or origination from the MS, it can allow the MS to 21
return if the redirection to the desired system fails. In this situation, the source BS may 22
inform the MSC that the CM Service Request or Location Updating Request message is 23
caused by the return of the MS. 24
This feature may be used, for example, when a voice origination from a dual mode (e.g., 25
IS-95 A/B and cdma2000
1X) MS is re-directed from the cdma2000
1X system to an 26
IS-95A/B system for distributed overload control. This can be used to avert overload 27
conditions in the cdma2000
1X system. 28
2.33 Features Supported Transparently in this Standard 30
The features included in this section are supported transparently (i.e., there are no 31
messages, call flows, information elements, fields, value ranges, etc., that need to be 32
added or modified to support them) by this version of the standard. The list is not 33
intended to be exhaustive. 34
2.33.1 Emergency Service (Basic) via Specific Dialed Number 35
For E911 Phase 1 and Phase 2, refer to section 2.9. 36
Emergency calls are handled as regular calls by the BS. There is no impact to the RAN. 37
For basic emergency calls, the specific digit string (e.g. 911) constitutes the dialed digits. 38
TIA-2001.3-C

Section 2 46

Alternatively, the MS may signal that the call is an emergency call, in which case the 1
Global Emergency Call Indication is used (refer to section 2.8). 2
The call flows for this feature are identical to the call flows for a mobile originated call; 3
2.33.2 Carrier Access 5
This feature uses carrier access codes as prefixes to the called party number to set up an 6
MS originated call. It is supported transparently by the IOS interfaces (IOS allows up to a 7
total of 32 digits in the Origination Messages). 8
2.33.3 Call Forwarding 9
Call Forwarding permits a called subscriber to send incoming calls addressed to the 10
called subscribers Directory Number to another Directory Number (forward-to number) 11
or to the called subscribers designated voice mailbox. The call forwarding may be done 12
under following conditions: 13
Unconditional 14
When Busy 15
No Answer 16
Default 17
Feature codes are sent in the Called Party BCD Number or Called Party ASCII Number 18
parameter of the CM Service Request message (refer to [14]) when a subscriber initiates 19
actions (e.g. to activate or deactivate Call Forwarding). Incoming calls are forwarded by 20
the MSC; this is transparent to the IOS interfaces. 21
2.33.3.1 Call Forwarding Unconditional 22
Call Forwarding Unconditional provides the capability to a subscriber to forward calls 23
regardless of the condition of the termination. 24
This feature is transparent to IOS interfaces. 26
2.33.3.2 Call Forwarding When Busy 27
Call Forwarding When Busy provides the capability to a subscriber to forward calls when 28
the subscriber is busy. 29
2.33.3.3 Call Forwarding - No Answer 32
Call Forwarding When No Answer provides the capability to a subscriber to forward 33
calls when the subscriber fails to answer a call or is otherwise inaccessible (excluding 34
busy). 35
TIA-2001.3-C

47 Section 2

2.33.3.4 Call Forward Default 3
Call Forwarding Default provides the capability to a subscriber to forward calls when the 4
subscriber fails to answer a call, is busy or is otherwise inaccessible. 5
2.33.4 Call Delivery 8
Call Delivery allows a subscriber to receive a call to his or her directory number while 9
roaming. 10
This feature is transparent to the IOS interfaces. 12
2.33.5 Advice of Charge 13
Advice of Charge (refer to [37]) permits a wireless subscriber to receive charging 14
information for telecommunication services. 15
Information is presented at the start of a call, during a call, or at the end of a call. 16
Information is conveyed to the subscriber within five (5) seconds of the appropriate event 17
(start of call, mid-call charging event, and end of call). 18
Information may be presented using visual display, distinctive alerting, audible tone or 19
announcement, or a combination of visual display, distinctive alerting, and audible tone 20
or announcement. 21
Information is sent from the MSC to the MS via the BS using Flash with Information 23
messages. 24
2.33.6 Call Transfer 26
Call Transfer enables a subscriber to transfer an in-progress established call to a third 27
party. The call to be transferred may be an incoming or outgoing call. 28
Call Transfer allows a controlling subscriber to put a call on hold, dial a third party, then 29
connect the held party and the third party into a call 30
Call Transfer also allows a controlling subscriber, that also has Three-Way Calling 31
(3WC) active, to set up a three-way call and drop out of the call leaving the other two 32
parties of call connected to each other. 33
TIA-2001.3-C

Section 2 48

For further description refer to [21]. 1
The feature is invoked using the Flash with Information messages. 3
There are no call flow is associated with this feature. 4
2.33.7 Lawfully Authorized Wiretap 5
Lawfully Authorized Wiretap refers to accessing communications as an intercept access 6
service. The service fall into four categories: 7
Non-call associated service to provide information about a subject that is not 8
necessary related to a call. 9
Call associated service to provide call-identification information about calls 10
involving the intercept subject. 11
Call associated and non-call associated service to provide subject and network 12
signaling call-identifying information. 13
Content surveillance services to provide access to an intercept subjects 14
communication. 15
Location support for wiretapping is not required; however, location of the wiretap subject 16
may be provided using the most recent Cell ID parameter provided to the MSC. 17
2.33.8 Access Control by Call Type (ACCT) 19
The Access Control by Call Type (ACCT) feature is activated by the BS for controlling 20
access attempts by certain classes of MSs for a specific service option or a set of service 21
options. For instance, if both voice and packet data calls are supported in the same 22
frequency band, and the RAN is having problems establishing packet data calls but is not 23
having problems establishing voice calls, ACCT allows the BS to control access attempts 24
by MSs based on the call type, by allowing voice calls but blocking data calls. Refer to 25
[5]. 26
ACCT may be activated by the BS based on interaction with the PDSN or the MSC, or 27
triggers internal to the BS.On activation of ACCT, the base station includes the SOs that 28
it is going to control within the APM/EAPM messages. For each specified SO, the BS 29
also lists group(s) of MSs to block. MSs that belong to the groups that are blocked do not 30
originate calls for those SOs. The BS may also use APM/EAPM to modify the ACCT for 31
groups of MSs for specific service option(s), add control for different service option(s), 32
remove control for specific service option(s) or turn off the ACCT control completely. 33
No call flows are associated with this feature. 34
TIA-2001.3-C

49 Section 3

3.0 Feature Call Flows 1
Refer to [14]~[17] for definitions of messages and timers used in this document. 2
3.1 Call Setup of Voice and Circuit Data Calls 3
Call flows for setup of mobile originated and terminated voice and circuit data calls are 4
described in this section. 5
For details on call clearing call flows, refer to section 3.2. 6
3.1.1 Mobile Origination Examples 7
Mobile originated call setup involves exchange of the following A1 messages: 8
Complete Layer 3 Information with Connection Management (CM) Service Request 9
Connection Management (CM) Service Request Continuation 10
Assignment Request 11
Assignment Failure 12
Assignment Complete 13
Progress. 14
3.1.1.1 Mobile Origination 15
This section describes the call flow associated with an MS call origination in the system. 16
TIA-2001.3-C

Section 3 50

MS BS MSC
time comment
Origination Message
Base Station Ack Order
a
b
c
d
e
f
Complete L3 Info: CM Service Request
Assignment Request
channel assignment message
Tch Preamble
g
h
BS Ack Order
MS Ack Order
Service Connect Message
Assignment Complete
Ringback Tone
i
k
l
T10
Transparent to
signaling
Service Connect Completion
j
T303
Origination Continuation Message
CM Service Request Continuation
T312
m
n
1
Figure 3.1.1.1-1 Mobile Origination 2
a. The MS transmits an Origination Message, with Layer 2 Ack required, over the 3
Access Channel of the air interface to the BS to request service. 4
b. The BS acknowledges the receipt of the Origination Message with a Base Station 5
Acknowledgment Order to the MS. 6
If the BS can determine that resources, e.g., a traffic channel, are not available, the 7
BS may perform the PACA call flow described in section 3.11 provided that the 8
MS indicated PACA supported in the Origination message. Otherwise, the call is 9
allowed to proceed. 10
c. The BS constructs the CM Service Request message, places it in the Complete Layer 11
3 Information message, sends the message to the MSC, and starts timer T
303
. For 12
circuit switched calls, the BS may request the MSC to allocate a preferred terrestrial 13
circuit. If the Origination Message sent in step a indicated that it is to be followed 14
by an Origination Continuation Message, the CM Service Request message shall 15
include an Origination Continuation Indicator element and the MSC shall start timer 16
T
312
to await the CM Service Request Continuation Message. 17
If the global challenge is used, the MSC continues the call setup process while 18
waiting for an authentication confirmation. If an authentication failure indication is 19
received at the MSC, it may clear the call. Some in-band treatment may be provided 20
on discretion of the MSC manufacturer, e.g., tone or announcement, assuming the 21
BS has already done channel assignment. 22
d. The MSC sends an Assignment Request message to the BS to request assignment of 23
radio resources. This message includes information on the terrestrial circuit, if one is 24
to be used between the MSC and the BS. The MSC then starts timer T
10
. 25
TIA-2001.3-C

51 Section 3

If the BS requested a preferred terrestrial circuit in the CM Service Request message 1
and the MSC can support that terrestrial circuit, the MSC shall use the same 2
terrestrial circuit in the Assignment Request message. Otherwise, the MSC may 3
assign a different terrestrial circuit. 4
If the Include Priority bit of the Radio Environment and Resources element was set 5
to 1 in the CM Service Request message to indicate that no lower priority channels 6
are available (e.g., when a PACA channel reservation scheme is used) the MSC shall 7
include the actual call priority. 8
Upon receipt of the Assignment Request message from the MSC, the BS stops timer 9
T
303
. 10
e. If a traffic channel is available for the call, the BS sends a channel assignment 11
message
3
over the Paging Channel of the radio interface (with the MS address) to 12
initiate the establishment of a radio traffic channel, if the MS is not already on a 13
traffic channel. 14
If for any reason the BS is unable to assign resources (e.g., a traffic channel) for this 15
call and the call is given PACA service, the BS queues the request and notifies the 16
MS of the reason and the current queue position (refer to section 3.11). The BS then 17
sends an Assignment Failure message to the MSC with the Cause field set to PACA 18
Call Queued. The MSC initiates normal call clearing call flow as described in 19
section 3.2.2 to release the underlying transport connection. 20
When a traffic channel becomes available, the BS instructs the MS to re-originate the 21
call by sending a PACA Message. 22
f. The MS begins sending the traffic channel preamble (TCH Preamble) over the 23
designated reverse traffic channel. 24
g. Once the BS acquires the reverse traffic channel, it sends the Base Station 25
Acknowledgment Order, with Layer 2 Ack required, to the MS over the forward 26
traffic channel. 27
h. The MS acknowledges the reception of the BS Ack Order by transmitting the Mobile 28
Station Acknowledgment Order and by sending null traffic channel data (Null TCH 29
Data) over the reverse traffic channel. 30
i. The BS sends the Service Connect Message / Service Option Response Order to the 31
MS specifying the service configuration for the call. The MS begins processing 32
traffic in accordance with the specified service configuration. 33
j. On receipt of the Service Connect Message, the MS responds with a Service Connect 34
Completion Message. 35
k. If the MS indicated in the Origination Message in step a that an Origination 36
Continuation Message would follow, the MS sends this message. 37
l. If the BS received an Origination Continuation Message in step k, it sends a CM 38
Service Request Continuation Message to the MSC. Upon receipt of this message the 39
MSC shall stop timer T
312
. 40
m. After the radio traffic channel and circuit have both been established and fully 41
interconnected, the BS sends the Assignment Complete message to the MSC and 42
considers the call to be in Conversation State. 43

3
This may be Channel Assignment Message or Extended Channel Assignment
Message.

TIA-2001.3-C

Section 3 52

The MSC stops timer T
10
upon receipt of the Assignment Complete message. 1
n. As call progress tone is applied in-band in this case, ringback tone is available on the 2
audio circuit path towards the MS. 3
3.1.1.2 Mobile Origination with Access Probe Handoff, Access Handoff and Channel 4
Assignment into Soft/Softer Handoff 5
This section describes the call flow associated with mobile origination and access probe 6
handoff, access handoff and channel assignment into soft handoff using the source BS 7
(the BS on which the first probe was sent). The same technique applies to the mobile 8
termination case. 9
The access handoff, access probe handoff, and channel assignment into soft handoff 10
functions shown in the following diagram are not all necessarily required for each call 11
setup. The diagram gives an example of a call where all three are used, but that is not the 12
case for all calls. In this section, A3-CEData Forward/Reverse messages represent 13
A3-IS-95 FCH Forward/Reverse, A3-IS-2000 FCH Forward/Reverse, or A3-IS- 14
2000 DCCH Forward/Reverse messages. 15
TIA-2001.3-C

53 Section 3

Origination Message (II)
x

MS
Source
BS
MSC
time comment
a
c
e
f
g
h
T303
b
d
Target
BS-1
Target
BS-2
Target
BS-3
x
Origination Message (I)
A7-Access Channel Message Transfer
A7-Access Channel Message Transfer Ack
Tacm
A7-Handoff Request
A3-Connect
l
j
i
Tconn3
A3-CEData Forward
k
A3-CEData Reverse
A3-Traffic Channel Status
Tchanstat
m
A7-Handoff Request Ack
A3-Connect Ack
Thoreq
n
Origination Message (III)
o
q
p
A7-Access Channel Message Transfer
A7-Access Channel Message Transfer Ack
Tacm
Assignment Request
s
A7-Paging Channel Message Transfer
r
x
x
x
Extended Channel Assignment Message
t
u
Pilot Preamble T10
Source BS was
attempted first
Access probe handoff
to target BS-1
Access probe handoff
to target BS-2
Access probe
handoff ends
Access handoff to
target BS-3
SCENARIO CONTINUES
NEXT PAGE
These messages are
used to set up soft
handoff legs for
channel assignment
into soft handoff.
1
Figure 3.1.1.2-1 Mobile Origination with Access Probe Handoff, Access Handoff and Channel 2
Assignment into Soft/Softer Handoff 3
TIA-2001.3-C

Section 3 54

MS
Source
BS
MSC
time comment
v
x
z
w
y
Target
BS-1
Target
BS-2
Target
BS-3
Assignment Complete
T10
SCENARIO CONTINUED
FROM PREVIOUS PAGE
MS Ack Order
Service Connect Completion Message
aa
Handoff Performed
1
Figure 3.1.1.2-1 (Cont.) Mobile Origination with Access Probe Handoff, Access Handoff and 2
Channel Assignment into Soft/Softer Handoff 3
a. The MS transmits an Origination Message (Origination (I)), with Layer 2 Ack 4
required, over the Access Channel of the air interface to the source BS to request 5
service. Because this BS is the first to which the MS sends an access probe, it 6
becomes by definition the source BS for this call setup attempt. In this message the 7
MS reports the pilot strength of all the pilots in the MSs Paging Channel Active Set. 8
It also reports other pilots using the ACCESS_HO_LIST and the 9
OTHER_REPORTED_LIST (refer to [1]~[6]). This message is not received by the 10
source BS. 11
b. The MS performs an access probe handoff and sends a second Origination Message 12
(Origination (II)), with Layer 2 Ack required, over the Access Channel of the air 13
interface to the target BS-1 to request service. Note that the target BS-1 may not 14
have been in the ACCESS_HO_LIST in step a. 15
c. The target BS-1 acknowledges the receipt of the Origination Message with a Base 16
Station Acknowledge Order to the MS. The BS Ack Order is not received by the MS. 17
d. The target BS-1 recognizes that it is not the first accessed BS and encapsulates the 18
Origination Message received from the MS in the A7-Access Channel Message 19
Transfer message and forwards it to the source BS instead of sending the CM 20
Service Request message to the MSC. The target BS-1 starts timer T
acm
. 21
e. The source BS acknowledges the A7-Access Channel Message Transfer message by 22
sending an A7-Access Channel Message Transfer Ack message to the target BS-1. 23
The target BS-1 stops timer T
acm
. 24
f. The source BS constructs the CM Service Request message, places it in the 25
Complete Layer 3 Information message, sends the message to the MSC, and starts 26
timer T
303
. The BS may request the MSC to allocate a preferred terrestrial circuit. 27
g. Since the Origination Message sent to the source BS carries the pilot report of other 28
strong pilots, the source BS initiates the inter-BS soft handoff setup procedure by 29
sending the A7-Handoff Request message to one or more target BSs. (In this 30
example scenario, the source BS chooses target BS-1, target BS-2, and target BS-3). 31
The source BS starts an instance of timer T
horeq
for each A7 Handoff Request 32
message sent. Alternatively, the initiation of soft handoff may be performed after 33
receiving the Assignment Request message from the MSC. 34
TIA-2001.3-C

55 Section 3

h. The target BSs initiate A3 connections by sending A3-Connect messages to the 1
specified address. Each target BS starts an instance of timer T
conn3
. The target BSs 2
may begin sending null frames over the air. 3
i. The source BS replies with A3-Connect Ack messages to complete the A3 4
connections. The target BSs stop timer T
conn3
. The source BS starts an instance of 5
timer T
chanstat
for each A3 Connect Ack message sent if the source BS requests to 6
receive A3-Traffic Channel Status messages from the target BSs. 7
j. The source BS begins to send idle forward frames to the target BSs. 8
k. The target BSs begin to send reverse idle frames as soon as the first forward frame is 9
received from the source BS. The reverse frames contain the timing adjustment 10
information necessary to achieve synchronization. 11
l. If the source BS has chosen to be notified of the start of transmission and reception 12
at the target BSs, when its SDU function and the target BSs have synchronized the 13
A3 traffic subchannel, the target BS replies with an A3-Traffic Channel Status 14
message. Note that this step can occur any time after step i'. The source BS stops 15
T
chanstat
timers. 16
m. Target BS-1, target BS-2 and target BS-3 send A7-Handoff Request Ack messages to 17
the source BS to complete the soft handoff setup procedure. Note that this message 18
can be sent at any time following the receipt of the A3-Connect Ack messages at 19
each target BS. The source BS stops T
horeq
timers. 20
n. The MS did not receive the Layer 2 Ack in response to the Origination Message at 21
step c; therefore, it performs an access probe handoff to target BS-2, and sends a 22
third Origination Message (Origination (III)) with the first accessed BS identified 23
and with Layer 2 Ack required. 24
Note that the ACCESS_HO_LIST identifies the source BS as the first attempted, and 25
that target BS-1 and target BS-2, which may not have been included in the 26
ACCESS_HO_LIST in step a, are included in the ACCESS_HO_LIST in this step. 27
o. Target BS-2 responds with a Base Station Ack Order to the MS. The MS receives the 28
Base Station Ack Order, which successfully completes the access attempt. 29
p. The target BS-2 recognizes that it is not the first accessed BS (i.e., the source BS) 30
and encapsulates the Origination Message received from the MS in the A7-Access 31
Channel Message Transfer message and forwards it to the source BS instead of 32
sending the CM Service Request message to the MSC. The target BS-2 starts timer 33
T
acm
. 34
q. The source BS acknowledges the A7-Access Channel Message Transfer message by 35
sending an A7-Access Channel Message Transfer Ack message to the target BS-2. 36
The source BS upon receiving the Origination Message from the target- BS-2 for the 37
same MS and the same call may send a second CM Service Request to the MSC, 38
though this option is not shown in this example. Upon receipt of the A7-Access 39
Channel Message Transfer Ack message the target BS-2 stops timer T
acm
. 40
r. The MSC sends an Assignment Request message to the source BS to request 41
assignment of radio resources. This message includes information on the terrestrial 42
circuit, if one is to be used between the MSC and the BS. The MSC then starts timer 43
T
10
. Upon receipt of the Assignment Request message from the MSC, the BS stops 44
timer T
303
. This step may occur any time after step f. 45
s. After receiving the Assignment Request message from the MSC and optionally 46
receiving A3-Connect messages from the potential target BSs, the source BS 47
TIA-2001.3-C

Section 3 56

constructs an air-interface Extended Channel Assignment message and forwards it in 1
the A7-Paging Channel Message Transfer message to one or more base stations, 2
usually chosen from those that are in the ACCESS_HO_LIST and 3
OTHER_REPORTED_LIST (which may not be the same BSs set up in soft 4
handoff). The A7-Paging Channel Message Transfer message may be sent any time 5
after the A3 Connections are completed. 6
t. The source BS and target BSs send the appropriate channel assignment message over 7
the air to the MS. The probability of the MS receiving this message is substantially 8
increased by sending this message from multiple base stations. In the meantime, the 9
MS has performed an access handoff to target BS-3. Since the MS is listening to the 10
Paging Channel of only one BS, it does not receive the Extended Channel 11
Assignment Message from any other BSs than target BS-3. At any time after 12
sending/receiving the A7-Paging Channel Message Transfer message, all soft 13
handoff legs on the source BS and target BS begin sending null forward traffic 14
frames to the MS. 15
u. After receiving the Extended Channel Assignment Message from the target BS-3 and 16
the forward traffic frames from one or more base stations, the MS starts sending the 17
traffic frames or preambles. 18
In steps v through y, the full activity of the messaging between the source BS and 19
the MS via the target BSs using A3-CEData Forward and A3-CEData Reverse 20
messages and transmission and reception of messages to and from the MS by the 21
target BSs is not shown for simplicity in the diagram. 22
v. If a target BS detects the reverse preamble, it sends it to the source BS in an A3- 23
CEData Reverse message. Once the source BS acquires the reverse traffic channel, it 24
sends the Base Station Acknowledgment Order, with Layer 2 Ack required, to the 25
MS over the forward traffic channel. The source BS also informs the target BSs that 26
the reverse traffic channel was acquired by starting to send non-idle frame content 27
type in the A3-CEData Forward messages. Upon receiving non-idle frame content in 28
the A3-CEData Forward messages, the target BS terminates any attempts to send the 29
channel assignment message to the MS. 30
w. The MS acknowledges the reception of the BS Ack Order by transmitting the Mobile 31
Station Acknowledgment Order and by sending null traffic channel data (Null TCH 32
Data) over the reverse traffic channel. 33
x. The source BS then sends the Service Connect Message / Service Option Response 34
Order to the MS specifying the service configuration for the call. The MS begins 35
processing traffic in accordance with the specified service configuration. 36
y. On receipt of the Service Connect Message, the MS responds with a Service Connect 37
z. The source BS sends the Assignment Complete message to the MSC. At this time, 39
the MS is on the traffic channel and the call setup into soft/softer handoff is 40
completed successfully. The MSC stops timer T
10
. At this time, the MS is set up 41
directly in soft/softer handoff with one or more base stations. 42
aa. The source BS may send a Handoff Performed message to the MSC as explained in 43
section 3.19.1.1.3 Concept of A Designated Cell. 44
3.1.1.3 Mobile Origination Failure Call Clearing with Local Tone Generation 45
This section describes the call flow associated with a Progress message. The Progress 46
message is used to trigger tone generation at the MS (e.g., via a Reorder Order or 47
Intercept Order message to the MS) prior to clearing a call request. Local tone generation 48
allows the network to convey information to a user by means of tones. 49
TIA-2001.3-C

57 Section 3

Progress
Release
MS BS MSC
time comment
Origination Message
a
b
c
d
e
f
g
h
T303
T315
2
Clear Command
Clear Complete
Tone generation
1
Figure 3.1.1.1-1 Call Clearing with Local Tone Generation 2
a. The MS transmits an Origination Message, with Layer 2 Ack required, over the 3
Access Channel of the air interface to the BS to request service. 4
303
. For 8
circuit switched calls, the BS may request the MSC to allocate a preferred terrestrial 9
circuit. 10
d. The MSC decides to reject the call prior to sending an Assignment Request. The 11
MSC sends a Progress message to the BS to trigger local tone generation at the MS 12
conveying information regarding the reason for rejection (e.g., reorder) to the user. 13
e. Upon receipt of the Progress message, the BS instructs the MS to generate the 14
appropriate tone (e.g., by sending a Reorder Order message). 15
f. The MSC sends a Clear Command message to the BS to instruct the BS to release 16
the associated dedicated resource and starts timer T
315
. 17
The MSC should delay sending the Clear Command message after the Progress 18
message to allow the local tone generation at the MS. 19
g. After receiving the Clear Command message, the BS initiates call clearing over the 20
air interface and stops timer T
303
. Note that the BS may need to be aware of the time 21
needed by the MS to generate the local tone. 22
h. Upon acknowledgement of the call clearing over the air interface, the BS returns a 23
Clear Complete message. The MSC stops timer T
315
upon receipt of the Clear 24
Complete message and releases the underlying transport connection. 25
3.1.2 Mobile Termination Examples 26
Mobile terminated call setup involves exchange of the following A1 messages: 27
TIA-2001.3-C

Section 3 58

Paging Request 1
Complete Layer 3 Information with Paging Response 2
Alert with Information 6
Connect. 7
3.1.2.1 Mobile Termination 8
This section describes the call flow associated with an MS call termination in the system. 9

MS BS MSC
time comment
Page Response Message
c
d
e
f
g
h
i
j
Complete L3 Info: Paging Response
Assignment Request
Tch Preamble
k
m
BS Ack Order
MS Ack Order
Assignment Complete
T10
Connect
p
r
Page Message
b
a
Paging Request
n
o
Alert with Info
MS Ack Order
Connect Order
q
BS Ack Order
T301
T3113
T303
l
10
Figure 3.1.2.1-1 Mobile Termination 11
a. The MSC determines that an incoming call terminates to an MS within its serving 12
region and sends the Paging Request message to the BS to initiate a mobile 13
terminated call setup scenario. The MSC then starts timer T
3113
. 14
b. The BS issues a Page Message containing the MS address over the Paging Channel. 15
c. The MS acknowledges the page by transmitting a Page Response Message over the 16
Access Channel. 17
TIA-2001.3-C

59 Section 3

d. The BS constructs the Paging Response message, places it in the Complete Layer 3 1
Information message, sends the message to the MSC, and starts timer T
303
. The BS 2
may request the MSC to allocate a preferred terrestrial circuit. 3
3113
upon receipt of the Paging Response message from the 4
BS. 5
e. The BS acknowledges the receipt of the Page Response Message from the MS with a 6
Base Station Acknowledgment Order to the MS. 7
f. The MSC sends an Assignment Request message to the BS to request assignment of 8
radio resources. This message also includes terrestrial circuit if one is to be used 9
between the MSC and the BS. The MSC then starts timer T
10
. 10
If the BS requested a preferred terrestrial circuit in the Paging Response message and 11
the MSC can support that terrestrial circuit, the MSC shall use the same terrestrial 12
circuit in the Assignment Request message. Otherwise, the MSC may assign a 13
different terrestrial circuit. 14
Upon receipt of the Assignment Request message from the MSC, the BS stops timer 15
T
303
. 16
g. The BS sends a channel assignment message
4
over the control channel of the radio 17
interface (with the MS address) to initiate the establishment of a radio traffic 18
channel, if the MS is not already on a traffic channel. 19
h. The MS begins sending the traffic channel preamble (TCH Preamble) over the 20
i. Once the BS acquires the reverse traffic channel, it sends the Base Station 22
traffic channel. 24
j. The MS acknowledges the reception of the BS order by transmitting the Mobile 25
Station Acknowledgment Order. 26
k. The BS then sends the Service Connect Message / Service Option Response Order to 27
the MS specifying the service configuration for the call. The MS begins processing 28
l. On receipt of the Service Connect Message, the MS responds with a Service Connect 30
m. After the radio traffic channel and circuit have both been established, the BS sends 32
the Assignment Complete message to the MSC. 33
10
upon receipt of the Assignment Complete message from 34
the BS, and starts timer T
301
. 35
n. The BS sends the Alert with Information Message to the MS to cause ringing at the 36
MS. 37
o. The MS acknowledges the reception of the Alert with Information Message by 38
transmitting the Mobile Station Acknowledgment Order. 39
p. When the call is answered at the MS, a Connect Order, with acknowledgment 40
required, is transmitted to the BS. 41

4
Message.
TIA-2001.3-C

Section 3 60

q. The BS acknowledges the Connect Order with the Base Station Acknowledgment 1
Order over the forward traffic channel. 2
r. The BS sends a Connect message to the MSC to indicate that the call has been 3
answered at the MS. The MSC stops timer T
301
upon receipt of the Connect message 4
from the BS. At this point, the call is considered stable and in the Conversation State. 5
6
3.1.2.2 Mobile Termination, Assignment Retry 7
This section describes the call flow when channel assignment is retried between the BS 8
and MSC interface for a mobile terminated call. 9

MS BS MSC
time comment
c
d
e
Page Message
b
a
Paging Request
T3113
h
i
j
k
l
Assignment Request
Tch Preamble
m
o
BS Ack Order
MS Ack Order
Assignment Complete
T10
Connect
r
t
p
q
Alert with Info
MS Ack Order
Connect Order
s
BS Ack Order
T301
f
Assignment Request
g
Assignment Failure
T10
T20
n
T303
10
Figure 3.1.2.2-1 Mobile Termination: Assignment Retry 11
TIA-2001.3-C

61 Section 3

a The MSC determines that an incoming call terminates to an MS within its serving 1
region and sends the Paging Request message to the BS to initiate a mobile 2
terminated call setup scenario. The MSC starts timer T
3113
. 3
b. The BS issues a Page Message containing the MS address over the Paging Channel. 4
c. The MS acknowledges the page by transmitting a Page Response Message over the 5
Access Channel. 6
d. The BS constructs the Paging Response message, places it in the Complete Layer 3 7
303
. The BS 8
may request the MSC to allocate a preferred terrestrial circuit. 9
3113
upon receipt of the Paging Response message from the 10
BS. 11
e. The BS acknowledges the receipt of the Page Response Message from the MS with a 12
Base Station Acknowledgment Order over the air interface. 13
f. The MSC sends an Assignment Request message to the BS to request assignment of 14
radio resources. This message also assigns the terrestrial circuit, if one is to be used, 15
between the MSC and the BS. The MSC then starts timer T
10
. 16
If the BS requested a preferred terrestrial circuit in the Paging Response message and 17
the MSC can support that terrestrial circuit, the MSC shall assign the same terrestrial 18
circuit in the Assignment Request message. Otherwise, the MSC may assign a 19
different terrestrial circuit. 20
The BS stops timer T
303
upon receipt of the Assignment Request message. 21
g. In this example, the BS recognizes that the assignment cannot be completed, (e.g., 22
the requested terrestrial circuit is not available) and sends the Assignment Failure 23
message to the MSC. The BS then starts timer T
20
. 24
10
upon receipt of the Assignment Failure message from the 25
BS. 26
h. The MSC retries by sending an Assignment Request message to the BS to request 27
assignment of radio resources. This message also assigns a different terrestrial circuit 28
to be used between the MSC and the BS, if one is needed for the call. The MSC 29
restarts timer T
10
. 30
Upon receipt of the retry of the Assignment Request message, the BS stops timer 31
T
20
. In this example, it is assumed that this second Assignment Request message is 32
acceptable to the BS. The BS connects the traffic channel to the designated terrestrial 33
circuit. 34
i. The BS sends a channel assignment message
5
over the Paging Channel of the radio 35
interface (with the MS address) to initiate the establishment of a radio traffic 36
channel, if the MS is not already on a traffic channel. 37
j. The MS begins sending the traffic channel preamble (TCH Preamble) over the 38
k. Once the BS acquires the reverse traffic channel, it sends the Base Station 40
traffic channel. 42

5
Message.
TIA-2001.3-C

Section 3 62

l. The MS acknowledges the reception of the Base Station Acknowledgment Order by 1
m. The BS then sends the Service Connect Message / Service Option Response Order to 3
the MS specifying the service configuration for the call. The MS begins processing 4
n. On receipt of the Service Connect Message the MS responds with a Service Connect 6
o. After the radio traffic channel and circuit have both been established, the BS sends 8
the Assignment Complete message to the MSC. 9
Upon receipt of the Assignment Complete message, the MSC stops timer T
10
, and 10
starts timer T
301
. 11
p. The BS sends the Alert with Information Message to the MS to cause ringing at the 12
MS. 13
q. The MS acknowledges the reception of the Alert with Information Message by 14
r. When the call is answered at the MS, a Connect Order, with acknowledgment 16
s. The BS acknowledges the Connect Order with the Base Station Acknowledgment 18
t. The BS sends a Connect message to the MSC to indicate that the call has been 20
answered at the MS. Upon receipt of the Connect message from the BS, the MSC 21
stops timer T
301
. At this point, the call is considered stable and in the Conversation 22
State. 23
3.2 Call Clearing of Voice and Circuit Data Calls 24
There are two types of clearing call flows over the A1 interface: 25
1. Call clearing for a single service that is not the only one connected. 26
2. Call clearing of all services connected (including the case where only one service is 27
connected). 28
For call flows showing call clearing involving concurrent services (call clearing for a 29
single service that is not the only one connected), refer to section 3.18. The call clearing 30
call flows shown in this section apply when all services are cleared. 31
Call clearing may be initiated by either the BS, the MS, the PDSN/PCF, or the MSC. 32
Call clearing of packet data call flows is specified in section 3.17. 33
3.2.1 Call Clearing Initiated by the MS or BS 34
When the MS initiates a normal clearing of all services including the only service 35
connected, the MS sends a Release Order to the BS. The BS shall send a Clear Request 36
message to the MSC and start timer T
300
to wait for the Clear Command message from 37
the MSC. For packet data calls, call clearing does not normally clear the service session. 38
The service session is cleared using call flows in this section for conditions such as MS 39
power down, termination of the PPP session by the MS or the network, etc. 40
TIA-2001.3-C

63 Section 3

The MSC is responsible for clearing A1, A2, and/or A5 connections associated with the 1
call. To release all allocated resources associated with all services, the MSC shall send a 2
Clear Command message to the BS. The BS responds with a Clear Complete message 3
and stops timer T
300
. The call flow scenarios are illustrated in section 3.2.4.3. 4
If the MS is not active (powered off) or if for any reason the radio channel failed between 5
the MS and the BS or if some internal BS failure occurs, then the BS initiates call 6
clearing. The BS sends a Clear Request message to the MSC. The MSC responds with a 7
Clear Command message to the BS and waits for a Clear Complete message from the BS. 8
The scenario is illustrated in section 3.2.4.2. 9
Refer to [14] for unsuccessful call clearing procedures related to the Service Release, 10
Clear Request and Clear Command messages. 11
3.2.2 Call Clearing Initiated by the MSC 12
When the MSC chooses to deny call setup initiated by the reception of a CM Service 13
Request or Paging Response message contained in an SCCP Connection Request, the 14
MSC may send an SCCP Connection Refused containing no user data. 15
3.2.2.1 Clear from the Network 16
When the MSC initiates a normal clearing of a single service that is not the only service 17
connected, the MSC sends a Service Release message to the BS and starts timer T
308
to 18
wait for a Service Release Complete message from the BS. This normal call clearing 19
scenario is illustrated in section 3.18.4.2. 20
In case the MSC initiates a normal clearing of all services including the only one 21
connected, the MSC shall send a Clear Command message to the BS, start timer T
315,
22
and wait for a Clear Complete message from the BS. Timer T
315
is stopped when the 23
Clear Complete message is received. This normal call clearing scenario is illustrated in 24
section 3.2.4.3. 25
3.2.2.2 Call Clearing when Tones/Announcements are Provided 26
Call clearing messages are not affected if the network provides either tones or 27
announcements immediately before clearing a call. 28
3.2.3 Call Clearing Collision 29
Call clearing collision occurs in the following cases: 30
1. The BS sends a Clear Request message and the MSC simultaneously sends a Clear 31
Command message. 32
When the MSC receives the Clear Request message, it shall note it and continue to wait 33
for the Clear Complete message. When the BS receives the Clear Command message, it 34
shall complete the call clearing. 35
2. The BS and MSC simultaneously send Service Release messages and each Service 36
Release message contains the same Service Option Connection Identifier (SOCI). 37
TIA-2001.3-C

Section 3 64

When the MSC receives the Service Release message, it shall note it and continue to wait 1
for a Service Release Complete message. When the BS receives the Service Release 2
message, stop timer T
308
and send a Service Release Complete message to the MSC. 3
3. The BS and MSC simultaneously send Service Release messages and each Service 4
Release message contains different SOCI. 5
When the MSC receives the Service Release message and the MSC realizes that all 6
services are being released, the MSC sends the Clear Command message to the BS and 7
starts timer T
315
. When the BS receives the Clear Command message it stops timer T
308
8
and shall proceed with the normal call clearing call flows as in 3.2.4.3.1. 9
4. The BS sends a Service Release message and the MSC simultaneously sends a Clear 10
Command message. 11
When the BS receives the Clear Command message, it shall complete the clearing of all 12
services including the only one connected and send a Clear Complete message to the 13
MSC. The BS then stops timer T
308
. When the MSC receives the Service Release 14
message, it shall note it and continue to wait for a Clear Complete message. 15
5. The BS sends a Clear Request message and the MSC simultaneously sends a Service 16
Release message 17
When the MSC receives the Clear Request message, it shall send a Clear Command 18
message and stop timer T
308
. The MSC starts timer T
315
to wait for a Clear Complete 19
message. When the BS receives the Service Release message, it shall note it and continue 20
to wait for a Clear Command message. 21
3.2.4 Call Flows for Call Clear Operation 22
The following subsections provide the call flows for call clearing operations. 23
3.2.4.1 Call Clear via Clear Request (MS Initiated) 24
In this example, when the MS initiates call clearing by sending a Release Order to the 25
BS, the BS sends a Clear Request message to the MSC and waits to receive a Clear 26
Command message. 27

MS MSC
time comment
release
a
b
c
d
Clear Request
Clear Command
Clear Complete
release
T300
T315
e
BS
28
Figure 3.2.4.1-1 Call Clear Initiated by MS 29
TIA-2001.3-C

65 Section 3

a. The MS initiates call clearing by transmitting a release
6
over the reverse traffic 1
channel. 2
b. The BS then sends the Clear Request message to the MSC to initiate the call clear 3
transaction. Timer T
300
is started by the BS. 4
c. The MSC sends a Clear Command message to the BS to instruct the BS to release 5
the associated dedicated resource (such as terrestrial circuit) and starts timer T
315
. 6
300
. 7
d. In response to the Clear Command message, the BS releases the terrestrial circuit, if 8
allocated. The BS then acknowledges the MS by sending it a release over the 9
forward traffic channel and releases the radio resource. 10
e. The BS returns a Clear Complete message to the MSC. The MSC stops timer T
315
11
upon receipt of the Clear Complete message. The MSC releases the underlying 12
transport connection. 13
3.2.4.2 Call Clear via Clear Request (BS Initiated) 14
In this example, if the BS decides to clear the call because of radio channel failure or 15
other reasons, the BS initiates call clearing by sending a Clear Request message to the 16
MSC. 17
MS BS MSC
time comment
a
b
c
Clear Request
Clear Command
Clear Complete
T300
T315
18
Figure 3.2.4.2-1 Call Clear Initiated by BS (via Clear Request) 19
a. If the BS decides to clear the call because of radio channel failure or other reasons, 20
the BS sends a Clear Request message to the MSC. The BS starts timer T
300
and 21
waits for the Clear Command from the MSC. 22
b. The MSC sends a Clear Command message to instruct the BS to release the 23
associated dedicated resource (such as terrestrial circuit) and starts timer T
315
. The 24
BS stops timer T
300
. 25
c. The BS returns a Clear Complete message. The MSC stops timer T
315
upon receipt 26
of the Clear Complete message and releases the underlying transport connection. 27
3.2.4.3 Call Clear via Clear Command 28
In this example, the MSC initiates call clearing by using the Clear procedure (Clear 29
Command and Clear Complete messages). 30

6
This may be a Release Order, Extended Release Message or Extended Release (Mini)
Message as appropriate.

TIA-2001.3-C

Section 3 66

MS MSC
time comment
b
c
Clear Command
Clear Complete
release
release
a
d
T315
BS
1
Figure 3.2.4.3-1 Call Clear Initiated by MSC (via Clear Command) 2
a. The MSC sends a Clear Command message to the BS to instruct the BS to release 3
the associated dedicated resource and starts timer T
315
. 4
b. The BS initiates call clearing over the air interface by transmitting a release over the 5
forward traffic channel. 6
c. The MS acknowledges the Release Order by returning a release over the reverse 7
traffic channel. 8
d. The BS returns a Clear Complete message. The MSC stops timer T
315
upon receipt 9
of the Clear Complete message and releases the underlying transport connection. 10
3.3 TFO Support 11
This section describes call flows associated with Tandem Free Operation. Refer to 12
section 2.3 for more description of this feature. 13
3.3.1 Call Flows for Transcoder Control 14
Figure 3.3.1-1 shows the Transcoder Control call flow. 15
Time
a
b
BS MSC
Transcoder Control Acknowledge
Transcoder Control Request
T309
Comment
16
Figure 3.3.1-1 Transcoder Control Call Flow 17
a. The MSC sends a Transcoder Control Request message to enable or disable the 18
inband signaling mechanism at the BS. If the inband signaling mechanism is already 19
enabled and the call is not in the TFO Operation state, an enable directive simply 20
resets the inband signaling state machine logic. Timer T
309
is started by the MSC. 21
b. Upon receipt of the Transcoder Control Request message, the BS sets the inband 22
signaling mechanism to the appropriate state and returns a Transcoder Control 23
Acknowledge message without a cause value if TFO operation was successfully 24
enabled/disabled. A Transcoder Control Acknowledge message with a cause value 25
TIA-2001.3-C

67 Section 3

indicating failure is sent if the BS is unable to process the Transcoder Control 1
Request directive. The MSC stops timer T
309
. 2
3.4 Test Calls 3
Test calls initiated by the MS use the call flows described in section 3.1.1. Test calls 4
initiated by the MSC use the call flows described in section 3.1.2. Handoff of test calls is 5
not supported in this standard. 6
3.5 Support of DTMF 7
This feature is supported using existing call flows. 8
3.6 Support of Supplementary Services 9
The following subsections contain call flows demonstrating the procedures for supporting 10
Supplementary Services. Refer to section 2.6 for overview descriptions of these features. 11
The features defined in [21] generally involve transactions between the MSC and the MS. 12
The required information is passed through the BS using the following messages: 13
Flash with Information 14
Flash with Information Ack 15
Feature Notification 16
Feature Notification Ack 17
CM Service Request 18
Clear Command 21
Clear Complete. 22
3.6.1 Feature Activation and Deactivation 23
The sections below indicate the call flows used to handle feature activation and 24
deactivation both when the MS is idle and is in a call. 25
3.6.1.1 Feature Activation/Deactivation in Idle Mode 26
3.6.1.2 Feature Activation/Deactivation While in a Call 28
29
TIA-2001.3-C

Section 3 68

MS BS MSC
time comment
a
Flash with Information
c
b
In-Band information
1
Figure 3.6.1.2-1 Feature Activation/Deactivation While in a Call 2
a. The MS sends a Flash with Information message to the BS to pass a string of digits 3
and end marks to request feature activation/deactivation. 4
b. The BS places the string of digits and end marks in a Flash with Information 5
message and sends it to the MSC. 6
c. The MSC generates in-band tones or announcements. 7
3.6.2 Call Waiting 8
This section provides the call flow description for the call waiting feature. 9
MS BS MSC
time comment
b
c
e
f
a
d
10
Figure 3.6.2-1 Call Waiting 11
a. The MSC sends a Flash with Information message to the BS to alert the MS that 12
there is a call waiting. 13
b. The BS takes the information from the MSC and sends a Flash with Information 14
message to the MS. 15
c. The MS sends the Flash with Information message to the BS to indicate the 16
acceptance of the second call. 17
d. The BS sends a Flash with Information message to the MSC. The MSC then places 18
the original call on hold and connects the second call to the MS. 19
TIA-2001.3-C

69 Section 3

e. To toggle between the two callers, the MS sends the Flash with Information message 1
to the BS. 2
f. The BS sends a Flash with Information message to the MSC. The MSC then places 3
the second call on hold and reconnects the original call to the MS. 4
The MSC may optionally apply an inband tone to alert the user of a waiting call. Such an 5
action takes the place of or supplements steps a and b above. 6
If an MS releases an active call after receiving a call waiting notification, and while a call 7
is waiting, the active call is cleared using normal call release call flows as described in 8
section 3.2.4.3, and the waiting call is offered using normal mobile termination call 9
flows, as described in section 3.1.2. 10
If an MS releases the active call while another call is held (by the Call Waiting feature), 11
the active call is cleared using normal call release call flows as described in section 12
3.2.4.2, and the held call is offered using normal mobile termination call flows, as 13
described in section 3.1.2. 14
3.6.3 Three Way Calling 15
3.6.3.1 Three-Way Calling (Method 1) 16
This section provides the call flow description for the Three-Way Calling feature 17
(Method 1). 18
MS BS MSC
time comment
a
b
c
d
Flash with Information (2nd party called address)
e
f
g
h
19
Figure 3.6.3.1-1 Three-Way Calling (Method 1) 20
a. To initiate Three-Way Calling while a call is in progress, the MS sends a Flash with 21
Information Message to the BS to request the original call be placed on hold. 22
b. The BS sends the Flash with Information message to the MSC. The MSC places the 23
original call on hold. 24
c. The MS sends a Flash with Information Message to the BS containing the dialed 25
digits of the second party. 26
TIA-2001.3-C

Section 3 70

d. The BS sends a Flash with Information message to the MSC with the dialed digits of 1
the second party. Once the second party answers, it is connected to the MS. 2
e. The MS sends a Flash with Information Message to the BS to request connection of 3
all three parties. 4
f. The BS sends a Flash with Information message to the MSC. The MSC places all 5
three parties in a conference call. 6
g. To disconnect the second party, the MS sends a Flash with Information Message to 7
the BS. 8
h. The BS sends a Flash with Information message to the MSC, which disconnects the 9
second call. 10
3.6.3.2 Three-Way Calling - (Method 2) 11
This section provides the call flow description for the Three-Way Calling feature 12
(Method 2). In Method 2, the called address information of the second call is sent during 13
the first hook flash indication from the MS. 14
MS BS MSC
time comment
a
b
Flash with Information (2nd party called address)
c
d
e
f
15
Figure 3.6.3.2-1 Three-Way Calling (Method 2) 16
a. To initiate Three-Way Calling while a call is in progress, the MS sends a Flash with 17
Information Message containing the dialed digits of the second call to the BS. 18
b. The BS sends a Flash with Information message to the MSC along with the dialed 19
digits of the second party. The MSC places the original call on hold and starts call 20
setup procedures for the second party. Once the second party answers, it is connected 21
to the MS. 22
c. The MS sends a Flash with Information Message to the BS to request connection of 23
all three parties. 24
d. The BS sends a Flash with Information message to the MSC. The MSC places all 25
three parties in a conference call. 26
e. To disconnect the second party, the MS sends a Flash with Information Message to 27
the BS. 28
f. The BS sends a Flash with Information message to the MSC, which disconnects the 29
second call. 30
TIA-2001.3-C

71 Section 3

3.6.4 Message Waiting Notification 1
3.6.4.1 Message Waiting Notification on the Paging Channel 2
The following example demonstrates the delivery of a Message Waiting Indication via 3
the Feature Notification message over the control channel. 4

MS BS MSC
time comment
b
c
d
Feature Notification Ack
Layer 2 Ack
a
Feature Notification
T63
5
Figure 3.6.4.1-1 Message Waiting Notification on the Paging Channel 6
a. The MSC sends a Feature Notification message containing message waiting 7
information and starts timer T
63
. 8
b. The BS sends a Feature Notification Message to the MS. 9
c. The MS acknowledges the receipt of the message by a Layer 2 Ack. 10
d. BS sends the Feature Notification Ack message to the MSC. The MSC stops timer 11
T
63
. 12
3.6.4.2 Message Waiting Notification on the Traffic Channel 13
The following example shows the delivery of a Message Waiting Indication to the MS 14
while on a traffic channel via the Flash with Information message. 15

MS BS MSC
time comment
b
c
d
Flash with Information Ack
Layer 2 Ack
a
T62
16
Figure 3.6.4.2-1 Message Waiting Notification on the Traffic Channel 17
a. When the MS is on traffic channel, the MSC may include message waiting 18
information in the Flash with Information message to inform the MS that there are 19
zero or more messages waiting. In this scenario, it is assumed that the MSC also 20
includes the Tag element in the Flash with Information message to request that the 21
BS notify the MSC when a Layer 2 Ack is received from the MS. The MSC starts 22
timer T
62
. 23
b. The BS sends the information in the Flash with Information air interface message. 24
TIA-2001.3-C

Section 3 72

c. Once the MS has received the Flash with Information message, it responds with a 1
Layer 2 Ack message. 2
d. The BS sends the Flash with Information Ack message to the MSC including the Tag 3
element included by the MSC in the Flash with Information message. The MSC 4
stops timer T
62
. 5
3.6.5 Call Barring 6
This section contains call flows associated with the Call Barring Feature. 7
3.6.5.1 Call Barring Incoming 8
Call Barring Incoming is transparent to the IOS. 9
3.6.5.2 Call Barring Outgoing 10
Clear Command
Clear Complete
T315
b
c
d
a
Mobile Originated Call
release
release
e
MS BS MSC
Time
11
Figure 3.6.5.2-1 Call Barring Outgoing 12
a. The MS originates a call; refer to steps a m in section 3.1.1.1. 13
b. If the MSC determines that the call should be blocked, it applies treatment 14
(announcement), sends a Clear Command to instruct the BS to release the associated 15
dedicated resources and starts timer T
315
. 16
c. The BS sends a release to the MS. 17
d. The MS sends a release to the BS. 18
e. The BS returns the Clear complete message and the MSC stops timer T
315
. 19
TIA-2001.3-C

73 Section 3

3.6.6 Calling Number ID Presentation/Restriction 1
For mobile originated CNIR, refer to the call flows in section 3.1.1. 2
For mobile terminated CNIP/CNIR, if the MS is idle, the CNIP/CNIR information is sent 3
in the Assignment Request message. The call flows for this feature are identical to the 4
call flows for a mobile terminated call, refer to section 3.1.2. 5
If the MS user subscribes to the Call Waiting (CW) feature and is engaged in a call, the 6
CNIP/CNIR information is sent in the Flash with Information message. The call flow for 7
this feature is identical to the call flow for Call Waiting; refer to section 3.6.2. 8
3.6.7 Distinctive Ringing 9
The call flows for this feature are identical to the call flows for a mobile terminated call; 10
3.6.8 Answer Holding 12
This section provides the call flows description for Answer Holding. The following types 13
of Answer Holding may occur: 14
Answer Holding of a Mobile Terminated Call 15
Answer Holding of Call Waiting. 16
3.6.8.1 Answer Holding of a Mobile Terminated Call 17
This call flow describes Answer Holding of a Mobile Terminated Call. 18

MS BS MSC
time comment
c
d
e
Assignment Complete
b
a
Alert with Info
Flash With Information
T301
Terminating call setup
f
g
19
Figure 3.6.8.1-1 Answer Holding of a Mobile Terminated Call 20
region and uses the normal procedure for terminating call setup. Refer to steps a 22
through l in section 3.1.2.1. 23
TIA-2001.3-C

Section 3 74

b. After the radio traffic channel and circuit have both been established, the BS sends 1
the Assignment Complete message to the MSC. The MSC starts timer T
301
. 2
c. The BS sends the Alert with Information Message to the MS to cause ringing at the 3
MS. 4
d. The MS decides to invoke answer holding of the call and sends a Flash with 5
Information Message to the BS with an indication that the call shall be put on hold. 6
e. The BS sends a Flash with Information message to the MSC with the indication that 7
the call shall be put on hold. The MSC stops timer T
301
. 8
f. At some later time, the MS decides to answer the call that is holding. The MS sends 9
a Flash With Information Message to the BS. 10
g. The BS sends a Flash With Information message to the MSC to connect the call. 11
3.6.8.2 Answer Holding of Call Waiting 12
This call flow describes the Answer Holding of Call Waiting. 13

MS BS MSC
time comment
b
c
a
d
e
f
14
Figure 3.6.8.2-1 Answer Holding of Call Waiting 15
Message to the MS. 19
c. The MS sends the Flash with Information Message to the BS to indicate that the new 20
call shall be put on hold. 21
d. The BS sends a Flash with Information message to the MSC with the indication that 22
the new call shall be put on hold. 23
e. At some later time, the MS decides to answer the call that is holding. The MS sends 24
a Flash With Information Message to the BS. 25
f. The BS sends a Flash With Information message to the MSC to connect the call. 26
TIA-2001.3-C

75 Section 3

3.6.9 User Selective Call Forwarding 1
This section provides the call flows description for User Selective Call Forwarding. The 2
following types of User Selective Call Forwarding may occur: 3
User Selective Call Forwarding of a Mobile Terminated Call 4
User Selective Call Forwarding of Call Waiting. 5
3.6.9.1 User Selective Call Forwarding of a Mobile Terminated Call 6
This call flow describes the User Selective Call Forwarding of a Mobile Terminated Call. 7
MS BS MSC
time comment
c
d
e
f
Assignment Complete
b
a
Alert with Info
T301
Terminating call setup
Network initiated call clearing
8
Figure 3.6.9.1-1 User Selective Call Forwarding of Mobile Terminated Call 9
region and uses the normal procedure for terminating call setup. Refer to steps a 11
through l in section 3.1.2.1. 12
b. After the radio traffic channel and circuit have both been established, the BS sends 13
the Assignment Complete message to the MSC. The MSC starts timer T
301
. 14
c. The BS sends an Alert with Information Message to the MS to cause ringing at the 15
MS. 16
d. The MS decides to invoke user selective call forwarding of the call and sends a Flash 17
with Information Message to the BS with an indication that the call shall be 18
forwarded. 19
e. The BS sends a Flash with Information message to the MSC with the indication that 20
the call shall be forwarded. The MSC stops timer T
301
. 21
f. The MSC initiates a network initiated call clearing. 22
3.6.9.2 User Selective Call Forwarding of Call Waiting 23
This call flow describes the User Selective Call Forwarding of Call Waiting. 24
TIA-2001.3-C

Section 3 76

MS BS MSC
time comment
b
c
a
d
1
Figure 3.6.9.2-1 User Selective Call Forwarding of Call Waiting 2
Message to the MS. 6
c. The MS sends a Flash with Information Message to the BS to indicate that the call 7
shall be forwarded. 8
d. The BS sends a Flash with Information message to the MSC with the indication that 9
the call shall be forwarded. 10
3.7 Mobile Registration 11
This section describes procedures related to Registration and Deregistration. 12
Successful location registration requests involve the exchange of the following A1 13
messages: 14
Complete Layer 3 Information with Location Updating Request 15
Authentication Request / Authentication Response (optional) 16
Location Updating Accept 17
Registration Request (Network initiated registration). 18
The call flows for the location update request procedure are illustrated in Figure 3.7.1 and 19
3.7.3. 20
When authentication is supported by the BS/MSC, a challenge RAND is broadcast on the 21
control channel. RAND is specified in [14] and utilized for the process of registration, 22
call origination and call termination. The MS utilizes the broadcast RAND to compute 23
the Authentication Response AUTHR specified in [14]. 24
The Location Updating Request message is sent by the BS to notify the MSC of a 25
registration attempt by the MS. 26
When the network performs an autonomous registration of an MS (refer to [32]), the 27
MSC sends the Mobile Station Registered Notification message to the serving BS. This 28
TIA-2001.3-C

77 Section 3

message directs the BS to send the Mobile Station Registered Message [5] on the traffic 1
channel to the MS to notify the MS of this registration. 2
The call flow for the use of Mobile Station Registration Notification message is 3
illustrated in section 3.7.4. 4
3.7.1 Mobile Initiated Location Registration 5
The call flow in Figure 3.7.1-1 provides an illustration of a successful Location 6
Registration procedure initiated by the MS. 7

MS BS MSC
time comment
Registration Message
Registration Accepted Order
a
b
c
d
Location Updating Request
Location Updating Accept T3210

8
Figure 3.7.1-1 Location Registration - Successful Case 9
a. The MS initiates a registration operation by sending the Registration Message to the 10
BS. 11
b. On reception of the Registration Message the BS constructs the Location Updating 12
Request message, places it in the Complete Layer 3 Information message, and sends 13
it to the MSC. The BS then starts timer T
3210
. 14
c. The MSC sends the Location Updating Accept message to the BS to indicate that the 15
Location Updating Request message has been processed. 16
Upon receipt of the Location Updating Accept message, the BS stops timer T
3210
. 17
d. The BS may transmit a Registration Accepted Order to the MS to indicate successful 18
location registration operation. 19
3.7.2 Power Down Registration at the End of a Call 20
The MS may send a power down indication in a Release Order when clearing a call. The 21
BS shall forward a power down indication to the MSC by including the Power Down 22
Indicator element in the Clear Complete message. Refer to [14] Clear Complete for 23
more information. 24
3.7.3 Network Initiated Location Registration 25
The call flow in Figure 3.7.3-1 provides an illustration of a successful Network Initiated 26
Location Registration procedure. 27
TIA-2001.3-C

Section 3 78

MS BS MSC
time comment
c
d
e
f
Location Updating Accept T3210
Registration Request a
b
Registration Request Order
Tordreg
1
Figure 3.7.3-1 Network Initiated Location Registration - Successful Case 2
a. The MSC initiates an ordered registration procedure by sending a Registration 3
Request message to the BS. The MSC starts timer T
ordreg
. 4
b. The BS sends a Registration Request Order to the MS on the common signaling 5
channel. 6
c. The MS responds by sending the Registration Message to the BS. 7
d. Upon reception of the Registration Message, the BS constructs the Location 8
Updating Request message, places it in the Complete Layer 3 Information message, 9
and sends it to the MSC. The BS then starts timer T
3210
. 10
Upon receipt of the Location Updating Request message from the BS, the MSC stops 11
timer T
ordreg
. 12
e. The MSC sends the Location Updating Accept message to the BS to indicate that the 13
Location Updating Request message has been processed. Upon receipt of the 14
Location Updating Accept message, the BS stops timer T
3210
. 15
f. The BS may transmit a Registration Accepted Order to the MS to indicate successful 16
location registration operation. 17
3.7.4 Mobile Station Registered Notification 18
The call flow in Figure 3.7.4-1 provides an illustration of the Mobile Station Registered 19
Notification procedure. 20
TIA-2001.3-C

79 Section 3

b
time
Mobile Station Registered Notification
Mobile Station Registered Message
a
MSC performs autonomous
registration
Layer 2 Ack
c

BS
MS
MSC
comment
1
Figure 3.7.4-1 Mobile Station Registered Notification 2
a. The MSC sends a Mobile Station Registered Notification message to the serving BS 3
following an autonomous registration of an MS. 4
b. Upon receipt of the Mobile Station Registered Notification message, the BS sends 5
the Mobile Station Registered Message to the MS. 6
c. The MS may acknowledge the receipt of the message by a Layer 2 Ack. 7
3.8 Global Emergency Call Origination 8
3.9 E911 Phase I and Phase 2 10
This feature also uses Mobile Position Determination; refer to section 3.13. 12
3.10 Short Message Service 13
This section contains descriptions and call flows for the Short Message Service feature. 14
Refer to section 2.10 for more details on this feature. 15
3.10.1 SMS Feature Description 16
The subsections below contain descriptions of the following SMS cases: 17
SMS Mobile Originated Point-to-Point 18
SMS Mobile Terminated Point-to-Point 19
SMS Broadcast 20
3.10.1.1 SMS - Mobile Originated Point-to-Point 21
A mobile originated SMS (SMS-MO) message may be sent from the MS to the BS on 22
either a control (access) or traffic channel. 23
TIA-2001.3-C

Section 3 80

An MS already on a traffic channel uses that traffic channel to send an SMS-MO 1
message. An idle MS may use either an Access Channel, or may request a traffic channel 2
for delivery of an SMS-MO message. If an idle MS wants to use a traffic channel to send 3
an SMS-MO message, it sends an Origination Message with the short message service 4
option number in the service option field. The call origination call flows described in 5
section 3.1.1 are then used. Once the traffic channel is established the transport of the 6
SMS-MO message on the MSC-BS interface is accomplished by sending an Application 7
Data Delivery Service (ADDS) Deliver message from the BS to the MSC. If the Access 8
Channel is used for SMS-MO message transmission from the MS to the BS, then no call 9
establishment is performed. When the SMS-MO message is transmitted from the MS to 10
the BS on an Access Channel, the transport of the SMS-MO message on the A1 interface 11
is accomplished by sending an Application Data Delivery Service (ADDS) Transfer 12
message from the BS to the MSC. 13
3.10.1.2 SMS - Mobile Terminated Point-to-Point 14
An SMS Mobile Terminated (SMS-MT) message can be transmitted from the BS to the 15
MS on either a common or traffic channel. An SMS-MT message intended for an MS 16
already on a traffic channel is sent on that traffic channel. 17
When the SMS-MT message is sent to the MS on a traffic channel, the transport of the 18
SMS-MT message on the A1 interface is accomplished by sending the ADDS Deliver 19
message from the MSC to the BS. 20
When the SMS-MT message is sent to the MS on a common channel, the transport of the 21
SMS-MT message on the A1 interface is accomplished by sending the ADDS Page 22
message from the MSC to the BS. 23
3.10.1.3 SMS - Broadcast 24
SMS Broadcast is a mobile terminated short message that is sent to all MSs operating 25
within the BS serving region. The broadcast address determines which MSs receive the 26
message. 27
When the MSC sends an SMS Broadcast message to idle MSs, the message is sent from 28
the MSC to the BS using an ADDS Page message. 29
3.10.2 SMS Delivery on a Common Channel 30
The delivery of SMS-MT, SMS-MO, and SMS-Broadcast messages on a common (e.g. 31
Paging or Common Control) channel is accomplished by the exchange of ADDS Page, 32
ADDS Page Ack, and ADDS Transfer messages. 33
The ADDS Page is sent from the MSC to the BS and is used for SMS-MT and SMS- 34
Broadcast messages. It may be acknowledged with the ADDS Page Ack message. 35
The ADDS Transfer message is sent from the BS to the MSC when the BS receives a 36
Data Burst message on the Access Channel. 37
This section contains examples of SMS delivery on the control channel. 38
TIA-2001.3-C

81 Section 3

3.10.2.1 SMS Broadcast Delivery over a Common Channel 1
This section provides the call flow description for SMS Broadcast delivery over a 2
common channel. 3

MS BS MSC
time comment
b
c
ADDS Page Ack
a
ADDS Page
Data Burst Message
T3113
4
Figure 3.10.2.1-1 SMS-Broadcast Delivery to MSs over a Common Channel 5
a. The MSC receives SMS Broadcast information for delivery to idle MSs. 6
The MSC sends an ADDS Page message to the BS. The ADDS Page contains the 7
SMS Broadcast message in its ADDS User Part information element. 8
If the MSC requires an acknowledgment to the ADDS Page message, the Tag 9
element shall be included in the ADDS Page message and starts timer T
3113
. 10
b. If the MSC requested an acknowledgment from the BS by including the Tag element 11
in the ADDS Page message, the BS replies with an ADDS Page Ack message 12
including the Tag element set to the same value as received from the MSC. The 13
MSC stops timer T
3113
, if it was started
..
14
c. The BS sends the SMS Broadcast information to the appropriate MSs over the 15
Paging Channel or Forward Common Control Channel. The BS does not request that 16
the MSs receiving the SMS broadcast message send Layer 2 Acks. 17
3.10.2.2 SMS Receipt from an MS on the Access Channel 18
This section provides the call flow description for the receipt of an SMS-MO message on 19
the Access Channel. 20
Time
a
b
c
MS BS MSC
ADDS Transfer
Data Burst Message
Layer 2 Ack
21
Figure 3.10.2.2-1 SMS-MO Delivery on the Access Channel 22
a. The MS sends a point-to-point SMS message to the network on the Access Channel. 23
b. If the MS had requested a Layer 2 Ack, the BS acknowledges the short message 24
received on the Access Channel by sending a Layer 2 Ack on the Paging Channel. 25
TIA-2001.3-C

Section 3 82

c. The BS sends an ADDS Transfer message to the MSC containing the SMS message 1
received from the MS in the ADDS User Part element. 2
3.10.2.3 SMS Delivery to an MS on a Common Channel - Example 1 3
This section provides the call flow description for the delivery of an SMS-MT message 4
on a common channel using the ADDS Page message. 5

MS BS MSC
time comment
b
c
d
ADDS Page Ack
Layer 2 Ack
a
ADDS Page
Data Burst Message
T3113
Conditional
Conditional
6
Figure 3.10.2.3-1 SMS-MT Delivery to an MS on a Common Channel - Example 1 7
a. The MSC determines that a point-to-point short message is to be sent to an idle MS. 8
The MSC sends an ADDS Page message to the BS. The ADDS Page contains the 9
short message in its ADDS User Part information element. 10
If the MSC requires an acknowledgment, it includes the Tag information element in 11
the ADDS Page message and starts timer T
3113
. 12
b. The BS sends the short message to the MS on the Paging Channel or the Forward 13
Common Control Channel. Before sending the short message, the BS may perform 14
vendor specific procedures such as paging the MS to determine the cell in which the 15
MS is located. 16
c. If a Layer 2 Ack was solicited, the MS acknowledges the receipt of the message by a 17
Layer 2 Ack. 18
d. If the MSC requested an acknowledgment by including the Tag information element 19
including the Tag information element set identical to the value sent by the MSC. If 21
timer T
3113
was previously started, it is now stopped. 22
3.10.2.4 SMS Delivery to an MS on a Common Channel - Example 2 (without Early Traffic 23
Channel Assignment) 24
This section provides an example call flow description for the delivery of an SMS-MT 25
message on a common channel without early traffic channel assignment by the BS. In 26
this example, the MS is first paged, and then held on the common signaling channel ( i.e. 27
not allowed to go to slotted mode) until the SMS messages are delivered. After delivery, 28
the MS is released. 29
TIA-2001.3-C

83 Section 3

MS BS MSC
time comment
g
h
i
ADDS Page Ack
Layer 2 Ack
f
ADDS Page
Data Burst Message
T3113
b
a
Paging Request
T3113
c
d
Page Message
MSC releases underlying
transport connection
k
Release Order
e
j
Conditional
Conditional
T303
1
a. The MSC sends a Paging Request message to the BS and starts timer T
3113
. 3
b. The BS sends a Page Message on the Paging Channel. 4
c. The MS responds with a Page Response Message. 5
d. The BS sends a Complete Layer 3 Information message containing a Paging 6
Response message to the MSC. The MSC stops timer T
3113
and starts timer T
303
. 7
e. The BS sends a Base Station Ack Order to acknowledge the Page Response Message 8
from the MS. 9
f. The Radio Environment and Resources element in the Paging Response message 10
indicates no early traffic channel assignment by the BS. The MSC sends an ADDS 11
Page message to the BS. The ADDS Page message contains the short message in its 12
ADDS User Part information element. 13
3113
. 15
g. The BS sends the short message to the MS on either the Paging Channel or the 16
Forward Common Control Channel. 17
h. If a Layer 2 Ack was solicited, the MS acknowledges the receipt of the message by a 18
Layer 2 Ack. 19
i. If the MSC requested an acknowledgment by including the Tag information element 20
timer T
3113
TIA-2001.3-C

Section 3 84

j. The MSC releases the underlying transport connection to clear the pending page 1
response. The BS stops timer T
303
during this process. 2
k. The BS, upon the release of the underlying transport connection, sends a Release 3
Order to the MS. 4
3.10.2.5 SMS Delivery to an MS on a Common Channel - Example 3 (with Early Traffic 5
Channel Assignment) 6
message on a common channel with early traffic channel assignment by the BS. 8

MS BS MSC
time comment
g
h
i
ADDS Page Ack
Layer 2 Ack
f
ADDS Page
Paging Channel SMS Delivery
T3113
b
a
Paging Request
T3113
c
d
Page Message
k
l
Release Order
Release Order
e
j
Conditional
Conditional
T303
m
TCH Setup
(MSC refuses underlying transport connection)
9
a. The MSC sends a Paging Request message to the BS and starts timer T
3113
. 11
b. The BS sends a Page Message on the Paging Channel. 12
c. The MS responds with a Page Response Message. 13
d. The BS sends a Complete Layer 3 Information message containing a Paging 14
Response message to the MSC and starts timer T
303
. The MSC stops timer T
3113
. 15
e. The BS sends a Base Station Ack Order to acknowledge the Page Response Message 16
from the MS. 17
f. The BS establishes a traffic channel to the MS. 18
g. The Radio Environment and Resources element in the Paging Response message 19
indicates early traffic channel assignment by the BS. The MSC refuses the 20
underlying transport connection. The BS stops timer T
303
. 21
TIA-2001.3-C

85 Section 3

h. The BS, upon the refusal of the underlying transport connection, sends a Release 1
Order to the MS. 2
i. The MS sends a Release Order to the BS to acknowledge the release. 3
j. The MSC sends an ADDS Page message to the BS. The ADDS Page contains the 4
short message in its ADDS User Part information element. Note that the MSC should 5
wait a sufficient amount of time after step g before sending this message, to allow 6
steps h and i to complete. 7
3113
. 9
k. The BS sends the short message to the MS on either the Paging Channel or Forward 10
Control Channel. 11
l. If a Layer 2 Ack was solicited, the MS acknowledges the receipt of the message by a 12
Layer 2 Ack. 13
m. If the MSC requested an acknowledgment by including the Tag information element 14
timer T
3113
3.10.2.6 SMS Delivery to an MS on a Common Channel - Example 4 using Registration 18
Procedures 19
message on a common signaling channel using registration procedures. It uses the MS 21
Registration Request message instead of the Paging Request message shown in section 22
3.10.2.5. 23
TIA-2001.3-C

Section 3 86

MS BS MSC
time comment
f
g
ADDS Page Ack
Layer 2 Ack
e
ADDS Page
Data Burst (SMS)
T3113
b
a
Registration Request
Registration Accept Order
Tordreg
c
d
Location Update Request
Registration Request Order
Loaction Update Accept
i
j
h
Conditional
Conditional
T3210
Optional
1
a. The MSC sends a Registration Request message to the BS and starts timer T
ordreg
. 3
b. The BS sends a Registration Request Order on the common signaling channel. 4
c. The MS responds with a Registration Message. 5
d. The BS sends a Complete Layer 3 Information message containing a Location 6
Updating Request message to the MSC and starts timer T
3210
. The MSC stops timer 7
T
ordreg
. 8
e. The MSC sends a Location Updating Accept message to the BS. The BS stop timer 9
T
3210
. This message releases the SCCP connection. 10
f. The BS may optionally send a Registration Accept Order to the MS. 11
g. The MSC sends an ADDS Page message to the BS. The ADDS Page contains the 12
short message in its ADDS User Part information element. If the MSC requires an 13
acknowledgment, it includes the Tag information element in the ADDS Page 14
message and starts timer T
3113
. 15
h. The BS sends the short message to the MS on either the Paging Channel or Forward 16
Control Channel. 17
i. The MS acknowledges the receipt of the message by a Layer 2 Ack. 18
j. If the MSC requested an acknowledgment by including the Tag information element 19
timer T
3113
TIA-2001.3-C

87 Section 3

3.10.3 SMS Delivery on the Traffic Channel 1
This section describes the delivery of SMS messages on the traffic channel. 2
The delivery of Short Messages on the traffic channel is accomplished with the ADDS 3
Deliver and ADDS Deliver Ack messages on the A1 interface. 4
3.10.3.1 SMS Delivery to an MS on a Traffic Channel 5
This section provides the call flow description for delivery of an SMS-MT short message 6
on a traffic channel. 7
a
b
c
d
MS BS MSC
ADDS Deliver
Data Burst Message
ADDS Deliver Ack
Layer 2 Ack
Comment Time
e
Mobile is on a traffic channel
Mobile is on a traffic channel f
8
Figure 3.10.3.1-1 SMS Message Delivery to an MS on a Traffic Channel 9
a. The MSC determines that a short message is to be sent to the MS while it is on the 10
traffic channel. Alternatively, if the MS is not on a traffic channel, an SMS-MT call 11
is established using steps a-r in section 3.1.2.1; the service option used in this 12
case is either 6H or EH. 13
b. The MSC sends an ADDS Deliver message to the BS. The ADDS Deliver message 14
contains the short message in the ADDS User Part element. 15
c. The BS transmits the short message over the forward traffic channel. If the BS does 16
not receive an acknowledgment after transmitting the Data Burst message, it shall 17
retransmit the message. The BS shall not exceed a maximum number of 18
retransmissions, to be selected by the BS manufacturer. When the BS reaches the 19
maximum number of retransmissions, it shall declare a Layer 2 Ack failure and 20
initiate call clearing. 21
d. The MS acknowledges delivery of the short message on the traffic channel with a 22
Layer 2 Ack. 23
e. If the MSC has requested a response by including the tag element in the ADDS 24
Deliver message, the BS replies with an ADDS Deliver Ack message when it has 25
received acknowledgment from the MS that the message was delivered. If a Tag 26
element was included in the ADDS Deliver message, the BS shall include the Tag 27
element in the ADDS Deliver Ack message, and set it to the same value as that 28
received in the ADDS Deliver message. 29
TIA-2001.3-C

Section 3 88

f. The MS may remain on the traffic channel (e.g. if a voice call is in progress in step 1
a). Alternatively, the MSC may initiate call clearing if a traffic channel was 2
established in step a using SO 6H or EH. Refer to section 3.2.4.3. 3
3.10.3.2 SMS Receipt from an MS on a Traffic Channel 4
This section provides the call flow description for the receipt of an SMS-MO message on 5
a traffic channel. 6
a
b
c
MS BS MSC
ADDS Deliver
Data Burst Message
Layer 2 Ack
Time
d
e
7
Figure 3.10.3.2-1 SMS Receipt from an MS on a Traffic Channel 8
a. An MS that is currently on a traffic channel determines that a short message is to be 9
sent to the network. Alternatively, if the MS is not on a traffic channel, an SMS-MO 10
call is established using steps a-m in section 3.1.1.1; the service option used in 11
this case is either 6H or EH. 12
b. The BS receives a Traffic Channel SMS Delivery message from an MS on the traffic 13
channel with a burst type indicating SMS. 14
c. If a Layer 2 Ack was requested by the MS, the BS sends a Layer 2 Ack to the MS on 15
the traffic channel. 16
d. The BS sends an ADDS Deliver message to the MSC. The ADDS User Part element 17
contains the short message which was received from the MS. 18
e. The MS may remain on the traffic channel (e.g. if a voice call is in progress in step 19
a). Alternatively, the MS may initiate call clearing if a traffic channel was 20
established in step a using SO 6H or EH. Refer to section 3.2.4.1. 21
3.11 Priority Access and Channel Assignment (PACA) 22
The following subsections describe call flows associated with the PACA feature. Refer to 23
section 2.11 for more information on this feature. PACA service involves exchange of the 24
following A1 messages: 25
PACA Command 26
PACA Command Ack 27
TIA-2001.3-C

89 Section 3

PACA Update 1
PACA Update Ack 2
CM Service Request 3
Assignment Failure. 5
3.11.1 Mobile Origination with PACA Service 6
Two conditions may occur on a call origination with PACA service. Under the first 7
condition, the BS can not determine that radio resources are not available for a call before 8
sending the CM Service Request message to the MSC. In this case the origination call 9
flow shown in section 3.1.1.1 is followed. In the second case, the BS determines that 10
radio resources are not available for a call before sending the CM Service Request 11
message. In this second case, the origination call flow shown in section 3.11.1.1 is 12
followed. 13
3.11.1.1 Mobile Origination with PACA Service Radio Resources not Available 14
This section describes the call flow associated with an MS call origination with PACA 15
service in the system. 16
MS BS MSC
time comment
Origination Message
a
c
e
f
g
h
PACA Command Ack
T303
PACA Message
b
d
PACA Command
Tpaca1
PACA Message
PACA Message
17
Figure 3.11.1.1-1 Mobile Origination with PACA Service 18
a. The MS transmits an Origination, with Layer 2 Ack required, over the Access 19
Channel of the air interface to the BS to request service. The MS sets the 20
PACA_REORIG field to 0 to indicate a user-directed origination. 21
303
. The BS 25
includes the Radio Environment and Resources element in the CM Service Request 26
message. The Avail bit of the Radio Environment and Resources element is set to 27
0 to indicate that resources at the BS are not available. The PSI field in the 28
Classmark Information Type 2 IE is set to 1. 29
TIA-2001.3-C

Section 3 90

The MSC receives the call origination and dialed digits in the CM Service Request 1
message and determines that the call is eligible for PACA service. 2
d. The MSC sends a PACA Command message to inform the BS that PACA service 3
shall be applied to this call. The PACA Command message includes the Priority and 4
the PACA Time Stamp information elements to provide information to the BS for 5
PACA queuing. The MSC starts timer T
paca1
. Upon receipt of the PACA Command 6
message the BS stops timer T
303
. 7
e. Based on the information received in the PACA Command message the BS queues 8
the call. The BS sends a PACA Command Ack message to the MSC. The MSC stops 9
timer T
paca1
after receiving the acknowledgment. The MSC releases the underlying 10
transport connection. 11
f. The BS sends a PACA Message to the MS to indicate that the service request has 12
been queued and includes the queue position. 13
g. The BS may optionally send additional PACA messages over the Paging Channel to 14
update the MS on its PACA queue position. The BS may resend this message as 15
needed until radio resources become available. 16
h. When radio resources become available, the BS sends a PACA Message to instruct 17
the MS to re-originate the call. In this case, the PURPOSE field is set to 0010 to 18
request PACA re-origination. The normal Origination call flow (refer to section 19
3.1.1.1) processes the re-origination request. 20
3.11.1.2 Mobile Origination, Idle Handoff with PACA Active 21
This section describes the call flow associated with MS call origination with PACA 22
active in the system while idle handoff occurs. This scenario assumes that the idle 23
handoff is intra-MSC. 24

MS BS-1 MSC
time comment
b
c
d
PACA Update Ack
a
PACA Update
Tpaca2
BS-2
Origination Procedure with PACA Service
Involving the BS-2
Origination Procedure with PACA Service
Involving the BS-1
25
Figure 3.11.1.2-1 Mobile Origination, Idle Handoff with PACA Active 26
a. The MS previously attempted a call origination and the call has been queued as in 27
steps a through f of Figure 3.11.1.1-1. 28
b. While approaching the boundary of the cell, the MS detects an adequately strong 29
pilot signal transmitted by one of the neighboring cells (BS-1). The MS performs an 30
TIA-2001.3-C

91 Section 3

idle handoff and starts monitoring the new Paging Channel. The MS then transmits 1
an Origination Message, with Layer 2 Ack required, over the Access Channel of the 2
air interface to BS-1 to request service. In this case, the PACA_REORIG field 3
received in the Origination Message is set to 1. The re-origination request is 4
processed as in a normal Origination call flow (refer to section 3.1.1.1). 5
c. The MSC sends a PACA Update message to instruct BS-2 to remove the service 6
request from its PACA queue. The MSC can send the PACA Update message 7
anytime after receiving the CM Service Request message from BS-1. The MSC starts 8
timer T
paca2
. 9
d. BS-2 sends a PACA Update Ack message to the MSC to confirm that appropriate 10
action has been taken and that its PACA information has been updated. Upon receipt 11
of the PACA Update Ack message the MSC stops timer T
paca2
. 12
3.11.1.3 Mobile Origination with PACA Active, Consecutive PACA Calls 13
This section describes the call flow associated with a successful MS PACA call 14
origination with consecutive service requests in the system. In this scenario the MS 15
originates a PACA call to another number while the first call request is in a PACA queue. 16
The second call is placed in the queue, and the first call is removed. 17
MS BS MSC
time comment
b
c
d
PACA Update Ack
a
PACA Update
Tpaca2
Origination Procedure
with PACA Service
with PACA Service
18
Figure 3.11.1.3-1 Mobile Origination with Consecutive PACA Call Requests 19
b. While the first call request is pending, the MS sends an Origination Message, with 22
Layer 2 Ack required, over the Access Channel of the air interface to the BS to 23
request service using a different called party number. In this case, the 24
PACA_REORIG field received in the Origination Message is set to 0. Steps a 25
through f in Figure 3.11.1.1-1 are followed, and the second call is placed in the 26
PACA queue. 27
c. The MSC requests that the BS remove the first call from the PACA queue by 28
sending a PACA Update message to the BS with the PACA Order indicating 29
Remove MS from the queue. The MSC can send the PACA Update message 30
TIA-2001.3-C

Section 3 92

anytime after receiving the second CM Service Request message. The MSC starts 1
timer T
paca2
. 2
d. The BS sends a PACA Update Ack message to the MSC to confirm that the first call 3
has been removed from the PACA queue and that its PACA information has been 4
updated. Upon receipt of the PACA Update Ack message the MSC stops timer 5
T
paca2
. 6
3.11.2 PACA Call Cancellation Initiated by the MS 7
This section describes the call flow associated with cancellation of a PACA queued call 8
in the system. In this scenario the cancellation is initiated by the MS. 9
MS BS MSC
time comment
b
c
e
PACA Update Ack
a
PACA Update
Tpaca2
with PACA Service
PACA Cancel
d
BS Ack Order
10
Figure 3.11.2-1 PACA Call Cancellation Initiated by the MS 11
b. The MS sends a PACA Cancel Message, with layer 2 Ack required, over the Access 14
Channel of the air interface to the BS to request that the call be canceled. 15
c. The BS acknowledges the receipt of the PACA Cancel Message with a Base Station 16
d. The BS cancels the call and removes the request from its PACA queue. The BS then 18
sends a PACA Update message to the MSC to indicate that the call has been 19
canceled. The BS starts timer T
paca2
. 20
e. The MSC sends a PACA Update Ack message to the BS to confirm the receipt of the 21
PACA Update message. Upon receipt of the PACA Update Ack message the BS 22
stops timer T
paca2
. 23
3.11.3 PACA Call Cancellation Initiated by Either MSC or BS 24
This section describes the call flow associated with cancellation of a PACA call in the 25
system. In this example scenario the cancellation is initiated by the MSC. The BS- 26
initiated PACA call cancellation is identical except the BS sends the PACA Update 27
TIA-2001.3-C

93 Section 3

MS BS MSC
time comment
b
c
e
PACA Update Ack
a
PACA Update
Tpaca2
with PACA Service
PACA Message
d
MS Ack Order
MSC decides to
cancel the
queued PACA
call.
1
Figure 3.11.3-1 PACA Call Cancellation Initiated by the MSC 2
b. The MSC sends a PACA Update message to the BS with the PACA Order indicating 5
Remove MS from the queue and release MS. The MSC starts timer T
paca2
. 6
c. The BS cancels the call and removes the request from its PACA queue. The BS then 7
sends a PACA Message (PURPOSE=0011) to the MS to indicate that the PACA 8
call has been canceled. 9
d. The MS sends an MS Ack order to the BS to acknowledge PACA cancellation. 10
e. The BS sends a PACA Update Ack message to the MSC to confirm that appropriate 11
action has been taken by the BS and that its PACA information has been updated. 12
Upon receipt of the PACA Update Ack message the MSC stops timer T
paca2
. 13
3.12 Over-The-Air Service Provisioning (OTASP) and Over The Air 14
Parameter Administration (OTAPA) 15
This section describes the messages and call flows to support the OTASP and OTAPA 16
features over the A1 interface. These features are fully specified in [22]. 17
3.12.1 OTASP Support 18
This section describes the messages and call flows to support OTASP calls. This includes 19
a mechanism for transporting OTASP data messages, as defined in [22]. The processing 20
of OTASP forward and reverse data messages at the MSC or BS is the responsibility of 21
the vendors. The air interface between the BS and MS is described in [22] and the MSC 22
interface to the network is addressed in [24]. 23
Successful OTASP processing involves the following procedures and exchange of some 24
A1 interface messages: 25
1. OTASP Call Setup procedure 26
2. OTASP Data Exchange procedure which includes exchange of following messages: 27
TIA-2001.3-C

Section 3 94

ADDS Deliver 1
ADDS Deliver Ack 2
Some existing procedures may also be applied as sub-procedures: 3
SSD update procedure 4
Privacy Mode request procedure 5
3. OTASP Call Clearing procedure 6
3.12.1.1 OTASP Call Setup 7
Normal call setup procedures for mobile origination (refer to section 3.1.1) are used to 8
establish the OTASP call. 9
3.12.1.2 OTASP Data Exchanges 10
After a traffic channel has been set up, the ADDS Deliver message is used in both 11
directions to support exchange of OTASP data. In addition, the SSD update procedure 12
and the Privacy Mode procedure over the traffic channel may also be utilized. Refer to 13
section 3.20.1 for the call flows. 14
3.12.1.3 SSD Update Procedure 15
After the A-key has been derived at the MS as a result of receiving appropriate 16
information via an ADDS Deliver message, an SSD Update procedure over the traffic 17
channel may also be used. 18
3.12.1.4 Privacy Mode Procedure 19
Privacy Mode procedures include pre-loading the BS with parameters for signaling 20
message encryption (SME) or privacy, as well as enabling or disabling SME or privacy. 21
A Privacy Mode procedure may be applied after an SSD Update procedure has been 22
successfully completed. 23
3.12.1.5 Rejection 24
When the BS receives a rejection indication (e.g., a Mobile Station Reject Order), it sends 25
the Rejection message to the MSC. No response is expected from the MSC. Refer to [14] 26
for Rejection message procedures and format. 27
3.12.1.6 OTASP Call Clear 28
Normal call clearing procedures (refer to section 3.2) are utilized to clear OTASP calls. 29
3.12.1.7 OTASP Call Flow 30
This section describes the message transactions between an MSC and BS to support 31
OTASP message transfer for the MS. 32
TIA-2001.3-C

95 Section 3

MS BS MSC
time comment
Origination Message
a
b
c
d
e
f
i
j
k
l
n
o
ADDS Deliver
ADDS Deliver Ack
Data Burst (OTA)
L2 Ack/Reject Order with L2 Ack
Data Burst (OTA)
ADDS Deliver
L2 Ack
p
Reject Order
Rejection
g
h
SSD Update
Privacy Mode Request
Repeat Steps c through k
Normal Call Clearing
m
Terminal Re-Authentication
If a Rejection
message is
received, the
remainder of this
scenario may be
omitted.
Optional
Optional
Optional
Optional
Normal Call Setup
1
Figure 3.12.1.7-1 OTASP Message Flow: CDMA 2
a. The MS transmits an Origination Message over the Access Channel of the air 3
interface to the BS to initiate the OTASP process. 4
b. The MSC and the BS utilize normal call setup procedures (refer to section 3.1.1) to 5
establish the OTASP call. 6
c. Upon request from the Over the Air Function (OTAF), the MSC encapsulates an 7
OTASP data message within an ADDS Deliver message and sends it to the BS. 8
d. The BS extracts the OTASP data message and places it in the CDMA Data Burst 9
Message and transmits it over the traffic channel to the MS. 10
TIA-2001.3-C

Section 3 96

e. The MS may respond with a Layer 2 Ack or a Reject Order containing a Layer 2 1
Ack, acknowledging the Data Burst Message. 2
f. When the BS receives a Layer 2 Ack or a Reject Order containing a Layer 2 Ack 3
acknowledging the Data Burst Message from the MS, in response to an ADDS 4
Deliver message that contained a Tag information element, it sends an ADDS 5
Deliver Ack message to the MSC with the corresponding Tag value. 6
g. The MS may return a Reject Order. 7
h. If the MS sends a Reject Order, the BS sends a Rejection message to the MSC to 8
convey the information contained in the Reject Order. If a Rejection message is 9
received, the remainder of this scenario may be omitted. 10
i. The OTASP application in the MS responds by sending an OTASP data message. 11
The MS places the OTASP data message in the CDMA Data Burst Message and 12
transmits it over the traffic channel to the BS. 13
j. Upon reception of the CDMA Data Burst Message, the BS responds with a Layer 2 14
Ack. 15
k. The BS extracts the OTASP data message and places it in the ADDS Deliver 16
Steps l through o are optional. 18
l. After the A-key has been derived from information transferred via ADDS Deliver 19
messages, an SSD Update procedure over the traffic channel may also be utilized to 20
exchange authentication information (RANDSSD, RANDBS, AUTHBS). 21
m. After an SSD Update procedure, Terminal Re-Authentication (refer to [22]) needs to 22
be performed to generate the cipher key that is used for Privacy. 23
n. After Terminal Re-Authentication, Privacy Mode procedures over the traffic channel 24
may also be applied to specify the use of either Signaling Message Encryption 25
(SME) or Privacy for the call. 26
o. Multiple forward and reverse OTASP messages can be sent between the OTASP 27
endpoint in the network and the MS. The MSC and the BS transfer these messages 28
whenever they are received. 29
p. Once the OTASP service programming has been successful, the call can be cleared 30
using regular call clearing procedures (refer to section 3.2). 31
3.12.2 OTAPA Support 32
The network initiates OTAPA by placing a mobile terminated call to the MS (refer to 33
Figure 3.1.2.1-1) using OTAPA service option 18 or 19. With the exception that during 34
the OTAPA session, access to individual NAM parameters of the active NAM is 35
controlled by the Subscriber Parameter Administration Security Mechanism (which is 36
transparent to the IOS), the remainder of the OTAPA procedure is the same as steps c 37
through p of Figure 3.12.1.7-1.. 38
3.13 Mobile Position Determination 39
This section presents several call flows which provide examples for Mobile Position 40
Determination. The approaches that are supported in this version of the standard are the 41
Position Location Service (MS-PDE) approach and the Software Calculation Position 42
Determination (BS-MSC) approach. Examples of both of these approaches are given in 43
this section. 44
TIA-2001.3-C

97 Section 3

The following messages (defined in [14]) are used to support this feature: 1
Radio Measurements for Position Request 2
Radio Measurements for Position Response 3
ADDS Page 4
ADDS Page Ack 5
ADDS Transfer 6
ADDS Deliver 7
ADDS Deliver Ack 8
For PLD applications that have a BS-based position determination process, the BS may 9
return the Geographic Location IE in the Radio Measurements for Position Response 10
message. 11
3.13.1 Call Flows for Position Location Service (MS-PDE) 12
This section provides call flows for the MS - PDE approach to position location. Position 13
Location Service may be done on either the common channels (Access and Paging) or 14
traffic channel (FCH). Position Location Service over common channels is very similar 15
to SMS delivery on the common channels. Position Location Service on the traffic 16
channel may be accomplished over an existing traffic link by sending Position Location 17
Service data bursts over the existing channel. Alternatively, the MS or the network may 18
initiate a Position Location Services call on a traffic channel if no other services are 19
active. 20
3.13.1.1 Mobile Originated Position Location Service on the Traffic Channel 21
This section describes how an MS may initiate Position Location Service on a traffic 22
channel. 23
TIA-2001.3-C

Section 3 98

MS BS MSC
Mobile Originated Call Setup
Unique Challenge-Response
Data Burst
ADDS Deliver
ADDS Deliver
Data Burst
Layer 2 Ack
ADDS Deliver Ack
Clear Command
Release Order
Release Order
Clear Complete
Time
a
b
c
d
e
f
g
h
i
j
k
l
m
optional
T315
Layer 2 Ack
Clear Request
T300
n
Release Order
o
1
Figure 3.13.1.1-1 Mobile Originated Position Location Service on a Traffic Channel 2
a. The MS originates a position location service call. Refer to steps a through m is 3
section 3.1.1.1. 4
b. Optionally, the MSC may initiate a unique challenge request-response. 5
c. The MS sends position location data to the BS on the traffic channel in a Data Burst 6
Message, and indicates that a Layer 2 Ack is required. 7
d. The BS sends a Layer 2 Ack to the MS. 8
e. The BS encapsulates the Position Location Service data in an ADDS Deliver 9
TIA-2001.3-C

99 Section 3

f. If the PDE has information for the MS, the MSC sends the information in an ADDS 1
Deliver message to the BS. This message includes the Tag information element. 2
g. The BS sends a Data Burst Message to the MS over the traffic channel and indicates 3
that a Layer 2 Ack is required. 4
h. Upon receipt of the Data Burst, the MS sends a Layer 2 Ack to the BS. 5
i. Upon receipt of the Layer 2 Ack, the BS sends an ADDS Deliver Ack to the MSC 6
including the Tag information element it received in the ADDS Deliver message. 7
j. The MS decides to terminate the position location service and sends a Release Order 8
to clear the call. 9
k. The BS sends a Clear Request message to the MSC and starts timer T
300
. 10
l. The MSC sends a Clear Command message to the BS to instruct the BS to release 11
the traffic channel and starts timer T
315
. Upon receipt of this message, the BS stops 12
timer T
300
. 13
m. The BS initiates call clearing over the air interface by transmitting a Release Order 14
over the forward traffic channel. 15
n. The MS responds by sending a Release Order to the BS and releasing the traffic 16
channel. 17
o. The BS sends a Clear Complete message to the MSC. Upon receipt of this message, 18
the MSC stops timer T
315
. 19
3.13.1.2 Mobile Terminated Position Location Service on the Traffic Channel 20
This section describes how the network may initiate Position Location Service on a 21
traffic channel. 22
TIA-2001.3-C

Section 3 100

MS BS MSC
Mobile terminated call setup
Data Burst
ADDS Deliver Ack
ADDS Deliver
Data Burst
Layer 2 Ack
Clear Command
Release Order
Release Order
Clear Complete
Time
a
b
c
d
e
f
g
h
i
j
k
l
m
T315
ADDS Deliver Layer 2 Ack
Clear Request
T300
Release Order
n
1
Figure 3.13.1.2-1 Mobile Terminated Position Location Service on a Traffic Channel 2
a. The MSC determines that a Position Location Service data request needs to be sent 3
to an MS within its serving region and initiates a mobile terminated call. Refer to 4
steps a through r in section 3.1.2.1. 5
b. The MSC sends a Position Location Service data request encapsulated in an ADDS 6
Deliver message to the BS. The MSC includes the Tag information element with this 7
message. 8
c. The BS delivers the Position Location Service request in a Data Burst Message to the 9
MS over the traffic channel, and indicates that a Layer 2 Ack is required. 10
d. Upon receipt of the Data Burst Message, the MS sends a Layer 2 Ack to the BS. 11
TIA-2001.3-C

101 Section 3

e. Upon receipt of the Layer 2 Ack, the BS sends an ADDS Deliver Ack message to the 1
MSC with the same Tag value it received from the MSC in the ADDS Deliver 2
message in step i. 3
f. The MS sends Position Location Service data response to the BS in a Data Burst 4
Message over the traffic channel and indicates that a Layer 2 Ack is required. 5
g. Upon receipt of the Data Burst Message, the BS sends a Layer 2 Ack to the MS. 6
h. The BS encapsulates the Position Location Information in an ADDS Deliver 7
i. The MS decides to terminate the position location service and sends a Release Order 9
to clear the call. 10
j. The BS sends a Clear Request message to the MSC and starts timer T
300
. 11
k. The MSC sends a Clear Command message to the BS to instruct the BS to release 12
the traffic channel and starts timer T
315
. Upon receipt of this message, the BS stops 13
timer T
300
. 14
l. The BS initiates call clearing over the air interface by transmitting a Release Order 15
over the forward traffic channel. 16
m. The MS acknowledges the Release Order by returning a Release Order over the 17
reverse traffic channel. 18
n. The BS sends a Clear Complete message to the MSC. The MSC stops timer T
315
19
upon receipt of the Clear Complete message and releases the underlying transport 20
connection. 21
3.13.1.3 Position Location Service over Common Channels Mobile Terminated 22
This section describes how mobile terminated Position Location Service may be 23
supported using common channels. 24
TIA-2001.3-C

Section 3 102

MS BS MSC
Data Burst
Layer 2 Ack
T3113
ADDS Transfer
Time
a
b
c
d
e
f
ADDS Page
Data Burst
Layer 2 Ack
g
ADDS Page Ack
1
Figure 3.13.1.3-1 Position Location Service over Common Channels Mobile Terminated 2
a. The MSC determines that a Position Location Service data request needs to be sent 3
to an MS within its serving region and sends the ADDS Page message to the BS. The 4
Data Burst Type field in the ADDS User Part is set to 05H (PLD). The MSC 5
includes the Tag information element in this message. The MSC starts timer T
3113
. 6
b. The BS sends the Position Location Information to the MS using a Data Burst 7
Message over the Paging Channel. The BS indicates that a Layer 2 Ack is required. 8
c. Upon receipt of the Data Burst Message, the MS sends a Layer 2 Ack to the BS. 9
d. Upon receipt of the Layer 2 Ack, the BS sends an ADDS Page Ack message to the 10
MSC including the Tag information element with the same value it received in the 11
ADDS Page message. Upon receipt of this message, the MSC stops timer T
3113
. 12
e. The MS sends the Position Location Service data response to the BS in a Data Burst 13
Message on the Access Channel. The MS indicates that a BS Ack is required. 14
f. Upon receipt of the Data Burst Message, the BS sends a Layer 2 Ack to the MS to 15
acknowledge receipt of the Data Burst Message on the Access Channel. 16
g. The BS encapsulates the Position Location Information in an ADDS Transfer 17
3.13.1.4 Position Location Service over Common Channels Mobile Originated 19
This section describes how mobile originated Position Location Service may be 20
supported using common channels. 21
TIA-2001.3-C

103 Section 3

MS BS MSC
Data Burst
Layer 2 Ack
ADDS Transfer
Time
a
b
c
d
e
f
Data Burst
BS Ack
ADDS Page
ADDS Page Ack
g
T3113
1
Figure 3.13.1.4-1 Position Location Service over Common Channels Mobile Originated 2
a. The MS sends the Position Location Service data request to the BS in a Data Burst 3
on the Access Channel. The MS indicates that a BS Ack is required. 4
b. The BS sends a BS Ack Order to the MS to acknowledge receipt of the Data Burst 5
Message on the Access Channel. 6
c. The BS encapsulates the Position Location Information in an ADDS Transfer 7
d. The MSC determines that a Position Location Service data response needs to be sent 9
to the MS and sends the ADDS Page message to the BS. The Data Burst Type field 10
in the ADDS User Part is set to 05H (PLD). The MSC includes the Tag 11
information element in this message. The MSC then starts timer T
3113
. 12
e. The BS sends the Position Location Information to the MS using a Data Burst 13
Message over the Paging Channel. The BS indicates that a Layer 2 Ack is required. 14
f. Upon receipt of the Data Burst Message, the MS sends a Layer 2 Ack to the BS. 15
g. Upon receipt of the Layer 2 Ack, the BS sends an ADDS Page Ack message to the 16
MSC including the Tag information element with the same value it received in the 17
ADDS Page message. Upon receipt of this message, the MSC stops timer T
3113
. 18
3.13.2 Call Flows for Software Calculation Position Determination 19
(BS-MSC) 20
This section describes a call flow for the Software Calculation Position Determination 21
approach. This approach is network initiated. 22
TIA-2001.3-C

Section 3 104

a
b
MS BS MSC
Radio Measurements for
Position Request
Position Response
Comment Time
c
Mobile is on a traffic channel d
Tsoftpos
1
Figure 3.13.2-1 Software Calculation for Position Determination 2
a. The PDE determines that position determination by means of software calculation is 3
to take place for a given MS that is on a traffic channel. 4
b. The MSC sends a Radio Measurements for Position Request message to the BS. The 5
MSC starts timer T
softpos
. 6
c. Upon receipt of the Radio Measurements for Position Request message, the BS 7
gathers the requested measurements and returns them in a Radio Measurements for 8
Position Response message. Upon receipt of the Radio Measurements for Position 9
Response message, the MSC stops timer T
softpos
. Optionally, if the BS is capable of 10
providing the position location, the BS sends the geographic location instead of the 11
requested measurements to the MSC in the Radio Measurements for Position 12
d. The MS remains on the traffic (e.g. if a voice call is in progress in step a). 14
3.14 User Zone 15
This section contains call flows describing the procedures for User Zones. Refer to 16
section 2.14 for more information on this feature. 17
TIA-2001.3-C

105 Section 3

3.14.1 Invoking User Zone at Registration 1
e

User Zone Reject
Location Updating Accept
MS
BS MSC
time comment
a
b
c
d
Conditional
T3210
User Zone Reject
Conditional
2
Figure 3.14.1-1 Location Registration using User Zones 3
a. The MS initiates a registration operation by sending a Registration Message to the 4
BS. 5
b. Upon reception of the Registration Message, the BS constructs the Location 6
Updating Request message, including the MS's User Zone, places it in a Complete 7
Layer 3 Information message, and sends it to the MSC. The BS starts timer T
3210
. 8
c. The MSC sends the Location Updating Accept message to the BS to indicate that the 9
Location Updating Request message has been processed. Upon receiving the 10
Location Updating Accept message the BS stops timer T
3210
. 11
The following two steps are only used when the MSC rejects the User Zone requested by 12
the MS. 13
d. The MSC sends a User Zone Reject message to reject the User Zone. The MSC may 14
include an alternate User Zone for the MS to use. 15
e. The BS sends the User Zone Reject message to the MS with the information it 16
18
TIA-2001.3-C

Section 3 106

3.14.2 Use of User Zones During Call Setup 1
2
MS BS MSC
time comment
a
b
User Zone Reject User Zone Reject
Conditional
c
Mobile Originated/Terminated Call Setup
Conditional
3
Figure 3.14.2-1 Mobile Call Setup Using User Zone 4
a. A mobile terminated call (refer to steps a through m in Figure 3.1.2.1-1) or 5
mobile originated call (refer to steps a through m in Figure 3.1.1.1-1) occurs. The 6
BS includes the User Zone received from the MS in either the CM Service Request 7
message or Paging Response message, depending on the scenario (mobile originated 8
or mobile terminated). 9
The following two steps are only used when the MSC rejects the User Zone requested by 10
the MS. 11
b. The MSC sends a User Zone Reject message to reject the MS's preferred User Zone. 12
The MSC may send an alternate User Zone for the MS to use. This message may be 13
sent any time after the MSC receives either the CM Service Request or Paging 14
Response message, depending on the scenario (mobile originated or mobile 15
terminated). 16
c. The BS sends the User Zone Reject message to the MS with the information it 17
TIA-2001.3-C

107 Section 3

3.14.3 Changing User Zone During a Call (Mobile initiated) 1

User Zone Reject
User Zone Update Request
MS BS MSC
time comment
a
b
c
d
User Zone Reject
Conditional
Conditional
2
Figure 3.14.3-1 Updating the User Zone During a Call (Mobile Initiated) 3
a. The MS transmits a User Zone Update Request over the reverse traffic channel of the 4
air interface to the BS. Included in this message is the User Zone the MS prefers. 5
b. The BS sends a User Zone Update Request message to the MSC. Included is the 6
preferred User Zone the MS transmitted. 7
c. If the MSC rejects the MS preferred User Zone the MSC sends a User Zone Reject 8
message which may contain an alternate User Zone for the MS to use. Note, this 9
message is sent only if the MSC rejects the MS preferred User Zone. 10
d. The BS sends a User Zone Reject message to the MS. Included is the User Zone 11
information the MSC transmitted. 12
3.14.4 Changing User Zone During a Call (Network initiated) 13
User Zone Update
MS BS MSC
time comment
a
b
User Zone Update
14
Figure 3.14.4-1 Updating the User Zone During a Call (Network initiated) 15
a. If the MSC wants to change the User Zone being used by the MS, it sends the User 16
Zone Update message to the BS, including the new User Zone to be used by the MS. 17
b. The BS sends a User Zone Update message to the MS. Included is the User Zone 18
information the MSC transmitted. 19
TIA-2001.3-C

Section 3 108

3.15 ISDN Interworking Service 1
For ISDN interworking calls, normal call origination, call termination, handoff and call 2
clearing call flows apply. These call flows are described in section 3.1.1, 3.1.2, 3.19.3, 3
and 3.2. Refer to [14] for information on valid service options. 4
For ISDN interworking calls, the A2 interface carries unrestricted digital information of 5
user traffic between the MSC and the SDU. The SDU shall construct 64 kbps 6
Unrestricted Digital Information (UDI) data from RLP frames transmitted over the air- 7
interface and shall construct RLP frames from 64 kbps unrestricted digital data received 8
from the MSC. 9
3.16 Circuit Data Calls 10
Normal call origination, call termination, and call clearing procedures apply. 11
Call flows associated with this feature are described in sections 3.1.1, 3.1.2, and 3.2. 12
13
14
15
16
17
TIA-2001.3-C
109 Section 3
3.17 3G Packet Data Calls 1
This section describes the procedures and call flows for packet data support in the IOS. 2
Refer to [32] for further explanation of MSC operations and [8] for further explanation of 3
PDSN operations. The call flows in this section assume that the MS does not have an 4
active call in progress. Refer to section 3.18 for call flows associated with concurrent 5
services. 6
3.17.1 Data Ready to Send (DRS) Indicator 7
As part of the support for the Dormant State of a service instance, the cdma2000
air 8
interface [23] supports a Data Ready to Send indicator that is used on origination. When 9
an MS sends an origination message
1
with a packet data service option specified, it 10
includes the Data Ready to Send (DRS) bit. This indicator is set to 1 on setup of a new 11
service instance and when a service instance transitions from Dormant to Active State 12
because the MS has data to send on that service instance and is requesting the 13
establishment of a traffic channel or service negotiation of an existing traffic channel. 14
The DRS bit is set to 0 to indicate that the terminal has detected that it has crossed a 15
Packet Zone boundary while the service instance was dormant, and is sending the 16
origination message for each service instance to update the network as to its current 17
location. On receipt of an origination with the DRS bit set to 1, the BS initiates the 18
service instance setup procedure as described in section 3.17.4.1, which normally results 19
in the establishment or service negotiation of a traffic channel and in the A8 and A10 20
bearer connections being established. 21
When the BS receives an origination message with the DRS bit set to 0, the BS delays 22
the establishment or service negotiation of a traffic channel until after the A8 and A10 23
bearer connection establishment procedures are complete. During the A8 bearer 24
connection establishment procedure, the BS indicates to the PCF that a DRS=0 has been 25
received through the use of the Data Ready Indicator element in the A9-Setup-A8 26
message. If the PDSN has data to send (e.g. PPP connection setup) on the service 27
instance, the PDSN indicates this to the PCF by including a Data Available Indicator 28
(DAI) field in the A11-Registration Reply message, and the PCF indicates this to the BS 29
by setting the cause element in the A9-Connect-A8 message to the Data ready to send 30
value. The BS requests establishment or service negotiation of a traffic channel using the 31
normal service instance setup procedure as in section 3.17.4.1. 32
If the PDSN does not have data to deliver to the MS on the service instance, the PCF 33
indicates to the BS that an A8 connection is not to be established by sending the A9- 34
Release-A8 Complete message to the BS, and the dormant mode handoff is completed. 35
3.17.2 Previous and Current Access Network Identifiers 36
(PANID/CANID) 37
Each PCF shall be uniquely identified by an ANID and shall know its ANID value. 38
For an MS originated packet data session, the MS does not send any ANID information 39
to the BS. The BS shall not send any ANID information to the PCF. The PCF shall send 40
an ANID NVSE in the A11-Registration Request message to the PDSN with the PANID 41

1
This may be an Origination Message or an Enhanced Origination Message.
TIA-2001.3-C
Section 3 110
field set to 0 and the CANID field set to its own ANID. The PDSN shall store the 1
received CANID and associate it with the A10 connections for the MS. 2
The MS initiates a dormant handoff when it moves into a new packet zone and 3
determines that it needs to notify the packet data network. The MS sends an Origination 4
Message or Enhanced Origination Message to the target BS for each of its dormant 5
service instances in which it may include the PREV_SID, PREV_NID, or PREV_PZID, 6
whichever is different from the current SID, NID and PZID.. The BS shall use these 7
fields to determine the ANID of the PCF the MS was previously connected to (i.e., the 8
PANID). The target BS shall send the PANID information to the target PCF in the 9
Access Network Identifiers information element of the A9-Setup-A8 message. The target 10
PCF shall set the PANID field to the received ANID and the CANID field to its own 11
ANID, and shall send this information in an ANID NVSE in each A11-Registration 12
Request message to the PDSN. If the target PCF did not receive the ANID information 13
element from the BS, it sets the PANID field to zero. 14
In the case of hard or fast handoff, the source BS shall include the ANID of the Source 15
PCF in the ANID field of the Handoff Required message sent to the MSC. The MSC 16
shall forward this information to the target BS in the Handoff Request message, which in 17
turn, shall send the received ANID to the target PCF. The target PCF shall include the 18
ANID received from the target BS in the PANID field, along with its own ANID in the 19
CANID field to the PDSN in an ANID NVSE in each A11-Registration Request 20
message. 21
When the PDSN receives an A11-Registration Request message, it first examines the 22
received mobile identity information to determine if it owns the call. If the PDSN does 23
not recognize the identity of the MS, PPP negotiation and MIP registration (if required) 24
are performed. If the PDSN recognizes the MSID, the PDSN compares the PANID (if 25
not set to zero) to the stored CANID to determine if PPP re-negotiation is required. If the 26
received PANID does not match the stored CANID at the PDSN for the A10 connection, 27
PPP re-negotiation and MIP re-registration (if required) are performed for the packet data 28
session. If multiple service instances are present, PPP re-negotiation and MIP registration 29
(if required) are performed once for the packet data session. Upon a successful A11 30
registration, the PDSN shall update its stored CANID for the MS with the CANID 31
received in the A11-Registration Request message (so that it is up-to-date with the 32
currently active PCF). 33
For a mobile initiated dormant re-activation: 34
When a packet zone change did not occur, or 35
When a packet zone change did occur, but the MOB_P_REV of the MS is 6, 36
the MS does not send any ANID information to the BS. The BS shall not send any ANID 37
information to the PCF. The PCF shall not send an ANID NVSE to the PDSN if an A10 38
connection exists with the PDSN for this service instance for this MS. 39
If the MS determines that it has moved into a new packet zone at the time of a mobile 40
initiated reactivation, and the MS sends ANID information to the BS, then the BS shall 41
determine the ANID of the source PCF from the ANID information received from the 42
MS and shall send it to the target PCF. The target PCF shall then send an ANID NVSE to 43
the PDSN with the PANID field set to the ANID received from the BS and the CANID 44
field set to the ANID of the target PCF. 45
For a network initiated dormant reactivation, the MS does not send any ANID 46
information to the BS. The BS shall not send any ANID information to the PCF. If the 47
A10 connections for the MS's service instances have already been established at the PCF, 48
TIA-2001.3-C
111 Section 3
the PCF shall not send an ANID NVSE to the PDSN. Otherwise, the PCF shall include an 1
ANID NVSE in the A11-Registration Request with the PANID field set to 0 and the 2
CANID field set to its own ANID. 3
3.17.3 PDSN Selection Algorithm 4
This section only applies to establishment of the first A10 bearer connection for a given 5
MS. Requests for additional A10 bearer connections (for additional packet data service 6
instances) shall be sent to the PDSN currently supporting the existing A10 bearer 7
connection(s). 8
Each PCF shall maintain a configuration table with IP addresses as follows: 9
PDSN Number PDSN IP Address 10
0 a b c d 11
1 k l m n 12
13
N-1 w x y z 14
The PDSNs accessible from the PCF shall be listed in ascending order of PDSN IP 15
addresses. In order for two PCFs to resolve the same IMSI to the same PDSN, the PCFs 16
need to have tables of equal lengths. In network configurations with full connectivity, the 17
PDSN selection algorithm allows two PCFs to resolve the same IMSI to the same PDSN. 18
In network configurations with partial connectivity, tables of equal lengths can be 19
achieved by adding dummy entries in the tables for PDSNs that exist in the network but 20
are not accessible from the PCF. The PCF shall be capable of including dummy entries in 21
the configuration table. Each dummy entry shall be placed in the position in the table that 22
the PDSN entry would have had if the PCF had had connectivity to that PDSN. The 23
PDSN IP address for such dummy PDSN entries shall be set to 0.0.0.0. Finally, the 24
entries shall be numbered from 0 to N-1 in ascending order, N being the total number of 25
entries in the table. 26
For initial PDSN assignment and for PDSN reselection, the PCF shall determine which 27
PDSN to use for a particular MS by the following PDSN Selection algorithm: 28
PDSN No. = (truncated Mobile IMSI) modulo N, 29
where (truncated Mobile IMSI) is defined to be the least significant 4 digits of the IMSI 30
(or MSIN) taken as a decimal value. 31
The IP address of the selected PDSN shall be obtained by indexing at the PDSN Number 32
entry in the configuration table. If the selected PDSN is not accessible by the PCF (PDSN 33
IP Address is all zeros, for example), the PCF shall select another PDSN by performing 34
the following algorithm, up to N-1 times, till a valid PDSN IP Address entry is found in 35
the configuration table. 36
PDSN No. = (PDSN No. +1 ) modulo N. 37
After the PCF has successfully selected a PDSN using the selection algorithm, the PCF 38
shall initiate establishment of the A10 connection with the selected PDSN. If the selected 39
TIA-2001.3-C
Section 3 112
PDSN responds with code 88H in the A11-Registration Reply, thereby proposing 1
another PDSN, the PCF may initiate establishment of the A10 connection with the 2
proposed PDSN. 3
3.17.4 A8/A9 Interface Call Flows 4
This section describes call flows for the A8/A9 interface. The following messages are 5
required to support the 3G packet data feature on the A8/A9 interface: 6
A9-Setup-A8 7
A9-Connect-A8 8
A9-AL Connected 9
A9-AL Connected Ack 10
A9-Release-A8 11
A9-Release-A8 Complete 12
A9-Update-A8 13
A9-Update-A8 Ack 14
A9-Disconnect-A8 15
A9-BS Service Request 16
A9-BS Service Response 17
For A8 interface Setup, Release, Handoff, and Accounting procedures, refer to [16]. 18
3.17.4.1 MS Initiated Packet Data Service Instance Setup 19
The MS initiates the setup of all packet data service instances. There are two cases of a 20
packet data service instance setup: 21
1. Setup of a packet data service instance when the packet data session is dormant (i.e., 22
all existing packet service instances are dormant) or the packet data session is in 23
Null/Inactive State (i.e., no existing packet data service instances exist for the MS). 24
2. Setup of a packet data service instance while the packet data session is active (i.e., at 25
least one other packet data service instance is active). 26
3.17.4.1.1 MS Initiated PDSI Setup - Packet Data Session is Dormant or Inactive 27
When an MS initiates a packet data service instance (PDSI) and PPP negotiation has not 28
been initiated yet, PPP negotiation is performed over that packet data service instance 29
before transmitting packet data. 30
TIA-2001.3-C
113 Section 3
A9-Connect-A8
T10
BS
MS
Origination
BS ACK Order
MSC
CM Service Request
A9-Setup-A8
Assignment Request
PCF PDSN
Assignment Complete
a
b
c
d
e
f
g
h
i
j
A10 Connection
Establishment
T303
TA8-Setup
Active Packet Data Session
Establishing PPP connection
IS-2000
TCH
Time Comment
k
1
Figure 3.17.4.1.1-1 MS Initiated PDSI Setup - Packet Data Session is Dormant or Inactive 2
a. The MS transmits an Origination Message (DRS=1), with layer 2 acknowledgment 3
required, over the access channel of the air interface to the BS to request packet data 4
service. 5
303
. 9
radio resources and starts timer T
10
. For packet data services a terrestrial circuit 11
between the MSC and the BS is not required. The BS stops timer T
303
. 12
e. The BS and the MS initiate the establishment of a radio traffic channel. 13
f. The BS transmits an A9-Setup-A8 message to PCF with Data Ready Indicator set to 14
1 to establish an A8 connection and starts timer T
A8-setup
. This step may occur 15
anytime after step d. 16
g. The procedure for establishing an A10 connection is performed; refer to section 17
3.17.5.1.1. 18
TIA-2001.3-C
Section 3 114
h. Upon establishment of the A10 connection, the PCF establishes an A8 connection 1
and transmits an A9-Connect-A8 message with cause value set to Successful 2
operation. If the PCF supports fast handoff, it provides the Anchor PDSN Address 3
and Source PDSN Address and the PDSN provides the Anchor P-P Address. The 4
PCF supporting fast handoff passes this information to the BS as part of this 5
message. In the message, the PCF includes a Service Instance Info information 6
element identifying all dormant packet data service instances. 7
i. Upon receiving an A9-Connect-A8 message, the BS stops timer T
A8-setup
and 8
transmits an Assignment Complete message. The MSC stops timer T
10
. 9
j. If the packet data service instance is the first to be set up (i.e. main packet data 10
service instance), the PPP connection establishment procedure and Mobile IP 11
Registration (if required) on the PPP connection are performed between the MS and 12
PDSN. 13
k. The packet data service instance is ready for data transmission. 14
3.17.4.1.2 Mobile Initiated Setup of a Packet Data Service Instance when the Packet Data 15
Session Already Is Active Successful Operation 16
In this scenario, another PDSI has already been established and is active. 17
A9-Connect-A8
BS
MS
Enhanced Origination
BS ACK Order
MSC
A9-Setup-A8
PCF PDSN
a
b
d
e
f
g
A10 Connection
Establishment
TA8-setup
Time Comment
c
Service negotiation
procedure
conditional
Active Packet Data Service Instance
18
Figure 3.17.4.1.2-1 Mobile Initiated Setup of a Packet Data Service Instance When the Packet 19
Data Session is Already Active Successful Operation 20
a. The MS has an active packet session, and decides to initiate another PDSI. The MS 21
transmits an Enhanced Origination Message (DRS=1) to the BS to initiate a packet 22
TIA-2001.3-C
115 Section 3
b. If a layer 2 acknowledgement was requested in step a, the BS acknowledges the 1
receipt of the Enhanced Origination Message with a Base Station Acknowledgment 2
Order to the MS. 3
c. Service negotiation procedures take place to associate the new service instance with 4
d. The BS transmits an A9-Setup-A8 message to PCF with Data Ready Indicator set to 6
A8-setup
. 7
e. The procedure for establishing A10 connection is performed; refer to section 8
3.17.5.1.2. 9
f. Upon establishment of the A10 connection, the PCF establishes an A8 connection 10
and transmits an A9-Connect-A8 message with cause value set to Successful 11
Operation. The BS stops timer T
A8-setup
upon receipt of this message. 12
g. The packet data service instance is ready for data transmission. 13
3.17.4.2 BS Initiated Packet Data Service Instance Release to Dormant State 14
This section presents example call flows associated with a BS initiated packet data 15
service instance release to Dormant. To simplify the diagrams, it is assumed that for 16
purposes of these examples, the packet call is not in inter-BS soft/softer handoff prior to 17
the release and that the MS does not have an active voice call in progress. 18
There are two cases of a packet data service instance release to Dormant State: 19
1. Release of a packet data service instance when no other packet data service instance 20
is active. 21
2. Release of a packet data service instance when other packet data service instances 22
are active. 23
TIA-2001.3-C
Section 3 116
3.17.4.2.1 BS Initiated Packet Data Service Instance Release to Dormant State when no 1
other packet data service instance is active 2

A11
Accounting
Procedures
Clear Request
Clear Complete
A9-Release-A8
Clear Command
A9-Release-A8 Complete
MS BS MSC/VLR PCF PDSN
Time Comment
Active packet data service instance / packet data session
a
b
c
d
e
g
h
T
300

T
315

T
rel9

TCH
Release
f
Dormant packet data service instance / Dormant packet data session
3
No Other Packet Data Service Instance is Active 5
a. The BS determines the service needs to be moved to the Dormant State. The BS 6
sends a Clear Request message with cause set to Packet call going dormant to the 7
MSC to initiate the call clear transaction, and starts timer T
300
. 8
b. The MSC starts timer T
315
and sends a Clear Command message to the BS to 9
instruct the BS to release the associated dedicated resources. The BS stops timer 10
T
300
. 11
c. BS initiates traffic channel release using existing procedures. 12
d. The BS sends an A9-Release-A8 message, with a cause value set to Packet call 13
going dormant, to the PCF to instruct the PCF to release the associated dedicated 14
resources, and starts timer T
rel9
. This step may occur anytime after step c. Note that 15
in this scenario the A10 connection is not released. 16
e. The A11 accounting update procedure takes place. The PCF sends the All-Dormant 17
Indicator to the PDSN. 18
f. The PCF acknowledges the A9-Release-A8 message by returning an A9-Release-A8 19
Complete message. The BS stops timer T
rel9
. 20
TIA-2001.3-C
117 Section 3
g. The BS returns a Clear Complete message to the MSC. The MSC stops timer T
315
1
and releases the underlying transport connection. This step may occur any time after 2
the traffic channel is released. 3
h. At this point, the packet data session is considered to be in the Dormant State. 4
3.17.4.2.2 BS Initiated Packet Data Service Instance Release to Dormant State When Other 5
Packet Data Service Instances Are Active 6
7

A11 Accounting
Procedures
A9-Release-A8
MS
BS MSC/VLR PCF PDSN
Time Comment
Active packet data service instance/ active packet data session
a
b
c
T
rel9

d
e
Service
Negotiation
Dormant packet data service instance/ active packet data session
8
Other Packet Data Service Instances are Active 10
a. The BS determines the service needs to be moved to the Dormant State. Service 11
negotiation procedures take place to dissociate the service instance from the traffic 12
channel. 13
b. The BS sends an A9-Release-A8 message, with a cause value set to Packet call 14
rel9
. Note that in this scenario the A10 connection is not 16
released. 17
c. The A11 accounting update procedure takes place. 18
d. The PCF acknowledges the A9-Release-A8 message by returning an A9-Release-A8 19
rel9
. 20
e. At this point, the packet data service instance is considered to be in the Dormant 21
State but the packet data session remains in Active State. 22
TIA-2001.3-C
Section 3 118
3.17.4.3 MS Initiated Packet Data Service Instance Release to Dormant State 1
This section presents example call flows associated with packet data service instance 2
release to Dormant initiated by the MS. To simplify the call flows, it is assumed that for 3
purposes of these examples, the packet data call is not in inter-BS soft/softer handoff 4
prior to the release and the MS does not have an active voice call in progress. 5
Refer to section 3.17.4.17 for MS initiated release of the packet data service instance to 6
the Inactive/Null State. 7
There are two cases of a packet data service instance release to the Dormant State: 8
1. Release of a packet data service instance to Dormant State when no other packet data 9
service instance is active. 10
2. Release of a packet data service instance to Dormant State when other packet data 11
service instances are active. 12
3.17.4.3.1 MS Initiated Packet Data Service Instance Release to Dormant State when no 13
other Packet Data Service Instance is Active 14
Active packet data service instance / Active packet data session
A11
Accounting
Procedures
Release Order
Time Comment
Clear Request
Clear Command
Clear Complete
a
b
c
d
e
f
h
i
A9-Release-A8
T300
T315
Trel9
TCH
Release
g
Dormant packet data service instance / Dormant packet data session
15
No Other Packet Data Service Instance is Active 17
TIA-2001.3-C
119 Section 3
a. The MS determines that the service needs to be released to Dormant State. The MS 1
sends a Release Order with ORDQ = 00000000 to the BS to request a transition of 2
the active packet data service instance to the Dormant State. 3
b. The BS then sends a Clear Request message with cause set to Packet call going 4
dormant to the MSC to initiate the call clear transaction, and starts timer T
300
. 5
the associated dedicated resources and starts timer T
315
300
. 7
d. The traffic channel is released. Upon reading the overhead messages on the common 8
channels the MS may discover that it has moved to another packet zone while active 9
and initiate a dormant handoff. Refer to section 3.17.4.9. 10
e. The BS sends an A9-Release-A8 message, with a cause value set to Packet call 11
rel9
. Note that in this scenario the A10 connection is not 13
released. 14
f. The A11 accounting update procedures take place. The PCF sends the All Dormant 15
Indicator to the PDSN. Any P-P connections that may exist to an anchor PDSN (see 16
section 3.19.4.2) are released according to procedures specified in [8]. 17
g. The PCF acknowledges the A9-Release-A8 message by returning an A9-Release-A8 18
rel9
. 19
h. The BS returns a Clear Complete message to the MSC. The MSC releases the 20
underlying transport connection and stops timer T
315
. This step may occur any time 21
after the traffic channel is released. 22
i. At this point the packet data session is considered to be in the Dormant State. 23
TIA-2001.3-C
Section 3 120
3.17.4.3.2 MS Initiated Packet Data Service Instance Release to Dormant State when other 1
Packet Data Service Instances are Active 2
RRRM / RRRMM
Time Comment
Active Packet Data Service Instance / Active Packet Data Session
a
d
e
f
A9-Release-A8
T
rel9
A11
Accounting
Procedures
b
c
Service
negotiation
procedures
Dormant Packet Data Service Instance / Active Packet Data Session
3
Other Packet Data Service Instances are Active 5
a. To transition an active packet data service instance to Dormant State, the MS sends 6
either a Resource Release Request Message (RRRM) or a Resource Release Request 7
Mini Message (RRRMM) with the Purge Indicator set to 0. The CON_REF 8
parameter in the message allows the BS to determine the corresponding SR_ID for 9
the affected packet data service instance. 10
b. Service negotiation procedures take place to dissociate the service instance from the 11
traffic channel. 12
c. The BS sends an A9-Release-A8 message with the cause value set to Packet call 13
going dormant to the PCF to instruct the PCF to release the associated dedicated 14
rel9
. 15
d. The A11 accounting update procedures take place. 16
e. The PCF acknowledges the A9-Release-A8 message by returning an A9-Release-A8 17
rel9
. 18
f. At this point, the packet data service instance is considered to be in the Dormant 19
State; however, the packet data session is still in Active State. 20
TIA-2001.3-C
121 Section 3
3.17.4.4 Active MS Power Down 1
This section describes the call flow associated with a packet data session release initiated 2
by an MS power down when the packet data session is active. Refer to section 3.17.4.18 3
for MS power down when the packet data session is in the Dormant State. 4

Time Comment
Clear Request
Clear Command
Release Order
Release Order
Clear Complete
a
b
c
d
e
f
g
h
A9-Release-A8
A10 Connection
Release Procedure
T300
T315
Trel9
5
Figure 3.17.4.4-1 Active MS Power Down 6
a. The MS powers down causing the packet data session to terminate. It sends a 7
Release Order to the BS with a power down indication. 8
b. The BS sends a Clear Request message with cause set to Normal clearing to the 9
300
. 10
315
300
. 12
d. In response to the Clear Command message, the BS acknowledges the MS by 13
sending it a Release Order and releases the radio resource. 14
e. The BS sends an A9-Release-A8 message with a cause value set to Packet data 15
session release to the PCF to instruct the PCF to release the dedicated resource 16
associated with all packet data service instances (both active and dormant) of the 17
MS, and to release the associated A10 connection(s). The BS uses the SR_ID of any 18
one of the active packet data service instances in the A9-Release-A8 message. The 19
BS starts timer T
rel9
. 20
f. The PCF initiates the procedure for releasing all A10 connections. Refer to section 21
3.17.5.6 for details. 22
g. The PCF sends an A9-Release-A8 Complete message to the BS. The BS stops timer 23
T
rel9
. The BS and PCF release all A8 connections for the MS. 24
h. The BS returns a Clear Complete message to the MSC and includes the Power Down 25
Indicator information element. The MSC releases the underlying transport 26
TIA-2001.3-C
Section 3 122
connection and stops timer T
315
. This step may occur any time after the traffic 1
channel is released. 2
3.17.4.5 PDSN Initiated Packet Data Service Instance Release to Inactive/Null State 3
This section presents example call flows associated with a packet data service instance 4
release initiated by the PDSN. It is assumed that the MS does not have an active voice 5
call in progress. 6
There are three cases of PDSN initiated inactivation of a packet data service instance: 7
1. inactivation of a dormant packet data service instance 8
2. inactivation of an active packet data service instance when other packet data service 9
instances are active. In this case the packet data session remains active 10
3. inactivation of an active packet data service instance when no other packet data 11
service instances are active. In this case, the packet data session becomes dormant or 12
inactive. 13
3.17.4.5.1 PDSN Initiated Release of a Dormant Packet Data Service Instance 14
In this scenario the PDSN releases the A10 connection associated with a dormant packet 15
data service instance. However, the packet data service instance may continue to exist in 16
the MS. 17
=
Time Comment
a
b
c
A10
Connection
Release
Procedure
Active or Dormant Packet Data Session
Active, Dormant or Inactive/Null Packet Data Session
A9-Update-A8
A9-Update-A8 Ack
d
e
T
upd9
conditional
conditional
18
Figure 3.17.4.5.1-1 PDSN Initiated Service Release of a Dormant Packet Data Service Instance 19
a. The packet service instance is dormant. Other packet data service instances may exist 20
and be active (active packet data session) or dormant (if all dormant packet data 21
session is dormant). 22
b. When the dormant packet data service instance is released by the PDSN the A10 23
connection is released. Refer to section 3.17.5.4 for A10 release procedures. 24
TIA-2001.3-C
123 Section 3
c. If the packet data session is active, the PCF sends an A9-Update-A8 message to the 1
BS to update the number of stored dormant packet data service instances in the BS. 2
The PCF starts timer T
upd9
. 3
d. The BS responds with an A9-Update-A8 Ack message to the PCF. The PCF stops 4
timer T
upd9
. 5
e. After the packet data service instance has been released, the packet data session is 6
active, dormant or inactive/null. If the released service instance was the main service 7
instance, then all other service instances are also released. 8
Session Remains Active 10
=
Time Comment
A9-Disconnect-A8
a
b
c
d
A9-Release-A8
A10 Connection
Release Procedure
Tdiscon9
Trel9
e
Service
negotiation
procedure
11
Figure 3.17.4.5.2-1 PDSN Initiated Service Release of an Active Packet Service Instance 12
Packet Data Session Remains Active 13
a. When the packet data service instance is released by the PDSN, the A10 connection 14
associated with the service instance is released. 15
b. When the PCF recognizes that the A10 connection is released, the PCF sends an A9- 16
Disconnect-A8 message to the BS and starts timer T
discon9
. 17
c. The BS initiates release of the A8 connection by transmitting an A9-Release-A8 18
rel9
. The PCF stops timer T
discon9
. 19
rel9
. 21
e. Service negotiation procedures take place to dissociate the service instance from the 22
traffic channel. Service negotiation may occur anytime after receipt of the A9- 23
Disconnect-A8 message. 24
TIA-2001.3-C
Section 3 124
Session Becomes Dormant or Inactive 2
=
Time Comment
Clear Request
Clear Command
Clear Complete
A9-Disconnect-A8
a
b
c
d
e
f
g
A9-Release-A8
A10 Connection
Release Procedure
h
Tdiscon9
Trel9
T300
T315
TCH
Release
3
Figure 3.17.4.5.3-1 PDSN Initiated Release of an Active Packet Data Service Instance Packet 4
Data Session Becomes Dormant or Inactive 5
a. When the packet data service instance is released by the PDSN (e.g., because of PPP 6
termination), the A10 connection is released. If the Packet Data Session transitions to 7
the Dormant State, then the PCF sends the All Dormant Indicator that is part of 8
this release procedure. 9
b. When the PCF recognizes that the A10 connection is released, the PCF sends an A9- 10
Disconnect-A8 message to the BS and starts timer T
discon9
. 11
rel9
discon9
. 13
rel9
. 15
e. The BS sends a Clear Request message to the MSC and starts timer T
300
. The cause 16
value in this message is set to packet call going dormant if the packet data session 17
is transitioning to the Dormant State. The cause value is set to normal clearing if 18
the packet data session is transitioning to the Null/Inactive State.. 19
f. The MSC sends a Clear Command message to the BS to instruct the BS to release 20
315
300
. 21
g. In response to the Clear Command message, the BS releases the traffic channel. 22
h. The BS returns a Clear Complete message to the MSC. The MSC stops timer T
315
23
and releases the underlying transport connection. This step may occur any time after 24
TIA-2001.3-C
125 Section 3
3.17.4.6 MS Initiated Packet Data Service Instance Re-Activation from Dormant State 1
(intra-PCF) 2
Once in the Dormant State, a packet data service instance is reconnected by the MS by 3
including a packet data specific service option in an Origination Message or an Enhanced 4
Origination Message with DRS bit set to 1. The PPP and MIP sessions need not be re- 5
established. That is, the A10 connection need not be reestablished, and the PCF does not 6
indicate its ANID to the PDSN.. In all other respects, this call is no different than a 7
normal A8 connection setup procedure. Refer to section 3.17.4.1 for details. 8
3.17.4.7 Network Initiated PDSI Re-Activation from Dormant State 9
Once in the Dormant State, a packet data service instance is reconnected when the PCF 10
sends an A9-BS Service Request message containing a packet data service specific 11
service option to the BS and an SR_ID value identifying the packet data service instance. 12
The BS acknowledges the request by sending the A9-BS Service Response message to 13
the PCF and initiates a normal BS initiated call setup. 14
This section describes the call flow examples associated with the establishment of an A8 15
connection upon Dormant State to Active State transition. In this scenario: 16
1. The MS has already performed MIP registration (if required) and established a PPP 17
connection with the PDSN. 18
2. The A8 (User Traffic) connection between the PCF and the BS does not exist. 19
3. The MS does not have an active voice call in progress. 20
Note, if the MS performed an intra-PCF dormant mode handoff, the target BS that 21
initiates the A8 connection setup may be different than the source BS that was initially 22
contacted by the PCF. 23
The PDSN sends data packets to the PCF on an existing A10 connection. 24
There are two cases of network initiated packet data service instance reactivation from 25
Dormant State: 26
1. Reactivation of a packet data service instance when the packet data session is 27
dormant. 28
2. Reactivation of a packet data service instance when the packet data session is active. 29
TIA-2001.3-C
Section 3 126
3.17.4.7.1 Network Initiated Packet Data Service Instance Reactivation when the Packet 1
Data Session is Dormant 2

Assignment Complete
Comment
MS
Time
a
b
c
d
e
f
g
h
i
Complete L3 info:
Paging Response
Assignment Request
A9-Setup-A8
A9-Connect-A8
BS Ack Order

IS-2000 Tch
Setup
ActivePacket Data Session
j
TA8-setup
T303
T10
Packet Data
A9-BS Service Request
BS Service Request
BS Service Response
A9-BS Service Response
Paging Request
Page Message
BS MSC/ VLR PDSN PCF
Tbsreq9 T311
T3113
K
l
m
o
p
Dormant Packet Data Session, PPP connection is maintained
n
A11 Accounting
Procedures
3
Figure 3.17.4.7.1-1 Network Initiated Packet Data Service Instance Re-Activation from 4
Dormant State Packet Data Session is Dormant 5
a. The PDSN sends data packets to the PCF on an existing PPP connection and A10 6
connection associated with a specific MS and dormant packet data service instance. 7
b. The PCF sends an A9-BS Service Request message containing the SR_ID 8
identifying the packet data service instance to the BS to request reactivation of 9
packet data service instance, and starts timer T
bsreq9
. 10
c. The BS sends a BS Service Request message containing the SR_ID identifying the 11
packet data service instance to the MSC and starts timer T
311
. 12
TIA-2001.3-C
127 Section 3
d. The MSC stores the SR_ID and acknowledges the call setup request by sending a BS 1
Service Response message to the BS. Upon receipt of the BS Service Response 2
message from the MSC the BS stops timer T
311
. 3
e. The BS sends an A9-BS Service Response message to the PCF. The PCF stops timer 4
T
bsreq9
upon receipt of the A9-BS Service Response message. 5
f. The MSC sends a Paging Request message to initiate packet data service instance re- 6
activation from dormant and starts timer T
3113
. 7
g. The BS issues a Page message containing the MS address over the Paging Channel. 8
h. The MS acknowledges the page by transmitting a Page Response message over the 9
access channel. 10
i. The BS constructs the Paging Response message, places it in Complete Layer 3 11
303
. The 12
MSC stops timer T
3113
upon receipt of the Paging Response message from the BS. 13
j. The BS acknowledges the receipt of the Page Response message with a BS Ack 14
order to the MS. 15
k. The MSC sends an Assignment Request message containing the stored SR_ID to the 16
BS to request assignment of radio resources and the A8 (User Traffic) connection 17
between the BS and the PCF. The MSC then starts timer T
10
. For packet data 18
services a terrestrial circuit between the MSC and the BS is not required. 19
Upon receipt of the Assignment Request message from the MSC the BS stops timer 20
T
303
. 21
l. The BS and the MS perform radio resources setup procedure. The BS uses the 22
SR_ID to identify the packet data service instance to be re-activated. 23
m. The BS sends an A9-Setup-A8 message to the PCF to establish an A8 (User Traffic) 24
connection between the BS and the PCF. The BS starts timer T
A8-setup
. Note: if the 25
MS performed an intra-PCF dormant mode handoff, the BS sending this message 26
may not be the same BS that was initially contacted by the PCF. 27
n. A11 accounting procedures take place on the A11 interface. 28
o. The PCF responds with an A9-Connect-A8 message to complete the setup of an A8 29
(User Traffic) connection for this packet service request. If fast handoff is supported, 30
the PCF passes the Anchor P-P Address to the BS as part of this message. In the 31
message, the PCF includes a Service Instance Info information element identifying 32
all dormant packet data service instances if any exist. Upon receipt of the A9- 33
Connect-A8 message from the PCF, the BS stops timer T
A8-setup
. 34
p. After the radio link and the A8 connection have been established, the BS sends an 35
Assignment Complete message to the MSC. The MSC stops timer T
10
. 36
37
TIA-2001.3-C
Section 3 128
3.17.4.7.2 Network Initiated Packet Data Service Instance Reactivation when the Packet 1
Data Session is Active 2
Comment
MS
Time
a
b
c
d
e
g
h
A9-Setup-A8
A9-Connect-A8
TA8-setup
Active Packet Data Session, Dormant Packet Data Service Instance
Packet Data
Tbsreq9
Service Instance Active
A11 Accounting
Procedures
f
Service negotiation
procedures
3
Figure 3.17.4.7.2-1 Network Initiated Packet Data Service Instance Re-Activation from 4
Dormant State Packet Data Session is Active 5
a. The PDSN sends data packets to the PCF on an existing A10 connection associated 6
with a specific MS and dormant packet data service instance. 7
b. The PCF sends an A9-BS Service Request message containing the SR_ID 8
identifying the packet data service instance to the BS to request reactivation of 9
bsreq9
. 10
c. The BS responds with an A9-BS Service Response message. The PCF stops timer 11
T
bsreq9
d. Service negotiation procedures take place to associate the new service instance with 13
e. The BS sends an A9-Setup-A8 message to the PCF to establish an A8 (User Traffic) 15
connection between the BS and the PCF. The BS starts timer T
A8-setup
. 16
f. A11 accounting procedures take place over the A11 interface. 17
g. The PCF responds with an A9-Connect-A8 message to complete the setup of an A8 18
(User Traffic) connection for this packet data service instance request. Upon receipt 19
of the A9-Connect-A8 message from the PCF, the BS stops timer T
A8-setup
. 20
TIA-2001.3-C
129 Section 3
h. Packet data flows on the packet data service instance. 1
3.17.4.8 Mobile Terminated Packet Data Rejection During a Voice Call 2
This procedure is only applicable to the cases that the MS is operating with protocol 3
revision less than 7 or the BS and/or the MSC does not support concurrent voice and 4
packet data services. The following call flow provides an illustration for rejection of 5
packet data termination during a voice call. 6

A9-BS Service Response(Cause: MS Busy)
Time Comment
a
b
c
d
e
Dormant packet data session, PPP connection is maintained
Packet Data
BS Service Request
BS Service Response
MS BS MSC / VLR PDSN PCF
Tbsreq9 T311
voice call
voice call
Dormant packet data session, PPP connection is maintained
7
Figure 3.17.4.8-1 Mobile Terminated Packet Data Rejection During a Voice Call 8
a. It is assumed that the MS has performed MIP registration (if required) and 9
established a PPP connection. The packet data service instance is dormant. Packet 10
data arrives at the PDSN and is sent on the A10 connection to the PCF. 11
b. The PCF sends an A9-BS Service Request message to the BS to request packet 12
service and starts timer T
bsreq9
. 13
c. The BS sends a BS Service Request message to the MSC and starts timer T
311
. 14
d. The MSC sends a BS Service Response message with cause value MS busy to the 15
BS. The BS stops timer T
311
upon receipt of the BS Service Response message. 16
e. The BS sends an A9-BS Service Response message to the PCF containing the cause 17
value MS busy. The PCF stops timer T
bsreq9
upon receipt of the A9-BS Service 18
3.17.4.9 Dormant Handoff (Inter-BS/Inter-PCF) - Mobile Served by Same PDSN 20
To perform dormant handoff of a packet data session, the MS initiates the dormant 21
handoff of each of its dormant packet data service instances. The packet data session may 22
TIA-2001.3-C
Section 3 130
become active as a result of the dormant handoff of one packet data service instance (i.e. 1
PDSN has data to send to the MS over that packet data service instance) in which case 2
the dormant handoff of the remaining packet data service instances occur as given in 3
section 3.17.4.9.2. 4
3.17.4.9.1 Intra-PDSN Dormant Handoff of a PDSI, While the Packet Data Session is 5
Dormant 6
The following call flow provides an illustration for a successful handoff of a dormant 7
packet data service instance from source PCF to target PCF during the Dormant State of 8
the packet data session. It is assumed that the PCF is uniquely identified by an ANID. On 9
detection of a new PZID, NID or SID, and the MS determining that it needs to notify the 10
network, the MS sends an Origination Message to the target BS that includes the packet 11
data service option and the DRS bit set to 0. The Origination Message may include the 12
previous PZID, NID and SID if any of these parameters changed during the dormant 13
handoff. The MS sends an Origination message for each of its dormant packet data 14
service instances. Based on the IDs (PZID, NID and/or SID) in the Origination Message 15
and the corresponding information in the A9-Setup-A8 messages, the target PCF 16
populates the PANID and CANID fields of the ANID NVSE with the ANID received 17
from the BS and the ANID of the target PCF respectively, and sends it to the serving 18
PDSN in each A11-Registration Request message. If neither the previous PZID, nor the 19
previous NID, nor the previous SID were sent by the MS , the target PCF shall set the 20
PANID field to zero. Upon determining that it supports the packet data session for the 21
MS, the serving PDSN compares the PANID (if non-zero) to the stored CANID and 22
determines that PPP re-negotiation is not required. The PDSN updates its stored ANID 23
with the CANID received from the PCF. 24
The BS does not establish a traffic channel when it receives an origination message with 25
the DRS bit set to 0; a traffic channel may be established after the completion of setup 26
of the A8 and A10 bearer connections if the PDSN has data for the MS. The following 27
call flow shows the case where the MS uses an Origination Message to handoff a packet 28
data service instance. Refer to section 3.17.4.9.2 for the case where the MS uses an 29
Enhanced Origination Message to handoff a packet data service instance. 30
TIA-2001.3-C
131 Section 3

Assignment Request
MSC Source PCF Time Comment
a
b
c
d
e
f
g
h
PDSN Target PCF MS
CMService Request
Origination Message
A9-Setup-A8
BS Ack Order
Packet Data Session Dormant, PPP connection is maintained
T
A8-setup

Target BS
T
303

i
Release Order
j
Assignment Failure
T
10
Clear Command
T
20

Clear Complete
T
315
k
l
m
PDSNDormant HO
d
1
PDSN, Packet Data Session Dormant 3
a. It is assumed that the MS has established a PPP connection with the PDSN and 4
performed a MIP registration (if required) but the packet data session is now 5
dormant. The MS does not have an active voice call in progress. 6
b. The dormant MS detects a change of PZID, SID or NID and initiates an origination 7
with the DRS bit set to 0. 8
c. The target BS acknowledges the receipt of the Origination Message with a Base 9
Station Ack Order to the MS. 10
d. The target BS constructs a CM Service Request message, places it in the Complete 11
Layer 3 Information message, sends the message to the MSC and starts timer T
303
. 12
e. The MSC sends an Assignment Request message to the target BS to request 13
assignment of resources and starts timer T
10
. For packet data services, a terrestrial 14
circuit between the MSC and the BS is not required. On receipt of this message the 15
target BS stops timer T
303.
. 16
f. The target BS sends an A9-Setup-A8 message, with Data Ready Indicator set to 0, 17
to the target PCF and starts timer T
A8-setup
. The handoff indicator of the A9 18
Indicators IE shall be set to 0. 19
TIA-2001.3-C
Section 3 132
g. The target PCF establishes the A10 link and the PDSN disconnects the old A10 link 1
(refer to procedure in section 3.17.5.8). (If the PDSN has data for the MS, it responds 2
to the target PCF with an A11-Registration Reply message with the Data Available 3
Indicator in a CVSE.) 4
h. The target PCF responds to the target BS with an A9-Release-A8 Complete message. 5
The target BS stops timer T
A8-setup
. 6
If the PDSN responds to the target PCF with a Data Available Indicator, the target 7
PCF responds to the target BS with an A9-Connect-A8 message with cause element 8
set to Data ready to send. In this case, the target BS establishes a traffic channel as 9
described in Figure 3.17.4.10-1steps h-m. 10
i. The target BS sends the Assignment Failure message to the MSC with a cause value 11
indicating Packet Call Going Dormant and starts timer T
20
. The MSC stops timer 12
T
10.
13
j. After the MSC has successfully authenticated the MS, it sends a Clear Command 14
message to the target BS with cause value Do not notify mobile and starts timer 15
T
315
. Upon receipt of the Clear Command the target BS stops timer T
20.
16
k. The target BS may send a Release Order to the MS (with normal release) to cause 17
the MS to transition back to the Mobile Station Idle State. This allows the MS to 18
send Origination Messages for remaining packet data service instances sooner, rather 19
than to wait for the System Access Timer (T
42m
) to expire before starting the 20
dormant handoff procedure for these packet data service instances. 21
l. The target BS sends a Clear Complete message to the MSC. The MSC stops timer 22
T
315.
23
m. The packet data session remains dormant. 24
3.17.4.9.2 Intra-PDSN Dormant Handoff, while the Packet Data Session is Active 25
If the PDSN indicated that it has data to send on a packet data service instance that was 26
handed off according to the call flow in the previous sections (refer to section 3.17.4.9.1), 27
any packet data service instance that has not yet been handed off is handed off according 28
to the following call flow. 29
TIA-2001.3-C
133 Section 3
Time Comment
PDSN Dormant HO
MS
Source BS Target BS MSC
Source
PCF
Target
PCF
PDSN
Enhanced Origination Message
BS Ack Order
A9-Setup-A8
TA8-setup
a
b
c
d
e
1
PDSN, Packet Data Session Active 3
a. The MS detected a change in packet zone (while the packet data session was 4
dormant) and sent an Origination Message for a dormant packet data service 5
instance. The PDSN indicated it had data to send on that packet data service instance 6
and a traffic channel was assigned (Refer to Call flow 3.17.4.10). The MS sends an 7
Enhanced Origination Message to the target BS with DRS bit set to 0 for another 8
dormant packet data service instance. If the MS has more than one additional packet 9
data service instance (besides the active packet data service instance) it sends an 10
Enhanced Origination with DRS bit set to 0 for each of those instances resulting in 11
the execution of this procedure for each such packet data service instance. 12
b. The target BS acknowledges receipt of the Enhanced Origination Message by 13
sending a BS Ack Order to the MS. 14
c. The target BS sends an A9-Setup-A8 message, with Data Ready Indicator set to 0, 15
to the PCF and starts timer T
A8-setup
. The handoff indicator of the A9 Indicators IE 16
shall be set to 0. 17
d. The target PCF establishes the A10 connection and the PDSN disconnects the old 18
A10 connection (refer to procedure in 3.17.5.8). (If the PDSN has data for the MS, it 19
responds to the PCF with an A11-Registration Reply message with the Data 20
Available Indicator in the CVSE.) 21
e. The PCF responds to the BS with an A9-Release A8 Complete message. The BS 22
stops timer T
A8-setup
. 23
If the PDSN responds to the target PCF with a Data Available Indicator, the target 24
PCF responds to the target BS with an A9-Connect-A8 message with cause element 25
set to Data ready to send. In this case, the target BS may initiate service negotiation 26
TIA-2001.3-C
Section 3 134
procedures and continue as in j-l in Figure 3.17.4.10-1 so that accounting 1
information can be sent to PDSN. 2
3.17.4.10 Dormant Handoff of a PDSI (Inter-BS/Inter-PCF) - Mobile Served by a Different 3
PDSN 4
This section provides a call flow for the case where an MS with a packet data session in 5
Dormant State moves into a different packet zone and ends up being connected to a 6
different PDSN. Upon detecting a new packet zone, the MS sends an Origination 7
Message with DRS=0 for each packet data service instance to initiate the dormant 8
handoff of that packet data service instance. (Note to perform dormant handoff of a 9
packet data session the MS performs dormant handoff of each of its packet data service 10
instances.) The Origination Messages may contain the ANID information of the previous 11
packet zone, which the target PCF is required to forward as a PANID together with its 12
own ANID (CANID) to the serving PDSN. If the previous ANID information is not 13
received from the BS, the PANID field is set to 0. If the target PDSN supports a packet 14
data session for the MS, it compares the received PANID (if set to a non-zero value) to 15
the stored CANID for the MS. The PDSN determines that PPP re-negotiation is required 16
and updates the stored ANID with the CANID received from the target PCF. In the event 17
that multiple service instances are supported, PPP re-negotiation is performed once for 18
the packet data session. 19
The following call flow shows the dormant handoff of a packet data service instance 20
while the packet data session is dormant. As shown in this call flow the packet session 21
may become active as a result of the dormant handoff of one packet data service instance 22
(i.e. a traffic channel is assigned since the PDSN has data to send to the MS on that 23
packet data service instance). In this case the dormant handoff of the remaining dormant 24
packet data service instances occurs as shown in section 3.17.4.9.2. 25
TIA-2001.3-C
135 Section 3

MS
Origination
BS ACK Order
MSC
CM Service Request
A9-Setup-A8
Assignment Request
Target
PCF
Target
PDSN
A9-Connect-A8
Assignment Complete
a
b
c
d
e
f
g
h
T
303

T
10

T
A8-setup

PDSN
Dormant HO
Procedure
A9-Update-A8
A9-Update-A8 Ack
T
upd9

i
j
TCH
Establishment
Time
A11 Accounting
Procedures
Target
BS
k
Comment
l
m
1
Figure 3.17.4.10-1 Dormant Handoff of a PDSI (Inter-BS/Inter-PCF) - Mobile Served by a 2
Different PDSN 3
a. The MS with a dormant packet data session detects a change of PZID, SID or NID 4
and initiates an origination with the DRS bit set to 0. 5
b. The target BS acknowledges the receipt of the Origination Message with a Base 6
Station Acknowledgment Order to the MS. 7
c. The target BS constructs a CM Service Request message, places it in a Complete 8
Layer 3 Information message, sends the message to the MSC, and starts timer T
303
. 9
d. The MSC sends an Assignment Request message to the target BS to request 10
assignment of radio resources and starts timer T
10
. For packet data services, a 11
terrestrial circuit between the MSC and the BS is not required. On receipt of this 12
message the target BS stops timer T
303
. 13
TIA-2001.3-C
Section 3 136
e. The target BS transmits an A9-Setup-A8 message to the target PCF, with DRS=0, 1
to establish an A8 connection and starts timer T
A8-setup
. The Handoff Indicator of the 2
A9 Indicators IE shall be set to 0. 3
f. The procedure for establishing A10 connection is performed; refer to section 4
3.17.5.9. 5
g. Upon establishment of the A10 connection, the target PCF establishes an A8 6
connection and transmits an A9-Connect-A8 Message with cause set to Data ready 7
to send. If fast handoff is supported, the target PCF passes the Anchor P-P Address 8
and the PDSN Address (set to the address of the target PDSN) to the target BS as 9
part of this message. Upon reception of the A9-Connect-A8 message, the target BS 10
stops the timer T
A8-setup
. 11
h. The target BS initiates the establishment of a radio traffic channel. 12
i. After the radio link is established, the target BS sends an Assignment Complete 13
message to the MSC. The MSC stops timer T
10
. 14
j. The target BS sends an A9-Update-A8 message to the target PCF to pass Accounting 15
Parameters. The target BS starts timer T
upd9
. 16
k. The A11 Accounting Procedure is performed. 17
l. The target PCF, upon receipt of the A9-Update-A8 message, responds with an A9- 18
Update-A8 Ack message. Upon receipt of this message, the target BS stops timer 19
T
upd9
. 20
m. The PPP connection establishment procedure and Mobile IP Registration (if 21
required) on the PPP connection (over main packet data service instance) are 22
performed between the MS and PDSN. Refer to section 3.17.4.9.2 for the handoff of 23
the additional packet data service instances. 24
3.17.4.11 Dormant Handoff of a PDSI (Inter-BS/Inter-PCF), Packet Data Session is 25
Dormant - Mobile Served by Same PDSN, Failed Authentication in MSC 26
Following Session Establishment (PDSN Has Data to Send) 27
The following call flow provides an illustration for a handoff of a dormant packet data 28
service instance during the Dormant State of the packet data session from source PCF to 29
target PCF. The BS does not immediately establish a traffic channel when it receives an 30
origination message with DRS set to 0. 31
The MSC starts its authentication procedure using the authentication data received in the 32
CM Service Request message and in parallel instructs the BS to assign necessary 33
resources via the Assignment Request message. 34
The BS communicates with the PCF to set up an A10 connection. The PCF establishes 35
the A10 connection and notifies the BS that a traffic channel and an A8 connection are 36
required. This is a result of the PDSN indicating that it has data to send in the A11- 37
Registration Reply. The BSC then sends an Assignment Complete message to the MSC 38
after successful establishment of the traffic channel. Meanwhile, the MSC was still 39
waiting for the authentication results to come back from the authentication center. The 40
results are received indicating that the authentication has failed. The MSC initiates a 41
clearing of the packet data call by sending a Clear Command message with the release 42
indicator indicating authentication failed to the BS. The BS sends an A9-Release-A8 43
message to the PCF containing a cause value set to Authentication failure. The PCF 44
initiates the release of all A10 connections by sending an A11-Registration Request 45
message containing the failure indication within the air-link record information. 46
TIA-2001.3-C
137 Section 3
The above scenario is illustrated in the following call flow. 1

A9-Release-A8
MSC Source PCF
Time Comment
a
PDSN MS
Target BS
Authentication results received
indicating failure

Clear Command. (Auth. Failed )
A9-Release-A8Complete
Clear Complete
d
TCHrelease
e
f
g
c
A10 Release
T
315
h
i
Dormant Handoff Procedure with Reactivation of the PDSI
b
j
Packet Data Session Null/Inactive
Packet Data Session Active
Target PCF
T
rel9
2
Figure 3.17.4.11-1 Dormant Handoff of a PDSI (Inter-BS/Inter-PCF) - Mobile Served by Same 3
PDSN, Failed Authentication in MSC Following Session Establishment (PDSN Has Data to Send) 4
a. It is assumed that the MS has established a PPP connection with PDSN and 5
performed a MIP registration (if required) but is now dormant. 6
b. The MS detects a change of PZID, SID or NID and initiates a dormant handoff, 7
which results in the reactivation of the PDSI and traffic channel establishment. Refer 8
to section 3.17.4.9.1 (or 3.19.6.1 if the alternate dormant handoff procedure is used). 9
During this step, the MSC requests the target BS to proceed with the handoff before 10
it had authenticated the MS. 11
c. The packet data session is active. If the MS has additional packet data service 12
instances, they may be handed off while the packet data session is active (refer to 13
section 3.17.4.9.2). 14
d. The MSC receives the authentication result from the authentication center indicating 15
that the authentication has failed, sends a Clear Command message to the target BS 16
indicating that authentication has failed and starts timer T
315
. This step may occur 17
any time after the MSC requested the target BS to assign a traffic channel to the MS 18
during step c. 19
e. The target BS sends a Release Order to the MS indicating Service Option 20
Rejected. The MS returns a Release Order to the BS. 21
TIA-2001.3-C
Section 3 138
f. The target BS informs the target PCF via an A9-Release-A8 message with the cause 1
value set to Authentication failure. The target BS uses the SR_ID of any one of the 2
active packet data service instances in the A9-Release-A8 message. The target BS 3
starts timer T
rel9
. 4
g. The target PCF initiates release of all A10 connections associated with the MS by 5
sending an A11-Registration Request message to the PDSN with Lifetime value set 6
to 0 for each packet data service instance and using Authentication failed for 7
dormant packet call as a release indicator in the air-link record. 8
h. Upon the response from the PDSN, the PCF sends an A9-Release-A8 complete 9
message back to the BS. The BS and PCF release all A8 connections for the MS. The 10
BS stops T
rel9.
11
i. The BS sends a Clear Complete message back to the MSC indicating that resources 12
for the packet data call have been released. Upon reception of the message, the MSC 13
stops timer T
315
. 14
j. The packet data session is in the Null/Inactive State. 15
3.17.4.12 Dormant Handoff of a PDSI (Inter-BS/Inter-PCF) -. Mobile Served by Same 16
PDSN, Failed Authentication in MSC Following Session Establishment (PDSN 17
Does Not Have Data to Send) 18
This scenario is similar to the scenario in section 3.17.4.11, except the PDSN does not 19
have data to send. The MSC sends the Assignment Request message to the BS before it 20
has received the authentication results. If authentication of the MS later fails, the MSC 21
Clear Command message to the BS with the Authentication failure cause value. The 22
BS then uses the A9-Update-A8 message to alert the PCF that it should tear down the 23
A10 connection for that MS. 24
TIA-2001.3-C
139 Section 3
1
a
PDSN Target PCF MS
Target BS
Release Order
d
Clear Command
T
20

Clear Complete
T
315
e
i
j
Conditional
MS authentication
failure
c
A9-Update-A8
A9-Update-A8 Ack
T
upd9

A10 Release
Procedures
f
g
h
Intra-PDSNDormant Handoff Procedures
b
2
Figure 3.17.4.12-1 Dormant Handoff of a PDSI (Inter-BS/Inter-PCF) - Mobile Served by Same 3
PDSN, Failed Authentication in MSC Following Session Establishment (PDSN Does Not Have Data 4
to Send) 5
a. It is assumed that the MS has performed a MIP registration (if required) and 6
established a PPP connection with the PDSN but is now dormant. 7
b. The MS with a dormant packet data session detects a change of PZID, SID or NID 8
and initiates a dormant handoff, which results in the MS being served by the same 9
PDSN. Refer to Figure 3.17.4.9.1-1, steps b through i. During this step, the MSC 10
requests the target BS to proceed with the handoff before it had authenticated the 11
MS. Timer T
20
is still running at the target BS. 12
c. The MSC receives authentication results from the authentication center indicating 13
that authentication has failed. 14
d. The MSC sends the Clear Command message to the target BS indicating that 15
authentication has failed. The target BS stops timer T
20
. 16
Rejected. 18
f. The target BS sends an A9-Update-A8 message with the cause value set to 19
authentication failure. The target BS starts timer T
upd9
. The target BS uses the 20
SR_ID of any of the dormant service instances in the A9-Update-A8 message. 21
sending an A11-Registration Request message to the PDSN with Lifetime value is 23
TIA-2001.3-C
Section 3 140
set to 0 for each packet data service instance and using Authentication failed for 1
dormant packet call as a release indicator in the air-link record.. 2
h. Upon completion of the A10 release procedures, the target PCF sends an A9-Update- 3
A8 Ack message to target BS. The target BS stops timer T
upd9
. 4
i. The target BS sends a Clear Complete message back to the MSC indicating that 5
resources for the packet data call have been released. 6
j. The packet data session is in the Null/Inactive State. 7
3.17.4.13 Soft / Softer Handoff Packet Data 8
Call flows for soft/softer handoff of the FCH, DCCH, and SCH are explained in section 9
3.19.2. 10
3.17.4.14 Inter-BS Hard Handoff (Within the Same PCF) 11
The following call flow provides an illustration for a successful hard handoff event 12
during packet data services. To simplify the diagram, it is assumed that for purposes of 13
this example, the packet call is not in inter-BS soft/softer handoff prior to the handoff, 14
and no other service options are connected. 15
TIA-2001.3-C
141 Section 3

MS Source BS MSC
Time
Comment
a
b
c
d
e
f
g
Handoff Required
Handoff Request
Target BS
T9
h
j
i
k
l
m
n
T306
T315
Twaitho
x
PCF PDSN
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
o
p
q
r
Talc9
Twaitho9
A9-AL Disconnected
s
A9-AL Disconnected Ack
t
Tald9
TA8-setup
Tre19
A9-Setup-A8
u
v
TA8-setup
T11
T8
Taldak
1
Figure 3.17.4.14-1 Inter-BS Hard Handoff (Within the Same PCF) 2
a. Based on an MS report that it crossed a network specified threshold for signal 3
strength or for other reasons, the source BS recommends cdma2000
to cdma2000
4
hard handoff to one or more cells in the domain of the target BS. The source BS 5
sends a Handoff Required message with the list of cells to the MSC and starts timer 6
T
7
. The Service Configuration Record in this message identifies the active packet 7
data service instances. The Service Option List information element identifies all 8
packet data service instances of the MS (both active and dormant). 9
b. The MSC sends a Handoff Request message to the target BS and starts timer T
11
. 10
The Service Configuration Record in this message identifies the active packet data 11
service instances. The Service Option List information element identifies all packet 12
TIA-2001.3-C
Section 3 142
data service instances of the MS (both active and dormant). Note the target BS 1
determines which packet data service instances are dormant by comparing this list 2
with the list of packet data active service options in the Service Configuration 3
Record. 4
c. For each active packet data service instance, the target BS sends an A9-Setup-A8 5
message to the PCF to establish the A8-Connection and starts timer T
A8-setup
. In this 6
case, the handoff indicator field of the A9-Setup-A8 message is set to 1. 7
d. Upon receipt of each A9-Setup-A8 message from the target BS, the PCF establishes 8
the A8 connection. At this point of time, the PCF continues to forward packet data 9
received from PDSN to the source BS (i.e., the target BS doesnt receive packet data 10
from the PCF). The PCF sends the A9-Connect-A8 message and starts timer 11
T
waitho9
. When the target BS receives the A9-Connect-A8 message it stops timer 12
T
A8-setup
. 13
The establishment of the A10 connection is not performed because this is an intra- 14
PCF handoff. 15
e. The target BS sends a Handoff Request Acknowledgment message to the MSC. The 16
target BS starts timer T
9
to wait for arrival of the MS on its radio channel. Upon 17
receipt of the Handoff Request Acknowledgement message the MSC stops timer T
11.
18
f. The MSC

prepares to switch the MS from the source BS to the target BS. The MSC 19
sends a Handoff Command message to the source BS. The source BS stops timer T
7
. 20
g. The PCF stops packet transmission for the MS to the source BS upon receipt of A9- 21
AL (Air Link) Disconnected message from source BS. At this point in time, the 22
source BS starts timer T
ald9
. 23
h. The PCF sends an A9-AL Disconnected Ack message in response to the A9-AL 24
Disconnected message. The BS stops timer T
ald9
. 25
i. The source BS sends the General Handoff Direction Message or Universal Handoff 26
Direction Message to the MS and starts timer T
8
. If the MS is allowed to return to 27
the source BS, then timer T
waitho
is started by the source BS. 28
j. The MS may acknowledge the General Handoff Direction Message or Universal 29
Handoff Direction Message by sending an MS Ack Order to the source BS. The 30
source BS stops timer T
8
If the General Handoff Direction Message or Universal Handoff Direction Message 32
is sent using quick repeats, the source BS might not request an acknowledgment 33
from the MS. 34
k. The source BS sends a Handoff Commenced message to the MSC to notify it that the 35
MS has been ordered to move to the target BS channel. The source BS starts timer 36
T
306
to await the Clear Command message from the MSC. If timer T
waitho
has been 37
started, the source BS shall wait for that timer to expire before sending the Handoff 38
Commenced message. 39
l. The MS sends a Handoff Completion message to the target BS. The target BS detects 40
that the MS has successfully accessed the target BS and stops timer T
9
. However, if 41
timer T
9
expires before the target BS detects that the MS has successfully accessed 42
the target BS, the target BS shall send a Handoff Failure message to the MSC. Refer 43
to [14] for detailed procedures. 44
m. The target BS sends the BS Ack Order to the MS over the air interface. 45
TIA-2001.3-C
143 Section 3
n. Upon the receipt of the Handoff Completion message from MS, the target BS sends 1
an A9-AL Connected message to the PCF and starts timer Talc9. The PCF stops 2
timer T
waitho9
, updates its routing table to route packet data sent from the PDSN to 3
the target BS, and restarts packet data transmission to the target BS. In this case, PCF 4
does not perform the A10 connection establishment procedure because the A10 5
connection has already been established. 6
o. The PCF sends the A9-AL Connected Ack message as the response of the A9-AL 7
Connected message and stops timer T
alc9
. If timer T
alc9
is expired, the target BS may 8
resend the A9-AL Connect message. 9
p. The target BS sends a Handoff Complete message to the MSC to notify it that 10
handoff has been successfully completed. 11
q. The MSC sends a Clear Command message to the source BS and starts timer T
315
. 12
The source BS stops timer T
306
. 13
r. For each A8 connection, the source BS sends an A9-Release-A8 message to the PCF 14
to release the A8-Connection and starts timer T
re19
. 15
s. Upon the receipt of each A9-Release-A8 message from the source BS, the PCF 16
releases the A8-Connection and responds with an A9-Release-A8 Complete 17
message. Upon receiving the A9-Release-A8 message the source BS stops timer 18
T
re19
. 19
t. The source BS sends a Clear Complete message to the MSC to notify it that clearing 20
has been accomplished. The MSC stops timer T
315
u. For each dormant packet data service instance (if any), the target BS sends an A9- 23
Setup-A8 message to the PCF with Data Ready Indicator set to 0 and starts an 24
associated timer T
A8-setup
. The message also includes the ANID of the PCF. Steps 25
u v may occur any time after step l. 26
v. The target PCF determines that no A11 procedures are needed since an A10 27
connection already exists for each dormant packet data service instance and the 28
handoff is within the same PCF (based on the received ANID information). The 29
target PCF returns an A9-Release-A8-Complete message as a response to each A9- 30
Setup-A8 message. The BS stops the associated T
A8-setup
timer for each A9-Setup- 31
A8 message. 32
3.17.4.15 Inter-PCF Hard Handoff (Within Same PDSN) 33
The following call flow provides an illustration for a successful hard handoff event from 34
a cdma2000
system to another cdma2000
system during packet data services. In this 35

scenario, it is assumed that the source and target PCF are both served by the same PDSN. 36
To simplify the diagram, it is assumed that for purposes of this example, the packet call is 37
not in inter-BS soft/softer handoff prior to the handoff, and no other service options are 38
connected. This call flow shows the case of hard handoff without fast handoff. For fast 39
handoff, refer to the call flow in section 3.19.4. 40
The ANID of the source PCF is communicated by the source BS to the target BS via the 41
Handoff Required/Request messages and is subsequently sent to target PCF via the A9- 42
AL-Connected message. The target PCF inserts its ANID (CANID) and communicates 43
both sets of access network identifiers to the PDSN. 44
TIA-2001.3-C
Section 3 144

MS Source BS MSC
Time
Comment
a
b
c
d
e
f
g
Handoff Required
Handoff Request
T9
h
j
i
k
l
m
n
T306
T315
Twaitho
x
Source
PCF
PDSN
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
Clear Complete
MS Ack Order
BS Ack Order
o
p
q
r
Target
PCF
Target BS
s
t
Talc9
Twaitho9
A9-AL Disconnected
u
Tald9
TA8-setup
Tre19
A9-Setup-A8
A9-Release-A8-Complete
T
A8-setup

A11 Handoff procedures
v
w
x
A11 Handoff procedures
Taldak
T8
1
Figure 3.17.4.15-1 Inter-PCF Hard Handoff (Within Same PDSN) 2
strength, changes to a different ANID or for other reasons, the source BS 4
recommends cdma2000
to cdma2000
hard handoff to one or more cells in the 5

domain of the target BS. The source BS sends a Handoff Required message with the 6
list of cells to the MSC and starts timer T
7
. The source BS includes the ANID 7
information of the source PCF in the Handoff Required message. The Service 8
Configuration Record in this message identifies the active packet data service 9
TIA-2001.3-C
145 Section 3
instances. The Service Option List information element identifies all packet data 1
service instances of the MS (both active and dormant). 2
b. The MSC sends a Handoff Request message (which includes the ANID information 3
previously communicated to the MSC via the Handoff Required message) to the 4
target BS. The Service Configuration Record in this message identifies the active 5
packet data service instances. The Service Option List information element identifies 6
all packet data service instances of the MS (both active and dormant). Note the target 7
BS determines which packet data service instances are dormant by comparing this 8
list with the list of active service options in the Service Configuration Record. 9
message to the target PCF to establish the A8 connection and starts timer T
A8-setup
. 11
In this case, the handoff indicator field of the A9-Setup-A8 message is set to 1 12
(during handoff). 13
d. Upon receipt of each A9-Setup-A8 message from the target BS, the target PCF 14
establishes the A8 connection. At this point of time, the PDSN continues to forward 15
packet data to the source BS via source PCF. (i.e., The target BS and target PCF 16
dont receive packet data from the PDSN.) The target PCF sends the A9-Connect-A8 17
waitho9
. When the target BS receives the A9-Connect-A8 18
message it stops timer T
A8-setup
. 19
The establishment of the A10 connection is not performed because the handoff 20
indicator field of the A9-Setup-A8 message is set to 1 (during handoff). 21
9
to wait for the arrival of the MS on its radio channel. 23
f. The MSC prepares to switch the MS from the source BS to the target BS and sends a 24
Handoff Command message to the source BS. The source BS stops timer T
7
. 25
g. The PCF stops packet transmission for the MS to the source BS upon receipt of A9- 26
AL Disconnected message from the source BS. At this point of time, the source BS 27
starts timer T
ald9
. 28
h. The PCF sends the A9-AL Disconnected Ack message as a response to the A9-AL 29
Disconnected message. The BS stops timer T
ald9
. 30
8
. If the MS is allowed to return to 32
the source BS, then timer T
waitho
8
upon receipt of this message. If the General Handoff 36
Direction Message or Universal Handoff Direction Message is sent using quick 37
repeats, the source BS might not request an acknowledgment from the MS. 38
k. The source BS sends a Handoff Commenced message to the MSC to notify it that the 39
T
306
waitho
has been 41
l. The MS sends a Handoff Completion Message to the target BS. The target BS 44
detects that the MS has successfully accessed the target BS and stops timer T
9
. 45
However, if timer T
9
expires before the target BS detects that the MS has 46
TIA-2001.3-C
Section 3 146
successfully accessed the target BS, the target BS shall send a Handoff Failure 1
message to the MSC. Refer to [14] for detailed procedures. 2
n. Upon the receipt of the Handoff Completion message from the MS, the target BS 4
sends an A9-AL Connected message, including the ANID received previously in the 5
Handoff Request message, to the target PCF and starts timer T
alc9
. The target PCF 6
stops timer T
waitho9
. 7
o. The target PCF establishes the A10 links associated with the packet data active 8
service instances and the PDSN disconnects the old A10 links (refer to procedure in 9
3.17.5.10). 10
p. The target PCF sends the A9-AL Connected Ack message in response to the A9-AL 11
Connected message and stops timer T
alc9
. If timer T
alc9
expires, the target BS may 12
resend the A9-AL Connect message. 13
q. The target BS sends a Handoff Complete message to the MSC to indicate that the 14
handoff was successfully completed. 15
r. The MSC sends a Clear Command message to the source BS and starts timer T
315
. 16
306
. 17
s. For each A8 connection, the source BS sends an A9-Release-A8 message to the 18
source PCF to release the A8 connection and starts timer T
re19
. 19
t. Upon the receipt of each A9-Release-A8 message from the source BS, the source 20
PCF releases the A8 connection and responds with an A9-Release-A8 Complete 21
message. When the source BS receives the A9-Release-A8 Complete message it 22
stops timer T
re19
. 23
u. The source BS sends a Clear Complete message to the MSC to notify it that clearing 24
315
v. For each dormant packet data service instance (if any), the target BS sends an A9- 27
Setup-A8 message to the PDSN with Data Ready Indicator set to 0 and starts an 28
associated timer T
A8-setup
. Steps v x may occur any time after step l. 29
w. The target PCF establishes the A10 links associated with the dormant packet data 30
service instances and the PDSN disconnects the old A10 links (refer to procedure in 31
3.17.5.10). 32
x. The target PCF sends an A9-Release-A8-Complete message as a response to each 33
A9-Setup-A8 message. The BS stops the T
A8-setup
timer associated with each A9- 34
Setup-A8 message. 35
3.17.4.16 Inter-PCF Hard Handoff (Within Same PDSN) With Return On Failure 36
The following call flow provides an illustration for a hard handoff event from a 37
cdma2000
system to another cdma2000
system. In this scenario, the MS successfully 38

returns to the source BS after hard handoff fails. It is assumed that the call is not in inter- 39
BS soft/softer handoff prior to the hard handoff, and thus no inter-BS connections need to 40
be removed. 41
TIA-2001.3-C
147 Section 3

MS Source BS MSC
Time
Comment
a
b
c
d
e
f
g
Handoff Required
Handoff Request
T9
h
j
i
k
l
m
n
T315
Twaitho
Source
PCF
PDSN
A9-Setup-A8
A9-Connect-A8
Handoff Request Ack
Handoff Command
GHDM / UHDM
CF Search Report
Message
T7
Clear Command
A9-Release-A8
Clear Complete
MS Ack Order
Target
PCF
Target BS
Handoff Failure
Twaitho9
A9-AL Disconnected
A9-AL Connected
A9-AL Connected Ack
o
p
q
r
Tald9
Talc9
TA8-setup
Tre19
Taldak
T8
1
Figure 3.17.4.16-1 Inter-PCF Hard Handoff (Within Same PDSN) With Return On Failure 2
strength or for other reasons, the source BS recommends cdma2000
to cdma2000
4
hard handoff to one or more cells in the domain of the target BS. The source BS 5
sends a Handoff Required message with the list of cells to the MSC and starts timer 6
T
7
. The Service Configuration Record in this message identifies the active packet 7
data service instances. The Service Option List information element identifies all 8
packet data service instances of the MS (both active and dormant). 9
b. The MSC sends a Handoff Request message to the target BS. The Service 10
service instances of the MS (both active and dormant). Note the target BS determines 13
which packet data service instances are dormant by comparing this list with the list 14
of active packet data service options in the Service Configuration Record. 15
message to the target PCF to establish the A8 connection and starts timer T
A8-setup
. 17
In this case, the handoff indicator field of the A9-Setup-A8 message is set to 1 18
(during handoff). 19
d. Upon receipt of each A9-Setup-A8 message from the target BS, the target PCF 20
establishes the A8 connection. At this point in time, the PDSN continues to forward 21
packet data to the source BS via the source PCF (i.e. the target BS and target PCF 22
dont receive packet data from the PDSN). The target PCF sends the A9-Connect-A8 23
TIA-2001.3-C
Section 3 148
waitho9
A8-setup
. 2
indicator field of the A9-Setup-A8 message is set to 1 (during handoff). 4
9
to wait for arrival of the MS on its radio channel. 6
f. The MSC prepares to switch the MS from the source BS to the target BS and sends a 7
7
. 8
g. Upon receipt of the Handoff Command message, the source BS sends the A9-AL 9
Disconnected message to the source PCF and starts timer T
ald9
. The source PCF 10
stops packet data transmission for the MS to the source BS upon receipt of the A9- 11
AL Disconnected message from the source BS. 12
h. The PCF sends the A9-AL Disconnected Ack message as a response of the A9-AL 13
Disconnected message. Upon receipt of this message, the source BS stops timer 14
T
ald9
. 15
8
. Because the MS is allowed to 17
return to the source BS, then timer T
waitho
8
If the General Handoff Direction Message or Universal Handoff Direction Message 22
is sent using quick repeats, the source BS might not request an acknowledgment 23
from the MS. 24
k. The MS sends a Candidate Frequency (CF) Search Report Message to the source BS 25
after handoff to the target has failed. 26
l. If the handoff fails (i.e., when the BS receives the CF Search Report Message), the 27
source BS sends the A9-AL Connected message to the source PCF and starts timer 28
T
alc9
. 29
m. The source PCF sends an A9-AL Connected Ack message to the source BS. The 30
source PCF restarts packet data transmission for the MS over existing A8 31
connection(s) upon receipt of the A9-AL Connected message from the source BS. 32
alc9
. 33
n. Upon receipt of the CF Search Report Message from the MS the source BS detects 34
that the MS has never accessed the target BS cell and sends a Handoff Failure 35
message to the MSC indicating the unsuccessful access by the MS. 36
o. The MSC sends a Clear Command message to the target BS and starts timer T
315
. 37
9
. 38
p. Upon receipt of the Clear Command message from the MSC, the target BS releases 39
and deallocates radio resources. The target BS sends an A9-Release-A8 message to 40
the target PCF for each active packet data service instance to instruct it to release the 41
associated dedicated resources and starts timer T
re19
. The target PCF stops timer 42
T
waitho9.
43
q. Upon the receipt of each A9-Release-A8 message from the target BS, the target PCF 44
releases resources and responds with an A9-Release-A8 Complete message. When 45
TIA-2001.3-C
149 Section 3
the target BS receives an A9-Release-A8 Complete message it stops the associated 1
timer T
re19
. 2
r. The target BS sends a Clear Complete message to the MSC. The MSC stops timer 3
T
315
. 4
3.17.4.17 MS Initiated Call Release to Null State 5
This section presents example call flows associated with an MS deactivation of a packet 6
data service instance (Active-to-Null State Transition) initiated by the MS. To simplify 7
the diagram, it is assumed that for purposes of this example, the packet call is not in inter- 8
BS soft/softer handoff prior to the deactivation. 9
There are two cases for MS Initiated Packet Data Service Instance Release to Null State: 10
1. MS Initiated Release when no other Packet Data Service Instance is Active 11
2. MS Initiated Release when other Packet Data Service Instance(s) are Active. 12
when no other Packet Data Service Instance is Active 14

Time Comment
Cl ear Request
Clear Command
Clear Compl ete
A9-Rel ease- A8 Compl ete
Active Packet Data Service Instance/Active Packet Data Session
Packet Data Session Released/ in Null state
a
b
c
d
e
f
h
i
A9-Rel ease- A8
T300
T315
Trel 9
TCH
Release
Procedure
g
A10
Rel ease
procedur e
Release Order
15
Figure 3.17.4.17.1-1 MS Initiated Packet Data Service Instance Release to Null State When No 16
Other Packet Data Service Instance is Active 17
a. If the packet data service instance becomes inactive at the MS (transition to Null 18
State), the MS requests the BS to disconnect the traffic channel. The MS sends a 19
Release Order with ORDQ=2 (Service Inactive) to the BS to request a transition to 20
the Null State. 21
TIA-2001.3-C
Section 3 150
b. The BS sends a Clear Request message with cause set to Normal clearing to the 1
300
. 2
the dedicated resources associated with the packet data service instance and starts 4
timer T
315
300
. 5
d. In response to the Clear Command message, the BS initiates call clearing over the air 6
interface by transmitting a Release Order. 7
e. The BS sends an A9-Release-A8 message, with cause value set to Normal call 8
release, to the PCF to instruct the PCF to release the dedicated resources associated 9
with the packet data service instance and its A10 connection. The BS starts timer 10
T
rel9
. 11
f. PCF initiates the procedure for releasing the A10 connection. Refer to section 12
3.17.5.6. for details. 13
rel9
. 15
underlying transport connection and stops timer T
315
i. The packet data service instance in the MS goes to the Null State and the Packet 19
Data Service instance is released in the BS/PCF/PDSN. 20
21
TIA-2001.3-C
151 Section 3
when other Packet Data Service Instance(s) are Active 2
A10
Connection
Release
Procedures
RRRM / RRRMM
Time Comment
Packet Data Session Active / PPP connected
Packet Data Session Active / PPP connected
a
b
e
g
A9-Release-A8
T
rel9

f
c
d
Service
Negotiation
Procedure
3
Figure 3.17.4.17.2-1 MS Initiated Packet data Service Instance Release to Inactive/Null State 4
When Other Packet Data Service Instances are Active 5
a. The MS is exchanging data on a packet data service instance. 6
b. The MS sends an RRRM or RRRMM message with Purge Indicator set to 1 to the 7
BS to request a transition of the active packet data service instance to the 8
Inactive/Null State. The CON_REF parameter in the message allows the BS to 9
determine the SR_ID of the affected packet data service instance. 10
c. Service negotiation procedures take place to dissociate the service instance from the 11
traffic channel. 12
d. The BS sends an A9-Release-A8 message to the PCF to instruct the PCF to release 13
rel9
. The cause code in this 14
message is set to Normal call release. 15
e. The PCF initiates the procedure for releasing the A10 connection. Refer to section 16
3.17.5.6. for details. 17
f. The PCF acknowledges the A9-Release-A8 message by returning an A9-Release-A8 18
rel9
. 19
TIA-2001.3-C
Section 3 152
g. At this point, the packet data service instance is considered to be in the Inactive/Null 1
State. 2
3.17.4.18 Dormant MS Power Down, A10 Release Initiated by the MSC/BS 3
An MS with a dormant packet data session and an active PPP session to a PDSN powers 4
down. A power down registration message is sent to the BS. Since the packet data session 5
is dormant, there is no A8 connection between the BS and the PCF for this MS. Refer to 6
section 3.17.4.4 for Active MS Power Down. 7
The BS sends a Location Updating Request message to the MSC indicating power down 8
registration. The MSC, which previously received an Assignment Failure or a Clear 9
Request message with cause Packet call going dormant (and therefore has the option of 10
retaining the state of the packet data session), may respond with a Location Updating 11
Accept message. In this situation, the following occurs: 12
The response includes a release indicator informing the BS that a packet call was 13
dormant. 14
Using the indicator, the BS triggers an A9-Update-A8 message to the PCF indicating 15
in the Cause information element that the MS has powered down. The BS may also 16
send this message to the PCF on its own. 17
The PCF starts releasing the A10 connection of each packet data service instance of 18
the MS by sending an A11-Registration Request message. Procedures for releasing 19
all A10 connections associated with the MS and removing mobility management 20
information from the PDSN are performed. 21
Registration Acknowledge
BS MS
MSC PCF PDSN
b
f
g
A9-Update-A8
A9-Update-A8 Ack
Active PPP session a
Registration
(power down)
d
c
e
h
Location. Updating Accept (Release indicator)
Time
Tupd9
A10 Release
Procedures
T3210
22
Figure 3.17.4.18-1 Dormant MS Power Down, A10 Release Initiated by the MSC/BS 23
a. An active PPP session exists between an MS with a dormant packet data session and 24
the PDSN (no data transferred over the PPP session). 25
TIA-2001.3-C
153 Section 3
b. The dormant MS powers down. A power down registration is sent to the BS. 1
c. The BS sends a Location Updating Request message to the MSC indicating that the 2
MS has powered down. The BS starts timer T
3210.
3
d. If the MSC is aware that the packet data session is dormant, the MSC sends a 4
Location Updating Accept message with a cause value set to Power down from 5
dormant state to inform the BS that a dormant packet data session is to be released. 6
3210.
7
e. The BS sends a Registration Acknowledgement Message to the MS after receiving a 8
power down registration message from the MS. 9
f. The BS sends the A9-Update-A8 message to the PCF if it receives a location update 10
message with cause value Power down from dormant state from the MSC. The BS 11
may also send the A9-Update-A8 message on its own. In both cases, the cause value 12
in the A9-Update-A8 message is set to Power down from dormant state. The BS 13
starts timer T
upd9
. 14
g. The PCF uses the MSID received in the A9-Update-A8 message to find the 15
corresponding A10 connection(s). Procedures for releasing all A10 connection(s) 16
associated with the MS and removing mobility management information from the 17
PDSN are performed. 18
h. The PCF sends an A9-Update-A8 Ack message to the BS. The BS stops timer T
upd9
. 19
3.17.4.19 Mobile Initiated Initial Packet Data Service Instance Setup Successful 20
Operation with Delayed Accounting Information 21
When an MS initiates a packet data service instance setup and PPP negotiation has not 22
yet been performed over that packet data service instance (main packet data service 23
instance), PPP negotiation is performed before transmitting packet data. In the case of 24
auxiliary packet data service instance setup PPP negotiation is not required before data 25
transfer since the main packet data service instance has already been set up. It is assumed 26
that the MS does not have an active voice call already in progress. 27
cdma2000
TCH establishment procedure may occur in parallel with the A8 connection 28

establishment, in which case the accounting information required to be included in the 29
Active-Start airlink record on the A11 interface may not be available in the A9-Setup- 30
A8 message. 31
When the cdma2000
TCH establishment procedure has completed, the BS updates the 32

PCF on the A9 connection with the accounting information required to be included in an 33
Active-Start Airlink record on the A11 interface. The BS sends an A9-Update-A8 34
message containing the information. 35
TIA-2001.3-C
Section 3 154
BS
MS
Origination
BS ACK Order
MSC
CM Service Request
A9-Setup-A8
Assignment Request
PCF PDSN
A9-Connect-A8
Assignment Complete
a
b
c
d
e
f
g
h
i
j
A10
Connection
T303
T10
TA8-setup
Transmitting packet data
cdma2000
TCH
A9-Update-A8
A9-Update-A8 Ack
A11
Accounting- Active k
time
l
m
Tupd9
n
1
Figure 3.17.4.19-1 Mobile Initiated Initial Packet Data Service Instance Setup Successful 2
Operation with Delayed Accounting Information 3
a. The MS transmits an Origination Message (DRS=1), with layer 2 acknowledgment 4
required, over the access channel of the air interface to the BS to request packet data 5
service instance setup. 6
303
. 10
10
. For packet data service, a terrestrial circuit 12
between the MSC and the BS is not required. 13
e. The BS and the MS initiate the establishment of a radio traffic channel. 14
f. The BS transmits an A9-Setup-A8 message to PCF with Data Ready Indicator set to 15
A8-setup
. All the required 16
accounting information to be included in the A11 Active-Start Airlink record is not 17
yet available. 18
TIA-2001.3-C
155 Section 3
g. The procedure for establishing an A10 connection is performed (including sending 1
the connection-setup airlink record to the PDSN). 2
and transmits an A9-Connect-A8 message to the BS. The BS stops timer T
A8-setup
. 4
i. The BS sends an Assignment Complete message to the MSC. This step may occur 5
any time after radio link establishment. The MSC stops timer T
10
. 6
j. The cdma2000
TCH establishment procedure is completed. The BS informs the 7

PCF via an A9-Update-A8 message that the traffic channel is now successfully 8
established to the MS by including the cause value Update accounting: late traffic 9
channel setup. The message includes the required accounting information to be 10
included in the A11 Active-Start Airlink record. The BS starts timer T
upd9
. 11
k. The PCF initiates an A11 registration procedure (Active-Start) that provides the 12
accounting information to the PDSN. 13
l. The PCF acknowledges the A9-Update-A8 message by returning an A9-Update-A8 14
Ack message back to the BS. Upon receipt of this message, the BS stops timer T
upd9.
15
m. The PPP connection establishment procedure and Mobile IP Registration (if 16
required) are performed on the PPP connection between the MS and PDSN in the 17
case of first/main packet data service instance setup. This setup does not apply to 18
auxiliary packet data service instance setup. 19
n. The MS begins transmitting/receiving packet data. 20
3.17.4.20 Accounting Parameters Update Event Procedure 21
During an active connection, if any of the accounting parameters defined in [17] change 22
the BS shall notify the PCF using the A9-Update-A8 message. The message shall contain 23
the changed parameters. The PCF then triggers an A11 procedure to update the PDSN 24
with the new accounting information. 25
TIA-2001.3-C
Section 3 156
BS MSC PCF PDSN
b
c
d
Parameter change
notification/
A9-Update-A8
A9-Update-A8 Ack
A11
Accounting- Active
Active PPP session
a
Parameter change
notification/
Tupd9
MS
Time
e
1
Figure 3.17.4.20-1 Accounting Parameters Update Event Procedure 2
a. An active PPP session exists and data is transferred over the connection. 3
b. An event occurs where parameters are changed/negotiated between the BS/MSC and 4
the MS. 5
c. The BS notifies the PCF using an A9-Update-A8 message when any of the following 6
parameters have changed: User-Zone, Quality of Service, Forward/Reverse Mux 7
Option. The BS starts timer T
upd9.
8
d. The PCF updates the PDSN with the new accounting information. 9
e. The PCF sends the A9-Update-A8 Ack message as an acknowledgment back to the 10
BS. The BS stops timer T
upd9
. 11
3.17.4.21 Packet Data Session Clearing MSC Initiated 12
An event occurs at the MSC that requires release of the packet data session and release of 13
radio and other resources for the call. The MSC initiates release of all the A8 and the A10 14
connections associated with the MS. Traffic channel and other resources assigned to the 15
call are also released. 16
TIA-2001.3-C
157 Section 3

Time Comment
Clear Command
Release Order
Clear Complete
a
b
c
d
e
f
g
A9-Release-A8
A10 Connection
Release Procedure
T315
Trel9
Release Order
h
i
1
Figure 3.17.4.21-1 Packet Data Session Clearing MSC Initiated 2
a. The packet data session is active when the MSC determines for some reason to 3
release the call. 4
b. The MSC sends a Clear Command message to the BS to instruct the BS to release 5
315
. 6
c. The BS initiates release of the traffic channel by sending a Release Order to the MS. 7
d. The MS acknowledges the Release Order from the BS by returning a Release Order 8
to the BS. 9
e. The BS then sends an A9-Release-A8 message with a cause value set to Packet data 10
session release to the PCF to instruct the PCF to release the dedicated resource 11
BS starts timer T
rel9
. 15
f. The PCF initiates the procedure for releasing all A10 connections. Refer to section 16
g. The PCF then sends an A9-Release-A8 Complete message to the BS. The BS stops 18
timer T
rel9
underlying A1 connection and stops timer T
315
. Clear Complete may occur any time 21
TIA-2001.3-C
Section 3 158
3.17.4.22 MS Initiated Reactivation from Dormant State; MS not Registered with New 1
PDSN 2
While in a dormant packet data session state, the MS has data to send to the network. The 3
MS detects a new packet zone and determines that it needs to notify the packet data 4
network. The MS sends an Origination Message to the target BS with the DRS bit set to 5
1. 6
Assignment Request
MSC
Time Comment
a
b
c
d
e
f
g
h
PDSN
Target
PCF
MS
CM Service Request
Origination Message
BS Ack Order
T
A8-setup
Target BS
T
303
i
j
Dormant Packet Data Session ,
Inter-PDSN Dorm.
HO Procedure
A9-Connect-A8
Assignment Complete
TCH Establishment
PPP Connection Establishment
T10
A9-Setup-A8
7
Figure 3.17.4.22-1 MS Initiated Reactivation from Dormant State; MS not Registered with 8
New PDSN 9
a. The MS has data to send to the network. Upon detection of a new PZID, SID or NID, 10
the MS determines that it needs to notify the packet data network. The MS sends an 11
Origination Message to the target BS with the DRS field set to 1. The MS may 12
include ANID information (PREV_SID, PREV_NID, or PREV_PZID) in the 13
message. 14
b. The target BS acknowledges the receipt of the Origination Message with a BS Ack 15
Order to the MS. 16
c. The target BS constructs the CM Service Request message, places it in the 17
Complete Layer 3 Information message, sends the message to the MSC, and starts 18
timer T
303
. 19
d. The MSC sends an Assignment Request message to the target BS to request 20
10
. On receipt of the Assignment 21
Request message, the target BS stops timer T
303
. 22
e. The target BS and the MS initiate the establishment of a traffic channel. 23
TIA-2001.3-C
159 Section 3
f. The target BS transmits an A9-Setup-A8 message to the PCF with Data Ready 1
Indicator set to 1 to establish an A8 connection and starts timer T
A8-setup
. If 2
ANID information was received from the MS, the target BS includes the PANID 3
in the ANID information element in the message. 4
g. The PDSN establishes an A10 connection with the target PCF (refer to procedure 5
in section 3.17.5.9). 6
h. The target PCF establishes an A8 connection with the target BS and transmits an A9- 7
Connect-A8 message with the Cause field set to Successful operation. If the PCF 8
supports fast handoff, it provides the Anchor PDSN Address and Source PDSN 9
Address and the PDSN provides the Anchor P-P Address. The PCF supporting fast 10
handoff passes the target PDSNs address (in the PDSN Address information 11
element) and the Anchor P-P Address to the BS as part of this message. The PCF 12
includes the Service Instance Info information element. If the MS has additional 13
PDSIs, the BS is informed about them through the dormant handoffs that the MS 14
initiates for them. Upon receiving an A9-Connect-A8 message, the BS stops the 15
timer T
A8-setup.
16
i. The BS transmits an Assignment Complete message to the MSC. The MSC stops 17
timer T
10
. This step may occur at any time after the radio link establishment. 18
j. The MS and PDSN perform PPP connection establishment and Mobile IP 19
Registration (if required). 20
TIA-2001.3-C
Section 3 160
3.17.5 A10/A11 Interface Call Flows 1
This section describes call flows for the A10/A11 interface. The following messages are 2
required to support the 3G packet data feature on the A10/A11 interface: 3
A11-Registration Request 4
A11-Registration Response 5
A11-Registration Update 6
A11-Registration Acknowledge 7
A11-Session Update 8
A11-Session Update Acknowledge 9
The A10/A11 interface uses messages modeled after Mobile IP for managing the A10 10
connections. The MS initiates packet data service instances by sending an IS-2000 11
origination (Origination Message or Enhanced Origination Message). Normal voice 12
service authentication procedures are followed for the subscriber, and then a traffic 13
channel is assigned, if necessary, and associated with the service instance. After 14
connection of the packet data service option, RLP synchronization between the MS and 15
the BS proceeds if applicable. The BS/PCF initiates setup of an A10 connection with the 16
PDSN by sending an A11-Registration Request message that includes the service option 17
of the requested A10 connection on the A11 interface. The PDSN may accept or reject 18
the connection setup request. If the connection setup request is acceptable, the PDSN 19
returns an A11-Registration Reply message with an accept indication, and the packet data 20
service instance is connected through the just established A10 connection. 21
The AAA stores subscription information such as the maximum number of packet data 22
service instances allowed and subscribed packet data service options. Therefore the RAN 23
should send the SO value to the PDSN in the A11-Registration Request message; the 24
PDSN may check the request against the information in the AAA and then either accept 25
or reject the request. 26
With the A10 connection in place, link layer/network layer frames pass over this 27
connection in both directions via Generic Routing Encapsulation (GRE) framing; refer to 28
[38]. The PDSN accepts these frames, strips the GRE, and processes them as normal 29
incoming frames for the appropriate interface and protocol. The other direction behaves 30
analogously, with the PDSN encapsulating the link layer/network layer frames in GRE, 31
and the PCF stripping the GRE before passing the frames over to the upper layer. At this 32
point, there is a point-to-point link layer/network layer connection between the MS and 33
the PDSN. 34
To set up an A10 connection, the PCF sends an A11-Registration Request message to the 35
PDSN. This message includes a PCF Session Identifier (PCF SID) to be used by the 36
PDSN as the Key in the GRE header when sending data frames on the A10 connection. 37
In the case of multiple A10 connections for one MS, each A10 connection is assigned a 38
separate Key to be used in the GRE header and a separate Lifetime timer. The PCF 39
Session Identifier (PCF SID) is unique only within the PCF entity. In the A11- 40
Registration Reply message, the PDSN assigns a PDSN Session Identifier (PDSN SID) to 41
be used by the PCF as the Key in the GRE header when sending data frames on the A10 42
connection. If both the PCF and the PDSN support a Session Identifier Version higher 43
than 0, the PDSN SID may be different from the PCF SID. This allows the PDSN to 44
choose a PDSN SID that is unique within the PDSN. Otherwise, the PDSN SID shall be 45
identical to the PCF SID, thereby maintaining backwards compatibility. The PCF also 46
uses the MN Session Reference ID, that is set to the SR_ID that is passed from the MS on 47
TIA-2001.3-C
161 Section 3
each origination and which, together with the Mobile Station Identifier (MS-ID), can be 1
used to identify a packet data service instance for a specific MS across PCFs and PDSNs. 2
In the A11-Registration Request message, the PCF sets the Home Address field to zeros. 3
The IP source address (IP header) and the Care-of-Address field of the A11-Registration 4
Request message are set to the IP address of the PCF. The IP destination address in the IP 5
header and the Home Agent field in the A11-Registration Request message are set to the 6
address of the PDSN designated for the call. The PCF Session Identifier (PCF_SID), link 7
layer/network layer protocol type identifier, MN Session Reference ID and MS_ID of the 8
MS are set in the Session Specific Extension of the A11-Registration Request message. 9
For procedures for A10 interface Setup, Operation, Release, and Accounting, refer to 10
[17]. 11
3.17.5.1 Mobile Originated Packet Data Service Instance Setup Successful Operation 12
To initiate a packet data service instance, the MS performs registration with the serving 13
wireless network and then with the packet network. There are two cases of a service 14
instance setup. 15
In the first case, the MS has not yet established a packet data session or the packet data 16
session is dormant. The MS sends an Origination Message to the BS that includes the 17
packet data service option. It results in assignment of the traffic channel, and 18
establishment of an A10 connection. For the first packet data service instance that the MS 19
initiates (main service instance), the Origination Message also results in the establishment 20
of the link layer (PPP) and for the case where Mobile IP is used by the terminal, Mobile 21
IP registration with the serving packet network. 22
In the second case, the MS initiates a new service instance, while maintaining an active 23
packet data session. In this case, the MS sends an Enhanced Origination Message to the 24
BS that includes the packet data service option, which results in a reconfiguration of the 25
traffic channel and establishment of an A10 connection. 26
User data traffic can now be passed over the A10 connection encapsulated within GRE 27
frames. The PCF periodically re-registers with the selected PDSN by the use the of A11- 28
Registration Request message before the A10 connection Lifetime expires. 29
30
TIA-2001.3-C
Section 3 162
Dormant or Inactive Successful Operation 2
MS BS/PCF MSC
time comment
Origination
a
b
c
d
e
f
Assignment Request
g
h Assignment Complete
i
k
l
T10
j
T303
PDSN
A11-Registration Request
TCH Setup
A11-Registration Reply
Establish PPP Connection
User Data Transmission
Tregreq
Tregreq
Trp
3
Figure 3.17.5.1.1-1 Mobile Initiated Packet Data Service Instance Setup When the Packet Data 4
Session Is Dormant or Inactive Successful Operation 5
Note: The following descriptions assume that the PCF is capable of determining whether 6
one or more PDSNs are reachable on the A10/A11 network. Based on the algorithm 7
specified in section 3.17.3, the PCF selects a PDSN best suited for handling this call. 8
a. To initiate a packet data service instance the MS sends an Origination Message with 9
Layer 2 Ack required indication over the Access Channel to the BS. The Origination 10
Message includes a packet data service option and an SR_ID, which is used to 11
identify the service instance. 12
Ack Order to the MS. 14
c. The BS constructs a CM Service Request message, places it in the Complete Layer 3 15
303
. 16
d. The MSC sends an Assignment Request message to the BS requesting assignment of 17
10
. No terrestrial circuit between the MSC and the 18
BS is assigned to the packet data call. 19
TIA-2001.3-C
163 Section 3
e. On receipt of the Assignment Request message, the BS stops timer T
303
. The BS and 1
the MS perform radio resources setup procedures if the MS is not already on a traffic 2
channel. 3
f. If the PCF recognizes that there are no A10 connections associated with this MS, the 4
PCF selects a PDSN for the call. If, however, one or more A10 connections already 5
exist for the MS at the PCF, the PCF selects the same PDSN to establish the A10 6
connection for the new service instance. The PCF sends an A11-Registration 7
Request message with non-zero Lifetime value and the ANID of the PCF (sent in the 8
CANID field) to the selected PDSN. This message also includes Accounting Data 9
(R-P Session Setup Airlink Record). The PCF starts timer T
regreq
. 10
g. The A11-Registration Request message is validated and the PDSN accepts the 11
connection by returning an A11-Registration Reply message with an accept 12
indication and the Lifetime set to the configured T
rp
value. Both the PDSN and the 13
PCF create a binding record for the A10 connection. The PCF stops timer T
regreq
. 14
The PCF and PDSN start timer T
rp
. If the A10 connection is the first set up for the 15
MS and the PDSN supports fast handoff, the Anchor P-P Address is sent as part of 16
an NVSE element to the PCF. If the PCF does not support fast handoff, the Anchor 17
P-P Address is discarded. 18
h. After the radio link and A10 connection are set up, the BS sends an Assignment 19
Complete message to the MSC. The MSC stops timer T
10
upon receipt of the 20
Assignment Complete message from the BS. 21
i. If the service instance is the first one initiated by the MS, the MS and the PDSN 22
establish the link layer (PPP) connection and then perform the MIP registration 23
procedures (if required) over the link layer (PPP) connection, thereby creating a 24
mobility binding for the MS. 25
j. The MS begins to send/receive user data via GRE framing over the A10 connection. 26
k. The PCF sends an A11-Registration Request message before expiration of 27
registration Lifetime timer (T
rp
) for refreshing registration for the A10 connection. 28
The A11-Registration Request message may also be used to send accounting related 29
and other information to the PDSN. The accounting related and other information is 30
sent at system defined trigger points. The PCF starts timer T
regreq
. 31
l. For a validated A11-Registration Request message, the PDSN returns an A11- 32
Registration Reply message with an accept indication and a configured Lifetime 33
value. Both the PDSN and the PCF update the A10 connection binding record. The 34
PDSN stores the accounting related and other information (if received) for further 35
processing, before returning the A11-Registration Reply message. The PCF stops 36
timer T
regreq
. The PCF and PDSN start timer T
rp
. 37
TIA-2001.3-C
Section 3 164
Active Successful Operation 2
MS BS/PCF MSC
time comment
a
b
c
d
e
g
h
f
PDSN
Service
negotiation
Tregreq
Tregreq
Trp
3
Figure 3.17.5.1.2-1 Mobile Originated Packet Data Service Instance Setup when the Packet 4
Data Session Is Active Successful Operation 5
Note: The following descriptions assume that one or more A10 connections already exist 6
at the PCF for this MS. 7
a. To initiate a packet data service instance the MS sends an Enhanced Origination 8
Message with Layer 2 Ack required indication over the traffic channel to the BS. The 9
Enhanced Origination Message includes a packet data service option and an SR_ID, 10
which is used to identify the service instance. 11
b. The BS acknowledges the receipt of the Enhanced Origination Message with a Base 12
Station Ack Order to the MS. 13
c. The BS and the MS perform service negotiation. 14
d. The PCF recognizes that one or more A10 connections associated with this MS 15
already exist at the PCF and selects the same PDSN to establish the A10 connection 16
for the new service instance. The PCF sends an A11-Registration Request message 17
with non-zero Lifetime value and the ANID of the PCF (sent in the CANID field) to 18
the selected PDSN. This message also includes Accounting Data (R-P Session Setup 19
Airlink Record). The PCF starts timer T
regreq
. 20
e. The A11-Registration Request message is validated and the PDSN accepts the 21
indication and the Lifetime set to the configured Trp value. Both the PDSN and the 23
PCF create a binding record for the A10 connection. The PCF stops timer T
regreq
. 24
The PCF and PDSN start timer T
rp
. 25
TIA-2001.3-C
165 Section 3
f. The MS can send/receive data via GRE framing over the A10 connection established 1
for the new service instance. 2
g. The PCF sends an A11-Registration Request message before expiration of 3
registration Lifetime timer (T
rp
) for refreshing registration for the A10 connection. 4
The A11-Registration Request message may also be used to send accounting related 5
and other information to the PDSN. The accounting related and other information is 6
sent at system defined trigger points. The PCF starts timer T
regreq
. 7
h. For a validated A11-Registration Request message, the PDSN returns an A11- 8
Registration Reply message with an accept indication and a configured Lifetime 9
value. Both the PDSN and the PCF update the A10 connection binding record. The 10
PDSN stores the accounting related and other information (if received) for further 11
processing, before returning the A11-Registration Reply message. The PCF stops 12
timer T
regreq
. The PCF and PDSN start timer T
rp
. 13
3.17.5.2 Mobile Originated Packet Data Service Instance Setup Failure Operation 14
wireless network and then with the packet network. The MS sends an Origination 16
Message or an Enhanced Origination Message to the BS that includes the packet data 17
service option. It results in assignment or reconfiguration of the traffic channel. The PCF 18
initiates establishment of the A10 connection with the PDSN by sending an A11- 19
Registration Request message to the PDSN. If the connection setup request is not 20
acceptable, the PDSN returns an A11-Registration Reply message with a reject code. 21
Based on the reject code, the PCF may attempt to establish the A10 connection again. If 22
the A10 connection is not able to be established, the PCF indicates this to the BS. If the 23
MS has no other active service instance, the BS returns a failure indication to the MSC, 24
which, in-turn, releases the call. Otherwise, if the MS has other active service instances, 25
the BS initiates service negotiation back to the previous configuration. 26
The following call flow shows the case where the MS does not have any other active 27
service instances prior to attempting to initiate a new service instance. The case where the 28
MS does have other active service instances is analogous with the following 29
modifications: 30
1. The MS sends an Enhanced Origination Message instead of an Origination Message. 31
2. The BS and MSC exchange no messages. 32
3. The traffic channel is reconfigured rather than set up and released. 33
TIA-2001.3-C
Section 3 166
MS BS/PCF MSC
time comment
Origination Message
a
b
c
d
e
f
Assignment Request
g
h
Assignment Failure
i
k
T10
j
T303
PDSN
Clear Complete
TCH Setup
Clear Command
Release Order
Tregreq
T315
Release Order
l
1
Figure 3.17.5.2-1 Mobile Originated Packet Data Service Instance Setup When the Packet Data 2
Session is Dormant or Inactive Failure Operation 3
Note: The following descriptions assume that the PCF is capable of determining 4
reachability to one or more PDSNs on the A10/A11 network. Based on the algorithm 5
a. To initiate a packet data service, the MS sends an Origination Message with Layer 2 7
Ack required indication over the Access Channel to the BS. The Origination 8
Message includes a packet data service option. 9
303
. 13
10
303
. The BS and 17
the MS perform radio resources setup procedures if the MS is not already on a traffic 18
channel. 19
f. If the PCF recognizes that there are no A10 connections associated with this MS, the 20
PCF selects a PDSN for the call. If, however, one or more A10 connections already 21
exist for the MS at the PCF, the PCF selects the same PDSN to establish the A10 22
connection for the new service instance. The PCF sends an A11-Registration 23
Request message with non-zero Lifetime value to the selected PDSN. This message 24
also includes Accounting Data (R-P Session Setup Airlink Record). The PCF starts 25
timer T
regreq
. 26
TIA-2001.3-C
167 Section 3
g. The PDSN does not accept the A11-Registration Request message and fails A10 1
connection setup by returning an A11-Registration Reply message with a reject code. 2
The PCF stops timer T
regreq
. 3
h. Based on the reject code, the PCF may attempt to establish the A10 connection 4
again. If the A10 connection can not be established, the BS returns an Assignment 5
Failure with cause PCF (or PDSN) resource unavailable or Equipment failure to 6
the MSC. Upon receipt of this message, the MSC stops timer T
10
. 7
i. The MSC sends a Clear Command message to the BS, instructing the BS to release 8
the associated resources, including the radio resources. The MSC starts timer T
315
. 9
j. The BS sends a Release Order to the MS instructing the MS to release the radio 10
resources. 11
k. The MS sends a Release Order to the BS. 12
l. The BS returns a Clear Complete message to the MSC. Upon receipt of this message, 13
the MSC stops timer T
315
. 14
Note: If the BS has already returned an Assignment Complete message to the MSC prior 15
to receiving an A11-Registration Reply message with a reject code from the PDSN, the 16
BS initiates release of the call by sending a Clear Request with cause (PDSN resource 17
unavailable or Equipment failure) to the MSC in place of the Assignment failure in step 18
h. 19
3.17.5.3 Mobile Originated Packet Call Setup With Registration to Alternate PDSN 20
wireless network and then with the packet network. The MS sends an Origination 22
Message to the BS that includes the packet data service option, which results in 23
assignment of the traffic channel. The PCF initiates establishment of the A10 connection 24
with the selected PDSN by sending an A11-Registration Request message. If the PDSN 25
does not accept the connection and wants to propose another PDSN, it returns an A11- 26
Registration Reply message with code 88H (Registration Denied unknown PDSN 27
address). The address of the alternate PDSN is also returned in the Home Agent field of 28
the A11-Registration Reply message. The PCF may accept the alternate PDSN by 29
sending another A11-Registration Request message, or may use the algorithm specified 30
in section 3.17.3 to select a new PDSN. The PCF initiates establishment of the A10 31
connection with the selected PDSN by sending an A11-Registration Request message. 32
Note that this scenario is relevant only for the case where the MS attempts to set up the 33
first (main) service instance, since all service instances shall be served by the same 34
PDSN. 35
TIA-2001.3-C
Section 3 168
MS BS/PCF MSC
time comment
Origination Message
a
b
c
d
e
f
Assignment Request
g
h
Assignment Complete
i
k
l
T10
j
T303
PDSN-1
TCH Setup
Tregreq
Tregreq
PDSN-2
1
Figure 3.17.5.3-1 Mobile Originated Packet Service Instance Setup With Registration to Alternate 2
PDSN 3
Note: The following descriptions assume that the PCF is capable of determining 4
reachability to one or more PDSNs on the A10/A11 network. Based on the algorithm 5
a. To initiate a packet data service instance, the MS sends an Origination Message with 7
Layer 2 Ack required indication over the Access Channel to the BS. The Origination 8
Message includes a packet data service option. 9
303
. 13
10
TIA-2001.3-C
169 Section 3
303
. The BS and 1
the MS perform radio resources setup procedures if the traffic channel has not 2
already been set up. 3
f. The PCF recognizes that no A10 connection associated with this MS is available and 4
selects a PDSN (PDSN-1) for this call. The PCF sends an A11-Registration Request 5
message with non-zero Lifetime value to the selected PDSN-1. This message also 6
includes Accounting Data (R-P Session Setup Airlink Record). The PCF starts timer 7
T
regreq
. 8
g. The A11-Registration Request message is validated. PDSN-1 rejects the connection 9
and proposes another PDSN (PDSN-2). PDSN-1 returns an A11-Registration Reply 10
message with a reject code of 88H (Registration Denied unknown PDSN address) 11
and the address of the alternate PDSN (PDSN-2) in the Home Agent address field of 12
the A11-Registration Reply message. The PCF stops timer T
regreq
. 13
h. The PCF initiates establishment of the A10 connection with PDSN-2 by sending an 14
A11-Registration Request message with non-zero Lifetime value. The PCF starts 15
timer T
regreq
. 16
i. The A11-Registration Request message is validated and PDSN-2 accepts the 17
indication and the Lifetime set to the configured Trp value. Both PDSN-2 and the 19
PCF create a binding record for the A10 connection. If PSDN-2 supports fast 20
handoff , the Anchor P-P address is sent as a part of the NVSE element to the PCF. If 21
the PCF does not support fast handoff , the Anchor P-P address is discarded. The 22
PCF stops timer T
regreq
. 23
j. After the radio link and the A10 connection have been established, the BS sends an 24
Assignment Complete message to the MSC. The MSC stops timer T
10
. This step 25
may occur any time after radio link establishment. 26
k. The MS and PDSN-2 establish the link layer (PPP) connection and then perform the 27
MIP registration procedures (if required) over the link layer (PPP) connection, 28
thereby creating a mobility binding for the MS. 29
l. The MS begins to send/receive user data via GRE framing over the A10 connection. 30
Note: The PCF continues to perform re-registration of the A10 connection with PDSN-2 31
by the exchange of A11-Registration Request messages and A11-Registration Reply 32
messages before expiration of Lifetime time Trp. 33
3.17.5.4 Packet Data Service Instance Clearing PDSN Initiated 34
User data traffic is passed over an A10 connection encapsulated within GRE frames. An 35
event occurs at the PDSN that requires release of the associated PDSI. The PDSN 36
initiates release of the A10 connection with the PCF. If the MS is on a traffic channel, 37
other resources assigned to the call may also be released. Refer to section 3.17.4.5 for the 38
various cases of PDSN initiated packet data service instance release. The A10 connection 39
release procedure referenced by a fat arrow in the call flows in that section is 40
comprised of steps b through e in the following call flow. 41
TIA-2001.3-C
Section 3 170
T
300
MS BS/PCF MSC
time
comment
b
d
e
c
PDSN
f
i
g
h
Clear Command
T
315

Clear Request
A11-Registration Update
A11-Registration Acknowledgement
Clear Complete
T
regreq
T
regupd

Service
Negotiation or
TCH Release
Packet Data Session Active, Dormant, or Null
a
j
1
Figure 3.17.5.4-1 Packet Data Service Instance Clearing PDSN Initiated 2
a. The MS has a packet data session in the Active State. 3
b. An event occurs at the PDSN that requires release of an active PDSI. The PDSN 4
initiates release of the associated A10 connection by sending an A11-Registration 5
Update message to the PCF. The PDSN starts timer T
regupd
. 6
c. The PCF responds with an A11-Registration Acknowledge message. Steps d 7
through e may occur in parallel with steps f through h. The PDSN stops timer 8
T
regupd
. 9
d. The PCF sends an A11-Registration Request message with Lifetime set to zero for 10
the PDSI being released, and accounting related information. The PCF starts timer 11
T
regreq
. 12
e. The PDSN stores the accounting related information for further processing before 13
returning an A11-Registration Reply message with an accept indication, and releases 14
the A10 connection for the MS. The PCF also releases the A10 connection. The PCF 15
stops timer T
regreq
. If the MS has other active PDSIs, steps f, g, and i are 16
omitted. 17
f. The BS sends a Clear Request message to the MSC to initiate clearing of the radio 18
and other resources assigned to the call and starts timer T
300
. 19
g. The MSC sends a Clear Command message to the BS, instructing the BS to release 20
the associated resources (including the radio resources), and starts timer T
315
. The 21
BS stops timer T
300
upon receiving the Clear Command message. 22
TIA-2001.3-C
171 Section 3
h. If the MS has no other active PDSI, the BS sends a Release Order to the MS 1
instructing the MS to release the PDSI. The BS releases the radio resources and 2
releases the PDSI for the MS. The MS acknowledges the Release Order by returning 3
a Release Order to the BS and releases the PDSI. If the MS has other active PDSIs, 4
the BS initiates service negotiation to dissociate the PDSI from the traffic channel. 5
i. The BS returns a Clear Complete message to the MSC. The MSC stops timer T
315
. 6
j. The packet data session remains in the Active State or transitions to the Dormant 7
State or Null/Inactive State depending on whether the MS has remaining active or 8
dormant PDSIs. 9
3.17.5.5 Packet Data Session Clearing MSC Initiated 10
User data traffic is being passed over one or more A10 connections encapsulated within 11
GRE frames. An event occurs at the MSC that requires release of the packet data session 12
and release of radio and other resources for the call. The MSC initiates release of the A10 13
connection with the PDSN. Traffic channel and other resources assigned to the call are 14
also released. 15
MS
PDSN
time comment
b
c
d
e
Clear Command
T315
BS/PCF
MSC
User Data Session
a
TCH Release
Tregreq
Clear Complete
16
Figure 3.17.5.5-1 Packet Data Session Clearing MSC Initiated 17
a. An event occurs at the MSC that requires release of the packet data session. The 18
MSC sends a Clear Command message to the BS, instructing the BS to release the 19
session and associated resources, including the radio resources. Steps c and d may 20
occur in parallel with step b. 21
b. The BS and the MS release the traffic channel and other radio resources. 22
c. For each service instance (both active and dormant), the PCF sends an A11- 23
Registration Request message to the PDSN with a Lifetime timer value of zero to 24
release the A10 associated connection. Accounting data is also included in the A11- 25
Registration Request message. The PCF starts a timer T
regreq
associated with each 26
A11-Registration Request message sent. 27
d. The PDSN stores the accounting data for further processing and sends an A11- 28
Registration Reply message with an accept indication for each A11-Registration 29
Request message to complete the release of each A10 connection. The PCF stops the 30
associated timer T
regreq
. 31
TIA-2001.3-C
Section 3 172
e. The BS sends a Clear Complete message to the MSC. The MSC stops timer T
315
. 1
3.17.5.6 Packet Data Service Session Clearing MS Initiated 2
The example below shows the clearing of an active packet data session as a result of a 3
power down operation by the MS. 4

Clear Command
Release Order
(Power Down Indication)
MS
PDSN
time comment
a
b
c
d
Clear Request
T300
T315
e
BS/PCF
MSC
f
g
TCH Release
Tregreq
Clear Complete
5
Figure 3.17.5.6-1 Packet Data Service Session Clearing MS Initiated 6
a. The MS powers down resulting in termination of the packet data session. The MS 7
sends a Release Order to the BS with a power down indication. 8
b. The BS sends a Clear Request message to the MSC. The BS starts timer T
300
. 9
c. The MSC responds with a Clear Command message. The BS stops timer T
300
. The 10
MSC starts timer T
315
. 11
d. The BS responds to the MS with a Release Order and the traffic channel and other 12
radio resources are released. Step d may occur in parallel with steps e and f. 13
e. The PCF sends one or more A11-Registration Request messages to the PDSN with a 14
Lifetime timer value of zero to release each A10 connection (both active and 15
dormant). Accounting data is included in the message. The PCF starts a timer T
regreq
16
associated with each message. 17
f. The PDSN stores the accounting data for further processing and responds with A11- 18
Registration Reply message(s) with an accept indication for each A11-Registration 19
Request message received to complete the release of the A10 connection(s). The 20
PCF stops the associated timer T
regreq
. 21
g. The BS sends a Clear Complete message to the MSC and includes the Power Down 22
Indicator. The MSC stops timer T
315
. 23
3.17.5.7 Packet Data Service Instance Clearing PDSN Initiated (Crossing A11- 24
Registration Request and A11-Registration Update) 25
User data traffic is passed over an A10 connections, encapsulated within GRE frames. An 26
event occurs at the PDSN that requires release of the associated PDSI. The PDSN 27
initiates release of the A10 connection with the PCF. At the same time, PCF sends an 28
TIA-2001.3-C
173 Section 3
A11-Registration Request message to the PDSN to perform periodic re-registration of the 1
A10 connection. In this scenario, release of the A10 connection initiated by the PDSN 2
takes precedence. The traffic channel (if the PDSI being release is the only one) and/or 3
other resources assigned to the call are also released. Refer to section 3.17.4.5 for the 4
various cases of PDSN initiated packet data service instance release. The A10 connection 5
release procedure referenced by a fat arrow in the call flows in that section is 6
comprised of steps a through f in the following call flow. 7
T
regupd
T
300
MS BS/PCF MSC
time
comment
b
f
g
d
PDSN
h
k
i
j
Clear Command
T
315

Clear Request
A11-Registration Acknowledgement
Clear Complete
T
regreq
Service
Negotiation or
TCH Release
Packet Data Session Active, Dormant, or Null
a
l
T
regreq
c
e
8
Figure 3.17.5.7-1 Packet Data Service Instance Clearing PDSN Initiated (Crossing A11-Registration 9
Request and A11-Registration Update) 10
a. The MS has a packet data session in the Active State. 11
b. The PCF sends an A11-Registration Request message with a non-zero Lifetime value 12
to refresh an A10 connection before expiration of that connections registration 13
Lifetime timer (T
rp
). The PCF starts a timer T
regreq
associated with the A10 14
connection. Accounting related and other information may also be included in the 15
A11-Registration Request message. 16
c. An event occurs at the PDSN that requires release of an active PDSI. The PDSN 17
initiates release of the associated A10 connection by sending an A11-Registration 18
TIA-2001.3-C
Section 3 174
Update message to the PCF, and starts timer T
regupd
. This occurs before the PDSN 1
receives the A11-Registration Request message sent by the PCF in step b. 2
d. On receipt of A11-Registration Request message for the service instance being 3
released while timer T
regupd
is running, the PDSN returns an A11-Registration Reply 4
message with lifetime set to zero. However, the PDSN stores the accounting related 5
and other information (if received) for further processing before returning the A11- 6
Registration Reply message. Upon receiving the A11-Registration Reply message, 7
the PCF stops timer T
regreq
for the service instance being released. 8
e. On receipt of the A11-Registration Update message, irrespective of timer T
regreq
9
condition, the PCF responds with an A11-Registration Acknowledge message. Steps 10
e through f may occur in parallel with steps g through i. The PDSN stops 11
timer T
regupd
. 12
f. The PCF sends an A11-Registration Request message with Lifetime set to zero for 13
the PDSI being released and accounting related information to the PDSN. The PCF 14
starts timer T
regreq
. 15
g. The PDSN stores the accounting related information for further processing before 16
returning an A11-Registration Reply message with an accept indication and releases 17
the A10 connection. The PCF also releases the A10 connection. The PCF stops timer 18
T
regreq
. If the MS has other active PDSIs, steps h, i, and k are omitted. 19
h. The BS sends a Clear Request message to the MSC to initiate clearing of the radio 20
and other resources assigned to the call. The BS starts timer T
300
. 21
i. The MSC sends a Clear Command message to the BS, instructing the BS to release 22
the associated resources (including the radio resources). The MSC starts timer T
315
. 23
Upon receiving the Clear Command message, the BS stops timer T
300
. 24
j. If the MS has no other active PDSI, the BS and the MS release the traffic channel 25
and other resources. If the MS has other active PDSIs, the BS initiates service 26
negotiation to dissociate the PDSI from the traffic channel. 27
k. The BS returns a Clear Complete message to the MSC. The MSC stops timer T
315
. 28
l. The packet data session remains in the Active State or transitions to the Dormant 29
State or Null/Inactive State depending on whether the MS has remaining active or 30
dormant PDSIs. 31
3.17.5.8 Inter-PCF Dormant Handoff Mobile Continues to be Served by the Same PDSN 32
To obtain packet data services, the MS performs registration(s) with the packet network 33
resulting in the establishment of one or more service instances. The packet data session 34
transitioned to Dormant State. While in the Dormant State the A10 connection for each 35
service instance and the link layer (PPP) connection of the MS are maintained. The 36
source PCF continues to perform re-registrations for the A10 connection with the PDSN 37
by the exchange of A11-Registration Request messages and A11-Registration Reply 38
messages before expiration of A10 connection Lifetime timer T
rp.
39
While in the dormant mode, the MS detects a change of PZID, SID or NID. On detection 40
of a new PZID, SID or NID, and the MS determining that the network needs to be 41
notified, the MS sends an Origination Message (or an Enhanced Origination Message) to 42
the target BS that includes the packet data service option and the DRS bit set to 0. The 43
MS sends an origination message with DRS bit set to 0 for each of its dormant packet 44
data service instances. The origination messages include the previous PZID, SID and 45
TIA-2001.3-C
175 Section 3
NID when any of these parameters change during the dormant handoff. The target PCF 1
establishes an A10 connection with the PDSN for each service instance. Based on the 2
ANID information (PZID, NID and/or SID) received in the origination message, the 3
target PCF sets the PANID field to the ANID received from the BS and the CANID field 4
to the ANID of the target PCF, and sends this information to the serving PDSN. If the 5
previous PZID, NID, and/or SID were not received from the MS, the PANID field is set 6
to zero. Upon determining that it supports a packet data session for the MS, the serving 7
PDSN compares the received PANID (if non-zero) to the stored CANID and determines 8
that PPP re-negotiation is not required. If the PDSN has data to send to the MS over a 9
particular service instance, the PDSN returns the Data Available Indicator in the CVSE 10
within the A11-Registration Reply message to the BS/PCF for that service instance, 11
resulting in establishment or reconfiguration of the traffic channel. The PDSN releases 12
the A10 connection with the source PCF for each service instance established with the 13
target PCF. 14
After each A10 establishment the target PCF periodically re-registers with the PDSN by 15
the use of an A11-Registration Request message before that A10 connection Lifetime 16
expires. Refer to section 3.17.4.9 for the different cases of intra-PDSN dormant handoffs. 17
handoff of each of its packet data service instances. The packet data session may become 19
active as the result of the dormant handoff of one packet data service instance (e.g., the 20
PDSN may have data to send for a packet data service instance), in which case the 21
dormant handoff of the remaining packet data service instances occur as given in section 22
3.17.4.9.2. 23
The following call flow shows the case where the MS sends an Origination Message with 24
the DRS bit set to 0 to handoff a service instance. Since the PDSN already has a PPP 25
session for this MS, PPP negotiation is not required and the traffic channel is not needed 26
in this scenario. 27
TIA-2001.3-C
Section 3 176

Source
BS/PCF
MSC
time comment
Origination Message
b
c
f
g
k
l
m
o
n
PDSN
Target
BS/PCF
T
regreq
T
regreq
T
regupd
MS
Release Order
T
303
d
e Assignment Request
CMService Request
Clear Command
Assignment Failure
T
20
A11-Registration Acknowledge
Clear Complete
T
10

T
315
h
i
j
Packet Data Session Dormant, PPP session is maintained a
Packet Data Session Dormant, PPP session is maintained p
1
Figure 3.17.5.8-1 Inter-PCF Dormant Handoff of a PDSI While Packet Data Session is Dormant 2
Mobile Continues to be Served by the Same PDSN 3
established a PPP connection with the PDSN but the packet data session is now 5
b. On detection of a new PZID, SID or NID, the MS sends an Origination Message 7
with DRS set to 0 to the target BS. 8
c. The target BS acknowledges the receipt of the Origination Message with a BS Ack 9
Order to the MS. 10
TIA-2001.3-C
177 Section 3
303
. 2
10
. For packet data services, a 4
303
. 6
f. The target PCF sends an A11-Registration Request message to the PDSN. This 7
message includes the Mobility Event Indicator within the CVSE and a non-zero 8
Lifetime. This message also includes Accounting Data (R-P Session Setup Airlink 9
Record) as well as ANID information (CANID/PANID). The PCF starts timer 10
T
regreq
. 11
indication. If the PDSN supports fast handoff the Anchor P-P Address is included. If 14
the target PCF does not support fast handoff it ignores the Anchor P-P Address. If 15
the PDSN has data to send, it includes the Data Available Indicator within the 16
CVSE. The A10 connection binding information at the PDSN is updated to point to 17
the target PCF. The target PCF stops timer T
regreq
. 18
If the PDSN responds to the target PCF with the Data Available Indicator, the target 19
BS establishes traffic channels. In this case the remaining steps in this call flow are 20
omitted. 21
h. The target BS sends the Assignment Failure message to the MSC with the cause 22
value indicating Packet Call Going Dormant and starts timer T
20
. The MSC stops 23
timer T
10
. 24
i. After the MSC has successfully authenticated the MS, it sends a Clear Command 25
message to the target BS with the cause value Do not notify mobile and starts timer 26
T
315
. Upon receipt of the Clear Command the target BS stops timer T
20
. 27
j. The target BS may send a Release Order to the MS. This allows the MS to send 28
Origination Messages for remaining packet data service instances sooner. 29
k. The target BS sends a Clear Complete message to the MSC. The MSC stops timer 30
T
315
. 31
l. The PDSN initiates release of the A10 connection with the source PCF by sending an 32
A11-Registration Update message. The PDSN starts timer T
regupd
. 33
m. The source PCF responds with an A11-Registration Acknowledge message. The 34
PDSN stops timer T
regupd
. 35
n. The source PCF sends an A11-Registration Request message with Lifetime set to 36
zero to the PDSN. The source PCF starts timer T
regreq
. 37
o. The PDSN sends the A11-Registration Reply message with an accept indication to 38
the source PCF. The source PCF releases the A10 connection for the MS. The source 39
PCF stops timer T
regreq
. 40
If the MS sends an Origination Message with DRS = 0 for additional dormant 41
service instances (this may occur any time after step j or when timer T
42m
expires 42
for last dormant service instance handed off), this procedure is repeated for each 43
such service instance. 44
p. The packet data session remains dormant. 45
TIA-2001.3-C
Section 3 178
3.17.5.9 Inter-PCF Dormant Handoff Mobile Served by a Different PDSN 1
To obtain packet data services, the MS performs registration(s) with the packet network 2
resulting in the establishment of one or more service instances. The packet data session 3
transitioned to dormant mode. While in the Dormant State, the A10 connection of each 4
service instance and the link layer (PPP) connection of the MS are maintained. The 5
source PCF continues to perform re-registrations for the A10 connection with the source 6
PDSN by the exchange of A11-Registration Request messages and A11-Registration 7
Reply messages before expiration of the A10 connection Lifetime timer T
rp.
8
While the packet data session is in dormant mode, the MS detects a change of PZID, SID 9
or NID. On detection of a new PZID, SID, or NID, the MS sends an Origination Message 10
to the target BS that includes the packet data service option and the DRS bit set to 0. 11
The MS sends an Origination or Enhanced Origination Message with DRS bit set to 0 12
for each of its dormant packet data service instances. The target PCF establishes an A10 13
connection with the target PDSN for each such service instance. The target PCF is 14
required to forward the PANID of the source PCF (if received from the MS) and the 15
CANID of the target PCF to the serving PDSN. 16
The BS normally does not establish a traffic channel when it receives an Origination 17
Message with DRS bit set to 0. However, in this case, a traffic channel is established if 18
the BS/PCF receives an A11-Registration Reply message from the PDSN for a service 19
instance containing the Data Available Indicator. Link layer (PPP) re-establishment 20
between the MS and the target PDSN and Mobile IP re-registration (if required) between 21
the MS and the packet network are then performed over the main service instance. The 22
target PCF establishes an A10 connection with the target PDSN for each dormant service 23
instance for which the MS sends Origination or Enhanced Origination with DRS bit set to 24
0. If user data is available, it is exchanged between the MS and the corresponding node 25
over the new A10 connection(s), encapsulated within GRE frames. The source PDSN 26
releases the A10 connection(s) with the source PCF on expiration of the MIP registration 27
timer. The target PCF periodically re-registers with the PDSN by the use of the A11- 28
Registration Request message before the A10 connection Lifetime expires. Refer to 29
section 3.17.4.10 for the A8/A9 procedures for inter-PDSN dormant handoffs. 30
handoff of each of its packet data service instances. The packet data session may become 32
active as the result of the dormant handoff of one packet data service instance (i.e., the 33
PDSN has data to send to the MS over that packet data service instance), in which case 34
the dormant handoff of the remaining packet data service instances occur as given in 35
section 3.17.4.9.2. 36
The following call flow shows the case where the MS sends an Origination Message with 37
the DRS bit set to 0 to handoff a service instance. Refer to section 3.17.4.9.2 for 38
handoff of service instance using Enhanced Origination Message. 39
TIA-2001.3-C
179 Section 3

Source
BS/PCF
MSC
time comment
Origination Message
b
c
f
g
n
o
p
m
q
Target
BS/PCF
T
regreq
T
regreq
T
regupd
MS
T
303
d
e Assignment Request
CMService Request
Assignment Complete
T
10

h
i
l
Packet Data Session Dormant, PPP session is maintained a
Packet Data Session Active, New PPP Session Established
Source
PDSN
Target
PDSN
TCH Setup
MIP Registration
j
k
T
regreq
1
Figure 3.17.5.9-1 Inter-PCF Dormant Handoff of a Service Instance Mobile Served by a Different 2
PDSN 3
established a PPP connection with the PDSN but the packet data session is now 5
b. On detection of a new PZID, SID or NID, the MS sends an Origination Message 7
with DRS set to 0 to the target BS. 8
TIA-2001.3-C
Section 3 180
c. The target BS acknowledges the receipt of the Origination Message with a BS Ack 1
Order to the MS. 2
303
. 4
10
. For packet data services a 6
303
. 8
f. The target PCF initiates establishment of the A10 connection by sending an A11- 9
Registration Request message with non-zero Lifetime value to the target PDSN. The 10
message includes the Mobility Event Indicator within a CVSE and a non-zero 11
Record) as well as ANID information (CANID/PANID). The target PCF starts timer 13
T
regreq
. 14
g. The A11-Registration Request message is validated and the target PDSN accepts the 15
indication and Data Available Indicator within a CVSE. If the PDSN supports fast 17
handoff the Anchor P-P Address is included. If the target PCF does not support fast 18
handoff it ignores the Anchor P-P Address. The target PCF stops timer T
regreq
. 19
h. The target BS initiates setup of the traffic channel with the MS. 20
i. The target BS sends the Assignment Complete message to the MSC. The MSC stops 21
timer T
10
. 22
j. The target PCF sends an A11-Registration Request message to the target PDSN 23
containing an Airlink Start accounting record. The target PCF starts timer T
regreq
. 24
k. The target PDSN updates the accounting data and returns an A11-Registration Reply 25
message with an accept indication back to the target PCF. The target PCF stops timer 26
T
regreq
. 27
l. The MS and the target PDSN establish the link layer (PPP) connection and then 28
perform the MIP registration procedures (if required) over the link layer (PPP) 29
connection, thereby creating a mobility binding for the MS. 30
m. The packet data session is active and a new PPP session has been established. 31
n. On expiration of the PPP timer or other events internal to the source PDSN, the 32
source PDSN initiates release of the A10 connection with the source PCF by sending 33
an A11- Registration Update message. The source PDSN starts timer T
regupd
. 34
o. The source PCF responds with an A11-Registration Acknowledge message. The 35
source PDSN stops timer T
regupd
. 36
p. The source PCF sends an A11-Registration Request message with Lifetime set to 37
zero. The source PCF starts timer T
regreq
. 38
q. The source PDSN stores the accounting related information for further processing 39
before returning an A11-Registration Reply message with an accept indication. The 40
source PCF releases the A10 connection. The source PCF stops timer T
regreq
. 41
3.17.5.10 Inter-PCF Hard Handoff Mobile Continues to be Served by the Same PDSN 42
To obtain packet data services, the MS performs registration with the packet network. 43
The traffic channel is assigned and an A10 connection for each service instance of the 44
TIA-2001.3-C
181 Section 3
MS is established between the source PCF and the PDSN. This results in establishment 1
of the link layer (PPP) connection and Mobile IP registration (if required) with the 2
serving packet network. The source PCF continues to perform re-registrations for each 3
A10 connection with the PDSN by the exchange of A11-Registration Request messages 4
and A11-Registration Reply messages before expiration of A10 connection Lifetime 5
timer T
rp.
6
The MS moves into the coverage area of a target BS resulting in a hard handoff. After 7
exchange of appropriate messages between the MSC, the source BS and the target BS, 8
the MS is acquired by the target BS. The target PCF establishes an A10 connection with 9
the PDSN for each service instance (both active and dormant) handed off. User data is 10
exchanged between the MS and the corresponding node over the new A10 connection(s), 11
encapsulated within GRE frames. The PDSN releases the A10 connection(s) with the 12
source PCF associated with each service instance handed off to target PCF. The target 13
PCF periodically re-registers with the PDSN by the use of the A11-Registration Request 14
message before the A10 connection Lifetime expires. Note this scenario does not cover 15
fast handoff; refer to section 3.19.4 for call flows related to fast handoff. 16
TIA-2001.3-C
Section 3 182
x
Extended/General Handoff Direction
MS
Source
BS/PCF
time
comment
Handoff Required
Handoff Request
a
b
c
d
e
f
Null forward traffic channels Frames
Handoff Request Ack
g
h
Handoff Complete
i
k
m
j
PDSN
A11-Registration
R t
n
o
q
s
p
t
u
r
Handoff Command
T7
MS Ack Order
Twaitho
Handoff Commenced
l
Reverse Traffic Channel Preamble or Data
Handoff Completion
BS Ack
Clear Complete
Clear Command
T315
T306
MSC
Tregreq
Tregupd
T
regreq
Target
BS/PCF
T11
T9
T8
1
Figure 3.17.5.10-1 Inter-PCF Hard Handoff Mobile Continues to be Served by the Serving 2
PDSN 3
a. On detection of a condition that a hard handoff is required, the source BS sends a 4
Handoff Required message to the MSC with a preferred list of target cells, and starts 5
timer T
7
. The source BS includes the ANID of the source PCF. The Service 6
TIA-2001.3-C
183 Section 3
service instances of the MS (active and dormant). 2
b. The MSC sends a Handoff Request message to the target BS which includes the 3
ANID of the source PCF. The Service Configuration Record in this message 4
identifies the active packet data service instances. The Service Option List 5
information element identifies all packet data service instances (active and dormant). 6
The target BS determines which packet data service instances are dormant by 7
comparing this list with the list of active service instances in the Service 8
Configuration Record. The MSC starts timer T
11
. 9
c. Upon receipt of the Handoff Request message, the target BS allocates suitable idle 10
(radio) resources. The target BS starts transmitting null TCH data on the forward 11
traffic channel for the MS. 12
d. The target BS returns a Handoff Request Ack message to the MSC with appropriate 13
RF channel information to allow the MS to be instructed to tune to the new RF 14
channel, and starts timer T
9
to wait for the MS to arrive on the radio channel. Upon 15
receipt of the Handoff Request Ack message from target BS the MSC stops timer 16
T
11
. 17
e. The MSC prepares to switch the MS from the source BS to the target BS. The MSC 18
sends a Handoff Command message to the source BS containing appropriate RF 19
channel information received from the target BS. The source BS stops timer T
7
upon 20
receipt of this message. 21
f. The source BS instructs the MS to handoff by sending the handoff direction message 22
(HDM, GHDM, EHDM, UHDM) and starting timer T
8
. If the MS is allowed to 23
return to the source BS, then timer T
waitho
g. The MS acknowledges receipt of the handoff direction message by sending an MS 25
Ack Order message to source BS. The source BS stops timer T
8
upon receipt of this 26
message. 27
h. Upon receipt of confirmation from the MS, the source BS sends a Handoff 28
Commenced message to the MSC. The source BS starts timer T
306
to await the Clear 29
Command message from the MSC. If timer T
waitho
has been started, the source BS 30
shall wait for that timer to expire before sending the Handoff Commenced message. 31
i. The MS starts sending reverse TCH frames or preamble data to the target BS. 32
j. Upon synchronization of the traffic channel, the MS sends a Handoff Completion 33
Message to the target BS. The target BS detects that the MS has successfully 34
accessed the target BS and stops timer T
9
. 35
k. The target BS acknowledges receipt of the Handoff Completion Message by sending 36
a BS Ack Order to the MS. 37
l. The target PCF sends an A11-Registration Request message with a non-zero 38
Lifetime value and with a Mobility Event Indicator within the CVSE to the PDSN 39
for each active and dormant service instance of the MS. Each message includes 40
Accounting Data (R-P Session Setup Airlink Record) within a CVSE. It also 41
includes the ANID of the source PCF (in the PANID field) in the Handoff Request 42
message and the ANID of the target PCF (in the CANID field) in an ANID NVSE. 43
The PCF starts timer T
regreq
. 44
m. The A11-Registration Request message is validated and the PDSN accepts the 45
indication. If the PDSN has data for the MS, it responds to the PCF with an A11- 47
TIA-2001.3-C
Section 3 184
Registration Reply message with the Data Available Indicator in the CVSE. The A10 1
connection binding information at the PDSN for each service instance is updated to 2
point to target PCF. The target PCF stops timer T
regreq
. If the PDSN indicates that it 3
has data available for the MS on a service instance that is dormant, the BS initiates 4
service negotiation with the MS to reconnect the dormant service instance. 5
Steps l through m are repeated for each active and dormant packet data service 6
instance. 7
n. The target BS then sends a Handoff Complete message to the MSC indicating 8
successful completion of hard handoff. 9
o. User data is exchanged between the MS and the corresponding node over the A10 10
connection of each service instance. 11
p. Upon receipt of the Handoff Complete message, the MSC initiates release of the 12
MSC resources used in the handoff. The MSC then sends a Clear Command message 13
to the source BS, informing it of the success of the hard handoff and starts timer 14
T
315
. The source BS stops timer T
306
. 15
q. The source BS sends a Clear Complete message to the MSC acknowledging success 16
of the handoff. MSC stops timer T
315
on receipt of the Clear Complete message. 17
r. The PDSN initiates release of all A10 connections associated with the MS at the 18
source PCF by sending an A11-Registration Update message for each A10 19
connection. The PDSN starts an associated timer T
regupd
for each message. The 20
PDSN starts timer T
regupd
. 21
Note: The source BS/PCF may initiate tear down of the A10 connections after 22
receiving the Clear Command (in step p). 23
s. The source PCF responds with an A11-Registration Acknowledge message for each 24
A11-Registration Update message received. The PDSN stops the associated timer 25
T
regupd
. 26
t. The source PCF sends an A11-Registration Request message with Lifetime set to 27
zero, and accounting related information to the PDSN for each A10 connection to be 28
cleared. The source PCF starts an associated timer T
regreq
for each message. 29
u. The PDSN stores the accounting related information for further processing before 30
returning an A11-Registration Reply message with an accept indication. The source 31
PCF releases the A10 connection(s) for the MS. The source PCF stops the associated 32
timer T
regreq.
33
3.17.5.11 Inter-BS Hard Handoff Mobile Served by a New Target PDSN 34
To obtain packet data services, the MS performs registration with the packet network. 35
The traffic channel is assigned and an A10 connection for each service instance of the 36
MS is established between the source PCF and the source PDSN on behalf of the MS. 37
This results in establishment of the link layer (PPP) connection and Mobile IP 38
registration (if required) with the serving packet network. The source PCF continues to 39
perform re-registrations for each A10 connection with the source PDSN by the exchange 40
of A11-Registration Request messages and A11-Registration Reply messages before 41
expiration of A10 connection Lifetime timer T
rp.
42
The MS moves into the coverage area of a target BS resulting in a hard handoff. After 43
exchange of appropriate messages between the MSC and the source BS, the MS is 44
acquired by the target BS. The target PCF establishes an A10 connection with the target 45
TIA-2001.3-C
185 Section 3
PDSN for each service instance (both active and dormant) handed off. Link layer (PPP) 1
establishment between the MS and target PDSN and Mobile IP re-registration (if 2
required) between the MS and the packet network may then be performed over the main 3
service instance. The target PCF populates the PANID and CANID fields of the ANID 4
NVSE and sends it to the target PDSN. User data is exchanged between the MS and the 5
corresponding node over the new A10 connection(s), encapsulated within GRE frames. 6
The source PDSN releases the A10 connection(s) with the source PCF on expiration of 7
the Lifetime timer (T
rp
) or other events internal to the PDSN. The target PCF periodically 8
re-registers with the target PDSN by the use of the A11-Registration Request message 9
before the A10 connection Lifetime expires. 10
TIA-2001.3-C
Section 3 186
x
MS
Source
BS/PCF
time
comment
Handoff Required
Handoff Request
a
b
c
d
e
f
Null forward traffic channels Frames
Handoff Request Ack
g
h
i
k
m
j
n
p
r
t
q
u
v
s
Handoff Command
T7
Extended/General Handoff Direction
MS Ack Order
Twaitho
Handoff Commenced
l
Reverse Traffic Channel Preamble or Data
Handoff Completion
Clear Complete
Clear Command
T9
T315
T306
MSC
Tregreq
Tregupd
T
regreq
BS Ack
O
Target
BS/PCF
Target
PDSN
Source
PDSN
T11
Service Negotiation
o
Handoff Complete
T8
1
Figure 3.17.5.11-1 Inter-BS Hard Handoff Mobile Served by New Target PDSN 2
a. On detection of a condition that a hard handoff is required, the source BS sends a 3
Handoff Required message to the MSC with a preferred list of target cells, and starts 4
timer T
7
. The source BS includes the ANID of the source PCF. The Service 5
TIA-2001.3-C
187 Section 3
Configuration Record in this message identifies the active service instances and the 1
Service Option List information element identifies all service instances. 2
b. The MSC sends a Handoff Request message to the target BS, which includes the 3
ANID received from the source BS, and starts timer T
11
. The Service Configuration 4
Record in this message identifies the active service instances and the Service Option 5
List information element identifies all service instances. The target BS determines 6
which service instances are dormant by comparing these two lists. 7
c. Upon receipt of the Handoff Request message, the target BS allocates suitable idle 8
(radio) resources. The BS starts transmitting null TCH data on the forward traffic 9
channel for the MS. 10
d. The target BS returns a Handoff Request Ack message to the MSC with appropriate 11
RF channel information to allow the MS to be instructed to tune to the new RF 12
channel, and starts timer T
9
to wait for the MS to arrive on the radio channel. Upon 13
receipt of the Handoff Request Ack message from the target BS, the MSC stops 14
timer T
11
. 15
e. The MSC prepares to switch the MS from source BS to target BS. The MSC sends a 16
Handoff Command message to the source BS containing the appropriate RF channel 17
information received from the target BS. Upon receipt of the Handoff Command 18
message, the source BS stops timer T
7
. 19
f. The source BS instructs the MS to handoff by sending a handoff direction message 20
(HDM/GHDM/EHDM/UHDM) and starting timer T
8
. If the MS is allowed to return 21
to the source BS timer T
waitho
g. The MS acknowledges receipt of the handoff direction message by sending an MS 23
Ack Order message to the source BS. The source BS stops timer T
8
upon receipt of 24
this message. 25
h. Upon receipt of confirmation from the MS, the source BS sends a Handoff 26
Commenced message to the MSC. The source BS starts timer T
306
to await the Clear 27
Command message from the MSC. If timer T
waitho
has been started, the source BS 28
shall wait for that timer to expire before sending the Handoff Commenced message. 29
i. The MS starts sending reverse TCH frames or preamble data to the target BS. 30
j. Upon synchronization of the traffic channel, the MS sends a Handoff Completion 31
Message to the target BS. The target BS detects that the MS has successfully 32
accessed the target and stops timer T
9
. 33
k. The target BS acknowledges receipt of the Handoff Completion Message by sending 34
a BS Ack Order to the MS. 35
l. The target PCF selects the target PDSN for this call and sends an A11-Registration 36
Request message with a non-zero Lifetime value and with Mobility Event Indicator 37
within a CVSE to the target PDSN for each active and dormant service instance of 38
the MS. This message also includes Accounting Data (R-P Session Setup Airlink 39
Record). This message also includes the PANID the target PCF received in the 40
Handoff Request message and the target PCFs CANID; both are included within an 41
NVSE. The target PCF starts a timer T
regreq
associated with the A11-Registration 42
Request message sent for each service instance. 43
m. Each A11-Registration Request message is validated and the target PDSN accepts 44
the connection by returning an A11-Registration Reply message with an accept 45
indication. The first A11-Registration Reply message also contains a Data Available 46
Indicator within a CVSE. The target PCF stops the associated timer T
regreq
. 47
TIA-2001.3-C
Section 3 188
n. The target BS then sends a Handoff Complete message to the MSC indicating 1
successful completion of hard handoff. 2
o. If the PDSN indicates that it has data available for the MS on a service instance that 3
is dormant, the BS initiates service negotiation with the MS to reconnect the dormant 4
service instance. 5
p. The link layer (PPP) connection between the MS and the target PDSN is established 6
and the MS performs MIP registration (if required) with the packet network over the 7
main service instance. User data is exchanged between the MS and the 8
corresponding node over the A10 connection(s). 9
q. Upon receipt of the Handoff Complete, the MSC initiates release of the MSC 10
resources used in the handoff. MSC then sends a Clear Command message to the 11
source BS, informing it of the success of the hard handoff. The source BS stops timer 12
T
306
315
. 13
r. The source BS sends a Clear Complete message to the MSC acknowledging success 14
of the handoff. MSC stops timer T
315
s. On expiration of the PPP timer or other events internal to it, the source PDSN 16
initiates closure of each A10 connection with the PCF by sending an A11- 17
Registration Update message. The source PDSN starts an associated timer T
regupd
. 18
Note: The source BS/PCF may initiate tear down of the A10 connections after 19
receiving the Clear Command (in step q). 20
t. The source PCF responds with an A11-Registration Acknowledge message to each 21
A11-Registration Update message. The source PDSN stops associated timer T
regupd
. 22
u. The source PCF sends an A11-Registration Request message with Lifetime set to 23
zero, and accounting related information to the source PDSN for each service 24
instance for which A11-Registration Update is received. The source PCF starts an 25
associated timer T
regreq
. 26
v. The source PDSN stores the accounting related information for further processing 27
before returning the A11-Registration Reply message with an accept indication for 28
each A11-Registration Request message received. The source PCF releases the 29
associated A10 connection(s) for the MS. The source PCF stops the associated 30
timer(s) T
regreq
for each A11-Registration Request message. 31
TIA-2001.3-C
189 Section 3
3.17.5.12 Accounting Update Due to Parameter Changes 1

BS/PCF
MS
MSC PDSN
b
c
d
Parameter
change
notification/
Active PPP session a
Parameter
change
notification/
time
Tregreq
2
Figure 3.17.5.12-1 Accounting Update Due to Parameter Change 3
a. An active PPP session exists and data is transferred over the connection. 4
b. An event occurs causing parameters associated with a particular service instance to 5
be changed/negotiated between the BS/MSC and the MS. 6
c. The PCF sends an A11-Registration Request message for the affected service 7
instance / A10 connection to notify the PDSN when any of the following parameters 8
have changed: User-Zone, Quality of Service, Forward/Reverse Mux Option (refer to 9
[5]). The message contains the airlink records Active-Stop followed by an Active 10
Start with the new set of parameters. The PCF starts timer T
regreq.
11
d. The PDSN updates the accounting data and returns an A11-Registration-Reply 12
message with an accept indication to PCF. The PCF stops T
regreq.
13
3.17.5.13 MS Initiated Reactivation from Dormant State; MS not Registered with New 14
PDSN 15
While in a dormant packet data session state, the MS has data to send to the network. The 16
MS detects a new packet zone and determines that it needs to notify the packet data 17
network. The MS sends an Origination Message to the target BS with the DRS bit set to 18
1. 19
TIA-2001.3-C
Section 3 190
MS
Source
BS/PCF
MSC
Time Comment
Origination
a
b
c
d
e
f
g
h
i
k
m
j
Source
PDSN
Target
BS/PCF
l
Assignment Complete
A11-Registration Request(Lifetime=0, Accounting data)
A11-Registration Reply (Lifetime=0, accept)
Tregreq
Tregupd
Target
PDSN
TCH Setup
CM Service Request
Assignment Request
T
303
T10
-
A11- Registration Reply
Tregreq
PPP Connection Establishment
1
Figure 3.17.5.13-1 MS Initiated Reactivation from Dormant State; MS Not Registered with 2
New PDSN 3
a. The MS has data to send to the network. Upon detection of a new PZID, SID or NID, 4
the MS determines that it needs to notify the packet data network. The MS sends an 5
Origination Message to the target BS with the DRS field set to 1. The MS may 6
include ANID information (PREV_SID, PREV_NID, or PREV_PZID) in the 7
message. 8
b. The target BS acknowledges the receipt of the Origination Message with a BS Ack 9
Order to the MS. 10
c. The target BS constructs a CM Service Request message, places it in the Complete 11
Layer 3 Information message, sends the message to the MSC, and starts timer T
303
. 12
d. The MSC sends an Assignment Request message to the target BS requesting 13
10
. On receipt of the Assignment 14
Request message, the target BS stops timer T
303
. 15
e. The target BS initiates setup of the traffic channel with the MS. 16
TIA-2001.3-C
191 Section 3
f. The BS sends the Assignment Complete message to the MSC. The MSC stops timer 1
T
10
. 2
g. The target PCF initiates establishment of the A10 connection by sending an A11- 3
Registration Request message with non-zero Lifetime value, an ANID NVSE, and 4
Accounting Data (R-P Session Setup Airlink Record) to the target PDSN. In the 5
ANID NVSE, the target PCF sets the CANID field to its ANID. If ANID 6
information was received from the MS, it is used to populate the PANID field. 7
Otherwise the PANID field is set to 0. If the target PCF is able to determine that a 8
handoff occurred (ANID information was received from the MS), it includes the 9
Mobility Event Indicator in the message. The PCF starts timer T
regreq
. 10
h. The A11-Registration Request message is validated and the target PDSN accepts the 11
indication. If the PDSN supports fast handoff the Anchor P-P Address is included. 13
i. The MS and the target PDSN establish the link layer (PPP) connection and perform 14
the MIP registration procedures (if supported) over the link layer (PPP) connection, 15
thereby creating a mobility binding for the MS. 16
j. Upon expiration of the Lifetime timer (T
rp
) or other events internal to the PDSN, the 17
a Registration Update message. The PDSN starts timer T
regupd
. 19
k. The source PCF responds with an A11-Registration Acknowledge message. The 20
regupd
. 21
l. The source PCF sends an A11-Registration Request message with Lifetime set to 22
zero to initiate release of the A10 connection. The source PCF starts timer T
regreq
. 23
m. The source PDSN stores the accounting related information for further processing 24
before returning A11-Registration Reply message with an accept indication. The 25
source PCF releases the A10 connection for the MS. The source PCF stops timer 26
T
regreq
. 27
3.17.6 Version Interoperability Control 28
This section describes version control on the A8/A9 interfaces. 29
3.17.6.1 Example of a Successful BS initiated A9 Version Control Procedure 30
This call flow shows an example of a successful BS initiated A9 version control 31
procedure. 32
Time
a
b
BS
PCF
A9-Version Info Ack
A9-Version Info
Comment
Tvers9
33
Figure 3.17.6.1-1 Successful BS Initiated A9 Version Control Procedure 34
TIA-2001.3-C
Section 3 192
a. The BS sends an A9-Version Info message to the PCF. The message includes the BS 1
software version information. If the message is sent as a result of a reset, a cause 2
element is included in the message to indicate that a BS reset occurred. The BS starts 3
timer T
vers9
. 4
b. The PCF responds with an A9-Version Info Ack message, which includes the PCFs 5
software version information. If a BS reset occurred, the PCF initiates a release of 6
any resources previously allocated for packet data calls supported by the BS. Upon 7
reception of the message, the BS stops timer T
vers9
. 8
3.17.6.2 Example of a Successful PCF Initiated A9 Version Control Procedure 9
This call flow shows an example of a successful PCF initiated A9 version control 10
procedure. 11
Time
a
b
BS
PCF
A9 Version Info Ack
A9 Version Info
Comment
Tvers9
12
Figure 3.17.6.2-1 Successful PCF Initiated A9-Version Control Procedure 13
a. The PCF sends an A9-Version Info message to the BS. The message includes the 14
PCF software version information. If the message is sent as a result of a reset, a 15
cause element is included in the message to indicate that a PCF reset occurred. The 16
PCF starts timer T
vers9
. 17
b. The BS responds with an A9-Version Info Ack message, which includes the BS 18
software version information. If a PCF reset occurred, the BS releases any resources 19
previously allocated for packet data calls supported by the PCF. Upon reception of 20
the message, the PCF stops timer T
vers9
. 21
3.17.7 Support of Short Data Bursts 22
This section describes call flows associated with the Short Data Burst feature. 23
3.17.7.1 Mobile Originated Short Data Burst Call Flows 24
An MS with a currently dormant packet data service instance may need to send a small 25
amount of data to the network. The MS may transmit it via a Short Data Burst (SDB) to 26
the BS in SDB format as specified in [23]. The short data burst is sent from the MS to the 27
BS over the signaling channel if there is no active voice or packet data call in progress 28
and over the traffic channel if there is an active voice or packet data call in progress. If 29
authentication is enabled in the network (and the MS is not engaged in an active voice or 30
packet data call), before the data is sent on from the BS, the MS may need to be 31
authenticated. If authentication is performed, the BS shall buffer the data during the 32
authentication procedure. If authentication is successful or not performed, the BS sends 33
the data to the PCF in SDB format as specified in [23]. The PCF sends this data on to the 34
PDSN as normal packet data. 35
TIA-2001.3-C
193 Section 3
The following call flow shows the receipt of a short data burst on the Access Channel 1
from the MS and its delivery to the PCF. This scenario assumes that the MS is not 2
engaged in an active voice or packet data call. 3

A11-Reqistration Request
T60
ADDS Transfer
Layer 2 Ack
A9-Short Data Delivery
MS BS MSC
PCF
PDSN
Time Comment
ADDS Transfer Ack
Dormant/PPP connected
a
b
c --- Optional
d --- Optional
e
Data Burst (type SDB)
f
g
h
Tregreq
Packet data
4
Figure 3.17.7.1-1 cdma2000
Short Data Burst from an MS to the PDSN 5

a. The MS sends a cdma2000
Short Data Burst to the network on a reverse common 6

signaling channel. 7
b. The BS acknowledges the cdma2000
Short Data Burst received by sending a Layer 8

2 Ack. 9
c. If the BS chooses to authenticate the MS, the BS sends an ADDS Transfer message 10
to the MSC containing the authentication parameters received from the MS, the BS 11
computed authentication data element, and the Data Burst Type field of the ADDS 12
User Part element set to short data burst. If authentication is performed, the BS shall 13
buffer the SDB data and start timer T
60
. The MSC receives the ADDS Transfer 14
message, reads the burst type field of the ADDS User Part element, and determines 15
that this a cdma2000
short data burst. The MSC may then authenticate the MS. 16
d. The MSC sends the result of the short data burst authentication to the BS in the 17
ADDS Transfer Ack message. Upon receipt of the ADDS Transfer Ack message, the 18
BS stops timer T
60
. If the cause element is present and indicates authentication 19
TIA-2001.3-C
Section 3 194
failure, the BS shall discard the buffered short data burst. If timer T
60
expires at the 1
BS before the BS receives the ADDS Transfer Ack message, the BS shall discard the 2
buffered short data burst. 3
e. If no cause element is present in the ADDS Transfer Ack response from the MSC, or 4
if the BS chose not to authenticate the MS, the BS sends the short data burst to the 5
PCF in SDB format as specified in [23] in the A9-Short Data Delivery message. 6
f. The PCF sends the data to the PDSN as normal packet data. 7
g. The PCF sends an A11-Registration Request message with the SDB Airlink record 8
to the PDSN. The PCF starts timer T
regreq.
9
h. The PDSN responds with an A11-Registration Reply message. The PCF stop T
regreq.
10
3.17.7.2 Mobile Terminated Short Data Burst Call Flows 11
When a small amount of data destined for a dormant packet data service instance on an 12
MS is received at the PCF, the PCF may send this data to the BS in SDB format as 13
If the BS accepts the data for delivery to the MS, the BS shall acknowledge the PCFs 15
request. The PCF may then discard the buffered data. 16
If the BS determines that a short data burst may be used to deliver the data to the MS, the 17
BS sends this data, in SDB format as specified in [23], directly to the MS over the 18
signaling or traffic channel. 19
If the BS is unsuccessful in delivering the SDB to the MS on its own or for other 20
implementation specific reasons, the BS may also send this data, in SDB format, on to the 21
MSC for delivery to the MS via the ADDS Page procedure. The BS may also send the 22
data to the MSC for delivery to the MS via the ADDS Deliver procedure if a voice call is 23
active. The data is delivered to the MSC using the BS Service Request/Response 24
procedure. 25
If after receiving data from the PCF in SDB format the BS determines that the packet 26
data service instance should be re-activated, it shall reject the PCFs request to send the 27
data as a short data burst by sending the cause value Initiate Re-Activation of Packet 28
Data Call in the A9-Short Data Ack message. The PCF shall then be required to initiate 29
the re-activation of the packet data service instance. Once the session is active, the 30
buffered data shall be resent to the BS for transmission to the MS as normal packet data. 31
Refer to section 3.17.7.2.2 for this scenario. 32
3.17.7.2.1 Short Data Delivery from the PDSN to the MS 33
The following procedure shows the call flow associated with the receipt of a short data 34
message from the PCF and its delivery to the MS. 35
TIA-2001.3-C
195 Section 3
T311
A9-Short Data Ack
All-Registration Request
Data Burst (Type SDB)
MS BS MSC/VLR PCF PDSN Time
b
f
g
h
j
BS Service Response
T311
BS Service Request
ADDS Page Procedure.
Packet data a
Layer 2 Ack d
i
Tsdd9
c
e
A9-Update-A8
A9-Update-A8 Ack
Tupd9
Tregreq
conditional
conditional
conditional
k
1
Figure 3.17.7.2.1-1 cdma2000
Short Data Burst from the PDSN to the MS 2

a. The PDSN sends packet data to the PCF on an existing PPP connection and A10 3
connection associated with a specific MS. The PCF sends the packet data to the BS 4
in the A9-Short Data Delivery message and starts timer T
sdd9
. The data is sent in 5
SDB format as specified in [23] and is encapsulated in the ADDS user part element. 6
The PCF buffers the data sent. 7
b. The BS acknowledges receipt of the A9-Short Data Delivery message from the PCF 8
by returning the A9-Short Data Delivery Ack message with cause value Successful 9
TIA-2001.3-C
Section 3 196
operation to indicate that it will deliver the data as a short data burst. The PCF stops 1
timer T
sdd9
and discards the buffered data. If timer T
sdd9
expires, the PCF discards 2
the buffered data. 3
c. The BS may send a short data burst directly to the MS, or alternatively the BS may 4
skip to step e to initiate the ADDS Page procedure. Note, the BS may also decide 5
to alternatively deliver the data to the MS over a traffic channel (refer to section 6
3.17..7.2.2). 7
d. The MS sends a layer 2 Ack in response to the short data burst from the BS. If a 8
layer 2 Ack is not received from the MS, the BS may continue with steps e through 9
g below. If the Layer 2 Ack is received, the call flow continues with step h. 10
e. The BS sends the SDB data in a SDB format to the MSC in the BS Service Request 11
message. The BS starts timer T
311
. If timer T
311
expires, the SDB information shall 12
not be sent to the MS. 13
f. The MSC acknowledges reception of the BS Service Request message by sending a 14
BS Service Response message to the BS. The BS stops timer T
311
. 15
g. The MSC sends an ADDS Page message to the BS with the Data Burst Type field in 16
the ADDS User Part element set to Short Data Burst, and the SDB in the Application 17
Data Message field. The BS forwards the Short Data Burst on to the MS. Refer to 18
section 3.10.2.3. 19
h. The BS sends an A9-Update-A8 message to the PCF to indicate successful 20
transmission of the Short Data Burst to the MS. The BS starts timer T
upd9.
21
i. The PCF sends an A11-Registration Request message with the SDB Airlink record 22
to the PDSN. The PCF starts timer T
regreq.
23
j. The PDSN responds with the A11-Registration Reply message. The PCF stops 24
T
regreq.
25
k. The PCF responds to the BS with an A9-Update-A8 Ack. The BS stops timer T
upd9
. 26
3.17.7.2.2 Short Data Delivery from the PDSN BS Refuses SDB Request 27
The following procedure shows the call flow associated with the BS refusal of the PCF 28
short data burst request, and subsequent delivery of the data to the MS on a traffic 29
channel. 30
TIA-2001.3-C
197 Section 3
T311
MS BS MSC PCF PDSN
Time
b
Network initiated call
re-activation from dormant state
Packet data
a
c
A9-Short Data Ack
Tsdd9
d
e
1
Figure 3.17.7.2.2-1 Short Data Burst from the PDSN to the MS BS Refuses SDB Request 2
a. The PDSN sends packet data to the PCF on an existing A10 connection associated 3
with a specific MS. 4
b. The PCF sends the packet data to the BS in the A9-Short Data Delivery message and 5
sets timer T
sdd9
. The data is sent in SDB format as specified in [23] and is 6
encapsulated in the ADDS user part element. The PCF buffers the data sent. 7
c. The BS makes the determination, based on its internal algorithm, the data count field 8
in the A9-Short Data Delivery, or any other factors, not to send a short data burst to 9
the MS. The BS sends an A9-Short Data Delivery Ack message to the PCF with an 10
indication that a short data burst is not to be sent to the MS by setting the cause value 11
to Initiate re-activation of packet data call. 12
d. The PCF stops timer T
sdd9
and initiates a reactivation of the packet data service. 13
Refer to section 3.17.4.7.1. 14
e Once the packet data service instance is active, the PCF sends the data buffered 15
earlier for the MS to the BS which forwards the data on to the MS. 16
17
TIA-2001.3-C
Section 3 198
3.17.8 Support for Common Channel Packet Data (CCPD) 1
This section describes support for Common Channel Packet Data (CCPD) mode of 2
packet data service. 3
3.17.8.1 Mobile Originated CCPD Mode Packet Data Call Setup Request 4
A CCPD capable MS requests CCPD Mode from the network by sending an Origination 5
Message to the BS with the SDB_DESIRED_ONLY and DRS bits set to 1. If the BS 6
agrees to support an MSs request for CCPD Mode, the MS is first authenticated and 7
registered via the ADDS Transfer procedure. Upon successful authentication of the MS, 8
the PCF is informed that CCPD Mode is to be used for the call. PPP connection setup and 9
Mobile IP Registration (if required) are performed using Short Data Bursts over Common 10
Channels to exchange the messages. Messages and data between the BS and PCF are 11
passed over the A9 signaling channel; an A8 bearer connection is not required. Upon 12
successful completion of these procedures, the packet data service instance transitions 13
from the Null to Dormant State. 14
The following messages are used to support a Mobile Originated CCPD Mode Request: 15
ADDS Transfer 16
ADDS Transfer Ack 17
A9-Setup-A8 18
A9-Short Data Delivery 20
A9-Short Data Ack 21
A-11 Registration Reply 23
The following call flow describes an MS initiated Common Channel Packet Data call. 24
TIA-2001.3-C
199 Section 3
BS
MS
Origination
BS Ack Order
MSC
ADDS Transfer
A9-Setup-A8
ADDS Transfer Ack
PCF PDSN
A9- Short Data Delivery
a
b
c
d
e
f
g
i
j
T60
TA8-setup
Data Burst (SDB)
Packet Data
(Establish PPP Connection)
Time
Null / Inactive State
Dormant / PPP Connected
Packet Data
l
m
BS Ack Order
n
o
p
Tregreq
Data Burst (SDB)
Packet Data
Layer 2 Ack
Data Burst (SDB)
BS Ack Order
q
r
s
t
u
v
w
A9- Short Data Ack
k
Tsdd9
Release Order
h
Tregreq
x
1
Figure 3.17.8.1-1 MS Initiated CCPD Mode Setup and Data Transfer 2
TIA-2001.3-C
Section 3 200
a. An MS transmits an Origination Message to the BS over the Access Channel of the 1
air interface with Layer 2 Ack required to request packet data service. The MS 2
indicates its desire for CCPD Mode to the network by setting the 3
SDB_DESIRED_ONLY bit in the message to 1 and DRS bit set to 1. 4
b. The BS acknowledges receipt of the Origination Message by sending a Base Station 5
c. The BS sends an ADDS Transfer message to the MSC containing the authentication 7
parameters received from the MS, the BS computed authentication data element, and 8
the Data Burst Type field of the ADDS User Part element set to Short Data Burst. 9
The BS starts timer T
60
. If the BS decides not to support the MSs request for CCPD 10
Mode, the BS may reject the call or treat the call as a normal mobile originated 11
packet data call by assigning a traffic channel (refer to section 3.17.4.1 for the call 12
flow). 13
d. The MSC sends the result of authentication for the MS back to the BS in the ADDS 14
Transfer Ack message. The BS stops timer T
60
. 15
e. The BS sends an A9-Setup-A8 message to PCF to initiate an A8 connection setup. 16
The BS sets the CCPD Mode bit in the message to 1 to indicate to the PCF that this 17
is a CCPD call and that an A8 connection is not required. The BS starts timer T
A8-
18
setup
. 19
f. If the PCF recognizes that no A10 connection associated with this MS is available 20
then the PCF selects a PDSN. The PCF sends an A11-Registration Request message 21
with non-zero Lifetime value to the selected PDSN. The PCF starts timer T
regreq
. 22
indication and the Lifetime field set to the configured T
rp
value. The PCF stops timer 25
T
regreq
. 26
h. The PCF sends an A9-Release-A8 Complete message to the BS with a Packet call 27
going dormant cause value. The BS stops timer T
A8-setup
. 28
i. The BS sends a Release Order without a rejection of the service option to the MS. 29
This Release Order serves as an acknowledge of the CCPD Mode request from the 30
MS 31
j. The PDSN sends packet data (PPP connection establishment and MIP registration 32
messages if supported) on the A10 connection to the PCF. 33
k. The PCF sends the packet data in SDB format in an A9-Short Data Delivery message 34
with an indication that the data is for MS in CCPD Mode to the BS. The PCF starts 35
timer T
sdd9
. 36
l. The BS acknowledges the receipt of an A9-Short Data Delivery message from the 37
PCF by sending an A9-Short Data Ack to the PCF. The PCF discards the buffered 38
data and stops timer T
sdd9
. 39
m. The BS sends the packet data in a Short Data Burst over the common channel to the 40
MS. 41
n. The MS acknowledges receipt of the Short Data Burst from the BS by sending a 42
Layer 2 Ack to the BS. If a Layer 2 Ack is not received from the MS, the BS may 43
resend the SDB to the MS. 44
o. The MS sends packet data (PPP connection establishment and MIP Registration if 45
supported) in a SDB over the common channel to the BS. 46
TIA-2001.3-C
201 Section 3
p. The BS acknowledges receipt of the SDB from the MS by sending a BS Ack Order 1
to the MS. 2
q. The BS sends an A9-Short Data Delivery message containing packet data from the 3
MS in SDB format to the PCF. 4
r. The PCF sends the data to the PDSN as normal packet data on the A10 connection. 5
Note: Steps j-r are repeated until the PPP connection is established and MIP 6
Registration (if supported) are completed. The packet data service state transitions to 7
the Dormant State. 8
s. The MS in CCPD Mode sends packet data in a SDB over the common channel to the 9
BS. 10
t. The BS acknowledges receipt of the SDB from the MS by sending a BS Ack Order 11
to the MS. 12
u. The BS sends an A9-Short Data Delivery message containing the packet data from 13
the MS in SDB format to the PCF. 14
v. The PCF sends the data to the PDSN as normal packet data on the A10 connection. 15
w. The PCF sends an A11-Registration Request message with the SDB Airlink record 16
for accounting to the PDSN. The PCF starts timer T
regreq.
17
x. The PDSN responds with an A11-Registration Reply message to the PCF. The PCF 18
stops T
regreq.
19
3.17.8.2 Mobile Terminated Packet Data for CCPD 20
The PCF was informed that the MS requested CCPD Mode at the time the MS initiated a 21
CCPD Mode Request from the network. If the network has data to send, the PCF sends 22
the data to the BS in the A9-Short Data Delivery message with an indication that the data 23
is for a CCPD capable MS. The BS sends the data to the MS in a Short Data burst as 24
specified in [23]. If the BS doesnt receive an acknowledgement from the MS after 25
sending the Short Data Burst to the MS, the BS may resend the data or invoke ADDS 26
Procedures to deliver the data. 27
The following messages are used to support a Mobile Terminated Packet Data for CCPD: 28
A9-Short Data Ack 30
A9-Update-A8 31
A9-Update-Ack 32
A-11 Registration Reply 34
Refer to call flow 3.17.7.2.1 Short Data Delivery from PDSN to MS for mobile 35
terminated packet data transfer for an MS in CCPD Mode. 36
3.17.8.3 CCPD Mode Packet Data Handoffs 37
The following calls flows describe dormant handoff for CCPD Capable MSs. Upon 38
detection of a new PZID, SID, or NID, the MS sends an Origination Message to the BS 39
with the SDB_DESIRED _ONLY bit set to 1 and the DRS bit set to 0. The PCF 40
establishes an A10 connection with the PDSN. If the MS continues to be served by the 41
same PDSN, the PDSN releases the A10 connection with the previous PCF. If as a result 42
TIA-2001.3-C
Section 3 202
of the dormant mode handoff a new PDSN is selected for the call, a PPP connection is 1
setup and Mobile IP Registration (if required) is performed using Short Data Bursts over 2
Common channels. 3
The BS may initiate CCPD Mode handoff for an MS that supports short data bursts even 4
though the MS may not have explicitly requested CCPD Mode from the BS The BS may 5
use this procedure to support dormant mode handoffs (e.g. if traffic channels are not 6
available) in the event PPP connection establishment is required or PDSN has data to 7
send. Upon detection of a new PZID, SID, or NID, the MS sends an Origination Message 8
to the BS with the SDB_DESIRED_ONLY bit set to 0, and the DRS bit set to 0. 9
Instead of initiating normal dormant mode handoff procedures, the BS initiates CCPD 10
handoff by informing the PCF that CCPD Mode shall be used in the case that the PDSN 11
has data to send as part of the dormant handoff. If the PDSN has data to send, the PCF 12
will forward the data via the BS to the MS as Short Data bursts. 13
The following IOS messages are used to support a CCPD Mode dormant handoff: 14
ADDS Transfer 15
ADDS Transfer Ack 16
A9-Setup-A8 17
A9-Short Data Ack. 20
3.17.8.3.1 CCPD MS Handoff - Mobile Served by the Same PDSN 21
The following call flow describes the procedure for a successful inter-PCF/intra-PDSN 22
handoff of a CCPD MS. It is assumed that the PCF is uniquely identified by the CANID. 23
On detection of a new PZID, NID or SID, the MS sends an Origination Message to the 24
target BS with the packet data service option the SDB_DESIRED_ONLY bit set to 1 25
and DRS bit set to 0. The Origination Message includes the previous PZID, NID and 26
SID when any of these parameters change during the dormant handoff. Based on the IDs 27
(PZID, NID and/or SID) in the Origination Message, the target PCF sends the PANID of 28
the source PCF and the CANID of the target PCF to the serving PDSN. The serving 29
PDSN uses this information to determine if PPP re-negotiation is required. All messages 30
using the SDB format in the call flow are as specified in [23]. If the PDSN has data, the 31
PDSN returns the Data Available Indicator in the CVSE within the Registration Reply 32
message to the BS/PCF. The source PDSN releases the A10 connection with the source 33
PCF. 34
TIA-2001.3-C
203 Section 3

ADDS Transfer Ack
Source BS MSC
Source
PCF
Time Comment
a
b
c
d
e
f
g
h
i
PDSN
Target
PCF
MS
ADDS Transfer
Origination Message
A9-Setup-A8
BS Ack Order
Dormant, PPPConnected
T
A8-setup

Target BS
T60
Release Order
Dormant, PPPConnected
T
regreq
T
regreq
T
regreq

j
k
l
1
Figure 3.17.8.3.1-1 MS in CCPD Mode Handoff (Inter-BS/Inter-PCF) - Mobile Served by Same 2
PDSN 3
a. The CCPD MS detects a change of PZID, SID or NID while monitoring the 4
broadcast channel and sends an Origination Message with the 5
SDB_DESIRED_ONLY bit set to 1 and DRS bit set to 0. 6
b. The target BS acknowledges receipt of the Origination Message with a Base Station 7
Acknowledgement Order to the MS. 8
c. The target BS sends an ADDS Transfer message to the MSC containing the 9
authentication parameters received from the MS, the target BS computed 10
authentication data element, and the Data Burst Type field of the ADDS User Part 11
element set to Short Data Burst. The target BS starts timer T
60
. 12
d. The MSC sends the ADDS Transfer Ack message to the target BS with no cause 13
value present. The target BS stops timer T
60
. 14
e. The target BS sends an A9-Setup-A8 message, with the Data Ready Indicator and 15
Handoff Indicator bits set to 0 to the target PCF. The target BS sets the CCPD 16
TIA-2001.3-C
Section 3 204
Mode bit in the message to 1 to indicate to the PCF that an A8 connection is not 1
required. The target BS starts timer T
A8-setup
. 2
f. The target PCF selects a PDSN and sends an A11-Registration Request message to 3
the PDSN. The Registration Request message includes the Mobility Event Indicator 4
within a CVSE. The PCF starts timer T
regreq
. 5
indication. If the PDSN has data to send, it includes the Data Available Indicator 8
within a CVSE The A10 connection binding information at the PDSN is updated to 9
point to the target PCF. The PCF stops timer T
regreq
. 10
h. The target PCF sends an A9-Release-A8 Complete message to the target BS with a 11
Packet data going dormant cause value. The target BS stops timer T
A8-setup
. 12
i. The target BS sends a Release Order without a rejection of the service option to the 13
MS. The Release Order serves as an acknowledgement to the CCPD Mode request 14
from the MS. 15
Note: The packet data session returns to Dormant State 16
j. The PDSN initiates release of the A10 connection with the source PCF by sending an 17
regupd
. 18
k. The source PCF responds with an A11-Registration Acknowledge message. The 19
PDSN stops timer T
regupd
. 20
l. The source PCF sends an A11-Registration Request message with Lifetime set to 21
zero, to the PDSN. The PCF starts timer T
regreq
. 22
m. The PDSN sends the A11-Registration Reply message to the source PCF. The source 23
PCF releases the A10 connection for the MS. The PCF stops timer T
regreq
. 24
3.17.8.3.2 Dormant Handoff of a CCPD Mobile: Mobile Served by a New PDSN 25
The following call flow describes the procedure for a successful inter-PCF/inter-PDSN 26
handoff of a CCPD MS. On detection of a new PZID, SID, or NID, the MS sends an 27
Origination Message to the target BS that includes the packet data service option and the 28
SDB_DESIRED_ONLY bit set to 1and DRS bit set to 0. The target PCF establishes 29
an A10 connection with the target PDSN. The target PCF forwards the PANID of the 30
source PCF and the CANID of the target PCF to the serving PDSN. PPP Connection 31
Setup and Mobile IP Registration (if required) occur using Short Data Bursts over the 32
common channels. The source PDSN releases the A10 connection with the source PCF 33
on expiration of the Lifetime timer (T
rp
) or other events internal to the PDSN. The target 34
PCF periodically re-registers with the PDSN by the use of the A11-Registration Request 35
message before the A10 connection Lifetime expires. 36
This call flow may also be used if the network decides to initiate CCPD Mode for a 37
dormant mode handoff without the MS having requested CCPD Mode. For this case, the 38
MS sends an Origination Message with the SDB_DESIRED_ONLY and DRS bits set to 39
0. 40
TIA-2001.3-C
205 Section 3

BS
MS
Origination
BS ACK Order
MSC
ADDS Transfer
A9-Setup-A8
ADDS Transfer Ack
PCF PDSN
a
b
c
d
e
f
g
h
T60
TA8-Setup
Time
Packet Data
Data Burst (SDB)
Packet Data
Layer 2 Ack
Data Burst (SDB)
BS Ack Order
i
j
k
l
m
n
o
Tregreq
Release Order
A9- Short Data Ack
Tsdd9
p
q
r
1
Figure 3.17.8.3.2-1 MS in CCPD Mode Handoff (Inter-BS/Inter-PCF) - Mobile Served by 2
Different PDSN 3
a. The CCPD MS detects a change of Packet Zone ID while monitoring the broadcast 4
channel and sends an Origination Message with the SDB_DESIRED_ONLY bit set 5
to 1 and DRS bit set to 0. 6
b. The BS acknowledges receipt of the Origination Message with a Base Station 7
c. The BS sends an ADDS Transfer message to the MSC containing the authentication 9
parameters received from the MS, the BS computed authentication data element, and 10
the Data Burst Type field of the ADDS User Part element set to Short Data Burst. 11
60
. 12
d. The MSC sends the ADDS Transfer Ack message to the BS with no cause value 13
present. The BS stops timer T
60
. 14
TIA-2001.3-C
Section 3 206
e. The BS sends an A9-Setup-A8 message, with Data Ready Indicator and Handoff 1
Indicator bits set to 0 to the target PCF. The BS sets the CCPD Mode bit in the 2
message to 1 to indicate to the PCF that CCPD Mode is being used for the call and 3
that an A8 connection is not required. The BS starts timer T
A8-setup
. 4
f. The target PCF selects a PDSN and sends an A11-Registration Request message to 5
the PDSN. The Registration Request message includes the Mobility Event Indicator 6
within a CVSE. The PCF starts timer T
regreq
. 7
indication. If the PDSN has data to send, it includes the Data Available Indicator 10
within a CVSE The A10 connection binding information at the PDSN is updated to 11
point to the target PCF. The PCF stops timer T
regreq
12
h. The PCF sends an A9-Release-A8 Complete message to the BS with a Packet call 13
going dormant cause value. The BS stops timer T
A8-setup
. 14
i. The BS sends a Release Order without a rejection of service option to the MS. This 15
Release Order serves as an acknowledge of the CCPD Mode request from the MS 16
j. The PDSN sends packet data (PPP connection establishment and MIP registration if 17
supported) on the A10 connection to the PCF. 18
k. The PCF sends the packet data SDB format in an A9-Short Data Delivery message to 19
the BS. The BS starts timer T
sdd9
. 20
l. The BS acknowledges the receipt of an A9-Short Data Delivery message from the 21
PCF by sending an A9-Short Data Ack to the PCF. The PCF discards the buffered 22
data and stops timer T
sdd9
. 23
m. The BS sends the packet data in a Short Data Burst over the common channel to the 24
MS. 25
n. The MS acknowledges receipt of the Short Data Burst from the BS by sending a 26
Layer 2 Ack to the BS. If a Layer 2 Ack is not received from the MS, the BS may 27
resend the SDB to the MS. 28
o. The MS sends packet data (PPP connection establishment and MIP Registration if 29
supported) in a SDB over the common channel to the BS 30
p. The BS acknowledges receipt of the SDB from the MS by sending a BS Ack Order 31
to the MS 32
q. The BS sends an A9-Short Data Delivery message containing the packet data (PPP 33
establishment) from the MS in SDB format to the PCF. 34
r. The PCF sends the data to the PDSN as normal packet data (PPP establishment) on 35
the A10 connection. 36
Note: The source PDSN will eventually release the A10 connection to the Source PCF for 37
the MS upon expiration of the PPP timer or other event internal to the source PDSN. 38
Refer to steps l through o in Figure 3.17.5.9-1. 39
3.17.9 Packet Data Security Considerations 40
There are no call flows associated with this feature. Refer to [17] for more information. 41
TIA-2001.3-C
207 Section 3
3.17.10 Support for PDSN Initiated Packet Data Session Updates 1
The PDSN may send parameters to the PCF that affect the behavior of the PCF or the BS 2
or both. The parameters may be related to the packet data session or to individual PDSIs. 3
If the parameters are available at the PDSN when a new A10 connection is established, 4
the PDSN sends the parameters in a Session Parameters NVSE in the A11-Registration 5
Reply message. The PCF may forward the parameters to the BS in the A9-Connect-A8 6
message. Refer to the call flows in section 3.17.4 involving setup of new A10 7
connections. 8
While the packet data session is dormant, the PDSN stores the parameters and sends them 9
to the PCF upon reactivation of the packet data session in the A11-Registration Reply 10
message. The PCF may forward the parameters to the BS in the A9-Connect-A8 11
message. Refer to the call flows in section 3.17.4 for packet data reactivation from 12
Dormant State. 13
If the parameters become available at the PDSN or change while the packet data session 14
is active, the PDSN may send a Session Parameters NVSE in the A11 Session Update 15
message. The PCF may forward the parameters to the BS using the A9-Update-A8 16
message. The following call flow describes a PDSN initiated packet data session update 17
procedure when the packet data session is active. 18

MS BS PCF
PDSN
Time Comment
A11-Session Update
A9-Update-A8
A9-Update-A8 Ack
T
sesup
A11-Session Update Ack
T
upd9
a
b
c
d
e
conditional
conditional
19
Figure 3.17.10-1 PDSN Initiated Packet Data Session Update 20
a. The packet data session is in the Active State. 21
b. The PDSN initiates the transfer of a new or updated packet session parameter(s) by 22
sending an A11-Session Update message to the PCF including the new or updated 23
parameters in an NVSE. The PDSN starts timer T
sesupd
. 24
c. For parameters that do not affect the BS behavior, steps c and d may be omitted. 25
The PCF sends an A9-Update-A8 message to the BS with the new or updated packet 26
session parameters. The PCF starts timer T
upd9
. 27
d. The BS responds by sending an A9-Update-A8 Ack message to the PCF with the 28
results of processing the session parameter(s) update. The PCF stops timer T
upd9
. 29
TIA-2001.3-C
Section 3 208
e. The PCF sends an A11-Session Update Acknowledge message to the PDSN 1
indicating the results of the session update procedure. The PDSN stops timer T
sesupd
. 2
3.18 Voice and Packet Concurrent Service 3
This section describes call flows associated with Concurrent Services. Concurrent service 4
provides support for one circuit voice and one packet data session (which may be 5
comprised of one or more packet data service instances) simultaneously. Other service 6
combinations may be supported by a future release. 7
Refer to [32] for further explanation of MSC operations and [8] for further explanation of 8
PDSN operations. 9
3.18.1 Concurrent Service Examples - Mobile Origination 10
The following subsections describe the call flows for establishing one or more additional 11
service option connection(s) through an MS originated action while the MS is already 12
active with another service. Mobile originated concurrent service setup involves 13
exchange of the following messages: 14
Additional Service Request 15
A9-Setup-A8 19
A9-Connect-A8. 20
3.18.1.1 Mobile Initiated Packet Data Service Connection, Packet Data Session is Null or 21
Dormant, Voice Service is Already Active 22
This section describes the call flow associated with an MS initiated packet data service 23
connection in the system for the case that the MS is engaged in an active voice call. The 24
MS initiates a packet data service connection to setup its first or main packet data service 25
instance, to set up an auxiliary service instance (while all other service instances are 26
dormant), or to reactivate a dormant service instance. In the first case, the MS performs 27
PPP negotiation over packet data connection / service instance before user data transfer. 28
The call flow applies to all three cases. 29
TIA-2001.3-C
209 Section 3
Assignment Request
BSC
MS
BS ACK Order
MSC
Additional Service Request
A9-Setup-A8
PCF PDSN
A9-Connect-A8
Assignment Complete
a
b
c
d
e
f
g
h
i
A10 Connection
Establishment
T303
T10
T
A8-setup

Concurrent Service Active
Establishing PPP connection j
Voice Active, Packet Data Session Null or Dormant
Time
Service
negotiation
1
Figure 3.18.1.1-1 Mobile Initiated Packet Data Service Connection, Packet Data Session Null or 2
Dormant, Voice Service is Already Active 3
a. The MS transmits an Enhanced Origination Message, with layer 2 acknowledgment 4
required, over the traffic channel of the air interface to the BS to request service. 5
c. The BS constructs the Additional Service Request message, sends the message to the 8
MSC, and starts timer T
303
. 9
10
. For packet data service, an additional terrestrial 11
circuit between the MSC and the BS is not required. The BS stops timer T
303
upon 12
receipt of the Assignment Request message. 13
e. Service Negotiation procedures take place to associate the service instance with the 14
traffic channel. 15
f. The BS transmits an A9-Setup-A8 message to the PCF to establish an A8 connection 16
and starts timer T
A8-setup
. 17
g. Procedure for establishing an A10 connection is performed. 18
and transmits an A9-Connect-A8 message. Upon receiving the A9-Connect-A8 20
message, the BS stops timer T
A8-setup.
21
TIA-2001.3-C
Section 3 210
i. The BS transmits an Assignment Complete message. The MSC stops timer T
10
. This 1
step may occur any time after radio link establishment. 2
j. If the packet data connection is to enable the MS to set up its first service instance, 3
PPP connection establishment procedures and Mobile IP Registration (if required) on 4
the PPP connection are performed between the MS and PDSN. 5
3.18.1.2 Mobile Initiated Voice Service Connection, Packet Data Session is Already Active 6
This section describes the call flow associated with an MS initiated voice service 7
connection in the system for the case that the MS is engaged in an active packet data 8
session (at least one packet data service instance is active). 9
MS BS MSC
time comment
a
b
c
d
e
Assignment Request
f
Assignment Complete
Ringback Tone
T10
Transparent to
signaling
T303
Concurrent Service active
g
Service negotiation
procedures
Active packet data session
10
Figure 3.18.1.2-1 Mobile Initiated Voice Service Connection, Packet Data Session is Already Active. 11
a. The MS transmits an Enhanced Origination Message, with layer 2 acknowledgment 12
required, over the traffic channel of the air interface to the BS to request voice 13
service. 14
c. The BS constructs the Additional Service Request message, sends the message to the 17
303
. The BS may request the MSC to allocate a preferred 18
terrestrial circuit. 19
radio resources. This message includes information on the terrestrial circuit. The 21
MSC then starts timer T
10
. If the BS requested a preferred terrestrial circuit in the 22
Additional Service Request message and that terrestrial circuit is available (refer to 23
TIA-2001.3-C
211 Section 3
[14]), the MSC shall use the same terrestrial circuit in the Assignment Request 1
message. Otherwise, the MSC may assign a different terrestrial circuit. Upon receipt 2
of the Assignment Request message from the MSC, the BS stops timer T
303
. 3
e. Service negotiation procedures take place to associate the new service instance with 4
f. After the radio traffic channel and circuit have both been established and fully 6
interconnected, the BS sends the Assignment Complete message to the MSC and 7
considers the additional service to be in Conversation State. The MSC stops timer 8
T
10
upon receipt of the Assignment Complete message. 9
g. As call progress tone is applied in-band in this case, a ringback tone is available on 10
the audio circuit path towards the MS. This step is only applicable to the additional 11
voice service. 12
3.18.1.3 Mobile Initiated Packet Data Service Connection, Packet Data Session is Already 13
Active, Voice Service is Already Active 14
This section describes the call flow associated with an MS initiated packet data service 15
connection for the case where the MS already has an active packet data session (i.e. at 16
least one packet data service instance is active) and it is also engaged in an active voice 17
call. The MS initiates auxiliary packet data service connection to set up an auxiliary 18
service instance or to reactivate a dormant auxiliary packet service instance. 19
This call flow procedure is identical to those in sections 3.17.4.1.2 and 3.17.5.1.2 with the 20
exception that voice service is already active in addition to the packet data session being 21
active. 22
3.18.1.4 Mobile Initiated Voice Service Connection, Packet Data Session is Dormant 23
This call flow is identical to a regular MS initiated voice service connection. Refer to 24
section 3.1.1. 25
3.18.2 Concurrent Service Examples - Mobile Termination 26
The following call flow illustrates the procedures for establishing a mobile terminated 27
voice call while the MS is maintaining an active packet data session. Mobile terminated 28
concurrent voice service setup involves exchange of the following A1 messages: 29
Additional Service Notification 30
Connect. 35
36
TIA-2001.3-C
Section 3 212
A
Service
negotiation
procedures
MS BS MSC
time comment
c
d
e
f
g
h
i
Assignment Request
j
Assignment Complete
T10
Connect
b
a
Additional Service Notification
Extended Alert with Info
MS Ack Order
Connect Order
BS Ack Order
T301
T314
T303
1
Figure 3.18.2-1 Mobile Termination for Voice Service, Packet Data Session is Already Active 2
a. The MSC sends an Additional Service Notification message to the BS to initiate a 3
voice service option connection. The MSC starts timer T
314
. 4
b. The BS constructs the Additional Service Request message, sends the message to the 5
303
. The BS may request the MSC to allocate a preferred 6
terrestrial circuit. The MSC stops timer T
314
upon receipt of the Additional Service 7
Request message from the BS. 8
c. The MSC sends an Assignment Request message to the BS to request assignment of 9
radio resources. This message includes information on the terrestrial circuit. The 10
MSC starts timer T
10
. 11
If the BS requested a preferred terrestrial circuit in the Additional Service Request 12
message and that terrestrial circuit is available (refer to [14]), the MSC shall use the 13
same terrestrial circuit in the Assignment Request message. Otherwise, the MSC 14
may assign a different terrestrial circuit. Upon receipt of the Assignment Request 15
message from the MSC, the BS stops timer T
303
. 16
d. Service negotiation procedures take place to associate the service instance with the 17
traffic channel. 18
TIA-2001.3-C
213 Section 3
e. After the radio traffic channel and circuit have both been established and fully 1
interconnected, the BS sends the Assignment Complete message to the MSC. The 2
MSC stops timer T
10
upon receipt of the Assignment Complete message. The MSC 3
starts timer T
301
. 4
f. The BS sends the Extended Alert with Information Message to the MS to cause 5
ringing at the MS. 6
g. The MS acknowledges the reception of the Alert with Information Message by 7
h. When the call is answered at the MS, a Connect Order, with acknowledgment 9
i. The BS acknowledges the Connect Order with the Base Station Acknowledgment 11
j. The BS sends a Connect message to the MSC to indicate that the call has been 13
answered at the MS. At this point, the call is considered stable and in the 14
Conversation State. The MSC stops timer T
301
upon receipt of the Connect message 15
from the BS. 16
3.18.3 Concurrent Service Examples - BS Initiated Packet Data 17
Service Instance Re-Activation 18
The following subsections describe the call flows for establishing a packet data 19
connection (i.e. re-activating a packet data service instance) to an MS that already has an 20
active voice call and may or may not have an active packet data service instance. The call 21
flow is triggered by a request from the PDSN (through the PCF) to send data packets to 22
the MS. BS initiated call setup for concurrent service involves exchange of the following 23
messages: 24
Additional Service Notification 29
A9-BS Service Request 30
A9-BS Service Response 31
A9-Setup-A8 32
A9-Connect-A8. 33
3.18.3.1 Network Initiated PDSI Re-Activation from Dormant State, MS is Already Active 34
with Voice Service, Packet Data Session is Dormant 35
The following call flow provides an illustration for a successful dormant packet data 36
service reactivation procedure, when the MS is already active with voice service and the 37
packet data session is dormant. 38
TIA-2001.3-C
Section 3 214
Comment
MS
Time
a
b
c
d
e
f
g
j
A9-Setup-A8
A9-Connect-A8
Assignment Complete
TA8-setup
T10
Voice Active, Packet Dormant, PPP connection is maintained
Packet Data
Assignment Request
Tbsreq9 T303
i
Service
negotiation
A11 Accounting
Procedures
h
1
Figure 3.18.3.1 Network Initiated PDSI Re-Activation from Dormant State, Voice is Already Active, 2
Packet Data Session is Dormant 3
a. The PDSN sends data packets to the PCF on an existing A10 connection associated 4
with a specific MS for packet service. 5
b. The PCF sends an A9-BS Service Request message containing the SR_ID of a 6
dormant packet data service instance to the BS to request reactivation of that packet 7
data service instance and starts timer T
bsreq9
. 8
c. The BS sends an Additional Service Request message to the MSC and starts timer 9
T
303
to reconnect the packet data service option connection. 10
radio resources and the A8 (User Traffic) connection between the BS and the PCF. 12
The MSC starts timer T
10
. Upon receipt of the Assignment Request message from 13
the MSC, the BS stops timer T
303
. 14
e. The BS responds with an A9-BS Service Response message. The PCF stops timer 15
T
bsreq9
TIA-2001.3-C
215 Section 3
f. Service negotiation procedures take place to associate the service instance with the 1
traffic channel. 2
g. The BS sends an A9-Setup-A8 message to the PCF to establish an A8 (User Traffic) 3
connection between the BS and the PCF. The BS then starts timer T
A8-setup
. 4
h. A11 accounting procedures take place on the A11 interface. 5
i. The PCF responds with an A9-Connect-A8 message to complete the setup of the A8 6
(User Traffic) connection for this packet service request. Upon receipt of the A9- 7
Connect-A8 message from the PCF, the BS stops timer T
A8-setup
. 8
j. The BS sends an Assignment Complete message to the MSC. The MSC stops timer 9
T
10
. This step may occur anytime after step f. 10
3.18.3.2 Network Initiated PDSI Re-Activation from Dormant State, MS is Active with a 11
Concurrent Voice Service (and Dormant Packet Data Session) and has 12
Performed an Inter-BS/Intra-PCF Voice Call Handoff 13
The following call flow provides an illustration of a successful packet data service 14
instance reactivation procedure for the case where an MS is active with a concurrent 15
voice service and has performed an inter-BS/intra-PCF voice call handoff. 16
TIA-2001.3-C
Section 3 216

k
Comment
MS
Time
a
b
c
d
e
f
g
h
i
A9-Setup-A8
A9-Connect-A8
Assignment Complete
TA8-Setup
T10
Voice Active, Packet Dormant, PPP connection is maintained
Packet Data Traffic
BS Service Request
BS Service Response
Source
BS
MSC/ VLR PDSN PCF
Tbsreq9
T311
Target
BS
Assignment Request
T314 T303
l
j
Service
negotiation
procedures
A11 Accounting
Procedures
m
1
Figure 3.18.3.2-1 Network Initiated PDSI Re-Activation from Dormant State, MS is Active with a 2
Concurrent Voice Service (and Dormant Packet Data Session) and Has Performed an Inter- 3
BS/Intra-PCF Voice Call Handoff 4
a. The PDSN sends data packets to the PCF on an existing PPP connection and A10 5
connection associated with a specific MS and packet data service instance. 6
b. The PCF sends an A9-BS Service Request message containing the SR_ID of a 7
dormant packet data service instance to the source BS to request reactivation of that 8
bsreq9
. 9
c. The source BS sends a BS Service Request message to the MSC and starts timer 10
T
311
. The BS Service Request message contains the SR_ID of the service instance to 11
be reactivated. 12
Note: Because the MS was involved in an intra-PCF voice call handoff, the source 13
BS sends a BS Service Request message to the MSC for the MSC to indicate to the 14
target BS the need for an Additional Service Request message, to initiate an MS 15
terminated call setup. 16
d. The MSC recognizes that the MS has performed a voice call hand off to the target 17
BS and sends a BS Service Response message to the source BS. 18
e. The source BS responds with A9-BS Service Response message to the PCF. The 19
PCF stops timer T
bsreq9
TIA-2001.3-C
217 Section 3
f. The MSC sends an Additional Service Notification message to the target BS to 1
initiate an additional service option connection and starts timer T
314
. 2
g. The target BS sends an Additional Service Request message to the MSC and starts 3
timer T
303
. The MSC stops timer T
314
upon receipt of the Additional Service 4
Request message from the target BS. 5
h. The MSC sends an Assignment Request message to the target BS to request 6
assignment of radio resources. The Assignment Request message contains the SR_ID 7
of the packet data service instance to be reactivated. The MSC starts timer T
10
. 8
Upon receipt of the Assignment Request message from the MSC, the target BS stops 9
timer T
303
. 10
i. Service negotiation procedures take place to associate the service instance with the 11
traffic channel. 12
j. The target BS sends an A9-Setup-A8 message to the PCF to establish an A8 (User 13
Traffic) connection between target BS and the PCF. The target BS starts timer T
A8-
14
setup
. 15
k. A11 accounting procedures takes place on the A11 interface 16
l. The PCF responds with an A9-Connect-A8 message to complete the setup of the A8 17
(User Traffic) connection for the packet data service instance reactivation request. 18
Upon receipt of the A9-Connect-A8 message from the PCF, the target BS stops timer 19
T
A8-setup
. 20
m. After the radio link and the A8 connection have been established, the target BS sends 21
an Assignment Complete message to the MSC. The MSC stops timer T
10
. 22
3.18.3.3 Network Initiated Service Instance Reactivation When There is Another Active 23
Packet Data Service Instance and MS is Already Active with a Voice Service 24
This section describes the call flow for network initiated reactivation of a packet data 25
service instance from the Dormant State when the MS already has an active packet data 26
service session and is engaged in an active voice call. 27
The steps of this call flow are essentially the same as the call flow in section 3.17.4.7.2 28
with the exception that voice service is active. 29
3.18.4 Concurrent Services: Call Clearing Examples 30
3.18.4.1 Call Clear via Service Release MS Initiated 31
This section describes the call flow associated with a single service instance release 32
initiated by the MS when a circuit switched (voice or data) service option connection and 33
one or more active packet data service instances exist in the system. 34
When the MS initiates a normal clearing of a single service that is not the only service 35
connected, the MS sends one of the Service Request Message (SRQM), Resource Release 36
Request Message (RRRM) or Resource Release Request Mini Message (RRRMM). The 37
BS shall send a Service Release message to the MSC and start timer T
308
to wait for the 38
Service Release Complete message from the MSC. 39
TIA-2001.3-C
Section 3 218

MS MSC
time comment
SreqM/RRRM/RRRMM
a
b
c
d
Service Release
Service Release Complete
T308
BS
Service
negotiation
procedures
Conditional
Conditional
1
Figure 3.18.4.1-1 Releasing a Service That Is Not the Only One Connected (MS Initiated) 2
a. The MS sends either the Service Request Message, Resource Release Request 3
Message or Resource Release Request Mini Message (RRRMM) to release either the 4
circuit voice service option or an active packet data service option. If a packet data 5
service option is being released, the MS uses the Purge Indicator in the Resource 6
Release Request Message / Mini Message to indicate whether the associated packet 7
data service instance is being released to the Null State or to the Dormant State. 8
b. If either the circuit voice service instance or the last active packet data service 9
instance is being released, the BS sends a Service Release message to the MSC to 10
clear the call control transaction associated with the service. The BS starts timer 11
T
308
. 12
c. If the BS sent a Service Release message in step b, upon receiving the Service 13
Release Message from the BS, the MSC releases the service option connection 14
identifier, the terrestrial circuit (if allocated for the associated service), and sends a 15
Service Release Complete Message to the BS. Upon receipt of the Service Release 16
Complete Message, the BS stops Timer T
308
. 17
d. If the BS sent a Service Release message in step b, it shall wait for the associated 18
Service Release Complete message (step c), before it proceeds with this step. 19
Service negotiation procedures take place to dissociate the service instance from the 20
traffic channel. In the case of a packet data service instance release, refer to section 21
3.17.4.3.2 (release to Dormant State) or 3.17.4.17.2 (release to Null State) for the 22
procedures associated with the release of this service. 23
3.18.4.2 Call Clear via Service Release - MSC Initiated 24
This section describes the call flow associated with a circuit switched voice or a packet 25
data service option connection release initiated by the MSC when a circuit voice service 26
option connection and one or more active packet data service instances exist in the 27
system. If the MSC releases a packet data service option connection, the BS releases the 28
associated packet data session to the Null/Inactive State. 29
TIA-2001.3-C
219 Section 3

MS MSC
time comment
a
b
c
Service Release
T308
BS
Service
Negotiation
PCF PDSN
A9-Release-A8
A10 Connection
Release procedures
T
rel9

d
e
f
1
Figure 3.18.4.2-1 Releasing a Service That Is Not the Only One Connected (MSC Initiated) 2
a. The MSC sends a Service Release message to the BS to instruct the BS to release the 3
call control transaction associated with either the circuit voice service option or with 4
the packet data service option and starts timer T
308
. In the case of packet data service 5
option release the packet data session is released to Null State (i.e. all packet data 6
service instances are released). 7
b. The MS and the BS perform service negotiation procedures. 8
9
In the case of a circuit voice service option connection release, the following three 10
steps (steps c, d, and e) are skipped and the call flow continues with step f. 11
c. The BS sends an A9-Release-A8 message with a cause value set to Packet data 12
session release to the PCF to instruct the PCF to release the dedicated resources 13
BS starts timer T
rel9
. 17
d. The PCF initiates the procedure for releasing all A10 connections. Refer to section 18
e. The PCF sends an A9-Release-A8 Complete message to the BS. The BS stops timer 20
T
rel9
f. The BS releases the service option connection identifier, the terrestrial circuit (if 22
allocated for the associated service), and sends a Service Release Complete message 23
to the MSC. Upon receipt of the Service Release Complete, the MSC stops timer 24
T
308
. 25
TIA-2001.3-C
Section 3 220
3.18.4.3 PDSN Initiated Service Instance Release, Voice Service is Active 1
This section describes the call flows associated with a PDSN initiated packet service 2
instance release to Null State while the MS is engaged in a voice call. The section 3
considers the cases when: 4
i. Service instance to be released is dormant 5
ii. Service instance to be released is active and there is at least one other active packet 6
data service instance 7
iii. Service instance to be released is the only active packet data service instance. 8
The case i call flow is the same as that in section 3.17.4.5.1 with the exception that the 9
voice service is active at the beginning and end of the call flow. 10
The case ii call flow is the same as that in section 3.17.4.5.2 with the exception that the 11
voice service is active at the beginning and end of the call flow. 12
The case iii call flow is shown in this section. 13
3.18.4.3.1 PDSN Initiated Release of Last Active Packet Data Service Instance, Voice 14
Service is Active 15

=
Service Release
Time Comment
A9-Disconnect-A8
a
b
c
e
f
g
A9-Release-A8
A10 Connection
Release Procedure
Tdiscon9
Trel9
T300
Service
Negotiation
One Active Packet Data Service Instance, Voice Service Active
Dormant or Null Packet Data Session, Voice Service Active
d
16
Figure 3.18.4.3.1-1 PDSN Initiated Service Release of the Last Active Packet Data Service 17
Instance Voice Service Active 18
TIA-2001.3-C
221 Section 3
a. The PDSN releases the A10 connection for the active packet data service instance. 1
Refer to section 3.17.5.4.. The PCF sends the All-Dormant Indicator to the PDSN 2
that is part of this release procedure. 3
b. When the PCF recognizes that the A10 connection has been released, the PCF sends 4
an A9-Disconnect-A8 message to the BS and starts timer T
discon9
. 5
rel9
discon9
. 7
Complete. The BS stops timer T
rel9
. 9
e. The BS the sends a Service Release message to the MSC and starts timer T
300
. This 10
message contains the cause value Normal release if the BS is aware of other 11
dormant packet data service instances. If no other dormant service instances exist the 12
message contains a cause element indicating PPP session closed by MS. 13
f. The MSC sends a Service Release Complete message to the BS to instruct the BS to 14
release the associated dedicated resources. The BS stops timer T
300
. 15
g. Service negotiation procedures take place. 16
3.18.4.4 BS Initiated Release to Dormant State of a Packet Data Service Instance, Voice 17
Service is Active 18
This section describes the call flow associated with a BS initiated packet service instance 19
deactivation (Active-to-Dormant State transition) while a circuit voice service is active. 20
This section considers the cases where: 21
i. There are two or more active packet data service instances 22
ii. There is only one active packet data service instance. 23
The case i call flow is the same as in section 3.17.4.2.2 with the exception that there 24
exists a circuit voice service. 25
The case ii call flow is shown in this section. 26
3.18.4.4.1 BS Initiated Release to Dormant State of Last Active Packet Data Service 27
Instance, Circuit Voice Service is Active 28
For this example, it is assumed that the packet data service instance(s) is/are not in inter- 29
BS soft/softer handoff prior to deactivation. 30
TIA-2001.3-C
Section 3 222

Service Release
A9-Release-A8
Time Comment
Active Packet Data Session connected, Voice Service Active a
b
c
d
e
g
h
T
308

T
rel9

Service
Negotiation
A11
Accounting
Update
Procedures
f
Dormant Packet Data Session, Voice Service Active
1
Figure 3.18.4.4.1-1 BS Initiated Service Instance Release to Dormant State of Last Active 2
Packet Data Service Instance, Voice Service Active 3
a. The MS has an active packet data session and a circuit voice call. 4
b. If the packet data inactivity timer expires, the BS should renegotiate the Traffic 5
Channel. The BS sends a Service Release message to the MSC to initiate the call 6
clear transaction and starts timer T
308
. 7
c. The MSC sends a Service Release Complete message to the BS to instruct the BS to 8
release the associated dedicated resources. The BS stops timer T
308
. 9
d. The BS initiates service negotiation to release the active packet data service instance. 10
e. The BS then sends an A9-Release-A8 message to the PCF to instruct the PCF to 11
release the associated dedicated resources, and starts timer T
rel9
. Note that in this 12
scenario the A10 connection is not released. 13
f The PCF sends an A11-Registration Request message with an Active Stop airlink 14
accounting record for the released service instance and an All Dormant indicator, 15
which the PDSN acknowledges with an A11-Registration Reply message. 16
rel9
. 18
h. At this point, the packet data session is considered to be in the Dormant State. 19
TIA-2001.3-C
223 Section 3
3.18.5 Concurrent Service - Handoff 1
This section describes the handoff call flows for concurrent service. 2
3.18.5.1 Concurrent Service (Active Voice and Packet Data Services) - Hard Handoff 3
This section describes call flows for the successful hard handoff of an MS that is engaged 4
in active voice and packet data calls simultaneously. 5
3.18.5.1.1 Successful Inter-BS Hard Handoff Call Flows (Within the Same PCF) 6
The call flows in this section are identical to the call flows described in section 3.17.4.14, 7
except that in this case an active voice call is also present and the target BS sends the 8
Handoff Complete message after acquiring the MS, rather than after receiving the A9-AL 9
Connected Ack message from the PCF. 10
3.18.5.1.2 Successful Inter-PCF Hard Handoff Call Flows (Mobile Served by the Same 11
PDSN) 12
The call flows in this section are identical to the call flows described in section 3.17.4.15 13
and section 3.17.5.10, except that in this case an active voice call is also present and the 14
target BS sends the Handoff Complete message after acquiring the MS, rather than after 15
receiving the A9-AL Connected Ack message from the PCF. 16
3.18.5.1.3 Successful Inter-PCF Hard Handoff Call Flows (Mobile Served by New PDSN) 17
The call flows in this section are identical to the call flows described in section 3.17.5.11, 18
except that in this case an active voice call is also present and the target BS sends the 19
Handoff Complete message after acquiring the MS, rather than after receiving the A9-AL 20
Connected Ack message from the PCF. 21
3.18.5.2 Concurrent Service (Active Voice and Dormant Packet Data Services) - Handoff 22
This section describes call flows for the successful handoff of an MS that is engaged in 23
an active voice call and has a dormant packet data session. 24
3.18.5.2.1 Successful Inter-PCF Handoff Call Flows (Mobile Served by the Same PDSN) 25
This section describes the call flows for the successful handoff between PCFs being 26
served by the same PDSN of an MS that is engaged in an active voice call and has a 27
dormant packet data session. It is assumed that the PCFs are in different packet zones, 28
and that the call is not in inter-BS soft/softer handoff prior to the hard handoff, and thus 29
no A3 connections need to be removed. 30
TIA-2001.3-C
Section 3 224
Active Voice Session, Dormant Packet Data Session
Active Voice Service
Handoff b
a
Time Comment
d
e
f
g
h
i PDSN Dormant HO
j
k
l
MS
Source BS Target BS MSC
Source
PCF
Target
PCF
PDSN
BS Ack Order
Assignment Request
T303
A9-Setup-A8
TA8-setup
Assignment Failure
T10
Service Release
Service Release
l
T20
T308
m
n
In Traffic SystemParameter
Active Voice Session, Dormant Packet Data Session
c
1
Figure 3.18.5.2.1-1 Successful Inter-PCF Handoff (Mobile Served by the Same PDSN) 2
a. The MS currently has a voice call active and a packet data session that is dormant. 3
Based on an MS report that it crossed a network specified threshold for signal 4
strength or for other reasons, the source BS recommends a hard handoff to one or 5
more cells in the domain of the target BS. 6
b. The voice service is handed off as shown in section 3.19.3.1.1. 7
c. The target BS, upon detecting that the MS has arrived from a different packet zone, 8
sends an In-Traffic System Parameter Message to the MS indicating the current 9
TIA-2001.3-C
225 Section 3
packet zone (CANID). The MS may acknowledge the In-Traffic System Parameter 1
Message by sending an MS Ack Order to the target BS. 2
d. The MS detects a change in packet zone and sends an Enhanced Origination 3
Message to the target BS with DRS bit set to 0 for each of its dormant packet data 4
service instances. Steps d through m are repeated for each dormant packet data 5
service instance. 6
e. The target BS acknowledges receipt of each Enhanced Origination Message by 7
f. The target BS sends an Additional Service Request message to the MSC and starts 9
timer T
303
. Note this step only occurs if there is no active packet data service 10
instance at the time the BS receives the Enhanced Origination Message. 11
g. The MSC sends an Assignment Request message to the target BS and starts timer 12
T
10
. Upon receipt of the Assignment Request message, the target BS stops timer 13
T
303
. 14
h. For each service instance, the target BS sends an A9-Setup-A8 message, with Data 15
Ready Indicator set to 0, to the PCF and starts an associated timer T
A8-setup
. The 16
handoff indicator of the A9 Indicators IE shall be set to 0. 17
i. For each service instance, the target PCF establishes an A10 link and the PDSN 18
disconnects the old A10 link (refer to procedure in 3.17.5.10). (If the PDSN has data 19
for the MS on an A10 connection, it responds to the PCF with an A11-Registration 20
Reply message with the Data Available Indicator in the CVSE.) 21
j. For each service instance, the PCF responds to the BS with an A9-Release-A8 22
Complete message. The BS stops the associated timer T
A8-setup
. 23
If the PDSN responds to the PCF with a Data Available Indicator for any of the 24
service instances, the PCF responds to the BS with an A9-Connect-A8 message with 25
cause element set to Data ready to send. In this case, the target BS may send a Call 26
Assignment Message to the MS to initiate activation of the packet data service 27
instance. The target BS sends a handoff direction message
1
to the MS to invoke the 28
additional packet data service option. After Service Negotiation, the MS responds 29
with a Service Connect Completion Message. In this case, the remaining steps in this 30
scenario are ignored. 31
k. The BS sends an Assignment Failure message to the MSC with cause value 32
indicating Packet call going dormant and starts associated timer T
20
. The MSC 33
stops timer T
10
associated with the transaction. 34
l. The MSC sends a Service Release message to the target BS with cause value set to 35
Packet call going dormant and starts timer T
308
. 36
m. The target BS sends a Service Release Complete message to the MSC. 37
n. Upon receipt of the Service Release Complete message, the MSC stops timer T
308
. 38
The circuit voice call is now active, and the packet data session is dormant. 39

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.
TIA-2001.3-C
Section 3 226
3.18.5.2.2 Successful Inter-PCF Handoff Call Flow (Mobile Served by New PDSN) 1
This section describes the call flows for the successful handoff between PCFs being 2
served by different PDSNs of an MS that is engaged in an active voice call and has a 3
dormant packet data session. It is assumed that the PCFs are in different packet zones, 4
and that the call is not in inter-BS soft/softer handoff prior to the hard handoff, and thus 5
no A3 connections need to be removed. 6
TIA-2001.3-C
227 Section 3
Active voice service, dormant packet data session
Active voice service handoff
In Traffic SystemParameter Message
a
b
Time Comment
c
d
e
f
g
h
i
A10 Connection
Establishment
j
k
l
MS
Source BS
Target BS
MSC
Source
PCF
Target
PCF
PDSN
BS Ack Order
Assignment Request
T303
A9-Setup-A8
TA8-Setup
A9-Connect-A8
T10
Assignment Complete
Service Negotiation
Establish PPP connection
m
1
Figure 3.18.5.2.2-1 Successful Inter-PCF Handoff (Mobile Served by New PDSN) 2
a. The MS currently has a voice call active and a packet data session that is dormant. 3
Based on an MS report that it crossed a network specified threshold for signal 4
TIA-2001.3-C
Section 3 228
more cells in the domain of the target BS. 2
b. The voice service is handed off as shown in section 3.19.3.1.1. 3
c. The target BS, upon detecting that the MS has arrived from a different packet zone, 4
sends an In-Traffic System Parameter Message to the MS indicating the current 5
packet zone (CANID). The MS may acknowledge the In-Traffic System Parameter 6
Message by sending an MS Ack Order to the target BS. 7
d. The MS detects a change in packet zone and sends an Enhanced Origination 8
Message to the target BS with DRS bit set to 0 for each of its dormant service 9
instances. 10
e. The target BS acknowledges receipt of each Enhanced Origination Message by 11
f. The target BS sends an Additional Service Request message to the MSC and starts 13
timer T
303
. 14
g. The MSC sends an Assignment Request message to the target BS and starts timer 15
T
10
. Upon receipt or the Assignment Request message, the target BS stops timer 16
T
303
. Note this step only occurs if there is no active packet data service instance at 17
the time the BS receives the Enhanced Origination Message. 18
h. For each service instance, the target BS sends an A9-Setup-A8 message, with Data 19
Ready Indicator set to 0, to the PCF and starts an associated timer T
A8-setup
. The 20
handoff indicator of the A9 Indicators IE shall be set to 0. 21
i. For each service instance, the target PCF establishes an A10 link with the new PDSN 22
(refer to procedure in 3.17.5.11). In this scenario, for at least one service instance, 23
the PDSN responds to the PCF with an A11-Registration Reply message with the 24
Data Available Indicator in the CVSE. Note: if the PDSN does not respond with a 25
Data Available Indicator, steps j through m of call flow 3.18.5.2.1 occur and the 26
remaining steps of this call flow do not apply. 27
j. For each service instance for which the PDSN indicated data available, the target 28
PCF sends an A9-Connect-A8 message with Traffic Channel Required indicator set 29
to the target BS. For each service instance for which the PDSN did not indicate data 30
available, the target PCF sends an A9-Release-A8 Complete message to the target 31
BS. The target BS stops the associated timer(s) T
A8-setup
. 32
k. The target BS and the MS engage in over the air service negotiation to connect the 33
packet data service instances for which the PDSN indicated data available. 34
l. Upon establishment of the A8 and A10 connections and service negotiation, the 35
target BS sends an Assignment Complete message to the MSC. The MSC stops timer 36
T
10
. 37
m. Establishment of the PPP connection between the MS and PDSN is now possible 38
over the main service instance. Mobile IP Registration may be performed once the 39
PPP link has been established. Following MIP registration (if required), if neither the 40
MS nor the PDSN has data to send, the packet data service instance may again 41
transition to dormant (refer to section 3.17.4.3). 42
3.18.5.3 Concurrent Service - Soft / Softer Handoff 43
The same procedures as in section 3.19.2 apply for this scenario. 44
TIA-2001.3-C
229 Section 3
3.19 Handoff 1
Inter-BS hard handoffs are discussed in section 3.19.1.2 (Inter-BS Hard Handoff), and 2
intra-BS handoffs are discussed in section 3.19.1.5 (Intra-BS Handoff). Multi-carrier 3
(MC) inter-BS soft/softer handoff is discussed in section 3.19.2 (Handoff via Direct BS- 4
to-BS Signaling). Call flows for each of these procedures can be found in section 3.19.3 5
(Handoff Call Flows). Message formats and definitions of timers used within this chapter 6
can be found in the associated interface documents. 7
3.19.1 Handoff via MSC 8
3.19.1.1 Introduction 9
This section describes handoff via the MSC procedures; refer to section 2.19.1 and [32] 10
for more information. 11
3.19.1.1.1 Recognition That a Handoff is Required by a BS 12
The BS shall be able to generate an indication to the MSC that a hard handoff may be 13
required using the protocols defined. 14
No additional guidance is given within this specification concerning the algorithm within 15
the BS that generates either an intra-BS handoff, or an indication to the MSC that an 16
inter-BS hard handoff is required. 17
3.19.1.1.2 Recognition That a Handoff is Required by the MSC 18
For this version of the standard, the MSC may not autonomously precipitate a handoff. 19
3.19.1.1.3 Concept of Designated Cell 20
A designated cell is a cell identifier (cell + sector) that is chosen by the BS to represent 21
the MSs location. The initial cell identifier associated with the MSs activity 22
(origination, termination, etc.) is by definition the first designated cell. When the air 23
interface only supports connection of the MS to a single sector at a time, the designated 24
cell is the currently connected sector. When the air interface supports connection of an 25
MS to multiple sectors (possibly on different cells) simultaneously, e.g., CDMA 26
soft/softer handoff, a single designated cell is to be identified to the MSC. 27
As long as the original cell identifier that was provided to the MSC to identify the initial 28
designated cell remains on the call, it may remain the designated cell. When the 29
sector identified as the designated cell is removed from the call, the BS currently 30
serving as the source BS for the call chooses a new designated cell from the set of 31
sectors serving the call and shall provide the appropriate cell identifier to the MSC. The 32
source BS may choose a new designated cell at any time from the set of cells currently 33
serving the call. The technique for choosing a designated cell is an 34
operator/manufacturer concern. 35
The notification to the MSC can be implicit through the use of the inter-BS handoff 36
procedure (Handoff Required, Handoff Request, Handoff Request Acknowledge, 37
Handoff Command messages), or explicit through the use of the Handoff Performed 38
message. The implicit notification occurs when the handoff type is a hard handoff. The 39
change of designated cell occurs upon receipt of the Handoff Complete message. 40
TIA-2001.3-C
Section 3 230
3.19.1.2 Inter-BS Hard Handoff 1
This section discusses the protocol to support hard handoff transitions where the source 2
and target cells are under the domain of different BSs. For this version of the standard, it 3
is assumed that the only CDMA traffic channels that may be transferred via inter-BS hard 4
handoff are the Fundamental and Dedicated Control Channels (FCH and DCCH, resp.). 5
Hard handoff of the Supplemental Channel is not supported in this version of the 6
standard. 7
For an MS operating on the CDMA traffic channel, an inter-BS hard handoff may occur 8
while the MS is in the Conversation State or Waiting for Answer State. All connected 9
services that are handed off shall be handed off together to the same BS. 10
3.19.1.2.1 Triggering Phase 11
Hard handoff triggering is initiated by the MS or the source BS. 12
3.19.1.2.2 Target Determination Phase 13
Having received an indication from a BS that an inter-BS hard handoff is required, the 14
decision of when and whether an inter-BS hard handoff is to take place shall be made by 15
the MSC. Inter-BS soft/softer handoff decisions can be made by the source and target 16
BSs involved; refer to section 3.19.2 (Handoff via Direct BS-to-BS Signaling). 17
The Handoff Required message is used for this phase of the handoff; refer to [14] for 18
procedure descriptions of this message. 19
3.19.1.2.3 Resource Establishment 20
When the MSC has decided that an inter-BS hard handoff shall take place, the MSC 21
requests resources from the target BS. 22
The following A1 interface messages are used for this phase of the handoff: 23
Handoff Request 24
Handoff Request Acknowledge 25
Refer to [14] for procedure descriptions of these messages. 26
3.19.1.2.4 Execution Phase 27
When MSC receives information from the target BS that resources have been established 28
in the target BS, the MSC requests the source BS to execute the handoff. The MSC 29
receives information from the target BS when the handoff is completed. 30
The following A1 interface messages are used for this phase of the handoff: 31
Handoff Command 32
Handoff Commenced 33
Handoff Complete 34
TIA-2001.3-C
231 Section 3
3.19.1.3 Call Clearing 1
The call clearing procedure is described in section 3.2. It is used in hard handoff 2
scenarios to release the source RF channel and terrestrial resource after either the MS has 3
been acquired by the target BS or the call is dropped. 4
The MSC may use call clearing to tear down either the source channel, the target channel, 5
or both in the event of a failure in the handoff process. 6
The Clear Command message shall contain a cause field to inform the source or target 7
cell of the success or failure of the handoff procedure. This indication can be used for 8
statistics purposes. 9
3.19.1.4 Handoff Failure Handling 10
There are two messages that indicate a failure in the handoff process: the Handoff 11
Required Reject and the Handoff Failure messages. These messages are defined in [14]. 12
Also, refer to section 3.19.3.1.4 (Hard Handoff With Return On Failure). 13
When a traffic channel is not available at the target BS, several options are available: 14
Option 1 The target can allocate an AMPS channel 15
Option 2 The target can indicate a failure to the MSC, and the MSC can attempt 16
to allocate an AMPS channel. 17
Option 3 The target can indicate a failure and the MSC can pass this information 18
to the source BS and let the source BS decide. 19
Option 3 shall be supported. 20
NOTE: This standard does not specify the messaging required for Option 1. Support and 21
implementation of this option is a vendor concern. 22
Handoff Failure Handling utilizes the following A1 interface messages: 23
Handoff Required Reject 24
Handoff Failure 25
3.19.1.5 Intra-BS Handoff 27
The BS uses the Handoff Performed message to inform the MSC of handoff operations. 28
Refer to [14] for procedure descriptions of this message. 29
3.19.2 Handoff via Direct BS-to-BS Signaling 30
This section describes handoff via direct BS-to-BS signaling. 31
3.19.2.1 A3 Interface Messages 32
This section lists the messages that are used to support handoff on the A3 interface. The 33
A3 messages are organized into three categories: 34
A3 Interface Setup Messages, 35
A3-Connect 36
TIA-2001.3-C
Section 3 232
A3-Connect Ack 1
A3 Interface Operational Messages, 2
A3-Physical Transition Directive 3
A3-Physical Transition Directive Ack 4
A3-Propagation Delay Measurement Report 5
A3-IS-95 FCH Forward 6
A3-IS-95 FCH Reverse 7
A3-Traffic Channel Status 8
A3-IS-2000 FCH Forward 9
A3-IS-2000 FCH Reverse 10
A3-IS-2000 DCCH Forward 11
A3-IS-2000 DCCH Reverse 12
A3-IS-2000 SCH Forward 13
A3-IS-2000 SCH Reverse 14
A3-FCH Forward Traffic Frame 15
A3-FCH Reverse Traffic Frame 16
A3-DCCH Forward Traffic Frame 17
A3-DCCH Reverse Traffic Frame 18
A3-SCH Reverse Traffic Frame 19
A3 Interface Clearing Messages, 20
A3-Remove 21
A3-Remove Ack 22
A3-Drop 23
For descriptions of the messages and their procedures, refer to [15].. 24
3.19.2.2 A7 Interface Messages 25
This section describes the messages used between base stations on an A7 connection to 26
support direct BS to BS soft/softer handoff, access handoff, access probe handoff, and 27
channel assignment into soft/softer handoff. These messages are: 28
A7-Handoff Request 29
A7-Handoff Request Ack 30
A7-Drop Target 31
A7-Drop Target Ack 32
A7-Target Removal Request 33
A7-Target Removal Response 34
A7-Paging Channel Message Transfer 35
A7-Paging Channel Message Transfer Ack 36
A7-Access Channel Message Transfer 37
A7-Access Channel Message Transfer Ack 38
A7-Burst Request 39
TIA-2001.3-C
233 Section 3
A7-Burst Response 1
A7-Burst Commit 2
A7-Burst Release 3
For descriptions of the messages and their procedures, refer to [15]. 4
3.19.2.3 Soft/Softer Handoff Addition 5
The source BS decides what cells are to be added to a call in soft/softer handoff. An A7- 6
Handoff Request message is sent directly to the target BS across the A7 connection 7
between the source and target BSs to request the addition of those cells to the call. The 8
target BS allocates and connects the appropriate resources and responds directly to the 9
source BS using an A7-Handoff Request Ack message once all expected A3-Connect 10
Ack messages have been received. 11
The A3-Connect message is used by the target BS to both create new A3 connections for 12
a call and to add cells to existing A3 connections. In either case, information on all cells 13
attached to the A3 connection shall be included in the A3 Connect Information IE, and 14
there shall be an indication as to which cells were already existing and which cells were 15
newly associated with the A3 connection. 16
The A3-Connect message can be used to establish multiple A3 connections. To support 17
this capability, multiple sets of cell information may be included. A single A3-Connect 18
Ack message is used to respond to an A3-Connect message, regardless of the number of 19
A3 connections being established via the A3-Connect message. The A3-Connect Ack 20
message is returned to the address from which the A3-Connect message was sent. 21
In response to an A7-Handoff Request message that includes multiple cells to be added to 22
the call association in soft or softer handoff, the target BS may send a single A3-Connect 23
message including information for multiple connections, or it may send multiple A3- 24
Connect messages where each message includes information for a single connection only. 25
However, the target BS shall not send multiple A3-Connect messages that each include 26
multiple connection information, nor any combination of such messages and A3-Connect 27
messages that include information for a single connection. 28
The A3-Connect Ack and A3-Traffic Channel Status messages support the ability of the 29
source BS to request that the target BS send a notification that the target BS transmitter(s) 30
and receiver(s) are turned on. 31
3.19.2.4 Soft/Softer Handoff Removal 32
Removal of cells in soft/softer handoff involves the sending by the source BS of an A7- 33
Drop Target message to the target BS. The target BS removes the indicated cells and 34
responds with an A7-Drop Target Ack message. If the last cell(s) attached to a particular 35
A3 connection are removed, the target BS also initiates removal of that A3 connection. 36
3.19.2.5 Cell Removal by a Target BS 37
For a variety of reasons, a target BS may need to request that one or more of its cells be 38
removed from a call. This request can be for reasons of internal resource management, 39
OA&M, internal BS error situations, etc. The target BS, in these cases, sends an A7- 40
Target Removal Request message to the source BS with appropriate information to 41
indicate what cells need to be removed from the call, and for what reason(s). The source 42
BS takes the appropriate actions and responds with an A7-Target Removal Response 43
TIA-2001.3-C
Section 3 234
message; the source BS may also indicate to the target BS that the target cell(s) are to 1
remain in the call. 2
3.19.2.6 Call Clearing 3
Call clearing for calls using packet based soft/softer handoff is always accomplished via 4
the source BS. If the call clearing is initiated by either the MS or source BS, a Clear 5
Request message is sent to the MSC to request call clearing. If the MSC initiates the call 6
clearing, it sends a Clear Command message to the source BS. Clear Command messages 7
are not sent to target BSs involved in the call. Instead, the source BS is responsible for 8
using the A7 interface drop target procedure to remove all target BSs from the call. 9
When the A7 interface drop target procedure is used during call release scenarios, the A7 10
Drop Target message shall contain the cell identify list with no cells included. In this 11
case, the source should wait some period of time to allow any in progress adds or drops to 12
complete prior to sending the A7 Drop Target message. 13
3.19.2.7 Handoff Performed 14
The source BS is responsible for sending Handoff Performed messages to the MSC to 15
keep it informed of the identity of the cells currently involved in supporting the call. 16
Refer to section 3.19.1.1.3 Concept of Designated Cell and [14]. 17
3.19.2.8 Access Handoff and Channel Assignment into Soft Handoff 18
In addition to setting up soft handoff legs during a call, the soft handoff legs can also be 19
set up during the establishment of the call. This procedure is required to support access 20
probe handoff, access handoff, and channel assignment into soft/softer handoff. 21
The source BS decides what cells are to be set up in soft/softer handoff during the 22
establishment of the call and the A7-Handoff Request procedure is used. That is, an A7- 23
Handoff Request message is sent directly to the target BSs across the A7 connection 24
between the source and target BSs to request the setup of those cells to the call. Each 25
target BS allocates and connects the appropriate resources and responds directly to the 26
source BS using an A7-Handoff Request Ack message once all expected A3-Connect 27
Ack messages have been received. 28
Cells that are likely candidates for access probe handoff and access handoff by the MS 29
are included in the ACCESS_HO_LIST. 30
For each message received on one of its Access Channels, the BS shall analyze the 31
PILOT_RECORD if such a record is included in the message. If the BS does not 32
correspond to the first attempted pilot in the record (i.e., is not the source BS), then it 33
shall forward the Access Channel message on an inter-BS (i.e., A7) link corresponding to 34
the first attempted pilot in the record. If the Access Channel message is an Origination or 35
Page Response, the BS shall forward the message as indicated above and shall not send 36
the corresponding CM Service Request message or Paging Response message to the 37
MSC. 38
The source BS sends A7-Paging Channel Message Transfer messages carrying 39
appropriate channel assignment information to selected BSs, usually chosen from those 40
contained in the ACCESS_HO_LIST and OTHER_REPORTED_LIST, requesting that 41
they send the Channel Assignment Message on specific cells. The Channel Assignment 42
Message is used to assign the forward channel(s) to the MS. 43
TIA-2001.3-C
235 Section 3
The set of BSs to which the source BS sends the A7-Paging Channel Message Transfer 1
message may be different from the set of BSs that are set up in soft handoff. 2
Refer to section 3.1.2.2 for an example scenario showing access probe handoff, access 3
handoff and channel assignment into soft/softer handoff. 4
Also refer to [15] for information on the A7-Paging Channel Message Transfer, A7- 5
Paging Channel Message Transfer Ack, A7-Access Channel Message Transfer, and A7- 6
Access Channel Message Transfer Ack messages. 7
3.19.2.9 Soft/Softer Handoff of High Speed Packet Data 8
Support of high speed packet data (i.e., speeds greater than 14.4 kbps) may be 9
accomplished through the use of multiple physical channels. These physical channels are 10
supported in the infrastructure using A3 traffic connections during soft/softer handoff. 11
Setup of an A3 connection for a traffic burst is accomplished using A7-Burst Request, 12
A7-Burst Response, A7-Burst Commit, and A7-Burst Release messages. Establishment 13
of the A3 connection for the Supplemental Channel (SCH) is accomplished via the A7- 14
Handoff Request, A7-Handoff Request Ack, A3-Connect and A3-Connect Ack messages. 15
In this version of this standard, it is assumed that any leg for a Supplemental Channel is 16
established on a cell that already supports a leg for the Fundamental Channel (FCH) or 17
the Dedicated Control Channel (DCCH) for the same MS. To minimize the time required 18
to establish a traffic burst, the A3 connection for an SCH is established on the target BS 19
at the transmission of the first data burst. When a leg is established for an SCH, only the 20
terrestrial resources are allocated, i.e., the A3 connection. This involves choosing the 21
traffic circuit to be used and establishing context between the target BS and the source 22
BS/SDU function. Allocation of radio resources for the SCH is made each time that a 23
traffic burst is set up. 24
When the source BS realizes that it is necessary to allocate radio resources for a traffic 25
burst in either the forward or reverse direction or both, it sends an A7-Burst Request 26
message to each target BS to request reservation of specific radio resources. Each target 27
BS responds with A7-Burst Response message(s) to indicate radio resource reservations 28
for the requested cells. Once the source BS has received the A7-Burst Response 29
messages, it sends either A7-Burst Commit or A7-Burst Release message(s) to each 30
target BS to indicate the set of radio resources to be used. A burst time that requires the 31
message to be pending for more than 7/8 of the modulo window in the future from its 32
time of arrival shall be considered late and the message shall be processed immediately. 33
End time shall still be calculated from the specified start time and duration. Each target 34
BS receiving an A7-Burst Commit message prepares the indicated cell, connects it to the 35
pre-established A3 connection, and then participates in the burst. Each target BS 36
receiving an A7-Burst Release message then releases the resources reserved at the 37
indicated cell(s). Both cases are shown in examples in section 3.19.3.2. 38
3.19.2.9.1 Soft/Softer Handoff of Forward Link Bursts of Data 39
When a traffic burst is scheduled to begin, the SDU function begins to transmit forward 40
link frames carrying user traffic on the A3 connection for the SCH. At the termination of 41
a traffic burst in the forward direction, the SDU function ceases transmitting frames on 42
the SCH A3 connection. The SDU function may begin to send idle frames on the forward 43
A3 connection prior to the beginning of the burst to allow synchronization of the A3 44
connection. If the target BS receives forward idle frames and is not receiving reverse 45
frames from the MS, it shall send reverse idle frames to the SDU function to allow packet 46
arrival time error adjustments to occur. 47
TIA-2001.3-C
Section 3 236
The SDU function shall send no more than 9144 bits (i.e., 3 frames of data for a burst at 1
153.6 KBPS) to the target BS prior to the beginning of a traffic burst in the forward 2
direction. 3
When a new traffic burst is initiated on an A3 connection for a SCH, the target BS shall 4
wait for the first forward link frame before transmitting any reverse link frames. If the 5
target BS receives a forward link Idle Frame, it shall calculate the packet arrival time 6
error and transmit that information on the reverse link in an Idle Frame if it has no user 7
traffic to transmit in a non-idle frame. The target BS shall not transmit any air interface 8
frame when receiving a forward link Idle Frame. In this way, the SDU function can 9
control precisely the beginning of forward link traffic bursts on physical channels. 10
The source BS may suppress (i.e., not transmit) an A3-IS-2000 SCH Forward message 11
with Forward Layer 3 Data elements containing Null or Idle frame contents. Refer to [15] 12
(IS-2000 Frame Content) for source and target operations with Null and Idle frames. 13
The target BS may suppress (i.e., not transmit) an A3-IS-2000 SCH Reverse message 14
with Reverse Layer 3 Data information elements containing Null or Idle frame contents 15
if, and only if, an A3-IS-2000 SCH Forward message was not received in the previous 16
air-frame period. Refer to [15] (IS-2000 Frame Content) for source and target operations 17
with Null and Idle frames. 18
3.19.2.9.2 Soft/Softer Handoff of Reverse Link Bursts of SCH Data 19
When a traffic burst is expected by a target BS, the target BS shall wait for the first 20
forward link frame so that the packet arrival time error can be correctly calculated. 21
Following the reception of each forward link frame at the target BS, the target BS shall 22
transmit a reverse link frame. Reverse link frames may contain user traffic (i.e., packet 23
data), Idle Frames, Null Frames, Re-Acquiring Frames, or Erasure Frames. Reverse link 24
frames containing user traffic, Re-Acquiring Frames, or Erasure frames (i.e., decoded 25
from the air interface) may be sent without prior reception of forward link frames. 26
The target BS shall decide whether Erasure Frames, Re-Acquired Frames, or Null Frames 27
should be sent to the SDU in the source BS in the cases of DTX or loss of finger lock. 28
3.19.3 Handoff Call Flows 29
Note: In the following call flows, the box marked MSC may represent one or two 30
MSCs. In the case of inter-MSC handoff, ANSI-41 signaling is not specified. 31
3.19.3.1 Hard Handoff via MSC Call Flows 32
33
3.19.3.1.1 Successful Hard Handoff 34
The following call flow provides an illustration for a successful hard handoff event. It is 35
assumed that the call is not in inter-BS soft/softer handoff prior to the hard handoff, and 36
thus no A3 connections need to be removed. 37
TIA-2001.3-C
237 Section 3

MS Source BS MSC
Time
Comment
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 Complete
T306
T315
Twaitho
x
T11
T8
1
Figure 3.19.3.1.1-1 Successful Hard Handoff 2
more cells in the domain of the target BS. The source BS sends a Handoff Required 5
message with the list of cells to the MSC and starts timer T
7
. 6
b. The MSC sends a Handoff Request message to the target BS with the IS-95 Channel 7
Identity element or the IS-2000 Channel Identity element present, based on if the 8
MSC proceeds with a CDMA-CDMA handoff attempt and the corresponding IS- 9
2000 or IS-95 Channel Identity element was present in the Handoff Required 10
message. 11
In the case of hard handoff for an async data/fax call, the Circuit Identity Code 12
Extension element in the Handoff Request message indicates the Circuit Identity 13
Code of the circuit to be connected to the SDU function at the target BS to support 14
the A5 connection to the IWF. 15
c. Upon receipt of the Handoff Request message from the MSC, the target BS allocates 16
appropriate radio resources as specified in the message and connects the call. As the 17
Handoff Request message can have multiple cell(s) specified, the target BS can also 18
choose to set up multiple cell(s) for the handoff request. The target BS sends null 19
forward traffic channel frames to the MS. 20
d. The target BS sends a Handoff Request Acknowledge message to the MSC and starts 21
timer T
9
to wait for arrival of the MS on its radio channel. The MSC stops timer T
11
22
upon the receipt of this message. The first cell in the cell identifier list element of the 23
message is treated as the new designated cell by the MSC. The change of designated 24
cell occurs upon receipt of the Handoff Complete message. If the service option 25
received in the Handoff Request message is not available at the target BS and the 26
TIA-2001.3-C
Section 3 238
target BS selected a different service option for the handoff then the target BS shall 1
include the service option it selected in the Service Configuration Record IE. 2
e. The MSC prepares to switch the MS from the source BS to the target BS and sends a 3
7
. The 4
MSC shall include in the Handoff Command message the IS-2000 Service 5
Configuration Record elements it received in the Handoff Request Ack message. 6
f. The source BS sends the handoff direction message
1
to the MS and starts timer T
8
. If 7
the MS is allowed to return to the source BS, timer T
waitho
is also started by the 8
source BS. 9
g. The MS may acknowledge the handoff direction message by sending an MS Ack 10
Order to the source BS. The source BS stops timer T
8
If the handoff direction message is sent using quick repeats, the source BS might not 12
request an acknowledgment from the MS. 13
h. The source BS sends a Handoff Commenced message to the MSC to notify it that the 14
T
306
waitho
has been 16
i. The MS sends reverse traffic channel frames or the traffic channel preamble to the 19
target cell(s). 20
j. The MS sends a Handoff Completion Message to the target BS. 21
k. The target BS sends the BS Ack Order to the MS over the air interface. 22
l. The target BS sends a Handoff Complete message to the MSC to notify it that the 23
MS has successfully completed the hard handoff. The target BS stops timer T
9
. 24
m. The MSC sends a Clear Command message to the source BS and starts timer T
315
. 25
306
. 26
27
n. The source BS sends a Clear Complete message to the MSC to notify it that clearing 28
315
. 29
3.19.3.1.2 Successful Hard Handoff to ANSI/TIA/EIA-553-A Systems 30
For the purpose of this specification, the single MSC in the following figure represents 31
the source and the target MSC connected by TIA/EIA IS-41. The message flows and 32
timers between the target MSC and the target BS in the figure are outside the scope of 33
this standard. 34
The following call flow provides an illustration for a successful hard handoff event to an 35
analog [18] system. 36

1
appropriate.
TIA-2001.3-C
239 Section 3

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
1
Figure 3.19.3.1.2-1 Successful Hard Handoff to an ANSI/TIA/EIA-553-A System 2
a. Based on an MS report that it has crossed a network specified threshold for signal 3
strength, the source BS recommends a hard handoff to one or more cells in the 4
Cell Identifier List to the source MSC to find a target with available resources and 6
starts timer T
7
. The source BS indicates a response requirement by including the 7
Response Request element. 8
b. The target MSC sends the equivalent of a Handoff Request message to the target BS 9
without the IS-95 Channel Identity or the IS-2000 Channel Identity element present, 10
since this is a CDMA to Analog hard handoff request. The MSC starts the equivalent 11
of timer T
11
. 12
c. The target BS determines that appropriate resources are available, sends the 13
equivalent of a Handoff Request Acknowledge message to the target MSC, and starts 14
the equivalent of timer T
9
. The MSC stops the equivalent of T
11
message. 16
d. The source MSC prepares to switch the MS from the source BS to the target BS and 17
sends a Handoff Command message to the source BS to convey information from the 18
target BS. The source BS stops timer T
7
e. The source BS transmits the Analog Handoff Direction Message to the MS and may 20
request a Layer 2 Ack. 21
f. The MS returns an MS Ack Order to the source BS to confirm receipt of the Analog 22
Handoff Direction Message. 23
If the handoff direction message is sent using quick repeats the source BS might not 24
request an acknowledgement from the MS. 25
g. The source BS sends a Handoff Commenced message to the source MSC to notify it 26
that the MS has been ordered to move to the target BS channel. The source BS starts 27
timer T
306
to await the Clear Command message from the source MSC. 28
TIA-2001.3-C
Section 3 240
h. The MS tunes to the target BS and initiates transmission of the transponded 1
Supervisory Audio Tone (SAT). The target BS stops the equivalent of timer T
9
. 2
i. Upon reception of the correct MS transponded SAT, the target BS sends the 3
equivalent of a Handoff Complete message to the target MSC to indicate that the MS 4
has successfully accessed the target BS. 5
j. The source MSC releases the source BSs terrestrial circuit and instructs the source 6
BS to release its radio resources by sending a Clear Command message to the source 7
BS with the cause element set to Handoff successful. The source MSC starts timer 8
T
315
. The source BS stops timer T
306
when the Clear Command message is received. 9
k. The source BS releases its source channel, clears any terrestrial resources, and 10
returns a Clear Complete message to the source MSC to indicate that the transition is 11
complete. The source MSC stops timer T
315
when the Clear Complete message is 12
received. 13
3.19.3.1.3 Unsuccessful Hard Handoff to ANSI/EIA/TIA-553: ANSI/TIA/EIA-553-A 14
Alternative Rejected 15
For the purpose of this specification, the single MSC in the following figure represents 16
the source and the target MSC connected by TIA/EIA IS-41. The message flows between 17
the target MSC and the target BS in the figure are informative and are not required. 18
The following call flow provides an illustration of an unsuccessful hard handoff. In this 19
example, the source BS determines that an ANSI/TIA/EIA-553-A alternative is not 20
acceptable, rejects the Handoff Command and maintains the MS. 21

MS MSC
time comment
a
b
c
d
e
f
g
Handoff Required
(Handoff Request)
Handoff Command
Handoff Failure
(Clear Command)
(Clear Complete)
T7
(T9)
T315
Source
BS
Target
BS
T11
22
Figure 3.19.3.1.3-1 Unsuccessful Hard Handoff to ANSI/EIA/TIA-553: ANSI/TIA/EIA-553-A 23
Alternative Rejected 24
a. Based on an MS report that it has crossed a network specified threshold for signal 25
strength, the source BS recommends a hard handoff to one or more cells in the 26
Cell Identifier List to the source MSC to find a target with available resources and 28
starts timer T
7
. The source BS indicates a response requirement by including the 29
Response Request element. 30
b. The target MSC sends the equivalent of a Handoff Request message to the target BS 31
without the IS-95 Channel Identity or the IS-2000 Channel Identity element present, 32
TIA-2001.3-C
241 Section 3
since this is a CDMA to Analog hard handoff request. The MSC starts the equivalent 1
of timer T
11
. 2
c. The target BS determines that a channel resource is not available and reserves or 3
allocates an ANSI/TIA/EIA-553-A channel. The target BS sends the equivalent of a 4
Handoff Request Acknowledge message to the target MSC informing it of the 5
availability of the ANSI/TIA/EIA-553-A channel and starts the equivalent of timer T
9
. 6
11
. 7
d. The source MSC sends a Handoff Command message to the source BS to convey 8
information from the target BS to the source BS. The source BS stops timer T
7
upon 9
receipt of this message. 10
e. Upon receipt of the Handoff Command message from the source MSC, the source 11
BS recognizes that an analog [18] channel has been supplied and decides to reject the 12
assignment. The source BS keeps the MS and sends a Handoff Failure message to 13
the source MSC with the cause element set to Alternate signaling type reject. 14
f. The target MSC releases the terrestrial circuit to the target BS, instructs the target BS 15
to release its radio resources by sending the equivalent a Clear Command message, 16
and starts the equivalent of timer T
315
. The target BS stops the equivalent of timer T
9
17
g. The target BS sends the equivalent of a Clear Complete message to the target MSC 19
to indicate that the resource release operation is complete. The MSC stops the 20
equivalent of timer T
315
3.19.3.1.4 Hard Handoff With Return On Failure 22
The following call flow provides an illustration for a hard handoff event. In this scenario, 23
the MS successfully returns to the source BS after hard handoff fails. It is assumed that 24
the call is not in inter-BS soft/softer handoff prior to the hard handoff, and thus no inter- 25
BS connections need to be removed. 26
TIA-2001.3-C
Section 3 242

MS Source BS MSC
Time
Comment
a
b
c
d
e
f
g
Handoff Required
Handoff Request
Handoff Command
handoff direction message
MS Ack Order
Target BS
Handoff Request Ack
T7
T9
h
i
j
k
Clear Command
Handoff Failure
CF Search Report Message
Clear Complete T315
Twaitho
T11
T8
1
Figure 3.19.3.1.4-1 Hard Handoff with Return On Failure 2
7
. 6
message. 11
appropriate radio resources as specified in the message and connects the terrestrial 17
circuit. The target BS sends null forward traffic channel frames to the MS. 18
d. The target BS sends a Handoff Request Acknowledgment message to the MSC and 19
starts timer T
9
to wait for arrival of the MS on its radio channel. The MSC stops 20
timer T
11
e. The MSC prepares to switch the MS from the source BS to the target BS and sends a 22
7
. 23
TIA-2001.3-C
243 Section 3
f. The source BS sends the handoff direction message
2
to the MS and starts timer T
8
. 1
The source BS indicates in the message that the MS is permitted to return to the 2
source BS if handoff to the target fails. The source BS starts timer T
waitho
. 3
g. The MS may acknowledge the handoff direction message by sending an MS Ack 4
8
h. The MS sends a Candidate Frequency (CF) Search Report Message to the source BS 8
after handoff to the target has failed. The source BS stops timer T
waitho
. 9
i. Upon receipt of the CF Search Report Message from the MS the source BS the 10
source BS realizes that the MS did not successfully access the target BS cell and 11
sends a Handoff Failure message to the MSC with the cause element set to 12
Reversion to old channel. 13
j. The MSC sends a Clear Command message to the target BS and starts timer T
315
. 14
9
k. The target BS releases and de-allocates the radio and terrestrial resources. The target 16
BS sends a Clear Complete message to the MSC to indicate that the resource release 17
operation is complete. The MSC stops timer T
315
3.19.3.1.5 Hard Handoff Failure 19
The following call flow provides an illustration for a hard handoff failure event. In this 20
scenario, the target BS notifies the MSC that the handoff has failed by sending a Handoff 21
Failure Message. It is assumed that the call is not in inter-BS soft/softer handoff prior to 22
the hard handoff, and thus no inter-BS connections need to be removed. 23
Source BS MSC
Time
Comment
a
b
c
d
Handoff Required
Handoff Request
Handoff Required Reject
Target BS
Handoff Failure
T7
T11
24
Figure 3.19.3.1.5-1 Hard Handoff Failure 25
7
. 29

2
appropriate.
TIA-2001.3-C
Section 3 244
message. 5
c. The target BS receives the Handoff Request message but is unable to accommodate 10
the handoff request. The target BS then sends a Handoff Failure message to the 11
MSC. 12
d. Upon receipt of the Handoff Failure message, the MSC stops timer T
11
. The MSC 13
then sends a Handoff Required Reject message to the source BS. Upon receipt of the 14
Handoff Required Reject message, the source BS stops timer T
7
. A new handoff 15
procedure may be initiated if the condition of the call connection warrants immediate 16
action. 17
3.19.3.2 Soft/Softer Handoff via Direct BS-to-BS Signaling Call Flows 18
19
3.19.3.2.1 Soft/Softer Handoff Addition 20
Soft/softer handoff addition occurs as shown in the following diagram. Soft/softer 21
handoff addition includes both the creation of new A3 traffic connections and the 22
addition of cells to existing A3 traffic connections. In this section, A3-CEData 23
Forward/Reverse messages represent A3-IS-95 FCH Forward/Reverse, A3-IS-2000 24
FCH Forward/Reverse, or A3-IS-2000 DCCH Forward/Reverse messages. For SCH 25
soft/softer handoff addition, refer to sections 3.19.3.2.4 and 3.19.3.2.5. 26
TIA-2001.3-C
245 Section 3

Source BS

Target BS MS

MSC
A7- Handoff Request
A3-Connect
A3-Connect Ack
A7- Handoff Request Ack
Handoff Performed
a
b
c
g
h
i
j
Time Comment
MS Ack Order
BS Ack Order
k
l
m
Thoreq
Tconn3
d
A3-CEData Forward (Forward Frames)
Forward Frames
e
f
A3-CEData Reverse (Idle Frames)
Tchanstat
T8
1
Figure 3.19.3.2.1-1 Soft/Softer Handoff Addition 2
a. The source BS decides that one or more cells at the target BS are needed to support 3
the call in soft/softer handoff. The source BS sends an A7-Handoff Request message 4
to the target BS and starts timer T
horeq
. 5
b. The target BS initiates an A3 traffic connection (or adds to an existing one) by 6
sending an A3-Connect message to the source BS and starting timer T
conn3
. Note 7
that a single A7-Handoff Request message may result in multiple A3 traffic 8
connections being established, each using a separate A3-Connect message. This 9
example shows only a single A3 traffic connection being established. 10
c. The source BS replies with an A3-Connect Ack message to complete the A3 11
connection or to acknowledge the addition of cells to an existing A3 connection. The 12
conn3
. If the source BS requested notification of transmission 13
start at the target BS, the source BS starts timer T
chanstat.
14
d. The source BS begins to send forward frames to the target BS. 15
e. The target BS begins to send reverse idle frames as soon as the first forward frame is 16
received from the source BS. The reverse frames contain the timing adjustment 17
information necessary to achieve synchronization. 18
f. The target BS begins to transmit the forward frames over the air as soon as 19
synchronization has occurred. 20
g. The target BS sends an A7-Handoff Request Ack message to the source BS to 21
indicate the success of the cell addition(s). The source BS stops timer T
horeq
. 22
TIA-2001.3-C
Section 3 246
h. If the source BS has chosen to be notified of the start of transmission and reception 1
at the target BS, when its SDU function and the target BS have synchronized the A3 2
traffic subchannel, the target BS replies with an A3-Traffic Channel Status message. 3
Refer to [15] A3-Connect Ack. Note that this step may occur any time after step 4
d. The source BS stops timer T
chanstat
if it was started. 5
i. The source BS sends a handoff direction message
3
to the MS to add the new cell(s) 6
to the active set. 7
j. The MS acknowledges receipt of the handoff direction message with an MS Ack 8
Order. 9
k. The MS indicates successful results of processing the handoff direction message by 10
sending a Handoff Completion Message. 11
l. The source BS acknowledges receipt of the Handoff Completion Message by 12
sending a BS Ack Order. 13
m. The source BS may send a Handoff Performed message to the MSC. Refer to section 14
3.19.1.1.3 (Concept of Designated Cell). The Handoff Performed message may 15
be sent any time after the Handoff Completion Message is received by the BS. 16
3.19.3.2.2 Soft/Softer Handoff Removal 17
Soft/softer handoff removal occurs as shown in the following diagram. In this section, 18
A3-CEData Forward/Reverse messages represent A3-IS-95 FCH Forward/Reverse, 19
A3-IS-2000 FCH Forward/Reverse, or A3-IS-2000 DCCH Forward/Reverse 20
messages. 21

3
appropriate.
TIA-2001.3-C
247 Section 3

MS

Source BS

Target BS MSC
A7-Drop Target
A3-Remove
A3-Remove Ack
A7-Drop Target Ack
Handoff Performed
b
c
MS 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
T8
1
Figure 3.19.3.2.2-1 Soft/Softer Handoff Removal 2
a. The source BS sends a handoff direction message
4
in an A3-CEData Forward 3
message to the target BS to be sent to the MS to drop one or more cell(s) from the 4
active set. 5
b. The source BS and target BS transmit the handoff direction message to the MS. 6
c. The MS acknowledges receipt of the handoff direction message with an MS Ack 7
Order transmitted to both the source and target BSs. 8
d. The target BS relays the MS Ack Order to the source BS in an A3-CEData Reverse 9
message. 10
e. The MS indicates the successful processing of the handoff direction message by 11
f. The source BS acknowledges receipt of the Handoff Completion Message by 13
g. The source BS sends an A7-Drop Target message to the target BS to request that the 15
specified cells be removed from the call. The source BS starts timer T
drptgt
. 16
h. The target BS, upon receipt of the A7-Drop Target message, deallocates internal 17
resources related to the specified cells. The target BS sends an A3-Remove message 18
to the SDU function of the source BS and starts timer T
discon3
. 19
i. The SDU function of the source BS replies with an A3-Remove Ack message and 20
deallocates internal resources. The target BS stop timer T
discon3
. 21

4
appropriate.
TIA-2001.3-C
Section 3 248
j. The target BS sends an A7-Drop Target Ack message to the source BS to 1
acknowledge the removal of the specified cells. The source BS stops timer T
drptgt
. 2
k. The source BS may send a Handoff Performed message to the MSC. Refer to section 3
3.19.1.1.3 Concept of Designated Cell. The Handoff Performed message may be 4
sent any time after the Handoff Completion Message is received by the BS. 5
3.19.3.2.3 Cell Removal by a Target BS 6
The example below shows a Target Removal initiated by a target BS, where the last cell 7
attached to an A3 call leg is removed, thus causing the A3 call leg connections to be torn 8
down. As can be seen in the example, the A7-Target Removal Request message initiates 9
normal call leg removal, that is, the normal A7 interface call leg removal procedure is 10
used between the A7-Target Removal Request and A7-Target Removal Response 11
messages. 12

Source BS

Target BS MS

MSC
A7-Drop Target
A3-Remove
A3-Remove Ack
A7-Drop Target Ack
Handoff Performed
b
c
MS Ack Order
BS Ack Order
d
e
j
f
g
h
i
Time Comment
A7-Target Removal Request
a
A7-Target Removal Response
k
Ttgtrmv
Tdrptgt
Tdiscon3
T8
13
Figure 3.19.3.2.3-1 Cell Removal Initiated by the Target BS 14
a. The target BS decides that one or more of its cells can no longer be involved in the 15
soft/softer handoff and sends an A7-Target Removal Request message to the source 16
BS. The target BS starts timer T
tgtrmv
. 17
b. The source BS sends a handoff direction message
5
to the MS to drop the cell(s) from 18
the active set. 19
c. The MS acknowledges receipt of the handoff direction message with an MS Ack 20
Order. 21

5
appropriate.
TIA-2001.3-C
249 Section 3
d. The MS indicates the successful processing of the handoff direction message by 1
e. The source BS acknowledges receipt of the Handoff Completion Message by 3
f. The source BS sends an A7-Drop Target message to the target BS to request that the 5
specified cells be removed from the call. The source BS starts timer T
drptgt
. 6
g. The target BS, upon receipt of the A7-Drop Target message, deallocates internal 7
resources related to the specified cells. In this example, it is assumed that all cells 8
attached to an A3 connection are removed from the call. The target BS sends an A3- 9
Remove message to the SDU function of the source BS and starts timer T
discon3
. 10
h. The SDU function of the source BS replies with an A3-Remove Ack message and 11
deallocates internal resources. The target BS stop timer T
discon3
. 12
i. The target BS sends an A7-Drop Target Ack message to the source BS to 13
acknowledge the removal of the specified cells. The source BS stops timer T
drptgt
. 14
j. The source BS may send a Handoff Performed message to the MSC. Refer to section 15
3.19.1.1.3 Concept of Designated Cell. The Handoff Performed message may be 16
sent any time after the Handoff Completion Message is received by the BS. 17
k. The source BS responds to the target BS with an A7-Target Removal Response 18
message. The target BS stops timer T
tgtrmv
. 19
3.19.3.2.4 Initial Traffic Burst Example A3 Connection Not Yet Established 20
The following example describes the support of an initial traffic burst when the A3 21
connection has not yet been established. 22
In this version of this standard, it is assumed that any leg for a Supplemental Channel is 23
established on a cell that also supports a leg for the Fundamental Channel (FCH) or the 24
Dedicated Control Channel (DCCH) for the same MS. To minimize the time required to 25
establish a traffic burst, the A3 connection for the SCH is established on the target BS at 26
the transmission of the first data burst. When a leg is established for a SCH, only the 27
terrestrial resources are allocated, i.e., the A3 connection. This involves choosing the 28
traffic circuit to be used and establishing context between the target BS and the source 29
BS/SDU function. Allocation of radio resources for the SCH is made each time that a 30
traffic burst is set up. 31
TIA-2001.3-C
Section 3 250
i

A3 -Physical Transition Directive
Tconn3
A3-Connect Ack
A3-Connect
A7-Burst Request
Thoreq
A7- Handoff Request Ack
A7- Handoff Request

Source BS

Target BS MS
b
c
d
Time Comment
Tbstcom
e
A7-Burst Response
f
g
A7-Burst Commit
Forward and/or reverse traffic burst
j
i
ESCAM
Layer 2 Ack
Tbstreq
SCRM Msg

PDSN
(data to be sent)
a
h
k

l
A7-Burst Release
m
A3 -Physical Transition Directive Ack
n
Tphysical
Tbstcom
1
Figure 3.19.3.2.4-1 Initial Traffic Burst Example 2
a. Either the source BS receives an indication from the MS (via a Supplemental 3
Channel Request Message (SCRM)) or from the network (via data being received 4
from the PDSN) that data needs to be sent to/from the MS. The source BS decides a 5
traffic burst on one or more new cells at a target BS is required in support of a 6
service instance in soft/softer handoff. This example assumes that a Fundamental 7
Channel (FCH) or Dedicated Control Channel (DCCH) leg already exists on the 8
selected cell(s) at the target BS. For simplicity, only one SCH is shown. 9
b. The source BS assigns an A7-Originating ID value and sends an A7 Handoff 10
Request message to the target BS to establish an A3 traffic connection to support a 11
Supplemental Channel (SCH) for the call. This example shows only a single A3 12
connection being established. The source BS is not required to assign a physical 13
Frame Selector at this time. The source BS starts timer T
horeq
. 14
c. The target BS assigns a traffic circuit and optionally a Channel Element ID (CE ID) 15
for each A3 traffic connection and sends an A3-Connect message to the source BS 16
indicating the Traffic Circuit ID, optional A3 Originating ID and CE ID to be 17
associated with the specified cell. The source BS and target BS save the association 18
of CE ID, Traffic Circuit ID, with Cell ID(s). The source BS also saves the A3 19
Originating ID value, to be included in subsequent A3 messages to the target BS. 20
The target BS starts timer T
conn3
. This is only done at the initial burst. 21
d. The source BS responds with an A3-Connect Ack message to complete the A3 22
connection. This may include an A3 Originating ID value assigned by the source BS, 23
TIA-2001.3-C
251 Section 3
which is included by the target BS in subsequent A3 messages to the source BS. The 1
conn3
. 2
e. The target BS sends an A7-Handoff Request Ack message to the source BS to 3
complete the A3 traffic circuit connection setup procedure for the specified set of 4
cells. This may include an A7 Originating ID value assigned by the target BS, which 5
is included by the source BS in subsequent A7 messages to the target BS for this call 6
association. Upon receipt of the A7-Handoff Request Ack message, the source BS 7
stops timer T
horeq
. 8
f. The source BS sends an A7-Burst Request message to the target BS to request the 9
reservation of the needed radio resources at one or more cells for the Supplemental 10
Channel. The source BS starts timer T
bstreq
. Note that the source BS may send an 11
A7-Burst Request message to the target BS at any time after receiving the A3- 12
Connect message in step c, and that the set of cells may be a subset of the cells 13
assigned in steps a through e. 14
g. The target BS determines that it can reserve part or all of the requested resources at 15
some of the cells and sends A7-Burst Response message(s) to the source BS 16
indicating the resources that have been reserved and committed to the traffic burst, 17
and the cause value for any uncommitted cells. Each A7-Burst Response message 18
can contain up to one committed cell and multiple uncommitted cells. Each 19
reservation includes a physical Channel Element. Note that the physical Channel 20
Element may be allocated any time after step b. The target BS starts an instance of 21
timer T
bstcom
for each committed cell. 22
h. The source BS makes a final decision on the resources using the information 23
received from the target BSs in the A7-Burst Response messages, associates a frame 24
selector with the physical channel, and sends A7-Burst Commit messages to each 25
target BS for each cell chosen to support the traffic burst, indicating the cell 26
resources to be used for the traffic burst. In this scenario, the source BS decides to 27
use the resources reserved by the target BS. Upon receipt of the A7-Burst Commit 28
message for a given cell, the target BS stops the corresponding timer T
bstcom
and sets 29
up the burst. Note that the source BS may allocate the frame selector any time after 30
step b. 31
Note that the source BS is not required to wait for all A7-Burst Responses before 32
committing the burst, but it shall not send an A7-Burst Commit message for a given 33
cell until after receiving the corresponding A7-Burst Response for that cell. 34
i. The source BS sends A7-Burst Release message(s) to the target BS(s) for cells that 35
reserved resources but are not required to support the burst. The target BS frees the 36
reserved resources. 37
Note that the source BS is not required to wait for all A7-Burst Response messages 38
before committing the burst, but it shall not send an A7-Burst Release message for a 39
given cell until after receiving the corresponding A7-Burst Response message for 40
that cell. Upon receipt of the A7-Burst Release message for a given cell, the target 41
BS stops the corresponding timer T
bstcom
. 42
Refer to the call flow in section 3.19.3.2.6 for procedures to release any reserved 43
resources that are not used for the traffic burst. 44
j. The source BS commands the MS to prepare for the traffic burst via an Extended 45
Supplemental Channel Assignment Message (ESCAM). 46
k. The MS acknowledges the command from the source BS with a Layer 2 Ack. 47
If the ESCAM is sent using quick repeats, the source BS might not request an 48
acknowledgment from the MS. 49
TIA-2001.3-C
Section 3 252
l. The network and MS exchange forward and/or reverse traffic burst information for 1
the specified duration, or until the source BS or target BS terminates or extends the 2
traffic burst. 3
m. The source BS sends an A3-Physical Transition Directive message if the previous 4
Power Control Mode is to be restored when the burst ends. This step may occur 5
anytime after step h. The source BS starts timer T
physical
. 6
n. The target BS sends an A3-Physical Transition Directive Ack message. Upon receipt 7
of this message, source BS stops timer T
physical.
8
3.19.3.2.5 Subsequent Traffic Burst Example 9
The following example describes the support of a traffic burst when the A3 connection 10
for the Supplemental Channel (SCH) has already been established. Note that this could be 11
the initial data burst if the A3 connection for the SCH was established previously via the 12
A7-Handoff Request procedure. 13
Source BS Target BS MS
A7- Burst Request
A7- Burst Commit
b
c
d
Time Comment
Tbstcom
e
f
g
ESCAM
Layer 2 Ack
SCRM Msg
PDSN
(data to be sent)
a
A7- Burst Response
Tbstreq
A7- Burst Response
Tbstreq
Tbstcom A7- Burst Release
h
i
14
Figure 3.19.3.2.5-1 Subsequent Traffic Burst Example 15
a. Either the source BS receives an indication from the MS (via a Supplemental 16
Channel Request Message (SCRM)) or from the network (via data being received 17
from the PDSN) that data needs to be sent to/from the MS. 18
b. The source BS decides a traffic burst is required on one or more cells for which an 19
A3 connection already exists in support of a Supplemental Channel. The source BS 20
sends an A7-Burst Request message to the target BS to request the reservation of the 21
needed radio resources for the Supplemental Channel. The source BS starts timer 22
T
bstreq
. 23
c. The target BS determines that it can reserve part or all of the requested resources at 24
some of the cells and sends A7-Burst Response message(s) to the source BS 25
indicating the resources that have been reserved and committed to the traffic burst, 26
and the cause value for any uncommitted cells. Each A7-Burst Response message 27
can contain up to one committed cell and multiple uncommitted cells. Each 28
reservation includes a physical Channel Element. Note that the physical Channel 29
Element may be allocated any time after step b. The target BS starts an instance of 30
timer T
bstcom
for each committed cell. 31
TIA-2001.3-C
253 Section 3
d. Upon receipt of the last A7-Burst Response message accounting for all requested 1
cells, the source BS stops timer T
bstreq
. 2
e. The source BS makes a final decision on the resources using the information 3
received from the target BSs in the A7-Burst Response messages, associates a frame 4
selector with the physical channel, and sends A7-Burst Commit messages to each 5
target BS for each cell chosen to support the traffic burst, indicating the cell 6
resources to be used for the traffic burst. In this scenario, the source BS decides to 7
use the resources reserved by the target BS. Upon receipt of the A7-Burst Commit 8
message for a given cell, the target BS stops the corresponding timer T
bstcom
and sets 9
up the burst. Note that the source BS may allocate the frame selector any time after 10
step b. 11
before committing the burst, but it shall not send an A7-Burst Commit message for a 13
that cell. 15
f. The source BS sends A7-Burst Release message(s) to the target BS(s) for cells that 16
reserved resources but are not required to support the burst. Upon receipt of an A7- 17
Burst Release message for a given cell, the target BS stops the corresponding timer 18
T
bstcom
. The target BS frees the reserved resources. 19
before committing the burst, but it shall not send an A7-Burst Release message for a 21
that cell. 23
Refer to the call flow in section 3.19.3.2.6 for procedures to release any reserved 24
resources that are not used for the traffic burst. 25
g. The source BS commands the MS to prepare for the traffic burst via an Extended 26
Supplemental Channel Assignment Message (ESCAM). 27
h. The MS acknowledges the command from the source BS with a Layer 2 Ack. 28
If the ESCAM is sent using quick repeats, the source BS might not request an 29
acknowledgment from the MS. 30
i. The network and MS exchange forward and/or reverse traffic burst information for 31
the specified duration, or until the source BS or target BS terminates or extends the 32
traffic burst. 33
3.19.3.2.6 Source BS Releases Reserved Resources 34
The following example describes how the source BS releases resources reserved at the 35
target BS for a cell that is not required to support the burst. 36
TIA-2001.3-C
Section 3 254
Source BS Target BS
A7- Burst Request
A7- Burst Response
A7- Burst Release
b
c
Time Comment
Tbstreq
Tbstcom
a
1
Figure 3.19.3.2.6-1 Source BS Releases Reserved Resources 2
a. The source BS sends an A7-Burst Request message to the target BS to request the 3
reservation of the needed radio resources for the Supplemental Channel. The source 4
BS starts timer T
bstreq
. 5
b. The target BS determines that it can reserve part or all of the requested resources and 6
sends A7-Burst Response message(s) to the source BS indicating the resources that 7
have been reserved and committed to the traffic burst, and the cause value for any 8
uncommitted cells. The target BS starts a timer T
bstcom
for each A7-Burst Response 9
message sent. Upon receipt of the last A7-Burst Response message, the source BS 10
stops timer T
bstreq
. 11
c. In this scenario, the source BS decides not to use the resources reserved by the target 12
BS. The source BS sends A7-Burst Release message(s) for the reserved cell(s) that 13
are not used for the traffic burst. Upon receipt of each A7-Burst Release message, 14
the target BS stops the timer T
bstcom
corresponding to the indicated cell(s) and 15
releases its resources. 16
3.19.3.2.7 Early Burst Termination Initiated by Source BS 17
The following example describes how the source BS terminates a burst in progress. 18
Source BS Target BS
A7- Burst Commit
A7- Burst Release
b
c
Time Comment
a
MS
19
Figure 3.19.3.2.7-1 Early Burst Termination Initiated by Source BS 20
a. The source BS sends A7-Burst Commit messages to all target BSs indicating the set 21
of committed resources that are actually used for the traffic burst. The target BS sets 22
up the burst. 23
b. The network and MS exchange forward and/or reverse traffic burst information. 24
c. While the burst is in progress, the source BS decides to terminate the burst early at 25
one or more cells. The source BS sends anA7-Burst Release message to the cells 26
which are to terminate the burst. The target BS releases all resources associated with 27
the burst. 28
TIA-2001.3-C
255 Section 3
3.19.3.2.8 Early Burst Termination Initiated by Target BS 1
The following example describes how the target BS terminates a burst in progress. 2

Source BS

Target BS
A7- Burst Release
b
Time Comment
a

MS
3
Figure 3.19.3.2.8-1 Early Burst Termination Initiated by Target BS 4
a. The network and MS exchange forward and/or reverse traffic burst information. 5
b. While the burst is in progress, the target BS decides to terminate the burst early at 6
one or more cells. The target BS sends A7-Burst Release message(s) for the cells 7
which are being removed from the burst. The source BS releases all resources 8
associated with the cells that are being removed from the burst. If there are other 9
cells supporting the SCH, then the burst continues on those cells. 10
3.19.4 Fast Handoff Call Flows 11
This section describes call flows for fast handoff. Refer to section 2.19.4 for more 12
information on this feature. 13
3.19.4.1 Anchor PDSN Reachable from Target PCF 14
This call flow shows the case of an initial fast handoff (source PDSN is the same as the 15
anchor PDSN) where the target BS/PCF is able to reach the anchor PDSN because the 16
target BS/PCF is in the same PDSN selection domain as the anchor PDSN. 17
TIA-2001.3-C
Section 3 256

w
Source BS
Handoff Required
Handoff Request
Source
PCF
Handoff Request Ack
Handoff Command
GHDM / UHDM
Handoff Commenced
Handoff Completion
Clear Command
A9-Release-A8
Clear Complete
MS Ack Order
BS Ack Order
Target
PCF
A9-AL Disconnected
a
b
d
e
c
f
g
h
i
l
k
j
m
n
o
p
r
q
v
w
x
x
Twaitho
MS Target BS MSC
Anchor
PDSN
A9-Connect-A8
A9-Setup-A8
A9-AL Connected
y
T7
T11
TA8-setup
T9
Twaitho9
T315
T306
s
u
t
A9-Setup-A8
TA8-setup
A9-AL Connected Ack
z
aa
Handoff Complete
Taldak
Talc9
T8
1
Figure 3.19.4.1-1 Anchor PDSN Reachable From Target PCF 2
TIA-2001.3-C
257 Section 3
a. User data flow is active using a PPP session between the MS and the source/anchor 1
PDSN. During the setup of the A10 connection(s), the source/anchor PDSN returned 2
its Anchor P-P Address in the A11-Registration Reply message to the source PCF. 3
The source PCF in turn relayed both the anchor PDSN address and the anchor P-P 4
address to the source BS. Note that if the source PDSN was not the same as the 5
anchor PDSN, then a P-P connection would exist between the source PDSN and the 6
anchor PDSN. The PCF shall then also return the source PDSN address to the BS 7
after the setup of the A10 connection. 8
b. Based on an MS report that it crossed a network specified threshold for signal 9
strength, changes to a different ANID, or for other reasons, the source BS 10
recommends cdma2000
to cdma2000

7
information of the source PCF in the Handoff Required message. It also includes the 14
source PDSN address, anchor PDSN Address, and Anchor P-P Address information 15
elements. The Service Configuration Record in this message identifies the active 16
service instances. The Service Option List information element identifies the 17
dormant and active service instances. 18
c. The MSC sends a Handoff Request message (which includes the PANID information 19
target BS. In this message the MSC also relays the source PDSN, anchor PDSN and 21
Anchor P-P Addresses. The Service Configuration Record in this message identifies 22
the active service instances. The Service Option List information element identifies 23
the active and dormant service instances. The MSC starts timer T
11
. 24
d. The target BS sends an A9-Setup-A8 message to the target PCF to establish the A8 25
connection for each active service instance and sets timer T
A8-setup
. In this case, the 26
handoff indicator field of the A9-Setup-A8 message is set to 1 (during handoff). 27
The target BS includes the PDSN Address (set to the address of the source PDSN), 28
anchor PDSN and Anchor P-P Addresses. 29
e. Upon receipt of the A9-Setup-A8 message(s) from the target BS, the target PCF 30
recognizes the presence of the Anchor P-P Address and establishes an A10 31
connection with the anchor PDSN for each active service instance using the anchor 32
PDSN Address. The lifetime field in the A11-Registration Request message is set to 33
Tpresetup, the S bit is set to 1 indicating simultaneous binding and the P-P 34
address VSE is attached (indicating fast handoff request). The A11-Registration 35
Request message also contains the A10 Connection Setup Airlink Record. The PCF 36
starts a timer T
regreq
associated with each active service instance for which an A11- 37
Registration Request message is sent. The PDSN accepts the connection and 38
indicates that the fast handoff is accepted by returning the A11-Registration Reply 39
message with the same Anchor P-P Address. The PCF stops the associated timer 40
T
regreq
when it receives an A11-Registration Reply message. Note that if the source 41
PDSN was not the same as the anchor PDSN, and the anchor PDSN was not 42
reachable from the target BS/PCF, then the target PCF connects to the source PDSN, 43
and the existing P-P connection(s) would be reused for the new A10 connection(s). 44
f. The target PCF returns an A9-Connect-A8 message for each active service instance 45
that includes the PDSN Address (set to the address of the target PDSN), the anchor 46
PDSN , and the Anchor P-P Addresses to indicate that the fast handoff was accepted 47
and starts timer T
waitho9
message(s) it stops timer T
A8-setup
. 49
Note: The target BS stores the anchor PDSN and Anchor P-P Addresses for use in 50
the event that this fast handoff is superseded by another fast handoff. 51
TIA-2001.3-C
Section 3 258
g. The target BS sends a Handoff Request Acknowledgment message to the MSC. The 1
9
to wait for arrival of the MS on its radio channel. The MSC 2
stops timer T
11
. 3
h. At this point in time, PDSN continues to forward packet data to the source BS via 4
source PCF. It also forwards user data to the target PCF, which at this time discards 5
the data. 6
i. The MSC prepares to switch the MS from the source BS to the target BS and sends a 7
7
. 8
j. The source BS sends an A9-AL Disconnected message to the source PCF. The BS 9
starts an associated timer T
ald9
. The PCF stops packet transmission to the source BS. 10
The PCF sends A9-AL Disconnected Ack message in response to the A9-AL 11
Disconnected message and starts timer T
aldak
. The BS stops associated timer T
ald9
. 12
k. The source BS sends the General Handoff Direction Message or Universal Handoff 13
Direction Message to the MS . If the BS requests an acknowledgement it starts T
8.
If 14
the MS is allowed to return to the source BS, then timer T
waitho
is started by the 15
source BS. 16
l. The MS may acknowledge the General Handoff Direction Message or Universal 17
Handoff Direction Message by sending an MS Ack Order to the source BS. If the BS 18
has started timer T
8
, it stops it. If the General Handoff Direction Message or 19
Universal Handoff Direction Message is sent using quick repeats, the source BS 20
might not request an acknowledgment from the MS. 21
m. The source BS sends a Handoff Commenced message to the MSC to notify it that the 22
MS has been ordered to move to the target BS. The source BS starts timer T
306
to 23
await the Clear Command message from the MSC. If timer T
waitho
has been started 24
(i.e., return on failure was requested), the source BS shall wait for that timer to 25
expire before sending the Handoff Commenced message. 26
n. The MS sends a Handoff Completion Message to the target BS. The target BS 27
detects that the MS has successfully accessed the target BS and stops timer T
9
. If 28
timer T
9
had expired the BS shall send Handoff Failure message to the MSC. Refer 29
to [14] for detail procedures. 30
o. The target BS sends the BS Ack Order to the MS. 31
p. The target BS sends an A9-AL (Air Link) Connected message to the target PCF and 32
alc9
. The target PCF stops timer T
waitho9
. 33
q. The target PCF sends an Active Start Airlink Record to the anchor PDSN in an A11- 34
Registration Request message for each active service instance. The A11-Registration 35
Request message contains Trp as lifetime and the S bit is cleared. The target PCF 36
regreq
. The PDSN sends an A11-Registration Reply 37
message to the target PCF in response to each A11-Registration Request message. 38
The target PCF stops associated timer T
regreq
. Note: before receipt of the Active Start 39
Airlink Record the PDSN is still transmitting the user data stream to the source 40
BS/PCF and the target BS/PCF via the pre-setup A10 connection(s). On receipt of 41
the Active Start Airlink Record, the PDSN stops sending user data to the source 42
PCF. 43
r. The target PCF sends an A9-AL (Air Link) Connected Ack message in response to 44
the A9-AL (Air Link) Connected message and stops timer T
alc9
. 45
TIA-2001.3-C
259 Section 3
s. The target BS sends a Handoff Complete message to the MSC to notify it that the 1
MS has successfully completed the hard handoff. 2
t. The target BS sends an A9-Setup-A8 message to the target PCF for each dormant 3
service instance of the MS; the A9-Setup-A8 message has the Data Ready Indicator 4
set to 0. Steps t y may occur anytime after step n. 5
u. The target PCF determines the MS is in fast handoff. The target PCF sends an A11- 6
Registration Request to the same PDSN used for the pre-setup A10 connection(s) to 7
initiate A10 connection establishment for each dormant service instance. The target 8
PCF starts an associated timer T
regreq
for each message sent. Each A11-Registration 9
Request message contains Trp as lifetime, zero S bit value, the Mobility Event 10
Indicator and Accounting Data (R-P Session Setup Airlink Record). The PDSN 11
determines the MS is in fast handoff. The PDSN returns an A11-Registration Reply 12
message to the target PCF for each A11-Registration Request message (for each 13
service dormant instance) received. The A11-Registration Reply message(s) do not 14
contain the Data Availability Indicator. The target PCF stops the associated timer(s) 15
T
regreq
. 16
v. The target PCF returns an A9-Release-A8 Complete message for each A9-Setup-A8 17
message sent by the target BS 18
w. The PDSN initiates termination of the A10 connection to the source PCF for each 19
service instance (both active and dormant) established via the target PCF as follows: 20
The PDSN sends an A11-Registration Update message to the source PCF to 21
disconnect each A10 connection. The PDSN starts associated timer(s) T
regupd
. The 22
source PCF sends an A11-Registration Acknowledge message to the PDSN for each 23
A11-Registration Update message received. The PDSN stops the associated timer(s) 24
T
regupd
. The source PCF sends an A11-Registration Request message to the PDSN 25
with lifetime zero to clear each A10 connection. The source PCF starts the associated 26
timer(s) T
regreq
. The PDSN sends an A11-Registration Reply message to the source 27
PCF for each A11-Registration Request message received. The A10 connection(s) 28
are now released. The source PCF stops the associated timer(s) T
regreq
. 29
x. Data flows between the anchor PDSN and target PCF. 30
y. The MSC sends a Clear Command to the source BS. The source BS stops timer T
306
. 31
315
. Note this step may occur any time after step s. 32
z. For each active service instance the source BS sends an A9-Release-A8 message to 33
the source PCF to release the A8 connection and starts timer T
re19
. Upon the receipt 34
of the A9-Release-A8 message from the source BS, the source PCF releases the A8 35
connection, stops timer T
aldak
, and responds with an A9-Release-A8 Complete 36
message. When the source BS receives the A9-Release-A8 Complete message it 37
stops timer T
re19
. 38
aa. The source BS sends a Clear Complete message to the MSC to notify it that clearing 39
315
. This may occur any time after 40
the traffic channel is released. At this point the fast handoff is completed. 41
3.19.4.2 Anchor PDSN Not Reachable from Target PCF 42
This call flow shows the case of an initial fast handoff (source PDSN is the same as the 43
anchor PDSN) from the source BS/PCF to a target BS/PCF where the target BS/PCF is 44
not able to reach the anchor PDSN because the target BS/PCF is in a different PDSN 45
selection domain than the anchor PDSN. 46
TIA-2001.3-C
Section 3 260

MS Source BS MSC
Handoff Required
Handoff Request
Source
PCF
Handoff Request Ack
Handoff Command
GHDM / UHDM
Handoff Commenced
Handoff Completion
A9-AL-Connected Ack
MS Ack Order
BS Ack Order
A9-AL Disconnected
a
b
d
e
c
f
g
h
l
k
j
i
m
n
o
q
r
P-P Registration Request
P-P Registration Reply
P-P Registration Request
P-P Registration Reply
s
x
Twaitho
Target BS
Target
PCF
Anchor
PDSN
Target
PDSN
A9-Setup-A8
A9-Connect-A8
A9-AL Connected
t
x
y
T7
TA8-setup
T11
T9
Twaitho9
T306
Talc9
u
v
A9-Setup-A8
w
TA8-setup
p
Handoff Complete
Taldak
T8
1
Figure 3.19.4.2-1 Anchor PDSN Not Reachable From Target PCF 2
TIA-2001.3-C
261 Section 3

T306
MS Source BS MSC
Source
PCF
cc
Target BS
Target
PCF
Anchor
PDSN
Target
PDSN
Clear Command
A9-Release-A8
Clear Complete
z
aa
bb
T315
Taldak
1
Figure 3.19.4.2-1 (Cont.) Anchor PDSN Not Reachable From Target PCF 2
a. User data flow is active using a PPP session between the MS and the source/anchor 3
PDSN. During the setup of the A10 connection(s), the source/anchor PDSN returned 4
its P-P address in the A11-Registration Reply message(s). The source PCF in turn 5
relayed both the anchor PDSN and Anchor P-P Addresses to the source BS. Note 6
that if the source PDSN was not the same as the anchor PDSN, then a P-P connection 7
would exist between the source PDSN and the anchor PDSN, and the PCF would 8
also return the source PDSN address to the BS during the setup of the A10 9
connection. 10
b. Based on an MS report that it crossed a network specified threshold for signal 11
recommends a cdma2000
to cdma2000

7
information of the source PCF in the Handoff Required message. It also includes the 16
Source PDSN Address, anchor PDSN Address, and Anchor P-P Address 17
information elements to request fast handoff. The Service Configuration Record in 18
this message identifies the active service instances. The Service Option List 19
information element identifies the dormant service instances, if any exist. 20
c. The MSC sends a Handoff Request message (which includes the ANID information 21
target BS. This message contains the source PDSN Address, anchor PDSN Address, 23
and Anchor PP Address information elements. The Service Configuration Record in 24
this message identifies the active service instances. The Service Option List 25
information element identifies the dormant service instances if any exist. The MSC 26
starts timer T
11
. 27
d. The target BS sends an A9-Setup-A8 message to the target PCF to establish the A8 28
connection for each active service instance and sets an associated timer T
A8-setup
. 29
The handoff indicator field of the A9-Setup-A8 message is set to 1 (during 30
handoff). The target BS includes the PDSN Address (set to the address of the source 31
PDSN), anchor PDSN, the Anchor P-P Address, and the ANID received in the 32
Handoff Request message. 33
e. The target PCF determines it cannot establish A10 connection(s) with the anchor 34
PDSN or with the source PDSN and selects another PDSN, the target PDSN. The 35
target PCF establishes an A10 connection for each active service instance to be 36
handed off. The lifetime field in each A11-Registration Request message is set to 37
TIA-2001.3-C
Section 3 262
T
presetup
, the S bit is set to 1 indicating simultaneous binding, and the Anchor P-P 1
Address NVSE is included to indicate a fast handoff operation. Each A11- 2
Registration Request message also includes the A10 Connection Setup Airlink 3
Record. The target PCF starts the associated timer(s) T
regreq
. The target PDSN 4
accepts the connection(s) and the fast handoff request by returning A11-Registration 5
Reply message(s) with the same Anchor P-P Address it received in the A11- 6
Registration Request message(s). The target PDSN buffers the airlink records as it 7
will need these for accounting purposes after the fast handoff completes (assuming 8
the target PDSN becomes the anchor PDSN at that point in time). The target PCF 9
stops the associated timer(s) T
regreq
. Note that if the anchor PDSN had been 10
reachable, then the target PCF shall select the anchor PDSN to be the target PDSN; if 11
the anchor PDSN Address is not reachable, the PCF shall try the source PDSN; if the 12
source PDSN is reachable, the target PCF shall select the source PDSN to be the 13
target PDSN. At this point, the call flow in Figure 3.19.4.1-1 starting at step e 14
applies and the fast handoff is completed. In the case when the anchor PDSN is 15
selected, the P-P connection(s) are released and no new ones are created. In the case 16
when the source PDSN is selected, the P-P connection between anchor PDSN and 17
source PDSN is kept and no new one is created. 18
f. The target PCF sends A9-Connect-A8 message(s) to the target BS. The target PCF 19
indicates acceptance of the fast handoff by including the PDSN Address (set to the 20
address of the target PDSN), anchor PDSN, and Anchor P-P Addresses. When the 21
target BS receives an A9-Connect-A8 message it stops associated timer T
A8-setup
. 22
waitho9
. Note that the target BS stores the anchor PDSN and 23
Anchor P-P Addresses for use in the event that this fast handoff is superseded by 24
another fast handoff. 25
g. The target PDSN establishes a P-P connection with the anchor PDSN for each active 26
A10 connection that was set up. P-P establishment is done concurrently with 27
subsequent RAN procedures. The anchor PDSN indicates the PPP service instance to 28
the target PDSN in the PPP Link Indicator extension. Refer to [8]. 29
h. The target BS sends a Handoff Request Acknowledgment message to the MSC. The 30
9
stops timer T
11
. 32
i. The anchor PDSN forwards packet data to the source BS via the source PCF. It also 33
forwards the data over the P-P connection(s) to the target PDSN which, in turn, 34
forwards the data to the target BS via the target PCF. The target PCF discards the 35
data received at this time. 36
j. The MSC prepares to switch the MS from the source BS to the target BS and sends a 37
7
. 38
k. The source BS sends an A9-AL Disconnected message to the source PCF. The BS 39
ald9
The PCF sends A9-AL Disconnected Ack message in response to the A9-AL 41
aldak
ald9
.. 42
l. The source BS sends the General Handoff Direction Message or Universal Handoff 43
Direction Message to the MS across the air interface and starts timer T
8
. If the MS is 44
allowed to return to the source BS, then timer T
waitho
m. The MS may acknowledge the General Handoff Direction Message or Universal 46
8
TIA-2001.3-C
263 Section 3
n. The source BS sends a Handoff Commenced message to the MSC to notify it that the 3
306
to 4
waitho
has been started 5
o. The MS sends a Handoff Completion message to the target BS. The target BS detects 8
9
. If timer T
9
9
had expired, the BS shall send Handoff Failure message to the MSC. Refer to [14] 10
for detailed procedures. 11
p. The target BS sends the BS Ack Order to the MS over the air interface. 12
q. The target BS sends an A9-AL (Air Link) Connected message to the target PCF and 13
alc9
. The target PCF stops timer T
waitho9
. 14
r. The target PCF stops discarding the user data it is receiving from the PDSN for each 15
active service instance upon receipt of the A9-AL (Air Link) Connected message and 16
begins forwarding the data to the target PCF. For each such service instance, the 17
target PCF sends an A11-Registration Request message, containing an Active Start 18
Airlink Record, the Trp as Lifetime, and the S bit cleared. The PDSN sends an 19
A11-Registration Reply message to the target PCF in response to each A11- 20
Registration Request message received. 21
s. The target PCF sends A9-AL (Air Link) Connected Ack message in response to the 22
A9-AL (Air Link) Connected message and stops associated timer T
alc9
. 23
t. The target BS sends a Handoff Complete message to the MSC to notify it that the 24
MS has successfully completed the hard handoff. 25
u. The target BS sends an A9-Setup-A8 message to the target PCF for each dormant 26
service instance of the MS; the A9-Setup-A8 message has the Data Ready Indicator 27
set to 0. Steps u w may occur anytime after step o. The target BS starts an 28
associated timer T
A8-setup
after each message is sent. 29
v. The target PCF determines the MS is in fast handoff. The target PCF sends an A11- 30
Registration Request message to the same PDSN used for pre-set up A10 31
connection(s) to initiate A10 connection establishment for each dormant service 32
instance. The target PCF starts an associated timer T
regreq
for each message sent. The 33
A11-Registration Request message contains T
rp
as lifetime, zero S bit value, the 34
Mobility Event Indicator and Accounting Data (R-P Session Setup Airlink Record). 35
The PDSN determines the MS is in fast handoff. The PDSN returns an A11- 36
Registration Reply message to the target PCF. The A11-Registration Reply message 37
does not contain the Data Availability Indicator. The target PCF stops timer T
regreq
. 38
w. The target PCF returns A9-Release-A8 Complete message for each A9-Setup-A8 39
message sent by the target BS. The target BS stops the associated timer T
A8-setup
for 40
each A9-Release-A8 Complete message received. 41
x. For active service instances, P-P connections already exist between the target PDSN 42
and anchor PDSN. Upon receiving the A11-Registration Request message(s) from 43
the target PCF for the active service instance(s), the target PDSN forwards the 44
Active Start Airlink Record(s) to the anchor PDSN in P-P Registration Request 45
message(s) that has/have the S bit clear. The anchor PDSN acknowledges this to 46
the target PDSN with a P-P Registration Reply. For dormant service instances no P-P 47
connection exists between the target PDSN and anchor PDSN. On receiving the 48
TIA-2001.3-C
Section 3 264
A11-Registration Request message(s) from the target PCF for the dormant service 1
instance(s), the target PDSN establishes the P-P connection(s) with the anchor PDSN 2
for each such service instance. 3
y. The anchor PDSN requests the source PCF to disconnect the A10 connection(s) (for 4
both active and dormant service instances) upon receipt of the P-P Registration 5
Request by sending A11-Registration Update message(s). The anchor PDSN starts 6
associated Timer(s) T
regupd
. The source PCF sends A11-Registration Acknowledge 7
message(s) to the anchor PDSN. The anchor PDSN stops the associated timer(s) 8
T
regupd
. The source PCF sends A11-Registration Request message(s) with Lifetime 9
value set to 0 in response. The message(s) contain(s) a final Active Stop Airlink 10
Record in the case of active service instance(s). The source PCF starts timer T
regreq
. 11
The anchor PDSN acknowledges with the receipt of each A11- Registration Request 12
message with a A11-Registration Reply message. The source PCF stops associated 13
timer(s) T
regreq
. 14
z. The MSC sends a Clear Command message to the source BS. The source BS stops 15
timer T
306
315
. This step can happen any time after step t. 16
aa. The source BS sends an A9-Release-A8 message to the source PCF to release the A8 17
connection for each active service instance and starts an associated timer T
re19
. Upon 18
the receipt of the A9-Release-A8 message from the source BS, the source PCF 19
releases the A8 connection, stops timer T
aldak
, and responds with an A9-Release-A8 20
Complete message. When the source BS receives the A9-Release-A8 Complete 21
message it stops the associated timer T
re19
. 22
bb. The source BS sends a Clear Complete message to the MSC to notify it that clearing 23
315
. This may occur any time after 24
cc. Data now flows bidirectionally from the anchor PDSN to the target PDSN to the 26
target PCF and the target BS. From the RAN perspective, the fast handoff is 27
completed when the packet data session transitions to the Dormant State (refer to 28
section 3.17.4.3.1) or when a subsequent fast handoff takes place (refer to section 29
3.19.4.3). 30
3.19.4.3 Fast Handoff Superseded by Another Fast Handoff 31
This call flow shows the case where the MS has performed a fast handoff that has not yet 32
completed when a subsequent fast handoff occurs (i.e., source PDSN is not identical to 33
the anchor PDSN). The target PDSN of the previous fast handoff becomes the source 34
PDSN in this handoff.. 35
In this call flow it is assumed that the target PCF cannot reach the anchor PDSN or the 36
source PDSN. 37
The case where the target PCF can reach the anchor PDSN has a similar call flow, where 38
the target PDSN and the anchor PDSN are collapsed into one node and no messages are 39
exchanged between them. The fast handoff is complete in step nn. 40
The case where the target PCF cannot reach the anchor PDSN but can reach the source 41
PDSN has a similar call flow, where the source PDSN and the target PDSN are collapsed 42
into one node. Bicasting occurs at the source/target PDSN and not at the anchor PDSN 43
(steps j and t). Existing P-P connections are not released (step ee) and new P-P 44
connections are not set up (steps f, v, and bb). In lieu thereof, accounting 45
information is forwarded to the anchor PDSN according to procedures specified in [8]. 46
TIA-2001.3-C
265 Section 3
1
Figure 3.19.4.3-1 Fast Handoff Superseded by Another Fast Handoff 2

MS

Source BS MSC
Handoff Required
Handoff Request
Source
PCF
Handoff RequestAck

Handoff Command
GHDM / UHDM
Handoff Commenced
Handoff Completion
MS Ack Order
BS Ack Order
x
T waitho

Target BS
Target
PCF

Source
PDSN

Target
PDSN
A9 -AL Connected
T 7

T11
T9

Twaitho9

Anchor
PDSN
MS Ack Order
A9 -Setup-A8
A9-Connect-A8
T A8 -setup

a

Time

b

i

a

e

h
j

k
l

n
o
p

q

r

s

t

c

d

T alc9
T306

P-P Connection
Pre- setup
Procedures
Tregreq

Packet Data Session Active, Data Flow via Source BS, Data Flow Bicast to Target PCF
Packet Data Session Active, Data Flow via Target BS, Data Flow Bic ast to Source PCF
Packet Data Session Active, Data Flow via Source BS

f

g

A9 -AL Disconnected
A9 - AL Disconnected Ack m T ald9

T aldak

T8
TIA-2001.3-C
Section 3 266

MS Source BS MSC
Source
PCF
Target BS
Target
PCF
Source
PDSN
Target
PDSN
Anchor
PDSN
jj
Time
kk
mm
nn
Clear Command
Clear Complete
T
315

A9-AL-Connected Ack
A9-Setup-A8
T
A8-setup
T
306
T
alc9
x
z
dd
ee
A11-Registration Request u
P-P Connection
Refresh
Procedures
T
regreq
v
w
A11-Registration Request aa
P-P Connection
Setup Procedures
T
regreq
bb
cc
P-P
Connection
Release
Procedures
Packet Data Session Active, Data Flow via Target BS
ff
gg
hh
ii
A9-Release-A8
T
rel9

T
aldak

ll
T
regupd

T
regreq

Handoff Complete
y
1
Figure 3.19.4.3-1 (Cont.) Fast Handoff Superseded by Another Fast Handoff 2
a. User data flow is active using a PPP session between the MS and the anchor PDSN. 3
During the setup of the A10 connection(s), the anchor PDSN returned its P-P address 4
in the A11-Registration Reply message(s). The source PCF in turn relayed both the 5
Anchor PDSN and Anchor P-P Addresses to the source BS. The PCF also returned 6
the source PDSN Address to the BS during the setup of the A10 connection. 7
b. Based on an MS report that the MS crossed a network specified threshold for signal 8
recommends a cdma2000
to cdma2000

TIA-2001.3-C
267 Section 3
7
. The source BS includes the PANID 1
information in the Handoff Required message. It also includes the Source PDSN, 2
Anchor PDSN, and Anchor P-P addresses to request fast handoff. The Service 3
Configuration Record in this message identifies the active service instances. The 4
Service Option List information element identifies all dormant and active service 5
instances. 6
c. The MSC sends a Handoff Request message (which includes the PANID information 7
target BS. In this message it relays the Source PDSN, Anchor PDSN, and Anchor 9
P-P Addresses. The Service Configuration Record in this message identifies the 10
active service instances. The Service Option List information element identifies all 11
dormant and active service instances. The MSC starts timer T
11
. 12
d. The target BS sends an A9-Setup-A8 message to the target PCF to establish the 13
A8-Connection for each active service instance and starts an associated timer 14
T
A8-setup
. The handoff indicator field of the A9-Setup-A8 message is set to 1 15
(during handoff). The target BS includes the PDSN Address (set to the address of the 16
Source PDSN), Anchor PDSN Address, and Anchor P-P Address. 17
e. The target PCF determines it cannot establish A10 connection(s) with the anchor 18
PDSN or with the source PDSN and selects another PDSN, the target PDSN. The 19
target PCF sends an A11-Registration Request to the target PDSN for each active 20
service instance to be handed off. The lifetime field in each A11-Registration 21
Request message is set to T
presetup
, the S bit is set to 1 indicating simultaneous 22
binding, and the Anchor P-P Address NVSE is included to indicate a fast handoff 23
operation. Each A11-Registration Request message also includes the A10 24
Connection Setup Airlink Record. The target PCF starts the associated timer(s) 25
T
regreq
. 26
f. The target PDSN establishes a P-P connection with the anchor PDSN for each A11- 27
Registration Request received in step e and forwards the associated airlink records 28
to the anchor PDSN according to procedures specified in [8]. P-P connection 29
establishment is done concurrently with subsequent RAN procedures. 30
g. The target PDSN accepts the connection(s) and the fast handoff request by returning 31
A11-Registration Reply message(s) with the same Anchor P-P Address it received in 32
the A11-Registration Request message(s). The target PDSN buffers the airlink 33
records as it will need these for accounting purposes after the fast handoff completes 34
(assuming the target PDSN becomes the anchor PDSN at that point in time). The 35
target PCF stops the associated timer(s) T
regreq
.. 36
h. The target PCF sends A9-Connect-A8 message(s) to the target BS. The target PCF 37
indicates acceptance of the fast handoff by including the PDSN Address (set to the 38
address of the Target PDSN), Anchor PDSN, and Anchor P-P Addresses. When the 39
target BS receives an A9-Connect-A8 message it stops the associated timer T
A8-setup
. 40
waitho9
. Note that the target BS stores the Anchor PDSN and 41
Anchor P-P Addresses for use in the event that this fast handoff is superseded by 42
another fast handoff. 43
i. The target BS sends a Handoff Request Acknowledgment message to the MSC. The 44
9
stops timer T
11
. 46
j. The anchor PDSN forwards packet data to the source BS via the source PDSN and 47
the source PCF. It also forwards the data over the P-P connection(s) to the target 48
PDSN, which, in turn, forwards it to the target PCF. The target PCF discards the data 49
at this time. 50
TIA-2001.3-C
Section 3 268
k. The MSC prepares to switch the MS from the source BS to the target BS and sends a 1
7
. 2
l. The source BS sends an A9-AL Disconnected message to the source PCF. The BS 3
ald9
m. The PCF sends A9-AL Disconnected Ack message in response to the A9-AL 5
aldak
ald9
. 6
n. The source BS sends the General Handoff Direction Message or Universal Handoff 7
Direction Message to the MSand starts timer T
8
. If the MS is allowed to return to the 8
source BS, then timer T
waitho
o. The MS may acknowledge the General Handoff Direction Message or Universal 10
8
p. The source BS sends a Handoff Commenced message to the MSC to notify it that the 15
306
to 16
waitho
has been started 17
q. The MS sends a Handoff Completion message to the target BS. The target BS detects 20
9
. 21
r. The target BS sends the BSC Ack Order to the MS over the air interface. 22
s. Upon the receipt of the Handoff Completion message from MS, the target BS sends 23
an A9-AL (Air Link) Connected message to the target PCF and starts timer T
alc9
. 24
The target PCF stops timer T
waitho9
. 25
t. The target PCF stops discarding the user data it is receiving from the PDSN for each 26
active service instance upon receipt of the A9-AL (Air Link) Connected message and 27
begins forwarding the data to the target PCF. At this point, data flows bidirectionally 28
between the MS and the anchor PDSN. Data is still forwarded to the source PCF, 29
which discards the data. 30
u. For each active service instance, the target PCF sends an A11-Registration Request 31
message, containing an Active Start Airlink Record, T
rp
as lifetime and the S bit 32
cleared. The target PCF starts T
regreq
. 33
v. The A11 procedures in steps u and w are replicated on the P-P interface 34
according to procedures specified in [8]. This step may occur concurrently with 35
subsequent RAN procedures. 36
w. The PDSN sends an A11-Registration Reply message in response to each 37
A11-Registration Request message received in step u to the target PCF. The target 38
PCF stops each associated timer T
regreq
. 39
x. The target PCF sends an A9-AL (Air Link) Connected Ack message as response to 40
the A9-AL (Air Link) Connected message and stops timer T
alc9
. 41
y. The target BS sends a Handoff Complete message to the MSC to notify it that the 42
MS has successfully completed the hard handoff. Refer to [14] for detailed 43
procedures. 44
TIA-2001.3-C
269 Section 3
z. The target BS sends an A9-Setup-A8 message to target PCF for each dormant 1
service instance of the MS the A9-Setup-A8 has the Data Ready Indicator set to 2
zero. Steps z dd may occur anytime after step q. The target BS starts an 3
associated timer T
A8-setup
after each message is sent. 4
aa. The target PCF determines the MS is in fast handoff. The target PCF sends an A11- 5
Registration Request message to the same PDSN used for pre-setup A10 6
connection(s) to initiate A10 connection establishment for each dormant service 7
instance. The target PCF starts an associated timer T
regreq
for each message sent. The 8
A11-Registration Request message contains T
rp
as lifetime, zero S bit value, the 9
Mobility Event Indicator and Accounting Data (R-P Session Setup Airlink Record). 10
bb. The A11 procedures in steps aa and cc are replicated on the P-P interface 11
according to procedures specified in [8]. This step may occur concurrently with 12
subsequent RAN procedures. 13
cc. The PDSN determines the MS is in fast handoff. The PDSN returns an A11- 14
Registration Reply message in reply to each A11-Registration Request message 15
received in step aa to the target PCF. The A11-Registration Reply message does 16
not contain the Data Availability Indicator. The target PCF stops each associated 17
timer T
regreq
. 18
dd. The target PCF returns A9-Release-A8 Complete message for each A9-Setup-A8 19
message sent by the target BS. The target BS stops the associated timer(s) T
A8-setup
. 20
ee. The anchor PDSN initiates teardown of the P-P connections to the source PDSN 21
according to procedures specified in [8]. The accounting records received in step 22
hh are forwarded to the anchor PDSN. 23
ff. The source PDSN requests the source PCF to disconnect the A10 connection(s) (for 24
both active and dormant service instances) by sending A11-Registration Update 25
message(s). The source PDSN starts the associated timer(s) T
regupd
. 26
gg. The source PCF sends A11-Registration Acknowledge message(s) to the source 27
PDSN. The anchor PDSN stops the associated timer(s) T
regupd
. 28
hh. The source PCF sends A11-Registration Request message(s) with Lifetime value set 29
to 0 in response. The message(s) contain(s) a final Active Stop Airlink Record in 30
the case of active service instance(s). The source PCF starts timer T
regreq
31
ii. The source PDSN acknowledges this with A11-Registration Reply message(s). The 32
source PCF stops associated timer(s) T
regreq
. 33
jj. Upon receiving the Handoff Complete message from the target BS (in step y), the 34
MSC sends a Clear Command to the source BS. The source BS stops timer T
306
. The 35
MSC starts timer T
315
. 36
kk. The source BS sends an A9-Release-A8 message to the source PCF to release the 37
A8connection for each active service instance and starts an associated timer T
re19
. 38
The source PCF stops T
aldak
. 39
ll. Upon the receipt of the A9-Release-A8 message from the source BS, the source PCF 40
releases the A8 connection and responds with an A9-Release-A8 Complete message. 41
When the source BS receives the A9-Release-A8 Complete message it stops 42
associated timer T
re19
. 43
mm. The source BS sends a Clear Complete message to the MSC to notify it that clearing 44
315
. Clear Complete may occur any 45
time after the traffic channel is released. 46
TIA-2001.3-C
Section 3 270
nn. The fast handoff is completed after the packet data session transitions to the 1
Dormant State (refer to section 3.17.4.3.1) or when a subsequent fast handoff takes 2
place. Meanwhile, the anchor PDSN continues to serve the MS via P-P connections 3
to the target PDSN. 4
3.19.5 Intergeneration Packet Data Handoff 5
Throughout this section it is assumed that that MS is capable of supporting both 3G and 6
2G packet data services (refer to [23]) and both air interfaces as defined in [1]~[6] and 7
[10]. The message flows and timers between the MSC and the 2G BS in the figure are 8
outside the scope of this standard. For simplicity, timers on the 2G network are not 9
shown in the following call flows. 10
3.19.5.1 Hard Handoff from 2G System to 3G System 11
The MS is engaged in a 2G packet call on the 2G system. The packet data call needs to be 12
re-established on the 3G side, since 2G packet data service is not supported on the 3G 13
system. It is assumed that the 2G BS instructs the MS to reconnect the packet data service 14
upon completion of handoff (refer to [23]). After the MS has been acquired on the 3G 15
BS, the service option is negotiated and changed to 3G packet data service. In this call 16
flow, the box marked MSC may represent one or two MSCs. In the case of inter-MSC 17
handoff, ANSI-41 signaling is not specified. 18
TIA-2001.3-C
271 Section 3
MS 2G BS
time
(Handoff Required)
Handoff Request
a
b
c
e
f
Handoff Request Ack
g
h
Handoff Complete
i
k
l
j
PCF
PPP
m
n
p
r
o
q
(Handoff Command)
(Handoff Direction Message)
(MS Ack Order)
(Handoff Commenced)
(Clear Complete)
(Clear Command)
T
9

MSC
BS Ack Order
3G BS
s
PDSN
comment
A9-Setup-A8
A9-Connect-A8
TA8-setup
A9-AL Connected
A9-AL Connected Ack
t
Talc9
(Service Option Control Message)
Service Negotiation
u
v
T11
A11-Registartion Request
A11-Registartion Reply
w
T
regreqq

Null ForwardTraffic Channel frames
d
(T8)
1
2
Figure 3.19.5.1-1 Hard Handoff from 2G System to 3G System 3
strength or for other reasons, the 2G BS sends the equivalent of a Handoff Required 5
message to the MSC with a preferred list of target cells. 6
TIA-2001.3-C
Section 3 272
b. The 2G BS requires the MS to reconnect the packet data service upon successful 1
completion of the hard handoff (refer to [23]). 2
c. The MSC tries each of the elements in the preferred cell list until one cell is found 3
that has an available radio channel. The MSC sends a Handoff Request message to 4
the 3G BS, with a Service Option set to 2G packet data. The MSC starts timer T
11
. 5
d. Upon receipt of the Handoff Request message, the 3G BS allocates suitable idle 6
(radio) resources. The 3G BS starts transmitting null TCH data on the forward traffic 7
channel for the MS. 8
e. The 3G BS sends an A9-Setup-A8 message to the PCF with the Handoff indicator in 9
the A9 Indicators information element set to 1, and starts timer T
A8-setup
. 10
f. Upon receipt of the A9-Setup-A8 message, the PCF sends an A9-Connect-A8 11
message to the 3G BS. Upon receipt of the A9-Connect-A8 message, the 3G BS 12
stops timer T
A8-setup
. 13
g. The 3G BS returns a Handoff Request Acknowledge message to the MSC with 14
appropriate RF channel information and an IS-2000 service configuration record 15
containing a 2G packet data service option to allow the MS to be instructed to tune to 16
the new RF channel. The MSC stops timer T
11
. The 3G BS starts timer T
9
to wait for 17
the MS to arrive on the radio channel. 18
h. Upon receipt of the Handoff Request Acknowledge message from the 3G BS, the 19
MSC prepares to switch the MS from the 2G BS to the 3G BS. The MSC sends the 20
equivalent of a Handoff Command message to the 2G BS containing appropriate RF 21
channel information from the 3G BS. 22
i. The 2G BS instructs the MS to handoff by sending a handoff direction message and 23
starts the equivalent of timer T
8
. 24
j. The MS acknowledges receipt of the handoff direction message. The 2G BS stops 25
the equivalent of timer T
8
k. Upon receipt of confirmation from the MS, the 2G BS sends the equivalent of a 27
Handoff Commenced message to the MSC. 28
l. Upon synchronization of the traffic channel, the MS sends a Handoff Completion 29
Message to the 3G BS. The 3G BS stops timer T
9
. 30
m. The 3G BS acknowledges receipt of the Handoff Completion Message by sending a 31
BS Ack Order to the MS. 32
n. The MS attempts to reconnect the 2G-packet data service option. The 3G BS uses 33
service negotiation to instruct the MS to use the 3G packet data service. 34
o. The 3G BS sends an A9-AL Connected message to the PCF and starts timer T
alc9
. 35
p. The PCF sends an A11-Registration Request message with a non-zero Lifetime value 36
and with a Mobility Event Indicator within CVSE to the PDSN. The message 37
includes Accounting Data (R-P Session Setup Airlink). The PCF starts timer T
regreq
. 38
q. The A11-Registration Request message is validated and the PDSN accepts the 39
indication. If the PDSN has data for the MS, it responds to the PCF with an A11- 41
Registration Reply message with the Data Available Indicator in the CVSE. The 42
target PCF stops timer T
regreq
. 43
r. The PCF sends an A9-AL Connected Ack message to the 3G BS. The 3G BS stops 44
timer T
alc9
. 45
TIA-2001.3-C
273 Section 3
s. The 3G BS sends a Handoff Complete message to the MSC indicating successful 1
completion of hard handoff and that the 3G packet data service option has been 2
connected. 3
t. The PPP connection between the MS and the PDSN is established and the MS 4
performs MIP registration (if required) with the packet network. 5
u. User data is exchanged between the MS and the correspondent node over this A10 6
connection. 7
v. Upon receipt of a Handoff Complete message, the MSC initiates release of the MSC 8
resources used in the handoff. MSC sends the equivalent of a Clear Command 9
message to the 2G BS, informing it of the success of the hard handoff. 10
w. The 2G BS sends the equivalent of a Clear Complete message to the MSC 11
acknowledging success of the handoff. 12
3.19.5.2 Hard Handoff from 3G System to 2G System, PCF not used in the 2G system 13
The MS is engaged in a 3G packet call on the 3G system. The packet data call needs to be 14
re- negotiated to 2G on the 3G side, since 3G packet data service is not supported on the 15
2G system. In this call flow, the box marked MSC may represent one or two MSCs. In 16
the case of inter-MSC handoff, ANSI-41 signaling is not specified. 17
TIA-2001.3-C
Section 3 274
Twaitho
MS 3G BS
time comment
Handoff Required
a
b
c
d
e
f
(Handoff Complete)
g
i
k
h
PCF
l
m
o
n
p
Handoff Command
T7
MS Ack Order
Handoff Commenced
j
(Handoff Completion Message)
Clear Complete
Clear Command
T315
T306
MSC
(BS Ack Order)
2G BS PDSN
A9-AL Disconnected
Tald9
A9-Release A8
A9-Release A8 Complete
Trel9
q
(Handoff Request)
x
A11-Registartion Update
A11-Registartion Acknowledge
A11-Registartion Request
A11-Registartion Reply
Tregupd
Tregreq
r
s
t
Null forward traffic channels frames
u
Taldak
T8
1
2
Figure 3.19.5.2-1 Hard Handoff from 3G System to 2G System 3
TIA-2001.3-C
275 Section 3
strength or for other reasons, the 3G BS sends a Handoff Required message to the 2
MSC with a preferred list of target cells and starts timer T
7
. 3
b. The MSC tries each of the elements in the preferred cell list until one cell is found 4
that has an available radio channel. The MSC sends the equivalent of a Handoff 5
Request message to the 2G BS with a 2G packet data service option. 6
c. Upon receipt of the equivalent Handoff Request message, the2G BS allocates 7
suitable idle (radio) resources. The BS starts transmitting null TCH data on the 8
forward traffic channel for the MS. 9
d. The 2G BS returns the equivalent of a Handoff Request Acknowledge message to the 10
MSC with appropriate RF channel information to allow the MS to be instructed to 11
tune to the new RF channel. 12
e. The MSC prepares to switch the MS from the 3G BS to the 2G BS. The MSC sends 13
a Handoff Command message to the 3G BS containing appropriate RF channel 14
information and a IS-2000 service configuration record containing a 2G packet data 15
service option received from the 2G BS. The 3G BS stops timer T
7
. 16
f. The 3G BS sends an A9-AL Disconnected message to the PCF. The 3G BS starts 17
timer T
ald9
. 18
g. The PCF sends an A9-AL Disconnected Ack message to the 3G BS and starts timer 19
T
aldak
. The 3G BS stops timer T
ald9
. 20
h. BS sends the Handoff Direction Message to the MS and starts timer T
8
. The message 21
instructs the MS to handoff and change to the 2G packet data service option. If the 22
MS is allowed to return to the 3G BS, the 3G BS starts timer T
waitho
. 23
i. The MS may acknowledge receipt of the handoff direction message by sending an 24
MS Ack Order message to 3G BS. The 3G BS stops timer T
8
message. 26
j. The 3G BS sends a Handoff Commenced message to the MSC to notify it that the 27
MS has been ordered to move to the 2G BS channel. The 3G BS starts timer T
306
. If 28
timer T
waitho
has been started, the 3G BS shall wait for that timer to expire before 29
sending the Handoff Commenced message.. 30
k. Upon synchronization of the traffic channel, the MS sends the equivalent of a 31
Handoff Completion Message to the 2G BS. 32
l. The 2G BS sends the equivalent of a BS Ack Order to the MS. 33
m. The 2G BS sends the equivalent of a Handoff Complete message to the MSC 34
indicating successful completion of the hard handoff and that the 2G packet data 35
service has been connected. 36
n. The MSC initiates release of the MSC resources used in the handoff. The MSC sends 37
a Clear Command message to the 3G BS, informing it of the success of the hard 38
handoff, and starts timer T
315
. The 3G BS stops timer T
306
message. 40
o. The 3G BS sends an A9-Release A8 message to the PCF and starts timer T
rel9
. The 41
PCF stops timer T
aldak
upon receipt

of this message. 42
p. The PCF sends an A9-Release A8 Complete message to the 3G BS; the 3G BS stops 43
timer T
rel9
. 44
TIA-2001.3-C
Section 3 276
q. The 3G BS sends a Clear Complete message to the MSC acknowledging success of 1
the handoff. The MSC stops timer T
315
r. At the expiration of the PPP timer or other internal event, the PDSN initiates release 3
of the A10 connection with the PCF by sending an A11-Registration Update 4
message. The PDSN starts timer T
regupd
. 5
s. The PCF responds with an A11-Registration Acknowledge message to PDSN. The 6
PDSN stops timer T
regupd
. 7
t. The PCF sends an A11-Registration Request message with Lifetime set to zero, to 8
the PDSN. The PCF starts timer T
regreq.
9
u. The PDSN sends the A11-Registration Reply message with an accept indication to 10
the PCF. The PCF releases the A10 connection.. 11
3.19.5.3 Intra-PCF Hard Handoff from 3G BS to 2G BS 12
The MS is engaged in a 3G packet call on the 3G BS. The 3G BS and the 2G BS are both 13
connected to the same PCF. 14
TIA-2001.3-C
277 Section 3

MS 3G BS PCF
Time
Comment
a
b
c
d
e
f
Handoff Required
(Handoff Request)
2G BS
g
i
h
j
k
l
m
T306
T315
Twaitho
x
MSC
(A9-Setup-A8)
(A9-Connect-A8)
Handoff Command
Handoff Commenced
T7
(Handoff Completion)
(A9-AL Connected)
(A9-AL Connected Ack)
(Handoff Complete)
Clear Command
A9-Release-A8
A9-Release Complete-A8
Clear Complete
MS Ack Order
(BS Ack Order)
n
o
p
q
A9-AL Disconnected
r
s
Tald9
Tre19
t
Null forward traffic channels frames
u
T8
Taldak
1
2
Figure 3.19.5.3-1 Intra-PCF Hard Handoff from 3G BS to 2G BS 3
strength or for other reasons, the 3G BS recommends a hard handoff to one or more 5
cells in the domain of the 2G BS. The 3G BS sends a Handoff Required message 6
with the list of cells to the MSC and starts timer T
7
. 7
b. The MSC sends the equivalent of a Handoff Request message to the 2G BS with a 8
2G packet data service option. 9
TIA-2001.3-C
Section 3 278
c. Upon receipt of the equivalent Handoff Request message, the 2G BS allocates 1
suitable idle (radio) resources. The BS starts transmitting null TCH data on the 2
forward traffic channel for the MS. 3
d. The 2G BS sends the equivalent of an A9-Setup-A8 message to the PCF to establish 4
the A8-Connection. In this case, the handoff indicator field of the equivalent A9- 5
Setup-A8 message is set to 1 (during handoff). 6
indicator field of the equivalent A9-Setup-A8 message is set to 1 (during handoff). 8
e. The PCF establishes the A8 connection, and continues to forward packet data 9
received from PDSN to the 3G BS (i.e., the 2G BS doesnt receive packet data from 10
the PCF). The PCF sends the equivalent of an A9-Connect-A8 message to the 2G 11
BS. 12
f. The 2G BS sends the equivalent of a Handoff Request Acknowledge message to the 13
MSC with appropriate RF channel information to allow the MS to be instructed to 14
tune to the new RF channel. 15
g. The MSC prepares to switch the MS from the 3G BS to the 2G BS. The MSC sends 16
a Handoff Command message to the 3G BS containing appropriate RF channel 17
information and a IS-2000 service configuration record containing a 2G packet data 18
service option received from the 2G BS. The 3G BS stops timer T
7
. 19
h. The PCF stops packet transmission to the 3G BS upon receipt of A9-AL (Air Link) 20
Disconnected message from the 3G BS. The 3G BS starts timer T
ald9
. 21
i. The PCF sends an A9-AL (Air Link) Disconnected Ack message in response to the 22
A9-AL Disconnected message. The PCF starts timer T
aldak
. The 3G BS stops timer 23
T
ald9
. 24
j. The 3G BS sends the handoff direction message to the MS and starts timer T
8
. The 25
message instructs the MS to handoff and change to 2G packet data service option. If 26
the MS is allowed to return to the 3G BS, then the 3G BS starts timer T
waitho
. 27
k. The MS may acknowledge the Handoff Direction Message by sending an MS Ack 28
8
l. The 3G BS sends a Handoff Commenced message to the MSC to notify it that the 30
MS has been ordered to move to the 2G BS channel. The 3G BS starts timer T
306
. If 31
timer T
waitho
has been started, the 3G BS shall wait for that timer to expire before 32
sending the Handoff Commenced message. 33
m. Upon synchronization of the traffic channel the MS sends the equivalent of a 34
Handoff Completion message to the 2G BS. 35
n. The 2G BS sends the equivalent of a BS Ack Order to the MS over the air interface. 36
o. The 2G BS sends the equivalent of an A9-AL (Air Link) Connected message to the 37
PCF. The PCF restarts packet data transmission to the 2G BS. 38
p. The PCF sends the equivalent of an A9-AL Connected Ack message to the 2G BS. 39
q. The 2G BS sends the equivalent of a Handoff Complete message to the MSC to 40
notify it that the MS has successfully completed the hard handoff and that the 2G 41
packet data service has been connected. 42
r. The MSC sends a Clear Command message to the 3G BS and starts timer T
315
. The 43
3G BS stops timer T
306
TIA-2001.3-C
279 Section 3
s. The 3G BS sends an A9-Release-A8 message to the PCF to release the A8 1
connection and starts timer T
re19
aldak
. 2
t. Upon the receipt of the A9-Release-A8 message from the 3G BS, the PCF releases 3
the A8 connection and responds with an A9-Release-A8 Complete message. Upon 4
receiving A9-Release-A8 message the 3G BS stops timer T
re19
. 5
u. The 3G BS sends a Clear Complete message to the MSC to notify it that clearing has 6
been accomplished. The MSC stops timer T
315
. 7
3.19.5.4 Dormant Handoff from 2G System to 3G System 8
The MS is engaged in a 2G packet call on the 2G system and is dormant. The packet data 9
call needs to be re-established on the 3G side, since 2G packet data service is not 10
supported on the 3G system. The call flow is identical to the call flow shown in 11
3.17.4.10. Dormant Handoff (Inter-BS/Inter-PCF) - Mobile served by a different PDSN. 12
3.19.5.5 Dormant Handoff from 3G System to 2G System 13
If a dormant MS roams to a 2G system, the procedures on the 3G system simply allow for 14
the A10 link to be torn down when the PPP timer expires. Refer to section 3.17.5.9 Inter- 15
PCF Dormant Handoff Mobile Served by a New Target PDSN. Step l through o. 16
3.19.6 Alternate Dormant Handoff 17
This section contains call flows for the Alternate Dormant Handoff feature. 18
handoff of each of its dormant packet data service instances. The packet data session may 20
become active as a result of the dormant handoff of one packet data service instance (i.e. 21
PDSN has data to send to MS over that packet data service instance) in which case the 22
dormant handoff of the remaining packet data service instances occur as given in section 23
3.17.4.9.2. 24
3.19.6.1 Intra-PDSN Alternate Dormant Handoff of a PDSI, While the Packet Data 25
Session is Dormant 26
The following call flow provides an illustration for a successful handoff of a dormant 27
packet data service instance during the Dormant State of the packet data session from 28
source PCF to target PCF. It is assumed that the PCF is uniquely identified by the 29
CANID. On detection of a new PZID, NID or SID, the MS sends an Origination Message 30
to the target BS that includes the packet data service option and the DRS bit set to 0. 31
The Origination Message includes the previous PZID, NID and SID when any of these 32
parameters change during the dormant handoff. The MS sends an Origination or 33
Enhanced Origination message for each of its dormant packet data service instances. 34
Based on the IDs (PZID, NID and/or SID) in the Origination Message, the target PCF 35
sends the PANID of the source PCF and the CANID of the target PCF to the serving 36
PDSN. The serving PDSN uses this information to determine whether or not PPP re- 37
negotiation is required over the main packet data service instance. 38
The BS does not establish a traffic channel when it receives an origination message with 39
DRS set to 0; a traffic channel may be established after the completion of setup of the 40
A8 and A10 bearer connections if the PDSN has data for the MS. The following call flow 41
shows the case where MS uses Origination Message to handoff a packet data service 42
TIA-2001.3-C
Section 3 280
instance. Refer to section 3.17.4.9.2 for the case where MS uses Enhanced Origination to 1
handoff a packet data service instance. Since the PDSN already has a PPP session for this 2
MS, PPP negotiation is not required and the traffic channel is not needed in this scenario. 3

ADDS-Transfer Ack
a
b
c
d
e
f
g
h
PDSN Target PCF MS
ADDS-Transfer
Origination Message
A9-Setup-A8
BS Ack Order
Packet Data Session Dormant, PPPconnection is maintained
T
A8-setup

Target BS
T
60

Release Order
k
l
m
n
p
o
T
regreq
ADDS-Transfer Ack
i
j
Optional
T
regupd
4
Figure 3.19.6.1-1 Alternate Dormant Handoff of a PDSI (Inter-BS/Inter-PCF) - Mobile Served by 5
Same PDSN, Packet Data Session Dormant 6
a. It is assumed that the MS has established a PPP connection with the PDSN and 7
performed a MIP registration (if required) but the packet data session is now 8
b. The dormant MS detects a change of PZID, SID or NID and initiates an origination 10
with the DRS bit set to 0. 11
TIA-2001.3-C
281 Section 3
c. Target BS acknowledges the receipt of the Origination Message with a Base Station 1
d. The target BS sends an ADDS Transfer message to the MSC with the Data Burst 3
Type field of the ADDS User Part element set to Asynchronous Data Services, the 4
authentication parameters received from the MS, and the BS computed 5
authentication data element included in the message. The BS starts timer T
60
. 6
e. The MSC optionally sends an ADDS Transfer Ack message indicating concurrent 7
authentication and packet data setup to the target BS. This allows the BS to proceed 8
with step f. If the MSC does not send this message, steps f through i occur after 9
step j. 10
f. The target BS sends an A9-Setup-A8 message, with Data Ready Indicator set to 0, 11
to the target PCF and starts timer T
A8-setup
. The handoff indicator of the A9 12
g. The target PCF sends an A11-Registration Request message to the PDSN. The 14
Registration Request message includes the Mobility Event Indicator within a CVSE 15
and a non-zero Lifetime. This message also includes Accounting Data (R-P Session 16
Setup Airlink Record) as well as ANID information (PANID/CANID). The PCF 17
starts timer T
regreq
. 18
h. The A11-Registration Request message is validated and the PDSN accepts the 19
indication. If the PDSN supports fast handoff the Anchor P-P Address is included. If 21
the PCF does not support fast handoff it ignores the Anchor P-P Address. If the 22
PDSN has data to send, it includes the Data Available Indicator within a CVSE. The 23
A10 connection binding information at the PDSN is updated to point to the target 24
PCF. The PCF stops timer T
regreq
. 25
i. The PCF responds to the BS with an A9-Release-A8 Complete message. The BS 26
stops timer T
A8-setup
. 27
If the PDSN responds to the PCF with a Data Available Indicator in step h, the PCF 28
responds to the BS with an A9-Connect-A8 message with Cause element set to Data 29
ready to send. In this case, the BS establishes a traffic channel as described in 30
Figure 3.19.6.2-1 steps i through p and the following two steps are skipped. 31
j The MSC sends an ADDS Transfer Ack message to the MS indicating successful 32
authentication of the MS. The BS stops timer T
60
. 33
k. The target BS may send a Release Order to the MS. This allows the MS to send 34
Origination Messages for remaining packet data service instances sooner. 35
l. The PDSN initiates release of the A10 connection with the source PCF by sending an 36
regupd
. 37
m. The source PCF responds with an A11-Registration Acknowledge message. The 38
PDSN stops timer T
regupd
. 39
n. The source PCF sends an A11-Registration Request message with Lifetime set to 40
zero, to the PDSN. The PCF starts timer T
regreq
. 41
o. The PDSN sends the A11-Registration Reply message with an accept indication to 42
the source PCF. The source PCF releases the A10 connection for the MS. The PCF 43
stops timer T
regreq
. If the MS sends an Origination Message with DRS = 0 for 44
additional dormant service instances (this may occur any time after step k or when 45
timer T
42m
expires for the last dormant service instance handed off), this procedure 46
is repeated for each such service instance. 47
TIA-2001.3-C
Section 3 282
p. The packet data session remains dormant. 1
3.19.6.2 Alternate Dormant Handoff of a PDSI (Inter-BS/Inter-PCF) - Mobile Served by a 2
Different PDSN 3
This section provides call flows for the case where an MS with a packet data session in 4
Dormant State moves into a different packet zone and ends up being connected to a 5
different PDSN. 6
TIA-2001.3-C
283 Section 3

MS
Origination
BS ACK Order
MSC
CM Service Request
A9-setup-A8
Assignment Request
Target
PDSN
A9-Connect-A8
Assignment Complete
a
b
h
i
e
f
g
k
T
303

T
10

T
A8-Setup

A9-Update-A8
A9-Update-A8 Ack
T
upd9

l
m
TCH
Establishment
Time
Target
BS
n
Comment
o
q
ADDS Transfer
ADDS Transfer Ack
c
d T
60

T
regreq
T
regreq
r
s
T
regreq
t
u
T
regreq
j
p
Source
PCF
Target
PCF
Source
PDSN
1
2
Figure 3.19.6.2-1 Alternate Dormant Handoff of a PDSI (Inter-BS/Inter-PCF) - Mobile Served by a 3
Different PDSN 4
a. The MS with a dormant packet data session detects a change of PZID, SID or NID 5
and initiates an origination with the DRS bit set to 0. 6
TIA-2001.3-C
Section 3 284
b. The target BS acknowledges the receipt of the Origination Message with a Base 1
c. The target BS sends an ADDS Transfer message to the MSC with the Data Burst 3
Type field of the ADDS User Part element set to Asynchronous Data Services, the 4
authentication parameters received from the MS, and the BS computed 5
authentication data element included in the message. The BS starts timer T
60
. 6
d. The MSC sends an ADDS Transfer Ack message indicating successful 7
authentication of the MS to the BS. The BS stops timer T
60
. Alternately, the MSC 8
sends an ADDS Transfer Ack message indicating concurrent authentication of the 9
MS to the BS. In this case the BS does not stop timer T
60
. 10
e. The BS transmits an A9-Setup-A8 message to the PCF, with DRS=0, to establish 11
an A8 connection and starts timer T
A8-setup
. The Handoff Indicator of the A9 12
f. The target PCF initiates establishment of the A10 connection by sending an A11- 14
Registration Request message with non-zero Lifetime value to the target PDSN. The 15
message includes the Mobility Event Indicator within a CVSE and a non-zero 16
Record) as well as ANID information (CANID/PANID). The PCF starts timer 18
T
regreq
. 19
g. The A11-Registration Request message is validated and the target PDSN accepts the 20
indication and Data Available Indicator within a CVSE. If the PDSN supports fast 22
handoff the Anchor P-P Address is included. If the PCF does not support fast 23
handoff it ignores the Anchor P-P Address. The PCF stops timer T
regreq
. 24
and transmits an A9-Connect-A8 message with Cause set to Data ready to send. If 26
fast handoff is supported, the PCF passes the Anchor P-P Address and the Target 27
PDSN IP Address to the BS as part of this message. Upon reception of the A9- 28
Connect-A8 message, the BS stops the timer T
A8-setup
. 29
i. The BS constructs the CM Service Request message, places it in the Complete Layer 30
303
. The 31
message includes the Authentication Event information element indicating that 32
authentication was recently requested. The BS stops the timer T
60
if it is still 33
running. 34
j. The MSC sends an Assignment Request message to the BS to request assignment of 35
10
. For packet data services, a terrestrial circuit 36
between the MSC and the BS is not required. The BS stops timer T
303
. 37
k. The BS initiates the establishment of a radio traffic channel. 38
l. After the radio link is established, the BS sends an Assignment Complete message to 39
the MSC. The MSC stops timer T
10
. 40
m. The BS sends an A9-Update-A8 message to the PCF to pass Accounting Parameters. 41
upd9
. 42
n. The PCF sends an A11-Registration Request message containing an Airlink Start 43
accounting record. The PCF starts timer T
regreq
. 44
o. The PDSN updates the accounting data and returns an A11-Registration Reply 45
message with an accept indication back to the PCF. The PCF stops timer T
regreq
. 46
TIA-2001.3-C
285 Section 3
p. The PCF, upon receipt of the A9-Update-A8 message, responds with an A9-Update- 1
A8 Ack message. Upon receipt of this message, the BS stops timer T
upd9
. 2
q. PPP connection establishment procedure and Mobile IP Registration (if required) on 3
the PPP connection (over main packet data service instance) are performed between 4
the MS and PDSN. Refer to section 3.17.4.9.2 for the handoff of the additional 5
packet data service instances. 6
r. On expiration of the PPP timer or other events internal to the source PDSN, the 7
a Registration Update message. The PDSN starts timer T
regupd
. 9
s. The source PCF responds with an A11-Registration Acknowledge message. The 10
regupd
. 11
t. The source PCF sends an A11-Registration Request message with Lifetime set to 12
zero. The source PCF starts timer T
regreq
. 13
u. The source PDSN stores the accounting related information for further processing 14
before returning A11-Registration Reply message with an accept indication. The 15
source PCF releases the A10 connection for the MS. The source PCF stops timer 16
T
regreq
. 17
3.19.6.3 Alternate Dormant Handoff of a PDSI (Inter-BS/Inter-PCF) - with Concurrent 18
Authentication Mobile Served by Same PDSN, Failed Authentication in MSC 19
Following session establishment (PDSN Does Not Have Data to Send) 20
This scenario is similar to the one in section 3.17.4.12, except that the Alternate Dormant 21
Handoff feature is used. The MSC sends the ADDS Transfer Ack message indicating 22
concurrent authentication of the MS to the BS. If authentication of the MS later fails, the 23
MSC sends a second ADDS Transfer Ack message to the BS with the Authentication 24
failure cause value and the same TAG value as was received in the ADDS Transfer 25
message from the BS. The BS then uses the A9-Update-A8 message to alert the PCF that 26
it should tear down the A10 connection for that MS. Note: Authentication of the MS shall 27
also be considered to have failed if timer T
60
expires prior to reception of the 28
authentication results in the second ADDS Transfer Ack message from the MSC after a 29
configurable number of retries. 30
TIA-2001.3-C
Section 3 286
a
PDSN Target PCF MS
Target BS
Release Order
d
ADDS Transfer Ack
T
60

e
i Packet Data Session Null/Inactive
MS authentication
failure
c
A9-Update-A8
A9-Update-A8 Ack
T
upd9

A10 Release
Procedures
f
g
h
Intra-PDSNDormant Handoff Procedures
b
1
Figure 3.19.6.3-1 Alternate Dormant Handoff of a PDSI (Inter-BS/Inter-PCF) with Concurrent 2
Authentication - Mobile Served by Same PDSN, Failed Authentication in MSC Following Session 3
Establishment (PDSN Does Not Have Data to Send) 4
established a PPP connection with the PDSN but is now dormant. 6
b. The MS with a dormant packet data session detects a change of PZID, SID or NID 7
and initiates a dormant handoff, which results in the MS being served by the same 8
PDSN. Refer to Figure 3.19.6.1-1, steps b through i. During this step, the MSC 9
requests the BS to proceed with the handoff before it has authenticated the MS. 10
Timer T
60
is still running. 11
c. The MSC receives authentication results from the authentication center indicating 12
that authentication has failed. 13
d. The MSC sends the ADDS Transfer Ack message to the BS indicating that 14
authentication has failed. The BS stops timer T
60
. 15
Rejected. 17
f. The target BS informs the target PCF via an A9-Update-A8 message containing an 18
update reason parameter indicating Authentication failed. The target BS starts 19
timer T
upd9
. The BS uses the SR_ID of any of the dormant service instances in the 20
A9-Update-A8 message. 21
TIA-2001.3-C
287 Section 3
sending an A11-Registration Request message with Lifetime value is set to 0 to the 2
PDSN for each packet data service instance. 3
h. At response from the PDSN, the target PCF sends an A9-Update-A8 Ack message 4
back to the BS. The target BS stops timer T
upd9
. 5
i. The packet data session is in the Null/Inactive State. 6
3.20 Security Features 7
This chapter discusses security features supported by the IOS. 8
3.20.1 Authentication and Privacy 9
The following table indicates the requirements for Authentication and Privacy while the 10
MS is idle, during registration, during origination, during termination, and during a call. 11
The table further illustrates whether the authentication is required for the Paging/Access 12
Channel and/or the traffic channel. 13
Table 3.20.1-1 Authentication and Voice Privacy Requirements 14
STATE On PAGING/ACCESS On TRAFFIC
While IDLE
Global Challenge N/A N/A
Unique Challenge Required N/A
SSD Update Not Required N/A
Parameter Update (Count) N/A N/A
Voice Privacy On/Off N/A N/A
Data Privacy On/Off Required N/A
During REGISTRATION
Global Challenge Required N/A
Unique Challenge Not Required N/A
SSD Update N/A N/A
Parameter Update (Count) N/A N/A
Voice Privacy On/Off N/A N/A
Data Privacy On/Off N/A N/A
15
TIA-2001.3-C
Section 3 288
Table 3.20.1-1 (Cont.) Authentication and Voice Privacy Requirements 1
STATE On PAGING/ACCESS On TRAFFIC
During ORIGINATION
Unique Challenge N/A (Refer to: During Call)
SSD Update N/A (Refer to: During Call)
Parameter Update (Count) N/A (Refer to: During Call)
Voice Privacy On/Off N/A Required
Data Privacy On/Off N/A Required
During TERMINATION
Unique Challenge N/A (Refer to: During Call)
SSD Update N/A (Refer to: During Call)
Parameter Update (Count) N/A (Refer to: During Call)
During CALL
Global Challenge N/A N/A
Unique Challenge N/A Required
SSD Update N/A Required
Parameter Update (Count) N/A Not Required
The assumptions in this specification are: 2
the BS shall be able to generate the RAND parameter 3
the MSC shall support BS generated RAND authentication 4
The SSD update procedure involves the exchange of the following A1 messages: 5
SSD Update Request 6
Base Station Challenge 7
Base Station Challenge Response 8
SSD Update Response 9
3.20.1.1 SSD Update Procedure - Successful Case 10
The call flow in Figure 3.20.1.1-1 provides an illustration of a Shared Secret Data (SSD) 11
Update procedure. 12
TIA-2001.3-C
289 Section 3
MS BS MSC
time comment
SSD Update Message
Base Station Challenge Order
a
b
c
d
SSD Update Request
Base Station Challenge
T3270
Base Station Challenge Confirmation Order
SSD Update Confirmation Order
e
f
g
h
Base Station Challenge Response
SSD Update Response
T3271
1
Figure 3.20.1.1-1 SSD Update - Successful Case 2
a. The MSC sends an SSD Update Request message to the BS to indicate that the 3
Shared Secret Data at the MS needs updating. The update information is in the form 4
of a random number (RANDSSD) that is used by the MS to calculate the new SSD. 5
3270
. 6
b. Based on the SSD Update Request message from the MSC, the BS sends the SSD 7
Update message to indicate to the MS that it should update its SSD. 8
c. Upon receipt of the SSD Update message from the BS, the MS uses the RANDSSD 9
as input to the algorithm to generate the new SSD. The MS then selects a 32 bit 10
random number (RANDBS) and sends it to the BS in a Base Station Challenge Order 11
message. 12
d. The BS forwards the Base Station Challenge message to the MSC to verify the new 13
SSD calculated at the MS is the same as the SSD calculated by the network. The 14
MSC stops timer T
3270
. 15
e. Upon reception of the Base Station Challenge message, the MSC uses the new SSD 16
as input to the algorithm to generate the authentication response signature 17
(AUTHBS). The MSC then sends the authentication response signature (AUTHBS) 18
to the BS in the Base Station Challenge Response message. The MSC starts timer 19
T
3271
. 20
f. Upon receipt of the Base Station Challenge Response message from the MSC, the 21
BS transmits this information in a Base Station Challenge Confirmation Order 22
g. If the AUTHBS from the MSC is valid, the MS returns an SSD Update Confirmation 24
Order message to the BS. 25
If the AUTHBS from the MSC is invalid, the MS returns an SSD Update Rejection 26
Order message to the BS. 27
TIA-2001.3-C
Section 3 290
h. The BS forwards the information in the SSD Update Response message to the MSC. 1
3271
. 2
3.20.1.2 Terminal Authentication 3
This procedure is performed when the MSC wants to initiate an authentication check (a 4
unique challenge) on a specified MS. 5

MS BS MSC
time comment
Authentication Challenge Response
Authentication Challenge
a
b
c
d
Authentication Response
T3260
Authentication Request
6
Figure 3.20.1.2-1 Terminal Authentication 7
a. The MSC sends the Authentication Request to the BS and starts timer T
3260
. 8
b. The BS forwards the information (RANDU) to the MS in an Authentication 9
Challenge Message over the air interface. 10
c. The MS computes the result AUTHU based on the specified RANDU and the MSs 11
SSD. It then returns an Authentication Challenge Response Message to the BS with 12
the enclosed AUTHU. 13
d. The BS forwards the AUTHU information to the MSC using the Authentication 14
Upon receipt of the Authentication Response message from the BS the MSC stops 16
timer T
3260
. 17
3.20.1.3 Parameter Update 18
This procedure is performed when the MSC is instructed to update the call history count 19
(COUNT) at the MS. 20
TIA-2001.3-C
291 Section 3
Time
T3220
a
b
c
d
MS BS
MSC
Parameter Update Request
Parameter Update Order
Parameter Update Confirmation Order
Parameter Update Confirm
Comment
1
Figure 3.20.1.3-1 Parameter Update 2
a. The MSC sends the Parameter Update Request message to request that the MS 3
update its call history count. The MSC starts timer T
3220
. 4
b. The BS sends a Parameter Update Order to the MS. 5
c. The MS increments its call history count and returns a Parameter Update 6
Confirmation Order to acknowledge that the update was successful. 7
d. The BS sends the Parameter Update Confirm message to the MSC indicating that the 8
MS incremented its call history count. Upon receipt of this message the MSC 9
updates the call history count and stops timer T
3220
. 10
3.20.1.4 Privacy Mode Procedure 11
This section describes the call flow associated with voice privacy activation. 12
If broadcast challenge is not active in the system, then voice privacy cannot be invoked. 13
The privacy mode procedure should be completed either before handoff is initiated or 14
after a handoff operation is complete. 15
Voice Privacy is shown here being invoked during an established call. 16
MS BS MSC
time comment
d
Privacy Mode Complete
a
Privacy Mode Command
Mobile Order
Mobile Response
b
c
T3280
17
Figure 3.20.1.4-1 Privacy Mode Procedure 18
TIA-2001.3-C
Section 3 292
a. The MSC at any point during the call following the receipt of the Assignment 1
Complete message may send the Privacy Mode Command message to the BS to 2
specify that privacy is to be provided for traffic information. The MSC starts timer 3
T
3280
. 4
b. After the radio traffic channel has been acquired, voice privacy can be established 5
when the BS transmits a voice privacy request order to the MS. 6
c. The MS performs the required privacy mode procedures and acknowledges the BS 7
with a voice privacy response order. 8
d. The BS returns the Privacy Mode Complete message to the MSC to indicate 9
successful receipt of the Privacy Mode Command message. The MSC stops timer 10
T
3280
upon receipt of the Privacy Mode Complete message. 11
3.21 Flex Rate 12
This section describes the procedures to support soft handoff when Flex Rate is in use. 13
For forward bursts, the assigned Flex Rate is transmitted to the target base stations by 14
sending the FOR_SCH_NUM_BITS_IDX in the Forward Supplemental Channel Rate 15
field of the Forward Burst Radio Info element in the A7-Burst Request and A7-Burst 16
Commit messages. For reverse bursts, the assigned Flex Rate is transmitted to the target 17
base stations by sending the REV_SCH_NUM_BITS_IDX in the Reverse Supplemental 18
Channel Rate field of the Reverse Burst Radio Info element in the A7-Burst Request and 19
A7-Burst Commit messages. 20
User data traffic frames sent on the A3 link use the Frame Content field to indicate either 21
the data rate that the frame is to be transmitted at (Forward Link) or the data rate that the 22
frame was received at (Reverse Link). For Flex Rate, the four least significant bits of this 23
field are used to indicate either REV_SCH_NUM_BITS_IDX or 24
FOR_SCH_NUM_BITS_IDX. 25
This feature utilizes the same call flows as soft/softer handoff using direct BS-to-BS 26
signaling. Refer to section 3.19.3.2. 27
3.22 Status Inquiry 28
This section describes the call flow associated with Status Inquiry. 29
3.22.1 Status Inquiry Example 30
The following call flow provides an illustration of the status inquiry procedure. 31
TIA-2001.3-C
293 Section 3

MS BS MSC
time comment
a
c
Status Request
Status Response
Status Response Message
Status Request Message
b
d
T3272
1
Figure 3.22.1-1 Status Inquiry 2
a. The MSC sends a Status Request message to the BS to request certain MS 3
capabilities and starts timer T
3272
. The type of capability information requested is 4
included in the Information Record Requested element. 5
b. The BS forwards the request for information to the MS in one of the following 6
CDMA air interface messages: 7
1. the Status Request Order on the traffic channel, 8
2. the Status Request Message on the traffic channel or the Paging 9
Channel. 10
c. The MS returns the requested information to the BS in one of the following CDMA 11
air interface messages: 12
1. the Status Message on the traffic channel, 13
2. the Status Response Message on the traffic channel or the Access 14
Channel. 15
d. The BS returns the requested information in the MS Information Records element of 16
the Status Response message. The MSC stops timer T
3272
. 17
3.23 3X Multi-Carrier Operation 18
This section describes how 3X Multi-Carrier operation can be implemented using 19
existing messages and information elements. 20
3.23.1 Hard Handoff Support 21
The following messages are impacted: 22
Handoff Request: The IS-2000 Channel Identity 3X information element is sent in place 23
of the IS-2000 Channel Identity information element. 24
TIA-2001.3-C
Section 3 294
Handoff Request Acknowledge: The IS-2000 Channel Identity 3X information element 1
is sent in place of the IS-2000 Channel Identity information element. 2
Handoff Command: The IS-2000 Channel Identity 3X information element is sent in 3
place of the IS-2000 Channel Identity information element. 4
3.23.2 Soft Handoff Support 5
The following messages are impacted: 6
A7 Handoff Request: In the Physical Channel Info information element, the AFRCN 7
field refers to the center 3X frequency. Indication of the use of 3X Multi-Carrier is 8
contained in the IS-2000 Service Configuration Record. 9
A7 Burst Response: In the Forward Burst Radio Info information element, the SR3 Incl 10
bit should be set to 1, and the proper QOF Mask and Forward Code Channel 11
information coded for all three carriers. 12
A7 Burst Commit: In the Forward Burst Radio Info information element, the SR3 Incl 13
bit should be set to 1, and the proper QOF Mask and Forward Code Channel 14
information coded for all three carriers. 15
A3 Connect: In the A3 Connect Information information element, for each cell record, 16
the SR3 Incl bit should be set to 1 and the proper QOF Mask and Forward Code 17
Channel information coded for all three carriers. 18
3.24 5 ms Messaging 19
This section outlines how 5 ms messaging is supported in the IOS. 20
3.24.1 Forward Link 21
When a 5 ms message is to be sent to an MS that is in soft handoff, the source BS 22
includes the message in either an A3-FCH Forward Traffic Frame or an A3-DCCH 23
Forward Traffic frame, depending on which physical channel the message is being sent. 24
The Air Interval Content Mask field of the FCH/DCCH Forward Air Interval Control 25
information element indicates in which 5 ms slot the message is to be sent. The source 26
BS may send up to four 5 ms messages in one traffic frame. The source BS may also 27
include a 20 ms data frame in the traffic frame. If this data frame is included, the 5 ms 28
message(s) is (are) punctured into the correct 5 ms slot(s) during the 20 ms frame 29
transmission. 30
3.24.2 Reverse Link 31
When a 5 ms message is received from an MS that is in soft handoff, the target BS 32
includes the message in either an A3-FCH Reverse Traffic Frame or an A3-DCCH 33
Reverse Traffic frame, depending on which physical channel the message was received. 34
The Air Interval Content Mask field of the FCH/DCCH Reverse Air Interval Control 35
information element indicates in which 5 ms slot the message was received. The target 36
BS may receive up to four 5 ms messages in one traffic frame. The target BS shall also 37
include a 20 ms data frame in the traffic frame, if this traffic was received in addition to 38
the 5 ms message(s) during the 20 ms interval. 39
TIA-2001.3-C
295 Section 3
3.25 Enhanced Rate Adaptation Mode (ERAM) 1
3.26 Code Combining Soft Handoff (CCSH) 4
3.27 Rescue Channel 7
This section describes call flows for the Rescue Channel feature. 8
Upon reception of a pre-determined number of frames (refer to [2]), an MS disables its 9
transmitter. After a configurable period of time, the MS autonomously promotes one or 10
more eligible rescue cells from its neighbor set to its active set, re-enables it transmitter, 11
and starts sending reverse traffic frames and an Extended Pilot Strength Measurement 12
Message (EPSMM) flagging the newly promoted pilot(s). 13
Upon recognition that the MS has stopped transmitting, the source BS selects a rescue 14
cell candidate(s) based on the MSs neighbor list, last reported EPSMM, and possibly 15
other factors, and initiates soft handoff addition procedures to prepare the target rescue 16
cell(s) to acquire the MS. This scenario assumes that at least one A3 connection has been 17
provisioned between the source and target BSs for rescue channel use. The rescue A3 18
connection is activated when the A7-Handoff Request message is received at the target. 19
The message indicates that a call rescue procedure is requested and that the target BS 20
shall not transmit forward frames until the MS is acquired. The target BS indicates with 21
the A7-Handoff Request Ack message if the rescue procedure can be supported. In this 22
case, the target base station begins listening for the MS on the frequency indicated in the 23
A7-Handoff Request message. When the MS re-enables its transmitter and sends an 24
EPSMM, the source BS examines the EPSMM to determine if any of the rescue cell(s) it 25
selected matches the cell(s) the MS autonomously promoted into the active set. 26
If the EPSMM indicates that none of the rescue cells selected by the source BS was 27
autonomously promoted into the active set by the MS, the source BS adds a soft handoff 28
leg(s) to the target BS for the cell that was promoted by the MS, and releases the handoff 29
leg(s) for the previously added rescue cell(s). The target rescue cell is instructed to begin 30
transmitting forward frames immediately since the MS is already listening for its 31
transmission. 32
Once the MS is successfully recovered, the call shall be moved from the rescue channel 33
on to a normal traffic channel on the rescue cell to make the rescue channel available for 34
other rescue attempts. Soft handoff legs to any other potentially strong neighbors may 35
also be added, while any weak cells may be removed. If, despite rescue attempts from the 36
network, a call fails to be recovered, normal call failure processing shall occur. The 37
following call flows describe these rescue channel procedures. 38
TIA-2001.3-C
Section 3 296
3.27.1 Rescue Channel Network and MS Select the Same Rescue 1
Cell(s) 2
In this call flow, the source BS correctly selected at least one rescue cell autonomously 3
promoted to the active set by the MS. Note: forward/reverse frames between the source 4
and target BS in the call flow represent A3-IS-2000 FCH Forward/Reverse messages. 5
MS Target BS
time comment
b
c
a
d
Source BS
Active Voice Call
ENLUM Message
Reverse Traffic Frames/EPSMM
e
f
g
h
i
j
k
Forward Traffic Frames
A7 Handoff Request
A7 Handoff Request Ack
Handoff Direction Msg
A7-Drop Target Ack
A3-IS-2000 FCH Forward (Handoff Direction).
MS Ack Order
Handoff Completion Msg
BS Ack Order
MSC
Reverse Frames
Handoff Performed
l
m
n
o
p
q
r
s
Soft/Softer Handoff Addition Procedure
Reverse Traffic Frames
A7-Drop Target
MS stops
Transmitting
Tdrptgt
A7-Drop Target Ack
A7-Drop Target
Tdrptgt
t
u
Thoreq
6
Figure 3.27.1-1 Rescue Channel Network and MS Select the Same Rescue Cell(s) 7
a. The MS is engaged in an active voice call with the network. 8
b. The source BS sends an Extended Neighbor List Update Message (ENLUM) to the 9
MS, which includes the rescue channel parameters. Note: if the MS has not yet 10
TIA-2001.3-C
297 Section 3
received an ENLUM, the MS uses the rescue channel parameters received in the 1
Universal Neighbor List Message (UNLM), General Neighbor List Message 2
(GNLM), or Extended Neighbor List Message (ENLM). 3
c. The MS receives a predetermined number of frames of insufficient signal quality and 4
disables its transmitter. 5
d. The source BS detects a loss of transmission from the MS. The source BS selects one 6
or more rescue cell candidates for the MS based on the MSs neighbor list, current 7
active set, and possibly other factors. The source BS sends an A7-Handoff Request 8
message to the target BS indicating that a rescue cell is required. The message 9
includes the cell ID(s) of one or more rescue cell candidates selected by the source 10
BS and the Rescue Request Info IE. The transmit flag in the element is set to 0 11
instructing the target BS not to transmit forward frames until the MS is acquired. The 12
source BS starts timer T
horeq
. 13
e. The source BS begins sending forward traffic frames to the target BS to synchronize 14
the A3 rescue link. 15
f. The target BS begins sending reverse idle frames to the source BS as soon as the first 16
forward frame is received to synchronize the A3 rescue link. The target BS sends 17
reverse traffic frames if it has already acquired the MS. 18
g. The target BS sends an A7-Handoff Request Ack message to the source BS to 19
acknowledge if a rescue procedure can be supported. If the target BS can support the 20
rescue procedure, it attempts to acquire the MS on the selected rescue cell(s).The 21
horeq
. 22
h. After a configurable period of time (as specified in the 23
ENLUM/UNLM/GNLM/ENLM), the MS re-enables its transmitter. The target BS 24
begins receiving reverse frames from the MS. 25
i. The target BS starts transmitting forward traffic frames to the MS over the rescue 26
channel(s) as soon as the MS is acquired. 27
j. The target BS sends reverse traffic frames and EPSMMs to the source BS. The 28
EPSMMs indicates that at least one rescue cell selected by the source BS was 29
autonomously promoted by the MS to the active set. 30
k. For any rescue cells that were both successfully selected by the source BS and 31
autonomously promoted into the active set by the MS, the source BS performs 32
soft/softer handoff addition procedure(s) to add a normal traffic channel onto each of 33
those rescue cells (rescue A3 connections and rescue channels remain active); refer 34
to 3.19.3.2.1-1 steps a through h. For any cell(s) that the MS autonomously 35
promoted into the active set that the source BS did not select, the source BS performs 36
soft handoff addition procedures using normal traffic channels in order sync up with 37
the current active set. 38
l. For any rescue cell(s) selected by the source BS that was not autonomously 39
promoted into the active set by the MS, the source BS sends an A7-Drop Target 40
message to the target BS to indicate that the rescue channel is no longer needed. The 41
target BS deactivates the A3 rescue channel, but the A3 traffic connection remains 42
connected for future rescue attempts. The source BS starts timer T
drptgt.
43
m. The target BS sends an A7-Drop Target Ack message to the source BS to 44
acknowledge release of the specified cell. The source BS stops timer T
drptgt
. 45
n. The source BS sends a handoff direction message in the A3-IS-2000 FCH Forward 46
message to the target BS. 47
TIA-2001.3-C
Section 3 298
o. The target BS sends the handoff direction message to the MS to sync up the active 1
sets and move the MS off the rescue channel. 2
p. The MS acknowledges receipt of the message with an MS Ack Order. 3
q. The MS indicates successful results of processing the handoff direction message by 4
responding with a Handoff Completion message. 5
r. The target BS responds with a BS Ack Order. 6
s. The source BS may send a Handoff Performed message to the MSC (refer to section 7
3.19.1.1.3). The Handoff Performed message may be sent at any time after the 8
Handoff Completion message is received at the BS. 9
t. The source BS sends an A7-Drop Target message to the target BS(s) to request 10
release of the rescue channel(s) used to recover the call. The source BS starts timer 11
T
drptgt
. Note: Rescue A3 traffic connections remain connected for future rescue 12
attempts. 13
u. The target BS sends an A7-Drop Target Ack message to the source BS to 14
acknowledge release of the specified channel(s). The source BS stops timer T
drptgt
. 15
3.27.2 Rescue Channel Network and MS Selected Different Rescue 16
Cell(s) 17
The MS has disabled its transmitter due to poor quality of forward frames received from 18
the network. The network detects a loss of transmission from the MS, which triggers 19
selection and setup of rescue cell candidates. The MS autonomously promotes one or 20
more rescue cells to its active set, re-enables its transmitter, and starts sending reverse 21
traffic frames and an EPSMM reflecting the newly promoted pilots. The EPSMM 22
indicates that none of the rescue cells selected by the source BS match those 23
autonomously promoted to the active set by the MS. The MS selected a rescue cell(s) 24
from the target BS2. Note: forward/reverse frames between the source and target BS in 25
the calls flow represent the A3-IS-2000 FCH Forward/Reverse messages. 26
TIA-2001.3-C
299 Section 3
MS T-BS1
time
comment
b
c
a
d
S-BS
Rescue Channel Setup
e
f
g
h
i
j
k
MSC
l
m
n
Rescue Channel Release
A7 Handoff Request
A7 Handoff Request Ack
Reverse Frames
T-BS2
A7-Drop Target
A7-Drop Target Ack
MS stops
Transmitting
o
Tdrptgt
Thoreq
X
1
Figure 3.27.2-1 Rescue Channel Network and MS Selected Different Rescue Cells 2
a. The MS receives a predetermined number of frames of insufficient signal quality and 3
disables its transmitter. 4
b. The source BS initiates a rescue channel procedure with the target BS1 as described 5
in section 3.27.1, steps d through g. The target BS1 is listening for the MS, but 6
the MS has not resumed transmission at this point. 7
c. After a configurable period of time (as specified in the 8
ENLUM/UNLM/GNLM/ENLM), the MS re-enables its transmitter. The source BS 9
and/or target BS1 begin receiving reverse frames from the MS. 10
d. The target BS1 starts transmitting forward traffic frames to the MS over the rescue 11
channel(s) as soon as the MS is acquired. 12
e. The target BS1 sends reverse traffic frames and EPSMMs to the source BS. The 13
EPSMMs indicate that no rescue cell(s) selected by the source BS matched a cell(s) 14
autonomously promoted to the active set by the MS. The MS promoted a rescue 15
cell(s) from the target BS2. 16
f. The source BS sends an A7-Handoff Request messages to the target BS2, indicating 17
that a rescue cell is required and starts timer T
horeq
. The message includes the cell ID 18
of one more rescue cell autonomously promoted to the active set by the MS as 19
reported in the EPSMM message. The message also includes the Rescue Request 20
Info IE with the transmit flag set to 1 instructing the target BS2 to begin 21
TIA-2001.3-C
Section 3 300
transmitting forward frames to the MS on the rescue channel(s) as soon as 1
synchronization with the source BS is achieved. 2
g. The source BS begins sending forward traffic frames to the target BS2 to 3
synchronize the A3 rescue link. 4
h. The target BS2 begins sending reverse idle frames to the source BS as soon as the 5
first forward frame is received to synchronize the A3 rescue link. Reverse traffic 6
frames are sent if the target BS2 has acquired the MS. 7
i. The target BS2 sends an A7-Handoff Request Ack message to the source BS to 8
acknowledge if the rescue procedure can be supported. If the target BS2 can support 9
the rescue procedure, it attempts to acquire the MS on the rescue cell(s). The source 10
BS stops timer T
horeq
. 11
j. The target BS2 begins transmitting forward frames to the MS as soon as 12
synchronization with the source BS has occurred. 13
k. If the source BS has chosen to be notified of the start of transmission and reception 14
at the target BS2 when its SDU function and the target BS2 have synchronized the 15
A3 rescue link, the target BS2 replies with an A3-Traffic Channel Status message. 16
Note: this step may occur any time after step f. 17
l. After acquiring the MS, the target BS2 begins to send reverse traffic frames to the 18
source BS. 19
m. The source BS sends an A7-Drop Target message to the target BS1 to request release 20
of any rescue cell(s) previously added in step b that was not autonomously 21
promoted by the MS. Rescue A3 traffic connection is deactivated but remains 22
connected. The source BS starts timer T
drptgt
. Note: this step may occur anytime 23
after step e. 24
n. The target BS1 sends an A7-Drop Target Ack message to the source BS to 25
acknowledge release of the specified cell(s). The source BS stops timer T
drptgt
. Note: 26
Rescue A3 traffic connections remain connected for future rescue attempts. 27
o. Rescue channel cleanup procedure occurs the source BS attempts to sync up the 28
active sets, moves the MS off the rescue channel, and sends a handoff direction 29
message to the MS. Refer to section 3.27.1 steps k through u for the remainder of 30
the call flow. 31
3.28 Terrestrial Circuit Management 32
The following sections describe those procedures involved with the management of 33
terrestrial circuits on the A2, A5, and A3 interfaces. 34
3.28.1 Terrestrial Circuit Management for the A2/A5 Interfaces 35
This section describes Terrestrial Circuit management for the A2 and A5 interfaces. 36
Section 3.28.1.1 describes circuit allocation and deallocation. Section 3.28.1.2 describes 37
blocking and unblocking of terrestrial circuits. Sections 3.28.1.3 and 3.28.1.4 describe 38
resetting of circuits. 39
3.28.1.1 A2/A5 Terrestrial Circuit Allocation 40
The MSC chooses the terrestrial circuit to be used as specified in 1.4.1.1. 41
The Terrestrial Circuit allocation procedure is described in [14]. 42
TIA-2001.3-C
301 Section 3
NOTE: There is at least one single logical trunk group serving the BS. 1
3.28.1.2 A2/A5 Terrestrial Circuit Blocking/Unblocking 2
The MSC needs to be informed of any A2/A5 terrestrial circuits that are out of service or 3
that return to service at the BS. The Block or Unblock message is sent by the BS as a 4
connectionless mode message for terrestrial circuits that are out of service or that return 5
to service. Upon receiving a Block or Unblock message, the MSC marks or unmarks the 6
identified circuits as blocked at the BS and acknowledges the action to the BS. The MSC 7
may locally block a circuit by not choosing it. No information flow across the interface 8
concerning this type of blocking is needed. 9
The following sections describe the operation of blocking and unblocking procedures. 10
3.28.1.2.1 Block Procedure Scenario Diagram 11
Figure 3.28.1.2.1-1 below shows the Block procedure. 12
Time
a
b
BS MSC
Block Acknowledge
Block
T1
Comment
13
Figure 3.28.1.2.1-1 Block Procedure 14
a. The BS sends the Block message to the MSC with information on the circuits to be 15
blocked. The BS starts timer T
1
. 16
b. In response to the Block message, the MSC returns a Block Acknowledge message, 17
indicating the involved circuit(s) has been marked as blocked. The BS stops timer 18
T
1
. 19
3.28.1.2.2 Unblock Procedure Scenario Diagram 20
The diagram in Figure 3.28.1.2.2-1 shows the Unblock procedure. 21
Time
a
b
BS MSC
Unblock Acknowledge
Unblock
T1
Comment
22
Figure 3.28.1.2.2-1 Unblock Procedure 23
a. The BS sends the Unblock message to the MSC in a request to unblock circuits. The 24
BS starts timer T
1
. 25
TIA-2001.3-C
Section 3 302
b. The MSC removes any marks that indicated that the circuits were blocked at the BS 1
and sends the Unblock Acknowledge message to the BS. The BS stops timer T
1
. 2
3.28.1.3 Reset Circuit Procedure 3
The reset circuit procedure is needed to initialize information in the MSC/BS when a 4
failure has occurred affecting only a small part of the equipment and in which the SCCP 5
connection has been released. If the MSC/BS detects that one or more circuits need to be 6
reset due to abnormal SCCP connection release, a Reset Circuit message is sent. Upon 7
receipt of the Reset Circuit message, the receiver resets the indicated circuits and returns 8
an acknowledgment. 9
The following sections describe the operation of the reset circuit procedures. 10
3.28.1.3.1 Reset Procedure at the BS Scenario Diagram 11
The diagram in Figure 3.28.1.3.1-1 shows the Reset Circuit procedure. 12
Time
a
b
BS MSC
Reset Circuit Acknowledge
Reset Circuit
T12
Comment
13
Figure 3.28.1.3.1-1 A1 Reset Circuit Procedure at the BS 14
a. Once the BS detects that one or more circuits need to be reset, it sends a Reset 15
Circuit message to the MSC with information on the circuit identities and the cause 16
of the reset. The BS starts timer T
12
after sending the Reset Circuit message. 17
b. Upon receipt of the Reset Circuit message, the MSC resets the circuits, removes any 18
marks that indicated that the circuits were blocked at the BS, and returns a Reset 19
Circuit Acknowledge message to indicate that the circuits have been reset. The BS 20
stops timer T
12
. 21
3.28.1.3.2 Reset Circuit Procedure at the MSC 22
The diagram in Figure 3.28.1.3.2-1 shows a simple reset circuit procedure initiated by the 23
MSC. 24
Time
a
b
BS MSC
Reset Circuit
T12
Comment
25
Figure 3.28.1.3.2-1 Reset Circuit Procedure at the MSC 26
TIA-2001.3-C
303 Section 3
a. Once the MSC detects that one or more circuits need to be reset, it resets the circuits 1
and sends a Reset Circuit message to the BS with information on the circuits and the 2
cause of the reset. The MSC starts timer T
12
. 3
b. Upon receipt of the Reset Circuit message, the BS resets the circuits and returns a 4
Reset Circuit Acknowledge message to indicate that the circuits have been reset. The 5
MSC removes any marks that indicated that the circuits were blocked at the BS and 6
stops timer T
12
. 7
3.28.1.3.3 Reset Circuit Procedure at the MSC with BS Block Response 8
The diagram in Figure 3.28.1.3.3-1 shows a reset circuits procedure initiated by the MSC 9
that is responded to from the BS by a Block message. 10
Time
a
b
BS MSC
Block
Reset Circuit
T12
Comment
c
Block Acknowledge
T1
11
Figure 3.28.1.3.3-1 Reset Circuit Procedure at the MSC with BS Block Response 12
a. Once the MSC detects that one or more circuits need to be reset, it resets the circuits, 13
and sends a Reset Circuit message to the BS with information on the circuit identities 14
and the cause of the reset. The MSC starts timer T
12
. 15
b. If the BS cannot reset a circuit, it sends the Block message to the MSC with 16
information on the blocked circuit identities and the cause of the blocking. The BS 17
starts timer T
1
. The MSC stops Timer T
12
upon receipt of the Block message. The 18
MSC marks the circuits identified in the Block message as blocked at the BS, and 19
unmarks the remaining circuits identified in the Reset Circuit message. 20
c. In response to the Block message, the MSC returns a Block Acknowledge message, 21
indicating the involved circuits that have been marked as blocked. The BS stops 22
timer T
1
3.28.1.4 Global System Reset 24
The purpose of the global system reset procedure is to cause the initialization of the MSC 25
or BS in the event of a global failure by its counterpart. Since this type of failure is 26
global, the messages of the procedure are sent as connectionless messages on the A1 27
interface. 28
Upon detection of a global failure or as a result of an initialization, the BS or MSC sends 29
a Reset message to its counterpart. The counterpart then performs all necessary 30
initialization functions such as: releasing of affected calls and references, idling of 31
circuits, blocking of circuits, and ensuring as necessary that all MSs previously involved 32
in a call are no longer transmitting. After a guard period sufficient to allow all necessary 33
initialization to occur, the counterpart acknowledges the Reset message. 34
TIA-2001.3-C
Section 3 304
The following sections describe the call flows involved in the reset procedures. The 1
message structures and the information elements in these messages are described in [14]. 2
3.28.1.4.1 Successful Reset at the MSC 3
This example shows a successful reset procedure when the MSC (re-)initializes. 4
Time
a
b
BS MSC
Reset Acknowledge
Reset
T16
Comment
BS blocks circuits as necessary
using the blocking procedure.
c
T13
x
5
Figure 3.28.1.4.1-1 Successful Reset at the MSC 6
a. When the MSC (re-)initializes, it sends a Reset message to the BS to notify the BS of 7
the reset procedure it is undertaking. The MSC starts timer T
16
. The BS starts timer 8
T
13
. 9
b. The BS may use the circuit blocking procedure to block circuits, as necessary, 10
between itself and the MSC. 11
c. Upon expiration of timer T
13
, the BS returns a Reset Acknowledge message. The 12
MSC stops timer T
16
. Both the MSC and BS begin normal operations relative to 13
each other. 14
3.28.1.4.2 Successful Reset at the BS 15
This example shows a successful reset procedure when the BS (re-) initializes. 16
TIA-2001.3-C
305 Section 3
Time
a
b
BS MSC
Reset Acknowledge
Reset
T2
Comment
c
T4
x
1
Figure 3.28.1.4.2-1 Successful Reset at the BS 2
a. When the BS (re-) initializes, it sends a Reset message to the MSC to notify the MSC 3
of the reset procedure it is undertaking. The MSC starts timer T
2
. The BS starts timer 4
T
4
. 5
b. The BS may use the circuit blocking procedure to block circuits, as necessary, 6
2
, the MSC returns a Reset Acknowledge message. The 8
BS stops timer T
4
. Both the MSC and BS begin normal operations relative to each 9
other. 10
3.28.1.4.3 Reset Glare Noted at the MSC 11
This example shows parallel reset procedures at the BS and MSC. In this case, the MSC 12
notes that a timing condition has occurred since the Reset message from the BS arrives 13
after the Reset message is sent from the MSC. The MSC shall assume that the Reset 14
message it has sent has been lost. As a result the MSC cancels the reset procedure that it 15
initiated and continues with the reset procedure initiated by the BS. 16
TIA-2001.3-C
Section 3 306
Time
b
c
BS MSC
Reset Acknowledge
Reset
T2
Comment
d
T4
x
a
Reset
T16
1
Figure 3.28.1.4.3-1 Reset Glare Noted at the MSC 2
a. When the MSC (re-) initializes, it sends a Reset message to the BS to notify the BS 3
of the reset procedure it is undertaking. The MSC starts timer T
16
. In this example, 4
the Reset message is lost or cannot be successfully processed by the BS. 5
b. When the BS (re-) initializes, it sends a Reset message to the MSC to notify the MSC 6
of the reset procedure it is undertaking. The MSC stops timer T
16
and starts timer T
2
. 7
4
. 8
c. The BS may use the circuit blocking procedure to block circuits, as necessary, 9
d. Upon expiration of timer T
2
BS stops timer T
4
. Both the MSC and BS begin normal operations relative to each 12
other. 13
3.28.1.4.4 Reset Glare Noted at the BS 14
This example shows parallel reset procedures at the BS and MSC. In this case, the BS 15
notes that a timing condition has occurred since the Reset message from the MSC arrives 16
after the Reset message is sent from the BS. The BS shall assume that the Reset message 17
it has sent has been lost. As a result the BS cancels the reset procedure that it initiated and 18
continues with the reset procedure initiated by the MSC. 19
TIA-2001.3-C
307 Section 3
Time
b
c
BS MSC
Reset Acknowledge
Reset
T16
Comment
d
T13
x
a
Reset
T4
1
Figure 3.28.1.4.4-1 Reset Glare Noted at the BS 2
of the reset procedure it is undertaking. The BS starts timer T
4
. In this example, the 4
Reset message is lost or cannot be successfully processed by the MSC. 5
b. When the MSC (re-) initializes, it sends a Reset message to the BS to notify the BS 6
of the reset procedure it is undertaking. The BS stops timer T
4
and starts timer T
16
. 7
13
. 8
c. The BS uses the circuit blocking procedure to block circuits, as necessary, between 9
itself and the MSC. 10
13
MSC stops timer T
16
. Both the MSC and BS begin normal operations relative to 12
each other. 13
3.28.1.4.5 Reset Glare Noted at Both the MSC and the BS 14
This example shows parallel reset procedures at the BS and MSC. In this case, the Reset 15
messages pass each other en route and are both received. The BS notes that a timing 16
condition has occurred since the Reset message from the MSC arrives after the Reset 17
message is sent from the BS. The BS shall assume that the Reset message it has sent has 18
been lost. As a result, the BS shall act as though it is not also performing a reset 19
procedure. Similarly, the MSC notes that a timing condition has occurred since the Reset 20
message from the BS arrives after the Reset message is sent from the MSC. The MSC 21
shall assume that the Reset message it has sent has been lost. As a result the MSC cancels 22
the reset procedure that it initiated and continues with the reset procedure initiated by the 23
BS. 24
TIA-2001.3-C
Section 3 308
Time
b
c
BS MSC
Reset Acknowledge
Reset
T16
Comment
d
T13
x
a
Reset
T4
T2
Reset Acknowledge
x e
1
Figure 3.28.1.4.5-1 Reset Glare Noted at Both the MSC and the BS 2
of the reset procedure it is undertaking. The BS starts timer T
4
. In this example, the 4
MSC also sends a Reset message due to (re-) initialization and starts timer T
16
. 5
b. When the BS receives the Reset message, it stops timer T
4
and starts timer T
13
. 6
When the MSC receives the Reset message, it stops timer T
16
and starts timer T
2
. 7
c. The BS uses the circuit blocking procedure to block circuits, as necessary, between 8
itself and the MSC. 9
13
MSC discards the message as an unexpected message. The BS begins normal 11
operations relative to the MSC. 12
e. Upon expiration of timer T
2
BS discards the message as an unexpected message. The MSC begins normal 14
operations relative to the BS. 15
NOTE: Steps d and e could occur in the reverse order. 16
3.28.2 Terrestrial Circuit Management for the A3 Interface 17
This section contains examples of the A7-Reset procedure, including glare situations. 18
Refer to section 2.28.2 for more information. 19
3.28.2.1 Successful Reset at a BS 20
This example shows a successful A7-Reset procedure when a BS (re)-initializes. 21
TIA-2001.3-C
309 Section 3
Time
a
b
Second
BSC
First
BSC
A7-Reset Acknowledge
A7-Reset
Comment
x
T2
T4
1
Figure 3.28.2.1-1 Successful A7-Reset at a BS 2
a. When the first BS (re-) initializes, it sends an A7-Reset message to another (second) 3
BS to notify the second BS of the reset procedure it is undertaking. The second BS 4
starts timer T
2
. The first BS starts timer T
4
. 5
b. Upon expiration of timer T
2
, the second BS returns an A7-Reset Acknowledge 6
message. The first BS stops timer T
4
. Both BSs begin normal operations relative to 7
each other. 8
3.28.2.2 A7-Reset Glare Noted at the First BS 9
This example shows parallel reset procedures at two BSs. In this case, the first BS notes 10
that a timing condition has occurred since the A7-Reset message from the other (second) 11
BS arrives after the A7-Reset message is sent from the first BS. The first BS shall assume 12
that the A7-Reset message it has sent has been lost. As a result the first BS cancels the 13
reset procedure that it initiated and continues with the reset procedure initiated by the 14
second BS. 15
Time
b
c
Second
BSC
First
BSC
A7-Reset
T2
Comment
T4
x
a
A7-Reset
T4
16
Figure 3.28.2.2-1 A7-Reset Glare Noted at the First BS 17
a. When a (first) BS (re-) initializes, it sends an A7-Reset message to another (second) 18
BS to notify the second BS of the A7-Reset procedure it is undertaking. The first BS 19
TIA-2001.3-C
Section 3 310
starts timer T
4
. In this example, the A7-Reset message is lost or cannot be 1
successfully processed by the second BS, which is itself (re)-initializing. 2
b. When the second BS (re-) initializes, it sends an A7-Reset message to the first BS to 3
notify the first BS of the A7-Reset procedure it is undertaking. The first BS stops 4
timer T
4
and starts timer T
2
. The second BS starts timer T
4
. 5
2
, the first BS returns an A7-Reset Acknowledge 6
message. The second BS stops timer T
4
. Both the first BS and second BS begin 7
normal operations relative to each other. 8
3.28.2.3 A7-Reset Glare Noted at Both BSs 9
This example shows parallel A7 reset procedures at two BSs. In this case, the A7-Reset 10
messages pass each other en route and are both received. The first BS notes that a timing 11
condition has occurred since the A7-Reset message from the second BS arrives after the 12
A7-Reset message is sent from the first BS. The first BS shall assume that the A7-Reset 13
message it has sent has been lost. As a result, the first BS shall act as though it is not also 14
performing a reset procedure. Similarly, the second BS notes that a timing condition has 15
occurred since the A7-Reset message from the first BS arrives after the A7-Reset 16
message is sent from the second BS. The second BS shall assume that the A7-Reset 17
message it has sent has been lost. As a result the second BS cancels the reset procedure 18
that it initiated and continues with the reset procedure initiated by the first BS. 19
Time
b
c
First
BSC
A7-Reset
T4
Comment
d
T2
x
a
A7-Reset
T4
T2
x
Second
BSC
20
Figure 3.28.2.3-1 A7-Reset Glare Noted at Both BSs 21
a. When the first BS (re-) initializes, it sends an A7-Reset message to the second BS to 22
notify the second BS of the reset procedure it is undertaking. The first BS starts timer 23
T
4
. In this example, the second BS also sends an A7-Reset message due to (re-) 24
initialization and starts timer T
4
. 25
TIA-2001.3-C
311 Section 3
b. When the first BS receives the A7-Reset message, it stops timer T
4
and starts timer 1
T
2
. When the second BS receives the A7-Reset message, it stops timer T
4
and starts 2
timer T
2
. 3
2
, the first BS returns an A7-Reset Acknowledge 4
message. The second BS discards the message as an unexpected message. The first 5
BS begins normal operations relative to the second BS. 6
2
, the second BS returns an A7-Reset Acknowledge 7
message. The first BS discards the message as an unexpected message. The second 8
BS begins normal operations relative to the first BS. 9
NOTE: Steps c and d could occur in the reverse order. 10
3.29 Vocoder Support 11
This section describes the IOS messaging required to support vocoder assignment by the 12
BS. This section pre-supposes the assumptions listed in section 1.0 of this document. 13
3.29.1 Mobile Originated Calls 14
The following call flow demonstrates the general sequence for vocoder selection for a 15
mobile originated call: 16
TIA-2001.3-C
Section 3 312
MS BS MSC
Time
Origination
CM Service Request
Assignment Request
Channel Assignment, Service
Negotiation
Assignment Complete
a
b
c
d
e
T303
T10
f
Ringback Tone
1
Figure 3.29.1-1 Vocoder Selection Mobile Originated Case 2
a. The MS originates the call by sending an Origination Message to the BS. This 3
message contains the voice service option that the MS prefers (13K, EVRC, SMV). 4
b. The BS sends a CM Service Request message to the MSC, containing the service 5
option that was requested by the MS. The BS starts timer T
303
. 6
c. Upon receipt of the CM Service Request message, the MSC sends an Assignment 7
Request message to the BS containing the same service option that was received in 8
the CM Service Request message. The BS stops timer T
303
message. The MSC starts timer T
10
. 10
d. Upon receipt of the Assignment Request message, the BS assigns a traffic channel to 11
the MS. Once the traffic channel has been established, the BS and MS negotiate the 12
service option for the voice service. Refer to Circuit mode voice service 13
assumptions: in section 1.1. 14
e. The BS sends an Assignment Complete message to the MSC indicating the service 15
option for the voice call. Upon receipt of the Assignment Complete message, the 16
MSC stops timer T
10
. 17
f. As call progress tone is applied in-band in this case, ringback tone is available on the 18
audio circuit path towards the MS. 19
TIA-2001.3-C
313 Section 3
3.29.2 Mobile Terminated Calls 1
The following call flow demonstrates the general sequence for vocoder selection for a 2
mobile terminated call: 3
MS BS MSC
Time
Page
Paging Response
Paging Request
Channel Assignment, Service
Negotiation
Assignment Complete
a
b
c
d
e
Page Response
Assignment Request
f
g
MS Rings, User Answers
Connect
T3113
T303
T10
T301
h
i
4
Figure 3.29.2-1 Vocoder Selection Mobile Terminated Case 5
a. The MSC initiates a mobile terminated call by sending a Paging Request message to 6
the BS. This message contains either the 13K, EVRC, or SMV voice service option. 7
3113
. 8
b. The BS pages the MS with the same service option it received in the Paging Request 9
message. 10
c. The MS responds with a Page Response message. This message contains the voice 11
service option (either 13K, EVRC, or SMV) that the MS prefers. 12
d. Upon receipt of the Page Response message from the MS, the BS sends a Paging 13
Response message to the MSC, including the service option sent by the MS. The BS 14
starts timer T
303
. 15
e. Upon receipt of the Paging Response message the MSC stops timer T
3113
. The MSC 16
sends an Assignment Request message to the BS, containing the same service option 17
that was included in the Paging Response message. The MSC starts timer T
10
. 18
f. Upon receipt of the Assignment Request message, the BS stops timer T
303
and 19
assigns a traffic channel to the MS. Once the traffic channel has been established, the 20
TIA-2001.3-C
Section 3 314
BS and MS negotiate the service option for the voice service. Refer to Circuit mode 1
voice service assumptions: in section 1.1. 2
g. The BS sends an Assignment Complete message to the MSC indicating the service 3
option for the voice call. Upon receipt of the Assignment Complete message, the 4
MSC stops timer T
10
and starts timer T
301
. 5
h. The BS alerts the MS to ring. 6
i. When the user answers the MS, the BS sends a Connect message to the MSC. The 7
MSC stops timer T
301.
8
3.29.3 Service Option Change During Handoff 9
This section describes the scenario for changing vocoder types during a hard handoff. It 10
is assumed that the target BS does not support the vocoder type that the MS is currently 11
using, and that the source BS is aware of the vocoder type(s) supported by the target BS. 12

MS Source BS MSC
Handoff Required
Handoff Request
Handoff Command
MS Ack Order
Target BS
Handoff Request Ack
T7
T9
Handoff Commenced
Reverse Traffic Channel Frames or Traffic Channel Preamble
Clear Command
Clear Complete
BS Ack Order
Handoff Complete
T306
T315
Twaitho
x
Service Connect Completion Message
Time
a
b
c
d
e
f
g
h
i
j
k
l
m
n
o
T11
p
13
Figure 3.29.3-1 Vocoder Selection Handoff Case 14
7
. The message contains 18
the service option for one of the vocoder types supported by the target BS. 19
TIA-2001.3-C
315 Section 3
message The MSC starts timer T
11
. 2
appropriate radio resources as specified in the message and connects the call. As the 4
Handoff Request message can have multiple cell(s) specified, the target BS can also 5
choose to set up multiple cell(s) for the handoff request. The target BS sends null 6
forward traffic channel frames to the MS. 7
d. The target BS sends a Handoff Request Acknowledge message to the MSC. The 8
9
to wait for arrival of the MS on its radio channel. The first 9
cell in the cell identifier list element of the message is treated as the new designated 10
cell by the MSC. The change of designated cell occurs upon receipt of the Handoff 11
Complete message. If the service option received in the Handoff Request message is 12
not available at the target BS and the target BS selected a different service option for 13
the handoff then the target BS shall include the service option it selected in the IS- 14
2000 Service Configuration Record IE. 15
e. Upon receipt of the Handoff Request Acknowledge message the MSC stops timer 16
T
11
. The MSC prepares to switch the MS from the source BS to the target BS and 17
sends a Handoff Command message to the source BS. The MSC shall include the 18
service option it received from the Handoff Request Acknowledgement message in 19
the Handoff Command message. The source BS stops timer T
7
. 20
f. The source BS sends a Service Connect Message to the MS indicating the new 21
service option for the call. Note this step is only necessary for IS-95-A MSs; for IS- 22
95-B and cdma2000
MSs, the service option can be included in the General or 23

Universal Handoff Direction Message. 24
g. The source BS sends the handoff direction message to the MS. The action time is set 25
to the same action time as the Service Connect Message (step f). If the MS is 26
allowed to return to the source BS, timer T
waitho
is also started by the source BS. 27
h. The MS may acknowledge the handoff direction message by sending an MS Ack 28
Order to the source BS. 29
i. The source BS sends a Handoff Commenced message to the MSC to notify it that the 32
T
306
waitho
has been 34
j. The MS sends reverse traffic channel frames or the traffic channel preamble to the 37
target cell(s). 38
k. The MS sends a Handoff Completion Message to the target BS. The target BS stops 39
timer T
9
. 40
l. The MS sends a Service Connect Completion message to the target BS to complete 41
the change to the new service option. 42
n. The target BS sends a Handoff Complete message to the MSC to notify it that the 44
MS has successfully completed the hard handoff. The target BS stops timer T
9
. 45
TIA-2001.3-C
Section 3 316
o. The MSC sends a Clear Command message to the source BS and starts timer T
315
. 1
306
. 2
p. The source BS sends a Clear Complete message to the MSC to notify it that clearing 3
315
. 4
3.30 Reverse FCH Gating 5
This feature is supported using existing handoff call flows. 6
3.31 Voice over IP (VoIP) 7
This feature is supported using 3G packet data services call flows. Refer to section 3.17. 8
3.32 Network Directed System Selection (NDSS) 9
This section contains examples showing the use of the appropriate messages for service 10
redirection. 11
In cdma2000
1X systems, there are three types of service redirection messages; SRM 12

(Service Redirection Message), GSRM (Global Service Redirection Message) to redirect 13
only those MSs with MOB_P_REV less than six, and EGSRM (Extended Global Service 14
Redirection Message) to redirect only those MSs with MOB_P_REV equal to or greater 15
than six. 16
3.32.1 Redirection During Mobile Origination 17
The following call flow shows a mobile originated call prior to registration. For 18
simplicity authentication procedures are not addressed. For authentication procedures, 19
refer to 3.20.1. 20
TIA-2001.3-C
317 Section 3

MS BS-2 MSC-2
time comment
Origination Message
a
b
c
d
e
f
BS-1 MSC-1
CM Service Request
EGSRDM/GSRDM/SRDM
Origination Message
CM Service Request
Service Redirection
T303
g
Normal call setup
BS Ack Order
h
i
BS Ack Order
1
Figure 3.32.1-1 Service Redirection During Mobile Origination 2
a. The MS scans, finds a serving system and sends an Origination Message to BS-1. 3
b. BS-1 acknowledges the receipt of the Origination Message with a Base Station 4
c. BS-1 sends a CM Service Request message to MSC-1 and starts timer T
303.
6
d. MSC-1 determines that another system is preferable for the MS and sends a Service 7
Redirection message to BS-1. BS-1 stops timer T
303
. 8
e. BS-1 conveys the redirection information received in the Service Redirection 9
message by sending an EGSRDM (Extended Global Service Redirection Message) 10
to the MS with P_REV equal to or greater than six, a GRSDM (Global Service 11
Redirection Message) to the MS with P_REV less than six, or a Service Redirection 12
f. Upon receipt of the EGRDSM/GRSDM/SRDM, the MS scans, finds the specified 14
preferred system, and sends an Origination Message to BS-2. 15
g. BS-2 acknowledges the receipt of the Origination Message with a Base Station 16
h. BS-2 sends a CM Service Request message to MSC-2. 18
i. The normal call procedures are used between MSC-2 and BS-2 to establish the call 19
as shown in Figure 3.1.1.1-1 step d and onwards. 20
3.32.2 Redirection During Mobile Registration 21
The following call flow illustrates redirection during registration. 22
TIA-2001.3-C
Section 3 318

MS BS-2 MSC-2
time comment
a
b
c
f
g
h
BS-1 MSC-1
EGSRDM/GSRDM/SRDM
d
e
Service Redirection
T3210
T3210
1
Figure 3.32.2-1 Service Redirection During Mobile Registration 2
a. MS scans, finds a serving system and sends a Registration Message to the BS-1. 3
b. The BS-1 sends a Location Updating Request message to MSC-1 and starts timer 4
T
3210
. 5
c. MSC-1 determines that another system is preferable for the MS, and sends a Service 6
Redirection message to BS-1. BS-1 stops timer T
3210
d. BS-1 conveys the redirection information received in the Service Redirection 8
message by sending a EGSRDM to the MS with P_REV equal to or greater than six, 9
GRSDM to the MS with P_REV less than six, or Service Redirection message to the 10
MS. 11
e. Upon receipt of the EGRDSM/GRSDM/SRDM, the MS scans, finds the specified 12
preferred system, and sends a Registration Message to BS-2. 13
f. BS-2 sends the Location Updating Request message to MSC-2 and starts timer 14
T
3210
. 15
g. MSC-2 sends a Location Updating Accept message to BS-2 to indicate that the 16
Location Updating Request message has been processed. BS-2 stops timer T
3210
. 17
h. BS-2 sends a Registration Accepted Order to the MS. 18
3.32.3 Re-Origination Upon Failed Re-Direction 19
The following call flow shows a mobile re-origination as a return to the first system upon 20
failure to obtain service from the redirected system. 21
TIA-2001.3-C
319 Section 3

MS BS-2 MSC-2
time comment
Origination Message
a
b
c
d
e
f
BS-1 MSC-1
CM Service Request
EGSRDM/GSRDM/SRDM
Origination Message
Origination Message
g
h
Normal call setup
CM Service Request
Release Order
i
Clear Command
j
k
l
T315
Clear Complete
Service Redirection
T303
T303
CM Service Request
m
BS Ack Order
BS Ack Order
BS Ack Order
n
o
1
Figure 3.32.3-1 Re-Origination Upon Failed Re-Direction 2
a. The MS scans, finds a serving system and sends an Origination Message to BS-1. 3
b. BS-1 acknowledges the receipt of the Origination Message with a Base Station 4
c. BS-1 sends a CM Service Request message to MSC-1 and starts timer T
303
. 6
d. MSC-1 determines that another system is preferable for the MS and sends a Service 7
Redirection message including an indication that the MS shall return if the 8
redirections fails to BS-1. BS-1 stops timer T
303
. 9
e. BS-1 conveys the redirection information received in the Service Redirection 10
message by sending an EGSRDM to the MS with P_REV equal to or greater than 11
six, GRSDM to the MS with P_REV less than six, or Service Redirection message to 12
the MS. 13
f. Upon receipt of the EGRDSM/GRSDM/SRDM, the MS scans, finds the specified 14
preferred system, and sends an Origination Message to BS-2. 15
TIA-2001.3-C
Section 3 320
g. BS-2 acknowledges the receipt of the Origination Message with a Base Station 1
Acknowledgement Order to the MS 2
h. BS-2 sends a CM Service Request message to MSC-2 and starts timer T
303
. 3
i. MSC-2 does not accept the CM Service Request message (e.g. because of a protocol 4
mismatch or registration reject). MSC-2 initiates call clearing by sending a Clear 5
Command message to BS-2 to instruct BS-2 to release the associated dedicated 6
resource. BS-2 stops timer T
303
and starts timer T
315
. 7
j. BS-2 initiates call clearing over the air interface by transmitting a Release Order to 8
the MS. 9
k. BS-2 returns a Clear Complete message to MSC-2. MSC-2 stops timer T
315
and 10
releases the underlying transport connection. 11
l. The MS sends an Origination Message with a return cause as specified in [5] to BS-1 12
to indicate this is a re-origination due to redirection failed. 13
m. BS-1 acknowledges the receipt of the Origination Message with a Base Station 14
n. BS-1 sends a CM Service Request with an indication that the redirection failed to 16
MSC-1. 17
o. The normal call procedures are used between MSC-1 and BS-1 to establish the call 18
as shown in Figure 3.1.1.1-1 step d and onwards. 19
3.32.4 Re-Registration Upon Failed Re-Direction 20
The following call flow shows a mobile re-registration as a return to the first system upon 21
failure to register to the redirected system. 22
TIA-2001.3-C
321 Section 3
MS BS-2 MSC-2
time comment
a
b
c
f
g
h
BS-1 MSC-1
EGSRDM/GSRDM/SRDM
d
e
Location Updating Reject
Registration Rejected Order
i
j
k
Service Redirection
T3210
T3210
1
Figure 3.32.4-1 Re-Registration Upon Failed Re-Direction 2
a. The MS scans, finds a serving system and sends a Registration Message to BS-1. 3
b. BS-1 sends a Location Updating Request message to MSC-1. BS-1 starts timer 4
T
3210
. 5
c. MSC-1 determines that another system is preferable for the MS and sends a Service 6
Redirection message to BS-1 including an indication that the MS shall return to this 7
system if the redirections fails. BS-1 stops timer T
3210
. 8
d. BS-1 conveys the redirection information from the Service Redirection message by 9
sending an EGSRDM to the MS with P_REV equal to or greater than six, GRSDM 10
to the MS with P_REV less than six, or Service Redirection message. 11
e. Upon receipt of the EGRDSM/GRSDM/SRDM, the MS scans, finds the specified 12
preferred system, and sends a Registration Message to BS-2. 13
f. BS-2 sends the Location Updating Request message to MSC-2 and starts timer 14
T
3210
. 15
g. MSC-2 sends a Location Updating Reject message to BS-2 to indicate that the 16
registration failed. 17
h. BS-2 sends a Registration Rejected Order to the MS. 18
i. The MS sends a Registration Message with return cause as specified in [5] to BS-1. 19
j. BS-1 sends a Location Updating Request message with an indication that redirection 20
failed to MSC-1. BS-1 starts timer T
3210
. 21
TIA-2001.3-C
Section 3 322
k. MSC-1 sends a Location Updating Accept message to BS-1 to indicate that the 1
Location Updating Request message has been processed. BS-1 stops timer T
3210
. 2
TIA-2001.4-C
1
2
3
4
5
Access Network Interfaces Part 4 (A1, A2, and 6
A5 Interfaces) 7

TIA-2001.4-C

1
3

TIA-2001.4-C
i
Table of Contents 1
2
1.0 Introduction ........................................................................................................................................ 1 3
1.1 Overview........................................................................................................................................ 1 4
1.1.1 Purpose ................................................................................................................................... 1 5
1.1.2 Scope ...................................................................................................................................... 1 6
1.2 References ...................................................................................................................................... 1 7
1.2.1 TIA / EIA................................................................................................................................ 1 8
1.2.2 3GPP2..................................................................................................................................... 2 9
1.2.3 Standards Committee T1 ........................................................................................................ 3 10
1.2.5 Other ....................................................................................................................................... 4 12
1.3 Terminology ................................................................................................................................... 5 13
1.3.1 Acronyms................................................................................................................................ 5 14
1.3.2 Definitions .............................................................................................................................. 8 15
1.4 Message Body, Coding, and Ordering of Elements........................................................................ 9 16
1.5 Forward Compatibility Guidelines ............................................................................................... 10 17
1.6 Message Processing Guidelines.................................................................................................... 11 18
1.7 Message Definition Guidelines..................................................................................................... 12 19
1.8 Message Sending Guidelines........................................................................................................ 12 20
1.9 MSC BS Functional Partitioning............................................................................................... 13 21
2.0 Message Procedures ......................................................................................................................... 15 22
2.1 Call Processing Message Procedures............................................................................................ 15 23
2.1.1 Complete Layer 3 Information ............................................................................................. 15 24
2.1.1.1 Successful Operation ........................................................................................................ 15 25
2.1.1.2 Failure Operation.............................................................................................................. 15 26
2.1.2 Connection Management (CM) Service Request.................................................................. 15 27
2.1.2.3 Abnormal Operation ......................................................................................................... 16 30
2.1.3 Connection Management (CM) Service Request Continuation............................................ 16 31
2.1.4 Paging Request ..................................................................................................................... 17 34
2.1.5 Paging Response................................................................................................................... 17 37
2.1.5.3 Abnormal Operation ......................................................................................................... 18 40
2.1.6 Progress ................................................................................................................................ 18 41
2.1.7 Assignment Request ............................................................................................................. 18 44
2.1.8 Assignment Complete........................................................................................................... 19 47
2.1.9 Assignment Failure............................................................................................................... 19 50
2.1.10 Connect ................................................................................................................................. 19 53
TIA-2001.4-C
ii
2.1.11 Service Release..................................................................................................................... 20 1
2.1.11.1 Base Station Initiated........................................................................................................ 20 2
2.1.11.1.1 Successful Operation ................................................................................................. 20 3
2.1.11.1.2 Failure Operation ....................................................................................................... 20 4
2.1.11.2 MSC Initiated ................................................................................................................... 20 5
2.1.12 Service Release Complete .................................................................................................... 21 8
2.1.12.1 MSC Initiated ................................................................................................................... 21 9
2.1.12.2 BS Initiated....................................................................................................................... 21 12
2.1.13 Clear Request........................................................................................................................ 22 15
2.1.14 Clear Command.................................................................................................................... 22 18
2.1.15 Clear Complete ..................................................................................................................... 23 21
2.1.16 Alert With Information......................................................................................................... 23 24
2.1.17 BS Service Request............................................................................................................... 23 27
2.1.18 BS Service Response ............................................................................................................ 24 30
2.1.19 Additional Service Notification............................................................................................ 24 33
2.1.20 Additional Service Request .................................................................................................. 24 36
2.2 Supplementary Services Message Procedures.............................................................................. 25 39
2.2.1 Flash with Information.......................................................................................................... 25 40
2.2.2 Flash with Information Ack.................................................................................................. 26 43
2.2.3 Feature Notification.............................................................................................................. 26 46
2.2.4 Feature Notification Ack ...................................................................................................... 26 49
2.2.5 PACA Command.................................................................................................................. 27 52
2.2.6 PACA Command Ack .......................................................................................................... 27 55
TIA-2001.4-C
iii
2.2.7 PACA Update ....................................................................................................................... 27 2
2.2.8 PACA Update Ack ............................................................................................................... 28 5
2.2.9 Radio Measurements for Position Request ........................................................................... 28 8
2.2.10 Radio Measurements for Position Response......................................................................... 29 11
2.3 Mobility Management Message Procedures................................................................................. 29 14
2.3.1 Authentication Request......................................................................................................... 29 15
2.3.2 Authentication Response ...................................................................................................... 30 18
2.3.3 SSD Update Request............................................................................................................. 30 21
2.3.4 SSD Update Response .......................................................................................................... 30 24
2.3.5 Base Station Challenge ......................................................................................................... 31 27
2.3.6 Base Station Challenge Response......................................................................................... 31 30
2.3.7 Location Updating Request .................................................................................................. 32 33
2.3.8 Location Updating Accept .................................................................................................... 32 36
2.3.9 Location Updating Reject ..................................................................................................... 32 39
2.3.10 Parameter Update Request.................................................................................................... 33 42
2.3.11 Parameter Update Confirm................................................................................................... 33 45
2.3.12 Privacy Mode Command ...................................................................................................... 33 48
2.3.13 Privacy Mode Complete ....................................................................................................... 34 51
2.3.14 Status Request....................................................................................................................... 34 54
TIA-2001.4-C
iv
2.3.15 Status Response .................................................................................................................... 35 1
2.3.16 User Zone Update Request ................................................................................................... 35 4
2.3.17 User Zone Update ................................................................................................................. 35 7
2.3.18 User Zone Reject .................................................................................................................. 36 10
2.3.19 Registration Request ............................................................................................................. 36 13
2.3.20 Mobile Station Registered Notification ................................................................................ 36 16
2.4 Handoff Message Procedures ....................................................................................................... 37 19
2.4.1 Handoff Required ................................................................................................................. 37 20
2.4.2 Handoff Request ................................................................................................................... 37 23
2.4.3 Handoff Request Acknowledge ............................................................................................ 38 26
2.4.4 Handoff Command ............................................................................................................... 39 29
2.4.5 Handoff Commenced............................................................................................................ 40 32
2.4.6 Handoff Complete ................................................................................................................ 41 35
2.4.7 Handoff Required Reject ...................................................................................................... 41 38
2.4.8 Handoff Failure..................................................................................................................... 42 41
2.4.9 Handoff Performed ............................................................................................................... 42 44
2.5 Facility Management Message Procedures................................................................................... 43 47
2.5.1 Block..................................................................................................................................... 43 48
2.5.2 Block Acknowledge.............................................................................................................. 43 51
2.5.3 Unblock ................................................................................................................................ 44 54
TIA-2001.4-C
v
2.5.4 Unblock Acknowledge ......................................................................................................... 44 1
2.5.5 Reset Circuit ......................................................................................................................... 44 4
2.5.5.1 Reset Circuit (at the BS) ................................................................................................... 45 5
2.5.5.2 Reset Circuit (at the MSC)................................................................................................ 45 8
2.5.6 Reset Circuit Acknowledge .................................................................................................. 46 11
2.5.6.1 Reset Circuit Acknowledge (from BS) ............................................................................. 46 12
2.5.6.2 Reset Circuit Acknowledge (from MSC).......................................................................... 46 15
2.5.7 Reset ..................................................................................................................................... 46 18
2.5.8 Reset Acknowledge .............................................................................................................. 47 21
2.5.9 Transcoder Control Request ................................................................................................. 48 24
2.5.10 Transcoder Control Acknowledge ........................................................................................ 48 27
2.6 Application Data Delivery Service (ADDS) Message Procedures ............................................... 49 30
2.6.1 ADDS Page........................................................................................................................... 49 31
2.6.2 ADDS Page Ack................................................................................................................... 50 34
2.6.3 ADDS Transfer ..................................................................................................................... 50 37
2.6.4 ADDS Transfer Ack ............................................................................................................. 51 40
2.6.5 ADDS Deliver ...................................................................................................................... 52 43
2.6.6 ADDS Deliver Ack............................................................................................................... 52 46
2.7 Error Handling Message Procedures ............................................................................................ 53 49
2.7.1 Rejection............................................................................................................................... 53 50
2.8 Network Directed System Selection (NDSS) Message Procedures.............................................. 53 53
2.8.1 Service Redirection............................................................................................................... 53 54
TIA-2001.4-C
vi
3.0 Message Formats .............................................................................................................................. 55 1
3.1 Call Processing Messages............................................................................................................. 55 2
3.1.1 Complete Layer 3 Information ............................................................................................. 55 3
3.1.2 CM Service Request ............................................................................................................. 56 4
3.1.3 CM Service Request Continuation........................................................................................ 65 5
3.1.4 Paging Request ..................................................................................................................... 67 6
3.1.5 Paging Response................................................................................................................... 71 7
3.1.6 Progress ................................................................................................................................ 78 8
3.1.7 Assignment Request ............................................................................................................. 80 9
3.1.8 Assignment Complete........................................................................................................... 85 10
3.1.9 Assignment Failure............................................................................................................... 88 11
3.1.10 Connect ................................................................................................................................. 90 12
3.1.11 Service Release..................................................................................................................... 91 13
3.1.12 Service Release Complete .................................................................................................... 93 14
3.1.13 Clear Request........................................................................................................................ 94 15
3.1.14 Clear Command.................................................................................................................... 96 16
3.1.15 Clear Complete ..................................................................................................................... 98 17
3.1.16 Alert with Information.......................................................................................................... 99 18
3.1.17 BS Service Request............................................................................................................. 100 19
3.1.18 BS Service Response .......................................................................................................... 102 20
3.1.19 Additional Service Notification.......................................................................................... 104 21
3.1.20 Additional Service Request ................................................................................................ 105 22
3.2 Supplementary Services Message Formats................................................................................. 108 23
3.2.1 Flash with Information........................................................................................................ 108 24
3.2.2 Flash with Information Ack................................................................................................ 111 25
3.2.3 Feature Notification............................................................................................................ 112 26
3.2.4 Feature Notification Ack .................................................................................................... 116 27
3.2.5 PACA Command................................................................................................................ 117 28
3.2.6 PACA Command Ack ........................................................................................................ 118 29
3.2.7 PACA Update ..................................................................................................................... 119 30
3.2.8 PACA Update Ack ............................................................................................................. 122 31
3.2.9 Radio Measurements for Position Request ......................................................................... 123 32
3.2.10 Radio Measurements for Position Response....................................................................... 124 33
3.3 Mobility Management Message Formats ................................................................................... 127 34
3.3.1 Authentication Request....................................................................................................... 127 35
3.3.2 Authentication Response .................................................................................................... 131 36
3.3.3 SSD Update Request........................................................................................................... 133 37
3.3.4 SSD Update Response ........................................................................................................ 134 38
3.3.5 Base Station Challenge ....................................................................................................... 135 39
3.3.6 Base Station Challenge Response....................................................................................... 136 40
3.3.7 Location Updating Request ................................................................................................ 137 41
3.3.8 Location Updating Accept .................................................................................................. 142 42
3.3.9 Location Updating Reject ................................................................................................... 143 43
3.3.10 Parameter Update Request.................................................................................................. 144 44
3.3.11 Parameter Update Confirm................................................................................................. 145 45
3.3.12 Privacy Mode Command .................................................................................................... 146 46
3.3.13 Privacy Mode Complete ..................................................................................................... 147 47
3.3.14 Status Request..................................................................................................................... 148 48
3.3.15 Status Response .................................................................................................................. 152 49
3.3.16 User Zone Update Request ................................................................................................. 154 50
3.3.17 User Zone Update ............................................................................................................... 155 51
3.3.18 User Zone Reject ................................................................................................................ 156 52
3.3.19 Registration Request ........................................................................................................... 160 53
3.3.20 Mobile Station Registered Notification .............................................................................. 163 54
3.4 Handoff Message Formats.......................................................................................................... 164 55
3.4.1 Handoff Required ............................................................................................................... 164 56
TIA-2001.4-C
vii
3.4.2 Handoff Request ................................................................................................................. 177 1
3.4.3 Handoff Request Acknowledge .......................................................................................... 191 2
3.4.4 Handoff Command ............................................................................................................. 199 3
3.4.5 Handoff Commenced.......................................................................................................... 208 4
3.4.6 Handoff Complete .............................................................................................................. 209 5
3.4.7 Handoff Required Reject .................................................................................................... 210 6
3.4.8 Handoff Failure................................................................................................................... 211 7
3.4.9 Handoff Performed ............................................................................................................. 212 8
3.5 Facility Management Message Formats ..................................................................................... 214 9
3.5.1 Block................................................................................................................................... 214 10
3.5.2 Block Acknowledge............................................................................................................ 216 11
3.5.3 Unblock .............................................................................................................................. 217 12
3.5.4 Unblock Acknowledge ....................................................................................................... 219 13
3.5.5 Reset Circuit ....................................................................................................................... 220 14
3.5.6 Reset Circuit Acknowledge ................................................................................................ 222 15
3.5.7 Reset ................................................................................................................................... 223 16
3.5.8 Reset Acknowledge ............................................................................................................ 224 17
3.5.9 Transcoder Control Request ............................................................................................... 225 18
3.5.10 Transcoder Control Acknowledge ...................................................................................... 226 19
3.6 Application Data Delivery Service (ADDS) Message Formats.................................................. 227 20
3.6.1 ADDS Page......................................................................................................................... 227 21
3.6.2 ADDS Page Ack................................................................................................................. 231 22
3.6.3 ADDS Transfer ................................................................................................................... 234 23
3.6.4 ADDS Transfer Ack ........................................................................................................... 241 24
3.6.5 ADDS Deliver .................................................................................................................... 243 25
3.6.6 ADDS Deliver Ack............................................................................................................. 245 26
3.7 Error Handling Messages ........................................................................................................... 246 27
3.7.1 Rejection............................................................................................................................. 246 28
3.8 NDSS Message Formats............................................................................................................. 248 29
3.8.1 Service Redirection............................................................................................................. 248 30
4.0 Information Element Definitions.................................................................................................... 251 31
4.1 Generic Information Element Encoding..................................................................................... 251 32
4.1.1 Conventions ........................................................................................................................ 251 33
4.1.2 Information Element Identifiers.......................................................................................... 251 34
4.1.3 A1 Interface Information Element Types ........................................................................... 255 35
4.1.4 Additional Coding and Interpretation Rules for Information Elements.............................. 258 36
4.1.5 Cross Reference of Information Elements With Messages................................................. 259 37
4.2 Information Elements ................................................................................................................. 274 38
4.2.1 Message Discrimination ..................................................................................................... 274 39
4.2.1.1 A1 Message Header ........................................................................................................ 274 40
4.2.1.1.1 Transfer of DTAP and BSMAP Messages............................................................... 274 41
4.2.1.1.1.1 Distribution Function ...................................................................................... 274 42
4.2.1.1.1.2 Transfer of DTAP Messages........................................................................... 274 43
4.2.1.1.1.3 Transfer of BSMAP Messages........................................................................ 275 44
4.2.2 Data Link Connection Identifier (DLCI) ............................................................................ 276 45
4.2.3 Length Indicator (LI) .......................................................................................................... 277 46
4.2.4 Message Type ..................................................................................................................... 278 47
4.2.5 Channel Number ................................................................................................................. 282 48
4.2.6 Channel Type...................................................................................................................... 283 49
4.2.7 RF Channel Identity............................................................................................................ 285 50
4.2.8 SID...................................................................................................................................... 287 51
4.2.9 IS-95 Channel Identity........................................................................................................ 288 52
4.2.10 Encryption Information....................................................................................................... 290 53
4.2.11 Voice Privacy Request........................................................................................................ 292 54
4.2.12 Classmark Information Type 2 ........................................................................................... 293 55
4.2.13 Mobile Identity ................................................................................................................... 297 56
TIA-2001.4-C
viii
4.2.14 Slot Cycle Index ................................................................................................................. 299 1
4.2.15 Priority................................................................................................................................ 300 2
4.2.16 Cause .................................................................................................................................. 302 3
4.2.17 Cell Identifier...................................................................................................................... 305 4
4.2.18 Cell Identifier List............................................................................................................... 308 5
4.2.19 Circuit Identity Code (CIC) ................................................................................................ 309 6
4.2.20 Circuit Identity Code Extension ......................................................................................... 310 7
4.2.21 Special Service Call Indicator............................................................................................. 311 8
4.2.22 Downlink Radio Environment ............................................................................................ 312 9
4.2.23 IS-2000 Channel Identity 3X.............................................................................................. 314 10
4.2.24 Source PDSN Address........................................................................................................ 318 11
4.2.25 Handoff Power Level.......................................................................................................... 319 12
4.2.26 User Zone ID...................................................................................................................... 320 13
4.2.27 IS-2000 Channel Identity.................................................................................................... 321 14
4.2.28 Response Request ............................................................................................................... 324 15
4.2.29 MS Measured Channel Identity .......................................................................................... 325 16
4.2.30 Reserved ............................................................................................................................. 326 17
4.2.31 Layer 3 Information............................................................................................................ 327 18
4.2.32 Protocol Discriminator........................................................................................................ 328 19
4.2.33 Reserved-Octet ................................................................................................................... 329 20
4.2.34 Reserved ............................................................................................................................. 330 21
4.2.35 Authentication Confirmation Parameter (RANDC)............................................................ 331 22
4.2.36 Reject Cause ....................................................................................................................... 332 23
4.2.37 AuthenticationChallenge Parameter (RAND/RANDU/RANDBS/RANDSSD) ................ 333 24
4.2.38 Authentication Response Parameter (AUTHR/AUTHU/AUTHBS) .................................. 334 25
4.2.39 Authentication Parameter COUNT..................................................................................... 335 26
4.2.40 Reserved ............................................................................................................................. 336 27
4.2.41 Reserved ............................................................................................................................. 337 28
4.2.42 Signal .................................................................................................................................. 338 29
4.2.43 CM Service Type................................................................................................................ 342 30
4.2.44 Called Party BCD Number ................................................................................................. 343 31
4.2.45 Quality of Service Parameters ............................................................................................ 346 32
4.2.46 Cause Layer 3 ..................................................................................................................... 347 33
4.2.47 Transcoder Mode................................................................................................................ 351 34
4.2.48 Power Down Indicator ........................................................................................................ 352 35
4.2.49 Registration Type................................................................................................................ 353 36
4.2.50 Tag...................................................................................................................................... 355 37
4.2.51 Hard Handoff Parameters ................................................................................................... 356 38
4.2.52 Software Version ................................................................................................................ 359 39
4.2.53 Service Option .................................................................................................................... 360 40
4.2.54 ADDS User Part ................................................................................................................. 362 41
4.2.55 IS-2000 Service Configuration Record............................................................................... 363 42
4.2.56 IS-2000 Non-Negotiable Service Configuration Record .................................................... 364 43
4.2.57 IS-2000 Mobile Capabilities ............................................................................................... 365 44
4.2.58 Protocol Type...................................................................................................................... 368 45
4.2.59 MS Information Records .................................................................................................... 369 46
4.2.60 Extended Handoff Direction Parameters ............................................................................ 370 47
4.2.61 CDMA Serving One Way Delay ........................................................................................ 371 48
4.2.62 Radio Environment and Resources..................................................................................... 372 49
4.2.63 Called Party ASCII Number ............................................................................................... 374 50
4.2.64 IS-2000 Cause Value .......................................................................................................... 375 51
4.2.65 Authentication Event .......................................................................................................... 376 52
4.2.66 Authentication Data ............................................................................................................ 377 53
4.2.67 PSMM Count ...................................................................................................................... 378 54
4.2.68 Geographic Location .......................................................................................................... 379 55
4.2.69 Downlink Radio Environment List ..................................................................................... 380 56
TIA-2001.4-C
ix
4.2.70 Circuit Group...................................................................................................................... 381 1
4.2.71 PACA Timestamp............................................................................................................... 383 2
4.2.72 PACA Order ....................................................................................................................... 384 3
4.2.73 PACA Reorigination Indicator ........................................................................................... 385 4
4.2.74 Access Network Identifiers................................................................................................. 386 5
4.2.75 Source RNC to Target RNC Transparent Container........................................................... 387 6
4.2.76 Target RNC to Source RNC Transparent Container........................................................... 388 7
4.2.77 Service Option Connection Identifier (SOCI) .................................................................... 389 8
4.2.78 Service Option List ............................................................................................................. 390 9
4.2.79 AMPS Hard Handoff Parameters........................................................................................ 391 10
4.2.80 Band Class .......................................................................................................................... 392 11
4.2.81 Information Record Requested ........................................................................................... 393 12
4.2.82 Anchor PDSN Address ....................................................................................................... 394 13
4.2.83 Protocol Revision................................................................................................................ 395 14
4.2.84 Anchor P-P Address ........................................................................................................... 396 15
4.2.85 Origination Continuation Indicator..................................................................................... 397 16
4.2.86 IS-2000 Redirection Record ............................................................................................... 398 17
4.2.87 Return Cause....................................................................................................................... 399 18
4.2.88 Service Redirection Info ..................................................................................................... 400 19
4.2.89 Packet Session Parameters.................................................................................................. 402 20
4.2.90 Service Reference Identifier (SR_ID)................................................................................. 404 21
5.0 Timer Definitions ........................................................................................................................... 405 22
5.1 Timer Values .............................................................................................................................. 405 23
5.2 Timer Definitions ....................................................................................................................... 406 24
5.2.1 Call Processing Timers ....................................................................................................... 406 25
5.2.1.1 T
10
................................................................................................................................... 406 26
5.2.1.2 T
20
................................................................................................................................... 406 27
5.2.1.3 T
300
.................................................................................................................................. 406 28
5.2.1.4 T
301
.................................................................................................................................. 407 29
5.2.1.5 T
303
.................................................................................................................................. 407 30
5.2.1.6 T
306
.................................................................................................................................. 407 31
5.2.1.7 T
308
.................................................................................................................................. 407 32
5.2.1.8 T
311
.................................................................................................................................. 407 33
5.2.1.9 T
314
.................................................................................................................................. 407 34
5.2.1.10 T
315
.................................................................................................................................. 407 35
5.2.1.11 T
paca1
................................................................................................................................ 407 36
5.2.1.12 T
paca2
................................................................................................................................ 408 37
5.2.1.13 T
3231
................................................................................................................................. 408 38
5.2.1.14 T
3113
................................................................................................................................. 408 39
5.2.1.15 T
3230
................................................................................................................................. 408 40
5.2.1.16 T
3280
................................................................................................................................. 408 41
5.2.1.17 T
312
.................................................................................................................................. 408 42
5.2.2 Supplementary Services Timers ......................................................................................... 408 43
5.2.2.1 T
softpos
.............................................................................................................................. 408 44
5.2.2.2 T
62
................................................................................................................................... 408 45
5.2.2.3 T
63
................................................................................................................................... 409 46
5.2.2.4 T
60
................................................................................................................................... 409 47
5.2.3 Mobility Management Timers ............................................................................................ 409 48
5.2.3.1 T
3210
................................................................................................................................. 409 49
5.2.3.2 T
3220
................................................................................................................................. 409 50
5.2.3.3 T
3260
................................................................................................................................. 409 51
5.2.3.4 T
3270
................................................................................................................................. 409 52
5.2.3.5 T
3271
................................................................................................................................. 409 53
5.2.3.6 T
3272
................................................................................................................................. 409 54
5.2.3.7 T
ordreg
............................................................................................................................... 410 55
5.2.4 Handoff Timers................................................................................................................... 410 56
TIA-2001.4-C
x
5.2.4.1 T
7
.................................................................................................................................... 410 1
5.2.4.2 T
8
.................................................................................................................................... 410 2
5.2.4.3 T
9
.................................................................................................................................... 410 3
5.2.4.4 T
11
................................................................................................................................... 410 4
5.2.4.5 T
waitho
............................................................................................................................... 410 5
5.2.5 Facility Management Timers .............................................................................................. 411 6
5.2.5.1 T
1
.................................................................................................................................... 411 7
5.2.5.2 T
2
.................................................................................................................................... 411 8
5.2.5.3 T
4
.................................................................................................................................... 411 9
5.2.5.4 T
12
................................................................................................................................... 411 10
5.2.5.5 T
13
................................................................................................................................... 411 11
5.2.5.6 T
16
................................................................................................................................... 411 12
5.2.5.7 T
309
.................................................................................................................................. 411 13
14
15
TIA-2001.4-C
xi
List of Figures 1
2
Figure 1.9-1 MSC-BS Interface Functional Planes ............................................................................... 13 3
Figure 4.2.1.1.1.3-1 Structure of A1 Layer 3 Messages .................................................................. 275 4
5
6
TIA-2001.4-C
xii
List of Tables 1
2
Table 1.4-1 Element Flow DIRECTION Indication .................................................................................. 9 3
Table 4.1.2-1 A1 Information Element Identifiers Sorted by Identifier Value ..................................... 252 4
Table 4.2.4-1 BSMAP Messages .......................................................................................................... 278 5
Table 4.2.4-2 DTAP Messages ............................................................................................................. 280 6
Table 4.2.6-1 Channel Type - Speech or Data Indicator Values........................................................... 283 7
Table 4.2.6-2 Channel Type - Channel Rate and Type Values ............................................................. 283 8
Table 4.2.6-3 Channel Type - Octet 5 Coding (Voice/Signaling Call) ................................................. 284 9
Table 4.2.6-4 Channel Type - Octet 5 Coding (Data Call) ................................................................... 284 10
Table 4.2.7-1 RF Channel Identity Timeslot Number........................................................................ 285 11
Table 4.2.10-1 Encryption Information - Encryption Parameter Coding......................................... 290 12
Table 4.2.10-2 Encryption Information - Encryption Parameter Identifier Coding ......................... 291 13
Table 4.2.12-1 Classmark Information Type 2 - RF Power Capability............................................ 294 14
Table 4.2.13-1 Mobile Identity - Type of Identity Coding............................................................... 297 15
Table 4.2.15-1 Call Priority.............................................................................................................. 300 16
Table 4.2.15-2 Priority - Queuing Allowed ..................................................................................... 301 17
Table 4.2.15-3 Priority - Preemption Allowed................................................................................. 301 18
Table 4.2.16-1 Cause Class Values.................................................................................................. 302 19
Table 4.2.16-2 Cause Values............................................................................................................ 302 20
Table 4.2.17-1 Cell Identifier - Cell Identification Discriminator List ............................................ 305 21
Table 4.2.17-2 Cell Identifier - Cell Identification Discriminator = 0000 0010............................ 305 22
Table 4.2.20-1 Circuit Identity Code Extension - Circuit Mode Field............................................. 310 25
Table 4.2.23-1 IS-2000 Channel Identity 3X- Physical Channel Type ............................................ 315 26
Table 4.2.23-2 IS-2000 Channel Identity 3X- Reverse Pilot Gating Rate........................................ 316 27
Table 4.2.27-1 IS-2000 Channel Identity - Physical Channel Type ................................................. 322 28
Table 4.2.27-2 IS-2000 Channel Identity - Reverse Pilot Gating Rate............................................. 322 29
Table 4.2.32-1 Protocol Discriminator............................................................................................. 328 30
Table 4.2.36-1 Reject Cause Value.................................................................................................. 332 31
Table 4.2.37-1 Authentication Challenge Parameter - Random Number Type................................ 333 32
Table 4.2.38-1 Authentication Response Parameter - Auth Signature Type.................................... 334 33
Table 4.2.42-1 Signal Value: Tones................................................................................................. 338 34
Table 4.2.42-2 Signal Value: cdma2000
Alerting.......................................................................... 339 35
Table 4.2.42-4 Signal - Signal Value Mapping: TIA/EIA-41, TIA/EIA/IS-2000, 36
and this Specification ........................................................................................................................ 340 37
Table 4.2.44-1 Called Party BCD Number - Type of Number Values............................................. 343 38
Table 4.2.44-2 Called Party BCD Number - Numbering Plan Identification Values....................... 344 39
Table 4.2.44-3 Called Party BCD Number - Number Digit Values................................................. 344 40
Table 4.2.46-2 Cause Layer 3 - Location......................................................................................... 348 41
Table 4.2.46-3 Cause Layer 3 - Cause (Class) Value....................................................................... 348 42
Table 4.2.46-4 Cause Layer 3 Values .............................................................................................. 349 43
Table 4.2.49-1 Location Registration Type...................................................................................... 353 44
Table 4.2.53-1 Service Option Values ............................................................................................. 360 45
Table 4.2.62-1 Radio Environment and Resources .......................................................................... 373 46
Table 4.2.72-1 PACA Order - PACA Action Required ................................................................... 384 47
Table 4.2.80-1 Band Class ............................................................................................................... 392 48
Table 4.2.87-1 Return Cause............................................................................................................ 399 49
Table 5.1-1 Timer Values and Ranges Sorted by Name ........................................................................ 405 50
51
TIA-2001.4-C
1 Section 1
1.0 Introduction 1
2
1.1 Overview 3
This document contains the message procedures, bitmaps, information elements, and 4
timers used to define the A1 interface. 5
1.1.1 Purpose 6
The purpose of this document is to provide a standard for interfacing a Mobile Switching 7
Center (MSC) with one or more Base Stations (BSs). This document defines the 8
functional capabilities, including services and features, of the specified interface. These 9
services and features are the defining characteristics that are the basis for the overall 10
system standard. 11
1.1.2 Scope 12
This standard provides the specification for the interface which coincides with the 13
Reference Point A defined in the TR45 Network Reference Model shown in [26]. The 14
scope of this standard includes the following topics: 15
Descriptions of the specified functional capabilities that provide wireless 16
telecommunications services across the A1 interface as defined in the TR45 Network 17
Reference Model; 18
Descriptions of the division of responsibility of the functions provided between the 19
BS and the MSC, without prescribing specific implementations; 20
Descriptions of the A1 interface standard that support DS-41 and cdma2000
1
21
systems. 22
1.2 References 23
24
1.2.1 TIA / EIA 25
For ease of cross referencing, the Telecommunications Industry Association (TIA) / 26
with the 3GPP2 references, provided in section 1.2.2. For consistency within IOS parts, 28
[1] TIA/EIA/IS-2000.1-B, Introduction to cdma2000

[2] TIA/EIA/IS-2000.2-B-1, Physical Layer Standard for CDMA 2000 Spread 33

1
cdma2000

TIA-2001.4-C
Section 1 2
[3] TIA/EIA/IS-2000.3-B-1, Medium Access Control (MAC) Standard for 1
cdma2000

[4] TIA/EIA/IS-2000.4-B-1, Signaling Link Access Control (LAC) Standard for 3
cdma2000

[5] TIA/EIA/IS-2000.5-B-1, Upper Layer (Layer 3) Signaling Standard for 5
cdma2000

Spread 7
[7] Reserved. 9
[8] Reserved. 10
[9] TIA/EIA-41-D, Cellular Radio-Telecommunications Intersystem Operations; 11
December 1997. 12
[10] TIA/EIA-95-B; Mobile Station - Base Station Compatibility Standard for 13
Wideband Spread Spectrum Cellular Systems; March 1999. 14
[11] Reserved. 15
Access 16
Access 18
[14] Reserved. 20
[15] Reserved. 21
[16] Reserved. 22
Access 23
Network Interfaces Part 7 (A10 and A11 Interfaces), May 2002. 24
[18] TIA/EIA-553-A, Mobile Station - Base Station Compatibility Specification; 25
November 1999. 26
[19] TIA/EIA-634-B, M(S)C-BS Interface for Public Wireless Communications 27
Systems , April 1999. 28
[20] TIA/EIA/IS-637-B, Short Message Service for Spread Spectrum Systems, 29
January 2002. 30
[21] TIA/EIA-664-A, Cellular Wireless Features Description; December 2000. 31
[22] TIA/EIA/IS-707-A-2, Data Services Option Standard for Spread Spectrum 32
Systems - Addendum 2, June 2000. 33
[23] TIA/EIA/IS-801, Position Determination Service Standard for Dual Mode 34
Spread Spectrum Systems, November 1999. 35
[24] TIA/EIA-895-A, CDMA Tandem Free Operation, October 2002. 36
[25] TIA/EIA/TSB58-E, Administration of Parameter Value Assignments for 37
TIA/EIA Spread Spectrum Standards; January 2002. 38
[27] TIA-735, Enhancements to TIA/EIA-41-D & TIA/EIA-664 for Advanced 40
Features in Wideband Spread Spectrum Systems, January 1, 2002. 41
[28] TIA/EIA/IS-880, TIA-41-D based network enhancements for CDMA packet data 42
service (C-PDS) phase 1, July 2002. 43
1.2.2 3GPP2 44

[2] 3GPP2 C.S0002-B-1, Physical Layer Standard for cdma2000
Spread Spectrum 49
TIA-2001.4-C
3 Section 1
[3] 3GPP2 C.S0003-B-1, Medium Access Control (MAC) Standard for cdma2000
1
[4] 3GPP2 C.S0004-B-1, Signaling Link Access Control (LAC) Standard for 3
cdma2000

[5] 3GPP2 C.S0005-B-1, Upper Layer (Layer 3) Signaling Standard for 5
cdma2000

[6] 3GPP2 C.S0006-B-1, Analog Signaling Standard for cdma2000
Spread 7
[7] Reserved. 9
[8] Reserved. 10
[9] Reserved. 11
[10] Reserved. 12
Access 13
Access 15
Access 17
[14] Reserved. 19
[15] Reserved. 20
[16] Reserved. 21
Access 22
[18] Reserved. 24
[19] Reserved. 25
[21] 3GPP2 S.R0006, Cellular Features Description, December 1999. 28
[22] 3GPP2 C.S0017-0-2, Data Service Options for Spread Spectrum Systems 29
Addendum 2, January 2000. 30
[23] 3GPP2 C.S0022-0, Location Services (Position Determination Service), 31
December 1999. 32
[24] 3GPP2 A.S0004-B, CDMA Tandem Free Operation, August 2002. 33
[25] 3GPP2 C.R1001-C, Administration of Parameter Value Assignments for 34
cdma2000
Spread Spectrum Standards, Release C, January 2002. 35

Spread Spectrum 36
[27] 3GPP2 N.S0010-0_v1.0, Advanced Features in Wideband Spread Spectrum 38
Systems, updated. 39
[28] N.S0029-0, TIA/EIA-41-D Based Network Enhancements for CDMA Packet 40
Data Service (C-PDS), Phase I, Revision 0, June 2002. 41
1.2.3 Standards Committee T1 42
[29] ANSI T1.607, ISDN - Layer 3 Signaling Specification for Circuit Switched 43
Bearer Service, July 1990. 44
[30] ANSI T1.628, Routing, Bridging and Transfer of Emergency Service Calls, May 45
1993. 46
[31] ITU-T Recommendation E.164, The International Public Telecommunication 49
Numbering Plan, May 1997. 50
TIA-2001.4-C
Section 1 4
[32] ITU-T Recommendation E.212, Identification Plan for Land Mobile Stations, 1
1993. 2
[33] ITU-T Recommendation F.69, The International Telex Service - Service and 3
Operational Provisions Of Telex Destination Codes and Telex Network 4
Identification Codes, June 1994. 5
[34] ITU-T Recommendation X.121, International Numbering Plan for Public Data 6
Networks, October 1996. 7
[35] ITU-T Recommendation Q.931, ISDN User-Network Interface Layer 3 Specifi- 8
cation for Basic Call Control, May 1998. 9
1.2.5 Other 10
[36] ETSI TS 125.413 V3.3.0, Technical Specification Universal Mobile 11
Telecommunications System (UMTS); UTRAN Iu Interface RANAP Signalling, 12
November 2000. Refer also to 3GPP TS 25.413 V3.3.0. 13
14
TIA-2001.4-C
5 Section 1
1.3 Terminology 1
2
1.3.1 Acronyms 3
4
Acronym Meaning
AC Authentication Center
AMPS Advanced Mobile Phone System
ANID Access Network Identifiers
ARFCN Absolute Radio Frequency Channel Number
ASCII American Standard Code for Information Interchange
AUTHBS Authentication
AUTHR Authentication Response
AUTHU Unique Challenge Authentication Response
BCD Binary Coded Decimal
BS Base Station
BSAP Base Station Application Part
BSMAP Base Station Management Application Part
CANID Current Access Network Identifier
CI Cell Identity
CIC Circuit Identity Code
CDG CDMA Development Group
CIE Content of Information Element
COUNT Call History Count
DLCI Data Link Connection Identifier
DS Direct Spread
DTAP Direct Transfer Application Part
DTX Discontinuous Transmission
ERAM Enhanced Rate Adaptation Mode
TIA-2001.4-C
Section 1 6
Acronym Meaning
ETSI European Telecommunications Standards Institute
EVRC Enhanced Variable Rate Codec
FPC Forward Power Control
IEI Information Element Identifier
IMT International Mobile Telecommunications
IS Interim Standard
ITU International Telecommunications Union
JTACS Japanese Total Access Communications
kbps kilobits per second
LAC Location Area Code
LCM Long Code Mask
LI Length Indicator
LPM logical to physical mapping
MAC Medium Access Control
MC-41 Multi-Carrier (ANSI)-41
MCC Mobile Country Code
MIN Mobile Identification Number
MNC Mobile Network Code
MPC
MS
Mobile Positioning Center
Mobile Station
MSCID Mobile Station Connection Identifier
MTSO Mobile Telephone Switching Office
MUX Multiplexer
N-AMPS Narrow band AMPS
NDSS
NID
Network Directed System Selection
Network ID
NMT Nordic Mobile Telephone
TIA-2001.4-C
7 Section 1
Acronym Meaning
Provisioning
OTA Over-the-Air
OTAPA Over-the-Air Parameter Administration
OTASP Over-the-Air Service Provisioning
OTD Orthogonal Transmit Diversity
PANID Previous Access Network Identifier
PBX Private Branch Exchange
PCS Personal Communications System
PDE Position Determining Equipment
PLD Position Location Data
PLMN Public Land Mobile Network
P-P PDSN-PDSN
PSI PACA Supported Indicator
PSMM Pilot Strength Measurement Message
PSTN Public Switched Telephone Network
PZID Packet Zone ID
QCELP Q Code Excited Linear Prediction
QOF Quasi-Orthogonal Function
QPCH Quick Paging Channel
RAND Random Variable
RANDBS Random Variable BS Challenge
RANDC Random Confirmation
RANDSSD Random SSD
RANDU Random Variable - Unique Challenge
RC Radio Configuration, Radio Class
RF Radio Frequency
RNC Radio Network Controller (DS-41)
SCM Station Class Mark
SME Signaling Message Encryption
SMS Short Message Service
TIA-2001.4-C
Section 1 8
Acronym Meaning
SMS-MO SMS Mobile Originated
SMV Selectable Mode Vocoder
SOCI Service Option Connection Identifier
SR_ID Service Reference Identifier
SRNC-ID Source Radio Network Controller Identifier
S-RNTI Source Radio Access Network Temporary Identifier
SSD Shared Secret Data
TACS Total Access Communications
TCH traffic channel
TDSO Test Data Service Option
TFO Tandem Free Operation
TMSI Temporary Mobile Station Identity
UMTS Universal Mobile Telecommunications System
UZID User Zone ID
VLR Visitor Location Register
VP Voice Privacy
1.3.2 Definitions 1
Channel Assignment Message. Either a Channel Assignment Message or Extended 3
Channel Assignment Message. 4
MC-41. An operational mode in which the BS and MS operate with the multi-carrier 5
(MC) radio layers and the upper layers defined in [1]~[6] that conform to and 6
interoperate with ANSI-41 based networks. 7
ORYX. A wireless data encryption and decryption algorithm. 8
Service Instance. An instance of a higher level communication service between the MS 9
user and various other endpoints. 10
Service Provider Network. A network operated by either the home service provider or 11
the visited service provider. The home service provider maintains the customer business 12
relationship with the user. The visited service provider provides access services through 13
the establishment of a service agreement with the home service provider. 14
Serving Network. The network that provides access services to the user. 15
System Identification. The System Identification (SID) is a number that uniquely 16
identifies a network within a cellular or PCS system. 17
TIA-2001.4-C
9 Section 1
1.4 Message Body, Coding, and Ordering of Elements 1
For each A1 (BSAP) interface message there are a number of information elements that 2
are individually defined in section 4.2. Each information element in a given message is 3
tagged with a reference in section 4.2, a direction indication (i.e., some elements within a 4
message are bi-directional and others are not), and a mandatory/optional type (M/O) 5
indicator. Information elements that are marked as optional carry an additional indication 6
of being either required (R) or conditional (C). Some information elements are reused in 7
multiple messages. 8
The DIRECTION indication associated with each message element pertains to the use of 9
that particular message element when used with the particular message (i.e., use of the 10
message element may be different in other messages). The format of the DIRECTION 11
indication is as follows: 12
Table 1.4-1 Element Flow DIRECTION Indication 13
BS -> MSC Element flows from the BS to the MSC
MSC -> BS Element flows from the MSC to the BS
BS <-> MSC Element flows both ways to/from the MSC and the BS
The inclusion of information elements in each message is specified as follows: 14
M information elements which are mandatory for the message. 15
O information elements which are optional for the message. 16
R Required in the message whenever the message is sent. 17
C Conditionally required. The conditions for inclusion of this element are 18
defined in the operation(s) where the message is used (refer to [13]) 19
and in footnotes associated with the table defining the order of 20
information elements in the message. 21
Information elements which are mandatory for a given message shall be present, and 22
appear in the order shown in the message definitions in this chapter. 23
Information elements which are optional for a given message are included as needed for 24
specific conditions. When included, they shall appear in the order shown in the message 25
definition given in this chapter. 26
An information element can be mandatory for some messages and optional for other 27
messages. 28
The bitmap tables in the message subsections of 3.0 are patterned after the format for 29
the information elements of section 4.2 and use the following conventions: 30
! Element Name{<# instances>: 31
= Name of information element. 32
Different elements within a message are separated by 33
double lines. 34
Fields within elements are separated by single lines. 35
Octets are renumbered at the beginning of every 36
element. 37
[<values>] = Set of allowed values. 38
} Element Name The number of instances of an element is 1 by default. 39
If the Element Name{<# instances }Element 40
TIA-2001.4-C
Section 1 10
Name notation is used, the <# instances> notation 1
indicates: 2
n = exactly n occurrences of the element 3
n+ = n or more occurrences of the element 4
1..n = 1 to n inclusive occurrences of the element 5
label {<# instances>: 6
<octet 1> 7
<octet m> 8
} label = Number of instances of the bracketed set of fields 9
where <# instances> notation indicates: 10
n = exactly n occurrences of the field 11
n+ = n or more occurrences of the field 12
1..n = 1 to n inclusive occurrences of the field 13
ssss ssss 14
= Variable length field. 15
ssss ssss 16
1.5 Forward Compatibility Guidelines 17
This standard is intended to evolve to accommodate new features and capabilities. To 18
ensure that equipment implemented to one revision level interoperates with equipment 19
implemented to later revision levels the following guidelines are defined for the 20
processing of messages and for the development of messages in future revisions of this 21
standard. 22
Unexpected signaling information may be received at an entity due to differing levels of 23
signaling protocol at different entities within a network: an entity using a more enhanced 24
version of the protocol may send (unless overridden by section 1.8) information to an 25
entity implemented at a lower level of the protocol which is outside the protocol 26
definition supported at that receiving entity. 27
It may happen that an entity receives unrecognized signaling information, i.e., messages, 28
element types or element values. This can typically be caused by the upgrading of the 29
protocol version used by other entities in the network. In these cases the following 30
message processing guidelines are invoked (unless overridden by section 1.8) to ensure 31
predictable network behavior. 32
If the receiving entity is implemented to IOS V4.0 or a later version of that standard, then 33
the sending entity shall send messages that are correctly formatted for the version of the 34
IOS declared to be implemented by the sending entity, unless overridden by section 1.8. 35
If the receiving entity is implemented to a CDG IOS version less than 3.1.0, then if the 36
sending entity is at an equal or greater version than the receiver, the sending entity shall 37
format messages according to the version of the protocol implemented at the receiving 38
entity. 39
TIA-2001.4-C
11 Section 1
For example, a CDG IOS version 3.1.0 entity by using the following guidelines (unless 1
overridden by section 1.8) may be capable of ignoring additional new elements or fields 2
within elements sent by an entity implemented to an IOS version higher than 3.1.0. 3
1.6 Message Processing Guidelines 4
The following message processing guidelines apply unless overridden by explicit 5
processing directions in other places within this standard. 6
In the guidelines in this section, optional includes both optional conditional and 7
optional required information elements as indicated in the Type column of the 8
individual message IE tables in section 3.0. 9
1. If a message is received containing a Message Type value which is not defined for 10
the revision level implemented then the message shall be discarded and ignored. 11
There shall be no change in state or in timers due to receipt of an unknown message. 12
2. If a message is received without an expected mandatory information element for the 13
revision level implemented then the message shall be discarded and ignored. There 14
shall be no change in state or in timers due to receipt of the message. 15
3. If a message is received that contains an information element which is defined for 16
the revision level implemented but contains invalid values in some fields, these fields 17
shall be ignored and the remainder of the information element processed to the extent 18
possible. The message and all other information elements shall be processed to the 19
extent possible. Failure handling may be initiated if call processing cannot continue. 20
Also refer to message processing guidelines 9 and 10 below. 21
4. If a message is received that contains an Information Element Identifier which is not 22
defined for the revision level implemented then that element shall be discarded and 23
ignored. The message shall be processed to the extent possible. Failure handling may 24
be initiated if call processing cannot continue. 25
5. If a known but unexpected optional information element is received, that information 26
element shall be ignored. The message and all other information elements shall be 27
processed. 28
6. If a message is received without an expected optional information element the 29
message shall be processed to the extent possible. Failure handling may be initiated 30
if call processing cannot continue. 31
7. If a field within a received information element contains a value that is specified as 32
reserved or is otherwise not defined in the revision level implemented this field 33
possible. In this situation all other information elements in the message shall be 35
processed to the extent possible. 36
8. Octets and bits designated as Reserved or which are undefined for the revision 37
implemented shall be set to zero by a sending entity and ignored by a receiving 38
entity. 39
9. If an element is received containing a field that is larger than expected, i.e., is 40
indicated as having more bits/octets than expected, then the expected bits/octets of 41
that field shall be processed to the extent possible and the additional bits/octets shall 42
be ignored. 43
10. If an element is received containing a field that is smaller than expected, i.e., is 44
indicated as having fewer bits/octets than expected, then the length field or other 45
indicator shall be considered correct and the bits/octets actually present in the 46
TIA-2001.4-C
Section 1 12
element shall be processed to the extent possible. Failure handling may be initiated if 1
call processing cannot continue. 2
1.7 Message Definition Guidelines 3
1. New messages shall have a Message Type that has never been previously used. 4
2. Information Element Identifiers may be reused in future revisions only when: 5
The old use of the element identifier is not used in the new revision, and 6
The new use of the element identifier is used only in new messages which were 7
not defined in previous revisions. 8
The old use of the element identifier shall be supported within the context of the 9
old messages in which it was used. 10
3. Defined valid values of Information Elements may be changed in future revisions. 11
The new version shall define the error handling when previously valid values are 12
received. 13
4. Octets and bits which are undefined or which are defined as reserved may be used in 14
future revisions. 15
5. The Mandatory/Optional designation of Information Elements within a message shall 16
not change. 17
6. Mandatory Information elements shall be sent in the order specified in section 4.0. 18
7. New optional Information Elements in a message shall be defined after all previously 19
defined optional Information Elements. 20
8. All new Information Elements shall be defined with a length field. 21
9. New information may be added to the end of an existing Information Element, 22
provided that the Information Element is defined with a length field. 23
1.8 Message Sending Guidelines 24
For supporting backward compatibility on the A1 interface: 25
When an MSC and a BS communicate on the A1 interface, no information element shall 26
be sent which is larger or smaller in length, or have values other than expected as per the 27
protocol version of the node running on the lower protocol version. If an information 28
element is sent in a manner that violates the above principle, or if an unexpected or 29
unknown information element is sent in the middle of a message, or if an information 30
element that was required to be sent for successful message processing as per the protocol 31
revision of the node running at the lower version is not sent, then failure handling may be 32
invoked by the receiving node. If the receiving node determines that failure handling does 33
not need to be applied, then processing may continue with the receiving entity generating 34
any OAM&P logs as required. 35
Any new information elements may be sent to the node running the lower protocol 36
version if the position of those information elements is beyond the end of the information 37
elements expected by the lower protocol revision. Information elements that were defined 38
at the lower protocol revision but identified as not included and that become used at the 39
higher protocol revision and appear before the end of the information elements expected 40
by the lower protocol revision shall not be sent to the node running the lower protocol 41
revision. 42
TIA-2001.4-C
13 Section 1
If both the nodes are running the same protocol version then the above rules still apply. 1
1.9 MSC BS Functional Partitioning 2
The functions provided by the network elements on either side of the A1 interface define 3
the functions that the A1 interface supports. Figure 1.9-1 depicts a model of the A1 4
interface functional planes. The four functional planes embody all of the functions that 5
the A1 interface supports. 6
Physical Facilities
Transport
Protocols
Call
Proc.,
Supp.
Services
Radio
Resource
Mngmnt.
Mobility
Mngmnt.
Trans.
Facilities
Mngmnt.
Transport
Protocols
Call
Proc.,
Supp.
Services
Radio
Resource
Mngmnt.
Mobility
Mngmnt.
Trans.
Facilities
Mngmnt.
MSC BSC
7
Figure 1.9-1 MSC-BS Interface Functional Planes 8
The Call Processing plane manages call control and telecommunications services for 9
the subscribers. 10
The Radio Resource Management plane manages stable links between the MSs and 11
the MSC and supports the movement of subscribers during calls (i.e., handoff 12
control). 13
The Mobility Management plane manages subscriber databases and subscriber 14
location data. 15
The Transmission Facilities Management plane is the basis for the A1 interface 16
telecommunications services. It manages the transmission means for the 17
communication needs of the subscribers as well as the required information transfer 18
between the BS and MSC. 19
20
TIA-2001.4-C
Section 1 14
1
3
4
5
6
TIA-2001.4-C
15 Section 2
2.0 Message Procedures 1
2
2.1 Call Processing Message Procedures 3
4
2.1.1 Complete Layer 3 Information 5
The Complete Layer 3 Information message is a BSMAP message that contains the CM 6
Service Request message, the Paging Response message, or the Location Updating 7
Request message. 8
2.1.1.1 Successful Operation 9
Refer to section 2.1.2.1, Successful Operation, when this message is used in conjunction 10
with the CM Service Request message. Refer to section 2.1.5.1 when this message is used 11
in conjunction with the Paging Response message. Refer to section 2.3.7.1 when this 12
message is used in conjunction with the Location Updating Request message. 13
2.1.1.2 Failure Operation 14
Refer to section 2.1.2.2, Failure Operation, when this message is used in conjunction with 15
the CM Service Request message. Refer to section 2.1.5.2 when this message is used in 16
conjunction with the Paging Response message. Refer to section 2.3.7.2 when this 17
message is used in conjunction with the Location Updating Request message. 18
2.1.2 Connection Management (CM) Service Request 19
When the MSs originating access attempt is received by the BS, the BS constructs the 20
CM Service Request DTAP message, places it in the Complete Layer 3 Information 21
message, and sends the message to the MSC. 22
In a mobile origination scenario, the BS transfers a CM Service Request message to the 24
MSC in a Complete Layer 3 Information message. The BS starts timer T
303
. The CM 25
Service Request message and the subsequent MSC response are used for connection 26
establishment. 27
If the Origination Message sent from the MS to the BS indicates that it is to be followed 28
by an Origination Continuation Message, the BS shall include an Origination 29
Continuation Indicator in the CM Service Request message. If the MSC receives a CM 30
Service Request message where the Origination Continuation Indicator is present, it shall 31
start timer T
312
to wait for a CM Service Request Continuation message. 32
In the Access Probe Handoff scenario, the source BS (the BS on which the first access 33
probe was sent), upon receiving an origination request for the same MS and the same call 34
forwarded via an A7 connection from another BS, may choose to send a second CM 35
Service Request to the MSC. In other scenarios (e.g. Silent Reorigination), the BS may 36
TIA-2001.4-C
Section 2 16
receive multiple Originations from the same MS, and may choose to send a second CM 1
Service Request message to the MSC. The MSC shall be able to handle a CM Service 2
Request for an MS that is already engaged in an origination attempt by sending a Clear 3
Command message to the BS containing a cause value of Do not notify MS. The MSC 4
shall send this message on the SCCP connection associated with the second CM Service 5
Request. The BS shall be able to handle Clear Command messages from the MSC for 6
these duplicated CM Service Request messages. 7
The base station may select an available channel based on the MSs capabilities, and 8
assign the MS to that channel at any time following the receipt of the MSs originating 9
access. 10
If the BS fails to receive an Assignment Request message, PACA Command message 12
(e.g., if the call is eligible for PACA service), Service Redirection message, or Clear 13
Command message in response to the CM Service Request message prior to expiration of 14
timer T
303
, then it may send a Reorder or Release message to the MS, and shall initiate 15
call clearing by sending a Clear Request message to the MSC with the cause value set to 16
Timer expired if an underlying transport connection exists. 17
If the MSC has started timer T
312
, but fails to receive a CM Service Request 18
Continuation message before the expiration of timer T
312
and has not received sufficient 19
information to process the call, then it shall initiate call clearing by sending a Clear 20
Command message to the BS with the cause value set to Timer expired. 21
2.1.2.3 Abnormal Operation 22
The MSC may clear the call in response to the CM Service Request by refusing the 23
connection request via the primitive appropriate to the underlying transport layer. 24
2.1.3 Connection Management (CM) Service Request Continuation 25
The CM Service Request Continuation message is sent from the BS to the MSC, when 26
the BS receives an Origination Continuation Message from the MS containing 27
information that needs to be conveyed to the MSC (e.g. dialed digits that did not fit in the 28
Origination Message). 29
Upon receiving an Origination Continuation Message from the MS, the BS sends a CM 31
Service Request Continuation message to the MSC. No response is expected from the 32
MSC to this message. The MSC stops timer T
312
when it receives the CM Service 33
Request Continuation message. Refer to section 2.1.2.1. 34
None. 36
TIA-2001.4-C
17 Section 2
2.1.4 Paging Request 1
This BSMAP message is sent from the MSC to the BS to initiate a mobile terminated call 2
setup scenario. This message may also be sent for location purposes. 3
The MSC determines that an MS in its serving area needs to be paged and initiates the 5
paging procedure. It starts timer T
3113
, sends the Paging Request message to the BS, and 6
waits for the Complete Layer 3 information containing a Paging Response message. 7
When the BS receives the Paging Request message from the MSC, it determines from 8
which cell(s) to broadcast the page request. The page messages are distributed to the 9
appropriate cell(s), which broadcast the page message over their paging channels. Where 10
necessary, the page message is inserted into the computed paging channel slot. 11
If a Complete Layer 3 Information message containing a Paging Response message has 13
not been received by the MSC before timer T
3113
expires, the MSC may repeat the 14
Paging Request message and restart timer T
3113
. 15
2.1.5 Paging Response 16
This DTAP message is sent from the BS to the MSC, after receipt of a Page Response 17
Message from the MS, in response to a Paging Request message. The Paging Response 18
and the subsequent MSC response are used for connection establishment. 19
When the MS recognizes a page message containing its identity, it sends a response 21
message to the BS. The BS constructs the Paging Response message using the 22
information received from the MS, encapsulates it in a Complete Layer 3 Information 23
message (refer to section 2.1.1, Complete Layer 3 Information), and sends this message 24
to the MSC. The BS starts timer T
303
to await reception of the Assignment Request 25
message. The MSC stops timer T
3113
upon receiving the Paging Response message. 26
In the Access Probe Handoff scenario, the source BS (the BS on which the first access 27
probe was sent), upon receiving a page response for the same MS and the same call 28
forwarded via an A7 connection from another BS, may choose to send a second Paging 29
Response to the MSC. The MSC shall be able to handle a Paging Response for an MS 30
that is already engaged in a termination attempt by sending a Clear Command message to 31
the BS containing a cause value of Do not notify MS. The MSC shall send this 32
message on the SCCP connection associated with the second Paging Response. The BS 33
shall be able to handle Clear Command messages from the MSC for duplicated Paging 34
Response messages. 35
The BS may select an available channel based on the MSs capabilities, and assign the 36
MS to that channel at any time following the receipt of a Page Response Message from 37
the MS. 38
TIA-2001.4-C
Section 2 18
No action is taken at the BS on failure to receive a Paging Response from the MS. 2
If the BS fails to receive an Assignment Request message or Clear Command message in 3
response to the Paging Response message prior to expiration of timer T
303
, then it may 4
send a Release message to the MS, and clear all associated resources. 5
2.1.5.3 Abnormal Operation 6
If a Paging Response is received by the MSC for a call that is no longer active, the MSC 7
may clear the call. 8
2.1.6 Progress 9
This DTAP message may be sent by the MSC to trigger tone generation at the MS (e.g., 10
via a Reorder Order or Intercept Order to the MS) prior to clearing a call request. Local 11
tone generation allows the network to convey information to a user by means of tones. 12
When the BS receives the Progress message from the MSC it takes the appropriate action 14
to request the MS to generate the tone as indicated. 15
The MSC should delay sending any call clearing message after a Progress message to 16
allow the local tone generation at the MS. In addition, the BS may need to be aware of 17
the time needed by the MS to generate the local tone. 18
None. 20
2.1.7 Assignment Request 21
This BSMAP message is sent from the MSC to the BS to request assignment of radio 22
resources. 23
After sending this message to the BS, the MSC starts timer T
10
and waits for the 25
Assignment Complete message from the BS. 26
303
or T
20
upon receipt of the Assignment Request message, selects 27
a traffic channel, sends the channel assignment message to the MS (unless the MS is 28
already on a traffic channel), and waits for the confirmation from the MS that the MS 29
reached the assigned traffic channel. 30
If the MSC fails to receive an Assignment Complete message, or an Assignment Failure 32
message before the expiration of timer T
10
, then it shall initiate call clearing. 33
TIA-2001.4-C
19 Section 2
2.1.8 Assignment Complete 1
This BSMAP message indicates that the requested assignment has been completed 2
correctly. The sending of the Assignment Complete message also indicates to the MSC 3
that it is now responsible for providing in-band treatment of the call if required. 4
When the MS and BS have successfully negotiated the traffic channel and service, the BS 6
sends this message to the MSC. 7
When the MSC receives this message, it stops timer T
10
and starts timer T
301
(unless the 8
Assignment Complete message is received as part of a mobile originated call or a packet 9
data call) and waits for the Connect or Flash With Information message from the BS. 10
Note that for mobile originated calls and network-initiated reactivation of packet data 11
calls, the MSC considers the call to be stable and in the conversation state after receiving 12
the Assignment Complete message. In all other cases the MSC considers the call to be 13
stable and in the conversation state after receiving the Connect message. 14
None. 16
2.1.9 Assignment Failure 17
This BSMAP message is sent from the BS to the MSC to indicate that the requested 18
assignment procedure could not be successfully completed. 19
Upon recognizing that the assignment can not be completed, the BS sends the 21
Assignment Failure message, starts timer T
20
and waits for the MSC to respond with an 22
Assignment Request message, Service Release message, or a Clear Command message. 23
An Assignment Request message is used if the MSC chooses to perform assignment retry 24
and the call was not queued for PACA service. The MSC stops timer T
10
upon receipt of 25
the Assignment Failure message.

26
If timer T
20
expires, the BS shall send a Clear Request or Service Release message to the 28
MSC. 29
2.1.10 Connect 30
This DTAP message informs the MSC that the called MS has entered the conversation 31
state. The Connect message is not sent for network initiated packet data reactivation. It is 32
sent for all other mobile terminated service options when a connect message is received 33
from the MS. 34
TIA-2001.4-C
Section 2 20
When the BS receives the connect indication from the MS, it sends the Connect message 2
to the MSC. 3
Upon receiving the Connect message, the MSC connects both parties, and stops timer 4
T
301
. 5
If the MSC fails to receive the Connect message prior to expiration of timer T
301
then it 7
performs exception handling (e.g., announcement, forwarding). The specific actions are 8
the MSC manufacturers concern. 9
2.1.11 Service Release 10
2.1.11.1 Base Station Initiated 11
This DTAP message is sent from the BS to the MSC to release service instances 12
associated with a single SOCI while other SOCIs are present. 13
2.1.11.1.1 Successful Operation 14
Upon receiving the Service Request Message, Resource Release Request Message or 15
Resource Release Request Mini Message from the MS, the BS shall send a Service 16
Release message to the MSC. The BS starts timer T
308
and waits for a Service Release 17
Complete message from the MSC. 18
2.1.11.1.2 Failure Operation 19
If a Service Release Complete message is not received from the MSC while timer T
308
is 20
active, the BS may resend a Service Release message to the MSC and restart timer T
308
. 21
If the Service Release Complete message is not received from the MSC before timer T
308
22
expires a second time or if the BS chooses not to resend the Service Release message, the 23
BS shall cease further supervision of this service option connection, release all dedicated 24
resources corresponding to this service, and shall release the service. 25
2.1.11.2 MSC Initiated 26
This DTAP message is sent from the MSC to the BS to release a single service that is not 27
the only one connected from the concurrent service. 28
Upon receiving a clear indication corresponding to a single service from the network, the 30
MSC shall send a Service Release message to the BS. This message may also be sent by 31
the MSC upon receipt of an Assignment Failure message associated with a concurrent 32
service setup. The MSC starts timer T
308
and waits for a Service Release Complete 33
message from the BS. The BS stops timer T
20
or timer T
303
(if either is running) upon 34
receipt of the Service Release message. 35
TIA-2001.4-C
21 Section 2
If a Service Release Complete message is not received from the BS while timer T
308
is 2
active, the MSC may resend a Service Release message to the BS and restart timer T
308
. 3
If the Service Release Complete message is not received from the BS before timer T
308
4
expires a second time or if the MSC chooses not to resend the Service Release message, 5
the MSC shall cease further supervision of this service option connection, release all 6
dedicated resources corresponding to this service, and shall release the service. 7
2.1.12 Service Release Complete 8
This message is sent by either the BS or the MSC. 9
2.1.12.1 MSC Initiated 10
This DTAP message is sent from the MSC to the BS as a response to the Service Release 11
message. 12
Upon receiving the Service Release message from the BS, the MSC sends a Service 14
Release Complete message to the BS. 15
When the BS receives a Service Release Complete message, it stops timer T
308
and 16
performs the appropriate procedure to release the dedicated resources associated with the 17
service. 18
None. 20
2.1.12.2 BS Initiated 21
This DTAP message is sent from the BS to the MSC as a response to the Service Release 22
message. 23
Upon receiving the Service Release message from the MSC, the BS sends a Service 25
Release Complete message to the MSC. 26
When the MSC receives a Service Release Complete message, it stops timer T
308
and 27
performs the appropriate procedure to release the dedicated resources associated with the 28
service. 29
None. 31
TIA-2001.4-C
Section 2 22
2.1.13 Clear Request 1
This BSMAP message is sent from the BS to the MSC upon failure of a radio channel or 2
when the MS sends a Release Order to clear the call. 3
The BS, after sending the Clear Request message, starts timer T
300
and waits for a Clear 5
Command message from the MSC. Upon receiving the Clear Request message from the 6
BS, the MSC sends a Clear Command message to the BS and waits for a Clear Complete 7
message. 8
If a Clear Command message is not received from the MSC while timer T
300
is active, 10
the BS may resend the Clear Request message to the MSC and restart timer T
300
. If the 11
Clear Command message is not received from the MSC before timer T
300
expires a 12
second time or if the BS chooses to not resend the Clear Request message, the BS shall 13
cease further supervision of this call connection, release all dedicated resources, and shall 14
release the connection. 15
2.1.14 Clear Command 16
This BSMAP message is sent from the MSC to the BS. Upon receipt of the Clear Request 17
message, the MSC sends a Clear Command message to the BS to instruct the BS to 18
release the associated dedicated resources. Upon receipt of the Handoff Complete 19
message from the target BS, the MSC sends a Clear Command message to the source BS 20
if it has not already done so. 21
Additionally, upon the receipt of a Handoff Commenced message, the MSC may send a 22
Clear Command message to the source BS to release the associated dedicated resources. 23
Upon receiving a clear indication from the network, the MSC shall send the Clear 24
Command message to the BS to clear the call. 25
After sending the Clear Command message to the BS, the MSC starts timer T
315
and 27
waits for the Clear Complete message from the BS. This operation is considered to be 28
successful if the Clear Complete message is received by the MSC. The MSC stops timer 29
T
315
upon receipt of the Clear Complete message. 30
When the BS receives a Clear Command message, it stops timer T
300
, T
303,
T
306
or T
9,
if 31
they are active, performs the appropriate procedure to release the MS and clears 32
associated dedicated resources. 33
If the Clear Command message contains a cause value of Do not notify MS, the BS 34
shall release terrestrial and radio resources and send no further messages to the MS. 35
If the MSC fails to receive the Clear Complete message before the expiration of timer 37
T
315
, the MSC may send the Clear Command message a second time and restart timer 38
TIA-2001.4-C
23 Section 2
T
315
. If the MSC does not receive the Clear Complete message, the MSC shall release the 1
underlying transport connection to clear the A1 signaling connection. 2
2.1.15 Clear Complete 3
This BSMAP message is sent from the BS to the MSC upon receipt of the Clear 4
Command message. 5
Upon receipt of the Clear Complete message from BS, the MSC stops timer T
315
and 7
releases the transport connection being used for the call. 8
None. 10
2.1.16 Alert With Information 11
This DTAP message is sent from the MSC to the BS. Upon receipt of this message, the 12
BS shall send an Alert With Information Message on the air interface. 13
The MSC may send this message to the BS, after it has sent an Assignment Request to 15
the BS, to request that the BS send an Alert With Info Message on the air interface. This 16
message may be sent by the MSC for mobile control purposes. For example, this message 17
may be used by the MSC to cause the MS to do audible alerting when it had been 18
previously doing silent alerting during a mobile termination call setup. 19
None. 21
2.1.17 BS Service Request 22
This BSMAP message is sent from the BS to the MSC to begin a BS initiated call setup. 23
It is also used to initiate an ADDS Page procedure to deliver a short data burst to an MS. 24
For short data bursts, the message is used to transport the data to the MSC for delivery to 25
an MS. 26
To initiate a call setup, the BS sends a BS Service Request message to the MSC 28
containing the identity of the MS to be paged. When the BS/PCF receives data from the 29
PDSN destined for an MS with a dormant packet data service instance, the BS may 30
deliver the data as a short data burst via the ADDS Page procedure, by sending a BS 31
Service Request message including the application data to be sent to the MS. The BS 32
starts timer T
311
and awaits the reception of the BS Service Response message. 33
TIA-2001.4-C
Section 2 24
If a BS Service Response message is not received at the BS before the expiration of timer 2
T
311
the BS may resend the BS Service Request message. For short data burst delivery to 3
a MS, if the BS times out waiting for a BS Service Response message from the MSC, the 4
BS shall not resend the BS Service Request message, and shall discard the data. 5
2.1.18 BS Service Response 6
This BSMAP message is sent from the MSC to the BS in response to a BS Service 7
Request. 8
The MSC shall send a BS Service Response message to the BS originating the BS 10
Service Request message. Upon receiving a BS Service Response message the BS stops 11
timer T
311
. 12
None. 14
2.1.19 Additional Service Notification 15
This BSMAP message is sent from the MSC to the BS to initiate additional service 16
option connection establishment when the MS already has an active service. 17
The MSC determines that an incoming call (either land or mobile originated) terminates 19
to an MS that is already active within its serving region and initiates additional service 20
option connection. The MSC starts timer T
314
, sends the Additional Service Notification 21
message to the BS, and waits for the Additional Service Request message. 22
If an Additional Service Request message has not been received by the MSC before timer 24
T
314
expires, the MSC may repeat the Additional Service Notification message and 25
restart timer T
314
. 26
2.1.20 Additional Service Request 27
This DTAP message is sent from the BS to the MSC to request the establishment of an 28
additional service option connection when the MS is already active with another service. 29
The BS shall send this message to the MSC when the BS receives an Enhanced 31
Origination Message from a MS to request an additional service option connection. The 32
BS starts timer T
303
when it sends this message. 33
TIA-2001.4-C
25 Section 2
The BS shall also send this message to the MSC in response to an Additional Notification 1
message from the MSC requesting establishment of an additional service option 2
connection. The BS starts timer T
303
When the MSC receives this message in response to a Additional Service Notification 4
message it shall stop timer T
314
. 5
If the BS fails to receive an Assignment Request, Service Release, or Clear Command 7
message prior to the expiration of timer T
303
, the BS may resend the Additional Service 8
Request message and restart the timer. If the timer expires a second time, the BS may 9
send a Retry Order or Call Assignment message to the MS and initiate service option 10
connection release by sending a Service Release message to the MSC with cause value 11
set to Timer expired. 12
2.2 Supplementary Services Message Procedures 13
14
2.2.1 Flash with Information 15
This DTAP message may be sent from the MSC to the BS to convey supplementary 16
services information which is to be sent to the MS. This message may also be sent from 17
BS to the MSC to convey supplementary service information received from the MS. 18
To send supplementary service information to the MS on a traffic channel, the MSC shall 20
include the information in a Flash with Information message. If a Tag element is included 21
in the Flash with Information message, the BS shall request that the MS acknowledge the 22
corresponding air interface message. Upon receipt of this acknowledgment, the BS shall 23
send a Flash with Information Ack message to the MSC. 24
If a Flash with Information Ack message is expected by the MSC, then it shall start timer 25
T
62
. 26
During call setup, the MSC shall queue any Flash with Information message until the 27
Assignment Complete message is received for mobile originations or packet data service 28
instance re-activations or until a Connect Message is received for mobile terminations 29
(i.e., conversation sub-state). In the event that the call is cleared prior to reaching the 30
conversation sub-state, a Feature Notification message may be sent by the MSC. 31
If the MSC receives a Flash with Information message from the BS during call setup (for 32
a supplementary service that is authorized), and timer T
301
is active, the MSC shall stop 33
timer T
301.
34
In the MSC to BS direction, if timer T
62
expires before the receipt of a Flash with 36
Information Ack message, the MSC may resend the Flash with Information message. 37
TIA-2001.4-C
Section 2 26
2.2.2 Flash with Information Ack 1
This DTAP message is sent from the BS to the MSC to acknowledge the Flash with 2
Information message. 3
This message is sent from the BS to the MSC. If the MSC had included a Tag element in 5
the Flash with Information message, then upon receiving a Layer 2 Ack for the Flash 6
with Information message from the MS, the BS sends this message to the MSC. The 7
MSC stops timer T
62
. 8
None. 10
2.2.3 Feature Notification 11
This BSMAP message is sent by the MSC to initiate sending of the feature indication 12
information to the MS. 13
If the MSC determines that it needs to deliver some feature indication information to the 15
MS, it sends this BSMAP message to the BS and starts timer T
63
. Then the MSC waits 16
for the BS to send the Feature Notification Ack message back. When the BS receives the 17
Feature Notification message, it sends an Order or Feature Notification message 18
(depending upon the applicable air interface protocol) to the MS on a Paging channel. If 19
the MSC requires an acknowledgment to the Feature Notification message, it indicates 20
this by including a Tag element in the Feature Notification message. When the BS 21
receives a Layer 2 Ack from the MS, it returns a Feature Notification Ack message, 22
including this Tag element, to the MSC. 23
The MSC may send the Feature Notification message again after timer T
63
expires. 25
2.2.4 Feature Notification Ack 26
This BSMAP message is sent by the BS to acknowledge the Feature Notification 27
message. 28
This BSMAP message is sent from the BS to the MSC. Upon receiving a Layer 2 Ack 30
from the MS for the Feature Notification message, the BS sends this message to the 31
MSC. Upon receipt of the Feature Notification Ack message the MSC stops timer T
63.
32
None. 34
TIA-2001.4-C
27 Section 2
2.2.5 PACA Command 1
This BSMAP message is sent by the MSC to inform the BS that PACA service is to be 2
applied to the call. 3
Upon receipt of the CM Service Request message from the BS, if the MSC determines 5
that it needs to queue the call for PACA service, it sends this message to the BS 6
containing priority level and time stamp information for the call. 7
After sending the PACA Command message to the BS, the MSC starts timer T
paca1
and 8
waits for the PACA Command Ack message from the BS. When the BS receives the 9
PACA Command message, it queues the call for PACA service, stops timer T
303
and 10
may send the air interface PACA Message to notify the MS that the call is queued and to 11
provide the queue position. Refer to [13] for more explanation on this feature. 12
If timer T
paca1
expires before the MSC receives the PACA Command Ack message the 14
MSC may resend the PACA Command to the BS. 15
2.2.6 PACA Command Ack 16
This BSMAP message is sent by the BS to the MSC to acknowledge that the PACA 17
request has been queued successfully. 18
Upon receipt of the PACA Command message from the MSC, the BS queues the request 20
and sends the PACA Command Ack message to notify the MSC that the call has been 21
queued. Upon receipt of the PACA Command Ack message the MSC stops timer T
paca1
. 22
None. 24
2.2.7 PACA Update 25
This BSMAP message is sent, from either the BS or the MSC, to indicate that the sending 26
entity intends to modify the queued call. 27
The PACA Update message is sent by the MSC or the BS to indicate to the receiving 29
entity (the BS or the MSC) that it shall take an appropriate action as specified by the 30
PACA Order information element in this message. After sending the PACA Update 31
message, the sending entity starts timer T
paca2
and waits to receive a PACA Update Ack 32
message from the other entity. Refer to [13] for example scenarios. 33
The PACA Update message is used in the following cases: 34
TIA-2001.4-C
Section 2 28
When idle handoff occurs the MSC sends this message to instruct the old BS to 1
remove the request from its PACA queue. 2
In the case of consecutive PACA calls the MSC may send this message to instruct 3
the BS to remove the previous request (the call associated with the first called 4
number) from its PACA queue. 5
The MSC may send this message to request the BS to update its PACA queue. If the 6
MSC doesnt receive any response from the BS within a certain period of time the 7
MSC may clear all resources associated with the call. 8
The MSC may send this message to indicate to the BS that the call has been 9
canceled. The BS shall remove the request from its PACA queue and clear any 10
resources allocated for the call. In this case, the BS shall notify the MS that the call 11
has been canceled. 12
The BS may send this message to the MSC either autonomously, if it wants to cancel 13
the call, or upon the receipt of the PACA Cancel Message from the MS. 14
If timer T
paca2
expires before the sender (MSC or BS) receives the PACA Update Ack 16
message, then the PACA Update message may be resent. 17
2.2.8 PACA Update Ack 18
This BSMAP message is sent by the BS or MSC to the MSC or BS to acknowledge that 19
an appropriate action has been taken by the BS or MSC and that its PACA information 20
has been updated. This message is sent in response to a PACA Update message. 21
The MSC or BS sends the PACA Update Ack message to inform the BS or MSC of the 23
result of the action taken in response to the PACA Update. The receiving entity stops 24
timer T
paca2
. 25
None. 27
2.2.9 Radio Measurements for Position Request 28
This BSMAP message is sent by the MSC to the BS to request a set of radio 29
measurements to be used for calculation of the MSs position. 30
When the Mobile Positioning Center (MPC) [23] determines that position determination 32
by means of software calculation is to take place for a given MS that is on a traffic 33
channel, the MSC sends a Radio Measurements for Position Request message to the BS. 34
This message indicates the MS to be measured, and the number of times to take 35
measurements. The MSC starts timer T
softpos
. 36
When the BS receives this message, it gathers the requested measurements and returns 37
them in a Radio Measurements for Position Response message. If the BS is capable of 38
TIA-2001.4-C
29 Section 2
determining the geographic location the BS may send the geographic location instead of 1
the requested measurements to the MSC. 2
If timer T
softpos
expires prior to the receipt of the Radio Measurements for Position 4
Response message, the MSC may resend this message. 5
2.2.10 Radio Measurements for Position Response 6
This BSMAP message is sent by the BS in response to a Radio Measurements for 7
Position Request message. It contains requested radio interface measurements with 8
respect to the MS whose position is to be determined or it contains the requested 9
geographic location of the MS. 10
When a BS receives a Radio Measurements for Position Request message, it gathers the 12
requested measurements and formats and sends them in a Radio Measurements for 13
Position Response message to the MSC. If the BS is capable of determining the 14
geographic location the BS may send the geographic location of the MS instead of the 15
requested measurements to the MSC. When the MSC receives this message, it stops timer 16
T
softpos
. 17
None. 19
2.3 Mobility Management Message Procedures 20
21
2.3.1 Authentication Request 22
The Authentication Request message is sent from the MSC to the BS to initiate an 23
authentication check on a specified MS. This is a DTAP message when used to perform 24
authentication on a traffic channel and a BSMAP message otherwise. 25
The MSC sends an Authentication Request message to the BS and starts timer T
3260
. 27
When the BS receives this message it forwards an Authentication Challenge message to 28
the MS. 29
When the MS receives the Authentication Challenge message, it uses the RANDU as 30
input to the authentication algorithm to generate the response parameter (AUTHU). 31
TIA-2001.4-C
Section 2 30
If timer T
3260
expires, the MSC may resend the Authentication Request message to the 2
BS, initiate call clearing, or invoke other failure processing as determined by the network 3
operator. 4
2.3.2 Authentication Response 5
This message is sent from the BS to the MSC in response to the Authentication Request 6
message. This is a DTAP message when used to perform authentication on a traffic 7
channel and a BSMAP message otherwise. 8
When a BS receives an Authentication Challenge Response message from the MS it 10
sends the Authentication Response message to the MSC. The MSC stops timer T
3260
. 11
None. 13
2.3.3 SSD Update Request 14
The SSD Update Request message is sent from the MSC to the BS to indicate that the 15
MS should update its Shared Secret Data. This DTAP message is used to perform SSD 16
update on a traffic channel. 17
The MSC sends an SSD Update Request message to the BS and starts timer T
3270
. When 19
the BS receives this message it forwards an SSD Update Message to the MS. 20
When the MS receives the SSD Update Message, it uses the 56 bit RANDSSD as input to 21
the algorithm to generate the new SSD. The MS selects a 32 bit random number 22
(RANDBS) and sends it to the BS in a Base Station Challenge Order. 23
If timer T
3270
expires prior to receipt of a Base Station Challenge message, the MSC may 25
choose to retransmit this message. 26
2.3.4 SSD Update Response 27
This message is sent from the BS to the MSC to indicate whether the MS has successfully 28
updated its SSD. It is sent by the BS only upon receipt of the SSD Update 29
Confirmation/Rejection Order from the MS. This DTAP message is used to perform SSD 30
update on a traffic channel. 31
When the MS receives the Base Station Challenge Confirmation Order from the BS, it 33
checks the validity of the response and returns an SSD Update Confirmation/Rejection 34
TIA-2001.4-C
31 Section 2
Order to the BS to indicate whether the procedure was successfully performed. The BS 1
uses the SSD Update Confirmation/Rejection Order to create the SSD Update Response 2
message which it sends to the MSC. The MSC stops timer T
3271
. 3
The MS does not update the SSD if the AUTHBS value is not considered valid. Further 4
error handling at the Home Location Register/Authentication Center (HLR/AC) is an 5
HLR/AC matter and is not detailed in this specification. 6
None. 8
2.3.5 Base Station Challenge 9
The Base Station Challenge message is sent from the BS to the MSC to verify the new 10
SSD that was calculated at the MS. This DTAP message is used to perform SSD update 11
on a traffic channel. 12
The MS selects a 32 bit random number (RANDBS) and sends it to the BS in a Base 14
Station Challenge Order. When a BS receives a Base Station Challenge Order, it 15
forwards this MS generated RANDBS in the Base Station Challenge message to the 16
MSC. The MSC stops timer T
3270
. 17
When the Home Location Register/Authentication Center (HLR/AC) receives the Base 18
Station Challenge message it uses the MS generated RANDBS and the new SSD as input 19
to the algorithm to generate the response. 20
None. 22
2.3.6 Base Station Challenge Response 23
This message is sent from the MSC to the BS in response to the Base Station Challenge 24
message. This DTAP message is used to perform SSD update on a traffic channel. 25
The MSC sends a Base Station Challenge Response message to the BS and starts timer 27
T
3271
. When the BS receives the Base Station Challenge Response message from the 28
MSC it sends the Base Station Challenge Confirmation Order to the MS. The MS checks 29
the validity of the response and sends an SSD Update Confirmation/Rejection Order to 30
the BS. 31
If timer T
3271
expires prior to receipt of a SSD Update Response message, the MSC may 33
declare failure of the SSD Update procedure. 34
TIA-2001.4-C
Section 2 32
2.3.7 Location Updating Request 1
This DTAP message is sent by the BS to the MSC to request an update to the MSs 2
location area (registration) when the MS moves to a new location from its previous 3
location. 4
When the MSs registration message is received by the BS, it constructs the Location 6
Updating Request message, places it in the Complete Layer 3 Information message (refer 7
to section 2.1.1), sends the message to the MSC, and starts timer T
3210
. 8
If the MSC had started timer T
ordreg,
the MSC shall stop this timer upon receipt of the 9
Location Updating Request message. 10
If timer T
3210
expires before the receipt of a Location Updating Accept message, a 12
Location Updating Reject message, or a Service Redirection message, the BS may re- 13
send the Location Updating Request message. The total number of retransmissions is 14
operator determined. 15
2.3.8 Location Updating Accept 16
This DTAP message is sent from the MSC to the BS to indicate that the Location 17
Updating Request has been successfully processed. 18
The MSC sends a Location Updating Accept message to the BS when a location 20
registration procedure has been successfully completed at the MSC. Upon receipt of this 21
3210
and may send the appropriate response (a Registration 22
Accepted order) to the MS over the control channel in use. 23
None. 25
2.3.9 Location Updating Reject 26
This DTAP message is sent from the MSC to the BS to indicate that the Location 27
Updating Request message was rejected. 28
The MSC may send a Location Updating Reject message to the BS when a registration 30
procedure yields a rejection. The Location Updating Reject message contains a 31
mandatory cause element containing the reason for rejection. Upon receipt of this 32
3210
and may send the appropriate response to the MS (a 33
Registration Reject Order) over the control channel in use. 34
TIA-2001.4-C
33 Section 2
None. 2
2.3.10 Parameter Update Request 3
This DTAP message is sent from the MSC to the BS to increment the call history count 4
in the MS. 5
When the MSC sends Parameter Update Request message to the BS it starts timer T
3220
. 7
When the BS receives this message, it shall send the Parameter Update Order to the MS. 8
If timer T
3220
expires without receiving a Parameter Update Confirm from the BS, the 10
MSC shall not increment the call history count and may re-send this message. 11
2.3.11 Parameter Update Confirm 12
This DTAP message is sent from the BS to the MSC in response to a Parameter Update 13
Request message. This message is sent when the BS receives a positive indication from 14
the MS that it incremented its call history count. 15
When the BS receives the Parameter Update Confirmation Order from the MS, it shall 17
send the Parameter Update Confirm message to the MSC. The MSC shall increment the 18
call history count and stop timer T
3220
. 19
If the BS fails to receive a response from the MS indicating that the call history count has 21
been successfully incremented in the MS, the BS shall do nothing in regards to parameter 22
update. 23
2.3.12 Privacy Mode Command 24
This optional BSMAP message may be sent by the MSC to the BS after receipt of the 25
Assignment Complete message while the call is in conversation state. Its typical use is to 26
specify the use of encryption/privacy parameters for the call. It may be sent to enable or 27
disable the use of encryption/privacy during conversation. 28
The pre-loading of the BS with parameters allows initiation of Signaling Message 29
Encryption (SME) during assignment to traffic channels when appropriate, and allows the 30
BS to immediately initiate privacy upon request by the mobile user or immediately 31
following assignment to a traffic channel. 32
The MSC may place the information in the Assignment Request message, if available. 33
Refer to section 3.1.7, Assignment Request for details on inclusion of the Encryption 34
Information element in this message. 35
TIA-2001.4-C
Section 2 34
If signaling encryption is not available at the time the Assignment Request message is 1
sent, the MSC shall wait until after the Assignment Complete message is received to send 2
the Privacy Mode Command message. 3
The Privacy Mode procedure may be invoked by the MSC during conversation state to 4
enable or disable the use of encryption/privacy. This may be initiated by the MSC, or sent 5
in response to a request for privacy by the mobile user. Use in the latter case is only 6
necessary where the privacy parameters are not pre-loaded by the MSC. 7
3280
upon sending this message. When the BS receives the 9
Privacy Mode Command message it responds to the MSC with the Privacy Mode 10
Complete message. 11
In the case where the MSC initiated the Privacy Mode procedure, if timer T
3280
expires 13
before the receipt of the Privacy Mode Complete message, the MSC shall initiate call 14
clearing. 15
2.3.13 Privacy Mode Complete 16
This optional BSMAP message is sent from the BS to the MSC autonomously, or in 17
response to the Privacy Mode Command message. It is used in the following cases: 18
During conversation, to acknowledge the Privacy Mode Command and indicate 19
current encryption parameter settings. 20
During conversation, to indicate a change in the privacy status, where the privacy 21
mode was changed to on or off at the request of the mobile user. 22
During conversation, to indicate that the mobile user has requested privacy but the 23
BS is unable to provide it. 24
When the MSC receives this message from the BS in response to the Privacy Mode 26
Command message it stops timer T
3280
. 27
When the MSC receives this message autonomously indicating that the MS has requested 28
Privacy, it may respond with the Privacy Mode Command message containing the 29
necessary Privacy parameters, or indicate that Privacy is not available. 30
None. 32
2.3.14 Status Request 33
The Status Request message is sent from the MSC to the BS to request information from 34
the MS such as call mode, terminal information, roaming information, security status, etc. 35
This is a DTAP message when sent on a traffic channel and a BSMAP message 36
otherwise. 37
TIA-2001.4-C
35 Section 2
The MSC sends the Status Request message to the BS and starts timer T
3272
. When the 2
BS receives this message it shall transparently transfer this information to the MS in the 3
Status Request Order or the Status Request Message. 4
If the MSC started timer T
3272
, and if the MSC does not receive a Status Response 6
message upon the expiration of timer T
3272
, the MSC may resend the Status Request 7
message. 8
2.3.15 Status Response 9
This message is sent from the BS to the MSC when the BS receives a Status Message or a 10
Status Response Message from the MS. This is a DTAP message when used to perform 11
the status inquiry on the traffic channel and a BSMAP message otherwise. 12
When the BS receives the Status Message or a Status Response Message from the MS, it 14
shall send the Status Response message to the MSC. The MSC shall stop the optional 15
timer T
3272
if running. 16
None. 18
2.3.16 User Zone Update Request 19
This DTAP message is sent from the BS to MSC when a request is received from a MS to 20
change its User Zone. 21
When the BS receives a request from the MS to change its User Zone, the BS constructs 23
the User Zone Update Request message, and sends the message to the MSC. 24
None. 26
2.3.17 User Zone Update 27
This DTAP message is sent from the MSC to the BS to change the User Zone of the MS. 28
The MSC sends a User Zone Update message to the BS to change the User Zone of the 30
MS. Upon receipt of the User Zone Update message, the BS sends the appropriate air 31
interface message to inform the MS. 32
TIA-2001.4-C
Section 2 36
None. 2
2.3.18 User Zone Reject 3
This DTAP/BSMAP message is sent from the MSC to the BS to indicate that a request 4
for a change of User Zone was rejected. 5
Upon receiving a Location Updating Request, CM Service Request or Paging Response 7
message indicating the MSs User Zone, or a User Zone Update Request message 8
proposing a new User Zone for the MS, the MSC may send a User Zone Reject message 9
to the BS to reject the User Zone. The MSC may propose an alternative User Zone in this 10
message. Upon receipt of the User Zone Reject message, the BS sends the appropriate air 11
interface message to inform the MS. 12
None. 14
2.3.19 Registration Request 15
The Registration Request message is a BSMAP message sent from the MSC to request 16
the BS to initiate an ordered registration. 17
The MSC sends Registration Request message to the BS and starts timer T
ordreg
. The BS 19
shall respond by sending a Registration Request Order to the MS to initiate ordered 20
registration. 21
If timer T
ordreg
expires before the MSC receives a Location Update Request message 23
from the BS, the MSC may repeat the Registration Request message and restart timer 24
T
ordreg
. 25
This BSMAP message may be sent by the MSC to the BS, after it autonomously registers 27
an MS, to trigger the BS to send the Mobile Station Registered Message to the MS. 28
When the BS receives the Mobile Station Registered Notification message from the 30
MSC, it sends the Mobile Station Registered Message to the MS. 31
TIA-2001.4-C
37 Section 2
None. 2
2.4 Handoff Message Procedures 3
4
2.4.1 Handoff Required 5
This BSMAP message allows the source BS to initiate a handoff. This message provides 6
the MSC with a list of target candidate cells or optional measurement information for the 7
MSC to use to determine a target with an available radio channel. 8
Upon receiving a Handoff Required message, the MSC may construct a candidate target 9
list, modify the existing one, or use the existing list as received. Alternatively, the MSC 10
may unilaterally determine a candidate target cell list. Once the MSC has established a 11
candidate target cell list, the handoff processing continues with resource establishment. 12
Refer to [13] for more details. The provisions of this paragraph do not apply when the 13
source BS is operating in DS-41 mode. 14
When a source BS has sufficient information to initiate a handoff, it shall determine if 16
one or more target cells are outside the current BS domain. If one or more candidate 17
targets are outside its domain, then the source BS shall generate a Handoff Required 18
message requesting the MSC to find a target with available resources. 19
Absence of the IS-95 Channel Identity or IS-2000 Channel Identity element indicates that 20
the type of handoff being requested is a CDMA to AMPS hard handoff. This condition 21
does not apply when the target BS is operating in DS-41 mode where the type of handoff 22
is contained within the transparent container element passed to the target BS. 23
If timer T
7
has not been started for this handoff attempt prior to this time, it shall now be 24
started. This implies that the Handoff Required message shall be repeated by the BS with 25
a periodicity no smaller than T
7
between messages. 26
If a Handoff Command message is not received prior to expiration of timer T
7
, then the 28
source BS may resend the Handoff Required message. 29
The MSC shall always respond to the Handoff Required message. The BS may resend the 30
Handoff Required message only after timer T
7
expires or a Handoff Required Reject 31
message is received. 32
2.4.2 Handoff Request 33
This BSMAP message allows the MSC to make specific requests of potential targets to 34
provide radio resources for a handoff of an existing mobile connection. 35
TIA-2001.4-C
Section 2 38
This message is sent by the MSC to candidate target cell(s). Using the candidate target 2
cell list generated per section 2.4.1 (Handoff Required), the MSC determines a target cell 3
that has available resources which match the MSs permitted channel type. More than one 4
candidate target cell under the domain of the same BS may be specified for simultaneous 5
inclusion in the handoff. To accomplish a handoff for any supported signaling type, a 6
Handoff Request message is constructed and sent to the necessary BS(s). Information 7
may be included in the request that instructs the BS on specific information on the type of 8
radio channel required and other miscellaneous parameters. This information can be 9
extracted from the Handoff Required message elements. Upon transmission of this 10
message, the MSC starts timer T
11
. 11
Refer to section 3.4.2, Handoff Request, for the use of: 12
IS-95 Channel Identity elements to indicate hard handoff for TIA/EIA-95-B systems 13
and 14
IS-2000 Channel Identity elements to indicate handoff for TIA/EIA/IS-2000 systems. 15
Upon receipt of this message, the candidate target BS shall choose suitable idle radio 16
resources. If these resources are available, the BS responds to the MSC with a Handoff 17
Request Acknowledge message containing the appropriate channel and other pertinent 18
information to allow the MS to be instructed to tune to the new channel. 19
Receipt of a Handoff Failure message at the MSC or expiration of timer T
11
signals the 21
failure of the target BS to allocate resources for a handoff request. On receipt of a 22
Handoff Failure message or upon expiration of timer T
11
, the MSC shall terminate the 23
handoff procedure and release all references and resources associated with the target. The 24
MSC may continue with additional target cell candidates or send a Handoff Required 25
Reject message to the source BS with the appropriate cause value. Refer to section 2.4.7 26
Handoff Required Reject, and section 2.4.8, Handoff Failure, for more information. 27
2.4.3 Handoff Request Acknowledge 28
This BSMAP message allows the target BS to respond to the MSC concerning the 29
Handoff Request message. When a Handoff Request message is received, the target BS 30
selects appropriate cell(s) amongst the target cell(s) identified in the Handoff Request 31
message to be set up for the requested handoff. This message is generated when the target 32
BS determines that appropriate resources are allocated to service the needs of the 33
incoming handoff. The first cell in the cell identifier list element of the message is treated 34
as the designated cell by the MSC. 35
This acknowledgment to the Handoff Request message indicates that at least one cell 37
under this BSs domain can qualify as the target for the handoff. The target BS indicates 38
that the appropriate radio and land resources have been allocated and set up for the 39
requested handoff. The MSC uses information provided in this message to create a 40
Handoff Command message to be sent to the source BS to execute the handoff. The MSC 41
stops timer T
11
. 42
TIA-2001.4-C
39 Section 2
Concurrent with the sending of the Handoff Request Acknowledge message, the target 1
BS shall start timer T
9
. 2
Refer to section 2.4.8, Handoff Failure, for actions to be taken upon the expiration of 4
timer T
9
. 5
2.4.4 Handoff Command 6
This BSMAP message allows the MSC to signal to the source BS that a target channel(s) 7
has/have been allocated for handoff. 8
Essentially, the Handoff Command message is used to convey information about the 10
target BS to the source BS (and on to the MS) regarding layer 1 access information at the 11
target. Upon receipt of the Handoff Command message the source BS stops timer T
7
. 12
If the source BS does not accept the Handoff Command message, a Handoff Failure 13
message with a cause value of Alternate signaling type reject shall be sent to the MSC 14
so that the reserved target resources are released. 15
The following three paragraphs do not apply when the source BS is operating in DS-41 16
mode. 17
The source BS transmits the handoff instructions to the MS to execute a handoff and 18
starts timer T
8
if an acknowledgment is requested. 19
The source BS typically receives confirmation that the MS has received the command 20
and is acting accordingly. Timer T
8
, if running, is stopped when this confirmation is 21
received. The source BS may optionally send the handoff direction message
2
to the MS 22
using quick repeats and may not request an acknowledgement from the MS. In this case, 23
the source BS shall not start timer T
8
. 24
If the source BS indicates in a handoff direction message that the MS is allowed to return 25
to the source BS if it cannot acquire the target BS, the source BS starts timer T
waitho
. 26
Information contained in the elements of this message are identical to the information 27
contained in the corresponding elements of the Handoff Request Acknowledge (refer to 28
section 2.4.3). 29
If the MS fails to acknowledge the handoff instruction (i.e., timer T
8
expires) and the MS 31
remains on the old channel, then a Handoff Failure message is sent to the MSC with the 32
cause field set to Reversion to old channel. The procedure at the target BS is terminated 33

2
This may be an Analog Handoff Direction message, Handoff Direction message, a
General Handoff Direction message, an Extended Handoff Direction message, or a
Universal Direction message as appropriate.
TIA-2001.4-C
Section 2 40
by the MSC using a call clearing sequence. Refer to [13] for additional call clearing 1
requirements. 2
The three paragraphs immediately following do not apply when the source BS is 3
operating in DS-41 mode. 4
If timer T
8
expires and the source BS cannot detect the presence of the radio link to the 5
MS, then the source BS sends a Clear Request message (refer to section 3.1.12, Clear 6
Request) to the MSC regarding the source channel with the cause field set to Radio 7
interface failure. The channel and terrestrial resource are released after a Clear 8
Command message is received from the MSC. 9
If timer T
waitho
expires, the source BS should consider this a normal event and send a 10
Handoff Commenced message to the MSC. Refer to section 2.4.5, Handoff Commenced. 11
If the source BS has allowed an MS to return if it cannot acquire the target BS and the 12
MS returns before timer T
waitho
expires, the source BS shall stop timer T
waitho
and 13
resume servicing the MS and send a Handoff Failure to the MSC with cause value 14
Reversion to old channel. 15
The following applies when the source BS is operating in DS-41 mode. 16
If the source BS determines that the MS is no longer present in the area of its control and 17
cannot return to that area, the source BS shall send a Clear Request message to the MSC 18
with the cause field set to Radio interface failure. The channel and terrestrial resources 19
are released after a Clear Command message is received from the MSC. 20
If the source BS detects that an MS returns to its control while in a call, the source BS 21
shall send a Handoff Failure message to the MSC with cause value Reversion to old 22
channel. 23
2.4.5 Handoff Commenced 24
This BSMAP message is used for TIA/EIA-553, TIA/EIA-95, and TIA/EIA/IS-2000 hard 25
handoffs. It is sent by the source BS to the MSC to indicate that the Handoff Command 26
message has been sent to the MS, and that the MS is not expected to return to the source 27
BS. 28
The MSC may send a Clear Command message to the source BS upon receipt of the 29
Handoff Commenced Message. 30
If the source BS does not expect the MS to return, it starts timer T
306
once the Handoff 32
Commenced message is sent to the MSC. If the handoff direction message is sent using 33
quick repeats, the source BS might not request an acknowledgment from the MS. In this 34
case, the source BS sends the Handoff Commenced message after all the quick repeats 35
have been transmitted to the MS unless the MS has been allowed to return if it cannot 36
acquire the target BS. In the case that the MS has been allowed to return, timer T
waitho
is 37
started and the source BS is required to wait until timer T
waitho
expires before sending the 38
Handoff Commenced message to the MSC. 39
TIA-2001.4-C
41 Section 2
If timer T
306
expires, then the BS follows the call clearing procedures defined in section 2
2.1.13 (i.e., send a Clear Request message to the MSC). 3
2.4.6 Handoff Complete 4
This BSMAP message allows the target BS to signal to the MSC that a MS has 5
successfully accessed the target cell and performed all connection procedures. 6
In the case of handoff of a circuit switched or concurrent services call, the Handoff 8
Complete message is sent from the target BS to the MSC when the target BS has acquired 9
the MS. 10
In the case of handoff of a packet data only session, the Handoff Complete message is 11
sent from the target BS to the MSC when the target BS has acquired the MS and has 12
performed the connection procedures to the PCF, i.e. when the BS has received the A9- 13
AL Connected Ack message. 14
When the MSC receives the Handoff Complete message from the target BS, the MSC 15
shall send a Clear Command message (refer to section 2.1.14) to the source BS. If the 16
Handoff Complete is the result of a hard handoff of a circuit switched or concurrent 17
services call, then any terrestrial circuit to the source BS shall also be cleared via an MSC 18
initiated clearing sequence. 19
When the target BS is operating in DS-41 mode, then when the new SRNC-ID + S-RNTI 20
are successfully exchanged with the MS by the radio protocols, the target BS shall send 21
the Handoff Complete message to MSC. 22
None. 24
2.4.7 Handoff Required Reject 25
This BSMAP message is sent from the MSC to the source BS to deny the request 26
contained in a Handoff Required message. 27
If the source BS requested a response by including the Response Request element in the 29
Handoff Required message, and the handoff cannot be accomplished, a Handoff Required 30
Reject message may be sent to the source BS indicating that the handoff cannot be 31
accomplished at this time. 32
If a Handoff Required Reject message is received, then the source BS shall stop timer T
7
33
and a new handoff procedure may be initiated if the condition of the call connection 34
warrants immediate action (e.g., emergency handoff). Such a procedure is implemented 35
at the discretion of the manufacturer and system operator. 36
TIA-2001.4-C
Section 2 42
None. 2
2.4.8 Handoff Failure 3
This BSMAP message is sent from either the target BS or the source BS to the MSC to 4
indicate that there has been a failure in either the resource allocation process or the 5
execution of an inter-BS handoff and that the handoff has been aborted. 6
After receiving a Handoff Failure message the MSC stops timer T
11
if it is running and 8
sends a Clear Command message to the target BS, which shall then deallocate radio and 9
terrestrial resources. 10
In the event that timer T
9
expires and no MS is detected by the target BS, a Handoff 11
Failure message shall be sent to the MSC with the appropriate cause field set. 12
If the source BS has indicated in a handoff direction message
3
that the MS is allowed to 13
return if it cannot acquire the target BS, the possibility exists that the MS may return to 14
the source BS. If this happens prior to the expiration of timer T
waitho
, the source BS sends 15
a Handoff Failure message to the MSC indicating the return of the MS. 16
None. 18
2.4.9 Handoff Performed 19
This BSMAP message is sent from the BS to the MSC to inform the MSC of handoff 20
operations. 21
An intra-BS handoff is a handoff performed under the domain of one BS. As such, the 23
MSC is not involved in the execution of the handoff. Once an intra-BS handoff is 24
successfully completed, the BS may inform the MSC via a Handoff Performed message. 25
When the sector identified as the designated cell is removed from the call, the BS 26
currently serving as the source BS for the call chooses a new designated cell from the 27
set of sectors serving the call and shall provide the appropriate cell identifier to the MSC 28
using this message. 29
None. 31

3
This may be an Analog Handoff Direction message, Handoff Direction message, a
General Handoff Direction message, an Extended Handoff Direction message, or a
Universal Direction message as appropriate.
TIA-2001.4-C
43 Section 2
2.5 Facility Management Message Procedures 1
2
2.5.1 Block 3
This BSMAP message is sent from the BS to the MSC to indicate that one or more 4
terrestrial circuits shall be blocked at the MSC and therefore cannot be used for traffic. 5
The BS sends a Block message to the MSC and starts timer T
1
. Timer T
1
shall be set to a 7
value to allow sufficient time for the MSC to block all circuits indicated in this message. 8
The message identifies at least one circuit (Circuit Identity Code) to be blocked and the 9
reason (Cause) of the blocking. The only way a terrestrial circuit may become unblocked 10
after it has been blocked is through a reset circuit procedure (from the BS), a global reset 11
from either the MSC or BS, or an unblock procedure (from the BS). More than one 12
circuit may be blocked using a single Block message. The MSC stops timer T
12
if it is 13
running and sends a Block Acknowledge message in response to the Block message after 14
taking appropriate action. A call that is already in progress on the specified circuit is not 15
affected by the Block message; the block becomes effective after the completion of the 16
call in progress. The MSC does not delay sending the Block Acknowledge message if a 17
call is in progress. If a circuit is already marked as blocked in the MSC, it remains 18
blocked and the MSC sends the Block Acknowledge message. 19
If the BS does not receive a Block Acknowledge message before the expiration of timer 21
T
1
, then the BS shall send the Block message a second and final time and shall mark the 22
indicated circuit(s) as blocked. 23
If an Assignment Request message is received for a circuit which is marked at the BS as 24
blocked then the BS shall send an Assignment Failure message with a cause value of 25
Terrestrial resource is not available followed by a Block message with a cause value of 26
No radio resource available. 27
2.5.2 Block Acknowledge 28
This BSMAP message is sent from the MSC to the BS to acknowledge receipt of the 29
Block message and to indicate that appropriate action has been taken. 30
After the MSC blocks all of the circuits specified in the Block message, the MSC sends a 32
Block Acknowledge message to the BS. The BS stops timer T
1
upon receipt of the Block 33
Acknowledge message. The Block Acknowledge message indicates to the BS that the 34
necessary action has been taken. The circuits involved are assumed to be blocked by the 35
MSC until a Reset message or an Unblock message relevant to the circuits is received 36
from the BS. The Block Acknowledge message returns the Circuit Identity Code of the 37
corresponding Block message. 38
TIA-2001.4-C
Section 2 44
If multiple circuits were indicated in the Block message, the response applies to all of 1
those circuits. 2
None. 4
2.5.3 Unblock 5
This BSMAP message is used by the BS to notify the MSC that the specified circuits are 6
available for use. 7
If the BS chooses to unblock blocked circuits, an Unblock message is sent to the MSC. 9
1
when it sends this message. Timer T
1
shall be set to a large 10
enough value to allow sufficient time for the MSC to unblock all circuits indicated in this 11
message. 12
If the BS does not receive the Unblock Acknowledge message before the expiration of 14
timer T
1
, then the BS shall send the Unblock message a second and final time. If timer T
1
15
expires on the second attempt, the BS shall mark the indicated circuit(s) as unblocked. 16
2.5.4 Unblock Acknowledge 17
This BSMAP message is sent from the MSC to the BS in response to a request to unblock 18
circuits. The MSC marks such circuits as available at the BS before it sends the Unblock 19
Acknowledge message to the BS. 20
Upon receipt of the Unblock message from the BS, the MSC marks the circuits as 22
available at the BS and sends an Unblock Acknowledge message to the BS. Upon receipt 23
of the Unblock Acknowledge message, the BS marks all circuits included in the Unblock 24
message as unblocked. The Unblock Acknowledge message returns the Circuit Identity 25
Code of the corresponding Unblock message. If a circuit is already marked as unblocked 26
in the MSC, it remains unblocked and the MSC sends the Unblock Acknowledge 27
message. 28
If multiple circuits were indicated in the Unblock message, the response applies to all of 29
those circuits. 30
None. 32
2.5.5 Reset Circuit 33
This BSMAP message is sent by either the BS or the MSC to request that one or more 34
circuits be idled (reset). 35
TIA-2001.4-C
45 Section 2
2.5.5.1 Reset Circuit (at the BS) 1
If the BS detects that one or more circuits have to be idled due to abnormal SCCP- 2
connection release, it sends a Reset Circuit message to the MSC indicating the Circuit 3
Identity Code(s) which the MSC is to idle and the reason (Cause) of the circuit reset. 4
12
12
enough value to allow sufficient time for the MSC to reset all circuits indicated in this 7
message. When the MSC receives the Reset Circuit message, it clears all calls that are 8
utilizing the circuits to be reset, marks the indicated circuits as idle and available (i.e., 9
unblocked), and returns a Reset Circuit Acknowledge message to the BS. 10
If the BS does not receive or recognize the Reset Circuit Acknowledge message before 12
the expiration of timer T
12
, the Reset Circuit message is repeated. The Reset Circuit 13
message shall be sent no more than three times. 14
If the Reset Circuit Acknowledge message is never received or recognized by the BS, 15
then the situation (i.e., possibly incompatible device states between the BS and MSC) 16
shall be resolved internally in the BS or by OAM&P procedures. 17
2.5.5.2 Reset Circuit (at the MSC) 18
If the MSC detects that one or more circuits have to be idled due to abnormal SCCP 19
connection release or OAM&P intervention, it sends a Reset Circuit message to the BS 20
indicating the circuits which the BS is to idle and the cause of the circuit reset. 21
12
12
enough value to allow sufficient time for the BS to reset all circuits indicated in this 24
message. When the BS receives a Reset Circuit message, it shall respond with a Reset 25
Circuit Acknowledge message in the case that all of the circuit(s) can be idled and none 26
of the circuits are blocked. If all of the circuits are blocked at the BS at reception of the 27
Reset Circuit message, one or more Block messages is returned to the MSC instead of the 28
Reset Circuit Acknowledge message. If some of the circuits are blocked at the BS at 29
reception of the Reset Circuit message, one or more Block messages is returned to the 30
MSC indicating those blocked circuits. The MSC responds with a Block Acknowledge 31
message to any Block message it receives if it successfully blocks all of the circuits 32
specified in the Block message. 33
If the MSC does not receive the Reset Circuit Acknowledge message or a Block message 35
before the expiration of timer T
12
, the Reset Circuit message is sent a second and final 36
time. 37
If the Reset Circuit Acknowledge message is never received or recognized by the MSC, 38
then the situation (i.e., possibly incompatible device states between the BS and MSC) 39
shall be resolved internally in the MSC or by OAM&P procedures. 40
TIA-2001.4-C
Section 2 46
2.5.6 Reset Circuit Acknowledge 1
This BSMAP message is sent by either the MSC or the BS to acknowledge the request 2
that one or more circuits be idled (reset). 3
2.5.6.1 Reset Circuit Acknowledge (from BS) 4
The Reset Circuit Acknowledge message is sent from the BS to the MSC to acknowledge 5
that the BS has reset (idled and unblocked) the circuits indicated in the corresponding 6
Reset Circuit message. 7
Upon receipt of the Reset Circuit Acknowledge or Block message from the BS, the MSC 9
stops timer T
12
. 10
None. 12
2.5.6.2 Reset Circuit Acknowledge (from MSC) 13
The Reset Circuit Acknowledge message is sent from the MSC to the BS to acknowledge 14
that the MSC has reset (idled and unblocked) the circuits indicated in the corresponding 15
Reset Circuit message. 16
When the MSC receives a Reset Circuit message, it idles the circuits and sends a Reset 18
Circuit Acknowledge message to the BS. 19
Upon receipt of the Reset Circuit Acknowledge message, the BS stops timer T
12
. 20
None. 22
2.5.7 Reset 23
This BSMAP message can be sent by either the BS or the MSC. In the event of a failure 24
or initialization at the BS or MSC that has resulted in the loss of transaction reference 25
information, a Reset message is sent on the A1 interface to the counterpart of the 26
equipment that is resetting to indicate the reason for the reset. 27
TIA-2001.4-C
47 Section 2
If the BS sends the Reset message to the MSC, the BS starts timer T
4
. Upon receipt of the 2
Reset message from the BS, the MSC releases affected calls, erases all affected 3
references, puts all circuits associated with the BS into the idle state and shall mark all 4
circuits as unblocked. During reinitialization, the BS may use the blocking procedure to 5
mark circuits as blocked. After a guard period of T
2
seconds a Reset Acknowledge 6
message is returned to the BS indicating that all references have been cleared. 7
If timer T
16
is running at the MSC when the Reset message is received from the BS, the 8
16
, start timer T
2
, complete initialization, and then return a Reset 9
Acknowledge message to the BS after timer T
2
expires. 10
If the MSC sends the Reset message to the one or more affected BSs, the MSC starts an 11
associated timer T
16
for each message.

Upon receipt of a Reset message from the MSC, 12
and the BS shall release all affected calls and erase all affected references. The BS may 13
use the blocking procedure to mark circuits as blocked as described in section 2.5.1 and 14
shall idle all others. After a guard period of T
13
seconds a Reset Acknowledge message is 15
returned to the MSC, indicating that all MSs that were involved in a call are no longer 16
transmitting and that all references at the BS have been cleared. 17
If timer T
4
is running at the BS when the Reset message is received from the MSC, the 18
BS shall stop timer T
4
, start timer T
13
, complete initialization, and then return a Reset 19
Acknowledge to the MSC after timer T
13
expires. 20
If the BS sends a Reset message to the MSC and does not receive a Reset 22
Acknowledgement message before timer T
4
expires then it shall repeat the entire reset 23
procedure. 24
If the MSC sends a Reset message to the BS and does not receive a Reset 25
Acknowledgement message before timer T
16
expires then it shall repeat the reset 26
procedure with respect to that BS. 27
If a Reset message is received that contains a protocol version less than the protocol 28
version of the receiver but unknown to the receiver, then the receiver may raise an 29
OAM&P flag and choose not to respond to the sender. 30
2.5.8 Reset Acknowledge 31
This BSMAP message is sent in response to a Reset message. 32
When the MSC has received a Reset message from a BS, the MSC, after a guard period 34
of timer T
2
seconds, sends a Reset Acknowledge message to the BS to indicate that the 35
Reset message is received and that all references have been cleared. When the BS 36
receives the Reset Acknowledge message, it stops timer T
4
and begins normal operation. 37
TIA-2001.4-C
Section 2 48
When the BS has received a Reset message from the MSC, the BS sends a Reset 1
Acknowledge message after a guard period of timer T
13
seconds to the MSC to indicate 2
that the Reset message was received and that all references have been cleared. When the 3
MSC receives the Reset Acknowledge message, it stops the associated timer T
16
and 4
begins normal operation. 5
None. 7
2.5.9 Transcoder Control Request 8
The BSMAP Transcoder Control Request message is sent from the MSC to the BS to 9
request a change in the current state of the inband signaling mechanism. 10
309
When the BS receives this message with an attempt TFO directive, the inband 13
signaling mechanism at the SDU is enabled (or reset if already enabled and not in the 14
Tandem Free Operation (TFO) state) and the BS responds with a Transcoder Control 15
Acknowledge. Refer to [24] for TFO. 16
When the BS receives this message with a tandem mode directive, it disables the 17
inband signaling mechanism and reverts to tandem vocoding mode. The Transcoder 18
Control Acknowledge message is returned upon successful transition to tandem vocoding 19
mode. 20
If the Transcoder Control Acknowledge message is not received by the MSC before 22
timer T
309
expires, then the MSC invokes the appropriate follow-up processing. The 23
MSC may peg the error counters associated with the TFO feature and the call. 24
2.5.10 Transcoder Control Acknowledge 25
This BSMAP message is sent from the BS to the MSC to indicate the success or failure 26
of enabling or disabling tandem free operation. 27
The BS sends this message to the MSC with an indication (success or failure) of the 29
outcome of the enabling or disabling of the TFO function. When the MSC receives this 30
message, it stops timer T
309
. 31
None. 33
TIA-2001.4-C
49 Section 2
2.6 Application Data Delivery Service (ADDS) Message Procedures 1
2
2.6.1 ADDS Page 3
This BSMAP message is sent from the MSC to the BS to transport an application data 4
message to be delivered to the MS or request application data from the MS on the paging 5
channel(s). 6
When the MSC determines that it needs to deliver an SMS message to a specific idle MS, 8
and a Layer 2 Ack notification is required from the MS, the MSC sends the ADDS Page 9
message containing a Tag information element to the BS, starts timer T
3113
, and waits for 10
the ADDS Page Ack message. 11
When the MSC determines that it needs to deliver an SMS message to a specific idle MS, 12
and the MSC does not require a Layer 2 Ack notification, the MSC sends the ADDS Page 13
message, without a Tag information element, to the BS. 14
The Tag information element, when present, indicates to the BS that a Layer 2 Ack is 15
required from the MS. It can be used by the MSC to uniquely identify the ADDS Page 16
message. If the Tag information element is present in the ADDS Page message, then the 17
BS shall save it and return the same value in the Tag information element of the ADDS 18
Page Ack message. 19
When the MSC determines that it needs to deliver an SMS Broadcast message, and the 20
MSC desires a response from the BS, the MSC starts timer T
3113
, sends the ADDS Page 21
message containing a Tag element to the BS, and waits for the ADDS Page Ack message. 22
The Tag information element, when present indicates to the BS that an ADDS Page Ack 23
response message is requested. However, the BS is not required to solicit Layer 2 Acks 24
from the MS. If the Tag element is present, the BS shall save it and return the saved value 25
in the Tag information element of the ADDS Page Ack message. 26
If the MSC needs to send position location data to an idle MS, the MSC sends an ADDS 27
page message to the BS with the burst type of ADDS User Part information element set 28
to PLD. The MSC includes a Tag information element in the ADDS Page message to 29
request the BS to wait for a Layer 2 Ack from the MS before the BS acknowledges the 30
message. The BS saves the Tag value and returns it in the Tag information element of the 31
ADDS Page Ack message. The MSC starts timer T
3113
and waits for an ADDS Page Ack 32
Message. 33
When the MSC determines that it needs to deliver a short data burst to an idle MS, the 34
MSC sends a ADDS Page message to the BS with the burst type of ADDS User Part 35
information element set to SDB. The MSC may include a Tag information element in 36
the ADDS Page message to request the BS to wait for a Layer 2 Ack from the MS before 37
the BS acknowledges the message.

If the Tag element is present, the BS saves the Tag 38
value and returns it in the Tag information element of the ADDS Page Ack message. The 39
MSC starts timer T
3113
and waits for an ADDS Page Ack Message. 40
TIA-2001.4-C
Section 2 50
If the Tag information element was included in the ADDS Page message, and the ADDS 2
Page Ack message has not been received at the MSC before timer T
3113
expires, the 3
MSC may resend the ADDS Page message and restart timer T
3113
. 4
2.6.2 ADDS Page Ack 5
This BSMAP message is sent from the BS to the MSC when the BS receives a Layer 2 6
Ack from an MS for an ADDS Page message directed to a specific MS that contains a 7
Tag element, or when the BS successfully processes an ADDS Page message containing 8
both Mobile Identity set to Broadcast Address and a Tag element, or when the BS is 9
indicating an error situation resulting from an ADDS Page message that contains a Tag 10
element. 11
For messages to a specific MS, if the MSC included the Tag element in the ADDS Page 13
message, the BS sends this message to the MSC when it receives a Layer 2 Ack from the 14
MS. The MSC shall stop timer T
3113
when it receives the ADDS Page Ack. 15
For SMS Broadcast messages, if the MSC included the Tag element in the ADDS Page 16
message, the BS sends this message to the MSC to indicate that it has processed the 17
ADDS Page message. The BS is not required to solicit Layer 2 Acks from the MSs. The 18
3113
when it receives the ADDS Page Ack. 19
None. 21
2.6.3 ADDS Transfer 22
This BSMAP message is sent from the BS to the MSC to deliver an application data 23
message. The application data can be of following types: Short Message Service and 24
Position Location Data. 25
The message can also be sent from the BS to the MSC to request authentication of an MS 26
in case of short data burst, an origination of CCPD mode or Dormant mode handoff. 27
When the BS receives an application data message for SMS or PLD from the MS on the 29
access channel, it sends it to the MSC in an ADDS Transfer message. The BS includes 30
the SMS or PLD message in the Application Data in the ADDS User Part element and 31
sets the Data Burst Type of the ADDS User Part element to SMS or PLD. 32
If the BS sends the ADDS Transfer message to the MSC for authentication purposes in 33
the case of short data burst, an MS origination with CCPD mode or Dormant mode 34
handoff, the BS sets the Data Burst Type of the ADDS User Part element to SDB (for 35
short data bursts or CCPD Mode) or Asynchronous Data (for Asynchronous Data or 36
Dormant Handoff) and includes a Tag information element. The BS starts timer T
60
. 37
TIA-2001.4-C
51 Section 2
If timer T
60
expires before an ADDS Transfer Ack message is received from the MSC in 2
the case of short data burst, the BS shall discard the data. 3
If timer T
60
expires before an ADDS Transfer Ack message is received from the MSC in 4
the case of CCPD Mode, the BS may resend the ADDS Transfer message to retry the 5
authentication a configurable number of times. If the BS chooses not to resend the 6
message, or does not receive an ADDS Transfer Ack message upon resending the 7
message, the BS shall not continue processing the call. 8
If timer T
60
expires before an ADDS Transfer Ack message is received from MSC in the 9
case of Dormant mode handoff, the BS may resend the ADDS Transfer message to retry 10
the authentication a configurable number of times. If the BS chooses not to resend the 11
message, or does not receive an ADDS Transfer Ack message upon resending the 12
message, the authentication of the MS is considered failed. 13
2.6.4 ADDS Transfer Ack 14
This BSMAP message is sent from the MSC to the BS in response to an ADDS Transfer 15
Message to indicate the result of the authentication for an MS originating a Short Data 16
Burst or requesting CCPD Mode from the network, or requesting a dormant mode 17
handoff. 18
If the MS is successfully authenticated for a mobile originated Short Data Burst, the MSC 20
sends a ADDS Transfer Ack message with the same Tag information element as in 21
ADDS Transfer message to the BS. The BS sends the buffered SDB data to the PCF. If 22
the MSC includes a cause value indicating authentication failure, the buffered data shall 23
be discarded. The BS stops timer T
60
upon receipt of the authentication results in the 24
ADDS Transfer Ack message. 25
If an MS requesting common channel packet data service is successfully authenticated, 26
the MSC sends an ADDS Transfer Ack message with the same Tag information element 27
as in ADDS Transfer message to the BS. The BS proceeds with the CCPD call setup. If 28
the MSC includes a cause value indicating authentication failure for an MS requesting 29
CCPD Mode, the BS shall not respond to the MS with a Short Data Burst 30
Acknowledgement, and the CCPD call setup fails. 31
If an MS requesting a dormant mode packet handoff is successfully authenticated the 32
MSC sends the ADDS Transfer Ack message with the same Tag information element as 33
in ADDS Transfer message to the BS. The BS stops timer T
60
upon receipt of the 34
message, and the dormant mode handoff is allowed to proceed. 35
Alternatively, the MSC may optionally allow the dormant mode handoff to begin prior to 36
completion of authentication procedures for the MS. In this case, the MSC sends an 37
ADDS Transfer Ack message with the same Tag information element as in ADDS 38
Transfer message and a cause value set to concurrent authentication to the BS. The MSC 39
then sends a second ADDS Transfer message with the same Tag information element as 40
in the ADDS Transfer message to the BS when the MSC has received the authentication 41
results. The BS stops timer T
60
upon receipt of the second ADDS Transfer Ack message. 42
If the MSC includes a cause value indicating authentication failure in the ADDS Transfer 43
Ack message, the BS shall stop the dormant handoff. 44
TIA-2001.4-C
Section 2 52
Note: The second ADDS Transfer Ack message is not sent if an SCCP connection was 1
requested by the BS when a traffic channel is required. In this case, the BS stops timer 2
T
60
upon sending the CM Service Request message. 3
None. 5
2.6.5 ADDS Deliver 6
This DTAP message is sent from the MSC to the BS or from the BS to the MSC to 7
transfer an application data message exchanged over the traffic channel. The application 8
data can be of following types: Short Message Service (SMS), Position Location Data 9
(PLD), and Over-The-Air Service Provisioning (OTASP) data. 10
When the MSC or BS needs to deliver an application data message while a traffic 12
channel exists, the sender includes that application data message (SMS, PLD or OTASP) 13
in an ADDS Deliver message and sends it across the A1 interface. 14
In the MSC to BS direction, the Tag information element, when present, indicates to the 15
BS that a Layer 2 Ack is required from the MS. It can be used by the MSC to uniquely 16
identify the ADDS Deliver message. If the Tag information element is present in the 17
ADDS Deliver message, then the BS shall save it and return the same value in the Tag 18
information element of the ADDS Deliver Ack message. 19
If a Layer 2 Ack is not received from the MS, the BS shall initiate call clearing. 21
2.6.6 ADDS Deliver Ack 22
This DTAP message is sent from the BS to the MSC when the BS receives a Layer 2 Ack 23
from the MS for an ADDS Deliver message that contains a Tag information element. In 24
the case of OTASP, PLD and SMS, this message is sent from the BS to the MSC to 25
report that an acknowledgment or a rejection from the MS has been received for 26
application data delivery. 27
The BS sends this message when it receives a Layer 2 Ack from the MS and the 29
corresponding ADDS Deliver message received from the MSC contained a Tag 30
information element. 31
None. 33
34
TIA-2001.4-C
53 Section 2
2.7 Error Handling Message Procedures 1
2
2.7.1 Rejection 3
The Rejection message is used by the BS to indicate to the MSC that the MS has 4
indicated rejection of a command/message. This is coded as a BSMAP message when 5
triggered by a Mobile Station Reject Order on the access channel and a DTAP message 6
otherwise. 7
When the BS receives a rejection indication (e.g., a Mobile Station Reject Order) it shall 9
send the Rejection message to the MSC only in the cases listed below. No response is 10
expected from the MSC. 11
The Rejection message shall only be used in conjunction with a Mobile Station Reject 12
Order received as a response to an ADDS Page or ADDS Deliver operation (i.e., Data 13
Burst). 14
None. 16
2.8 Network Directed System Selection (NDSS) Message 17
Procedures 18
19
2.8.1 Service Redirection 20
This DTAP message is sent by the MSC to the BS to cause the BS to redirect the MS to 21
another system. 22
The MSC sends a Service Redirection message to the BS when an MS is to be redirected 24
to another system. Upon receipt of this message, the BS stops timer T
3210
and/or timer 25
T
303
if they are running and sends the appropriate redirection message to the MS (refer to 26
[5]). 27
None. 29
30
TIA-2001.4-C
Section 2 54
1
3
4
5
6
7
8
9
TIA-2001.4-C
55 Section 3
3.0 Message Formats 1
2
3.1 Call Processing Messages 3
4
3.1.1 Complete Layer 3 Information 5
This BSMAP message is sent from the BS to the MSC upon receipt of the first message 6
from the MS. This message contains a CM Service Request message (refer to section 7
3.1.2), a Paging Response message (refer to section 3.1.5), or a Location Updating 8
Request message (refer to section 3.3.7). 9
Information Element Section
Reference
Element
Direction
Type
Message Type 4.2.4 BS -> MSC M
Cell Identifier 4.2.17 BS -> MSC M
a

Layer 3 Information 4.2.31 BS -> MSC M
a. This element identifies the cell where the service request was received from the MS. 10
Discriminator type 0000 0010 (Cell ID) shall be used in the complete Layer 3 11
Information message. 12
The bitmap below is included for information only. It is already included in the bitmaps 13
for the CM Service Request, Paging Response and Location Updating Request messages. 14
3.1.1 Complete Layer 3 Information
7 6 5 4 3 2 1 0 Octet
! !! ! Message Type = [57H] 1
! !! ! Cell Identifier: A1 Element Identifier = [05H] 1
Length = [03H] 2
Cell Identification Discriminator = [02H] 3
(MSB) Cell = [001H-FFFH] 4
Sector = [0H-FH] (0H = Omni) (LSB) 5
! !! ! Layer 3 Information: A1 Element Identifier = [17H] 1
Length = <variable>
(# of bytes included in the following message)
2
Contents of Layer 3 Message:
CM Service Request, Paging Response or Location Updating Request
3

n
15
TIA-2001.4-C
Section 3 56
3.1.2 CM Service Request 1
This DTAP message is sent from the BS to the MSC to request a service for the 2
connection management sub-layer entities, e.g., circuit switched and packet connection 3
establishment and activation of supplementary services. 4
Reference
Element
Direction
Type
Protocol Discriminator 4.2.32 BS -> MSC M
m

Reserved Octet 4.2.33 BS -> MSC M
CM Service Type 4.2.43 BS -> MSC M
m, u

Classmark Information Type 2 4.2.12 BS -> MSC M
a, m, q, u

Mobile Identity (IMSI) 4.2.13 BS -> MSC M
m, u

Called Party BCD Number 4.2.44 BS -> MSC O
b
C
Mobile Identity (ESN) 4.2.13 BS -> MSC O
m
R

Slot Cycle Index 4.2.14 BS -> MSC O
c,r
C

Authentication Response Parameter (AUTHR) 4.2.38 BS -> MSC O
d
C

Authentication Confirmation Parameter (RANDC) 4.2.35 BS -> MSC O
e
C
Authentication Parameter COUNT 4.2.39 BS -> MSC O
x
C
Authentication Challenge Parameter (RAND) 4.2.37 BS -> MSC O
f
C

Service Option 4.2.53 BS -> MSC O
g, m
R

Voice Privacy Request 4.2.11 BS -> MSC O
x
C
Radio Environment and Resources 4.2.62 BS -> MSC O
h
R
Called Party ASCII Number 4.2.63 BS -> MSC O
i
C
Circuit Identity Code 4.2.19 BS -> MSC O
j
C
Authentication Event 4.2.65 BS -> MSC O
k
C

Authentication Data 4.2.66 BS -> MSC O
l
C
PACA Reorigination Indicator 4.2.73 BS -> MSC O
n
C
User Zone ID 4.2.26 BS -> MSC O
x
C
IS-2000 Mobile Capabilities 4.2.57 BS -> MSC O
o, r, y
C
CDMA Serving One Way Delay 4.2.61 BS ->MSC O
p
C
Special Service Call Indicator 4.2.21 BS -> MSC O
s
C
Service Option Connection Identifier (SOCI) 4.2.77 BS -> MSC O
t
C
Origination Continuation Indicator 4.2.85 BS -> MSC O
v
C
Return Cause 4.2.87 BS -> MSC O
w
C
a. If an MS is capable of multiple band classes, and this information is available at the 5
BS, this shall be indicated in the band class entry field as shown in section 4.2.12. 6
b. This element is included when Digit_Mode=0, i.e. BCD digits are received by the 7
BS from the MS. 8
If the Special Service Call Indicator element is not present in this message, either the 9
Called Party ASCII Number element or the Called Party BCD Number element shall 10
TIA-2001.4-C
57 Section 3
be present (except for packet data calls (service option 0021H) or PLD calls (service 1
options 0023H or 0024H)), but not both simultaneously. If both this element and the 2
Called Party ASCII Number element are missing, or both are present, the MSC may 3
initiate call failure handling (except for packet data calls (service option 0021H) or 4
PLD calls (service options 0023H or 0024H)). 5
If the Special Service Call Indicator element is present in this message, the message 6
is valid if either the Called Party ASCII Number element or the Called Party BCD 7
Number element is present, or if both elements are absent from the message. If both 8
elements are present, the MSC may initiate call failure handling. 9
c. This element applies only to MSs operating in slotted mode (discontinuous 10
reception). It contains an index value used in paging channel slot computation. The 11
Slot Cycle Index shall be stored by the MSC, and returned to the BS for call 12
termination to the MS to ensure that the Paging Message is broadcast in the paging 13
channel slots monitored by the MS. 14
d. This optional element contains the authentication response signature (AUTHR) 15
received from an authentication capable MS when broadcast authentication is active. 16
e. This element contains the RANDC received from the MS. RANDC shall be included 17
whenever it is received from the MS and authentication is enabled. 18
f. This element is included where broadcast authentication is performed, and contains 19
the random number (RAND) value used when the BS is responsible for RAND 20
assignment and can correlate this parameter with the RAND used by the MS in its 21
authentication computation. 22
g. If no service option is received from the MS, the Service Option element is set to 23
0001H (8K speech). Note, this service option is not explicitly supported in this 24
specification. 25
h. If the MS has been or is being placed on a radio traffic channel prior to the 26
Assignment Request message, the BS shall set the Alloc field to Resources are 27
allocated and the Avail field shall be set to Resources are available. 28
i. This element contains information on the called party number coded as an ASCII 29
string. This element is included when Digit_Mode of value = 1, i.e. ASCII digit is 30
received by the BS from the MS. If the Special Service Call Indicator element is not 31
present in this message, either the Called Party ASCII Number element or the Called 32
Party BCD Number element shall be present (except for packet data calls (service 33
option 0021H) or PLD calls (service options 0023H or 0024H)), but not both 34
simultaneously. If both this element and the Called Party BCD Number element are 35
missing, or both are present, the MSC may initiate call failure handling (except for 36
packet data calls, service option 0021H). 37
elements are present, the MSC may initiate call failure handling 41
j. This element is included when the BS requests a preferred terrestrial circuit. 42
k. This element is present when an authentication enabled BS does not receive the 43
authentication parameters (AUTHR, RANDC and COUNT) from the MS, or when a 44
RAND/RANDC mismatch has occurred, or if authentication was recently requested 45
and a new authentication is not required. 46
l. This element is required when the service option is Async Data or Group 3 Fax. It 47
may be optionally included for other calls. If this element is absent and the Service 48
Option element indicates an Async Data or Group 3 Fax call, then the MSC may 49
initiate call failure handling. 50
TIA-2001.4-C
Section 3 58
m. If any of these elements are not correctly present, call failure handling may be 1
initiated by the MSC. 2
n. This element is included if the air interface Origination message indicated PACA 3
reorigination. 4
o. This element is only included when the MS operates at revision level 6 or greater as 5
defined by [1]~[6]. 6
p. This IE is included if applicable to the geo-location technology and if this technology 7
is supported at the base station. 8
q. When the BS is operating in DS-41 mode, only the following fields in the Classmark 9
Type 2 Information element shall be considered valid by the MSC: MOB_P_REV, 10
NAR_AN_CAP, Mobile Term, PSI (PACA Supported Indicator), SCM Length, 11
Count of Band Class Entries, Band Class Entry Length, Band Class n, Band Class n 12
Air Interfaces Supported, Band Class n MOB_P_REV. 13
r. These elements shall not be included by the BS when the BS and MS are operating 14
in DS-41 mode. 15
s. This element is included if the air interface Origination message indicates that the 16
user is attempting to initiate a Global Emergency Call. 17
t. This element is required if concurrent services are supported. 18
u. Because this information element is sent as a mandatory information element in a 19
DTAP message, the information element identifier is not included. 20
v. This element is included if the air interface Origination Message indicates that an 21
Origination Continuation Message is to follow. 22
w. This element is included if the MS re-sends the Origination message with Return 23
Cause to the BS because it failed to be redirected to the desired system. 24
x. This information element is included if the necessary information was received from 25
the MS. 26
y. If the BS does not have the information required to correctly populate a field in this 27
information element, it shall code the field to zero. 28
29
TIA-2001.4-C
59 Section 3
The following message layout contains the Complete Layer 3 Info message (shaded in 1
gray) encapsulating the CM Service Request message. Refer to section 3.1.1. 2
3.1.2 CM Service Request
7 6 5 4 3 2 1 0 Octet
! !! ! BSMAP Header: Message Discrimination = [00H] 1
Length Indicator (LI) = <variable> 2
Length = [03H] 2
Length = <variable>
2
Reserved = [0000] ! !! ! Protocol Discriminator = [0011]
(Call Processing & Supplementary Services)
1
! !! ! Reserved Octet = [00H] 1
! !! ! CM Service Type:
A1 Element Identifier = [1001]
Service Type = [0001]
(Mobile Originating Call)
1
! !! ! Classmark Information Type 2: Length = <variable> 1
MOB_P_REV
= [000 111]
Reserved =
[0]
See List
of
Entries
= [0,1]
RF Power Capability = [000-010]

2
Reserved = [00H] 3

NAR_AN_C
AP
= [0,1]
IS-
95
=
[1]
Slott
ed
=
[0,1]
Reserved = [00]

DTX
= [0,1]
Mobile
Term
= [0,1]
TIA/EIA
-553
= [0,1]
4
Reserved = [00H]

5
Reserved = [000000]

Mobile
Term
= [0,1]
PSI
= [0,1]
6
SCM Length = [01H] 7
Station Class Mark = [00H FFH] 8
Count of Band Class Entries = [01H-20H] 9
Band Class Entry Length = [03H] 10
TIA-2001.4-C
Section 3 60
7 6 5 4 3 2 1 0 Octet
Mobile Band Class Capability Entry {1+:
Reserved = [000] Band Class n = [00000-11111] K
Band Class n Air Interfaces Supported = [00H-FFH] k+1
Band Class n MOB_P_REV = [00H-FFH] k+2
}Mobile Band Class Capability Entry
! !! ! Mobile Identity (IMSI): Length = [06H-08H] (10-15 digits) 1
Identity Digit 1 = [0H-9H] (BCD) Odd/eve
n
Indicator
= [1,0]
Type of Identity
= [110] (IMSI)
2
Identity Digit 3 = [0H-9H] (BCD) Identity Digit 2 = [0H-9H] (BCD) 3

Identity Digit N+1 = [0H-9H] (BCD) Identity Digit N = [0H-9H] (BCD) n
= [1111] (if even number of digits) Identity Digit N+2 = [0H-9H] (BCD) n+1
! !! ! Called Party BCD Number: A1 Element Identifier = [5EH] 1
Length = [00H-11H] 2
= [1] Type of Number
= [000-111]
Number Plan Identification
= [0000-1111]
3
Number Digit/End Mark 2 = [0000-1111] Number Digit/End Mark 1 = [0000-1111] 4

Number Digit/End Mark m+1 = [0000-
1111]
Number Digit/End Mark m = [0000-1111] n
! !! ! Mobile Identity (ESN): A1 Element Identifier = [0DH] 1
Length = [05H] 2
Identity Digit 1 = [0000] Odd/eve
n
Indicator
= [0]
Type of Identity
= [101] (ESN)
3
(MSB) ESN = <any value> 4
5
6
(LSB) 7
! !! ! Slot Cycle Index: A1 Element Identifier = [35H] 1
Reserved = [00000] Slot Cycle Index = [000-111] 2
! !! ! Authentication Response Parameter (AUTHR): A1 Element Identifier = [42H] 1
Length = [04H] 2
TIA-2001.4-C
61 Section 3
7 6 5 4 3 2 1 0 Octet
Reserved = [0000] Auth Signature Type = [0001] (AUTHR) 3
[0] [0] [0] [0] [0] [0] (MSB) 4
Auth Signature = <any value> 5
(LSB) 6
! !! ! Authentication Confirmation Parameter (RANDC): A1 Element Identifier = [28H] 1
RANDC = [00H-FFH] 2
! !! ! Authentication Parameter COUNT: A1 Element Identifier = [40H] 1
Reserved =
[00]
Count = [000000-111111] 2
! !! ! Authentication Challenge Parameter (RAND): A1 Element Identifier = [41H] 1
Length = [05H] 2
Reserved = [0000] Random Number Type = [0001] (RAND) 3
(MSB) RAND = <any value> 4
5
6
(LSB) 7
! !! ! Service Option: A1 Element Identifier = [03H] 1
(MSB) Service Option = <any value> 2
(LSB) 3
! !! ! Voice Privacy Request: A1 Element Identifier = [A1H] 1
! !! ! Radio Environment and Resources: A1 Element Identifier = [1DH] 1
Reserved =
[0]
Inclu
de
Priori
ty =
[0,1]
Forward =
[00]
Reverse = [00] Alloc =
[0,1]
Avail =
[0,1]
2
! !! ! Called Party ASCII Number: A1 Element Identifier = [5BH] 1
Length = <variable> 2
ext = [1] Type of Number = [000-
111]

Numbering Plan Identification = [0000-1111]

3
ASCII character 1 4
ASCII character 2 5

ASCII character n n
! !! ! Circuit Identity Code: A1 Element Identifier = [01H] 1
(MSB) PCM Multiplexer = <any value> 2
TIA-2001.4-C
Section 3 62
7 6 5 4 3 2 1 0 Octet
(LSB) Timeslot = [00000-11111] 3
! !! ! Authentication Event: A1 Element Identifier = [4AH] 1
Length = [01H] 2
Event = [01H, 02H, 03H]
(Parameters not received, RANDC/RAND mismatch, Authentication Recently Requested)
3
! !! ! Authentication Data: A1 Element Identifier = [59H] 1
Length = [03H] 2
(MSB) Auth-Data = <any value> 3
4
(LSB) 5
! !! ! PACA Reorigination Indicator: A1 Element Identifier = [60H] 1
Length = [01H] 2
Reserved = [0000 000] PRI = [1] 3
! !! ! User Zone ID: A1 Element Identifier = [02H] 1
Length = [02H] 2
(MSB) UZID = <any value> 3
(LSB) 4
! !! ! I S-2000 Mobile Capabilities: A1 Element Identifier = [11H] 1
Reserved
= [00]
ERAM
Support
ed =
[0,1]
DCCH
Support
ed
= [0,1]
FCH
Supported
= [0,1]
OTD Supported
= [0,1]
Enhanced
RC CFG
Supported
= [0,1]
QPCH
Supporte
d
= [0,1]
3
FCH Information: Bit-Exact Length Octet Count
= [00H to FFH]
4
Reserved
= [0]
Geo Location Type
= [000, 001, 010,
011]
Geo
Location
Included =
[0,1]
FCH Information:
Bit-Exact Length Fill Bits
= [000 to 111]
5
(MSB) 6
FCH Information Content
= <any value>

Sevent
h Fill
Bit if
needed
= [0 (if
used
as a
fill
bit)]
Sixth
Fill Bit
if
needed
= [0 (if
used as
a fill
bit)]
Fifth Fill
Bit if
needed
= [0 (if
used as a
fill bit)]
Fourth
Fill Bit
if
needed
= [0 (if
used as
a fill
bit)]
Third Fill Bit
if needed
= [0 (if used
as a fill bit)]
Second Fill
Bit if
needed
= [0 (if used
as a fill bit)]
First Fill
Bit if
needed
= [0 (if
used as a
fill bit)]
k
TIA-2001.4-C
63 Section 3
7 6 5 4 3 2 1 0 Octet
DCCH Information: Bit-Exact Length Octet Count
= [00H to FFH]
k+1
Reserved
= [0000 0]
DCCH Information:
= [000 to 111]
k+2
(MSB) k+3
DCCH Information Content
= <any value>

Sevent
h Fill
Bit if
needed
= [0 (if
used
as a
fill
bit)]
Sixth
Fill Bit
if
needed
= [0 (if
used as
a fill
bit)]
Fifth Fill
Bit if
needed
= [0 (if
used as a
fill bit)]
Fourth
Fill Bit
if needed
= [0 (if
used as a
fill bit)]
Third Fill
Bit if
needed
= [0 (if used
as a fill bit)]
Second Fill
Bit if
needed
= [0 (if used
as a fill bit)]
First Fill
Bit if
needed
= [0 (if
used as a
fill bit)]
m
! !! ! CDMA Serving One Way Delay: A1 Element Identifier = [0CH] 1
Length = [08H, 0BH] 2
Cell Identification Discriminator = [02H, 07H] 3
I F (Discriminator =02H), Cell I dentification {1:
(MSB) Cell = [001H-FFFH] j
Sector = [0H-FH] (0H = Omni) (LSB) j+1
}OR I F (Discriminator =07H), Cell I dentification {1:
(MSB) MSC_ID = <any value> j
j+1
(LSB) j+2
(MSB) Cell = [001H-FFFH] j+3
}Cell I dentification
(MSB) CDMA Serving One Way Delay = [0000H-FFFFH] k
(LSB) k+1
Reserved = [0000 00] Resolution = [00, 01, 10] k+2
(MSB) CDMA Serving One Way Delay Time Stamp = [00 00H FF FFH] k+3
(LSB) k+4
! !! ! Special Service Call Indicator: A1 Element Identifier = [5AH] 1
Length = [01H] 2
Reserved = [0000 00] MOPD
= [0,1]
GECI = [1] 3
! !! ! Service Option Connection Identifier (SOCI): A1 Element Identifier = [1EH] 1
TIA-2001.4-C
Section 3 64
7 6 5 4 3 2 1 0 Octet
Length = [01H] 2
Reserved = [0000 0] Service Option Connection Identifier
= [001 - 110]
3
! !! ! Origination Continuation Indicator: A1 Element Identifier = [A0H] 1
! !! ! Return Cause: A1 Element Identifier = [68H] 1
Reserved Return_Cause

= [0000 (Normal access),
0001 (System not found),
0010 (Protocol mismatch),
0011 (Registration rejection),
0100 (Wrong SID),
0101 (Wrong NID)]
2
1
TIA-2001.4-C
65 Section 3
3.1.3 CM Service Request Continuation 1
This DTAP message is sent from the BS to the MSC when the BS receives an Origination 2
Continuation Message from the MS. 3
Reference
Element
Direction
Type
a
C
b
C
MS Information Records 4.2.59 BS -> MSC O
c
C
a. This element is included when Digit_Mode = 0, i.e. BCD digits are received by the 4
BS from the MS. The digits are copied from the Origination Continuation Message. 5
b. This element contains information on the called party number coded as an ASCII 6
string. It is included when Digit Mode of value = 1, i.e. ASCII digit is received by 7
the BS from the MS. The digits are copied from the Origination Continuation 8
Message. 9
c. This element is included if the Origination Continuation message included 10
information records carrying other relevant information to be sent to the MSC. 11
The following table shows the bitmap layout for the CM Service Request Continuation 12
message. 13
3.1.3 CM Service Request Continuation
7 6 5 4 3 2 1 0 Octet
! !! ! DTAP Header: Message Discrimination = [01H] 1
Data Link Connection Identifier (DLCI) = [00H] 2
Reserved = [0000] Protocol Discriminator = [0011]
1
= [000-111]
= [0000-1111]
3
Number Digit/End Mark 2 = [0000-1111] Number Digit/End Mark 1 = [0000-
1111]
4
Number Digit/End Mark 4 = [0000-1111] Number Digit/End Mark 3 = [0000-
1111]
5

TIA-2001.4-C
Section 3 66
3.1.3 CM Service Request Continuation
7 6 5 4 3 2 1 0 Octet
1111]
Number Digit/End Mark m = [0000-
1111]
n
ext =
[1]
Type of Number = [000-111]

Numbering Plan Identification = [0000-
1111]

3
ASCII character 1 4
ASCII character 2 5

ASCII character n n
! !! ! MS Information Records: A1 Element Identifier = [15H] 1
Length = [01H-FFH] 2
I nformation Record: {1+:
Information Record Type = [00H-FFH] j
Information Record Length = <variable> j+1
(MSB) Information Record Content = <any value> j+2

(LSB) k
}I nformation Record
1
TIA-2001.4-C
67 Section 3
3.1.4 Paging Request 1
This BSMAP message is sent from MSC to BS and contains sufficient information to 2
allow the paging to be transmitted by the correct cells, in the correct format at the correct 3
time. 4
Reference
Element
Direction
Type
Message Type 4.2.4 MSC -> BS M
Mobile Identity (IMSI/ESN) 4.2.13 MSC -> BS M
a
Tag 4.2.50 MSC -> BS O
h
C
Cell Identifier List 4.2.18 MSC -> BS O
b
C
Slot Cycle Index 4.2.14 MSC -> BS O
c,f
C

Service Option 4.2.53 MSC -> BS O
d
R

IS-2000 Mobile Capabilities 4.2.57 MSC -> BS O
e,f,i
C
Protocol Revision 4.2.83 MSC -> BS O
g
C
a. This element shall be set to ESN when the BS and MS are operating in DS-41 mode 5
and IMSI otherwise. 6
b. This element is only required for a multi-cell BS. More than one cell identifier 7
element may be included to allow the paging request of several cells within a BS on 8
receipt of a single paging request message from the MSC. When absent, paging 9
request at all cells controlled by the BS is assumed. 10
c. This element is included where slotted paging is performed on the paging channels. 11
It is used by the BS to compute the correct paging channel slot on each paging 12
channel. If this element is absent, then it is assumed that the MS is operating in non- 13
slotted mode. 14
d. The MSC may decide to page the MS with the preferred service option selected from 15
the subscribed service option record. 16
e. This element is only included when the MSC has previously been given this 17
information by a BS. 18
f. These elements shall not be included by the MSC when the BS and MS are operating 19
in DS-41 mode. 20
g. This element contains the MSs MOB_P_REV of the current band class and shall be 21
included if the value is greater than or equal to 7. 22
h. If this element is present in the message, the value shall be saved at the BS to be 23
included in the corresponding Paging Response message. 24
i. If the MSC does not have the information required to correctly populate a field in 25
this information element, it shall code the field to zero. 26
27
28
TIA-2001.4-C
Section 3 68
The following table shows the bitmap layout for the Paging Request message. 1
3.1.4 Paging Request
7 6 5 4 3 2 1 0 Octet
Message Type = [52H] 1
! !! ! Mobile Identity (IMSI/ESN): A1 Element Identifier = [0DH] 1
Length = [05H-08H] (10-15 digits) 2
Identity Digit 1 = [0H-9H] (BCD) Odd/even
Indicator
= [1,0]
Type of Identity
= [101 (ESN),110 (IMSI)]
3
I F(Type of I dentity =101), Identity {1:
5
6
(LSB) 7
}OR I F (Type of I dentity =110), I dentity {1:

}Type of I dentity
! !! ! Tag: A1 Element Identifier = [33H] 1
(MSB) Tag Value = <any value> 2
3
4
(LSB) 5
! !! ! Cell Identifier List: A1 Element Identifier = [1AH] 1
Cell Identification Discriminator = [02H,05H] 3
I F (Discriminator =02H), Cell I dentification {1+:
}OR I F (Discriminator =05H), Cell I dentification {1+:
(MSB) LAC = [0001H-FFFFH] j
(LSB) j+1
TIA-2001.4-C
69 Section 3
7 6 5 4 3 2 1 0 Octet
(MSB) Service Option 2
= [8000H (13K speech),
0011H (13K high rate voice service),
0003H (EVRC),
801FH (13K Markov),
0009H (13K Loopback),
0004H (Async Data Rate Set 1),
000CH (Async Data Rate Set 2),
0005H (G3 Fax Rate Set 1),
000DH (G3 Fax Rate Set 2),
0006H (SMS Rate Set 1),
000EH (SMS Rate Set 2),
0021H (3G High Speed Packet Data),
0012H (OTAPA Rate Set 1),
0025H (ISDN Interworking Service),
0020H (TDSO),
0036H (IS-2000 Markov),
0037H (IS-2000 Loopback),
0023H (PLD Rate Set 1),
0038H (SMV)]
(LSB) 3
Reserved
= [00]
ERAM
Supported =
[0,1]
DCCH
Supported
= [0,1]
FCH
Supported
= [0,1]
OTD
Supported
= [0,1]
Enhanced
RC CFG
Supported
= [0,1]
QPCH
Supported
= [0,1]
3
= [00H to FFH]
4
Reserved
= [0]
Geo Location Type = <any
value> (Ignored)
Geo
Location
Included
= <any
value>
(Ignored)
FCH Information:
= [000 to 111]
5
(MSB) 6
TIA-2001.4-C
Section 3 70
7 6 5 4 3 2 1 0 Octet
= <any value>

Seventh
Fill Bit
if
needed
= [0 (if
used as
a fill
bit)]
Sixth
Fill Bit
if
needed
= [0 (if
used as
a fill
bit)]
Fifth
Fill Bit
if
needed
= [0 (if
used as
a fill
bit)]
Fourth
Fill Bit
if
needed
= [0 (if
used as a
fill bit)]
Third Fill Bit
if needed
= [0 (if used
as a fill bit)]
Second
Fill Bit
if needed
= [0 (if
used as a
fill bit)]
First Fill
Bit if
needed
= [0 (if
used as a
fill bit)]
k
= [00H to FFH]
k+1
Reserved
= [0000 0]
DCCH Information:
= [000 to 111]
k+2
(MSB) k+3
= <any value>

Seventh
Fill Bit
if
needed
= [0 (if
used as
a fill
bit)]
Sixth
Fill Bit
if
needed
= [0 (if
used as
a fill
bit)]
Fifth
Fill Bit
if
needed
= [0 (if
used as
a fill
bit)]
Fourth
Fill Bit
if
needed
= [0 (if
used as a
fill bit)]
Third Fill Bit
if needed
= [0 (if used
as a fill bit)]
Second
Fill Bit
if needed
= [0 (if
used as a
fill bit)]
First Fill
Bit if
needed
= [0 (if
used as a
fill bit)]
m
! !! ! Protocol Revision: A1 Element Identifier = [3BH] 1
Length = [01H] 2
MOB_P_REV = [07H-FFH] 3
1
TIA-2001.4-C
71 Section 3
3.1.5 Paging Response 1
This DTAP message is sent from the BS to the MSC when the BS receives a page 2
response message from an MS. 3
Reference
Element
Direction
Type
j

Classmark Information Type 2 4.2.12 BS -> MSC M
a, j, l, p

j, p

Tag 4.2.50 BS -> MSC O
q
C

R
b,m
C

c
C

d
C
r
C
e
C

f, j
R

r
C
g
C
h
C
Radio Environment and Resources 4.2.62 BS -> MSC O
i
R
r
C

k, m, s
C
CDMA Serving One Way Delay 4.2.61 BS -> MSC O
n, m
C
m, o
C
a. If an MS is capable of supporting multiple band classes, and this information is 4
available at the BS, it shall be indicated in the Band Class Entry field as shown in 5
section 4.2.12. 6
b. This element applies only to MSs operating in slotted mode (discontinuous 7
termination to the MS to ensure that the paging message is broadcast in the 10
cdma2000
paging channel slots monitored by the MS. 11

c. This element contains the authentication response signature (AUTHR) received from 12
an authentication capable MS when broadcast authentication is active. 13
d. This element contains the RANDC received from the MS. RANDC shall be included 14
e. This element is included when broadcast authentication is performed, and contains 16
TIA-2001.4-C
Section 3 72
f. If no service option is received from the MS, the Service Option element is set to 1
specification. 3
g. This element is included when the BS requests a preferred terrestrial circuit. 4
h. This element is present when an authentication enabled BS does not receive the 5
RAND/RANDC mismatch has occurred. 7
i. If the MS has been or is being placed on a radio traffic channel prior to the 8
Assignment Request message, the BS shall set the Alloc field to Resources are 9
allocated and the Avail field shall be set to Resources are available. 10
j. If any of these elements are not correctly present, call failure handling may be 11
k. This element is only included when the MS operates at revision level 6 or greater as 13
l. When the BS is operating in DS-41 mode, only the following fields in the Classmark 15
m. These elements shall not be included by the BS when the BS and MS are operating 20
in DS-41 mode. 21
n. This IE is included if applicable to the geo-location technology and if this technology 22
is supported at the base station. 23
o. This element is required if concurrent services are supported. 24
p. Because this information element is sent as a mandatory information element in a 25
q. If the Tag information element was received from the MSC in the Paging Request 27
message, the BS shall include the Tag information element. The Tag value used in 28
this message shall be the same as the Tag value received from the MSC in the Paging 29
Request message. 30
r. This information element is included if the necessary information was received from 31
the MS. 32
s. If the BS does not have the information required to correctly populate a field in this 33
35
TIA-2001.4-C
73 Section 3
The following message layout contains the Complete Layer 3 Info message (shaded in 1
gray) encapsulating the Paging Response message. Refer to section 3.1.1. 2
3.1.5 Paging Response
7 6 5 4 3 2 1 0 Octet
Length = [03H] 2
Length = <variable>
2
1
! !! ! Classmark Information Type 2: Length = <variable> 1
MOB_P_REV
= [000 111]
Reserved
= [0]
See List
of Entries
= [0,1]

2
Reserved = [00H] 3
NAR_
AN_
CAP
= [0,1]
IS-95
= [1]
Slotted
= [0,1]
Reserved = [00]

DTX
= [0,1]
Mobile
Term
= [0,1]
TIA/EI
A-553
= [0,1]
4
Reserved = [00H] 5
Reserved = [0000 00]

Mobile
Term
= [0,1]
PSI
= [0,1]
6
Reserved = [000] Band Class n = [00000-11111] k
TIA-2001.4-C
Section 3 74
7 6 5 4 3 2 1 0 Octet
Indicator
= [1,0]
Type of Identity
= [110] (IMSI)
2

3
4
(LSB) 5
Length = [05H] 2
Identity Digit 1 = [0000] Odd/even
Indicator
= [0]
Type of Identity
= [101] (ESN)
3
5
6
(LSB) 7
Length = [04H] 2
= [0] = [0] = [0] = [0] = [0] = [0] (MSB) 4
(LSB) 6
! !! ! Authentication Confirmation Parameter (RANDC):
A1 Element Identifier = [28H]
1
RANDC = [00H-FFH] 2
TIA-2001.4-C
75 Section 3
7 6 5 4 3 2 1 0 Octet
Reserved = [00] Count = [00 0000 - 11 1111] 2
Length = [05H] 2
(MSB) RAND Value = <any value> 4
5
6
(LSB) 7
(LSB) 3
(LSB) Timeslot = [00000-11111] 3
Length = [01H] 2
Event = [01H, 02H]
(Parameters not received, RANDC/RAND mismatch)
3
! !! ! Radio Environment and Resources: A1 Element Identifier = [1DH] 1
Reserve
d = [0]
Include
Priorit
y =
[0,1]
Forward = [00] Reverse = [00] Alloc =
[0,1]
Avail
= [0,1]
2
Length = [02H] 2
(LSB) 4
Reserved
= [00]
ERAM
Supported
= [0,1]
DCCH Supported
= [0,1]
FCH
Supported
= [0,1]
OTD
Supported
= [0,1]
Enhanced
RC CFG
Supported
= [0,1]
QPCH
Support
ed
= [0,1]
3
= [00H to FFH]
4
TIA-2001.4-C
Section 3 76
7 6 5 4 3 2 1 0 Octet
Reserved
= [0]
Geo Location Type = [000]
(Ignored)
Geo
Location
Included =
[0]
(Ignored)
FCH Information:
= [000 to 111]
5
(MSB) 6
= <any value>

Seventh
Fill Bit
if
needed
= [0 (if
used as
a fill
bit)]
Sixth Fill
Bit if
needed
= [0 (if
used as a
fill bit)]
Fifth Fill
Bit if
needed
= [0 (if
used as a
fill bit)]
Fourth Fill
Bit if
needed
= [0 (if
used as a
fill bit)]
Third Fill
Bit if
needed
= [0 (if used
as a fill bit)]
Second
Fill Bit
if
needed
= [0 (if
used as
a fill
bit)]
First
Fill
Bit if
needed
= [0 (if
used as
a fill
bit)]
k
= [00H to FFH]
k+1
Reserved
= [0000 0]
DCCH Information:
= [000 to 111]
k+2
(MSB) k+3
= <any value>

Sevent
h Fill
Bit if
needed
= [0 (if
used as
a fill
bit)]
Sixth Fill
Bit if
needed
= [0 (if
used as a
fill bit)]
Fifth Fill
Bit if
needed
= [0 (if
used as a
fill bit)]
Fourth Fill
Bit if
needed
= [0 (if
used as a
fill bit)]
Third Fill
Bit if
needed
= [0 (if used
as a fill bit)]
Second
Fill Bit
if
needed
= [0 (if
used as
a fill
bit)]
First
Fill
Bit if
needed
= [0 (if
used as
a fill
bit)]
m
(MSB) MSCID = <any value> j
j+1
(LSB) j+2
TIA-2001.4-C
77 Section 3
7 6 5 4 3 2 1 0 Octet
(LSB) Sector = [0H-FH] (0H = Omni) j+4
(LSB) k+1
Reserved = [0000 00] Resolution = [00,
01, 10]
k+2
(LSB) k+4
Length = [01H] 2
Reserved = [0000 0] Service Option Connection
Identifier = [001 - 110]
3
1
TIA-2001.4-C
Section 3 78
3.1.6 Progress 1
This DTAP message is sent from the MSC to the BS to trigger tone generation at the MS 2
(e.g., via a Reorder Order or Intercept Order message to the MS) prior to clearing a call 3
request. Local tone generation allows the network to convey tone information to a user by 4
means of signaling information. 5
Reference
Element
Direction
Type
Protocol Discriminator 4.2.32 MSC -> BS M
Reserved Octet 4.2.33 MSC -> BS M
Signal 4.2.42 MSC -> BS O
a
C
MS Information Records 4.2.59 MSC -> BS O
a,b
C
Service Option Connection Identifier (SOCI) 4.2.77 MSC -> BS O
c
C
a. Either the Signal element or the MS Information Records element shall be present in 6
this message, but both shall not be present simultaneously. 7
8
b. This element carries the MS Information Records. This element shall carry only 9
signal information. 10
c. This element is required if concurrent services are supported. 11
The following table shows the bitmap layout for the Progress message. 12
3.1.6 Progress
7 6 5 4 3 2 1 0 Octet
Reserved = [0000] ! !! ! Protocol Discriminator = [0011] 1
! !! ! Signal: A1 Element Identifier = [34H] 1
Signal value = [63H (abbrev intercept),
65H (abbrev reorder),
02H (intercept),
03H (Network Congestion (reorder) tone on)]
2
Reserved = [000000] Alert Pitch =
[00,01,10]
(med, high, low)
3
TIA-2001.4-C
79 Section 3
3.1.6 Progress
7 6 5 4 3 2 1 0 Octet
(MSB) Information Record Content j+2

(LSB) k
Length = [01H] 2
Reserved = [0000 0] Service Option
Connection Identifier =
[001 - 110]
3
1
TIA-2001.4-C
Section 3 80
3.1.7 Assignment Request 1
This BSMAP message is sent from the MSC to the BS to request that the BS assign radio 2
resource, the attributes of which are defined within the message. The message may 3
include the terrestrial circuit to be used if one is needed for the call/activity. The message 4
includes the necessary information for providing PACA service if the call is eligible for 5
such service. 6
Reference
Element
Direction
Type
Channel Type 4.2.6 MSC -> BS M
a
Circuit Identity Code 4.2.19 MSC -> BS O
b
C
Encryption Information 4.2.10 MSC -> BS O
c
C
d
R
e, f, h
C
g
C
Priority 4.2.15 MSC -> BS O
k
C
PACA Timestamp 4.2.71 MSC -> BS O
i
C
Quality of Service Parameters 4.2.45 MSC -> BS O
j
C
l
C
Service Reference Identifier (SR_ID) 4.2.90 MSC -> BS O
m
C
a. Channel Type is being included for historical reasons and is hard coded as shown. 7
The BS should examine the Service Option element instead. 8
b. This element is not included when a terrestrial resource is not required. When the 9
Service Option element indicates one of the following {Markov, loopback, packet 10
data, OTAPA, short message, Test Data, IS-2000 Markov, IS-2000 Loopback, PLD}, 11
this element is not included in the message. 12
c. This element is present when encryption is requested and the MSC has the keys 13
available at the time this message is sent. 14
d. The MSC shall send to the BS the same service option received on the CM Service 15
Request, Paging Response, or Additional Service Request message. 16
e. This element carries instructions for the generation of audible tones or alerting 17
patterns. For mobile terminated calls, it can be used to specify a distinctive alerting 18
pattern. This element is not used for mobile originated calls. This element may be set 19
to Alerting Off if included when used for setting up an SMS delivery on the traffic 20
channel. 21
f. The Signal element is retained in this message for the purpose of backward 22
compatibility. If this information is included in the MS Information Records 23
information element, this element is not included. 24
g. This element carries the MS Information Records. It shall not redundantly carry 25
information present in other elements such as Signal. 26
h. The Signal information record may be set to Alerting Off if included when used 27
for setting up an SMS delivery on the traffic channel. The Signal information record 28
is not included for mobile originated calls. 29
TIA-2001.4-C
81 Section 3
i. This element is present only when the call is eligible for PACA service. 1
j. This element is only used for packet data calls. In this version of this standard, this 2
element carries the users subscribed QoS for non-assured mode operation. 3
k. If the Include Priority bit of the Radio Environment and Resources element was set 4
to 1 in the CM Service Request message to indicate that no lower priority channels 5
are available (e.g., when a PACA channel reservation scheme is used) the MSC shall 6
include the actual call priority. 7
l. This element is required if concurrent services are supported. 8
m. This element is included if this message is sent upon receiving a BS Service Request 9
message containing this element. This element contains the SR_ID value of the 10
packet data service instance that is to be re-activated. 11
The following table shows the bitmap layout for the Assignment Request message. 12
3.1.7 Assignment Request
7 6 5 4 3 2 1 0 Octet
! !! ! Channel Type: A1 Element Identifier = [0BH] 1
Length = [03H] 2
Speech or Data Indicator =[01H] (speech) 3
Channel Rate and Type = [08H] (Full Rate) 4
Speech Encoding Algorithm/data rate + Transparency Indicator = [05H]
(13 kbps vocoder - speech)
5
(LSB) Timeslot = [00000-11111] 3
! !! ! Encryption Information: A1 Element Identifier = [0AH] 1
Encryption I nfo {1..2:
I F (Encryption Parameter I dentifier =00001, 00101, or 00110) {1:
ext = [1] Encryption Parameter Identifier =
[00001 (SME),
00101 (Datakey (ORYX)),
00110 (Initial RAND)]
Status
= [0,1]
Available
= [0]
j
Encryption Parameter Length = [04H, 08H] j+1
(MSB) Encryption Parameter value j+2

(LSB) k
}OR I F (Encryption Parameter I dentifier =00100) {1:
TIA-2001.4-C
Section 3 82
7 6 5 4 3 2 1 0 Octet
ext = [1] Encryption Parameter Identifier = [00100]
(Private Longcode)
Status
= [0,1]
Available
= [0]
j
Encryption Parameter Length = [06H] j+1
Reserved = [00 0000] (MSB) j+2
Encryption Parameter value (Private Long Code) j+3
j+4
j+5
j+6
(LSB) j+7
}Encryption Parameter I dentifier
}Encryption I nfo
= [8000H (13K speech),
0001H (8K Speech),
0003H (EVRC),
801FH (13K Markov),
0020H (TDSO),
0036H (IS-2000 Markov),
0038H (SMV)]
(LSB) 3
TIA-2001.4-C
83 Section 3
7 6 5 4 3 2 1 0 Octet
Signal value = [40H (normal),
41H (inter-group),
42H (special/priority),
44H (ping ring),
4FH (alerting off),
81H (long),
82H (short-short),
83H (short-short-long),
84H (short-short-2),
85H (short-long-short),
86H (short-short-short-short),
87H (PBX long),
88H (PBX short-short),
89H (PBX short-short-long),
8AH (PBX short-long-short),
8BH (PBX short-short-short-short)]
2
Reserved = [00 0000] Alert Pitch =
[00,01,10]
(med, high, low)
3

(LSB) k
! !! ! Priority: A1 Element Identifier = [06H] 1
Length = [01H] 2
Reserved = [00] Call Priority = [0000 1111] Queuing
Allowed
= [0,1]
Preemption
Allowed
= [0,1]
3
! !! ! PACA Timestamp: A1 Element Identifier = [4EH] 1
Length = [04H] 2
(MSB) PACA Queuing Time = <any value> 3
4
5
TIA-2001.4-C
Section 3 84
7 6 5 4 3 2 1 0 Octet
(LSB) 6
! !! ! Quality of Service Parameters: A1 Element Identifier = [07H] 1
Length = [01H] 2
Reserved = [0000] Non-Assured Mode Packet Priority =
[0000 1101]
3
Length = [01H] 2
[001 - 110]
3
! !! ! Service Reference Identifier (SR_ID): A1 Element Identifier = [71H] 1
Length = [01H] 2
Reserved = [0000 0] SR_ID =
[001 110]
3
1
TIA-2001.4-C
85 Section 3
3.1.8 Assignment Complete 1
This BSMAP message is sent from the BS to the MSC and indicates that the requested 2
assignment has been completed. 3
Reference
Element
Direction
Type
Channel Number 4.2.5 BS -> MSC M
c

Encryption Information 4.2.10 BS -> MSC O
a
C
b
R
d
C
a. This element is present when either Voice Privacy (VP) or Signaling Message 4
Encryption (SME) parameters were provided by the MSC in the Privacy Mode 5
Command or Assignment Request message. It contains the algorithm information 6
which indicates the current settings of VP and SME. No keys (encryption 7
parameters) are included in this message. 8
b. If the service option value included in the Assignment Request message was 8000H, 9
0011H, 0038H or 0003H (13K speech, 13K high rate speech, SMV, or EVRC), then 10
the only allowable values that may be sent on this message are those same four 11
service options. 12
If the service option value included in the Assignment Request message indicated a 13
fax call, then the only allowable values that may be sent on this message are fax 14
service options. 15
data call, then the only allowable values that may be sent on this message are data 17
service options. 18
If the service option value included in the Assignment Request message indicated an 19
SMS call, then the only allowable values that may be sent on this message are SMS 20
service options. 21
If the service option value included in the Assignment Request message indicated 22
either Markov or loopback procedures, then the only allowable values that may be 23
sent on this message are values that indicate Markov or loopback procedures. 24
If the service option value included in the Assignment Request message indicated an 25
OTAPA call, then the only allowable values that may be sent on this message are 26
OTAPA service options. 27
PLD call, then the only allowable values that may be sent on this message are values 29
that indicate PLD service options. 30
If any of the above rules are violated, the MSC may initiate failure handling. 31
c. If this element is not correctly present, call failure handling may be initiated by the 32
MSC. 33
d. This element is required if concurrent services are supported. 34
35
TIA-2001.4-C
Section 3 86
The following table shows the bitmap layout for the Assignment Complete message. 1
3.1.8 Assignment Complete
7 6 5 4 3 2 1 0 Octet
! !! ! Channel Number: A1 Element Identifier = [23H] 1
(reserved) ARFCN High Part (MSB) 2
ARFCN Low Part(LSB) 3
Length = [02H,04H] 2
[0 0001 (SME),
0 0100 (Private Longcode),
0 0101 (Datakey (ORYX)),
0 0110 (Initial RAND)]

Status
= [0,1]
Available
= [0,1]
j
}Encryption I nfo
TIA-2001.4-C
87 Section 3
3.1.8 Assignment Complete
7 6 5 4 3 2 1 0 Octet
= [8000H (13K speech),
0003H (EVRC),
801FH (13K Markov),
0020H (TDSO),
0036H (IS-2000 Markov),
0038H (SMV)]
(LSB) 3
Length = [01H] 2
[001 - 110]
3
1
TIA-2001.4-C
Section 3 88
3.1.9 Assignment Failure 1
This BSMAP message is sent from the BS to the MSC and indicates that the requested 2
assignment could not be completed. 3
Reference
Element
Direction
Type
Cause 4.2.16 BS -> MSC M
a
b
C
a. If the MSC uses a CIC value that is unknown to the BS, the cause value used shall be 4
25H (BS not equipped). 5
b. This element is required if concurrent services are supported. 6
The following table shows the bitmap layout for the Assignment Failure message. 7
3.1.9 Assignment Failure
7 6 5 4 3 2 1 0 Octet
Length Indicator (LI) = [04H, 07H] 2
! !! ! Cause: A1 Element Identifier = [04H] 1
Length = [01H] 2
ext = [0] Cause Value =
[00H (Radio interface message failure),
01H (Radio interface failure),
07H (OAM&P intervention),
10H (Packet call going dormant),
20H (Equipment failure),
21H (No radio resource available),
22H (Requested terrestrial resource unavailable),
25H (BS not equipped),
26H (MS not equipped (or incapable)),
29H (PACA call queued),
30H (Requested transcoding/rate adaptation unavailable),
31H (Lower priority radio resources not available),
50H (Terrestrial circuit already allocated),
60H (Protocol error between BS and MSC),
79H (PDSN resources are not available)]
3
! !! ! SOCI: A1 Element Identifier = [1EH] 1
Length = [01H] 2
TIA-2001.4-C
89 Section 3
3.1.9 Assignment Failure
7 6 5 4 3 2 1 0 Octet
Reserved Service Option Connection
3
1
2
TIA-2001.4-C
Section 3 90
3.1.10 Connect 1
This DTAP message is sent by the BS to the MSC for mobile terminated calls (except for 2
network initiated packet data session reactivations) to indicate that the call has been 3
accepted by the user. 4
Reference
Element
Direction
Type
a
C
a. This element is required if concurrent services are supported. 5
The following table shows the bitmap layout for the Connect message. 6
3.1.10 Connect
7 6 5 4 3 2 1 0 Octet
Length Indicator (LI) = [03H] 3
Length = [01H] 2
[001 - 110]
3
7
8
TIA-2001.4-C
91 Section 3
3.1.11 Service Release 1
This DTAP message is sent, from either the BS or the MSC, to indicate that the 2
equipment sending the message intends to release a service that is not the only service 3
connected to the MS, and that the receiving equipment should release the corresponding 4
service option connection after sending a Service Release Complete message. 5
Reference
Element
Direction
Type
Protocol Discriminator 4.2.32 BS <-> MSC M
Reserved - Octet 4.2.33 BS <-> MSC M
Message Type 4.2.4 BS <-> MSC M
Service Option Connection Identifier (SOCI) 4.2.77 BS <-> MSC O R
Cause 4.2.16 BS <-> MSC O
a
R
Cause Layer 3 4.2.46 BS <-> MSC O
b
C
a. When the MS or MSC initiates a single service option connection release, the cause 6
value in this message shall be set to call processing, and the real reason for sending 7
the Service Release message is specified in the Cause Layer 3 information element. 8
Since the purpose of this message is to release the call, call release should proceed 9
even if the Cause element is missing from this message. 10
b. This element contains the reason for sending the Service Release message when the 11
MS or MSC has initiated a single service option connection release. 12
The following table shows the bitmap layout for the Service Release message. 13
3.1.11 Service Release
7 6 5 4 3 2 1 0 Octet
Length Indicator (LI) = [09H, 0DH] 3
(Call Processing & Supplementary
Services)
1
! !! ! Message Type = [2EH] 1
Length = [01H] 2
Connection Identifier
= [001 - 110]
3
Length = [01H] 2
TIA-2001.4-C
Section 3 92
3.1.11 Service Release
7 6 5 4 3 2 1 0 Octet
ext =
[0]
Cause Value =
[00H (radio interface message failure),
01H (radio interface failure),
09H (call processing),
10H (packet call going dormant),
0DH (timer expired),
20H (equipment failure),
60H (protocol error between BS and MSC),
77H (PPP session closed by the MS)]
3
! !! ! Cause Layer 3: A1 Element Identifier = [08H] 1
Length = [02H] 2
ext =
[1]
Coding Standard
= [00]
Reserved
= [0]
Location = [0100]
(Public network serving the remote user)
3
ext =
[1]
Cause Value = [001 0000 (normal clearing),
001 0001(user busy),
001 0011(user alerting no answer),
001 1111(normal unspecified)]

4
1
TIA-2001.4-C
93 Section 3
3.1.12 Service Release Complete 1
This DTAP message is sent by the BS or the MSC, to indicate that the equipment sending 2
the message has released a service that is not the only service connected to MS, and that 3
the receiving equipment shall release the corresponding service option connection. 4
Reference
Element
Direction
Type
Reserved - Octet 4.2.33 BS <-> MSC M
Service Option Connection Identifier (SOCI) 4.2.77 BS <-> MSC O R
5
The following table shows the bitmap layout for the Service Release Complete message. 6
3.1.12 Service Release Complete
7 6 5 4 3 2 1 0 Octet
Services)
1
! !! ! Message Type = [2FH] 1
Length = [01H] 2
Reserved = [0000 0] Service Option Connection
3
TIA-2001.4-C
Section 3 94
3.1.13 Clear Request 1
The BS sends this BSMAP message to the MSC to indicate that the BS is releasing all 2
service option connections to the MS and the associated dedicated resource. This 3
message is sent via the BSMAP SCCP connection associated with the dedicated resource. 4
Reference
Element
Direction
Type
a

Cause Layer 3 4.2.46 BS -> MSC O
b
C
a. When the MS sends a Release Order to the BS to clear the call, the cause value in 5
this message shall be set to call processing, and the real reason for sending the 6
Clear Request message is specified in the Cause Layer 3 information element. 7
Since the purpose of this message is to release the call, call release should proceed 8
even if the Cause element is missing from this message. 9
b. This element contains the reason for sending the Clear Request message from the BS 10
to the MSC when the MS has sent a Release Order to the BS to clear the call. 11
The following table shows the bitmap layout for the Clear Request message. 12
3.1.13 Clear Request
7 6 5 4 3 2 1 0 Octet
Length Indicator (LI) = [04H,08H] 2
Length = [01H] 2
[00H (radio interface message failure),
01H (radio interface failure),
09H (call processing),
10H (packet call going dormant),
0DH (timer expired),
20H (equipment failure),
60H (protocol error between BS and MSC),
77H (PPP session closed by the MS)]
3
Length = [02H] 2
ext = [1] Coding Standard
= [00]
Reserved
= [0]
Location = [0100]
3
TIA-2001.4-C
95 Section 3
3.1.13 Clear Request
7 6 5 4 3 2 1 0 Octet
[001 0000 (Normal clearing),
001 1111(Normal, unspecified)]
4
1
TIA-2001.4-C
Section 3 96
3.1.14 Clear Command 1
This BSMAP message is sent from MSC to BS to instruct the BS to release all service 2
option connections to the MS and the associated dedicated resource. This message is sent 3
via the BSMAP SCCP connection associated with the dedicated resource. 4
Reference
Element
Direction
Type
Cause 4.2.16 MSC -> BS M
a

Cause Layer 3 4.2.46 MSC -> BS O
b
C
a. This mandatory element indicates the reason for sending the Clear Command 5
message to the BS. If the Clear Command message is being sent in response to a 6
Clear Request message that contained a cause value of call processing, then this 7
element shall be set to call processing. 8
b. This element is only used when the MSC initiates call clearing. The Cause Layer 3 9
element shall be present only when the Cause element contains a value of Call 10
processing. 11
The following table shows the bitmap layout for the Clear Command message. 12
3.1.14 Clear Command
7 6 5 4 3 2 1 0 Octet
Length = [01H] 2
[07H (OAM&P intervention),
09H (Call processing),
0AH (Reversion to old channel),
0BH (Handoff successful),
1AH (Authentication Failure),
60H (Protocol error between BS and MSC),
78H (Do not notify MS)]
3
Length = [02H] 2
= [00]
Reserved
= [0]
Location = [0100]
3
TIA-2001.4-C
97 Section 3
3.1.14 Clear Command
7 6 5 4 3 2 1 0 Octet
[001 0000 (Normal clearing),
001 0001 (User busy),
001 0011 (User alerting, no answer),
001 1111 (Normal, unspecified)]
4
1
TIA-2001.4-C
Section 3 98
3.1.15 Clear Complete 1
The BS sends this BSMAP message to the MSC to inform the MSC that all service 2
option connections to the MS and the associated dedicated resource have been 3
successfully cleared. 4
Reference
Element
Direction
Type
Power Down Indicator 4.2.48 BS -> MSC O
a
C
a. This element is used to indicate that the mobile powered down at the end of the call. 5
The following table shows the bitmap layout for the Clear Complete message. 6
3.1.15 Clear Complete
7 6 5 4 3 2 1 0 Octet
Length Indicator (LI) = [01H,02H]
(depending on the presence of the Power Down Indicator)
2
[1] [0] [1] [0] ! !! ! Power Down Indicator:
A1 Element Identifier = [0010]
1
7
8
TIA-2001.4-C
99 Section 3
3.1.16 Alert with Information 1
This DTAP message is sent from the MSC to the BS. It directs the BS to send an Alert 2
with Information Message on the air interface to the MS. 3
Reference
Element
Direction
Type
a
C
b
C
a. This element carries the MS Information Records. 4
The following table shows the bitmap layout for the Alert with Information message. 6
3.1.16 Alert with Information
7 6 5 4 3 2 1 0 Octet
(MSB) Information Record Content j+2

(LSB) k
Length = [01H] 2
[001 - 110]
3
7
TIA-2001.4-C
Section 3 100
3.1.17 BS Service Request 1
This BSMAP message is sent from the BS to the MSC to request a BS initiated mobile 2
terminated call setup. This message is also used for mobile terminated Short Data Burst 3
delivery. 4
Reference
Element
Direction
Type
a
C
b
R
c
C
ADDS User Part 4.2.54 BS -> MSC O
d
C
Service Reference Identifier (SR_ID) 4.2.90 BS -> MSC O
e
C
a. This element is present when the ESN is available at the BS. 5
b. This element indicates the service option requested by the BS. 6
c. If this element is present in the message, the value shall be saved at the MSC to be 7
included in a BS Service Response message. 8
d. This element contains the data received from the PDSN in SDB format as specified 9
in [22]. 10
e. This element is passed to the MSC when the network reactivates a packet data 11
service instance and the SR_ID is available at the BS. The element identifies the 12
reactivated service instance. 13
The following table shows the bitmap layout for the BS Service Request message. 14
3.1.17 BS Service Request
7 6 5 4 3 2 1 0 Octet
! !! ! Mobile Identity (IMSI): A1 Element Identifier = [0DH] 1
Indicator
= [1,0]
Type of Identity
= [110] (IMSI)
3

Length = [05H] 2
TIA-2001.4-C
101 Section 3
3.1.17 BS Service Request
7 6 5 4 3 2 1 0 Octet
Indicator
= [0]
Type of Identity
= [101] (ESN)
3
5
6
(LSB) 7
(MSB) Service Option =
[00 21H (3G High Speed Packet Data)]
2
(LSB) 3
3
4
(LSB) 5
! !! ! ADDS User Part: A1 Element Identifier = [3DH] 1
Reserved Data Burst Type =
[06H (Short Data Burst)]
3
(MSB) Application Data Message = <any value> 4

(LSB) n
! !! ! Service Reference Identifier (SR_ID): A1 Element Identifier = [71H] 1
Length = [01H] 2
Reserved = [0000 0] SR_ID =
[001 110]
3
1
TIA-2001.4-C
Section 3 102
3.1.18 BS Service Response 1
This BSMAP message is sent from the MSC to the originating BS to convey the outcome 2
of processing the BS Service Request message. 3
Reference
Element
Direction
Type
Mobile Identity (IMSI) 4.2.13 MSC -> BS M
Mobile Identity (ESN) 4.2.13 MSC -> BS O
a
C
b
C
Cause 4.2.16 MSC -> BS O
c
C
a. This element is present when the ESN value is available at the MSC. 4
b. If a Tag element was received from the BS in the BS Service Request message, the 5
MSC shall include the Tag element in the BS Service Response message. The Tag 6
value used in this message shall be the same as the Tag value received from the BS. 7
c. This element shall only be included if the MSC does not grant the BS service 8
request. 9
The following table shows the bitmap layout for the BS Service Response message. 10
3.1.18 BS Service Response
7 6 5 4 3 2 1 0 Octet
! !! ! Message Type = [0AH] 1
Indicator
= [1,0]
Type of Identity
= [110] (IMSI)
3

Length = [05H] 2
Indicator
= [0]
Type of Identity
= [101] (ESN)
3
5
TIA-2001.4-C
103 Section 3
3.1.18 BS Service Response
7 6 5 4 3 2 1 0 Octet
6
(LSB) 7
3
4
(LSB) 5
Length = [01H] 2
ext = [0] Cause Value = [08H (MS busy),
11H (Service option not available)]
3
1
TIA-2001.4-C
Section 3 104
3.1.19 Additional Service Notification 1
This BSMAP message is sent from MSC to BS to request additional service option 2
connection establishment to the existing call. 3
Reference
Element
Direction
Type
Mobile Identity (IMSI) 4.2.13 MSC -> BS O R
a
R

a. The MSC may propose the preferred service option selected from the subscribed 4
service option record as an additional service option connection. 5
The following table shows the bitmap layout for the Additional Service Notification 6
message. 7
3.1.19 Additional Service Notification
7 6 5 4 3 2 1 0 Octet
Indicator
= [1,0]
Type of Identity
= [110] (IMSI)
3

= [8000H (13K speech),
0003H (EVRC),
0001H (8K speech),
0038H (SMV),
0021H (3G High Speed Packet Data)]
(LSB) 3
8
9
TIA-2001.4-C
105 Section 3
3.1.20 Additional Service Request 1
This DTAP message is sent from the BS to the MSC to request additional service option 2
connection establishment to the existing call. 3
Reference
Element
Direction
Type
a

Service Option Connection Identifier (SOCI) 4.2.77 BS -> MSC O R
b
C
c,a
R

Voice Privacy Request 4.2.11 BS -> MSC O C
d
C
e
C
f
C
a. If any of these elements are not correctly present, call failure handling may be 4
b. This element is included when Digit_Mode=0, i.e. BCD digits are received by the 6
BS from the MS. 7
be present (except for packet data calls, service option 0021H), but not both 10
simultaneously. If both this element and the Called Party ASCII Number element are 11
missing, or both are present, the MSC may initiate call failure handling (except for 12
packet data calls, service option 0021H). 13
c. If no service option is received from the MS, the Service Option element is set to 18
specification. 20
d. This element contains information on the called party number coded as an ASCII 21
string. This element is included when Digit_Mode of value = 1, i.e. ASCII digit is 22
received by the BS from the MS. 23
be present, but not both simultaneously. If both this element and the Called Party 26
BCD Number element are missing, or both are present, the MSC may initiate call 27
failure handling (except for packet data calls, service option 0021H). 28
TIA-2001.4-C
Section 3 106
e. This element is included when the BS requests a preferred terrestrial circuit. 1
f. This element is included if the air interface Enhanced Origination message indicates 2
that the user is attempting to initiate a Global Emergency Call. 3
The following table shows the bitmap layout for the Additional Service Request message. 4
3.1.20 Additional Service Request
7 6 5 4 3 2 1 0 Octet
Services)
1
Length = [01H] 2
[001 - 110]
3
= [000-111]
= [0000-1111]
3

1111]
Number Digit/End Mark m = [0000-1111] n
= [8000H (13K speech),
0003H (EVRC),
0001H (8K speech),
0038H (SMV)]
(LSB) 3
TIA-2001.4-C
107 Section 3
3.1.20 Additional Service Request
7 6 5 4 3 2 1 0 Octet
ext =
[1]
Type of Number = [000-111]

Numbering Plan Identification = [0000-1111]

3
ASCII character 1 4
ASCII character 2 5

ASCII character n n
(LSB) Timeslot = [00000-11111] 3
Length = [01H] 2
Reserved = [0000 00] MOPD =
[0,1]
GECI =
[1]
3
1
TIA-2001.4-C
Section 3 108
3.2 Supplementary Services Message Formats 1
2
3.2.1 Flash with Information 3
This DTAP message is sent from the BS to the MSC to indicate that a hook-flash has 4
been received from the MS. This message may be sent from the MSC to the BS for 5
supplementary services. 6
Reference
Element
Direction
Type
Reserved Octet 4.2.33 BS <-> MSC M
a
C
b
C
f
C
MS Information Records 4.2.59 MSC <-> BS O
c
C
d
C
Service Option Connection Identifier (SOCI) 4.2.77 BS <-> MSC O
e
C
a. This element is only retained in this message in this version of the standard for the 7
purpose of backward compatibility. It is not intended to be supported in future 8
versions. This element shall only be sent to a base station operating at IOS V4.0 or 9
earlier. 10
b. The Signal information element is retained in this message for the purpose of 11
backward compatibility. 12
c. This element carries the MS Information Records. It shall not redundantly carry 13
d. This element is included if the air interface Flash With Information message 15
indicates that the user is attempting to initiate an emergency call. 16
e. This element is required if concurrent services are supported. 17
f. The MSC includes this element to request an acknowledgement from the BS that the 18
corresponding air interface message was received by the MS. 19
20
TIA-2001.4-C
109 Section 3
The following table shows the bitmap layout for the Flash with Information message. 1
3.2.1 Flash with Information
7 6 5 4 3 2 1 0 Octet
= [000-111]
= [0000-1111]
3

Number Digit/End Mark m+1 = [0000-1111] Number Digit/End Mark m = [0000-1111] n
Signal value = [00H-FFH] (refer to 4.2.42) 2
[00,01,10]
(med, high, low)
3
3
4
(LSB) 5

(LSB) k
TIA-2001.4-C
Section 3 110
3.2.1 Flash with Information
7 6 5 4 3 2 1 0 Octet
Length = [01H] 2
Reserved = [0000 00] MOPD
= [0,1]
GECI =
[1]
3
Length = [01H] 2
[001 - 110]
3
1
TIA-2001.4-C
111 Section 3
3.2.2 Flash with Information Ack 1
This DTAP message is sent from the BS to the MSC to indicate that a Layer 2 Ack to a 2
Flash with Information message has been received from the MS. 3
Reference
Element
Direction
Type
a
R
b
C
a. This information element contains the Tag value received from the MSC in the Flash 4
With Information message. 5
The following table shows the bitmap layout for the Flash with Information Ack 7
message. 8
3.2.2 Flash with Information Ack
7 6 5 4 3 2 1 0 Octet
Length Indicator (LI) = [08H, 0BH] 3
3
4
(LSB) 5
Length = [01H] 2
[001 - 110]
3
9
10
TIA-2001.4-C
Section 3 112
3.2.3 Feature Notification 1
This BSMAP message is sent from the MSC to the BS and currently is used for message 2
waiting indication. 3
Reference
Element
Direction
Type

f
C
a
C
b, e
C
c, e
C
d,
C
e, h
C
f
C
a. This element uniquely identifies cells within a BS, therefore it is a variable length 4
element dependent on the number of cells that need to be identified. This element is 5
only useful for multi-cell BSs. 6
b. This element is included when slotted paging is performed on the paging channels. It 7
is used by the BS to compute the correct paging channel slot on each paging channel 8
in the cdma2000
system. If this element is absent, then it is assumed that the MS is 9

operating in non-slotted mode. 10
c. The Signal information element is retained in this message for the purpose of 11
backward compatibility. 12
d. This element carries MS Information Records. It shall not redundantly carry 13
e. This element shall not be included by the MSC when the BS and MS are operating in 15
DS-41 mode. 16
f. This element contains the MSs MOB_P_REV of the current band class and shall be 17
g. The MSC includes this element to request an acknowledgement from the BS that the 19
corresponding air interface message was received by the MS. 20
h. If the MSC does not have the information required to correctly populate a field in 21
The following table shows the bitmap layout for the Feature Notification message. 23
3.2.3 Feature Notification
7 6 5 4 3 2 1 0 Octet
TIA-2001.4-C
113 Section 3
7 6 5 4 3 2 1 0 Octet
Indicator
= [1,0]
Type of Identity
= [110] (IMSI)
3

3
4
(LSB) 5
Sector = [0H-FH] (0H =
Omni)
(LSB) j+1
(MSB) LAC = [00 01H-FF FFH] j
(LSB) j+1
Signal value = [00H-FFH] (refer to 4.2.42) 2
[00,01,10]
(med, high, low)
3
TIA-2001.4-C
Section 3 114
7 6 5 4 3 2 1 0 Octet

(LSB) k
Reserved
= [00]
ERAM
Supported =
[0,1]
DCCH
Supported
= [0,1]
FCH
Supported
= [0,1]
OTD
Supported
= [0,1]
Enhanced
RC CFG
Supported
= [0,1]
QPCH
Supported
= [0,1]
3
= [00H to FFH]
4
Reserved
= [0]
value> (Ignored)
Geo
Location
Included
= <any
value>
(Ignored)
FCH Information:
= [000 to 111]
5
(MSB) 6
= <any value>

Seventh
Fill Bit
if needed
= [0 (if
used as a
fill bit)]
Sixth Fill
Bit if
needed
= [0 (if
used as a
fill bit)]
Fifth Fill
Bit if
needed
= [0 (if
used as a
fill bit)]
Fourth
Fill Bit
if needed
= [0 (if
used as a
fill bit)]
Third
Fill Bit
if needed
= [0 (if
used as a
fill bit)]
Second
Fill Bit
if needed
= [0 (if
used as a
fill bit)]
First Fill
Bit if
needed
= [0 (if
used as a
fill bit)]
k
= [00H to FFH]
k+1
Reserved
= [0000 0]
DCCH Information:
= [000 to 111]
k+2
(MSB) k+3
= <any value>

Seventh
Fill Bit
if needed
= [0 (if
used as a
fill bit)]
Sixth Fill
Bit if
needed
= [0 (if
used as a
fill bit)]
Fifth Fill
Bit if
needed
= [0 (if
used as a
fill bit)]
Fourth
Fill Bit
if needed
= [0 (if
used as a
fill bit)]
Third
Fill Bit
if needed
= [0 (if
used as a
fill bit)]
Second
Fill Bit
if needed
= [0 (if
used as a
fill bit)]
First Fill
Bit if
needed
= [0 (if
used as a
fill bit)]
m
Length = [01H] 2
TIA-2001.4-C
115 Section 3
7 6 5 4 3 2 1 0 Octet
1
TIA-2001.4-C
Section 3 116
3.2.4 Feature Notification Ack 1
This BSMAP message is sent from the BS to the MSC in response to Feature Notification 2
message. 3
Reference
Element
Direction
Type

a
R
The following table shows the bitmap layout for the Feature Notification Ack message. 4
a. This information element contains the Tag value received from the MSC in the 5
Feature Notification message. 6
3.2.4 Feature Notification Ack
7 6 5 4 3 2 1 0 Octet
Indicator
= [1,0]
Type of Identity
= [110] (IMSI)
3

3
4
(LSB) 5
7
8
TIA-2001.4-C
117 Section 3
3.2.5 PACA Command 1
This BSMAP message is sent from the MSC to the BS. This message is used to indicate 2
that the BS is to apply PACA service to the call. The MSC sends this message to convey 3
the PACA information (e.g., priority and PACA time stamp) to the BS. 4
Reference
Element
Direction
Type
Priority 4.2.15 MSC -> BS O R
PACA Timestamp 4.2.71 MSC -> BS O R
5
The following table shows the bitmap layout for the PACA Command message. 6
3.2.5 PACA Command
7 6 5 4 3 2 1 0 Octet
Length Indicator (LI) = [0AH] 2
! !! ! Message Type = [6CH] 1
Length = [01H] 2
Allowed
= [0,1]
Preemption
Allowed
= [0,1]
3
! !! ! PACA Timestamp: A1 Element Identifier = [4EH] 1
Length = [04H] 2
(MSB) PACA Queuing Time = <any value> 3
4
5
(LSB) 6
7
8
TIA-2001.4-C
Section 3 118
3.2.6 PACA Command Ack 1
This BSMAP message is sent from the BS to the MSC to acknowledge that the PACA 2
Command message was received and appropriate action was taken by the BS. 3
Reference
Element
Direction
Type
Cause 4.2.16 BS -> MSC O
a
C
a. This cause value is included if the BS was unable to queue the call. 4
The following table shows the bitmap layout for the PACA Command Ack message. 5
3.2.6 PACA Command Ack
7 6 5 4 3 2 1 0 Octet
! !! ! Message Type = [6DH] 1
Length = [01H] 2
ext = [0] Cause Value = [2DH (PACA queue overflow)] 3
6
7
TIA-2001.4-C
119 Section 3
3.2.7 PACA Update 1
This BSMAP message is sent, from either the BS or the MSC, to indicate that the BS 2
(MSC) intends to modify the queued call. The MSC sends this message to cancel the call, 3
to remove the previous request (the request associated with the first called number when 4
the MS makes consecutive PACA calls) or to instruct the source BS (cell) to remove the 5
request from its PACA queue when an idle handoff has occurred. The BS sends this 6
message to the MSC to cancel the call. The BS can either send this message 7
autonomously or send it when it receives a PACA cancellation request from the MS. 8
Reference
Element
Direction
Type
Mobile Identity (IMSI) 4.2.13 BS <-> MSC O R
a
C
PACA Order 4.2.72 BS <-> MSC O R
Priority 4.2.15 BS <- MSC O
b
C
c
C
c
C
c
C
d
C

e
C

a. This element is included in the message if the ESN is received from the MS. 9
b. This element is included in the message if the MSC is modifying the priority of a 10
queued call. 11
c. This element is included in the message if it is received from the MS. 12
d. This element is included when broadcast authentication is performed, and contains 13
e. This element is present when an authentication enabled BS does not receive the 17
RAND/RANDC mismatch has occurred, or if authentication was recently requested 19
and a new authentication is not required. 20
21
22
TIA-2001.4-C
Section 3 120
The following table shows the bitmap layout for the PACA Update message. 1
3.2.7 PACA Update
7 6 5 4 3 2 1 0 Octet
! !! ! Message Type = [6EH] 1
Indicator
= [1,0]
Type of Identity
= [110] (IMSI)
3

Length = [05H] 2
Indicator
= [0]
Type of Identity
= [101] (ESN)
3
5
6
(LSB) 7
! !! ! PACA Order: A1 Element Identifier = [5FH] 1
Length = [01H] 2
Reserved = [0000 0] PACA Action Required
= [000 101]
3
Length = [01H] 2
Allowed
= [0,1]
Preemption
Allowed
= [0,1]
3
Length = [04H] 2
= [0] = [0] = [0] = [0] = [0] = [0] (MSB) 4
(LSB) 6
TIA-2001.4-C
121 Section 3
3.2.7 PACA Update
7 6 5 4 3 2 1 0 Octet
1
RANDC = [00H-FFH] 2
Reserved = [00] Count = [00 0000-11 1111] 2
Length = [05H] 2
5
6
(LSB) 7
Length = [01H] 2
Event = [01H, 02H]
3
1
TIA-2001.4-C
Section 3 122
3.2.8 PACA Update Ack 1
This BSMAP message is sent in either direction between the BS and the MSC to 2
acknowledge that the PACA Update message was received and processed. 3
Reference
Element
Direction
Type
Mobile Identity (IMSI) 4.2.13 BS <-> MSC O R
Priority 4.2.15 BS <- MSC O
a
C
b
C
a. Indicates the new priority to be applied to the queued call if the priority is to be 4
changed. 5
b. This information element is included when the PACA update procedure fails. 6
The following table shows the bitmap layout for the PACA Update Ack message. 7
3.2.8 PACA Update Ack
7 6 5 4 3 2 1 0 Octet
! !! ! Message Type = [6FH] 1
Indicator
= [1,0]
Type of Identity
= [110] (IMSI)
3

Length = [01H] 2
Allowed
= [0,1]
Preemption
Allowed
= [0,1]
3
Length = [01H] 2
ext = [0] Cause Value = [0CH (No response from MS),
2DH (PACA queue overflow),
2EH (PACA cancel request rejected)]
3
TIA-2001.4-C
123 Section 3
3.2.9 Radio Measurements for Position Request 1
This BSMAP message is sent from the MSC to the BS to request that specific radio 2
interface measurements be gathered or the geographic location determined with respect to 3
a given MS that is on a traffic channel. 4

Information Element
Section
Reference
Element
Direction
Type
Message Type 4.2.4 MSC->BS M
PSMM Count 4.2.67 MSC->BS O
a
R
a. If the value of the PSMM Count field is greater than zero, this is the number of Pilot 5
Strength Measurement Messages (PSMMs) (refer to [5]) the PDE is requesting the 6
BS to send. If the value is zero, the BS is requested to provide geographic location 7
instead of the requested measurements to the MSC. 8
The following table shows the bitmap layout for the Radio Measurements for Position 9
Request message. 10
3.2.9 Radio Measurements for Position Request
7 6 5 4 3 2 1 0 Octet
! !! ! PSMM Count A1 Element Identifier = [2DH] 1
Length=[01H] 2
Reserved = [0H] PSMM Count = [0000-1010] 3
11
TIA-2001.4-C
Section 3 124
3.2.10 Radio Measurements for Position Response 1
This BSMAP message is sent from the BS to the MSC to provide the geographic location 2
or the specific radio interface measurements that have been gathered with respect to a 3
given MS that is on a traffic channel. These measurements are input to position 4
determination calculations. 5

Information Element
Section
Reference
Element
Direction
Type
a
C
Downlink Radio Environment List 4.2.69 BS -> MSC O
b,f
C
c
C
Geographic Location 4.2.68 BS -> MSC O
d,e
C
a. If the PSMM count is zero in the Radio Measurements for Position Request message 6
and the BS is not capable of determining the geographic location, then the BS shall 7
return the CDMA Serving One Way Delay. The CDMA Serving One Way Delay is 8
included at most once. 9
b. The Downlink Radio Environment List contains one entry for each PSMM received. 10
Each entry contains pilots from the active and candidate list.. All occurrences of the 11
Downlink Radio Environment List entries are populated in the order in which the BS 12
receives the related PSMMs from the MS. 13
c. When present, this element indicates some level of failure to provide one or more of 14
the requested radio interface measurements. This element is not included when the 15
Geographic Location IE is present. 16
d. If the BS is capable of determining the geographic location the BS may send the 17
geographic location instead of the requested measurements to the MSC. 18
e. This element is not present if the Downlink Radio Environment List is present. 19
f. This element is not present if Geographic Location is present. 20
21
22
TIA-2001.4-C
125 Section 3
The following table shows the bitmap layout for the Radio Measurements for Position 1
Response message. 2
3.2.10 Radio Measurements for Position Response
7 6 5 4 3 2 1 0 Octet
(MSB) MSCID = <any value> 4
5
(LSB) 6
Omni)
(LSB) 8
(MSB) CDMA Serving One Way Delay = [0000H-FFFFH] 9
(LSB) 10
Reserved = [0000 00] Resolution = [00,
01, 10]
11
(MSB) CDMA Serving One Way Delay Time Stamp = [00 00H FF FFH] 12
(LSB) 13
! !! ! Downlink Radio Environment List: A1 Element Identifier = [2BH] 1
Downlink Radio Environment List entry {1+:
Length = <variable> i
Number of Cells = <variable> i+1
Cell Identification Discriminator = [02H,07H] i+2
Downlink Radio Environment entry{1+:
I F (Discriminator =02H), Cell I dentification {1
Omni)
(LSB) j+1
j+1
(LSB) j+2
TIA-2001.4-C
Section 3 126
3.2.10 Radio Measurements for Position Response
7 6 5 4 3 2 1 0 Octet
Omni)
(LSB) j+4
Reserved = [00] Downlink Signal Strength Raw = [00 0000 - 11 1111] k
(MSB) CDMA Target One Way Delay = [00 00H - FF FFH] (x100ns) k+1
(LSB) k+2
}Downlink Radio Environment entry
}Downlink Radio Environment List entry
Length = [01H] 2
ext = [0] Cause Value = [34H (MS rejected order),
45H (PLD-related capability not available
or not supported)]
3
! !! ! Geographic Location: A1 Element Identifier = [2CH] 1
(MSB) Calling Geodetic Location (CGL) = <any value> 3

(LSB) k
1
TIA-2001.4-C
127 Section 3
3.3 Mobility Management Message Formats 1
2
3.3.1 Authentication Request 3
This message is sent from the MSC to the BS and it is used to make an authentication 4
check on the MS. This is a DTAP message when used to perform authentication on a 5
voice/traffic channel and a BSMAP message otherwise. The RANDU information 6
element of this message is used by the MS to generate the AUTHU. 7
Reference
Element
Direction
Type
a

a

Authentication Challenge Parameter (RANDU) 4.2.37 MSC -> BS M
i

Mobile Identity (IMSI) 4.2.13 MSC -> BS O
b,c
C
c,d
C
c,e
C
c,f,g
C
c,g,j
C
h,c
C
a. This element is not used when the Authentication Request message is sent as a 8
BSMAP message. 9
b. This element contains the identity of the MS to which the Authentication Challenge 10
order is to be sent. It shall be included when the Authentication Challenge is to be 11
sent on the paging channel(s).. 12
c. This element is not used when the Authentication Request message is sent as a 13
DTAP message. 14
d. If this element is present in this message, the value shall be saved at the BS to be 15
included in an Authentication Response message if one is sent in response to this 16
message. 17
e. This element uniquely identifies cells within a BS from which the Authentication 18
Challenge is to be sent on paging channels. It is a variable length element dependent 19
on the number of cells that need to be identified. This element is only included when 20
the Authentication Challenge is to be sent on paging channel(s) and is only required 21
when a subset of the BSs cells shall be identified. 22
f. This element is included when slotted paging is performed on cdma2000
paging 23
channels. It is used by the BS to compute the correct paging channel slot on each 24
paging channel. In cdma2000
systems, if this element is absent, then it is assumed 25

that the MS is operating in non-slotted mode. 26
g. This element shall not be included by the MSC when the BS and MS are operating in 27
DS-41 mode. 28
h. This element contains the MSs MOB_P_REV of the current band class and shall be 29
TIA-2001.4-C
Section 3 128
i. When this information element is sent as a mandatory information element in a 1
j. If the MSC does not have the information required to correctly populate a field in 3
When the Authentication Request message is sent as a BSMAP message, the following 5
format applies. 6
3.3.1 Authentication Request
7 6 5 4 3 2 1 0 Octet
! !! ! Authentication Challenge Parameter (RANDU): A1 Element Identifier = [41H] 1
Length = [04H] 2
Reserved = [0000] Random Number Type = [0010] (RANDU) 3
(MSB) RANDU Value = <any value> 4
5
(LSB) 6
Indicator
= [1,0]
Type of Identity
= [110] (IMSI)
3

3
4
(LSB) 5
Omni)
(LSB) J+1
TIA-2001.4-C
129 Section 3
7 6 5 4 3 2 1 0 Octet
(LSB) j+1
Reserved
= [00]
ERAM
Supported =
[0,1]
(Ignored)
DCCH
Supported
= [0,1]
(Ignored)
FCH
Supported
= [0,1]
(Ignored)
OTD
Supported
= [0,1]
(Ignored)
Enhanced
RC CFG
Supported
= [0,1]
(Ignored)
QPCH
Supported
= [0,1]
3
= [00H]
4
Reserved
= [0]
Geo Location Type = [000, 001,
010, 011]
(Ignored)
Geo
Location
Included
= [0,1]
(Ignored)
FCH Information:
= [000]
5
= [00H]
6
Reserved
= [0000 0]
DCCH Information:
= [000]
7
Length = [01H] 2
1
TIA-2001.4-C
Section 3 130
When the Authentication Request message is sent as a DTAP message, the following 1
format applies. 2
7 6 5 4 3 2 1 0 Octet
! !! ! Authentication Challenge Parameter (RANDU): Length = [04H] 1
Reserved = [0000] Random Number Type = [0010] (RANDU) 2
(MSB) RANDU Value = <any value> 3
4
(LSB) 5
3
4
TIA-2001.4-C
131 Section 3
3.3.2 Authentication Response 1
This message is in response to the Authentication Request message and it is sent from the 2
BS to the MSC. This is a DTAP message when used to perform authentication on a 3
voice/traffic channel and a BSMAP message otherwise. The AUTHU is generated by the 4
MS using an algorithm and the RANDU which was sent through the Authentication 5
Request message. 6
Reference
Element
Direction
Type
a

a

Authentication Response Parameter (AUTHU) 4.2.38 BS -> MSC M
d

Mobile Identity (IMSI) 4.2.13 BS -> MSC O
b,c
C
c
C
c
C
a. This element is not used when the Authentication Response message is sent as a 7
BSMAP message. 8
b. This element contains the identity of the MS that sent the Authentication Challenge 9
Response. It shall be included when the Authentication Challenge Response was 10
received on an access channel. 11
c. This element is not used when the Authentication Response message is sent as a 12
DTAP message. 13
d. When this information element is sent as a mandatory information element in a 14
When the Authentication Response message is sent as a BSMAP message, the following 16
format applies. 17
3.3.2 Authentication Response
7 6 5 4 3 2 1 0 Octet
! !! ! Authentication Response Parameter (AUTHU): A1 Element Identifier = [42H] 1
Length = [04H] 2
Reserved = [0000] Auth Signature Type = [0010] (AUTHU) 3
[0] [0] [0] [0] [0] [0] (MSB) 4
(LSB) 6
TIA-2001.4-C
Section 3 132
7 6 5 4 3 2 1 0 Octet
Indicator
= [1,0]
Type of Identity
= [110] (IMSI)
3

3
4
(LSB) 5
Length = [05H] 2
Indicator
= [0]
Type of Identity
= [101] (ESN)
3
5
6
(LSB) 7
When the Authentication Response message is sent as a DTAP message, the following 1
format applies. 2
7 6 5 4 3 2 1 0 Octet
! !! ! Authentication Response Parameter (AUTHU): Length = [04H] 1
Reserved = [0000] Auth Signature Type = [0010] (AUTHU) 2
[0] [0] [0] [0] [0] [0] (MSB) 3
(LSB) 5
TIA-2001.4-C
133 Section 3
3.3.3 SSD Update Request 1
This DTAP message is sent from the MSC to the BS and is used to initiate the Shared 2
Secret Data update procedure at the MS. This message is used to perform the SSD 3
Update on a voice/traffic channel. The Authentication Challenge Parameter (RANDSSD) 4
information element of this message is used to generate the new SSD at the MS. 5
Reference
Element
Direction
Type


Authentication Challenge Parameter (RANDSSD) 4.2.37 MSC -> BS M
a

a. Because this information element is sent as a mandatory information element in a 6
The following table shows the bitmap layout for the SSD Update Request message. 8
3.3.3 SSD Update Request
7 6 5 4 3 2 1 0 Octet
Length Indicator (LI) = [0CH] 3
! !! ! Authentication Challenge Parameter (RANDSSD): Length = [08H] 1
Reserved = [0000] Random Number Type = [0100]
(RANDSSD)
2
(MSB) RANDSSD Value = <any value> 3
4
5
6
7
8
(LSB) 9
9
TIA-2001.4-C
Section 3 134
3.3.4 SSD Update Response 1
This DTAP message is used to complete the SSD Update procedure and is sent in 2
response to the Base Station Challenge Response message. This message is sent from the 3
BS to the MSC. This message is used to perform the SSD Update on a voice/traffic 4
channel. 5
Reference
Element
Direction
Type

Cause Layer 3 4.2.46 BS -> MSC O
a
C
a. This element indicates the failure of the SSD update operation at the MS. Absence of 6
this element indicates success of the SSD update operation at the MS. If the BS 7
receives an SSD update reject order from the MS, the BS shall set the Cause Layer 3 8
value to SSD update rejected. 9
The following table shows the bitmap layout for the SSD Update Response message. 10
3.3.4 SSD Update Response
7 6 5 4 3 2 1 0 Octet
Length = [02H] 2
= [00]
Reserved
= [0]
Location = [0100]
3
ext = [1] Cause Value = [000 1111 (Procedure failed),
011 1011 (SSD update rejected)]
4
11
12
TIA-2001.4-C
135 Section 3
3.3.5 Base Station Challenge 1
This DTAP message is in response to the SSD Update Request message and is sent from 2
the BS to the MSC. This message is used to perform the SSD Update on a voice/traffic 3
channel. The authentication parameter RANDBS information element of this message 4
contains the RANDBS and is used by the HLR/AC as input to the authentication 5
algorithm to verify the new Shared Secret Data. 6
Reference
Element
Direction
Type


Authentication Challenge Parameter (RANDBS) 4.2.37 BS -> MSC M
a

a. Because this information element is sent as a mandatory information element in a 7
The following table shows the bitmap layout for the Base Station Challenge message. 9
3.3.5 Base Station Challenge
7 6 5 4 3 2 1 0 Octet
! !! ! Authentication Challenge Parameter (RANDBS): Length = [05H] 1
Reserved = [0000] Random Number Type = [1000] (RANDBS) 2
(MSB) RANDBS Value = <any value> 3

(LSB) 6
10
11
TIA-2001.4-C
Section 3 136
3.3.6 Base Station Challenge Response 1
This DTAP message is in response to the Base Station Challenge message and is sent 2
from the MSC to the BS. This message is used to perform the SSD Update on a 3
voice/traffic channel. The AUTHBS is generated using an authentication algorithm, the 4
new SSD, and RANDBS, which was sent in the Base Station Challenge message. 5
Reference
Element
Direction
Type

Authentication Response Parameter (AUTHBS) 4.2.38 MSC -> BS M
a

a. Because this information element is sent as a mandatory information element in 6
DTAP message, the information element identifier is not included 7
The following table shows the bitmap layout for the Base Station Challenge Response 8
message. 9
3.3.6 Base Station Challenge Response
7 6 5 4 3 2 1 0 Octet
! !! ! Authentication Response Parameter (AUTHBS): Length = [04H] 1
Reserved = [0000] Auth Signature Type = [0100] (AUTHBS) 2
[0] [0] [0] [0] [0] [0] (MSB) 3
(LSB) 5
10
11
TIA-2001.4-C
137 Section 3
3.3.7 Location Updating Request 1
This DTAP message is sent by the BS to the MSC to request an update to the MSs 2
location area (registration) when the MS moves to a new location from its previous 3
location. 4
Reference
Element
Direction
Type
i

a, i, m
Classmark Information Type 2 4.2.12 BS -> MSC O
b, i, k
R
Registration Type 4.2.49 BS -> MSC O
i
R
c
C
d, l
C
e
C
f
C
o
C
g
C
h
C
o
C

j, l, p
C
Return Cause 4.2.87 BS -> MSC O
n
C
a. This element contains an IMSI. 5
b. If an MS is capable of supporting multiple band classes, and this information is 6
available at the BS, it shall be indicated in the Band Class Entry field as shown in 7
section 4.2.12. 8
c. This element is present in cdma2000
systems when the ESN is received from the 9

MS. 10
d. The slot cycle index is included when provided by the MS. 11
e. This element contains the authentication response signature (AUTHR) received from 12
an authentication capable MS when broadcast authentication is active. 13
f. This element contains the RANDC received from the MS. RANDC shall be included 14
g. This element is included when broadcast authentication is performed, and contains 16
h. This element is present when an authentication enabled BS does not receive the 20
i. If any of these elements are not correctly present, call failure handling may be 23
TIA-2001.4-C
Section 3 138
j. This element is only included when the MS operates at revision level 6 or greater as 1
k. When the BS is operating in DS-41 mode, only the following fields in the Classmark 3
l. These elements shall not be included by the BS when the BS and MS are operating 8
in DS-41 mode. 9
m. Because this information element is sent as a mandatory information element in a 10
n. This element is included if the MS re-sends the Registration Message with Return 12
Cause to the BS because it failed to be redirected to the desired system. 13
o. This information element is included if the necessary information was received from 14
the MS. 15
p. If the BS does not have the information required to correctly populate a field in this 16
The following message layout contains the Complete Layer 3 Info message encapsulating 18
the Location Updating Request message. Refer to section 3.1.1. 19
3.3.7 Location Updating Request
7 6 5 4 3 2 1 0 Octet
Length = [03H] 2
Omni)
(LSB) 5
Length = <variable>
2
Indicator
= [1,0]
Type of Identity
= [110] (IMSI)
2
TIA-2001.4-C
139 Section 3
7 6 5 4 3 2 1 0 Octet

! !! ! Classmark Information Type 2: A1 Element Identifier = [12H] 1
MOB_P_REV
= [000 111]
Reserved
= [0]
See List
of
Entries =
[0, 1]

3
Reserved = [00H] 4
NAR_
AN_
CAP
= [0,1]
IS-95
= [1]
Slotted
= [0,1]
Reserved = [00]

DTX
= [0,1]
(ignored)
Mobile
Term
= [0,1]
TIA/EIA-
553
= [0,1]
5
Reserved = [00H] 6

Mobile
Term
= [0,1]
PSI
= [0,1]
7
! !! ! Registration Type: A1 Element Identifier = [1FH] 1
Location Registration Type =
[00H (timer-based),
01H (power-up),
02H (zone-based),
03H (power-down),
04H (parameter change)
05H (ordered),
06H (distance-based)
07H (user zone based)]
2
TIA-2001.4-C
Section 3 140
7 6 5 4 3 2 1 0 Octet
Length = [05H] 2
Indicator
= [0]
Type of Identity
= [101] (ESN)
3
5
6
(LSB) 7
Length = [04H] 2
[0] [0] [0] [0] [0] [0] (MSB) 4
(LSB) 6
1
RANDC = [00H-FFH] 2
Reserved = [00] Count = [000000-111111] 2
Length = [05H] 2
5
6
(LSB) 7
Length = [01H] 2
Event = [01H (Parameters not received),
02H (RANDC/RAND mismatch)]
3
Length = [02H] 2
(LSB) 4
TIA-2001.4-C
141 Section 3
7 6 5 4 3 2 1 0 Octet
Reserved
= [00]
ERAM
Supported =
[0,1]
(Ignored)
DCCH
Supported
= [0,1]
(Ignored)
FCH
Supported
= [0,1]
(Ignored)
OTD
Supported
= [0,1]
Enhanced
RC CFG
Supported
= [0,1]
QPCH
Supported
= [0,1]
3
= [00H]
4
Reserved
= [0]
010, 011]
Geo
Location
Included
= [0,1]
FCH Information:
= [000]
5
= [00H]
6
Reserved
= [0000 0]
DCCH Information:
= [000]
7
! !! ! Return Cause: A1 Element Identifier = [68H] 1
Reserved = [0000] Return_Cause

= [0001 (Service redirection failed as a result
of system not found),
0010 (Service redirection failed as a result of
protocol mismatch),
registration rejection),
wrong SID),
wrong NID)]
2
1
TIA-2001.4-C
Section 3 142
3.3.8 Location Updating Accept 1
This DTAP message is sent from MSC to BS to acknowledge that the MSC received and 2
accepted the Location Updating Request from the BS. 3
Reference
Element
Direction
Type
a
C
b
C
a. This element is included in this message when a MS hosting a dormant packet data 4
session powers down. 5
b. This element contains the MSs MOB_P_REV of the current band class and shall be 6
The following table shows the bitmap layout for the Location Updating Accept message. 8
3.3.8 Location Updating Accept
7 6 5 4 3 2 1 0 Octet
Length = [01H] 2
Ext= [0] Cause Value = [19H] (Power down from dormant state) 3
Length = [01H] 2
9
10
TIA-2001.4-C
143 Section 3
3.3.9 Location Updating Reject 1
This DTAP message is sent by the MSC to the BS to indicate that updating has failed. 2
This message is optional. 3
Reference
Element
Direction
Type
Reject Cause 4.2.36 MSC -> BS M
a

b
C
a. Because this information element is sent as a mandatory information element in 4
b. This element contains the MSs MOB_P_REV of the current band class and shall be 6
The following table shows the bitmap layout for the Location Updating Reject message. 8
3.3.9 Location Updating Reject
7 6 5 4 3 2 1 0 Octet
! !! ! Reject Cause =
[03H (Illegal MS),
0BH (Roaming not allowed),
51H (Network failure),
56H (Congestion)]
1
Length = [01H] 2
9
10
TIA-2001.4-C
Section 3 144
3.3.10 Parameter Update Request 1
This DTAP message is sent from the MSC to the BS to increment the call history count 2
in the MS. 3
Reference
Direction Type
Protocol Discriminator 4.2.32 MSC-> BS M
Reserved Octet 4.2.33 MSC-> BS M
Message Type 4.2.4 MSC-> BS M
The following table shows the bitmap layout for the Parameter Update Request message. 4
3.3.10 Parameter Update Request
7 6 5 4 3 2 1 0 Octet
5
6
TIA-2001.4-C
145 Section 3
3.3.11 Parameter Update Confirm 1
This DTAP message is sent from the BS to the MSC in response to a Parameter Update 2
Request message. This message is sent when the BS receives a positive indication from 3
the MS that it incremented its call history count. 4
Reference
Direction Type
Protocol Discriminator 4.2.32 BS-> MSC M
Reserved Octet 4.2.33 BS-> MSC M
Message Type 4.2.4 BS-> MSC M
The following table shows the bitmap layout for the Parameter Update Confirm message. 5
3.3.11 Parameter Update Confirm
7 6 5 4 3 2 1 0 Octet
! !! ! Message Type = [2BH] 1
6
7
TIA-2001.4-C
Section 3 146
3.3.12 Privacy Mode Command 1
This BSMAP message is sent from the MSC to the BS to enable or disable signaling 2
message encryption or Voice Privacy mode. 3
Reference
Element
Direction
Type
Encryption Information 4.2.10 MSC -> BS M

The following table shows the bitmap layout for the Privacy Mode Command message. 4
3.3.12 Privacy Mode Command
7 6 5 4 3 2 1 0 Octet
I F (Encryption Parameter I dentifier =00001, 00101, or 00110), Encryption I nfo {1:
[00001 (SME),
Status
= [0,1]
Available
= [0]
j
Encryption Parameter Length = [04H, 08H] j+1
(MSB) Encryption Parameter value j+2
(LSB) j+k
}OR I F (Encryption Parameter I dentifier =00100), Encryption I nfo {1:
(Private Longcode)
Status
= [0,1]
Available
= [0]
j
Unused = [000000] (MSB) j+2
Encryption Parameter value j+3
j+4
j+5
j+6
(LSB) j+7
}Encryption I nfo
5
6
TIA-2001.4-C
147 Section 3
3.3.13 Privacy Mode Complete 1
This BSMAP message is sent from the BS to the MSC to acknowledge the Privacy Mode 2
Command, to indicate a change in the Voice Privacy mode setting, or to indicate that the 3
MS has requested Voice Privacy. 4
Reference
Element
Direction
Type
a
C
b
C
a. This element is used to indicate Voice Privacy mode changes when this message is 5
sent autonomously by the BS. 6
b. This element is used to indicate that Voice Privacy was requested by the MS, but 7
could not be provided by the BS. 8
Note: Encryption Information and voice privacy elements are mutually exclusive. The 9
Encryption Information element is used to indicate a change in Encryption 10
Information at the BS. The Voice Privacy Request element is used by the BS to 11
request the encryption keys. 12
The following table shows the bitmap layout for the Privacy Mode Complete message. 13
3.3.13 Privacy Mode Complete
7 6 5 4 3 2 1 0 Octet
Length = [02H,04H] 2
ext = [1] Encryption Parameter Identifier = [00001,00100]
(SME, Private Longcode)
Status
= [0,1]
Available
= [0,1]
j
}Encryption I nfo
14
TIA-2001.4-C
Section 3 148
3.3.14 Status Request 1
This message is sent from the MSC to the BS to request that the MS report certain MS 2
programmable and static parameters such as call mode, roaming and security setting, 3
terminal information etc. This is a DTAP message when used to perform the Status 4
Request on a traffic channel and a BSMAP message otherwise. 5
This message shall not be used for DS-41 operation. 6
Reference
Element
Direction
Type
a

a

Message Type 4.2.4 MSC -> BS
M

Information Record Requested 4.2.81 MSC -> BS
M
e
Mobile Identity (IMSI) 4.2.13 MSC -> BS
O
b
C
Mobile Identity (ESN) 4.2.13 MSC -> BS
O
b
C
Slot Cycle Index 4.2.14 MSC -> BS
O
b,c
C
Cell Identifier List 4.2.18 MSC -> BS
O
b
C
b, f
C
b,d
C
a. This element is not used when the Status Request message is sent as a BSMAP 7
message. 8
b. These elements are used only in BSMAP messages. 9
c. This element is included where slotted paging is performed on cdma2000
paging 10
paging channel. If this element is absent, then it is assumed that the MS is operating 12
in non-slotted mode. 13
d. This element contains the MSs MOB_P_REV of the current band class and shall be 14
e. When this information element is sent as a mandatory information element in DTAP 16
message, the information element identifier is not included. The Information Record 17
Type field shall be coded as specified in [5]. 18
f. If the MSC does not have the information required to correctly populate a field in 19
21
TIA-2001.4-C
149 Section 3
When the Status Request message is sent as a BSMAP message, the following format 1
applies. 2
3.3.14 Status Request
7 6 5 4 3 2 1 0 Octet
! !! ! Information Record Requested: A1 Element Identifier = [2EH] 1
I nformation Record requested: {1+:
Information Record Type = <any value> j
}information Record Requested

Indicator
= [1,0]
Type of Identity
= [110] (IMSI)
3

Length = [05H] 2
Indicator
= [0]
Type of Identity
= [101] (ESN)
3
5
6
(LSB) 7
Reserved = [0 0000] Slot Cycle Index = [000-111] 2
TIA-2001.4-C
Section 3 150
7 6 5 4 3 2 1 0 Octet
Omni)
(LSB) j+1
(LSB) j+1
! !! ! IS-2000 Mobile Capabilities: A1 Element Identifier = [11H] 1
Reserved
= [00]
ERAM
Supported =
[0,1]
DCCH
Supported
= [0,1]
(Ignored)
FCH
Supported
= [0,1]
(Ignored)
OTD
Supported
= [0,1]
Enhanced
RC CFG
Supported
= [0,1]
QPCH
Supported
= [0,1]
3
= [00H]
4
Reserved
= [0]
010, 011]
Geo
Location
Included
= [0,1]
FCH Information:
= [000]
5
= [00H]
6
Reserved
= [0000 0]
DCCH Information:
= [000]
7
Length = [01H] 2
1
TIA-2001.4-C
151 Section 3
When the Status Request message is sent as a DTAP message, the following format 1
applies. 2
7 6 5 4 3 2 1 0 Octet
! !! ! Information Record Requested: Length = [01H] 1
Information Record Types = [0DH (ESN)] 2
3
4
TIA-2001.4-C
Section 3 152
3.3.15 Status Response 1
This message is sent from the BS to the MSC when the MS reports certain parameters to 2
the network. This message is the response to the Status Request message. This is a DTAP 3
message when the Status Response Message is received on a traffic channel and a 4
BSMAP message otherwise. 5
This message shall not be used for DS-41 operation. 6
Reference
Element
Direction
Type
a

a

Message Type 4.2.4 BS -> MSC
M

MS Information Records 4.2.59 BS -> MSC
M
b
c

C
c

C
a. This element is not used when the Status Request message is sent as a BSMAP 7
message. 8
b. When this information element is sent as a mandatory information element in DTAP 9
message, the information element identifier is not included. 10
c. These elements are only used in BSMAP messages. 11
When the Status Response message is sent as a BSMAP message, the following format 12
applies. 13
3.3.15 Status Response
7 6 5 4 3 2 1 0 Octet

(LSB) k
TIA-2001.4-C
153 Section 3
7 6 5 4 3 2 1 0 Octet
Indicator
= [1,0]
Type of Identity
= [110] (IMSI)
3

Length = [05H] 2
Indicator
= [0]
Type of Identity
= [101] (ESN)
3
5
6
(LSB) 7
1
When the Status Response message is sent as a DTAP message, the following format 2
applies. 3
7 6 5 4 3 2 1 0 Octet
! !! ! MS Information Records: Length = [01H-FFH] 1

(LSB) k
TIA-2001.4-C
Section 3 154
3.3.16 User Zone Update Request 1
This DTAP message is sent from the BS to the MSC to indicate that the MS has sent a 2
User Zone Update Request message to change its User Zone. 3
Reference
Element
Direction
Type
a
R
a. This element indicates the User Zone proposed by the MS. 4
The following table shows the bitmap layout for the User Zone Update Request message: 5
3.3.16 User Zone Update Request
7 6 5 4 3 2 1 0 Octet
! !! ! Message Type = [0DH] 1
Length = [02H] 2
(LSB) 4
6
7
TIA-2001.4-C
155 Section 3
3.3.17 User Zone Update 1
This DTAP message is sent from the MSC to the BS when the MSC is updating the User 2
Zone being used by the MS. 3
Reference
Element
Direction
Type
User Zone ID 4.2.26 MSC -> BS O
a
R
a. This element indicates the User Zone proposed by the MSC. 4
The following table shows the bitmap layout for the User Zone Update message: 5
3.3.17 User Zone Update
7 6 5 4 3 2 1 0 Octet
! !! ! User Zone ID: A1 Element identifier = [02H] 1
Length = [02H] 2
(LSB) 4
6
7
TIA-2001.4-C
Section 3 156
3.3.18 User Zone Reject 1
This message is sent from the MSC to the BS to indicate that the MSC has rejected the 2
User Zone indicated by the MS. The MSC may choose to include an alternate User Zone 3
in this message. This is a BSMAP message when sent on a Paging Channel and a DTAP 4
message otherwise. 5
6
Reference
Element
Direction
Type
Protocol Discriminator 4.2.32 MSC -> BS
M
a

Reserved Octet 4.2.33 MSC -> BS
M
a

User Zone ID 4.2.26 MSC -> BS O
f
C
b,c
C
c,d
C
c,e,g
C
c,g,i
C
h,c
C
a. These elements are not used when the User Zone Reject message is sent as a 7
BSMAP message. 8
b. This element contains the identity of the MS to which the User Zone Reject is to be 9
sent. It shall be included when the User Zone Reject is to be sent on the paging 10
channel(s). 11
c. These elements are not used when the User Zone Reject is sent as a DTAP message. 12
d. This element is only required for multi-cell BSs. Uniquely identifies cells within a 13
BS. 14
e. This element is included when slotted paging is performed on paging channels. It is 15
used by the BS to compute the correct paging channel slot on each paging channel. If 16
this element is absent, then it is assumed that the MS is operating in non-slotted 17
mode. 18
f. The MSC shall include this element if it is proposing an alternate User Zone to be 19
used by the MS. 20
g. These elements shall not be included by the MSC when the BS and MS are operating 21
in DS-41 mode. 22
h. This element contains the MSs MOB_P_REV of the current band class and shall be 23
i. If the MSC does not have the information required to correctly populate a field in 25
27
28
TIA-2001.4-C
157 Section 3
When the User Zone Reject message is sent as a BSMAP message, the following format 1
applies. 2
3.3.18 User Zone Reject
7 6 5 4 3 2 1 0 Octet
Length = [02H] 2
(LSB) 4
Indicator
= [1,0]
Type of Identity
= [110] (IMSI)
3

Omni)
(LSB
)
j+1
(LSB) j+1
Reserved
= [00]
ERAM
Supported =
[0,1]
DCCH
Supported
= [0,1]
FCH
Supported
= [0,1]
OTD
Supported
= [0,1]
Enhanced
RC CFG
Supported
= [0,1]
QPCH
Supported
= [0,1]
3
TIA-2001.4-C
Section 3 158
7 6 5 4 3 2 1 0 Octet
= [00H to FFH]
4
Reserved
= [0]
010, 011]
Geo
Location
Included
= [0,1]
FCH Information:
= [000 to 111]
5
(MSB) 6
= <any value>

Seventh
Fill Bit
if needed
= [0 (if
used as a
fill bit)]
Sixth Fill
Bit if
needed
= [0 (if
used as a
fill bit)]
Fifth Fill
Bit if
needed
= [0 (if
used as a
fill bit)]
Fourth
Fill Bit
if needed
= [0 (if
used as a
fill bit)]
Third
Fill Bit
if needed
= [0 (if
used as a
fill bit)]
Second
Fill Bit
if needed
= [0 (if
used as a
fill bit)]
First Fill
Bit if
needed
= [0 (if
used as a
fill bit)]
k
= [00H to FFH]
k+1
(MSB)
6
= <any value>

Seventh
Fill Bit
if needed
= [0 (if
used as a
fill bit)]
Sixth Fill
Bit if
needed
= [0 (if
used as a
fill bit)]
Fifth Fill
Bit if
needed
= [0 (if
used as a
fill bit)]
Fourth
Fill Bit
if needed
= [0 (if
used as a
fill bit)]
Third
Fill Bit
if needed
= [0 (if
used as a
fill bit)]
Second
Fill Bit
if needed
= [0 (if
used as a
fill bit)]
First Fill
Bit if
needed
= [0 (if
used as a
fill bit)]
M
Length = [01H] 2
1
TIA-2001.4-C
159 Section 3
When the User Zone Reject message is sent as a DTAP message, the following format 1
applies. 2
7 6 5 4 3 2 1 0 Octet
Length = [02H] 2
(LSB) 4
3
4
TIA-2001.4-C
Section 3 160
3.3.19 Registration Request 1
This BSMAP message is sent from the MSC to the BS to initiate ordered registration 2
with the MS. 3
Reference
Element
Direction
Type
Mobile Identity (IMSI/ESN) 4.2.13 MSC -> BS M
a
b
C
c,d
C

e
C
f
C
a. This element shall be set to the ESN when the BS and MS are operating in DS-41 4
mode and IMSI otherwise. 5
b. One or more cell identifiers may be included to indicate which cells within the BS 6
shall send the Registration Request Order upon receipt of a single Registration 7
Request message from the MSC. If this element is not included in the message, all 8
cells within the BS shall send the Registration Request order. 9
c. This element is included where slotted paging is performed on the paging channels. 10
It is used by the BS to compute the correct paging channel slot on each paging 11
channel. If this element is absent, then it is assumed that the MS is operating in non- 12
slotted mode. 13
d. This element shall not be included by the MSC when the BS and MS are operating in 14
DS-41 mode. 15
e. This element contains the MSs MOB_P_REV of the current band class and shall be 16
f. If the MSC does not have the information required to correctly populate a field in 18
The following table shows the bitmap layout for the Registration Request message. 20
3.3.19 Registration Request
7 6 5 4 3 2 1 0 Octet
Message Type = [05H] 1
! !! ! Mobile Identity (IMSI/ESN): A1 Element Identifier = [0DH] 1
Identity Digit 1 = [0H-9H] (BCD),
[0H] (ESN)
Odd/even
Indicator
= [1,0]
Type of Identity
= [101 (ESN),110 (IMSI)]
3
I F(Type of I dentity =101), Identity {1:
TIA-2001.4-C
161 Section 3
7 6 5 4 3 2 1 0 Octet
5
6
(LSB) 7
}OR I F (Type of I dentity =110), I dentity {1:

}Type of I dentity
Omni)
(LSB) j+1
(LSB) j+1
Length = [01H] 2
Reserved
= [00]
ERAM
Supported
= [0,1]
DCCH
Supported
= [0,1]
FCH
Supported
= [0,1]
OTD
Supported
= [0,1]
Enhanced
RC CFG
Supported
= [0,1]
QPCH
Supported
= [0,1]
3
= [00H to FFH]
4
Reserved
= [0]
value> (Ignored)
Geo
Location
Included
= <any
value>
(Ignored)
FCH Information:
= [000 to 111]
5
TIA-2001.4-C
Section 3 162
7 6 5 4 3 2 1 0 Octet
(MSB) 6
= <any value>

Seventh
Fill Bit
if needed
= [0 (if
used as a
fill bit)]
Sixth
Fill Bit
if needed
= [0 (if
used as a
fill bit)]
Fifth Fill
Bit if
needed
= [0 (if
used as a
fill bit)]
Fourth
Fill Bit
if needed
= [0 (if
used as a
fill bit)]
Third Fill
Bit if
needed
= [0 (if
used as a
fill bit)]
Second
Fill Bit
if needed
= [0 (if
used as a
fill bit)]
First Fill
Bit if
needed
= [0 (if
used as a
fill bit)]
k
= [00H to FFH]
k+1
Reserved
= [0000 0]
DCCH Information:
= [000 to 111]
k+2
(MSB) k+3
= <any value>

Seventh
Fill Bit
if needed
= [0 (if
used as a
fill bit)]
Sixth
Fill Bit
if needed
= [0 (if
used as a
fill bit)]
Fifth Fill
Bit if
needed
= [0 (if
used as a
fill bit)]
Fourth
Fill Bit
if needed
= [0 (if
used as a
fill bit)]
Third Fill
Bit if
needed
= [0 (if
used as a
fill bit)]
Second
Fill Bit
if needed
= [0 (if
used as a
fill bit)]
First Fill
Bit if
needed
= [0 (if
used as a
fill bit)]
m
1
2
TIA-2001.4-C
163 Section 3
This BSMAP message is sent from MSC to BS to trigger the BS to send the Mobile 2
Station Registered Message to the MS. 3
Reference
Element
Direction
Type

R

4
The following table shows the bitmap layout for the Mobile Station Registered 5
Notification message. 6
3.3.20 Mobile Station Registered Notification
7 6 5 4 3 2 1 0 Octet
Length Indicator (LI) = [04] 2
Length = [01H] 2
ext=[0] Cause Value=[1EH (Autonomous Registration by the Network)] 3
7
8
TIA-2001.4-C
Section 3 164
3.4 Handoff Message Formats 1
Within this section where a Cell Identifier List element is contained in a handoff 2
message, care shall be taken in selection of the type of Cell Identifier Discriminator used. 3
Only one discriminator type can be used in a single occurrence of the Cell Identifier List 4
element, and all cells appearing in the list shall follow that format. For details, refer to 5
sections 4.2.18, Cell Identifier List and 4.2.17, Cell Identifier. 6
3.4.1 Handoff Required 7
This BSMAP message is sent from the BS to the MSC to indicate that for a given MS 8
which already has a dedicated radio resource assigned, a handoff is required for the 9
reason given by the cause element. 10
Reference
Element
Direction
Type
Cell Identifier List (Target) 4.2.18 BS -> MSC M
a

b, g, p
R
Response Request 4.2.28 BS -> MSC O R
c
R
IS-95 Channel Identity 4.2.9 BS -> MSC O
d, h, q
C
e
R
Downlink Radio Environment 4.2.22 BS -> MSC O
f, h, r
C
t
C
h, r
C
MS Measured Channel Identity 4.2.29 BS -> MSC O
i, r
C
h, j, v, q
C
Quality of Service Parameters 4.2.45 BS -> MSC O
k
C
h, aa

C
IS-2000 Service Configuration Record 4.2.55 BS -> MSC O
h, r
C
Source PDSN Address 4.2.24 BS -> MSC O
l
C
Protocol Type 4.2.58 BS -> MSC O
m
C
Source RNC to Target RNC Transparent Container 4.2.75 BS -> MSC O
n
C
r
C
Access Network Identifiers 4.2.74 BS ->MSC O
s
C
Service Option List 4.2.78 BS -> MSC O
u
C
IS-2000 Channel Identity 3X 4.2.23 BS -> MSC O
h, v, q, o
C
IS-2000 Non-Negotiable Service Configuration
Record
4.2.56 BS -> MSC O
h, q, x
C
Anchor PDSN Address 4.2.82 BS -> MSC O
w
C
Anchor P-P Address 4.2.84 BS -> MSC O
y
C
TIA-2001.4-C
165 Section 3
Reference
Element
Direction
Type
Packet Session Parameters 4.2.89 BS -> MSC O
z
C
a. This element contains the preferred list of target cells in order of predicted best 1
performance. 2
b. This element indicates the signaling modes and band classes the MS is capable of 3
operating in. If an MS is capable of supporting multiple band classes, and this 4
information is available at the BS, it shall be indicated in the band class entry field as 5
shown in section 4.2.12. 6
c. This element conveys current Voice/Data Privacy and Signaling Message Encryption 7
modes, as well as the Voice/Data Privacy and Signaling Message Encryption Keys, 8
if applicable. 9
d. This element specifies the current TIA/EIA/IS-95-B channel for CDMA to CDMA 10
handoff requests only. This element shall contain only a single instance of octets 4 to 11
7 when sent by an entity compliant with this version of the standard. For backward 12
compatibility with older IOS versions, an entity compliant with this version of the 13
standard shall be prepared to receive multiple instances of octets 4 to 7, but may 14
ignore all additional instances, since the ARFCN value is already contained in the 15
first instance. This element is not present if the IS-2000 Channel Identity element is 16
present. 17
e. This element is required for TIA/EIA/IS-95-B and cdma2000
handoffs and shall 18

contain the MSs ESN, so that the target BS can calculate the Public Long Code 19
Mask. 20
f. This element provides information for each cell in the Cell Identifier List element. 21
g. The fields in octets 4 and 5 shall be coded as shown in the bitmap that follows. The 22
MSC shall ignore all fields except IS-95, Slotted, and Mobile_Term. 23
h. These elements are not required for a CDMA to AMPS handoff. 24
i. This element specifies the target channel for CDMA to CDMA hard handoff based 25
on the MS measurement. It is required if the value is provided by the MS. 26
j. This element specifies the IS-2000 physical channel(s) for CDMA to CDMA hard 27
handoff requests only. This element is not present if the IS-95 Channel Identity 28
element or the IS-2000 Channel Identity 3X element is present. 29
k. This element is only used for packet data calls. In this version of this standard, this 30
element is used to carry the current non-assured mode priority of the packet data 31
session. 32
l. This element is only used for packet data calls in case of an inter-PCF hard handoff. 33
It carries the IP Address of the PDSN currently connected to the PCF. 34
m. This element indicates the protocol type that is indicated in the Generic Routing 35
Encapsulation (GRE) header for the A8 and A10 interfaces. The only allowed value 36
in this revision of the standard is 88 81H Unstructured Byte Stream. 37
n. This element is only used when the target BS is operating in DS-41 mode. 38
o. This element is used for 3X systems. It is not present if either the IS-2000 Channel 39
Identity or IS-95 Channel Identity elements are present. 40
p. When all target BSs indicated in this message (Cell Identifier List (Target)) are 41
operating in DS-41 mode, only the following fields in the Classmark Type 2 42
Information element shall be considered valid: MOB_P_REV, NAR_AN_CAP, 43
Mobile Term, PSI (PACA Supported Indicator), SCM Length, Count of Band Class 44
TIA-2001.4-C
Section 3 166
Entries, Band Class Entry Length, Band Class n, Band Class n Air Interfaces 1
Supported, Band Class n MOB_P_REV 2
When at least one target BS indicated in this message (Cell Identifier List (Target)) 3
is operating in MC-41 mode, footnote 'h' applies. It is the responsibility of a source 4
BS operating in DS-41 mode to properly populate all necessary fields in this 5
element. 6
q. These elements shall not be included when the source BS and MS are operating in 7
DS-41 mode. 8
r. These elements shall be included by the DS-41 source BS when the target BS is 9
operating in MC-41 mode. 10
s. This element is only used for packet data calls. The Access Network Identifiers 11
(ANIDs) are those of the source PCF. 12
t. This element is included if neither concurrent services nor multiple service instances 13
are supported. This element is not present if the Service Option List element is 14
present. 15
u. This element specifies the information of the service options being handed off. This 16
element is not present if the Service Option element is present, but shall be present if 17
the Service Option element is not present. This element may contain more than one 18
service option. Multiple instances of 3G packet data (SO=21H) may be present. If 19
this message is being used to hand off a packet data session, this element contains all 20
active and dormant 3G packet data service instances which are associated with that 21
packet data session. This element shall contain at most one instance from the 22
following set of service options: 13K speech (SO=8000H), 13K high rate voice 23
service (SO=11H), EVRC (SO=03H), VoIP (SO=3CH, 3DH), or SMV (SO=38H). If 24
this element contains either OTAPA (SO 12H, 13H), SMS (SO 06H, 0DH), or PLD 25
(SO 23H, 24H) then the number of service options included shall equal one. 26
v. Hard handoff of the Supplemental Channel is not supported in this version of the 27
standard. Allowed values for the Physical Channel Type in the IS-2000 Channel 28
Identity IE and IS-2000 Channel Identity 3X IE are: Fundamental Channel or 29
Dedicated Control Channel. 30
w. This is the IP address of the A11 interface on the anchor PDSN. This element is 31
present only if fast handoff is supported. 32
x. This element shall be included for CDMA-CDMA handoffs. 33
y. This is the IP address of the P-P interface on the anchor PDSN. Inclusion of this 34
element indicates that fast handoff is requested 35
z. This element is included when there are one or more packet data parameters to be 36
sent to theh target BS. 37
aa. If the BS does not have the information required to correctly populate a field in this 38
40
41
TIA-2001.4-C
167 Section 3
The following table shows the bitmap layout for the Handoff Required message. 1
3.4.1 Handoff Required
7 6 5 4 3 2 1 0 Octet
Length = [01H] 2
0DH (Timer expired),
0EH (Better cell),
0FH (Interference),
17H (Time critical relocation/handoff),
18H (Network optimization)]
3
! !! ! Cell Identifier List (Target): A1 Element Identifier = [1AH] 1
Omni)
(LSB) j+1
j+1
(LSB) j+2
Omni)
(LSB) j+4
MOB_P_REV
= [000 111]
Reserved
= [0]
See List
of
Entries =
[0, 1]

3
Reserved = [00H] 4
NAR_
AN_
CAP
= [0,1]
IS-95
= [1]
Slotted
= [0,1]
Reserved = [00]

DTX
= [0,1]
Mobile
Term
= [0,1]
TIA/EIA-
553
= [0,1]
5
TIA-2001.4-C
Section 3 168
7 6 5 4 3 2 1 0 Octet
Reserved = [00H] 6

Mobile
Term
= [0,1]
PSI
= [0,1]
7
! !! ! Response Request: A1 Element Identifier = [1BH] 1
ext =
[1]
Encryption Parameter Identifier =
[00001 (SME),
Status
= [0,1]
Available
= [0,1]
j
Encryption Parameter Length = <variable> j+1
(MSB) Encryption Parameter value = <any value> j+2

(LSB) k
ext =
[1]
Encryption Parameter Identifier = [00100]
(Private Longcode)
Status
= [0,1]
Available
= [0,1]
m
Encryption Parameter Length = [06H] m+1
Unused = [000000] (MSB) m+2
Encryption Parameter value = <any value> m+3
m+4
m+5
m+6
(LSB) m+7
TIA-2001.4-C
169 Section 3
7 6 5 4 3 2 1 0 Octet
}Encryption I nfo
! !! ! IS-95 Channel Identity: A1 Element Identifier = [22H] 1
Hard
Handoff
= [1]
Number of Channels to Add =
[001]
Frame Offset = [0H-FH] 3
{1+:
Walsh Code Channel Index = <any value> (Ignored) k
Pilot PN Code (low part) = <any value> (Ignored) k+1
Pilot PN
Code
(high
part)
= <any
value>
(Ignored
)
Power
Combined
= [0]
Freq.
included
= [1]
Reserved = [00] ARFCN (high part)
= [000-111]
k+2
ARFCN (low part) = [00H-FFH] k+3
}
Length = [05H] 2
Indicator
= [0]
Type of Identity
= [101] (ESN)
3
5
6
(LSB) 7
! !! ! Downlink Radio Environment: A1 Element Identifier = [29H] 1
Number of Cells = <variable> 3
Downlink Radio Environment entry {1+:
I F (Discriminator =02H), Cell I dentification {1
Omni)
(LSB) j+1
TIA-2001.4-C
Section 3 170
7 6 5 4 3 2 1 0 Octet
j+1
(LSB) j+2
Omni)
(LSB) j+4
Reserved = [00] Downlink Signal Strength Raw = [000000-111111] k
(MSB) CDMA Target One Way Delay = [0000H-FFFFH] (x100ns) k+1
(LSB) k+2
= [8000H (13K speech),
0003H (EVRC),
000EH (SMS Rate Set 2)
0038H (SMV)]
(LSB) 3
Omni)
(LSB) j+1
TIA-2001.4-C
171 Section 3
7 6 5 4 3 2 1 0 Octet
j+1
(LSB) j+2
Omni)
(LSB) j+4
(LSB) k+1
Reserved = [0000 00] Resolution = [00, 01,
10]
k+2
(LSB) k+4
! !! ! MS Measured Channel Identity: A1 Element Identifier = [64H] 1
Length = [02H] 2
Band Class = [00000 11111] ARFCN (high part)
= [000-111]
3
ARFCN (low part) = [00H FFH] 4
OTD=
[0]
(Ignored
)
Physical Channel Count =
[001, 010]
The following 6 octets are repeated once for each physical channel {1..2:
Physical Channel Type =
[01H (Fundamental Channel FCH IS-2000),
02H (Dedicated Control Channel DCCH IS-2000)]
n
Rev_FCH
_Gating
=[0,1]
Reverse Pilot
Gating Rate
= [00, 01, 10]
QOF Mask
= <any value>
(ignored)
Walsh Code Channel Index (high
part) = <any value> (Ignored)
n+1
Walsh Code Channel Index (low part) = <any value> (Ignored) n+2
Pilot PN Code (low part) = <any value> (Ignored) n+3
Pilot PN
Code
(high
part)
= <any
value>
(Ignored
)
Reserved = [00] Power
Combined
= [0]
Freq.
included
= [1]
ARFCN (high part)
= [000-111]
n+4
TIA-2001.4-C
Section 3 172
7 6 5 4 3 2 1 0 Octet
ARFCN (low part) = [00H-FFH] n+5
}Channel I nformation
Length = [01H] 2
[0000 1101]
3
Reserved
= [00]
ERAM
Supported
= [0,1]
DCCH
Supported
= [0,1]
FCH
Supported
= [0,1]
OTD
Supported
= [0,1]
Enhanced
RC CFG
Supported
= [0,1]
QPCH
Supported
= [0,1]
3
= [00H to FFH]
4
Reserved
= [0]
value> (Ignored)
Geo
Location
Included
= <any
value>
(Ignored)
FCH Information:
= [000 to 111]
5
(MSB) 6
= <any value>

Seventh
Fill Bit
if needed
= [0 (if
used as a
fill bit)]
Sixth
Fill Bit
if needed
= [0 (if
used as a
fill bit)]
Fifth Fill
Bit if
needed
= [0 (if
used as a
fill bit)]
Fourth
Fill Bit
if needed
= [0 (if
used as a
fill bit)]
Third Fill
Bit if
needed
= [0 (if
used as a
fill bit)]
Second
Fill Bit
if needed
= [0 (if
used as a
fill bit)]
First Fill
Bit if
needed
= [0 (if
used as a
fill bit)]
k
= [00H to FFH]
k+1
Reserved
= [0000 0]
DCCH Information:
= [000 to 111]
k+2
(MSB) k+3
= <any value>

Seventh
Fill Bit
if needed
= [0 (if
used as a
fill bit)]
Sixth
Fill Bit
if needed
= [0 (if
used as a
fill bit)]
Fifth Fill
Bit if
needed
= [0 (if
used as a
fill bit)]
Fourth
Fill Bit
if needed
= [0 (if
used as a
fill bit)]
Third Fill
Bit if
needed
= [0 (if
used as a
fill bit)]
Second
Fill Bit
if needed
= [0 (if
used as a
fill bit)]
First Fill
Bit if
needed
= [0 (if
used as a
fill bit)]
m
! !! ! IS-2000 Service Configuration Record: A1 Element Identifier = [0EH] 1
TIA-2001.4-C
173 Section 3
7 6 5 4 3 2 1 0 Octet
Bit-Exact Length Octet Count = <variable> 2
Reserved
= [0000 0]
= [000 111]
3
(MSB) 4
IS-2000 Service Configuration Record Content = <any value>

Seventh
Fill Bit
if needed
= [0 (if
used as a
fill bit)]
Sixth Fill
Bit if
needed
= [0 (if
used as a
fill bit)]
Fifth Fill
Bit if
needed
= [0 (if
used as a
fill bit)]
Fourth
Fill Bit
if needed
= [0 (if
used as a
fill bit)]
Third
Fill Bit
if needed
= [0 (if
used as a
fill bit)]
Second
Fill Bit
if needed
= [0 (if
used as a
fill bit)]
First Fill
Bit if
needed
= [0 (if
used as a
fill bit)]
k
! !! ! Source PDSN Address: A1 Element Identifier = [14H] 1
Length = [04H] 2
(MSB) Source PDSN Address = <any value> 3
4
5
(LSB) 6
! !! ! Protocol Type: A1 Element Identifier = [18H] 1
Length = [02H] 2
(MSB) Protocol Type = [88 81H]
(Unstructured Byte Stream)
3
(LSB) 4
! !! ! Source RNC to Target RNC Transparent Container:
1
Length = [01H FFH] 2
(MSB) Container = <any value> 3

(LSB)
K
! !! !Access Network Identifiers: A1 Element Identifier = [20H] 1
Length = [05H] 2
Reserve
d = [0]
(MSB) SID = <any value> 3
(LSB) 4
(MSB) NID = <any value> 5
(LSB) 6
PZID = <any value> 7
TIA-2001.4-C
Section 3 174
7 6 5 4 3 2 1 0 Octet
! !! ! Service Option List: A1 Element Identifier = [2AH] 1
Number of Service Option Instances = [01H-06H] 3
Service Option Connection {1..6:
Reserved = [00] SR_ID = [001 110] Service Option
[001 - 110]
i
(MSB) Service Option i+1
= [8000H (13K speech),
0003H (EVRC),
0025H (ISDN Interworking),
0038H (SMV),
003CH (Link Layer Assisted Header
Removal),003DH (Link Layer Assisted RObust
Header Compression)]
(LSB) i+2
}Service Option Connection
! !! ! I S-2000 Channel Identity 3X: A1 Element Identifier = [27H] 1
OTD=
[0]
(Ignored
)
[001, 010]

n
TIA-2001.4-C
175 Section 3
7 6 5 4 3 2 1 0 Octet
Rev_FCH_
Gating =
[0,1]
Reverse Pilot
Gating Rate
= [00, 01, 10]
QOF Mask
= <any value>
(ignored)
n+1
Pilot PN
Code
(high
part)
= <any
value>
(Ignored
)
Combined
= [0]
Freq.
included
= [1]
ARFCN (high part)
= [000-111]
n+4
Reserved = [000] Lower QOF Mask
= <any value>
(ignored)
Lower Walsh Code Channel
Index (high part) = <any
value>(Ignored)
n+6
Lower Walsh Code Channel Index (low part) = <any value> (Ignored) n+7
Reserved = [000] Upper QOF Mask
= <any value>
(ignored)
Upper Walsh Code Channel
value>(Ignored)
n+8
Upper Walsh Code Channel Index (low part) = <any value> (Ignored) n+9
! !! ! I S-2000 Non-negotiable Service Configuration Record:
A1 Element Identifier = [0FH]
1
Bit-Exact Length Octet Count = [00H to FFH] 2
Reserved = [0000 0] Bit-Exact Length Fill Bits
= [000 to 111]
3
(MSB) 4
IS-2000 Non-Negotiable Service Configuration Record Content = <any value>

Seventh
Fill Bit
if needed
= [0 (if
used as a
fill bit)]
Sixth Fill
Bit if
needed
= [0 (if
used as a
fill bit)]
Fifth Fill
Bit if
needed
= [0 (if
used as a
fill bit)]
Fourth
Fill Bit
if needed
= [0 (if
used as a
fill bit)]
Third
Fill Bit
if needed
= [0 (if
used as a
fill bit)]
Second
Fill Bit
if needed
= [0 (if
used as a
fill bit)]
First Fill
Bit if
needed
= [0 (if
used as a
fill bit)]
k
! !! ! Anchor PDSN Address: A1 Element Identifier = [30H] 1
Length = [04H] 2
(MSB) Anchor PDSN Address = <any value> 3
4
5
(LSB) 6
TIA-2001.4-C
Section 3 176
7 6 5 4 3 2 1 0 Octet
! !! ! Anchor P-P Address: A1 Element Identifier = [7CH] 1
Length = [04H] 2
(MSB) Anchor P-P Address = <any value> 3
4
5
(LSB) 6
! !! ! Packet Session Parameters: A1 Element Identifier = [70H] 1
Service Instance {1..6:
Reserved = [00000] SR_ID = [001-110] k
Data Length = [03H] k+1
Parameter Identifier = [01H] (RN-PDIT) k+2
Parameter Length = [01H] k+3
Parameter Value = [01H-FFH] k+4
} Service Instance
1
TIA-2001.4-C
177 Section 3
3.4.2 Handoff Request 1
The BSMAP Handoff Request message is sent from the MSC to the BS to indicate that a 2
MS is to be handed off to that BS. 3
Reference
Element
Direction
Type
Channel Type 4.2.6 MSC -> BS M
a
Encryption Information 4.2.10 MSC -> BS M
b

Classmark Information Type 2 4.2.12 MSC -> BS M
c,o

Cell Identifier List (Target) 4.2.18 MSC -> BS M
d
Circuit Identity Code Extension 4.2.20 MSC -> BS O
e
C
IS-95 Channel Identity 4.2.9 MSC -> BS O
f,p
C
g
R
g
R
Downlink Radio Environment 4.2.22 MSC -> BS O
h,q
R
t
C
CDMA Serving One Way Delay 4.2.61 MSC -> BS O
q
R
MS Measured Channel Identity 4.2.29 MSC -> BS O
i,q
C
j,p
C
Quality of Service Parameters 4.2.45 MSC -> BS O
k
C
s, aa
C
IS-2000 Service Configuration Record 4.2.55 MSC -> BS O
q, s
C
Source PDSN Address 4.2.24 MSC -> BS O
l, s
C
Protocol Type 4.2.58 MSC -> BS O
m, s
C
Source RNC to Target RNC Transparent Container 4.2.75 MSC -> BS O
r
C
q, s
C
Access Network Identifiers 4.2.74 MSC->BS O
n, s
C
Service Option List 4.2.78 MSC -> BS O
u
C
IS-2000 Channel Identity 3X 4.2.23 MSC -> BS O
p, v
C
Record
4.2.56 MSC -> BS O
x, q
C
Anchor PDSN Address 4.2.82 MSC->BS O
w
C
Anchor P-P Address 4.2.84 MSC->BS O
y
C
Packet Session Parameters 4.2.89 MSC->BS O
z
C
a. Channel Type is being included for historical reasons and is hard coded as shown. 4
The BS should examine the Service Option element instead. 5
b. This element conveys the current Voice/Data Privacy Signaling Message Encryption 6
mode, as well as the Voice/Data Privacy and/or Signaling Message Encryption Keys, 7
if applicable. 8
TIA-2001.4-C
Section 3 178
Whatever encryption information is received from the source BS in the Handoff 1
Required message is sent to the target BS in the Handoff Request message. 2
c. This element provides the signaling types and band classes that the MS is permitted 3
to use. More than one is permitted. If an MS is capable of supporting multiple band 4
classes, and this information was included in the Handoff Required message, it shall 5
be indicated in the band class entry field as shown in section 4.2.12. 6
d. If more than one cell is specified, then they shall be in order of selection preference. 7
Only discriminator types 0000 0010 and 0000 0111 are used. 8
e. This element contains the full-rate circuit identifier allocated by the MSC. 9
In the case of hard handoff for an async data/fax call, this element indicates the 10
Circuit Identity Code of the circuit to be connected to the target BS to support the A5 11
connection to the IWF. 12
In the case of hard handoff for a voice call, this element indicates the Circuit Identity 13
Code of the circuit to be connected to the target BS to support the A2 connection. 14
In the case of hard handoff for a packet data call, SMS delivery on a traffic channel 15
(SMS service option in use), OTAPA delivery on a traffic channel, or PLD on a 16
traffic channel, this element shall not be included. 17
f. This element specifies current TIA/EIA/IS-95-B channel for CDMA to CDMA 18
handoff requests only. This element shall contain only a single instance of octets 4 to 19
7 when sent by an entity compliant with this version of the standard. For backward 20
compatibility with older IOS versions, an entity compliant with this version of the 21
standard shall be prepared to receive multiple instances of octets 4 to 7, but may 22
ignore all additional instances, since the ARFCN value is already contained in the 23
first instance. This element is not present if the IS-2000 Channel Identity element or 24
IS-2000 Channel Identity 3X element is present. 25
g. This element is required for CDMA to CDMA handoffs. The first instance shall 26
contain the IMSI, and the second shall contain the MS's ESN, so that the target BS 27
can calculate the Public Long Code Mask. 28
h. This element provides information for each cell in the Cell Identifier List (target) 29
element. 30
i. If the MS Measured Channel Identity element was included in the Handoff Required 31
message, this element is required in this message. 32
j. This element specifies the IS-2000 physical channel(s) for CDMA to CDMA hard 33
handoff requests only. This element is not present if the IS-95 Channel Identity 34
element or the IS-2000 Channel Identity 3X element is present. 35
k. This element is only used for packet data calls. In this version of this standard, this 36
element is used to carry the current non-assured mode priority of the packet data 37
session. 38
l. This element is only used for packet data calls in case of an inter-PCF hard handoff. 39
It carries the IP Address of the PDSN currently connected to the PCF. 40
m. This element indicates the Protocol Type that is indicated in the GRE header for the 41
A8 and A10 interfaces. 42
n. This element is only used for packet data calls. The Access Network Identifiers are 43
those of the source PCF. 44
o. When all target BSs indicated in this message (Cell Identifier List (Target)) are 45
operating in DS-41 mode, only the following fields in the Classmark Type 2 46
Information element shall be considered valid: MOB_P_REV, NAR_AN_CAP, 47
Mobile Term, PSI (PACA Supported Indicator), SCM Length, Count of Band Class 48
TIA-2001.4-C
179 Section 3
Entries, Band Class Entry Length, Band Class n, Band Class n Air Interfaces 1
Supported, Band Class n MOB_P_REV. 2
When at least one target BS indicated in this message (Cell Identifier List (Target)) 3
is operating in MC-41 mode, all fields of this element shall be considered as valid. It 4
is the responsibility of a source BS operating in DS-41 mode to properly complete all 5
necessary fields in this element. 6
p. These elements shall not be included when the source BS and MS are operating in 7
DS-41 mode. 8
q. These elements shall be included by the DS-41 source BS when the target BS is 9
operating in MC-41 mode. 10
r. This element is only used when the target BS is operating in DS-41 mode. 11
s. This element is included for CDMA to CDMA handoffs. 12
t. This element shall be present if it was received by the MSC from the source BS, or if 13
the target BS does not support concurrent services or multiple service instances. 14
u. This element specifies the information of the service options being handed off. This 15
element shall be present if it was received by the MSC from the source BS and if the 16
Service Option element is not present in the Handoff Request message. This element 17
may contain more than one service option. Multiple instances of 3G packet data 18
(SO=21H) may be present. If this message is being used to hand off a packet data 19
session, this element contains all active and dormant 3G packet data service 20
instances which are associated with that packet data session. This element shall 21
contain at most one instance from the following set of service options: 13K speech 22
(SO=8000H), 13K high rate voice service (SO=11H), EVRC (SO=03H), VoIP 23
(SO=3CH, 3DH), or SMV (SO=38H). If this element contains either OTAPA (SO 24
12H, 13H), SMS (SO 06H, 0DH) or PLD (SO 23H, 24H) then the number of service 25
options included shall equal one. 26
v. This element specifies the IS-2000 physical channel(s) for CDMA to CDMA hard 27
handoff requests in a 3X system only. This element is not present if the IS-95 28
Channel Identity element or the IS-2000 Channel Identity element is present. 29
w. This is the IP address of the A11 interface on the anchor. This element is present 30
only if fast handoff is supported. 31
x. This element is sent if available at the source BS. 32
y. This is the IP address of the P-P interface on the anchor PDSN. Inclusion of this 33
element indicates that fast handoff is requested. 34
z. This element is included when there are one or more packet data parameters to be 35
sent to the target BS. 36
aa. If the MSC does not have the information required to correctly populate a field in 37
39
TIA-2001.4-C
Section 3 180
The following table shows the bitmap layout for the Handoff Request message. 1
3.4.2 Handoff Request
7 6 5 4 3 2 1 0 Octet
! !! ! Channel Type: A1 Element Identifier = [0BH] 1
Length = [03H] 2
Speech or Data Indicator =[01H] (speech) 3
Channel Rate and Type = [08H] (Full Rate) 4
Speech Encoding Algorithm/data rate + Transparency Indicator =
[05H (13 kbps vocoder - speech)]
5
ext =
[1]
Encryption Parameter Identifier =
[00001] (SME),
Status
= [0,1]
Available
= [0]
j
Encryption Parameter Length = <variable> j+1
(MSB) Encryption Parameter value = <any value> j+2

(LSB) k
(Private Longcode)
Status
= [0,1]
Available
= [0]
m
Encryption Parameter Length = [06H] m+1
Unused = [000000] (MSB) m+2
Encryption Parameter value = <any value> m+3
m+4
m+5
m+6
(LSB) m+7
}Encryption I nfo
TIA-2001.4-C
181 Section 3
7 6 5 4 3 2 1 0 Octet
MOB_P_REV
=[000 111]
Reserved
= [0]
See List
of
Entries =
[0, 1]

3
Reserved = [00H] 4
NAR_
AN_
CAP
= [0,1]
IS-95
= [1]
Slotted
= [0,1]
Reserved = [00]

DTX
= [0,1]
Mobile
Term
= [1]
TIA/EIA-
553
= [0,1]
5
Reserved = [00H] 6

Mobile
Term
= [0,1]
PSI
= [0,1]
7
! !! ! Cell Identifier List (Target): A1 Element Identifier = [1AH] 1
j+1
(LSB) j+2
Omni)
(LSB) j+4
! !! ! Circuit Identity Code Extension: A1 Element Identifier = [24H] 1
TIA-2001.4-C
Section 3 182
7 6 5 4 3 2 1 0 Octet
Length = [03H] 2
(LSB) Timeslot = [00000-11111] 4
Reserved = [0H] Circuit Mode = [0H] (Full-rate) 5
! !! ! I S-95 Channel Identity: A1 Element Identifier = [22H] 1
Hard
Handoff
= [1]
Number of Channels to Add
= [001]
{1+:
Walsh Code Channel Index = <any value> (Ignored) n
Pilot PN
Code
(high
part)
= <any
value>
(Ignored)
Power
Combined
= [0]
Freq.
included
= [1]
= [000-111]
n+2
}
Indicator
= [1,0]
Type of Identity
= [110] (IMSI)
3

Length = [05H] 2
Indicator
= [0]
Type of Identity
= [101] (ESN)
3
5
6
(LSB) 7
TIA-2001.4-C
183 Section 3
7 6 5 4 3 2 1 0 Octet
! !! ! Downlink Radio Environment: A1 Element Identifier = [29H] 1
Downlink Radio Environment entry {1+:
Omni)
(LSB) j+1
} OR I F (Discriminator =07H), Cell I dentification {1:
j+1
(LSB) j+2
Omni)
(LSB) j+4
Reserved = [00] Downlink Signal Strength Raw = [000000-111111] k
(MSB) CDMA Target One Way Delay = [0000H-FFFFH] (x100ns) k+1
(LSB) k+2
TIA-2001.4-C
Section 3 184
7 6 5 4 3 2 1 0 Octet
= [8000H (13K speech),
0003H (EVRC),
0038H (SMV),
003CH (Link Layer Assisted Header Removal),
003DH (Link Layer Assisted RObust Header
Compression)]
(LSB) 3
j+1
(LSB) j+2
(LSB) k+1
TIA-2001.4-C
185 Section 3
7 6 5 4 3 2 1 0 Octet
10]
k+2
(LSB) k+4
! !! ! MS Measured Channel Identity: A1 Element Identifier = [64H] 1
Length = [02H] 2
Band Class = [00000 11111] ARFCN (high part)
= [000-111]
3
ARFCN (low part) = [00H FFH] 4
OTD =
[0]
(Ignored
)
[001, 010]
02H (Dedicated Control Channel DCCH IS-2000)]]
n
Rev_FCH
_Gating
Reverse Pilot
Gating Rate
= [00, 01, 10]
QOF Mask
= <any value>
(ignored)
part) = <any value>Ignored)
n+1
Pilot PN
Code
(high
part)
= <any
value>
(Ignored)
Combined
= [0]
Freq.
included
= [1]
ARFCN (high part)
= [000-111]
n+4
Length = [01H] 2
[0000 1101]
3
TIA-2001.4-C
Section 3 186
7 6 5 4 3 2 1 0 Octet
Reserved
= [00]
ERAM
Supported =
[0,1]
DCCH
Supported
= [0,1]
FCH
Supported
= [0,1]
OTD
Supported
= [0,1]
Enhanced
RC CFG
Supported
= [0,1]
QPCH
Supported
= [0,1]
3
= [00H to FFH]
4
Reserve
d
= [0]
value> (Ignored)
Geo
Location
Included
= <any
value>
(Ignored)
FCH Information:
= [000 to 111]
5
(MSB) 6
= <any value>

Seventh
Fill Bit
if needed
= [0 (if
used as a
fill bit)]
Sixth
Fill Bit
if
needed
= [0 (if
used as a
fill bit)]
Fifth Fill
Bit if
needed
= [0 (if
used as a
fill bit)]
Fourth Fill
Bit if
needed
= [0 (if
used as a
fill bit)]
Third Fill
Bit if
needed
= [0 (if
used as a
fill bit)]
Second
Fill Bit
if needed
= [0 (if
used as a
fill bit)]
First Fill
Bit if
needed
= [0 (if
used as a
fill bit)]
k
= [00H to FFH]
k+1
Reserved
= [0000 0]
DCCH Information:
= [000 to 111]
k+2
(MSB) k+3
= <any value>

Seventh
Fill Bit
if needed
= [0 (if
used as a
fill bit)]
Sixth
Fill Bit
if
needed
= [0 (if
used as a
fill bit)]
Fifth Fill
Bit if
needed
= [0 (if
used as a
fill bit)]
Fourth
Fill Bit
if needed
= [0 (if
used as a
fill bit)]
Third
Fill Bit
if needed
= [0 (if
used as a
fill bit)]
Second
Fill Bit
if needed
= [0 (if
used as a
fill bit)]
First Fill
Bit if
needed
= [0 (if
used as a
fill bit)]
m
Reserved
= [0000 0]
= [000 111]
3
(MSB) 4

TIA-2001.4-C
187 Section 3
7 6 5 4 3 2 1 0 Octet
Seventh
Fill Bit
if needed
= [0 (if
used as a
fill bit)]
Sixth
Fill Bit
if
needed
= [0 (if
used as a
fill bit)]
Fifth Fill
Bit if
needed
= [0 (if
used as a
fill bit)]
Fourth
Fill Bit
if needed
= [0 (if
used as a
fill bit)]
Third
Fill Bit
if needed
= [0 (if
used as a
fill bit)]
Second
Fill Bit
if needed
= [0 (if
used as a
fill bit)]
First Fill
Bit if
needed
= [0 (if
used as a
fill bit)]
k
! !! ! Source PDSN Address: A1 Element Identifier = [14H] 1
Length = [04H] 2
(MSB) Source PDSN Address = <any value> 3
4
5
(LSB) 6
! !! ! Protocol Type: A1 Element Identifier = [18H] 1
Length = [02H] 2
(MSB) Protocol Type = [8881H]
(Unstructured Byte Stream)
3
(LSB) 4
! !! ! Source RNC to Target RNC Transparent Container: A1 Element
Identifier = [39H]
1

(LSB) k
! !! ! Access Network Identifiers: A1 Element Identifier = [20H] 1
Length = [05H] 2
Reserve
d = [0]
(LSB) 4
(LSB) 6
TIA-2001.4-C
Section 3 188
7 6 5 4 3 2 1 0 Octet
[001 - 110]
i
= [8000H (13K speech),
0003H (EVRC),
0025H (ISDN Interworking)0038H (SMV),
003CH (Link Layer Assisted Header Removal)
003DH (Link Layer Assisted RObust Header
Compression)]
(LSB) i+2
OTD =
[0]
(Ignored
)
[001, 010]
n
Rev_FCH
_Gating
=[0,1]
Reverse Pilot
Gating Rate
= [00, 01, 10]
QOF Mask
= <any value>
(Ignored)
n+1
TIA-2001.4-C
189 Section 3
7 6 5 4 3 2 1 0 Octet
Pilot PN
Code
(high part)
= <any
value>
(Ignored)
Reserved =
[00]
Power
Combined
= [0]
Freq.
included
= [1]
ARFCN (high part)
= [000-111]
n+4
= <any value>
(Ignored)
value> (Ignored)
n+6
Lower Walsh Code Channel Index (low part) = <any value> (Ignored) n+7
= <any value>
(Ignored)
value> (Ignored)
n+8
Upper Walsh Code Channel Index (low part) = <any value> (Ignored) n+9
! !! ! I S-2000 Non-negotiable Service Configuration Record:
A1 Element Identifier = [0FH]
1
Bit-Exact Length Octet Count = [00H to FFH] 2
Reserved = [0000 0] Bit-Exact Length Fill Bits
= [000 to 111]
3
(MSB) 4
IS-2000 Non-Negotiable Service Configuration Record Content = <any value>

Seventh
Fill Bit
if needed
= [0 (if
used as a
fill bit)]
Sixth Fill
Bit if
needed
= [0 (if
used as a
fill bit)]
Fifth Fill
Bit if
needed
= [0 (if
used as a
fill bit)]
Fourth
Fill Bit
if needed
= [0 (if
used as a
fill bit)]
Third
Fill Bit
if needed
= [0 (if
used as a
fill bit)]
Second
Fill Bit
if needed
= [0 (if
used as a
fill bit)]
First Fill
Bit if
needed
= [0 (if
used as a
fill bit)]
k
Length = [04H] 2
4
5
(LSB) 6
! !! ! Anchor P-P Address: A1 Element Identifier = [7CH] 1
Length = [04H] 2
4
5
TIA-2001.4-C
Section 3 190
7 6 5 4 3 2 1 0 Octet
(LSB) 6
! !! ! Packet Session Parameters : A1 Element Identifier = [70H] 1
Service Instance {1..6:
Reserved = [00000] SR_ID = [001-110] k
Data Length = [03H] k+1
Parameter Identifier = [01H] (RN-PDIT) k+2
Parameter Length = [01H] k+3
Parameter Value = [01H-FFH] k+4
} Service Instance
1
TIA-2001.4-C
191 Section 3
3.4.3 Handoff Request Acknowledge 1
This BSMAP message is sent from the BS to the MSC to indicate that a target channel 2
has been allocated for handoff as requested. This is in response to the Handoff Request 3
message. This message is only used for CDMA-CDMA hard handoff and hard handoff to 4
or from DS-41 systems. 5
Reference
Element
Direction
Type
a,f
C
Cell Identifier List 4.2.18 BS -> MSC O
b
R
Extended Handoff Direction Parameters 4.2.60 BS -> MSC O
f,k
C
Hard Handoff Parameters 4.2.51 BS -> MSC O
f
C
c,f
C
IS-2000 Service Configuration Record 4.2.55 BS -> MSC O
d,f
C
Record
4.2.56 BS -> MSC O
e,f
C
Target RNC to Source RNC Transparent Container 4.2.76 BS -> MSC O
g
C
Service Option List 4.2.78 BS -> MSC O
h
C
i
C
IS-2000 Channel Identity 3X 4.2.23 BS -> MSC O
f,j
C
a. This element is included if the air interface channel allocated by the target is 6
TIA/EIA/IS-95-B. It lists each TIA/EIA/IS-95-B channel, one for each cell listed in the 7
Cell Identifier List, that has been allocated by the target BS. This element is not 8
present if the IS-2000 Channel Identity element or IS-2000 Channel Identity 3X 9
element is present. 10
b. The first cell in this cell identifier list element shall be treated as the designated 11
cell by the MSC. The cell identifier list consists of all cells set up by the target BS. 12
c. This element is included if the air interface channel allocated by the target is 13
cdma2000
. It lists the cdma2000
channel(s) for each cell listed in the Cell 14

Identifier List that have been allocated by the target BS. The total number instances 15
of octets n through n+5 is the Physical Channel Count multiplied by the number of 16
cells in the Cell Identifier List element. This version of the standard allows for a 17
maximum of six cells for each physical channel. This element is not present if the IS- 18
95 Channel Identity element or the IS-2000 Channel Identity 3X element is present. 19
d. This element is included if the target BS indicates a desired configuration different 20
from that currently being used at the source BS. 21
e. This element contains the cdma2000
non-negotiable service configuration record to 22

support the transport of information related to IS-2000 logical to physical mapping 23
(LPM) tables, and if needed, FPC power control information. It is included if the 24
target BS provides the source BS with non-negotiable service configuration 25
parameter values that may be sent to the MS. It is up to the source BS to decide 26
whether or not to include the received non-negotiable service configuration record in 27
the Universal Handoff Direction Message / General Handoff Direction Message sent 28
to the MS. 29
TIA-2001.4-C
Section 3 192
f. These elements are only applicable when the target BS is not operating in DS-41 1
mode. 2
g. This element is only included when the target BS is operating in DS-41 mode. 3
h. This element is used when a partially successful service transfer occurs. In this case, 4
this element has only the service instances successfully transferred. 5
i. This element is used to indicate the reason for the occurrence of the partially 6
successful service transfer. In this case, this element is associated with the failed 7
service option connections. 8
j. This element is included if the air interface channel allocated by the target is 9
cdma2000
3X. It lists the cdma2000

95 Channel Identity element or the IS-2000 Channel Identity element is present. 15
k. The target BS Values Included field of this IE is hard-coded to 10 in this message. 16
17
TIA-2001.4-C
193 Section 3
The following table shows the bitmap layout for the Handoff Request Acknowledge 1
message. 2
3.4.3 Handoff Request Acknowledge
7 6 5 4 3 2 1 0 Octet
Hard
Handoff =
[1]
<any value> (Ignored)
The following 4 octets are repeated once for each entry in the Cell I dentifier List {1..6
Walsh Code Channel Index = [00H-3FH] i
Pilot PN Code (low part) = [00H-FFH] i+1
Pilot PN
Code
(high
part)
= [0,1]
Power
Combined
= [0,1]
Freq.
included
= [1]
= [000-111]
i+2
ARFCN (low part) = [00H-FFH] i+3
}
I F (Discriminator =02H) {1..6:
Omni)
(LSB) j+1
}OR I F (Discriminator =07H), Cell I dentification {1..6:
j+1
(LSB) j+2
Omni)
(LSB) j+4
! !! ! Extended Handoff Direction Parameters: A1 Element Identifier = [10H] 1
Length = [09H] 2
TIA-2001.4-C
Section 3 194
7 6 5 4 3 2 1 0 Octet
Search Window A Size (Srch_Win_A) =
[0H-FH]
Search Window N Size (Srch_Win_N)
= [0H-FH]
3
Search Window R Size (Srch_Win_R) =
[0H-FH]
Add Pilot Threshold (T_Add) high
order = [0H-FH]
4
T_Add (low order)
= [00-11]
Drop Pilot Threshold (T_Drop) = [000000-111111] 5
Compare Threshold (T_Comp)
= [0H-FH]
Drop Timer Value (T_TDrop)
= [0H-FH]
6
Neighbor Max Age (Nghbor_Max_AGE)
= [0H-FH]
Reserved =
[00]
Target BS Values
Included = [10]
7
Reserved = [00] SOFT_SLOPE = [00 0000 - 11 1111] 8
Reserved = [00] ADD_INTERCEPT = [00 0000 - 11 1111] 9
Reserved = [00] DROP_INTERCEPT = [00 0000 - 11 1111] 10
Target BS P_REV = [00H FFH] 11
! !! ! Hard Handoff Parameters: A1 Element Identifier = [16H] 1
Reserved = [000] Band Class = [0 0000 - 1 1111] 2
Number of Preamble
Frames
= [000-111]
Reset L2
= [0,1]
Reset
FPC
= [0,1]
Encryption
Mode
= [00,01]
Private
LCM
= [0,1]
3
Rev_P
wr_Cn
tl_Dela
y_Incl
= [0,1]
Rev_Pwr_Cnt
l_Delay
= [00 11]
Nom_Pwr_Ext
= [0,1]
Nom_Pwr = [0000-1111] 4
Reserved = [00] FPC Subchannel Information
= <any value>
FPC
SubCha
n Info
Included
= [0,1]
5
Reserved = [0000] Power Control Step
= <any value>
Power
Control
Step
Included
= [0,1]
6
OTD
=
[0,1]
[001, 010]
The following 6 octets are included once for each physical channel in each cell listed in the Cell
I dentifier List {1..12:
TIA-2001.4-C
195 Section 3
7 6 5 4 3 2 1 0 Octet
n
Rev_FCH
_Gating
= [0,1]
Reverse Pilot
Gating Rate
= [00, 01, 10]
QOF Mask
= [00,01,10,11]
part) = <any value>
n+1
Walsh Code Channel Index (low part) = <any value> n+2
Pilot PN Code (low part) = <any value> n+3
Pilot PN
Code
(high
part)
= [0,1]
Combined
= [0,1]
Freq.
included
= [1]
ARFCN (high part)
= [000-111]
n+4
! !! ! I S-2000 Service Configuration Record: A1 Element Identifier = [0EH] 1
Bit-Exact Length Octet Count
= [00H to FFH]
2
Reserved
= [0000 0]
= [000 to 111]
3
(MSB) 4
IS-2000 Service Configuration Record Content
= <any value>

Seventh
Fill Bit
if needed
= [0 (if
used as a
fill bit)]
Sixth Fill
Bit if
needed
= [0 (if
used as a
fill bit)]
Fifth Fill
Bit if
needed
= [0 (if
used as a
fill bit)]
Fourth
Fill Bit
if needed
= [0 (if
used as a
fill bit)]
Third
Fill Bit
if needed
= [0 (if
used as a
fill bit)]
Second
Fill Bit
if needed
= [0 (if
used as a
fill bit)]
First Fill
Bit if
needed
= [0 (if
used as a
fill bit)]
k
! !! ! IS-2000 Non-negotiable Service Configuration Record: A1 Element Identifier
= [0FH]
1
= [00H to FFH]
2
Reserved
= [0000 0]
= [000 to 111]
3
(MSB) 4
IS-2000 Non-Negotiable Service Configuration Record Content
= <any value>

TIA-2001.4-C
Section 3 196
7 6 5 4 3 2 1 0 Octet
Seventh
Fill Bit
if needed
= [0 (if
used as a
fill bit)]
Sixth
Fill Bit
if needed
= [0 (if
used as a
fill bit)]
Fifth Fill
Bit if
needed
= [0 (if
used as a
fill bit)]
Fourth
Fill Bit
if needed
= [0 (if
used as a
fill bit)]
Third
Fill Bit
if
needed
= [0 (if
used as a
fill bit)]
Second
Fill Bit
if needed
= [0 (if
used as a
fill bit)]
First Fill
Bit if
needed
= [0 (if
used as a
fill bit)]
k
! !! ! Target RNC to Source RNC Transparent Container: A1 Element Identifier
= [3AH]
1

(LSB) k
[001 - 110]
i
= [8000H (13K speech),
0003H (EVRC),
0038H (SMV),
(LSB) i+2
Length = [01H] 2
TIA-2001.4-C
197 Section 3
7 6 5 4 3 2 1 0 Octet
ext =
[0]
Cause Value =
[01H (Radio interface failure),
26H (MS not equipped),
27H (2G only sector),
28H (2G only carrier),
2BH (Alternate signaling type reject),
50H (Terrestrial circuit already allocated)
7FH (Handoff procedure time-out)]
3
OTD=
[0,1]
[001, 010]

n
Rev_FCH
_Gating
= [0, 1]
Reverse Pilot
Gating Rate
= [00, 01, 10]
QOF Mask
= [00,01,10,11]
part) = <any value>
n+1
Pilot PN
Code
(high
part)
= [0,1]
Combined
= [0,1]
Freq.
included
= [1]
ARFCN (high part)
= [000-111]
n+4
= [00,01,10,11]
value>
n+6
Lower Walsh Code Channel Index (low part) = <any value> n+7
TIA-2001.4-C
Section 3 198
7 6 5 4 3 2 1 0 Octet
= [00,01,10,11]
value>
n+8
Upper Walsh Code Channel Index (low part) = <any value> n+9
1
TIA-2001.4-C
199 Section 3
3.4.4 Handoff Command 1
This BSMAP message is sent from the MSC to the source BS to commence source cell 2
handoff procedures. This message is in response to the Handoff Required message. 3
Reference
Element
Direction
Type
RF Channel Identity 4.2.7 MSC -> BS O
a
C
b, j
C
i
C
Handoff Power Level 4.2.25 MSC -> BS O
a
C
SID 4.2.8 MSC -> BS O
a,d
C
Extended Handoff Direction Parameters 4.2.60 MSC -> BS O
c,e,j
C
Hard Handoff Parameters 4.2.51 MSC -> BS O
c,j
C
f,j
C
IS-2000 Service Configuration Record 4.2.55 MSC -> BS O
g,j
C
Record
4.2.56 MSC -> BS O
h,j
C
Target RNC to Source RNC Transparent Container 4.2.76 MSC -> BS O
k
C
Service Option List 4.2.78 MSC -> BS O
l
C
m
C
AMPS Hard Handoff Parameters 4.2.79 MSC -> BS O
a
C
IS-2000 Channel Identity 3X 4.2.23 MSC -> BS O
j, n
C
a. This element is included if the air interface channel allocated by the target is within 4
an analog system [18]. Information received from the AMPS target BS may be used 5
to populate the fields contained in this IE. 6
b. This element is included if the air interface channel allocated by the target is 7
TIA/EIA/IS-95-B. It lists each TIA/EIA/IS-95-B channel, one for each cell listed in the 8
Cell Identifier List, that has been allocated by the target BS. This element is not 9
present if the IS-2000 Channel Identity element or IS-2000 Channel Identity 3X 10
element is present. 11
c. This element is included if the air interface channel allocated by the target is 12
TIA/EIA/IS-95-B or cdma2000
. 13
d. This element is only provided for analog [18] handoffs. In the event that an 14
cdma2000
channel cannot be allocated but an analog channel is allocated and 15

identified in the RF Channel Identity element, then this element provides the SID of 16
the target. The SID is sent to the MS in the Analog Handoff Direction message from 17
the source BS. 18
e. The MSC, for intra-MSC handoffs, should use the Extended Handoff Direction 19
Parameters element supplied in the Handoff Request Acknowledge message. For 20
intra-MSC handoffs the MSC sets the Target BS Values Included field to 10. 21
For inter-MSC handoffs, the source BS uses the Target BS Values Included field to 22
determine which fields within this element were successfully conveyed from the 23
Target BS via the ANSI-41 network. Note that [9] supports only Search Window A 24
TIA-2001.4-C
Section 3 200
[Size], [27] supports Search Window A Size, Add Pilot Threshold, Drop Pilot 1
Threshold, Compare Threshold, and Drop Timer Value and [28] supports all fields of 2
the Extended Handoff Direction Parameters IE. If the source MSC received 3
parameters supported by [27], it sets the Target BS Values Included field to 01. 4
f. This element is included if the air interface channel allocated by the target is 5
cdma2000
. It lists the cdma2000

95 Channel Identity element or IS-2000 Channel Identity 3X element is present. 11
g. This element is included if the MSC receives this element from the target BS in the 12
Handoff Request Acknowledge message. 13
h. This element contains the cdma2000
non-negotiable Service configuration record 14

to support the transport of information related to IS-2000 logical to physical mapping 15
(LPM) tables, and if needed, FPC power control information. It is included if the 16
target BS provides the source BS with non-negotiable service configuration 17
parameter values that may be sent to the MS. It is up to the source BS to decide 18
whether or not to include the received non negotiable service configuration record in 19
the Universal Handoff Direction Message / General Handoff Direction Message sent 20
to the MS. 21
i. The cell(s) or channel(s) shall be identical to the cell(s) or channel(s) listed in the 22
Handoff Request Acknowledge message, provided that this does not violate 23
backwards compatibility rules. 24
j. These elements are only applicable when the target BS is not operating in DS-41 25
mode. 26
k. This element is only included when the target BS is operating in DS-41 mode. 27
l. This element is used when a partially successful service transfer occurs. In this case, 28
this element has only the service instances successfully transferred. 29
m. This element is used to indicate the reason for the occurrence of the partially 30
successful service transfer. In this case, this element is associated with the failed 31
service option connections. 32
n. This element is included if the air interface channel allocated by the target is 33
cdma2000
3X. It lists the cdma2000

95 Channel Identity element or IS-2000 Channel Identity element is present. 39
40
TIA-2001.4-C
201 Section 3
The coding of the Handoff Command message for CDMA CDMA and DS-41 hard 1
handoff is as follows. 2
3.4.4 Handoff Command
7 6 5 4 3 2 1 0 Octet
Hard
Handoff =
[1]
[001] (Ignored)
(the following 4 octets are repeated once for each entry in the Cell I dentifier List) {1..6
Walsh Code Channel Index = [00H-3FH] j
Pilot PN Code (low part) = [00H-FFH] j+1
Pilot PN
Code
(high
part)
= [0,1]
Power
Combined
= [0,1]
Freq.
included
= [1]
= [000-111]
j+2
ARFCN (low part) = [00H-FFH] j+3
}
Length = [variable] 2
I F (Discriminator =02H) , Cell I dentification {1..6:
Omni)
(LSB) j+1
}OR I F (Discriminator =07H), Cell I dentification {1..6:
j+1
(LSB) j+2
Omni)
(LSB) j+4
! !! ! SID: A1 Element Identifier = [32H] 1
Reserved
= [0]
(MSB) SID (high order) = [000 0000 111 1111] 2
TIA-2001.4-C
Section 3 202
7 6 5 4 3 2 1 0 Octet
SID (low order) = [00H-FFH] (LSB) 3
! !! ! Extended Handoff Direction Parameters: A1 Element Identifier = [10H] 1
Length = [09H] 2
Search Window A Size (Srch_Win_A) =
[0H-FH]
Search Window N Size (Srch_Win_N)
= [0H-FH]
3
Search Window R Size (Srch_Win_R) =
[0H-FH]
Add Pilot Threshold (T_Add) high
order = [0H-FH]
4
T_Add (low order)
= [00-11]
Drop Pilot Threshold (T_Drop) = [000000-111111]

5
= [0H-FH]
= [0H-FH]
6
Neighbor Max Age (Nghbor_Max_AGE)
= [0H-FH]
Reserved =
[00]
Target BS Values
Included = [00,
01, 10]
7
Reserved = [00] SOFT_SLOPE = [00 0000 - 11 1111] 8
Reserved = [00] ADD_INTERCEPT = [00 0000 - 11 1111] 9
Reserved = [00] DROP_INTERCEPT = [00 0000 - 11 1111] 10
Target BS P_REV = [00H FFH] 11
! !! ! Hard Handoff Parameters: A1 Element Identifier = [16H] 1
Reserved = [000] Band Class = [00000-11111] 2
Number of Preamble
Frames
= [000-111]
Reset L2
= [1]
Reset
FPC
= [1]
Encryption
Mode
= [00,01]
Private
LCM
= [0,1]
3
Rev_Pwr
_Cntl_D
elay_Incl
= [0, 1]
Rev_Pwr_C
ntl_Delay
= [00 11]
Nom_Pwr_Ext
= [0,1]
Nom_Pwr = [0000-1111] 4
Reserved = [00] FPC Subchannel Information
= <any value>
FPC
SubChan
Info
Included
= [0,1]
5
Reserved = [0000] Power Control Step
= <any value>
Power
Control
Step
Included
= [0,1]
6
OTD =
[0,1]
[001. 010]
TIA-2001.4-C
203 Section 3
7 6 5 4 3 2 1 0 Octet

n
Rev_FCH
_Gating
= [0, 1]
Reverse Pilot
Gating Rate
= [00, 01, 10]
QOF Mask
= [00,01,10,11]
part) = <any value>
n+1
Pilot PN
Code
(high
part)
= [0,1]
Combined
= [0,1]
Freq.
included
= [1]
ARFCN (high part)
= [000-111]
n+4
= [00H to FFH]
2
Reserved
= [0000 0]
= [000 to 111]
3
(MSB) 4
= <any value>

Seventh
Fill Bit
if needed
= [0 (if
used as a
fill bit)]
Sixth Fill
Bit if
needed
= [0 (if
used as a
fill bit)]
Fifth Fill
Bit if
needed
= [0 (if
used as a
fill bit)]
Fourth
Fill Bit
if needed
= [0 (if
used as a
fill bit)]
Third
Fill Bit
if needed
= [0 (if
used as a
fill bit)]
Second
Fill Bit
if needed
= [0 (if
used as a
fill bit)]
First Fill
Bit if
needed
= [0 (if
used as a
fill bit)]
k
! !! ! IS-2000 Non-negotiable Service Configuration Record: A1 Element Identifier
= [0FH]
1
= [00H to FFH]
2
Reserved
= [0000 0]
= [000 to 111]
3
(MSB) 4
= <any value>

TIA-2001.4-C
Section 3 204
7 6 5 4 3 2 1 0 Octet
Seventh
Fill Bit
if needed
= [0 (if
used as a
fill bit)]
Sixth Fill
Bit if
needed
= [0 (if
used as a
fill bit)]
Fifth Fill
Bit if
needed
= [0 (if
used as a
fill bit)]
Fourth
Fill Bit
if needed
= [0 (if
used as a
fill bit)]
Third
Fill Bit
if needed
= [0 (if
used as a
fill bit)]
Second
Fill Bit
if needed
= [0 (if
used as a
fill bit)]
First Fill
Bit if
needed
= [0 (if
used as a
fill bit)]
k
! !! ! Target RNC to Source RNC Transparent Container: A1 Element Identifier
= [3AH]
1

(LSB) k
Number of Service Instances = [01H-05H] 3
[001 - 110]
i
= [8000H (13K speech),
0003H (EVRC),
0038H (SMV),
(LSB) i+2
Length = [01H] 2
TIA-2001.4-C
205 Section 3
7 6 5 4 3 2 1 0 Octet
ext =
[0]
Cause Value =
3
OTD =
[0,1]
[001 - 010]

n
Rev_FCH
_Gating
= [0, 1]
Reverse Pilot
Gating Rate
= [00, 01, 10]
QOF Mask
= [00,01,10,11]
part) = <any value>
n+1
Pilot PN
Code
(high
part)
= [0,1]
Reserved =
[00]
Power
Combined
= [0,1]
Freq.
included
= [1]
ARFCN (high part)
= [000-111]
n+4
= [00,01,10,11]
value>
n+6
Lower Walsh Code Channel Index (low part) = <any value> n+7
TIA-2001.4-C
Section 3 206
7 6 5 4 3 2 1 0 Octet
= [00,01,10,11]
value>
n+8
Upper Walsh Code Channel Index (low part) = <any value> n+9
1
2
TIA-2001.4-C
207 Section 3
The coding of the Handoff Command message for CDMA AMPS hard handoff is as 1
follows. 2
7 6 5 4 3 2 1 0 Octet
! !! ! RF Channel Identity: A1 Element Identifier = [21H] 1
Color Code = [00H-FFH] 2

N-
AMPS
= [0,1]
TIA/EIA-
553
= [0,1]
3
Reserved = [000000] Timeslot Number
= [00-11]
4
Reserved = [00000] ARFCN (high part) = [000-111] 5
ARFCN (low part) = [00H-FFH] 6
! !! ! Handoff Power Level: A1 Element Identifier = [26H] 1
Length = [06H] 2
Number of Cells = [01H] 3
Reserved
= [0]
ID Type = [00,01,10]
(Discriminator 1,7,8)
Handoff Power Level = [00000-11111] 4
(MSB) LAC = [0001H-FFFFH] 5
(LSB) 6
(LSB) Sector = [0H-FH] (0H = Omni) 8
! !! ! SID: A1 Element Identifier = [32H] 1
Reserved
= [0]
(MSB) SID (high order) = [000 0000 111 1111] 2
SID (low order) = [00H-FFH] (LSB) 3
! !! ! AMPS Hard Handoff Parameters: A1 Element Identifier = [25H] 1
Length = [01H] 2
Reserved = [0000 00] Encryption Mode = [00, 01] 3
TIA-2001.4-C
Section 3 208
3.4.5 Handoff Commenced 1
This BSMAP message is used for cdma2000
hard handoffs. It is sent by the source BS 2

to the MSC to indicate that the Handoff Command message has been sent to the MS, and 3
that an acknowledgment has been received from the MS. For cdma2000
, if the Handoff 4
Command message is sent using quick repeats, the source BS may not request an 5
acknowledgment from the MS. In this case, the source BS sends the Handoff 6
Commenced message after all the quick repeats have been transmitted to the MS. 7
Reference
Element
Direction
Type
The following table shows the bitmap layout for the Handoff Commenced message. 8
3.4.5 Handoff Commenced
7 6 5 4 3 2 1 0 Octet
9
10
TIA-2001.4-C
209 Section 3
3.4.6 Handoff Complete 1
This BSMAP message is sent from the target BS to the MSC to inform the MSC that the 2
MS has arrived on the new channel and has completed all (if any) required connection 3
procedures. This message is only used for CDMA-CDMA hard handoff and hard handoff 4
to or from DS-41 systems. 5
Reference
Element
Direction
Type
a
C
a. This information element is included only during packet data intergeneration 6
handoff. 7
The following table shows the bitmap layout for the Handoff Complete message. 8
3.4.6 Handoff Complete
7 6 5 4 3 2 1 0 Octet
= [0021H (3G High Speed Packet Data)]
0016H (High Speed Packet Data Service),
0019H (High Speed Packet Data Service)]
(LSB) 3
9
10
TIA-2001.4-C
Section 3 210
3.4.7 Handoff Required Reject 1
This BSMAP message is sent from the MSC to the BS. It indicates to the BS that it was 2
not possible to execute a handoff as requested. 3
Reference
Element
Direction
Type
Cause 4.2.16 MSC -> BS M
The following table shows the bitmap layout for the Handoff Required Reject message. 4
3.4.7 Handoff Required Reject
7 6 5 4 3 2 1 0 Octet
Length = [01H] 2
2AH (Handoff blocked),
3
5
6
TIA-2001.4-C
211 Section 3
3.4.8 Handoff Failure 1
This BSMAP message is sent from the BS to the MSC. It indicates to the MSC that there 2
has been a failure in the resource allocation process on an inter-BS handoff, and that the 3
handoff has been aborted. 4
Reference
Element
Direction
Type
The following table shows the bitmap layout for the Handoff Failure message. 5
3.4.8 Handoff Failure
7 6 5 4 3 2 1 0 Octet
Length = [01H] 2
3
6
TIA-2001.4-C
Section 3 212
3.4.9 Handoff Performed 1
This BSMAP message is sent from the BS to the MSC to indicate that the BS has 2
performed an internal handoff that has resulted in the change of the designated cell, 3
bandclass or frequency. The handoff may have been internal or in conjunction with 4
another BS. The purpose of this message is to update the call configuration for the MSC. 5
The Cell Identifier List is included for billing, trace, etc. 6
Reference
Element
Direction
Type
Cell Identifier List 4.2.18 BS -> MSC O
a
R
Channel Number 4.2.5 BS -> MSC O
b
C
Band Class 4.2.80 BS -> MSC O
c
C
a. The MSC shall consider the first cell in the Cell Identifier List to be the designated 7
cell. 8
b. The Channel Number IE is included when the CDMA Channel Number is altered. 9
c. The Band Class IE is included when the Band Class is altered. 10
The following table shows the bitmap layout for the Handoff Performed message. 11
3.4.9 Handoff Performed
7 6 5 4 3 2 1 0 Octet
Length = [01H] 2
[02H (uplink quality),
03H (uplink strength),
04H (downlink quality),
05H (downlink strength),
06H (distance),
1BH (inter-BS soft handoff drop target),
0EH (better cell),
0FH (interference),
1DH (intra-BS soft handoff drop target)]
3
TIA-2001.4-C
213 Section 3
3.4.9 Handoff Performed
7 6 5 4 3 2 1 0 Octet
I F (Discriminator =02H), Cell I dentification {1..6:
Omni)
(LSB) j+1
}OR I F (Discriminator =07H) ), Cell I dentification {1..6:
j+1
(LSB) j+2
Omni)
(LSB) j+4
! !! ! Channel Number: A1 Element Identifier = [23H] 1
Reserved = [0 0000] ARFCN High Part (MSB) =
[000 111]
2
ARFCN Low Part (LSB) = [00H FFH] 3
! !! ! Band Class: A1 Element Identifier = [37H] 1
Length = [01H] 2
Reserved = [000] Band Class = [0 0000 0 1010] 3
1
TIA-2001.4-C
Section 3 214
3.5 Facility Management Message Formats 1
2
3.5.1 Block 3
terrestrial circuits shall be blocked at the MSC, and cannot therefore be used for traffic. 5
Reference
Element
Direction
Type
Circuit Identity Code 4.2.19 BS -> MSC M
a

Circuit Group 4.2.70 BS -> MSC O
b
C
a. This cause value applies to all circuits identified in this message. 6
b. If this element is present it shall include the value found within the Circuit Identity 7
Code element as the first value represented within its range of circuit identity code 8
values. 9
The following table shows the bitmap layout for the Block message. 10
3.5.1 Block
7 6 5 4 3 2 1 0 Octet
(LSB) Timeslot = [00000-11111] 3
Length = [01H] 2
ext =
[0]
Cause Value =
21H (No radio resource available)]
3
! !! ! Circuit Group : A1 Element Identifier = [19H] 1
Reserved = [000000] All
Circuits
= [0,1]
Inclusive
= [0,1]
3
Count = [01H to FFH] 4
(MSB) First CIC: PCM Multiplexer = <any value> 5
TIA-2001.4-C
215 Section 3
3.5.1 Block
7 6 5 4 3 2 1 0 Octet
(LSB) Timeslot = [00000-11111] 6
(first
unused
bit - if
any)
(second
unused
bit - if
any)
(third
unused
bit - if
any)
(fourth
unused
bit - if
any)
(fifth
unused
bit - if
any)
(sixth
unused
bit - if
any)
(seventh
unused
bit - if
any)

7
Circuit Bitmap = <any value> 8

(corresp
to value
in First
CIC
field)

k
1
2
TIA-2001.4-C
Section 3 216
3.5.2 Block Acknowledge 1
The MSC sends this BSMAP message to BS to acknowledge the receipt of an earlier 2
Block message, and to indicate that the circuits concerned have been removed from 3
service. 4
Reference
Element
Direction
Type
Circuit Identity Code 4.2.19 MSC -> BS M
a

a. This element is the same as the one received in the Block message. 5
The following table shows the bitmap layout for the Block Acknowledge message. 6
3.5.2 Block Acknowledge
7 6 5 4 3 2 1 0 Octet
(LSB) Timeslot = [00000-11111] 3
7
8
TIA-2001.4-C
217 Section 3
3.5.3 Unblock 1
terrestrial resources may be returned to service at the MSC, and can therefore be used for 3
traffic. 4
Reference
Element
Direction
Type
Circuit Identity Code 4.2.19 BS -> MSC M
Circuit Group 4.2.70 BS -> MSC O
a,b
C
a. If this element is present it shall include the value found within the Circuit Identity 5
values. 7
b. This element shall not be sent to implementations of the CDG IOS earlier than IOS 8
v3.1.0. 9
The following table shows the bitmap layout for the Unblock message. 10
3.5.3 Unblock
7 6 5 4 3 2 1 0 Octet
(LSB) Timeslot = [00000-11111] 3
! !! ! Circuit Group: A1 Element Identifier = [19H] 1
Circuits
= [0,1]
Inclusive =
[0,1]
3
(LSB) Timeslot = [00000-11111] 6
(first
unused
bit - if
any)
(second
unused
bit - if
any)
(third
unused
bit - if
any)
(fourth
unused
bit - if
any)
(fifth
unused
bit - if
any)
(sixth
unused
bit - if
any)
(seventh
unused
bit - if
any)
7

TIA-2001.4-C
Section 3 218
3.5.3 Unblock
7 6 5 4 3 2 1 0 Octet
(corresp to
value in
First CIC
field)

k
1
TIA-2001.4-C
219 Section 3
3.5.4 Unblock Acknowledge 1
The MSC sends this BSMAP message to BS to acknowledge the receipt of an earlier 2
Unblock message, and to indicate that the circuits concerned have been returned to 3
service. 4
Reference
Element
Direction
Type
Circuit Identity Code 4.2.19 MSC -> BS M
The following table shows the bitmap layout for the Unblock Acknowledge message. 5
3.5.4 Unblock Acknowledge
7 6 5 4 3 2 1 0 Octet
(LSB) Timeslot = [00000-11111] 3
6
7
TIA-2001.4-C
Section 3 220
3.5.5 Reset Circuit 1
This BSMAP message can be sent either from the BS to the MSC or from the MSC to the 2
BS. It indicates to the receiving entity that the state of the circuits indicated in the 3
message is unknown. 4
This message is sent as a connectionless message. 5
Reference
Element
Direction
Type
Circuit Identity Code 4.2.19 BS <-> MSC M
Cause 4.2.16 BS <-> MSC M
a

Circuit Group 4.2.70 BS <-> MSC O
b,c
C
a. This cause value applies to all circuits identified in this message. 6
b. If this element is present it shall include the value found within the Circuit Identity 7
values. 9
c. This element shall not be sent to implementations of the CDG IOS earlier than IOS 10
v3.1.0. 11
The following table shows the bitmap layout for the Reset Circuit message. 12
3.5.5 Reset Circuit
7 6 5 4 3 2 1 0 Octet
(LSB) Timeslot = [00000-11111] 3
Length = [01H] 2
ext =
[0]
Cause Value =
09H (Call processing),
20H (Equipment failure)]
3
! !! ! Circuit Group: A1 Element Identifier = [19H] 1
Circuits
= [0,1]
Inclusive
= [0,1]
3
TIA-2001.4-C
221 Section 3
3.5.5 Reset Circuit
7 6 5 4 3 2 1 0 Octet
(LSB) Timeslot = [00000-11111] 6
(first
unused
bit - if
any)
(second
unused
bit - if
any)
(third
unused
bit - if
any)
(fourth
unused
bit - if
any)
(fifth
unused
bit - if
any)
(sixth
unused
bit - if
any)
(seventh
unused
bit - if
any)
7

(corresp
to value
in First
CIC
field)

k
1
2
TIA-2001.4-C
Section 3 222
3.5.6 Reset Circuit Acknowledge 1
This BSMAP message can be sent either from the BS to the MSC, or from the MSC to 2
the BS. It indicates to the receiving entity that the transmitting entity has cleared any 3
possible calls using the specified circuits (i.e., the circuits are idled). 4
Reference
Element
Direction
Type
Circuit Identity Code 4.2.19 BS <-> MSC M
The following table shows the bitmap layout for the Reset Circuit Acknowledge message. 5
3.5.6 Reset Circuit Acknowledge
7 6 5 4 3 2 1 0 Octet
(LSB) Timeslot = [00000-11111] 3
6
7
TIA-2001.4-C
223 Section 3
3.5.7 Reset 1
This BSMAP message can be sent either from the BS to the MSC or from the MSC to the 2
BS. It indicates to the receiving entity that the transmitting entity has failed and has lost 3
memory of the calls in progress, calls set up, and associated references. 4
This message is sent as a connectionless message. 5
Reference
Element
Direction
Type
Cause 4.2.16 BS <-> MSC M
Software Version 4.2.52 BS <-> MSC O R
The following table shows the bitmap layout for the Reset message. 6
3.5.7 Reset
7 6 5 4 3 2 1 0 Octet
3
! !! ! Software Version: A1 Element Identifier = [31H] 1
IOS Major Revision Level (X) = [04H] 3
IOS Minor Revision Level (Y) = [03H] 4
IOS Point Release Level (Z) = [00H] 5
Manufacturer/Carrier Software Information = <printable ASCII character> 6

Manufacturer/Carrier Software Information = <printable ASCII character> n
7
8
TIA-2001.4-C
Section 3 224
3.5.8 Reset Acknowledge 1
This BSMAP message can be sent either from the BS to the MSC, or from the MSC to 2
the BS. It indicates to the receiving entity that the transmitting entity has cleared all calls 3
and reset all references, and is ready to resume service. If sent by the MSC, it also 4
indicates that all MSC-BS terrestrial circuits have been idled. 5
Reference
Element
Direction
Type
Software Version 4.2.52 BS <-> MSC O R
The following table shows the bitmap layout for the Reset Acknowledge message. 6
3.5.8 Reset Acknowledge
7 6 5 4 3 2 1 0 Octet

7
8
TIA-2001.4-C
225 Section 3
3.5.9 Transcoder Control Request 1
This BSMAP message is sent from the MSC to the BS to change the state of the inband 2
signaling mechanism at the BS. A disable directive also results in the BS reverting to 3
tandem vocoding mode if already in tandem free operation. 4
Reference
Element
Direction
Type
Message Type 4.2.4 MSC->BS M
Transcoder Mode 4.2.47 MSC->BS M
The following table shows the bitmap layout for the Transcoder Control Request 5
message. 6
3.5.9 Transcoder Control Request
7 6 5 4 3 2 1 0 Octet
! !! ! Transcoder Mode: A1 Element Identifier = [36H] 1
Length = [01H] 2
Reserved = [0000 000] TFO
Mode
=[0,1]
3
TIA-2001.4-C
Section 3 226
3.5.10 Transcoder Control Acknowledge 1
This BSMAP message is sent from the BS to the MSC to acknowledge whether tandem 2
free operation was successfully enabled or disabled in response to the MSCs mode 3
setting request. 4
Reference
Element
Direction
Type
Message Type 4.2.4 BS->MSC M
Cause 4.2.16 BS->MSC O
a

a. If this element is not present, then tandem free operation was either successfully 5
established or disabled (depending on the directive from the MSC). If the element is 6
present, its only allowable value is TFO Control Request Failed. This value is used 7
when the MSC directive received in the Transcoder Control Request could not be 8
accomplished. 9
The following table shows the bitmap layout for the Transcoder Control Request 10
message. 11
3.5.10 Transcoder Control Acknowledge
7 6 5 4 3 2 1 0 Octet
Length = [01H] 2
ext = [0] Cause Value = [33H (TFO control request failed)] 3
12
13
TIA-2001.4-C
227 Section 3
3.6 Application Data Delivery Service (ADDS) Message Formats 1
2
3.6.1 ADDS Page 3
This BSMAP message is sent from the MSC to the BS to request delivery of an 4
application data message on the paging channel. 5
Reference
Element
Direction
Type
Mobile Identity (IMSI/Broadcast Address) 4.2.13 MSC -> BS M
a
ADDS User Part 4.2.54 MSC -> BS M
b
c
C
d
C
e,f
C
f, h
C
g
C
a. This element contains IMSI or Broadcast Address. 6
b. This element contains the application data information to be sent to the mobile user, 7
encoded using the syntax appropriate for the current radio channel and service type. 8
In the case of the Short Message Service, the ADDS User Part contains an 9
application type field indicating Short Message Service. In the case of the Position 10
Location Data, the ADDS User Part contains an application type field indicating 11
Position Location Data. In the case of the Short Data Burst, the ADDS User Part 12
contains an application type field indicating Short Data Burst. 13
c. If this element is present in this message, the value shall be saved at the BS to be 14
included if an ADDS Page Ack message is sent in response to this message. 15
d. The cell identifiers indicate the cells and location areas in which the BS is to attempt 16
delivery of the message. When the Cell Identifier information element is absent, the 17
BS shall attempt delivery in all cells controlled by the BS. 18
e. This element is included when slotted paging is performed on cdma2000
paging 19
paging channel. In cdma2000
systems, if this element is absent, then it is assumed 21

that the MS is operating in non-slotted mode. Note: For SMS Broadcast, the presence 22
or absence of this element does not indicate the slotted/non-slotted operating mode 23
of the MS. 24
f. This element shall not be included when the BS and MS are operating in DS-41 25
mode. 26
g. This element contains the MSs MOB_P_REV of the current band class and shall be 27
h. If the MSC does not have the information required to correctly populate a field in 29
31
TIA-2001.4-C
Section 3 228
The following table shows the bitmap layout for the ADDS Page message. 1
3.6.1 ADDS Page
7 6 5 4 3 2 1 0 Octet
I F (Type of I dentity in octet 3 =110), Mobile I dentity {1:
Indicator
= [1,0]
Type of Identity =
[110 (IMSI)]
3

}OR I F (Type of I dentity in octet 3 =010), Mobile I dentity {1:
Reserved = [0000 0] Type of Identity =
[010 Broadcast Identifier]
3
Priority = [00 11] Message ID = [00 0000 11 1111] 4
Zone ID = [00H FFH] 5
(MSB) Service = [0000H FFFFH] 6
(LSB) 7
Language = [00H FFH] 8
}Mobile I dentity
Reserved = [00] Data Burst Type =
[03H (SMS),
05H (PLD),
06H (Short Data Burst)]
3

(LSB) n
3
4
TIA-2001.4-C
229 Section 3
3.6.1 ADDS Page
7 6 5 4 3 2 1 0 Octet
(LSB) 5
(LSB) j+1
Reserved
= [00]
ERAM
Supported =
[0,1]
DCCH
Supported
= [0,1]
FCH
Supported
= [0,1]
OTD
Supported
= [0,1]
Enhanced
RC CFG
Supported
= [0,1]
QPCH
Supported
= [0,1]
3
= [00H to FFH]
4
Reserved
= [0]
value> (Ignored)
Geo
Location
Included
= <any
value>
(Ignored)
FCH Information:
= [000 to 111]
5
(MSB) 6
= <any value>

Seventh
Fill Bit
if
needed
= [0 (if
used as
a fill
bit)]
Sixth
Fill Bit
if
needed
= [0 (if
used as
a fill
bit)]
Fifth Fill
Bit if
needed
= [0 (if
used as a
fill bit)]
Fourth
Fill Bit
if needed
= [0 (if
used as a
fill bit)]
Third Fill
Bit if
needed
= [0 (if used
as a fill bit)]
Second
Fill Bit
if needed
= [0 (if
used as a
fill bit)]
First Fill
Bit if
needed
= [0 (if
used as a
fill bit)]
k
= [00H to FFH]
k+1
TIA-2001.4-C
Section 3 230
3.6.1 ADDS Page
7 6 5 4 3 2 1 0 Octet
Reserved
= [0000 0]
DCCH Information:
= [000 to 111]
k+2
(MSB) k+3
= <any value>

Seventh
Fill Bit
if
needed
= [0 (if
used as
a fill
bit)]
Sixth
Fill Bit
if
needed
= [0 (if
used as
a fill
bit)]
Fifth Fill
Bit if
needed
= [0 (if
used as a
fill bit)]
Fourth
Fill Bit
if needed
= [0 (if
used as a
fill bit)]
Third Fill
Bit if
needed
= [0 (if used
as a fill bit)]
Second
Fill Bit
if needed
= [0 (if
used as a
fill bit)]
First Fill
Bit if
needed
= [0 (if
used as a
fill bit)]
m
Length = [01H] 2
1
TIA-2001.4-C
231 Section 3
3.6.2 ADDS Page Ack 1
This BSMAP message is sent from the BS to the MSC to indicate that the BS received a 2
Layer 2 Ack from the MS indicating that the point-to-point application data message was 3
successfully delivered, or that the BS received the ADDS Page message to send an SMS 4
broadcast message, or that the ADDS message was too long for delivery on the Paging 5
channel, or that an internal BS failure has occurred with respect to the ability to complete 6
an ADDS Page activity. 7
Reference
Element
Direction
Type
Mobile Identity (IMSI/Broadcast Address) 4.2.13 BS -> MSC M
a
e
R
b
C
c
C
Cell Identifier 4.2.17 BS -> MSC O
d
C
a. This element contains an IMSI or Broadcast Address. 8
b. The second occurrence of the Mobile Identity element contains the ESN, if it is 9
available at the Base Station. This element is required if the ESN is received from 10
the MS. 11
c. This element is used to indicate an error situation. In particular, this element can be 12
used to carry information to the MSC that the ADDS User Part element contained in 13
the ADDS Page message is too long to be carried on the paging channel. 14
d. This element identifies the cell where the air interface acknowledgement was 15
received corresponding to the paging channel message sent as a result of an ADDS 16
Page message. This element is not included for SMS Broadcast. 17
e. This information element contains the same value received in the ADDS Page 18
message. 19
The following table shows the bitmap layout for the ADDS Page Ack message. 20
3.6.2 ADDS Page Ack
7 6 5 4 3 2 1 0 Octet
I F (Type of I dentity in octet 3 =110), Mobile I dentity {1:
Indicator
= [1,0]
Type of Identity
= [110] (IMSI)
3
TIA-2001.4-C
Section 3 232
3.6.2 ADDS Page Ack
7 6 5 4 3 2 1 0 Octet

}OR I F {Type of I dentity in octet 3 =010), Mobile I dentity {1:
Reserved = [0000 0] Type of Identity = [010 (Broadcast
Identifier)]
3
Priority =
[00-11]
Message ID=[00 0000 - 11 1111] 4
Zone ID = [00H FFH] 5
(MSB) Service = [00 00H FF FFH] 6

(LSB) 7
Language = [00H FFH] 8
}Mobile I dentity
3
4
(LSB) 5
Length = [05H] 2
Indicator
= [0]
Type of Identity
= [101] (ESN)
3
5
6
(LSB) 7
Length = [01H] 2
[20H (equipment failure),
71H (ADDS message too long for delivery on paging channel)]
3
Length = [03H] 2
TIA-2001.4-C
233 Section 3
3.6.2 ADDS Page Ack
7 6 5 4 3 2 1 0 Octet
Omni)
(LSB) 5
1
2
TIA-2001.4-C
Section 3 234
3.6.3 ADDS Transfer 1
This BSMAP message is sent from the BS to the MSC whenever an application data 2
message is received from the MS on the access channel. It is also sent from the BS to the 3
MSC to transfer authentication parameters when an MS originates a Short Data Burst, 4
requests CCPD mode, or requests dormant handoff from the network. 5
Reference
Element
Direction
Type
ADDS User Part 4.2.54 BS -> MSC M
a
b
C
Authentication Response Parameter AUTHR 4.2.38 BS -> MSC O
c
C
Authentication Confirmation Parameter RANDC 4.2.35 BS -> MSC O
d
C
e
C
Authentication Challenge Parameter RAND 4.2.37 BS -> MSC O
f
C
g
C
Cell Identifier 4.2.17 BS -> MSC O
h
R
i
C
Authentication Data 4.2.66 BS -> MSC O
j
C
k
C
l, m,q
C
l,n,o
C
l,q
C
l
C
l,o,p,r
C
a. This element contains the application data information that was received from the 6
MS. In the case of Short Message Service the application data information is the 7
Short Message. In the case of the Position Location Data, the application data 8
information is the Position Location Data. An application type field in this element is 9
used to distinguish the application, e.g., Short Message, Position Location Data, 10
Short Data Burst or Asynchronous Data Services. In the case of Short Data Burst, 11
the application data message field is not included but the burst type field is included 12
and set to short data burst. 13
b. The second occurrence of the Mobile Identity element contains the ESN, if it is 14
available at the base station. 15
c. This element is included when broadcast authentication is performed and contains 16
the Authentication Response Parameter, AUTHR, as computed by the MS. 17
d. This element contains the RANDC received from the MS. RANDC shall be included 18
e. This element is included when broadcast authentication is performed and contains 20
the MSs call history count for authentication operations. 21
f. This element is included when broadcast authentication is performed and contains 22
TIA-2001.4-C
235 Section 3
g. This element is present when an authentication enabled BS does not receive the 3
h. This element identifies the cell where the application data (e.g., SMS-MO) was 6
received from the MS. Discriminator type 0000 0010 (Cell ID) may be used in the 7
ADDS Transfer message. For more information, refer to section 4.2.17. 8
i. This element is included if the data burst type is set to 05H (PLD), if applicable to 9
the geo-location technology, and if this technology is supported at the base station. 10
j. This element is included if the BS determines that authentication should be applied. 11
k. These elements are required when the ADDS user part element data burst type field 12
is set to SDB for Short Data Burst or Asynchronous Data Services for dormant 13
handoff, and shall be returned in the ADDS Transfer Ack message. 14
l. This element is included if the message is triggered by an Origination Message from 15
the MS. 16
m. When the BS is operating in DS-41 mode, only the following fields in the Classmark 17
Air Interfaces Supported, Band Class n MS Protocol Level. 21
n. This element applies only to MSs operating in slotted mode (discontinuous 22
termination to the MS to ensure that the Paging Message is broadcast in the paging 25
channel slots monitored by the MS. 26
o. These elements shall not be included by the BS when the BS and MS are operating 27
in DS-41 mode. 28
p. This element is only included when the MS operates at revision level 6 or greater as 29
q. If any of these elements are not correctly present in case of dormant handoff, failure 31
handling may be initiated by the MSC. 32
r. If the BS does not have the information required to correctly populate a field in this 33
The following table shows the bitmap layout for the ADDS Transfer message. 35
3.6.3 ADDS Transfer
7 6 5 4 3 2 1 0 Octet
TIA-2001.4-C
Section 3 236
3.6.3 ADDS Transfer
7 6 5 4 3 2 1 0 Octet
n
Indicator
= [1,0]
Type of Identity
= [110] (IMSI)
3

Reserved =
[00]
Data Burst Type =
[01H (Asynchronous Data Services),
03H (SMS),
05H (PLD),
3

(LSB) n
Length = [05H] 2
Identity Digit 1 = [0000] Odd/eve
n
Indicator
= [0]
Type of Identity
= [101] (ESN)
3
5
6
(LSB) 7
Length = [04H] 2
[0] [0] [0] [0] [0] [0] (MSB) 4
(LSB) 6
! !! ! Authentication Confirmation Parameter (RANDC): A1 Element Identifier =
[28H]
1
RANDC = [00H-FFH] 2
TIA-2001.4-C
237 Section 3
3.6.3 ADDS Transfer
7 6 5 4 3 2 1 0 Octet
Reserved =
[00]
Count = [000000-111111] 2
Length = [05H] 2
5
6
(LSB) 7
Length = [01H] 2
Event = [01H, 02H]
3
Length = [03H] 2
I F (Discriminator =02H) , Cell I dentification {1:
5
(LSB) 6
(LSB) k+1
TIA-2001.4-C
Section 3 238
3.6.3 ADDS Transfer
7 6 5 4 3 2 1 0 Octet
(LSB) k+4
! !! ! Authentication Data: A1 Element Identifier = [59H] 1
Length = [03H] 2
(MSB) Auth-Data = <any value> 3
4
(LSB) 5
3
4
(LSB) 5
MOB_P_REV
= [000 111]
Reserv
ed =
[0]
See
List of
Entries
= [0,1]

3
Reserved = [00H] 4

NAR_AN_C
AP
= [0,1]
IS-95
= [1]
Slotte
d
= [0,1]
Reserved = [00]

DTX
= [0,1]
Mobile
Term
= [0,1]
TIA/EIA-
553
= [0,1]
5
Reserved = [00H]

6
Reserved = [000000]

Mobile
Term
= [0,1]
PSI
= [0,1]
7
TIA-2001.4-C
239 Section 3
3.6.3 ADDS Transfer
7 6 5 4 3 2 1 0 Octet
(LSB) 3
Length = [02H] 2
(LSB) 4
Reserved
= [00]
ERAM Supported
= [0,1]
DCCH
Suppor
ted
= [0,1]
FCH
Support
ed
= [0,1]
OTD
Support
ed
= [0,1]
Enhanced RC
CFG Supported
= [0,1]
QPCH
Supported
= [0,1]
3
= [00H to FFH]
4
Reserve
d
= [0]
Geo Location Type = [000,
001, 010, 011]
Geo
Location
Included
= [0,1]
FCH Information:
= [000 to 111]
5
(MSB) 6
= <any value>

Seventh
Fill Bit
if
needed
= [0 (if
used as
a fill
bit)]
Sixth
Fill Bit
if
needed
= [0 (if
used as
a fill
bit)]
Fifth
Fill Bit
if
needed
= [0 (if
used as
a fill
bit)]
Fourth
Fill Bit
if
needed
= [0 (if
used as
a fill
bit)]
Third
Fill
Bit
if
neede
d
= [0
(if
used
as a
fill
bit)]
Second Fill Bit
if needed
= [0 (if used as
a fill bit)]
First Fill
Bit if
needed
= [0 (if
used as a
fill bit)]
k
= [00H to FFH]
k+1
Reserved
= [0000 0]
DCCH Information:
= [000 to 111]
k+2
(MSB) k+3
= <any value>

TIA-2001.4-C
Section 3 240
3.6.3 ADDS Transfer
7 6 5 4 3 2 1 0 Octet
Seventh
Fill Bit
if
needed
= [0 (if
used as
a fill
bit)]
Sixth
Fill
Bit
if
neede
d
= [0
(if
used
as a
fill
bit)]
Fifth
Fill Bit
if
needed
= [0 (if
used as
a fill
bit)]
Fourth
Fill Bit
if
needed
= [0 (if
used as
a fill
bit)]
Third
Fill
Bit
if
neede
d
= [0
(if
used
as a
fill
bit)]
Second Fill Bit
if needed
= [0 (if used as a
fill bit)]
First Fill
Bit if
needed
= [0 (if
used as a
fill bit)]
m
1
TIA-2001.4-C
241 Section 3
3.6.4 ADDS Transfer Ack 1
This BSMAP message is sent from the MSC to the BS to indicate the result of the 2
authentication for a MS which has sent a Short Data Burst, requested CCPD Mode or 3
requested dormant handoff from the network. This message may be sent twice in the case 4
of dormant handoff. The first message is sent to the BS to indicate that authentication is 5
done in parallel and the BS can continue with the dormant handoff. The second message 6
is sent to the BS to indicate the result of the authentication. 7
Reference
Element
Direction
Type
a
C

b
C

a. The MSC copies the tag field from the ADDS Transfer message sent by the BS into 8
the tag field in the ADDS Transfer Ack message. 9
b. If the cause value is set to Concurrent Authentication for a dormant mode handoff, 10
the MSC shall resend the ADDS Transfer Ack message to the BS when the 11
authentication results are received provided that the MSC has not received a CM 12
Service Request from the BS prior to authentication results being received. If this 13
element is not present in the response, the authentication was successful. 14
The following table shows the bitmap layout for the ADDS Transfer Ack message. 15
3.6.4 ADDS Transfer Ack
7 6 5 4 3 2 1 0 Octet
! Mobile Identity (IMSI): A1 Element Identifier = [0DH] 1
Indicator
= [1,0]
Type of Identity
= [110] (IMSI)
3

3
4
(LSB) 5
TIA-2001.4-C
Section 3 242
3.6.4 ADDS Transfer Ack
7 6 5 4 3 2 1 0 Octet
Length = [01H] 2
Ext =
[0]
Cause Value =
[15H (Short data burst authentication failure),
1AH (Authentication failure),
7BH (Concurrent authentication)]
3
1
TIA-2001.4-C
243 Section 3
3.6.5 ADDS Deliver 1
This DTAP message is sent from the MSC to the BS to request delivery of an application 2
data message to an MS on a traffic channel. This message can also be sent from the BS to 3
the MSC to deliver an application data message received on the traffic channel. 4
Reference
Element
Direction
Type
Protocol Discriminator 4.2.32 MSC <-> BS M
Reserved Octet 4.2.33 MSC <-> BS M
Message Type 4.2.4 MSC <-> BS M
ADDS User Part 4.2.54 MSC <-> BS M
a,d
b
C
CDMA Serving One Way Delay 4.2.61 BS->MSC O
c
C
a. This element contains the application data information that was received from the 5
MS. An application type field in this element is used to distinguish the application, 6
e.g., Short Message. In the case of Short Message Service, the application data 7
information is the Short Message. In the case of Position Location Data, the 8
application data information is the Position Location Data. In the case of Over- 9
The-Air, the application data information is the Over-The-Air data. In the case of 10
Short Data Burst or Asynchronous Data Service, the application data message 11
field is not included. 12
b. If this element is used in this message, it shall be returned to the MSC in the ADDS 13
Deliver Ack. 14
c. This element is included if the data burst type is set to05H (PLD), if applicable to 15
the geo-location technology, and if this technology is supported at the base station. 16
d. Because this information element is sent as a mandatory information element in a 17
The following table shows the bitmap layout for the ADDS Deliver message. 19
3.6.5 ADDS Deliver
7 6 5 4 3 2 1 0 Octet
! !! ! ADDS User Part: Length = <variable> 1
[03H (SMS),
04H (OTA),
05H (PLD),
2
TIA-2001.4-C
Section 3 244
3.6.5 ADDS Deliver
7 6 5 4 3 2 1 0 Octet

(LSB) n
3
4
(LSB) 5
Omni)
(LSB) j+1
j+1
(LSB) j+2
Omni)
(LSB) j+4
(LSB) k+1
(LSB) k+4
1
2
TIA-2001.4-C
245 Section 3
3.6.6 ADDS Deliver Ack 1
This DTAP message shall be sent from the BS to the MSC when a Layer 2 Ack from the 2
MS has been received at the BS for an ADDS Deliver message that contains a Tag 3
element. 4
Reference
Element
Direction
Type
Tag 4.2.50 BS -> MSC O R
a
C
a. Used to indicate an error situation. 5
The following table shows the bitmap layout for the ADDS Deliver Ack message. 6
3.6.6 ADDS Deliver Ack
7 6 5 4 3 2 1 0 Octet
3
4
(LSB) 5
Length = [01H] 2
[34H (MS rejected order)]
3
7
8
TIA-2001.4-C
Section 3 246
3.7 Error Handling Messages 1
This section contains messages used for general error handling. 2
3.7.1 Rejection 3
The Rejection message is used by the BS to indicate to the MSC that the MS has 4
indicated rejection of a command/message. This is coded as a BSMAP message when 5
triggered by a Mobile Station Reject Order on the access channel and a DTAP message 6
otherwise. 7
This message shall not be used in DS-41 systems. 8
Reference
Element
Direction
Type
a

a

b
R
c
C
IS-2000 Cause Value 4.2.64 BS -> MSC O
d
R
e
C
a. These elements are not used in BSMAP messages and shall be included in a DTAP 9
message. 10
b. Thise element is not used in DTAP messages and shall be included in a BSMAP 11
message. 12
c. If the ESN is available at the BS, this element shall contain the ESN. 13
d. This element contains the cause indication sent by the MS in a Mobile Station Reject 14
Order. 15
e. This element is required if concurrent services are supported. This is only included 16
when the message is sent as DTAP. 17
When the Rejection message is sent as a BSMAP message, the following format applies. 18
3.7.1 Rejection
7 6 5 4 3 2 1 0 Octet
Indicator
= [1,0]
Type of Identity
= [110] (IMSI)
3
TIA-2001.4-C
247 Section 3
3.7.1 Rejection
7 6 5 4 3 2 1 0 Octet

Length = [05H] 2
Indicator
= [0]
Type of Identity
= [101] (ESN)
3
5
6
(LSB) 7
! !! ! I S-2000 Cause Value: A1 Element Identifier = [62H] 1
Length = [01H] 2
IS-2000 Cause Information = <any value> 3
1
When the Rejection message is sent as a DTAP message, the following format applies. 2
3.7.1 Rejection
7 6 5 4 3 2 1 0 Octet
! !! ! I S-2000 Cause Value: A1 Element Identifier = [62H] 1
Length = [01H] 2
IS-2000 Cause Information = <any value> 3
Length = [01H] 2
[001 - 110]
3
3
4
TIA-2001.4-C
Section 3 248
3.8 NDSS Message Formats 1
2
3.8.1 Service Redirection 3
This DTAP message is sent from the MSC to the BS to request that the BS redirect the 4
MS to another system. 5
Reference
Element
Direction
Type
IS-2000 Redirection Record 4.2.86 MSC -> BS O R
Service Redirection Info 4.2.88 MSC -> BS O R
Mobile Identity (IMSI) 4.2.13 MSC -> BS O R
b
C
a
C
a. This element contains the MSs MOB_P_REV of the current band class and shall be 6
b. If the ESN is available at the MSC, the second occurrence of the Mobile Identity 8
element shall be included and shall contain the ESN. 9
The following table shows the bitmap layout for the Service Redirection message. 10
3.8.1 Service Redirection
7 6 5 4 3 2 1 0 Octet
! !! ! Reserved - Octet = [00H] 1
! !! ! IS-2000 Redirection Record: A1 Element Identifier = [67H] 1
Redirection Record Type = [00H 04H] 3
Redirection Record Length = <variable> 4
(MSB) Redirection Record Content = <any value> 5

(LSB) j
! !! ! Service Redirection Info: A1 Element Identifier = [69H]
1
TIA-2001.4-C
249 Section 3
3.8.1 Service Redirection
7 6 5 4 3 2 1 0 Octet
Length = [03H]
2
Reserved = [000] Excl_P_
REV_Ind
= [0, 1]
Redirect
_P_REV
_Incl =
[0, 1]
Redirect
Type =
[0, 1]
Reserved
= [0]
Return If
Fail =
[0, 1]
3
(MSB)
REDIRECT_P_MIN = [06H FFH]
(LSB) 4
(MSB)
REDIRECT_P_MAX = [06H - FFH]
(LSB) 5
Length = [06H-08H] (10-15 digits)
n
Indicator
= [1,0]
Type of Identity
= [110] (IMSI)
2

Length = [05H] 2
Indicator
= [0]
Type of Identity
= [101] (ESN)
3
5
6
(LSB) 7
Length = [01H] 2
MOB_P_REV = [07H] 3
1
2
TIA-2001.4-C
Section 3 250
1
3
4
5
6
TIA-2001.4-C
251 Section 4
4.0 Information Element Definitions 1
This section contains the coding of the information elements used in the messages 2
defined in section 3.0. 3
The definitions in the following subsections are for informational purposes only. 4
Parameter usage may vary per message in that only a subset of the defined values may be 5
applicable in a particular message. Therefore, the allowed values are specified per 6
message in the subsections of section 3.0. 7
4.1 Generic Information Element Encoding 8
9
4.1.1 Conventions 10
The following conventions are assumed for the sequence of transmission of bits and 11
bytes: 12
Each bit position is marked as 0 to 7. Bit 0 is the least significant bit and is 13
transmitted first. 14
In a message, octets are identified by number. Octet 1 is transmitted first, then octet 15
2, etc. 16
For variable length elements, a length indicator is included. This indicates the number of 17
octets following in the element. 18
The definition of whether an information element is mandatory or optional is specified in 19
the Type column of the individual message IE tables in section 3.0. 20
All information elements of BSMAP messages shall include their information element 21
identifier (IEI). Mandatory information elements of DTAP messages, except as noted for 22
Type 1 elements (refer to 4.1.3), shall not include their IEI. Optional information 23
elements of DTAP messages shall include their IEI. All unused and reserved bits are set 24
to 0, unless otherwise indicated. 25
For future expansion purposes, some of these information elements have fields within 26
them that have been reserved. 27
4.1.2 Information Element Identifiers 28
The following table contains a list of all information elements that make up the messages 29
defined in section 3.0. The table is sorted by the Information Element Identifier (IEI) 30
coding which distinguishes one information element from another. The table also 31
includes a reference to the section where the element coding can be found. 32
33
TIA-2001.4-C
Section 4 252
A listing of information elements, sorted by name, is included in Table 4.1.5-1, which 1
also specifies the messages in which each information element is used. 2
Table 4.1.2-1 A1 Information Element Identifiers Sorted by Identifier Value
Element Name IEI
(Hex)
Reference
Circuit Identity Code 01H 4.2.19
User Zone ID 02H 4.2.26
Service Option 03H 4.2.53
Cause 04H 4.2.16
Cell Identifier 05H 4.2.17
Priority 06H 4.2.15
Quality of Service Parameters 07H 4.2.45
Cause Layer 3 08H 4.2.46
IS-2000 Channel Identity 09H 4.2.27
Encryption Information 0AH 4.2.10
Channel Type 0BH 4.2.6
CDMA Serving One Way Delay 0CH 4.2.61
Mobile Identity 0DH 4.2.13
IS-2000 Service Configuration Record 0EH 4.2.55
Record
0FH 4.2.56
Extended Handoff Direction Parameters 10H 4.2.60
IS-2000 Mobile Capabilities 11H 4.2.57
Classmark Information Type 2 12H 4.2.12
Reserved (This value is used to identify
Location Area Identification in [19]).
13H
Source PDSN Address 14H 4.2.24
MS Information Records 15H 4.2.59
Hard Handoff Parameters 16H 4.2.51
Layer 3 Information 17H 4.2.31
Protocol Type 18H 4.2.58
Circuit Group 19H 4.2.70
Cell Identifier List 1AH 4.2.18
Response Request 1BH 4.2.28
(unused available element identifier values) 1CH
Radio Environment and Resources 1DH 4.2.62
Service Option Connection Identifier (SOCI) 1EH 4.2.77
Registration Type 1FH 4.2.49
Access Network Identifiers 20H 4.2.74
RF Channel Identity 21H 4.2.7
TIA-2001.4-C
253 Section 4
Element Name IEI
(Hex)
Reference
IS-95 Channel Identity 22H 4.2.9
Channel Number 23H 4.2.5
Circuit Identity Code Extension 24H 4.2.20
AMPS Hard Handoff Parameters 25H 4.2.79
Handoff Power Level 26H 4.2.25
IS-2000 Channel Identity 3X 27H 4.2.23
Authentication Confirmation Parameter
(RANDC)
28H 4.2.35
Downlink Radio Environment 29H 4.2.22
Service Option List 2AH 4.2.78
Downlink Radio Environment List 2BH 4.2.69
Geographic Location 2CH 4.2.68
PSMM Count 2DH 4.2.67
Information Record Requested 2EH 4.2.81
(unused available element identifier values) 2FH
Anchor PDSN Address 30H 4.2.82
Software Version 31H 4.2.52
SID 32H 4.2.8
Tag 33H 4.2.50
Signal 34H 4.2.42
Slot Cycle Index 35H 4.2.14
Transcoder Mode 36H 4.2.47
Band Class 37H 4.2.80
38H
Source RNC to Target RNC Transparent
Container
39H 4.2.75
Target RNC to Source RNC Transparent
Container
3AH 4.2.76
Protocol Revision 3BH 4.2.83
(unused available element identifier values) 3CH
ADDS User Part 3DH 4.2.54
(unused available element identifier value) 3EH
(unused available element identifier value) 3FH
Authentication Parameter COUNT 40H 4.2.39
Authentication Challenge Parameter 41H 4.2.37
Authentication Response Parameter 42H 4.2.38
TIA-2001.4-C
Section 4 254
Element Name IEI
(Hex)
Reference
Reserved (this value is used by the Private
Parameters Information Element in [19])
43H
Reject Cause 44H 4.2.36
(unused - available element identifier value) 45H 47H
(unused available element identifier value) 48H
Authentication Event 4AH 4.2.65
4BH
(unused available element identifier value) 4CH
(unused - available element identifier value) 4DH
PACA Timestamp 4EH 4.2.71
(unused - available element identifier values) 4FH 58H
Authentication Data 59H 4.2.66
Special Service Call Indicator 5AH 4.2.21
Called Party ASCII Number 5BH 4.2.63
Reserved (this value is used by the Calling
Party BCD Information Element in [19])
5CH
(unused available element identifier value) 5DH
Called Party BCD Number 5EH 4.2.44
PACA Order 5FH 4.2.72
PACA Reorigination Indicator 60H 4.2.73
IS-2000 Cause Value 62H 4.2.64
MS Measured Channel Identity 64H 4.2.29
IS-2000 Redirection Record 67H 4.2.86
Return Cause 68H 4.2.87
Service Redirection Info 69H 4.2.88
(unused available element identifier values) 6AH 6FH
Packet Session Parameters 70H 4.2.89
Service Reference Identifier (SR_ID) 71H 4.2.90
(unused available element identifier values) 72H 7BH
Anchor P-P Address 7CH 4.2.84
(unused available element identifier values) 7DH 7FH
Type 1 Information Elements
TIA-2001.4-C
255 Section 4
Element Name IEI
(Hex)
Reference
(unused - available element identifier value) 8XH
a

CM Service Type 9XH
a
4.2.43
Type 2 Information Elements
Origination Continuation Indicator A0H 4.2.85
Voice Privacy Request A1H 4.2.11
Power Down Indicator A2H 4.2.48
(unused - available type 2 element identifier
values)
A3H - AFH
Additional Type 1 Information Elements
(unused - available type 1 element identifier
value)
EXH
a -
FXH
a

Information Elements without Identifiers
Message Discrimination none 4.2.1
Message Type none 4.2.4
Data Link Connection Identifier (DLCI) none
b
4.2.2
Protocol Discriminator none
b
4.2.32
Reserved Octet none
b
4.2.33
a. This is a type 1 information element (refer to section 4.1.3). The X in the IEI 1
column) is data. 2
b. This is a type 3 information element (refer to section 4.1.3) that is contained as a 3
mandatory element in a DTAP message. 4
4.1.3 A1 Interface Information Element Types 5
This section describes the four information element types used on the A1 interface. 6
Two main categories of information elements are defined: 7
Information elements with fixed length 8
Information elements with variable length 9
The number of octets in fixed length elements is previously defined: a fixed value is 10
associated with the element identifier. 11
Variable length elements shall include the length field immediately following the element 12
identifier when present. When the element identifier is absent, the length field occupies 13
the first octet of the message. 14
Four types of information elements are defined: 15
Information elements with 1/2 octet of content (Type 1) 16
Information elements with 0 octets of content (Type 2) 17
Information elements with fixed length and at least one octet of content (Type 3) 18
TIA-2001.4-C
Section 4 256
Information elements with variable length (Type 4). 1
Information element Response Request (1BH) is an exception to the rules specified in 2
this section. Bit position 7 is hard coded to 1 to indicate a Type 1 or a Type 2 3
Type 1 Information Element 5
Type 1 information elements provide the information element identifier in bit positions 6, 6
5, 4. The value 0 1 0 in these bit positions is reserved for Type 2 information elements 7
which together with this value provide the information element identifier in bit positions 8
3,2,1,0. Type 3 and 4 information elements provide the information element identifier in 9
the first octet. 10
These information elements are shown in the figures below for both the case where the 11
information element is optional in a message and mandatory in a message. 12
In the figures below, IEI is used as an abbreviation for Information Element Identifier. 13
CIE as an abbreviation for Content of Information Element and LI as an abbreviation for 14
Length Indicator. 15
Type 1 information elements with 1/2 octet of content: 16
7 6 5 4 3 2 1 0 Octet
1 IEI CIE 1
Type 1 information elements may be either optional or mandatory in a BSMAP or a 17
DTAP message. When a Type 1 element is included as a mandatory information element 18
in a DTAP message, the information element identifier field shall be coded appropriately 19
by the sender, but may be ignored by the receiver. 20
Type 2 information elements have fixed length and zero octets of content: 22
7 6 5 4 3 2 1 0 Octet
1 0 1 0 IEI 1
Note: A Type 2 information element cannot be mandatory in a DTAP message. 23
24
TIA-2001.4-C
257 Section 4
Type 3 information elements have fixed length and at least one octet of content as shown 2
below. The first instance includes the information element identifier (IEI). The second 3
excludes the IEI to demonstrate the coding for a mandatory DTAP element. 4
7 6 5 4 3 2 1 0 Octet
0 IEI 1
CIE 2

CIE n
5
6
7 6 5 4 3 2 1 0 Octet
CIE 1
CIE 2

CIE n
7
Type 4 information elements have variable length as shown below. The first instance 9
includes the information element identifier (IEI). The second excludes the IEI to 10
demonstrate the coding for a mandatory DTAP element. 11
7 6 5 4 3 2 1 0 Octet
0 IEI 1
LI 2
CIE 3

CIE n
12
13
7 6 5 4 3 2 1 0 Octet
LI 1
CIE 2

CIE n
14
15
TIA-2001.4-C
Section 4 258
4.1.4 Additional Coding and Interpretation Rules for Information 1
Elements 2
Information elements shall always use the same Information Element Identifier for all 3
occurrences on a specific IOS interface. Insofar as possible, the same Information 4
Element Identifier shall be used for a given information element when it is used on more 5
than one of the IOS interfaces. 6
The order of appearance for each information element which is mandatory or optional in 7
a message is laid down in the definition of the message. 8
Where the description of the information element in this standard contains unused bits, 9
these bits are indicated as being set to 0. To allow compatibility with future 10
implementation, messages shall not be rejected simply because an unused bit is set to 1. 11
An optional variable length information element may be present, but empty. For example, 12
a message may contain a Called Party BCD Number information element, the content of 13
which is zero length. This shall be interpreted by the receiver as equivalent to that 14
information element being absent. 15
On the A1 interface, all new information elements shall be defined with a length field. 16
Some existing elements make use of an extension bit mechanism that allows the size of 17
the information element to be increased. This mechanism consists of the use of the high 18
order bit (bit 7) of an octet as an extension bit. When an octet within an information 19
element has bit 7 defined as an extension bit, then the value 0 in that bit position 20
indicates that the following octet is an extension of the current octet. When the value is 21
1, there is no extension. 22
An example of the use of the extension bit mechanism is found in octets 3 and 4 of the 23
Cause Layer 3 element. Octet 3 is extended by setting bit 7 to 1 and including octet 4. 24
This would allow the transmission of the presentation indicator and screening indicator 25
values as part of this element. 26
27
TIA-2001.4-C
259 Section 4
4.1.5 Cross Reference of Information Elements With Messages 1
The following table provides a cross reference between the elements defined in this 2
specification and the messages defined herein. 3
4.1.5 Cross Reference of Information Elements With Messages
Information Element Reference IEI Used in These Messages Reference
Access Network Identifiers 4.2.74 20H Handoff Request 3.4.2
Handoff Required 3.4.1
ADDS User Part 4.2.54 3DH ADDS Deliver 3.6.5

ADDS Page 3.6.1

ADDS Transfer 3.6.3
BS Service Request 3.1.17
AMPS Hard Handoff Parameters 4.2.79 25H Handoff Command 3.4.4
Anchor PDSN Address 4.2.82 30H Handoff Request 3.4.2
Anchor P-P Address 4.2.84 7CH Handoff Request 3.4.2
Authentication Challenge Parameter 4.2.37 41H ADDS Transfer 3.6.3
(RAND/RANDU/RANDBS/RANDS
SD)
Authentication Request 3.3.1
Base Station Challenge 3.3.5
CM Service Request 3.1.2
Location Updating Request 3.3.7
PACA Update 3.2.7
Paging Response 3.1.5
SSD Update Request 3.3.3
Authentication Confirmation
Parameter
4.2.35 28H ADDS Transfer 3.6.3
(RANDC) CM Service Request 3.1.2
PACA Update 3.2.7
Authentication Data 4.2.66 59H ADDS Transfer 3.6.3
Authentication Event 4.2.65 4AH ADDS Transfer 3.6.3
PACA Update 3.2.7
TIA-2001.4-C
Section 4 260
Authentication Parameter COUNT 4.2.39 40H ADDS Transfer 3.6.3
PACA Update 3.2.7
Authentication Response Parameter 4.2.38 42H ADDS Transfer 3.6.3
(AUTHR/AUTHU/AUTHBS) Authentication Response 3.3.2
Response
3.3.6
PACA Update 3.2.7
Band Class 4.2.80 37H Handoff Off p Performed 3.4.9
Called Party ASCII Number 4.2.63 5BH Additional Service Request 3.1.20
CM Service Request Contin-
uation
3.1.3
Called Party BCD Number 4.2.44 5EH Additional Service Request 3.1.20
CM Service Request Contin-
uation
3.1.3
Flash with Information 3.2.1
Cause 4.2.16 04H ADDS Deliver Ack 3.6.6
ADDS Page Ack 3.6.2
ADDS Transfer Ack 3.6.4
Assignment Failure 3.1.9
Block 3.5.1
BS Service Response 3.1.18
Clear Command 3.1.14
Clear Request 3.1.13
Handoff Command 3.4.4
Handoff Failure 3.4.8
Handoff Performed 3.4.9
Handoff Request
Acknowledge
3.4.3
Handoff Required Reject 3.4.7
TIA-2001.4-C
261 Section 4
Location Updating Accept 3.3.8
PACA Command Ack 3.2.6
PACA Update Ack 3.2.8
Position Response
3.2.10
Reset 3.5.7
Reset Circuit 3.5.5
Service Release 3.1.11
Transcoder Control
Acknowledge
3.5.10
Cause Layer 3 4.2.46 08H Clear Command 3.1.14
SSD Update Response 3.3.4
CDMA Serving One Way Delay 4.2.61 0CH ADDS Deliver 3.6.5
ADDS Transfer 3.6.3
Handoff Request 3.4.2
Position Response
3.2.10
Cell Identifier 4.2.17 05H ADDS Page Ack 3.6.2
ADDS Transfer 3.6.3
Complete Layer 3 Information 3.1.1
Cell Identifier List 4.2.18 1AH ADDS Page 3.6.1
Feature Notification 3.2.3
Handoff Request
Acknowledge
3.4.3
Paging Request 3.1.4
Registration Request 3.3.19
Service Redirection 3.8.1
Status Request 3.3.14
TIA-2001.4-C
Section 4 262
User Zone Reject 3.3.18
Channel Number 4.2.5 23H Assignment Complete 3.1.8
Channel Type 4.2.6 0BH Assignment Request 3.1.7
Circuit Group 4.2.70 19H Block 3.5.1
Reset Circuit 3.5.5
Unblock 3.5.3
Circuit Identity Code 4.2.19 01H Additional Service Request 3.1.20
Assignment Request 3.1.7
Block 3.5.1
Block Acknowledge 3.5.2
Reset Circuit 3.5.5
Reset Circuit Acknowledge 3.5.6
Unblock 3.5.3
Unblock Acknowledge 3.5.4
Circuit Identity Code Extension 4.2.20 24H Handoff Request 3.4.2
Classmark Information Type 2 4.2.12 12H ADDS Transfer 3.6.3
CM Service Type 4.2.43 9XH
a
Data Link Connection Identifier
(DLCI)
4.2.2 none
b
Additional Service Request 3.1.20
ADDS Deliver 3.6.5
ADDS Deliver Ack 3.6.6
Alert with Information 3.1.16
Authentication Response 3.3.2
Response
3.3.6
Connect 3.1.10
TIA-2001.4-C
263 Section 4
Flash with Information Ack 3.2.2
Location Updating Reject 3.3.9
Parameter Update Confirm 3.3.11
Parameter Update Request 3.3.10
Progress 3.1.6
Rejection 3.7.1
Service Release Complete 3.1.12
Status Response 3.3.15
User Zone Update 3.3.17
User Zone Update Request 3.3.16
Downlink Radio Environment 4.2.22 29H Handoff Request 3.4.2
Downlink Radio Environment List 4.2.69 2BH Radio Measurements for
Position Response
3.2.10
Encryption Information 4.2.10 0AH Assignment Complete 3.1.8
Privacy Mode Command 3.3.12
Privacy Mode Complete 3.3.13
Extended Handoff Direction
Parameters
4.2.60 10H Handoff Command 3.4.4
Handoff Request
Acknowledge
3.4.3
Geographic Location 4.2.68 2CH Radio Measurements for
Position Response
3.2.10
Handoff Power Level 4.2.25 26H Handoff Command 3.4.4
Hard Handoff Parameters 4.2.51 16H Handoff Command 3.4.4
Handoff Request
Acknowledge
3.4.3
TIA-2001.4-C
Section 4 264
Information Record Requested 4.2.81 2EH Status Request 3.3.14
IS-2000 Cause Value 4.2.64 62H Rejection 3.7.1
IS-2000 Channel Identity 4.2.27 09H Handoff Command 3.4.4
Handoff Request
Acknowledge
3.4.3
IS-2000 Channel Identity 3X 4.2.23 27H Handoff Command 3.4.4
Handoff Request
Acknowledge
3.4.3
IS-2000 Mobile Capabilities 4.2.57 11H ADDS Page 3.6.1
ADDS Transfer 3.6.3
IS-2000 Non-Negotiable Service
Configuration Record
4.2.56 0FH Handoff Command 3.4.4
Handoff Request
Acknowledge
3.4.3
IS-2000 Redirection Record 4.2.86 67H Service Redirection 3.8.1
IS-2000 Service Configuration
Record
4.2.55 0EH Handoff Command 3.4.4
Handoff Request
Acknowledge
3.4.3
IS-95 Channel Identity 4.2.9 22H Handoff Command 3.4.45
TIA-2001.4-C
265 Section 4
Handoff Request
Acknowledge
3.4.3
Layer 3 Information 4.2.31 17H Complete Layer 3 Information 3.1.1
Message Type 4.2.4 none
b
Additional Service
Notification
3.1.19
ADDS Deliver 3.6.5
ADDS Page 3.6.1
ADDS Page Ack 3.6.2
ADDS Transfer 3.6.3
Assignment Complete 3.1.8
Response
3.3.6
Block 3.5.1
Block Acknowledge 3.5.2
Clear Command 3.1.14
Clear Complete 3.1.15
CM Service Request
Continuation
3.1.3
Complete Layer 3 Information 3.1.1
Connect 3.1.10
Feature Notification Ack 3.2.4
TIA-2001.4-C
Section 4 266
Handoff Commenced 3.4.5
Handoff Complete 3.4.6
Handoff Failure 3.4.8
Handoff Request
Acknowledge
3.4.3
Handoff Required Reject 3.4.7
PACA Command 3.2.5
PACA Command Ack 3.2.6
PACA Update 3.2.7
Privacy Mode Command 3.3.12
Progress 3.1.6
Position Request
3.2.9
Position Response
3.2.10
Rejection 3.7.1
Reset 3.5.7
Reset Acknowledge 3.5.8
Reset Circuit 3.5.5
Reset Circuit Acknowledge 3.5.6
TIA-2001.4-C
267 Section 4
Transcoder Control
Acknowledge
3.5.109
Transcoder Control Request 3.5.98
Unblock 3.5.3
Unblock Acknowledge 3.5.4
Mobile Identity 4.2.13 0DH Additional Service
Notification
3.1.19
ADDS Page 3.6.1
ADDS Page Ack 3.6.2
ADDS Transfer 3.6.3
PACA Update 3.2.7
Rejection 3.7.1
TIA-2001.4-C
Section 4 268
MS Information Records 4.2.59 15H Alert with Information 3.1.16
CM Service Request
Continuation
3.1.3
Flash With Information 3.2.1
Progress 3.1.6
MS Measured Channel Identity 4.2.29 64H Handoff Request 3.4.2
Origination Continuation Indicator 4.2.85 A0H CM Service Request 3.1.2
PACA Order 4.2.72 5FH PACA Update 3.2.7
PACA Reorigination Indicator 4.2.73 60H CM Service Request 3.1.2
PACA Timestamp 4.2.71 4EH Assignment Request 3.1.7
PACA Command 3.2.5
Packet Session Parameters 4.2.89 70H Handoff Request 3.4.2
Power Down Indicator 4.2.48 A2H Clear Complete 3.1.15
Priority 4.2.15 06H Assignment Request 3.1.7
PACA Command 3.2.5
PACA Update 3.2.7
Protocol Discriminator 4.2.32 none
b
ADDS Deliver 3.6.5
Response
3.3.6
CM Service Request
Continuation
3.1.3
Connect 3.1.10
TIA-2001.4-C
269 Section 4
Progress 3.1.6
Rejection 3.7.1
Protocol Revision 4.2.83 3BH ADDS Page 3.6.1
Protocol Type 4.2.58 18H Handoff Request 3.4.2
PSMM Count 4.2.67 2DH Radio Measurements for
Position Request
3.2.9
Quality of Service Parameters 4.2.45 07H Assignment Request 3.1.7
Radio Environment and Resources 4.2.62 1DH CM Service Request 3.1.2
TIA-2001.4-C
Section 4 270
Registration Type 4.2.49 1FH Location Updating Request 3.3.7
Reject Cause 4.2.36 44H Location Updating Reject 3.3.9
Reserved Octet 4.2.33 none
b
ADDS Deliver 3.6.5
Response
3.3.6
CM Service Request
Continuation
3.1.3
Connect 3.1.10
Progress 3.1.6
Rejection 3.7.1
Response Request 4.2.28 1BH Handoff Required 3.4.1
Return Cause 4.2.87 68H CM Service Request 3.1.2
TIA-2001.4-C
271 Section 4
RF Channel Identity 4.2.7 21H Handoff Command 3.4.4
Service Option 4.2.53 03H Additional Service
Notification
3.1.19
ADDS Transfer 3.6.3
Handoff Complete 3.4.6
Service Option Connection Identifier 4.2.77 1EH Additional Service Request 3.1.20
(SOCI) Alert with Information 3.1.16
Connect 3.1.10
Progress 3.1.6
Rejection 3.7.1
Service Option List 4.2.78 2AH Handoff Command 3.4.45
Handoff Request
Acknowledge
3.4.3
Service Redirection Info 4.2.88 69H Service Redirection 3.8.1
Service Reference Identifier (SR_ID) 4.2.90 71H Assignment Request 3.1.7
TIA-2001.4-C
Section 4 272
SID 4.2.8 32H Handoff Command 3.4.4
Signal 4.2.42 34H Assignment Request 3.1.7
Progress 3.1.6
Slot Cycle Index 4.2.14 35H ADDS Page 3.6.1
ADDS Transfer 3.6.3
Software Version 4.2.52 31H Reset 3.5.7
Reset Acknowledge 3.5.8
Source PDSN Address 4.2.24 14H Handoff Request 3.4.2
Source RNC to Target RNC
Transparent Container
4.2.75 39H Handoff Request 3.4.2
Special Service Call Indicator 4.2.21 5AH Additional Service Request 3.1.20
Tag 4.2.50 33H ADDS Deliver 3.6.5
ADDS Page 3.6.1
ADDS Page Ack 3.6.2
ADDS Transfer 3.6.3
TIA-2001.4-C
273 Section 4
Target RNC to Source RNC
Transparent Container
4.2.76 3AH Handoff Command 3.4.4
Handoff Request
Acknowledge
3.4.3
Transcoder Mode 4.2.47 36H Transcoder Control Request 3.5.9
User Zone ID 4.2.26 02H ADDS Transfer 3.6.3
Voice Privacy Request 4.2.11 A1H Additional Service Request 3.1.20
a. This is a type 1 information element (refer to section 4.1.3). The X in the IEI column 1
is data. 2
b. This is a type 3 information element (refer to section 4.1.3) that is contained as a 3
mandatory element in a DTAP message. 4
5
TIA-2001.4-C
Section 4 274
4.2 Information Elements 1
2
4.2.1 Message Discrimination 3
A one octet field is used in all messages to discriminate between DTAP and BSMAP 4
messages. 5
4.2.1 Message Discrimination
7 6 5 4 3 2 1 0 Octet
0 0 0 0 0 0 0 D-bit 1
The D-bit is set to 1 to indicate that the message is a DTAP message. All other messages 6
shall have the D-bit set to 0. Refer to section 4.2.4 for message types.. 7
4.2.1.1 A1 Message Header 8
Each message transferred between the BS and MSC is classified either as a DTAP or a 9
BSMAP message. The BS performs protocol conversion between the DTAP/BSMAP 10
messages and the specific air interface signaling system in use. 11
To distinguish between the DTAP messages and BSMAP messages, a header is prefixed 12
on each A1 interface message transferred between the BS and MSC. Refer to Figure 13
4.2.1.1.1.3-1. 14
4.2.1.1.1 Transfer of DTAP and BSMAP Messages 15
Refer to [12] for information on the transport of DTAP and BSMAP messages on the A1 16
interface. 17
4.2.1.1.1.1 Distribution Function 18
The distribution of messages between the BSMAP and DTAP functions and the 19
distribution or multiplexing of DTAP messages to or from the various radio link layer 2 20
access points are performed in an intermediate layer of protocol between the transport 21
layer and Layer 3 referred to as the distribution sub-layer. 22
The protocol for this sub-layer simply consists of the management of a one or two octet 23
Distribution Data Unit as a header, followed by the actual Layer 3 BSMAP or DTAP 24
message. This is shown in Figure 4.2.1.1.1.3-1, Structure of A1 Layer 3 Messages. The 25
user data field contains a Distribution Data Unit, a Length Indicator, and the actual layer 26
3 message. The Distribution Data Unit consists of one or two octets depending on 27
whether the message is DTAP or BSMAP. The first octet, Message Discrimination, 28
differentiates the message between these two types. 29
4.2.1.1.1.2 Transfer of DTAP Messages 30
For DTAP messages, the Distribution Data Unit consists of two parameters: the Message 31
Discrimination parameter and the Data Link Connection Identifier (DLCI) parameter. 32
Refer to section 4.2.1, Message Discrimination and section 4.2.2, Data Link Connection 33
Identifier (DLCI) for details on the coding of these parameters. 34
TIA-2001.4-C
275 Section 4
In the Message Discrimination parameter the discrimination bit D is set to the value 1 to 1
indicate DTAP. 2
The DLCI parameter is used for MSC to BS and BS to MSC messages to indicate the 3
type and treatment of the message being transmitted. 4
The length indicator (refer to section 4.2.3) is coded in one octet, and is the binary 5
representation of the number of octets of the subsequent layer 3 message parameter. 6
Messages that are actually DTAP messages are distinguished from those that are BSMAP 7
in the description of Message Type (section 4.2.4). 8
4.2.1.1.1.3 Transfer of BSMAP Messages 9
The transfer of BSMAP messages over a specific transport connection allows the 10
BSMAP functions in both the MSC and the BS to identify to which particular MS 11
association the exchanged message (e.g., assign, handoff request, etc.) applies. 12
The structure of the user data field is given in Figure 4.2.1.1.1.3-1, Structure of A1 13
Layer 3 Messages. The user data field contains a Distribution Data Unit, a Length 14
Indicator, and the actual layer 3 message. 15
The Distribution Data Unit only consists of the Message Discrimination parameter, and is 16
coded as one octet. The discrimination bit D is set to the value 0 to indicate BSMAP. 17
The Length Indicator (refer to section 4.2.3) is coded in one octet, and is the binary 18
representation of the number of octets of the subsequent layer 3 message parameter. 19
The coding of the BSMAP layer 3 messages is specified in this chapter starting in section 20
3.0. 21
Message Discrimination
DLCI (Always set to 0)
DTAP Message Header
BSMAP Message Header
octet 1 octet 1
octet 2
Length Indicator Length Indicator octet 3 octet 2
octets 3 to k
octets 4 to
k+1
Distribution
Data
Unit
Layer 3
Message
Length
Layer 3
Message
APPLICATION
MESSAGE
APPLICATION
MESSAGE
DLCI (Always set to 0)
DTAP Message Header
BSMAP Message Header
octet 1 octet 1
octet 2
Length Indicator Length Indicator octet 3 octet 2
octets 3 to k
octets 4 to
k+1
Distribution
Data
Unit
Layer 3
Message
Length
Layer 3
Message
APPLICATION
MESSAGE
APPLICATION
MESSAGE
22
Figure 4.2.1.1.1.3-1 Structure of A1 Layer 3 Messages 23
TIA-2001.4-C
Section 4 276
4.2.2 Data Link Connection Identifier (DLCI) 1
The DLCI is one of the parameters for the distribution data unit that is part of the user 2
data field of every DTAP message. Refer to section 4.2.1.1.1.2 for details on use of this 3
element in the header of all DTAP messages. The DLCI parameter is used for MSC to BS 4
messages to indicate the type of data link connection to be used over the radio interface. 5
In the direction BS to MSC the DLCI parameter is used to indicate the type of originating 6
data parameter and is coded in one octet, as follows: 7
4.2.2 Data Link Connection Identifier (DLCI)
7 6 5 4 3 2 1 0 Octet
C2 C1 Reserved S3 S2 S1 1
Bits C2 and C1 are defined as: 8
C2 C1 Description
0 0
Represents the default for cdma2000

All other
values
Reserved
Reserved: 9
These bits are set to 000. 10
Bits S3, S2, and S1: 11
These bits represent the SAPI (Signaling Access Point Identifier) value 12
used on the radio link. The SAPI shall be set to zero for cdma2000
. 13
14
TIA-2001.4-C
277 Section 4
4.2.3 Length Indicator (LI) 1
The length indicator is coded in one octet, and is used to indicate the length of a message. 2
4.2.3 Length Indicator (LI)
7 6 5 4 3 2 1 0 Octet
Length Indicator 1
Length Indicator: 3
This field contains the binary representation of the number of octets in 4
the message following this octet. 5
6
7
TIA-2001.4-C
Section 4 278
4.2.4 Message Type 1
The Message Type is used to identify a message. Element Format: 2
4.2.4 Message Type
7 6 5 4 3 2 1 0 Octet
Message Type 1
Message Type: 3
This octet is coded as shown in table 4.2.4-1. 4
BSMAP messages are used to perform functions at the MSC or BS while DTAP 5
messages carry information primarily used by the MS. For details, refer to [12]. 6
7
Table 4.2.4-1 BSMAP Messages

BSMAP Message Name
Message
Type
Value

Message Category

Section
Reference
69H
Call Processing
3.1.19
ADDS Page
65H
Supplementary
Services
3.6.1
ADDS Page Ack
66H
Supplementary
Services
3.6.2
ADDS Transfer
67H
Supplementary
Services
3.6.3
ADDS Transfer Ack
68H
Supplementary
Services
3.6.4
Assignment Complete
02H
Call Processing 3.1.8
Assignment Failure
03H
Assignment Request
01H
45H
Mobility Management 3.3.1
46H
48H
49H
Block
40H
Facilities Management 3.5.1
Block Acknowledge
41H
BS Service Request
09H
BS Service Response
0AH
Clear Command
20H
Clear Complete
21H
Clear Request
22H
Complete Layer 3 Information
57H
TIA-2001.4-C
279 Section 4

BSMAP Message Name
Message
Type
Value

Message Category

Section
Reference
60H
Supplementary
Services
3.2.3
Feature Notification Ack
61H
Supplementary
Services
3.2.4
Handoff Command
13H
Radio Resource Mgmt. 3.4.4
Handoff Commenced
15H
Handoff Complete
14H
Handoff Failure
16H
Handoff Performed
17H
Handoff Request
10H
Handoff Request Acknowledge
12H
Handoff Required
11H
Handoff Required Reject
1AH
PACA Command
6CH
Supplementary
Services
3.2.5
PACA Command Ack
6DH
Supplementary
Services
3.2.6
PACA Update
6EH
Supplementary
Services
3.2.7
PACA Update Ack
6FH
Supplementary
Services
3.2.8
Paging Request
52H
Privacy Mode Command
53H
Privacy Mode Complete
55H
Request
23H
Supplementary
Services
3.2.9
Response
25H
Supplementary
Services
3.2.10
Rejection
56H
Registration Request
05H
Reset
30H
Reset Acknowledge
31H
Reset Circuit
34H
35H
Status Request
6AH
Status Response
6BH
Transcoder Control Acknowledge
39H
Transcoder Control Request
38H
TIA-2001.4-C
Section 4 280

BSMAP Message Name
Message
Type
Value

Message Category

Section
Reference
Unblock
42H
Unblock Acknowledge
43H
User Zone Reject
0BH
Table 4.2.4-2 DTAP Messages 1

DTAP Message Name
Message
Value
Type

Message Category

Section
Reference
62H Call Processing 3.1.20
ADDS Deliver
53H Supplementary Services 3.6.5
ADDS Deliver Ack
Alert with Information
45H Mobility Management 3.3.1
CM Service Request
CM Service Request Continuation
Connect
Flash with Information Ack
Location Updating Reject
Paging Response
Parameter Update Confirm
2BH Mobility Management 3.3.11
Parameter Update Request
2CH Mobility Management 3.3.10
Progress
Rejection
Service Redirection
Service Release
2EH Call Processing 3.1.11
2FH Call Processing 3.1.12
SSD Update Request
SSD Update Response
4AH Mobility Management 3.3.4
Status Request
6AH Mobility Management 3.3.14
Status Response
User Zone Reject
TIA-2001.4-C
281 Section 4

DTAP Message Name
Message
Value
Type

Message Category

Section
Reference
User Zone Update
0CH Mobility Management 3.3.17
0DH Mobility Management 3.3.16
TIA-2001.4-C
Section 4 282
4.2.5 Channel Number 1
This element contains a logical channel number assigned to the equipment providing a 2
traffic channel. 3
4.2.5 Channel Number
7 6 5 4 3 2 1 0 Octet
A1 Element Identifier 1
Reserved ARFCN High Part (MSB) 2
ARFCN Low Part (LSB) 3
Reserved: 4
Populate as 00000. 5
For backward compatibility with versions prior to IOS 4.1, an entity 6
compliant with this version of the standard shall be prepared to receive 7
nonzero bits 8
ARFCN: 9
The ARFCN (Absolute RF Channel Number) is an 11-bit number that 10
identifies the Absolute Radio Frequency Channel Number relative to 11
the band class for the call association. 12
Range of values: 13
0 Undefined 14
1-2047 ARFCN 15
For backward compatibility, default value of 0 may be used by 16
manufacturers when this element is not needed for Location Based 17
Services. 18
19
TIA-2001.4-C
283 Section 4
4.2.6 Channel Type 1
This element is being maintained for historical purposes only. The sending entity shall 2
encode the information element as shown in the bitmaps and the receiving entity shall 3
obtain this information from other information elements. 4
4.2.6 Channel Type
7 6 5 4 3 2 1 0 Octet
Length 2
Speech or Data Indicator 3
Channel Rate and Type 4
Speech Encoding Algorithm/data rate + Transparency Indicator 5
Length: 5
The Length field is defined as the number of octets following the 6
Length field. 7
Speech or Data Indicator: 8
The Speech or Data Indicator octet is coded as follows: 9
Table 4.2.6-1 Channel Type - Speech or Data Indicator Values 10
7 6 5 4 3 2 1 0 Speech or Data Indicator
setting
0 0 0 0 0 0 0 0 No Alert
0 0 0 0 0 0 0 1 Speech
a

0 0 0 0 0 0 1 0 Data
a

0 0 0 0 0 0 1 1 Signaling
b

a. A dedicated terrestrial resource is also required 11
b. A dedicated terrestrial resource is not required 12
Channel Rate and Type: 13
The Channel Rate and Type is coded as follows: 14
Table 4.2.6-2 Channel Type - Channel Rate and Type Values 15
7 6 5 4 3 2 1 0 Channel Rate and Type
0 0 0 0 0 0 0 0 Reserved (invalid)
0 0 0 0 0 0 0 1 DCCH
0 0 0 0 0 0 1 0 Reserved for future use (invalid)
0 0 0 0 1 0 0 0 Full rate TCH channel Bm
0 0 0 0 1 0 0 1 Half rate TCH channel Lm
Speech Encoding Algorithm/data rate + Transparency Indicator: 16
If the Speech or Data Indicator field in octet 3 indicates that the call is a 17
speech call or signaling (e.g., DCCH) then this field shall be coded as 18
follows: 19
20
TIA-2001.4-C
Section 4 284
Table 4.2.6-3 Channel Type - Octet 5 Coding (Voice/Signaling Call) 1
7 6 5 4 3 2 1 0 Octet 5 coding if speech call or signaling
0 0 0 0 0 0 0 0 No Resources Required (invalid)
0 0 0 0 0 0 0 1 Reserved
0 0 0 0 0 0 1 0 Reserved
0 0 0 0 0 0 1 1 TIA/EIA/IS-2000 8 kbps vocoder
0 0 0 0 0 1 0 0 8 kbps enhanced vocoder (EVRC)
0 0 0 0 0 1 0 1 13 kbps vocoder
0 0 0 0 0 1 1 0 Adaptive Differential Pulse Code Modulation
All other values are reserved
If the Speech or Data Indicator field in octet 3 indicates that the call is a 2
data call, then this field shall be coded as follows: 3
Table 4.2.6-4 Channel Type - Octet 5 Coding (Data Call) 4
7 6 5 4 3 2 1 0
ext.
a
T/ NT
b

Reserved
c

a. reserved for extension. 5
b. 0-Transparent service, 1-Non-Transparent service. 6
c. Currently unused and is encoded as 000000 7
8
TIA-2001.4-C
285 Section 4
4.2.7 RF Channel Identity 1
This element specifies the identity of an analog radio channel (refer to [18]). 2
4.2.7 RF Channel Identity
7 6 5 4 3 2 1 0 Octet
Color Code 2
Reserved N-AMPS ANSI
EIA/TIA-
553
3
Reserved (Timeslot Number) 4
Reserved ARFCN (high part) 5
ARFCN (low part) 6
Color Code: 3
The Color Code field in octet 2 identifies the unique code used by an 4
analog signaling system to distinguish the serving cell RF channels 5
from cells reusing this RF channel. For analog cells, this color code 6
corresponds to the 3 possible Supervisory Audio Tones (SAT) used to 7
distinguish this cells radio channels. 8
Reserved: 9
These bits are coded as 000000. 10
N-AMPS:This bit is set to 1, when the signaling type allocated by a 11
target BS in ahard handoff procedure is narrow band analog technology 12
(N-AMPS) based. 13
ANSI EIA/TIA 553: 14
This bit is set to 1, when the signaling type allocated by a target BS in a 15
hard handoff procedure is ANSI EIA/TIA 553 based. 16
Timeslot Number: 17
When the indicated signaling type is narrow band analog technology 18
(N-AMPS), then the Timeslot Number field represents the C12 and 19
C13 narrow band bits which are defined as the narrow band channel 20
offset from the center frequency of the overlaid channel N. It is coded 21
as follows: 22
Table 4.2.7-1 RF Channel Identity Timeslot Number 23
Value Description
00 Centered on N
01 Channel below N
10 Channel above N
11 Reserved
Reserved: 24
TIA-2001.4-C
Section 4 286
ARFCN: 1
The ARFCN (Absolute RF Channel Number) field in octets 5 and 6 2
may, depending on the message in which it is included, identify the 3
channel being used in the current mobile connection; for example, to 4
allow a remote sites scan receiver to measure the uplink signal strength 5
relative to the remote site. Alternatively, depending on the message in 6
which it is included, this element may identify a target set channel for a 7
handoff. This ARFCN has a range of 0-2047 to accommodate the 8
Frequency Bands of each signaling system. The frequency bands are 9
shown below for clarification. 10
The frequency bands reserved for analog signaling systems are covered 11
with the following channel numbering schemes: 12
initial allocation of 20 MHz for both band A and B representing 1-666 13
signaling and voice channels and numbered 1-333 for the A band, and 14
334-666 for the B band. 15
extended allocation ([18]) of 5 MHz for A, B, and A bands 16
representing 166 voice channels and numbered 667-716 for the A 17
band, 717-799 for the B band, and 991-1023 for the A band. 18
19
TIA-2001.4-C
287 Section 4
4.2.8 SID 1
This element provides the System Identification used by MSs to determine home/roam 2
status. It is coded as follows: 3
4.2.8 SID
7 6 5 4 3 2 1 0 Octet
Reserved (MSB) SID (high order) 2
SID (low order) (LSB) 3
Reserved: 4
This bit is coded as 0. 5
SID: 6
The SID is a 15 bit unique number assigned to each wireless system 7
coverage area. 8
9
TIA-2001.4-C
Section 4 288
4.2.9 IS-95 Channel Identity 1
This element specifies identity information for one or more TIA/EIA/IS-95-B radio 2
channels. 3
4.2.9 I S-95 Channel Identity
7 6 5 4 3 2 1 0 Octet
Length 2
Hard
Handoff
Number of Channels to Add Frame Offset 3
Walsh Code Channel Index n
Pilot PN Code (low part) n+1
Pilot PN
Code (high
part)
Power
Combined
Freq.
included
Reserved ARFCN (high part) n+2
ARFCN (low part) n+3
Length: 4
Length is the number of octets that follow this octet. The length of this 5
element is variable because more than one target cell may be requested 6
in a TIA/EIA/IS-95-B handoff. Therefore, this element provides the 7
flexibility to specify multiple TIA/EIA/IS-95-B channels that the target 8
BS can accommodate. 9
Hard Handoff to Add: 10
This field, when set to 1, indicates that a hard handoff is required rather 11
than a soft/softer handoff. This field may be set in a handoff request or 12
response. It shall be set appropriately by the responding target BS to 13
correspond to the action committed by the target Number of Channels: 14
In this version of the standard, this field shall be set to 001. 15
Frame Offset: 16
This field contains the number of 1.25 ms intervals relative to system 17
time that the forward and reverse traffic channels are delayed by the 18
source. If this element is returned to the source with the hard handoff 19
indicator bit set, this field contains the frame offset delay required by 20
the target. 21
The following four octets may be included multiple times: 22
Walsh Code Channel Index: 23
This field (octet n) specifies one of 64 possible Walsh Codes used to 24
channelize the downlink RF bit stream in a TIA/EIA/IS-95-B call. 25
Pilot PN Code: 26
The Pilot PN Code is one of 511 unique values for the Pilot Channel 27
offset. The offsets are in increments of 64 PN chips. 28
Power Combined: 29
This field is a flag that, when set to 1, indicates diversity combining 30
of the power control sub-channel of this TIA/EIA/IS-95-B code channel 31
with the previous TIA/EIA/IS-95-B code channel listed in this element. 32
TIA-2001.4-C
289 Section 4
In other words, if this is the second replication of octets n through n+3, 1
then the power control sub-channel of this TIA/EIA/IS-95-B code 2
channel is diversity combined with power control sub-channel of the 3
previous replication of octets n through n+3. The first occurrence of 4
this field in the IS-95 Channel Identity element is set to zero. 5
Frequency Included: 6
This is a flag indicating whether the frequency assignment is included. 7
A 0 indicates no frequency assignment is present, a 1 indicates a 8
frequency assignment is present and is specified in the ARFCN field of 9
this element. For code channel assignments that are on the same 10
TIA/EIA/IS-95-B channel frequency, this field shall be set to 0. 11
ARFCN: 12
This field in octets n+2 and n+3 identifies the TIA/EIA/IS-95-B 13
frequency being used in the current mobile connection. This ARFCN 14
has a range of 0-2047 to accommodate the various frequency bands. 15
The frequency bands are shown below for clarification. When the 16
Frequency Included flag is set to zero, the ARFCN field shall be set to 17
all binary zeros. 18
The Frequency Bands reserved for TIA/EIA/IS-95-B signaling system in 19
the North American cellular band class is covered with the following 20
channel numbering scheme: 21
A band allocation of 311 channels and numbered for TIA/EIA/IS-95-B 22
or TIA/EIA/IS-2000 as 1-311. 23
B band allocation of 289 channels and numbered for TIA/EIA/IS-95-B 24
or TIA/EIA/IS-2000 as 356-644. 25
A band allocation of 6 channels and numbered for TIA/EIA/IS-95-B 26
or TIA/EIA/IS-2000 as 689-694. 27
B band allocation of 39 channels and numbered for TIA/EIA/IS-95-B 28
or TIA/EIA/IS-2000 as 739-777. 29
A band allocation of 11 channels and numbered TIA/EIA/IS-95-B or 30
TIA/EIA/IS-2000 as 1013-1023. 31
The Frequency Bands reserved in the North American PCS band class are 32
covered with the following channel numbering scheme: 33
A-F band allocation of channels numbered from 25-1175. 34
35
TIA-2001.4-C
Section 4 290
4.2.10 Encryption Information 1
This is a variable length element. It contains necessary information to control encryption 2
devices. This element is used during call setup and handoff. 3
4.2.10 Encryption Information
7 6 5 4 3 2 1 0 Octet
Length 2
Encryption Info - 1 3 - n
Encryption Info - 2 n+1 - m

Encryption Info - k p - q
Length: 4
This field (octet 2) is a binary number indicating the absolute length of 5
the contents after the Length octet. 6
Encryption Info: 7
Multiple instances of the Encryption Info field may occur within this 8
element. If no Encryption Info information is available, the Length 9
indicator shall be set to 0000 0000 10
The Encryption Info field is coded as follows: 11
Table 4.2.10-1 Encryption Information - Encryption Parameter Coding 12
7 6 5 4 3 2 1 0 Octet
ext=1 Encryption Parameter Identifier Status Available 1
Encryption Parameter Length 2
(MSB) Encryption Parameter value - octet 1 3

Encryption Parameter value - octet m (LSB) variable
Encryption Parameter Coding - Octet 1: 13
Available: 14
Bit 0 indicates if the encryption algorithm is available (supported). The 15
BS sets this bit appropriately when this element is included in a 16
message being sent by a BS. The MSC always sets this bit to 0 and 17
the BS always ignores it when this element is included in a message 18
being sent by the MSC. Available is coded 1, and not available is 19
coded 0. 20
Status: 21
The Status indication, bit 1, is coded 1 to indicate active and 0 to 22
indicate inactive. 23
TIA-2001.4-C
291 Section 4
Encryption Parameter Identifier: 1
Bits 2 through 6 contain the Encryption Parameter Identifier; refer to Table 4.2.10-2 2
below.Ext: 3
Bit 7 is an extension bit. 4
Table 4.2.10-2 Encryption Information - Encryption Parameter Identifier Coding 5
Encryption
Parameter
Identifier Value

Encryption Parameter
00000 Not Used - Invalid value.
00001 SME Key: Signaling Message Encryption Key
00010 Reserved (VPM: Voice Privacy Mask)
00011 Reserved
00100 Private Longcode
00101 Data Key (ORYX)
00110 Initial RAND
All other values Reserved
A brief description of the parameters and their typical usage is given below for 6
information only, and is not intended to limit the scope of application. 7
SME Key: 8
Signaling Message Encryption Key, used for encryption of some 9
signaling messages in [10] and [1]~[6]. Key length is 8 octets. 10
Private Longcode: 11
Encryption parameter for [10] and [1]~[6]. Key length is 42 bits, 12
encoded in 6 octets, such that the 6 unused bits are set equal to 0, and 13
occupy the high-order positions of the most significant octet. 14
Data Key (ORYX): 15
Parameter intended for encryption of user data in [22]. Key length is 4 16
octets. 17
Initial RAND: 18
Parameter used for data encryption in [22]. When data encryption is 19
enabled, this parameter shall be passed to the target BS from the source 20
BS so that the same value of RAND can be used. The key length is 4 21
octets. 22
Encryption Parameter Coding - Octets 2 and 3 - n: 23
The second octet indicates the length of the parameter as a binary 24
number. Octets 3 through n contain the parameter value. The length of 25
the parameter may be zero in which case octet 2 is set to a binary value 26
of zero. 27
28
TIA-2001.4-C
Section 4 292
4.2.11 Voice Privacy Request 1
This is a fixed length element with zero octets of content. Only the element identifier is 2
included (type 2). When present, it indicates that the MS has requested Voice Privacy. 3
Refer to section 4.1.3 for additional information on type 2 IEs. 4
4.2.11 Voice Privacy Request
7 6 5 4 3 2 1 0 Octet
1 0 1 0 A1 Element Identifier 1
TIA-2001.4-C
293 Section 4
4.2.12 Classmark Information Type 2 1
The Classmark Information Type 2 defines certain attributes of the MS equipment in use 2
on a particular transaction, thus giving specific information about the MS. It is coded as 3
follows: 4
4.2.12 Classmark Information Type 2
7 6 5 4 3 2 1 0 Octet
Length 2
MOB_P_REV Reserved See List
of
Entries
RF Power Capability 3
Reserved 4
NAR_
AN_
CAP
IS-95 Slotted Reserved

DTX
Mobile
Term
ANSI/EIA/TIA-
553
5
Reserved 6
Reserved Mobile
Term
PSI 7
SCM Length 8
Station Class Mark 9

Count of Band Class Entries k
Band Class Entry Length k+1
Reserved Band Class 1 k+2
Band Class 1 Air Interfaces Supported k+3
Band Class 1 MOB_P_REV k+4

Reserved Band Class n m
Band Class n Air Interfaces Supported m+1
Band Class n MOB_P_REV m+2
The A1 Element Identifier is not included when this information element is sent as a 5
mandatory element as part of a DTAP message. 6
Length: 7
This field is defined as the number of octets following the Length field. 8
MOB_P_REV: 9
The MOB_P_REV field in octet 3 contains the current mobile station 10
protocol revision level as defined in [1] to [6]. The MOB_P_REV field 11
in octet 3 contains the low order 3 bits of the 8-bit MOB_P_REV. The 12
source BS shall always set this field when sending this element to the 13
MSC in a message. The MSC shall transparently transfer this value 14
TIA-2001.4-C
Section 4 294
when forwarding this element to the target BS. The target BS may 1
choose to ignore the value. 2
Reserved (octet 3): 3
See List of Entries: 5
This field is an escape mechanism that allows octets 3 through 6 to be 6
ignored by the receiver. When set to 1, the receiver shall ignore the 7
contents of octets 3 through 6 and shall instead use the contents of 8
octets 7 through the end of the element to derive the valid class mark 9
information. When this field is set to 0, the receiver shall process the 10
contents of octets 3 through 6 and ignore any additional data that may 11
be present after these octets. A BS shall be required to populate both 12
portions of this element, i.e. octets 3-6 and 7 through the end-of- 13
element, to provide backward compatibility. The information contained 14
in the first band class entry set in octets 12-14 shall be applicable to the 15
current band class of the mobile. 16
RF Power Capability: 17
This field is coded as follows: 18
Table 4.2.12-1 Classmark Information Type 2 - RF Power Capability 19
Binary Values Meaning ANSI /EI A/TI A-
553
TI A/EI A/I S-
2000
000 Class 1, vehicle and portable 4W 1.25 W
001 Class 2, portable 1.6 W 0.5 W
010 Class 3, handheld 0.6 W 0.2 W
011 Class 4, handheld
Unused
Each MS has an assigned power class capability that needs to be known 20
at the base station to regulate uplink power control. Each power class is 21
unique to the specific signaling system. Power classes can range from 1 22
to 8. All other values are reserved. 23
NAR_AN_CAP: 24
This field in bit 7 of octet 5 is set to 1 for an MS that is capable of 25
supporting narrow band analog technology (N-AMPS), and is set to 0 26
otherwise. 27
IS-95: 28
This field indicates that the MS is capable of supporting the air 29
interfaces defined in [10] and/or [1] to [6]. 30
Slotted: 31
This field indicates that the mobile is operating in slotted paging 32
request mode when set to 1 (cdma2000 only). 33
This field is coded as 00. 35
TIA-2001.4-C
295 Section 4
DTX: 1
This field indicates whether or not the mobile is capable of 2
discontinuous transmission. It is set to 1 if the mobile is capable of 3
DTX, otherwise it is set to 0. 4
Mobile Term (octet 5 and 7): 5
This field is set to 1 for cdma2000
MSs currently capable of 6

receiving incoming calls, and is set to 1 for all other MS types. It is 7
set to 0 for cdma2000
MSs incapable of receiving incoming calls. 8

ANSI/EIA/TIA-553: 9
This field is set to 1 if the mobile supports analog capabilities. It is set 10
to 0 if the mobile doesnt support analog mode. 11
This field is coded as 00H. 13
PSI: 16
The PACA Supported Indicator (PSI) field in bit 0 of octet 7 indicates 17
the MSs capability to support PACA. This field is set to 1 if the MS 18
supports PACA; otherwise it is set to 0. 19
SCM Length: 20
This field indicates the length of the Station Class Mark field in the 21
following octet(s). Station Class Mark: 22
This field shall be coded as specified in [1]~[6]. 23
Count of Band Class Entries: 24
This field indicates the number of band class information entries that 25
follow. These entries each contain information on the air interface 26
capabilities and protocol level information of the MS with respect to a 27
specific band class. At least one entry for the MSs current band class is 28
required. The current band class information shall be included in the 29
first band class entry information set. Data pertaining to other band 30
classes supported by the MS may also be included. 31
Band Class Entry Length: 32
This field indicates the length of the set of parameters associated with 33
each band class entry set. The length of each band class entry set 34
included in this element shall be the same. 35
Reserved (octet k+2 and m): 36
Band Class n (octet k+2 and m):This field shall be a binary value coded 38
as shown in section 4.2.80. 39
Band Class n Air Interfaces Supported (octet k+3 and m+1): 40
This field shall be a binary value consisting of subfields indicating 41
which operating modes are supported by the MS in the corresponding 42
band class. The subfields are coded as defined in the cdma2000
43
Operating Mode Information record [1]~[6]. The first subfield is 44
OP_MODE0 and it shall correspond to bit 7. 45
TIA-2001.4-C
Section 4 296
Band Class n MOB_P_REV: 1
This field contains the MS protocol revision level as defined in [1]~[6]. 2
The source BS shall always set this field when sending this element to 3
the MSC on a message. The MSC shall transparently transfer this value 4
when forwarding this element to the target BS. The target BS may 5
choose to ignore the value. 6
7
TIA-2001.4-C
297 Section 4
4.2.13 Mobile Identity 1
The purpose of the mobile identity information element is to provide the MS Electronic 2
Serial Number (ESN), the International Mobile Subscriber Identity (IMSI), or the 3
Broadcast Address. 4
The International Mobile Subscriber Identifier (IMSI) does not exceed 15 digits and the 5
ESN is a 32 bit field separated into a Manufacturer code, the Serial Number and a 6
Reserved field. The Broadcast Address is used to deliver Short Messages to groups of 7
subscribers, has the format specified in section 3.4.3.2 of [20] and is mapped to the 8
Mobile Identity element as shown below. 9
The following is the Mobile Identity element coding: cdma2000
. 10
Warning: The length limit for this information element was 10 octets in IOS v2.0a, IOS 11
v2.1, and IOS v3.0.0. Care needs to be exercised for interoperability with 12
implementations based on the previous standard. 13
4.2.13 Mobile Identity
7 6 5 4 3 2 1 0 Octet
Length 2
Identity Digit 1 Odd/even
Indicator
Type of Identity 3
Identity Digit 3 Identity Digit 2 4

Identity Digit N+1 Identity Digit N k
The A1 Element Identifier is not included when this information element is sent as a 14
mandatory element as part of a DTAP message. 15
Length: 16
Type of Identity: 18
This field is defined as follows: 19
Table 4.2.13-1 Mobile Identity - Type of Identity Coding 20
Binary Values Meaning
000 No Identity Code
010 Broadcast Address
101 ESN
110 IMSI
Odd/Even Indicator (octet 3; bit 3): 21
This field is set to 0 for an even number of digits and to 1 for an odd 22
number of identity digits. 23
Identity Digits N(octet 3 etc.): 24
These fields are coded as follows: 25
TIA-2001.4-C
Section 4 298
The International Mobile Subscriber Identifier fields are coded using 1
BCD coding format. If the number of identity digits is even then bits 4 2
to 7 of the last octet shall be filled with an end mark coded as 1111. 3
The ESN is not separated into digits, and occupies octets 4-7 with the 4
most significant bit in octet 4 bit 7. Identity Digit 1 in octet 3 is unused 5
and coded as 0000. 6
For Broadcast Address (type 010), the Mobile Identity is encoded as 7
specified below based on [20]. 8
9
7 6 5 4 3 2 1 0 Octet
Length 2
Reserved Type of Identity 3
Priority Message ID 4
Zone ID 5
(MSB) Service 6
(LSB) 7
Language 8
Length: 10
This field indicates the number of octets in this element following the 11
Length field. 12
Type of Identity: 13
This field is defined as shown above. 14
Priority: 15
This field indicates the priority level of this broadcast message to the 16
MS. 17
Message ID: 18
This field contains a value used by the MS to distinguish between 19
different messages from the same broadcast service transmitted within 20
the time period established for broadcast duplicate detection in the MS. 21
Zone ID: 22
This field contains a value used by the MS to distinguish between 23
messages from the same broadcast service transmitted in different 24
geographic regions. 25
Service: 26
This field contains the service category. The MS should receive and 27
process the broadcast message or page if the Service field contains a 28
service category that the MS has been configured to receive. 29
Language: 30
This field contains a value used by the MS to distinguish the language 31
used in the content of the broadcast message. 32
TIA-2001.4-C
299 Section 4
4.2.14 Slot Cycle Index 1
The Slot Cycle Index element is unique to cdma2000
MSs. It contains a parameter used 2

in computation of the paging timeslot, allowing discontinuous reception in the MS. It is 3
coded as follows: 4
4.2.14 Slot Cycle Index
7 6 5 4 3 2 1 0 Octet
Reserved Slot Cycle Index 2
Note that the Classmark Information Type 2 element contains an indication of whether 5
the MS is operating in slotted or non-slotted mode. Also refer to section 4.2.12. 6
Reserved: 7
This is coded as 00000. 8
Slot Cycle Index: 9
This field is coded as specified in [1]-[6]. 10
11
12
TIA-2001.4-C
Section 4 300
4.2.15 Priority 1
This element indicates the PACA priority of the call and is coded as follows: 2
4.2.15 Priority
7 6 5 4 3 2 1 0 Octet
Length 2
Reserved Call Priority Queuing
Allowed
Preemption
Allowed
3
Length: 3
Reserved: 5
Call Priority: 7
This field allows prioritizing of requests for mobile connections. The 8
priorities are ordered from 0000 (highest priority) to 1111 (lowest 9
priority). 10
The meaning of the priorities are as follows: 11
Table 4.2.15-1 Call Priority 12
Binary Values
bits 5-4-3-2

Meaning
0000 Priority Level 0 (highest)
0001 Priority Level 1
1111 Priority Level 15 (lowest)
Queuing Allowed: 13
This field is coded as shown in table 4.2.15-2. 14
TIA-2001.4-C
301 Section 4
Table 4.2.15-2 Priority - Queuing Allowed 1
Binary Values
bit 1

Meaning
0 queuing not allowed
1 queuing allowed
Preemption Allowed: 2
Table 4.2.15-3 Priority - Preemption Allowed 4
Binary Values
bit 0

Meaning
0 preemption not allowed
1 preemption allowed
5
6
TIA-2001.4-C
Section 4 302
4.2.16 Cause 1
This element is used to indicate the reason for occurrence of a particular event and is 2
coded as shown below. 3
4.2.16 Cause
7 6 5 4 3 2 1 0 Octet
Length 2
0/1 Cause Value 3
A Cause information element exists for multiple interfaces. The cause values defined in 4
this document are specific to the A1 interface. 5
Length: 6
Cause Value: 8
The cause value field is a single octet field if the extension bit (bit 7) is 9
set to 0. If bit 7 of octet 3 is set to 1 then the cause Value is a two 10
octet field. If the value of the first octet of the cause field is 1XXX 11
0000 then the second octet is reserved for national applications, where 12
XXX indicates the Cause Class as indicated in the table below. 13
Table 4.2.16-1 Cause Class Values 14
000 Normal event
001 Normal event
010 Resource unavailable
011 Service or option not available
100 Service or option not implemented
101 Invalid message (e.g., parameter out of range)
110 Protocol error
111 Interworking
15
Table 4.2.16-2 Cause Values
6 5 4 3 2 1 0 Hex
Value
Cause
Normal Event Class (000 xxxx and 001 xxxx)
0 0 0 0 0 0 0 00 Radio interface message failure
0 0 0 0 0 0 1 01 Radio interface failure
0 0 0 0 0 1 0 02 Uplink quality
0 0 0 0 0 1 1 03 Uplink strength
0 0 0 0 1 0 0 04 Downlink quality
0 0 0 0 1 0 1 05 Downlink strength
0 0 0 0 1 1 0 06 Distance
TIA-2001.4-C
303 Section 4
6 5 4 3 2 1 0 Hex
Value
Cause
0 0 0 0 1 1 1 07 OAM&P intervention
0 0 0 1 0 0 0 08 MS busy
0 0 0 1 0 0 1 09 Call processing
0 0 0 1 0 1 0 0A Reversion to old channel
0 0 0 1 0 1 1 0B Handoff successful
0 0 0 1 1 0 0 0C No response from MS
0 0 0 1 1 0 1 0D Timer expired
0 0 0 1 1 1 0 0E Better cell (power budget)
0 0 0 1 1 1 1 0F Interference
0 0 1 0 0 0 0 10 Packet call going dormant
0 0 1 0 0 0 1 11 Service option not available
0 0 1 0 1 0 1 15 Short data burst authentication failure
0 0 1 0 1 1 1 17 Time critical relocation/handoff
0 0 1 1 0 0 0 18 Network optimization
0 0 1 1 0 0 1 19 Power down from dormant state
0 0 1 1 0 1 0 1A Authentication failure
0 0 1 1 0 1 1 1B Inter-BS soft handoff drop target
0 0 1 1 1 0 1 1D Intra-BS soft handoff drop target
0 0 1 1 1 1 0 1E Autonomous Registration by the Network
Resource Unavailable Class (010 xxxx)
0 1 0 0 0 0 0 20 Equipment failure
0 1 0 0 0 0 1 21 No radio resource available
0 1 0 0 0 1 0 22 Requested terrestrial resource unavailable
0 1 0 0 1 0 1 25 BS not equipped
0 1 0 0 1 1 0 26 MS not equipped (or incapable)
0 1 0 0 1 1 1 27 2G only sector
0 1 0 1 0 0 0 28 2G only carrier
0 1 0 1 0 0 1 29 PACA call queued
0 1 0 1 0 1 1 2B Alternate signaling type reject
0 1 0 1 1 0 1 2D PACA queue overflow
0 1 0 1 1 1 0 2E PACA cancel request rejected
Service or Option Not Available Class (011 xxxx)
0 1 1 0 0 0 0 30 Requested transcoding/rate adaptation unavailable
0 1 1 0 0 0 1 31 Lower priority radio resources not available
0 1 1 0 0 1 1 33 TFO control request failed
0 1 1 0 1 0 0 34 MS rejected order
Service or Option Not Implemented Class (100 xxxx)
1 0 0 0 1 0 1 45 PLD-related capability not available or not
supported)
Invalid Message Class (101 xxxx)
1 0 1 0 0 0 0 50 Terrestrial circuit already allocated
Protocol Error (110 xxxx)
1 1 0 0 0 0 0 60 Protocol error between BS and MSC
Interworking (111 xxxx)
1 1 1 0 0 0 1 71 ADDS message too long for delivery on the paging
channel
1 1 1 0 1 1 1 77 PPP session closed by the MS
1 1 1 1 0 0 0 78 Do not notify MS
TIA-2001.4-C
Section 4 304
6 5 4 3 2 1 0 Hex
Value
Cause
1 1 1 1 0 0 1 79 PCF (or PDSN) resources are not available
1 1 1 1 0 1 0 7B Concurrent authentication
1 1 1 1 1 1 1 7F Handoff procedure time-out
All other values
Reserved for future use.
a. Used prior to version 3.0.0 of this specification only. 1
2
TIA-2001.4-C
305 Section 4
4.2.17 Cell Identifier 1
This element uniquely identifies a particular cell and is of variable length depending on 2
how the cell is identified. The fields of this element are shown below: 3
4.2.17 Cell Identifier
7 6 5 4 3 2 1 0 Octet
Length 2
Cell Identification Discriminator 3
Cell Identification variable
Length: 4
Length field. The length depends on the Cell Identification 6
Discriminator (octet 3). 7
Cell Identification Discriminator: 8
The Cell Identification Discriminator is a binary number indicating if 9
all or a part of the Cell Global Identification (e.g., one or more of the 10
following: MCC, MNC, LAC, MSCID, CI) is used for cell 11
identification in octets 4 through n. The Cell Identification 12
Discriminator is coded as follows: 13
14
Table 4.2.17-1 Cell Identifier - Cell Identification Discriminator List 15
0000 0010 Cell Identity (CI) is used to identify the cell.
0000 0101 Location Area Code (LAC) is used to identify all cells within a location area.
0000 0111
a
IS-41 whole Cell Global Identification (ICGI) is used to identify the cell.
a. When the Cell Identifier is used to identify a cell controlled by another MSC, type 16
0000 0111 is used. 17
Cell Identification: 18
This field includes a unique identification number for the cell being 19
referenced. It is coded as indicated below, depending on the value of 20
the Cell Identifier Discriminator. The fields shall be coded as shown in 21
Table 4.2.17-2: 22
Table 4.2.17-2 Cell Identifier - Cell Identification Discriminator = 0000 0010 23
7 6 5 4 3 2 1 0 Octet
(MSB) Cell 4
Sector (LSB) 5
Cell/Sector: 24
In the Cell/Sector value field bit 7 of octet 4 is the most significant bit 25
and bit 0 of octet 5 is the least significant bit. Bits 3 to 0 of octet 5 26
contain the sector number (0H = omni). The coding of the cell identity 27
is the responsibility of each administrator. Coding using full 28
TIA-2001.4-C
Section 4 306
hexadecimal representation may be used. The cell identity consists of 2 1
octets maximum. If an administrator has chosen N bits for the cell 2
identity where N <16 then the additional bits up to 16 are coded with a 3
0 in each in the following way: 4
If 8 <N<16 the bits N-8 through 7 of octet 5 are coded with a 0 in 5
each. 6
If N=8 then octet 5 is coded with a 0 in each bit. 7
If N<8 then octet 5 is coded with a 0 in each bit and bits N through 4 8
of octet 3 are coded with a 0 in each. 9
7 6 5 4 3 2 1 0 Octet
(MSB) LAC 4
LAC cont. (LSB) 5
LAC: 11
In the LAC field bit 7 of octet 4 is the most significant bit and bit 0 of 12
octet 5 is the least significant bit. The coding of the location area code 13
is the responsibility of each administrator. Location Area Code (LAC) 14
is an operator-defined identifier for a set of cells. LAC is not defined by 15
the IOS for features (i.e., features are not LAC dependent). In this 16
standard the LAC field is supported; however, it may be ignored or 17
filled with zeros at the suppliers option, and shall not cause a protocol 18
error. 19
7 6 5 4 3 2 1 0 Octet
MSB MSCID 4
5
LSB 6
MSB Cell 7
Sector LSB 8
MSCID: 21
The MSCID is coded as defined in [9], section 6.5.2.82. MSCID is 3 22
octets long where the first two octets (octets 4 and 5) represent Market 23
ID and the last octet represents the Switch Number. In the MSCID 24
field, bit 7 of octet 4 is the most significant bit and bit 0 of octet 5 is the 25
least significant bit of the Market ID field. In the MSCID field bit 7 of 26
octet 6 is the most significant bit of the Switch Number field. 27
Cell/Sector: 28
TIA-2001.4-C
307 Section 4
each. 2
6
TIA-2001.4-C
Section 4 308
4.2.18 Cell Identifier List 1
This element uniquely identifies cells and is of variable length containing the following 2
fields: 3
4.2.18 Cell Identifier List
7 6 5 4 3 2 1 0 Octet
Length 2
Cell Identification 1 4

Cell Identification n k
Length: 4
The Length field is a binary value indicating the number of octets 5
following the Length field. 6
Refer to section 4.2.17 for a description of this field. 8
Cell Identification n (octets 4 k): 9
Refer to section 4.2.17 for a description of these fields. 10
11
12
TIA-2001.4-C
309 Section 4
4.2.19 Circuit Identity Code (CIC) 1
This element defines the terrestrial channel over which the call is to pass. It contains the 5 2
least significant bits of a binary representation of the timeslot assigned to the circuit. The 3
remaining bits in the CIC are used where necessary, to identify one among several 4
systems interconnecting an originating and destination point. 5
The Circuit Identity Code defines the PCM multiplex and timeslot in use at the MSC. In 6
cases where re-multiplexing takes place between the MSC and BS a translation may be 7
necessary at the BS. 8
4.2.19 Circuit Identity Code (CIC)
7 6 5 4 3 2 1 0 Octet
a b c d e f g h 2
i j k x x x x x 3
Bits a-k: 9
These bits define the PCM multiplexer in use. 10
Bits xxxxx: 11
These bits define the actual timeslot in use. 12
13
14
TIA-2001.4-C
Section 4 310
4.2.20 Circuit Identity Code Extension 1
This variable length element defines a full rate terrestrial channel. 2
4.2.20 Circuit Identity Code Extension
7 6 5 4 3 2 1 0 Octet
Length 2
(MSB) Circuit Identity Code 3
Circuit Identity Code (cont.) (LSB) 4
Reserved Circuit Mode 5
Length: 3
Circuit Identity Code: 5
This field is coded as specified in octets 2-3 of section 4.2.19. 6
Reserved: 7
Circuit Mode: 9
This field informs the MSC about the use of this element, and is 10
encoded as follows: 11
Table 4.2.20-1 Circuit Identity Code Extension - Circuit Mode Field 12
Binary
Value
Name Meaning
0000 Full-rate Full-rate circuit operation.
All other values reserved
TIA-2001.4-C
311 Section 4
4.2.21 Special Service Call Indicator 1
The presence of this information element in a message indicates to the MSC that the MS 2
has initiated an emergency call. Associated with this emergency call, the MS may also 3
initiate a position location session without the use of a service option. 4
4.2.21 Special Service Call Indicator
7 6 5 4 3 2 1 0 Octet
Length 2
Reserved MOPD GECI 3
Length: 5
Length field. 7
Reserved: 8
MOPD: 10
Mobile Originated Position Determination. This field is set to 1 if the 11
GECI field is set to 1 and the MS initiates a position location session 12
associated with the global emergency call. 13
GECI: 14
Global Emergency Call Indication. This field is set to 1 if the user 15
indicated an emergency call in the cdma2000
air interface message. 16

17
18
TIA-2001.4-C
Section 4 312
4.2.22 Downlink Radio Environment 1
This element includes signal strength measurement information that was made by the 2
MS. It is of variable length and is coded as follows: 3
4.2.22 Downlink Radio Environment
7 6 5 4 3 2 1 0 Octet
Length 2
Number of cells 3
Cell Identification 1 5-k
Reserved Downlink Signal Strength Raw k+1
CDMA Target One Way Delay (high part) k+2
CDMA Target One Way Delay (low part) k+3

Cell Identification n m-n
Reserved Downlink Signal Strength Raw n+1
CDMA Target One Way Delay (high part) n+2
CDMA Target One Way Delay (low part) n+3
Length: 4
Number of Cells: 6
Octet 3 indicates the number of cells represented by this element. For 7
each cell, the Cell Identification, Downlink Signal Strength Raw, and 8
CDMA Target One Way Delay fields are replicated. 9
This field is coded per section 4.2.17. It applies to all Cell Identification 11
fields present in this element. 12
This field is coded as per the equivalent octets described in section 14
4.2.17, and shall uniquely identify one cell. Only one cell can be 15
indicated per replication. 16
Reserved (octets k+1, n+1): 17
Downlink Signal Measurement Raw: 19
This field is an average signal level measured by the MS for the 20
specified cell. The method of measurement is unique to the signaling 21
system. The signal level is the last measurement average received from 22
the MS in its raw, not normalized format. 23
The range of values for this field is 0 to 63 where the units are defined 24
by 25
TIA-2001.4-C
313 Section 4
! "
2 10
10
log PS
1
where PS is the strength of this pilot measured as the sum of ratios of 2
received pilot energy per chip to the total received spectral density 3
(noise and signals) of at most k usable multi-path components, where k 4
is the number of demodulating elements supported by the MS. 5
CDMA Target One Way Delay: 6
This field shall contain the estimated one-way delay from the MS to the 7
associated target cell, according to the information reported by the MS. 8
The CDMA Target One Way Delay is specified in units of 100 ns, 9
using twos complement numbers to represent negative values. The BS 10
calculates the value of the CDMA Target One Way Delay as follows: 11
! (Target PN phase measured by the MS - Target pilot offset index 64 12
+ 13
CDMA Serving One Way Delay in PN chips) / 0.12288 " 14
Where: 15
The target PN phase is reported by the MS in the Pilot Strength 16
Measurement Message. 17
The target pilot offset index is derived by the BS from information in 18
the Pilot Strength Measurement Message. 19
The CDMA serving One Way Delay is the one way propagation delay 20
estimated by the BS in relation to CDMA System Time, refer to [2]. 21
Refer also to section 4.2.61, CDMA Serving One Way Delay. 22
23
TIA-2001.4-C
Section 4 314
4.2.23 IS-2000 Channel Identity 3X 1
This element specifies identity information for one or more cdma2000
radio channels 2
operating in 3X mode. 3
4.2.23 I S-2000 Channel Identity 3X
7 6 5 4 3 2 1 0 Octet
Length 2
OTD Physical Channel Count Frame Offset 3
Physical Channel Type 1 4
Rev_FCH_Gating Reverse Pilot
Gating Rate 1
QOF Mask 1 Walsh Code Channel Index 1
(high part)
5
Walsh Code Channel Index 1 (low part) 6
Pilot PN Code 1 (low part) 7
Pilot PN Code 1
(high part)
Reserved Power
combined
1
Freq.
Included
1
ARFCN 1 (high part) 8
ARFCN (low part) 9
Reserved Lower QOF Mask 1 Lower Walsh Code Channel
Index 1
(high part)
10
Lower Walsh Code Channel Index 1 (low part) 11
Reserved Upper QOF Mask 1 Upper Walsh Code Channel
Index 1
(high part)
12
Upper Walsh Code Channel Index 1 (low part) 13

Physical Channel Type n k
Rev_FCH_Gating Reverse Pilot
Gating Rate n
QOF Mask n Walsh Code Channel Index n
(high part)
k+1
Walsh Code Channel Index n (low part) k+2
Pilot PN Code n (low part) k+3
Pilot PN Code n
(high part)
Reserved Power
combined
n
Freq.
Included
n
ARFCN n (high part) k+4
ARFCN n (low part) k+5
Reserved Lower QOF Mask n Lower Walsh Code Channel
Index n
(high part)
k+6
Lower Walsh Code Channel Index n (low part) k+7
TIA-2001.4-C
315 Section 4
4.2.23 I S-2000 Channel Identity 3X
7 6 5 4 3 2 1 0 Octet
Reserved Upper QOF Mask n Upper Walsh Code Channel
Index n
(high part)
k+8
Upper Walsh Code Channel Index n (low part) k+9
Length: 1
Length field. The length of this element is variable because more than 3
one target cell may be requested in a hard handoff. Therefore, this 4
element provides the flexibility to specify multiple channels that the 5
target BS can accommodate. 6
Orthogonal Transmit Diversity (OTD): 7
This bit shall be set to 1 to indicate that the MS is using OTD. It is set 8
to 0 otherwise. 9
Physical Channel Count: 10
Number of IS-2000 physical channels that are being handed off. 11
Frame Offset: 12
source. 15
The remaining fields are repeated once for each physical channel type for each cell. 16
Physical Channel Type: 17
This field contains the binary value used to indicate the type of physical 18
channel. Valid values are shown in Table 4.2.23-1. 19
Table 4.2.23-1 I S-2000 Channel Identity 3X- Physical Channel Type 20
Hex Values Meaning
01H
Fundamental Channel (FCH) cdma2000

02H
Dedicated Control Channel (DCCH) cdma2000

Rev_FCH_Gating: 23
This field is used to indicate availability of the reverse FCH gating 24
mode. The field is set to 1 if the BS allows the MS to perform reverse 25
FCH gating mode; otherwise it is set to 0. 26
In messages sent from the source BS that contain the IS-2000 Channel 27
Identity 3X IE, this field indicates whether or not the source BS 28
allowed the MS to perform reverse FCH gating. 29
In messages sent from the target BS that contain the IS-2000 Channel 30
Identity 3X IE, this field indicates whether or not the target BS will 31
allow the MS to perform reverse FCH gating after the handoff. 32
TIA-2001.4-C
Section 4 316
Reverse Pilot Gating Rate: 1
This field is used to indicate the gating rate for the Reverse Pilot 2
channel as shown in Table 4.2.23-2. 3
Table 4.2.23-2 I S-2000 Channel Identity 3X- Reverse Pilot Gating Rate 4
00 Gating rate 1
01 Gating rate 1/2
10 Gating rate 1/4
11 Reserved
QOF Mask: 5
This field contains the QOF (Quasi-Orthogonal Function) mask index 6
as specified in [2]. This QOF Mask is used with the center frequency 7
channel. 8
This field specifies one of 256 possible Walsh Codes used to 10
channelize the downlink RF bit stream in a cdma2000
call. The high 11

order 3 bits are reserved for future expansion. This Walsh Code is used 12
with the center frequency channel. 13
Pilot PN Code: 14
Power Combined: 19
The Power Combined field is a flag that, when set to 1, indicates 20
diversity combining of the power control sub-channel of this TIA/EIA- 21
2000 code channel with the previous cdma2000
code channel 22
supporting the same physical channel listed in this element. In other 23
words, if this is the second replication of octets k through k+9, then the 24
power control sub-channel of this cdma2000
code channel is diversity 25

combined with power control sub-channel of the previous replication of 26
octets k through k+9. The first occurrence of this field in the IS-2000 27
Channel Identity element is set to zero. 28
Freq. Included: 29
The Frequency Included field is a flag indicating whether the frequency 30
assignment is included. A 0 indicates no frequency assignment is 31
present, a 1 indicates a frequency assignment is present and is 32
specified in the ARFCN field of this element. 33
ARFCN: 34
This field identifies the Absolute Radio Frequency Channel Number 35
relative to the band class for the call association. This channel number 36
refers to the center frequency channel. 37
TIA-2001.4-C
317 Section 4
Lower QOF Mask: 3
This field contains the QOF mask index as specified in [2] that is used 4
with the lower frequency channel in a 3X system. 5
Lower Walsh Code Channel Index: 6
call. The high 8

with the lower frequency channel. 10
Upper QOF Mask: 13
This field contains the QOF mask index as specified in [2] that is used 14
with the upper frequency channel in a 3X system. 15
Upper Walsh Code Channel Index: 16
call. The high 18

with the upper frequency channel. 20
21
TIA-2001.4-C
Section 4 318
4.2.24 Source PDSN Address 1
This element contains an IPv4 IP Address of the A11 interface for a source PDSN. 2
3
4.2.24 Source PDSN Address
7 6 5 4 3 2 1 0 Octet
Length 2
(MSB) Source PDSN Address 3
4
5
(LSB) 6
Length: 4
Length field. 6
Source PDSN Address: 7
This field contains an IPv4 address of the A11 interface for a source 8
PDSN. 9
10
TIA-2001.4-C
319 Section 4
4.2.25 Handoff Power Level 1
This element contains the desired Handoff Power Level of the MS. This element is 2
applicable when operating in a CDMA system and the target BS is in an analog [18] 3
system. 4
4.2.25 Handoff Power Level
7 6 5 4 3 2 1 0 Octet
Length 2
Number of Cells 3
Reserved ID Type Handoff Power Level 4
Cell Identification 1 5-8
Reserved Handoff Power Level 9

Reserved Handoff Power Level j
Length: 5
Number of Cells: 7
Octet 3 indicates the number of cells represented by this element. For 8
each cell, the Handoff Power Level and Cell Identification fields are 9
replicated. 10
ID Type: 13
This field specifies the type of Cell Identification. If the ID Type field 14
is set to 01, Cell Identification shall be formatted according to Cell 15
Identification Discriminator 0000 0111. All other ID Type value are 16
reserved. 17
Handoff Power Level: 18
This field provides a recommendation of the uplink power level that the 19
mobile should use when accessing the target on handoff. 20
This field is coded as per the Cell Identification field described in 22
section 4.2.17. The first instance of the Cell Identification field in this 23
element shall be formatted according to Cell Identification 24
Discriminator Cell Identification Discriminator 0000 0111. 25
Subsequent instances shall be formatted according to Cell Identification 26
Discriminator 0000 0010. 27
Reserved (octets 9, , j) : 28
30
TIA-2001.4-C
Section 4 320
4.2.26 User Zone ID 1
This element uniquely identifies a particular User Zone 2
4.2.26 User Zone ID
7 6 5 4 3 2 1 0 Octet
Length 2
(MSB) UZID 3
(LSB) 4
Length: 3
Length field. 5
UZID: 6
This field contains a User Zone ID value as sent by the MSC or MS. 7
The MSC is responsible for any mapping of this 16-bit value to the 24- 8
bit value defined in [9]. 9
TIA-2001.4-C
321 Section 4
This element specifies identity information for one or more cdma2000
radio channels. 2
7 6 5 4 3 2 1 0 Octet
Length 2
OTD Physical Channel Count Frame Offset 3
Physical Channel Type 1 4
Rev_FCH
_Gating 1
Reverse Pilot Gating
Rate 1
QOF Mask 1 Walsh Code Channel Index 1
(high part)
5
Walsh Code Channel Index 1 (low part) 6
Pilot PN Code 1 (low part) 7
Pilot PN
Code 1
(high
part)
Reserved Power
combined
1
Freq.
Included
1
ARFCN 1 (high part) 8
ARFCN 1 (low part) 9

Physical Channel Type n k
Rev_FCH
_Gating n
Reverse Pilot Gating
Rate n
QOF Mask n Walsh Code Channel Index n
(high part)
k+1
Walsh Code Channel Index n (low part) k+2
Pilot PN Code n (low part) k+3
Pilot PN
Code n
(high
part)
Reserved Power
combined
n
Freq.
Included
n
ARFCN n (high part) k+4
ARFCN n (low part) k+5
Length: 3
Length field. The length of this element is variable because more than 5
one target cell may be requested in a hard handoff. Therefore, this 6
element provides the flexibility to specify multiple channels that the 7
target BS can accommodate. 8
OTD: 9
to 0 otherwise. 11
Physical Channel Count: 12
Number of IS-2000 physical channels that are being handed off. 13
TIA-2001.4-C
Section 4 322
Frame Offset: 1
source. 4
The remaining fields are repeated once for each physical channel type for each cell. 5
This field contains the binary value used to indicate the type of physical 7
channel. Valid values are shown in Table 4.2.27-1. 8
Table 4.2.27-1 I S-2000 Channel Identity - Physical Channel Type 9
Hex Values Meaning
01H
Fundamental Channel (FCH) cdma2000

02H
Dedicated Control Channel (DCCH) cdma2000

Rev_FCH_Gating: 10
This field is used to indicate availability of the reverse FCH gating 11
mode. The field is set to 1 if the BS allows the MS to perform reverse 12
FCH gating mode; otherwise it is set to 0. 13
In messages sent from the source BS that contain the IS-2000 Channel 14
Identity IE, this field indicates whether or not the source BS allowed 15
the MS to perform reverse FCH gating. 16
In messages sent from the target BS that contain the IS-2000 Channel 17
Identity IE, this field indicates whether or not the target BS will allow 18
the MS to perform reverse FCH gating after the handoff. 19
Reverse Pilot Gating Rate: 20
This field is used to indicate the gating rate for the Reverse Pilot 21
channel as shown in Table 4.2.27-2. 22
Table 4.2.27-2 I S-2000 Channel Identity - Reverse Pilot Gating Rate 23
00 Gating rate 1
01 Gating rate
10 Gating rate
11 Reserved
QOF Mask: 24
as specified in [2]. 26
call. The high 29

order 3 bits are reserved for future expansion. 30
Pilot PN Code: 31
TIA-2001.4-C
323 Section 4
Reserved (octet 8, , k+4): 1
Power Combined: 3
The Power Combined field is a flag that, when set to 1, indicates 4
diversity combining of the power control sub-channel of this 5
cdma2000
code channel with the previous cdma2000
code channel 6
supporting the same physical channel listed in this element. In other 7
words, if this is the second replication of octets k through k+5, then the 8
power control sub-channel of this cdma2000
code channel is diversity 9

combined with power control sub-channel of the previous replication of 10
octets k through k+5. The first occurrence of this field in the IS-2000 11
Channel Identity element is set to zero. 12
Freq. Included: 13
The Frequency Included field is a flag indicating whether the frequency 14
assignment is included. A 0 indicates no frequency assignment is 15
present, a 1 indicates a frequency assignment is present and is 16
specified in the ARFCN field of this element. 17
ARFCN: 18
This field identifies the Absolute Radio Frequency Channel Number 19
relative to the band class for the call association. 20
21
TIA-2001.4-C
Section 4 324
4.2.28 Response Request 1
The presence of this element indicates that a response is required by the sender. The 2
element has a fixed length of one octet. Each procedure that uses this element shall 3
specify the appropriate responses. 4
4.2.28 Response Request
7 6 5 4 3 2 1 0 Octet
TIA-2001.4-C
325 Section 4
4.2.29 MS Measured Channel Identity 1
This element indicates the band class and frequency that has been measured by the MS in 2
preparation for a hard handoff. 3
Note: This element was formerly called IS-95 MS Measured Channel Identity in 4
previous versions of this standard. 5
4.2.29 MS Measured Channel Identity
7 6 5 4 3 2 1 0 Octet
Length 2
Band Class (MSB) ARFCN 3
(LSB) 4
Length: 6
Length field. 8
Band Class: 9
The BS shall copy the band class from the Candidate Frequency Search 10
Report message received from the MS into this field when this element 11
is included in the Handoff Required message. The MSC shall copy this 12
value to the corresponding field in this same element in the Handoff 13
Request message. 14
ARFCN: 15
The BS shall set this field to the CDMA channel number in the 16
specified CDMA band class corresponding to the CDMA frequency 17
assignment for the candidate frequency. 18
19
TIA-2001.4-C
Section 4 326
4.2.30 Reserved 1
2
3
TIA-2001.4-C
327 Section 4
4.2.31 Layer 3 Information 1
This element is included in the Complete Layer 3 Information message. It contains either 2
the Location Updating Request message, CM Service Request message or Paging 3
Response message. 4
4.2.31 Layer 3 Information
7 6 5 4 3 2 1 0 Octet
Length 2
Layer 3 Information 3-n
Length: 5
This field indicates the number of octets following the Length field. 6
Layer 3 Information: 7
The coding of this field follows the DTAP message encoding rules, 8
and accordingly the Protocol Discriminator, Reserved Octet and 9
Message Type elements in octets 3, 4, and 5, respectively do not 10
include an Element Identifier. 11
12
TIA-2001.4-C
Section 4 328
4.2.32 Protocol Discriminator 1
This element distinguishes the messages belonging to the following procedures: 2
1. Call Processing and Call Related Supplementary Services 3
2. Mobility Management 4
3. Radio Resource Management 5
4. Facilities Management 6
5. Other Signaling Procedures 7
The message category of each DTAP message may be determined from Table 4.2.4-2. 8
4.2.32 Protocol Discriminator
7 6 5 4 3 2 1 0 Octet
Reserved Protocol Discriminator 1
Reserved: 9
These bits are coded as 0H. 10
Protocol Discriminator: 11
The coding of this field is shown in Table 4.2.32-1. 12
Table 4.2.32-1 Protocol Discriminator 13
3 2 1 0 Description
0 0 1 1 Call Processing and call related Supplementary Services
0 1 0 1 Mobility Management
0 1 1 0 Radio Resource Management
1 0 0 1 Facility Management
1 0 1 1 Other Signaling Procedures
1 1 1 1 reserved for test procedures
TIA-2001.4-C
329 Section 4
4.2.33 Reserved-Octet 1
This element, used in a DTAP message, does not have an element identifier. It uses a 2
single octet and is always coded as zero. 3
4.2.33 Reserved-Octet
7 6 5 4 3 2 1 0 Octet
0 0 0 0 0 0 0 0 1
4
5
TIA-2001.4-C
Section 4 330
4.2.34 Reserved 1
2
3
TIA-2001.4-C
331 Section 4
4.2.35 Authentication Confirmation Parameter (RANDC) 1
This element contains the Authentication Confirmation Parameter (RANDC) received 2
from the MS. The RANDC is included for the use of the network. 3
4.2.35 Authentication Confirmation Parameter (RANDC)
7 6 5 4 3 2 1 0 Octet
RANDC 2
RANDC: 4
This field contains the Authentication Confirmation Parameter 5
(RANDC) received from the MS. 6
TIA-2001.4-C
Section 4 332
4.2.36 Reject Cause 1
This element indicates the reason for rejecting an MS request by the network. 2
4.2.36 Reject Cause
7 6 5 4 3 2 1 0 Octet
Reject Cause Value 2
The Reject Cause Value: 3
Table 4.2.36-1 Reject Cause Value 5
Bit Positions Hex
7 6 5 4 3 2 1 0 Value Reject Cause
0 0 0 0 0 0 0 1 01 Reserved
0 0 0 0 0 0 1 0 02 MIN/IMSI unknown in HLR
0 0 0 0 0 0 1 1 03 Illegal MS
0 0 0 0 0 1 0 0 04 TMSI/IMSI/MIN unknown in VLR
0 0 0 0 0 1 0 1 05 Reserved
0 0 0 0 1 0 1 1 0B Roaming not allowed
0 0 0 0 1 1 0 0 0C Location area not allowed
0 0 1 0 0 0 0 0 20 Service option not supported
0 0 1 0 0 0 0 1 21 Requested service option not subscribed
0 0 1 0 0 0 1 0 22 Service option temporarily out of order
0 0 1 0 0 1 1 0 26 Call cannot be identified
0 1 0 1 0 0 0 1 51 Network failure
0 1 0 1 0 1 1 0 56 Congestion
0 1 1 0 0 0 1 0 62 Message type non-existent or not implemented
0 1 1 0 0 0 1 1 63 Information element non-existent or not
implemented
0 1 1 0 0 1 0 0 64 Invalid information element contents
0 1 1 0 0 1 0 1 65 Message not compatible with the call state
0 1 1 0 0 1 1 0 66 Protocol error, unspecified
0 1 1 0 1 1 1 0 6E Invalid message, unspecified
0 1 1 0 1 1 1 1 6F Mandatory information element error
All other values reserved.
6
7
TIA-2001.4-C
333 Section 4
4.2.37 AuthenticationChallenge Parameter 1
(RAND/RANDU/RANDBS/RANDSSD) 2
The Authentication Challenge Parameter information element provides a non-predictable 3
number which is used for authentication/SSD update. 4
4.2.37 AuthenticationChallenge Parameter (RAND/RANDU/RANDBS/RANDSSD)
7 6 5 4 3 2 1 0 Octet
Length 2
Reserved Random Number Type 3
(MSB) RAND/RANDU/RANDBS/RANDSSD Value 4
5-m
(LSB) m+1
Length: 5
Length field. 7
Reserved: 8
Random Number Type: 10
Table 4.2.37-1 Authentication Challenge Parameter - Random Number Type 11
Random Number
Type Value
Random Number
Type
Random Number
Length
0001 RAND 32 bits
0010 RANDU 24 bits
0100 RANDSSD 56 bits
1000 RANDBS 32 bits
RAND/RANDU/RANDBS/RANDSSD Value: 12
This field contains a non-predictable number that is used for 13
authentication/SSD update. Bit 7 of the lowest numbered octet is the 14
most significant bit, while bit 0 of the highest numbered octet is the 15
least significant bit. 16
17
TIA-2001.4-C
Section 4 334
4.2.38 Authentication Response Parameter (AUTHR/AUTHU/AUTHBS) 1
This element provides the authentication response signature calculated by the MS or the 2
network as appropriate. 3
In cdma2000
systems the authentication response may be the AUTHR, AUTHU, or 4

AUTHBS. 5
AUTHU and AUTHR are used in messages which are transmitted from the MS/BS to the 6
HLR/AC. AUTHBS is used in messages which are transmitted from the HLR/AC to the 7
MS/BS. 8
4.2.38 Authentication Response Parameter (AUTHR/AUTHU/AUTHBS)
7 6 5 4 3 2 1 0 Octet
Length 2
Reserved Auth Signature Type 3
0 0 0 0 0 0 (MSB) 4
Auth Signature 5
(LSB) 6
Length: 9
Length field. 11
Reserved: 12
Auth Signature Type: 14
This field identifies the type of authentication signature included in this 15
element and shall be set as follows: 16
Table 4.2.38-1 Authentication Response Parameter - Auth Signature Type 17
Auth Signature Type Value Auth Signature Type
0001 AUTHR
0010 AUTHU
0100 AUTHBS
All other values are reserved.
Auth Signature: 18
This field occupies the lower 18 bits in octets four through six. The 19
higher order bits in octet four are set to 0. Bit seven of octet four is 20
the most significant bit, while bit zero of octet six is the least 21
significant bit. This field contains the authentication signature 22
(AUTHR/AUTHU/AUTHBS). 23
24
TIA-2001.4-C
335 Section 4
4.2.39 Authentication Parameter COUNT 1
This element provides the HLR/AC with the MSs call history parameter. 2
4.2.39 Authentication Parameter COUNT
7 6 5 4 3 2 1 0 Octet
Reserved Count 2
Reserved: 3
Count: 5
This field contains the mobiles Call History Parameter (COUNT). 6
Refer to [4]. 7
8
TIA-2001.4-C
Section 4 336
4.2.40 Reserved 1
2
3
TIA-2001.4-C
337 Section 4
4.2.41 Reserved 1
2
3
TIA-2001.4-C
Section 4 338
4.2.42 Signal 1
This element is used by the MSC to transfer the information required for creating the tone 2
or the alerting signals to the BS for transmission in appropriate messages to the MS. This 3
information element may be repeated in a message. It is the responsibility of the MSC to 4
map any signal values received via [9] or other protocol into the values given below. 5
4.2.42 Signal
7 6 5 4 3 2 1 0 Octet
Signal Value 2
Reserved Alert Pitch 3
Note: This previously defined information element is no longer used and is maintained 6
here only for backwards compatibility. 7
Signal Value: 8
This field is coded as shown in table 4.2.42-1 and 4.2.42-2. 9
Table 4.2.42-1 Signal Value: Tones 10
Binary
Values
Meaning
0000 0000 Dial tone on
0000 0001 Ring back tone on
0000 0010 Intercept tone on
0000 0011 Network congestion (reorder) tone on
0000 0100 Busy tone on
0000 0101 Confirm tone on
0000 0110 Answer tone on
0000 0111 Call waiting tone on
0000 1000 Off-hook warning tone on
0011 1111 Tones off
11
12
TIA-2001.4-C
339 Section 4
Table 4.2.42-2 Signal Value: cdma2000
Alerting 1
Binary
Values
Meaning
0100 0000 Normal Alerting
0100 0001 Inter-group Alerting
0100 0010 Special/Priority Alerting
0100 0011 Reserved (ISDN Alerting pattern 3)
0100 0100 Ping Ring (abbreviated alert)
0110 0011 Abbreviated intercept
0110 0101 Abbreviated reorder
0100 1111 Alerting off
Reserved: 2
Alert Pitch: 4
Table 4.2.42-3 Signal - Alert Pitch Values 6
Binary
Values
Meaning
00 Medium pitch (standard alert)
01 High pitch
10 Low pitch
11 Reserved
7
TIA-2001.4-C
Section 4 340
Table 4.2.42-4 provides a mapping between signal values in [9], [1]~[6], and this 1
specification. 2
Table 4.2.42-4 Signal - Signal Value Mapping: TI A/EI A-41, TI A/EI A/I S-2000, and this Specification 3
Tone & Reference TONES (Signal Type = 00)
Reference TIA/EIA/IS-2000
Table 3.7.4.5-3
TIA/EIA-41.5
Table 117
Announcement Code
Value
TIA/EIA/IS-2001-A
Table 4.2.42-2

SIGNAL_TYPE SIGNAL
field

Dial Tone 00 000000 00000000 00000000
Ring Back 00 000001 00000001 00000001
Intercept 00 000010 00000010 00000010
Abbreviated Intercept 00 000011 11000001 01100011
Network Congestion 00 000100 00000011 00000011
Abbreviated Network
Congestion
00 000101 11000010 01100101
Busy 00 000110 00000100 00000100
Confirm 00 000111 00000101 00000101
Answer 00 001000 00000110 00000110
Call Waiting 00 001001 00000111 00000111
Tones Off 00 111111 00111111 00111111
SIGNAL_TYPE SIGNAL
field

No Tone (off) 10 000000 000000 10000000
Long (standard alert) 10 000001 000001 10000001
Short-Short 10 000010 000010 10000010
Short-Short-Long 10 000011 000011 10000011
Short-Short2 10 000100 000100 10000100
Short-Long-Short 10 000101 000101 10000101
Short-Short-Short-
Short
10 000110 000110 10000110
PBX Long 10 000111 000111 10000111
PBX Short-Short 10 001000 001000 10001000
PBX Short-Short-
Long
10 001001 001001 10001001
PBX Short-Long-
Short
10 001010 001010 10001010
PBX Short-Short-
Short-Short
10 001011 001011 10001011
4
TIA-2001.4-C
341 Section 4
Table 4.2.42-4 (Cont.) Signal - Signal Value Mapping: TI A/EI A-41, TI A/EI A/I S-2000, and this 1
Specification 2
Alert Type &
Reference
Alerting (Signal Type = 01)
Reference TIA/EIA/IS-2000
Table 3.7.5.5-3
TIA/EIA-41.5 Table
115, Cadence Octet of
Alert Code
TIA/EIA/IS-2001-A
Table 5.2.42-1

SIGNAL_TYPE SIGNAL
field

Normal Alerting 01 000000 000001 01000000
Intergroup Alerting 01 000001 NA
1
01000001
Special/Priority
Alerting
01 000010 NA 01000010
Rsvd (pattern 3) 01 000011 NA 01000011
Ping-ring 01 000100 NA 01000100

Rsvd (pattern 5) 01 000101 NA 01000101
Rsvd (pattern 6) 01 000110 NA 01000110
Rsvd (pattern 7) 01 000111 NA 01000111
Alerting Off 01 001111 000000 01001111

1
IS-41C does not support the Alert Codes marked NA.
TIA-2001.4-C
Section 4 342
4.2.43 CM Service Type 1
This element specifies the type of service requested from the network. 2
The CM Service Type information element is coded as shown below. It is a type 1 3
4.2.43 CM Service Type
7 6 5 4 3 2 1 0 Octet
1 A1 Element Identifier Service Type 1
Service Type: 5
This field is coded as shown in table 4.2.43-1 6
Table 4.2.43-1 CM Service Types 7
0001 Mobile originating call establishment
0010 Emergency call establishment
0100 Short Message transfer
1000 Supplementary service activation
8
9
TIA-2001.4-C
343 Section 4
4.2.44 Called Party BCD Number 1
The purpose of the Called Party BCD Number information element is to identify the 2
called party. 3
The Called Party BCD Number information element is coded as shown below. It is a type 4
4 information element with 19 octets length maximal. The maximum number of number 5
digit(s)/end mark(s) is 32. 6
4.2.44 Called Party BCD Number
7 6 5 4 3 2 1 0 Octet
Length 2
1 Type of Number Numbering Plan Identification 3
Number Digit/End Mark 2 Number Digit/End Mark 1 4
Number Digit/End Mark 4 Number Digit/End Mark 3 5

Number Digit/End Mark m+1 Number Digit/End Mark m n
Length: 7
If the Called Party BCD Number information element is included in a 9
Setup message for emergency call establishment, the Length field may 10
be set to 0. 11
Type of Number: 12
This field is coded as shown in table 4.2.44-1. Type of Number field in 13
octet 3 is coded as follows: 14
Table 4.2.44-1 Called Party BCD Number - Type of Number Values 15
000 Unknown
a

001 International number
b, d

010 National number
b

011 Network specific number
c

100 Dedicated PAD access, short code
101 Reserved
110 Reserved
111 Reserved for extension
a. The Type of Number unknown is used when the user of the network has no 16
knowledge of the Type of Number, e.g., international number, national number, etc. 17
In this case, the number digits/end marks field is organized according to the network 18
dialing plan (e.g., prefix or escape digits might be present). 19
b. Prefix or escape digits shall not be included. 20
TIA-2001.4-C
Section 4 344
c. The Type of Number network specific number is used to indicate 1
administration/service number specific to the serving network (e.g., used to access an 2
operator). 3
d. The international format shall also be accepted by the MSC when the call is destined 4
to the same country as the MSC. 5
Numbering Plan Identification: 6
Table 4.2.44-2 Called Party BCD Number - Numbering Plan Identification Values 8
Binary
Values
Meaning
0000 unknown
a

0001 ISDN/telephony number plan ([31])
0011 data number plan ([34])
0100 telex numbering plan ([33])
1000 national numbering plan
1001 private numbering plan
0111 reserved for extension
a. The numbering plan unknown is used when the user or network has no knowledge 9
of the numbering plan. In this case, the number digits/end marks field is organized 10
according to the network dialing plan (e.g., prefix or escape digits might be present). 11
Number Digits/End Marks: 12
These fields in octets 4 through n are coded as shown in table 4.2.44-3. 13
If the Called Party BCD Number element contains an odd number of 14
digits/end marks, bits 4 to 7 of the last octet shall be set to 1111. 15
Table 4.2.44-3 Called Party BCD Number - Number Digit Values 16
0000

0
0001 1
0010 2
0011 3
0100 4
0101 5
0110 6
0111 7
1000 8
1001 9
1010

*
1011

#
1100 a
1101 b
TIA-2001.4-C
345 Section 4
1110 c
1111 used as end
mark in case of
odd number
information
1
TIA-2001.4-C
Section 4 346
4.2.45 Quality of Service Parameters 1
This element identifies the Quality of Service for a given packet service. In this version 2
of this standard the only information carried is non-assured mode packet priority. 3
4.2.45 Quality of Service Parameters
7 6 5 4 3 2 1 0 Octet
Length 2
Reserved Non-Assured Mode Packet Priority 3
Length: 4
Length field. 6
Reserved: 7
This field shall be set to 0000 and ignored. 8
Non-Assured Mode Packet Priority: 9
This field indicates the priority of a non-assured packet data service as 10
a binary value. Value 0000 is the lowest priority. Value 1101 is the 11
highest priority. Values 1110 and 1111 are reserved. 12
TIA-2001.4-C
347 Section 4
4.2.46 Cause Layer 3 1
This element is included to provide the reason for generating certain messages, to provide 2
diagnostic information in the event of procedural errors and to indicate the location of the 3
cause originator. 4
The Cause Layer 3 is a type 4 information element. 5
4.2.46 Cause Layer 3
7 6 5 4 3 2 1 0 Octet
Length 2
ext=1 Coding Standard Reserved Location 3
ext=1 Cause Value 4
Length: 6
Length field. 8
Ext: 9
Refer to section 4.1.4 for the coding of extension bits (bit 7 in octets 3 10
and 4). 11
Coding Standard: 12
Table 4.2.46-1 Cause Layer 3 - Coding Standard 14
00 Standard as described in [35]
01 Reserved for other international standards
10 National standard
11 Reserved for other international standards
Reserved: 15
Location: 17
19
20
TIA-2001.4-C
Section 4 348
Table 4.2.46-2 Cause Layer 3 - Location 1
0000 User
0001 Private network serving the local user
0010 Public network serving the local user
0011 Transit network
0100 Public network serving the remote user
0101 Private network serving the remote user
0111 International network
1010 Network beyond interworking point
Cause Value: 2
The cause value field is divided into two subfields: a Class (bits 4 3
through 6) and a value within the Class (bits 0 through 3). 4
The class indicates the general nature of the event, and is coded as 5
shown in table 4.2.46-3. 6
Table 4.2.46-3 Cause Layer 3 - Cause (Class) Value 7
Class (000) Normal event
Class (001) Normal event
Class (010) Resource unavailable
Class (011) Service or option not available
Class (100) Service or option not implemented
Class (101) Invalid message (e.g., parameter out of range)
Class (110) Protocol error (e.g., unknown message)
Class (111) Interworking
8
The values for each class are shown in table 4.2.46-4. 9
10
TIA-2001.4-C
349 Section 4
Table 4.2.46-4 Cause Layer 3 Values 1
Binary Cause
Values

Cause Diagnostic Remarks
Class (000) and Class (001) - Normal Event
000 0001 Unassigned (unallocated) number
000 0011 No route to destination
000 0110 Channel unacceptable
000 1111 Procedure failed
001 0000 Normal Clearing
001 0001 User busy
001 0010 No user responding
001 0011 User alerting, no answer
001 0101 Call rejected
001 0110 Number changed new destination
a

001 1010 Non selected user clearing
001 1011 Destination out of order
001 1100 Invalid number format (incomplete number)
001 1101 Facility rejected
001 1111 Normal, unspecified
Class (010) - Resource Unavailable
010 0010 No circuit/channel available
010 0110 Network out of order
010 1001 Temporary failure
010 1010 Switching equipment congestion
010 1011 Access information discarded information element ids
010 1100 requested circuit/channel not available
010 1111 Resources unavailable, unspecified
Class (011) - Service or Option Not Available
011 0001 Quality of service unavailable
011 0010 Requested facility not subscribed
011 0011 Request MUX option or rates unavailable
011 1001 Bearer capability not authorized
b

011 1010 Bearer capability not presently available
b

011 1011 SSD update rejected
011 1111 Service or option not available, unspecified
2
TIA-2001.4-C
Section 4 350
Table 4.2.46-4 (Cont.) Cause Layer 3 Values 1
Binary Cause
Values

Cause Diagnostic Remarks
Class (100) - Service or Option Not Implemented
100 0001 Bearer service not implemented
b

100 0101 Requested facility not implement
100 0110 Only restricted digital information bearer capability is available
b

100 1111 Service or option not implemented, unspecified
Class (101) - Invalid Message
101 0001 Reserved
101 1000 Incompatible destination incompatible parameter
c

101 1011 Invalid transit network selection
101 1111 Invalid message, unspecified
Class (110) - Protocol Error
110 0000 Mandatory information element error information element
identifier(s)
110 0001 Message type nonexistent or not implemented message type
110 0010 Message not compatible with control state message type or message
type nonexistent or not implemented
110 0100 Invalid information element contents information element
Identifier(s)
110 0101 Message not compatible with call state message type
110 1111 Protocol error, unspecified
Class (111) - Interworking
111 1111 Interworking, unspecified
All other values
reserved

a. New destination is formatted as the called party number information element, 2
including information element identifier. 3
b. These values are being kept for backward compatibility. 4
c. Incompatible parameter is composed of incompatible information element identifier. 5
TIA-2001.4-C
351 Section 4
4.2.47 Transcoder Mode 1
This element specifies the settings of the transcoder in the BS, for one party of the call. 2
4.2.47 Transcoder Mode
7 6 5 4 3 2 1 0 Octet
Length = [01H] 2
Reserved TFO
Mode
3
Length: 3
Length field. 5
Reserved: 6
TFO Mode: 8
This field specifies whether the transcoder should disable the inband 9
signaling mechanism and employ the speech coding algorithm 10
appropriate to the channel type (e.g., QCELP for cdma2000
) or enable 11
the inband signaling mechanism and attempt tandem free operation. 12
The bit is set to 0 for tandem mode, 1 for TFO. 13
TIA-2001.4-C
Section 4 352
4.2.48 Power Down Indicator 1
The presence of this type 2 element in a message indicates to the MSC that the MS has 2
powered down at the end of a call. Refer to section 4.1.3 for additional information on 3
type 2 IEs. 4
4.2.48 Power Down Indicator
7 6 5 4 3 2 1 0 Octet
5
6
TIA-2001.4-C
353 Section 4
4.2.49 Registration Type 1
This information element indicates the type of registration requested by an MS. An MS 2
registering on an access channel may initiate any of the following types of registration, 3
when enabled. This element shall not be included if the BS cannot determine the 4
registration type, and shall always be present in the case of power down registration. 5
4.2.49 Registration Type
7 6 5 4 3 2 1 0 Octet
Location Registration Type 2
Location Registration Type: 6
This field in octet 2 is coded as shown in table 4.2.49-1. 7
Table 4.2.49-1 Location Registration Type 8
0000 0000 Timer-based
0000 0001 Power-up
0000 0010 Zone-based
0000 0011 Power-down
0000 0100 Parameter-change
0000 0101 Ordered
0000 0110 Distance-based
0000 0111 User Zone-based
Timer Based Registration 9
Timer based registration is performed when a timer expires in the MS. This causes the 10
MS to register at regular intervals, allowing deregistration of inactive MSs by the 11
network. 12
Power Up Registration 13
Power up registration is performed when power is applied to the MS. This is used to 14
notify the network that the MS is now active. 15
Zone Based Registration 16
A mobile service area may be partitioned into smaller regions, called Zones, which is a 17
group of one or more cells. The MS identifies the current zone via parameters on the 18
forward control channel, which are specific to the air interface type. When the MS enters 19
a zone in which it is not registered, it may initiate zone based registration. Zone based 20
registration allows the network to limit paging to only the zone(s) in which the MS is 21
registered. 22
TIA-2001.4-C
Section 4 354
Power Down Registration 1
Power down registration may be performed when the MS is switched off. Power down 2
registration may occur as an independent procedure on the control channel, or an 3
indication of the power down may accompany a release operation on the traffic channel 4
for a call in progress. This latter form of power down registration is described in [13]. 5
Parameter Change Registration 6
Parameter change registration may be performed when specific operating parameters in 7
the MS are modified. 8
Ordered Registration 9
Ordered Registration occurs when the BS orders a MS to register with the network 10
(Network Initiated Registration). 11
Distance Based Registration 12
When the distance (computed via control channel parameters) between the current cell 13
and the cell where the MS last registered is exceeded by a threshold, distance based 14
registration may be performed by the MS. 15
User Zone Registration 16
User Zone Registration is performed when the MS selects an active User Zone while in 17
the idle state. 18
19
20
TIA-2001.4-C
355 Section 4
4.2.50 Tag 1
This element provides a reference for correlating a response to the original request. If the 2
sender desires a response, then this element is included in the request message. If this 3
element is received, the response message shall contain this element set to the received 4
Tag value. Use of this element allows multiple instances of a request to be outstanding 5
simultaneously. When the Tag element is used by the MSC on a message that causes 6
interaction with the MS on a traffic channel, the MSC shall be prepared to handle call 7
clearing. If call clearing occurs, the MSC is then aware that the MS may not have 8
received the information contained in that message. Unless the call is cleared, the BS 9
shall respond with the appropriate response message when the Tag element is included in 10
the request message. 11
4.2.50 Tag
7 6 5 4 3 2 1 0 Octet
Tag Value 2-5
Tag Value: 12
This field is a 32 bit fixed length field (octets 2 through 5). The value 13
of this field is a manufacturers concern. 14
15
TIA-2001.4-C
Section 4 356
4.2.51 Hard Handoff Parameters 1
This element is used to deliver information needed by the source BS to perform hard 2
handoff. 3
4.2.51 Hard Handoff Parameters
7 6 5 4 3 2 1 0 Octet
Reserved Band Class 2
Number of Preamble Frames Reset L2 Reset
FPC
Encryption Mode Private
LCM
3

Rev_Pwr
_Cntl_D
elay_Incl
Rev_Pwr_Cntl_delay Nom_
Pwr_Ext
Nom_Pwr

4
Reserved FPC Subchannel Information FPC
SubChan
Info
Included
5
Reserved Power Control Step Power
Control
Step
Included
6
Band Class: 4
The Band Class field corresponds to the CDMA frequency assignment 5
for the CDMA channel. The coding of this field is specified in [25]. 6
Number of Preamble Frames: 7
This field contains the number of traffic channel preamble frames that 8
the MS has to send when performing a hard handoff. All values 000 9
through 111 are valid. 10
Reset L2: 11
The Reset L2 (Reset Layer 2 Ack) field indicates whether the Layer 2 12
Ack sequence number is to be maintained or initialized after a hard 13
handoff is performed. The coding of this field is as follows: 14
0 Do not reset Layer 2 Ack 15
1 Reset Layer 2 Ack 16
Reset FPC: 17
The Reset FPC (Reset Forward Traffic Power Control) field indicates 18
whether the forward traffic channel counters are to be maintained or 19
initialized after a hard handoff is performed. The coding of this field is 20
as follows: 21
0 Do not reset counters 22
1 Reset counters 23
TIA-2001.4-C
357 Section 4
Encryption Mode: 1
This field indicates whether encryption is to be used for the messages 2
on the CDMA forward and reverse traffic channels. The encoding of 3
this field is as follows: 4
00 Encryption disabled 5
01 Encryption enabled 6
Private LCM: 7
This field indicates whether to use the private long code mask after a 8
hard handoff is performed. The coding of this field is as follows: 9
0 Do not use Private Long Code Mask 10
1 Use Private Long Code Mask 11
The Rev_Pwr_Cntl_Delay_Incl: 12
This field is set to 1 if the Rev_Pwr_Cntl_Delay field contains valid 13
information and is set to 0 if the Rev_Pwr_Cntl_Delay field is to be 14
ignored. 15
Rev_Pwr_Cntl_Delay: 16
The Rev_Pwr_Cntl_Delay (Reverse Power Control Delay)
1
field 17
contains the reverse link power control delay required after the handoff. 18
This field is coded per [5] when the target BS allows the MS to perform 19
the reverse FCH gating mode. Otherwise, this field is set to 0 0000. 20
Nom_Pwr_Ext: 21
This field is coded per [1]~[6]. 22
Nom_Pwr: 23
This field is coded per [1]~[6]. 24
FPC Subchannel Information: 25
This field contains the Forward power control subchannel relative gain 26
(FPC_SUBCHAN_GAIN) and is coded per [5].. This field shall only 27
be valid when the call is operating per [1]~[6]. Otherwise, this field 28
FPC SubChan Info Included: 30
This field is set to 1 if the FPC Subchannel Information field contains 31
valid information and is set to 0 if the FPC Subchannel Information 32
field is to be ignored. 33
Power Control Step: 34
This field is coded per [1]~[6] section 3.7.3.3.2.36. This field shall only 35
be included when the call is operating per [1]~[6]. Otherwise, this field 36

1
The base station shall set this field to the closed-loop reverse power control delay
minus one (the closed-loop reverse power control delay is the time between the end of
a gated-on reverse PCG and the beginning of the reverse PCG where the corresponding
feedback is sent on the Forward Power Control Subchannel) used by the MS after
handoff, in units of 1.25 ms.
TIA-2001.4-C
Section 4 358
Power Control Step Included: 1
This field is set to 1 if the Power Control Step field contains valid 2
information and is set to 0 if the Power Control Step field is to be 3
ignored. 4
TIA-2001.4-C
359 Section 4
4.2.52 Software Version 1
This element provides software version information about the sub-system originating the 2
message. Its definition is a BS and MSC manufacturer concern. 3
4.2.52 Software Version
7 6 5 4 3 2 1 0 Octet
Length 2
IOS Major Revision Level (X) 3
IOS Minor Revision Level (Y) 4
IOS Point Release Level (Z) 5
Manufacturer/Carrier Software Information 6-n
Length: 4
Length field. 6
IOS Major/Minor Revision / Point Release Level: 7
Each version of this standard is published with a version number in the 8
form X.Y.Z. These three values shall be placed in octets 3, 4, and 5 9
respectively as binary values. 10
Manufacturer/Carrier Software Information; 11
Each separate software load from a manufacturer shall have some 12
software load identity. In addition, the carrier may require the exchange 13
of specific information between entities in their network. This 14
information shall be placed in octets 6-n in ASCII format as agreed 15
between the carrier and the manufacturer. 16
TIA-2001.4-C
Section 4 360
4.2.53 Service Option 1
This element indicates the service option requested by the MS, or by the network. It is 2
coded as follows: 3
4.2.53 Service Option
7 6 5 4 3 2 1 0 Octet
(LSB) 3
Service Option: 4
For signaling type TIA/EIA/IS-2000, the Service Option field in octets 2 5
and 3 is coded as defined in [25]. 6
The service options supported are given in Table 4.2.53-1. 7
Table 4.2.53-1 Service Option Values 8
Service Option
Value (hex)

Description
8000H 13K speech
0011H 13K high rate voice service
0003H EVRC
801FH 13K Markov
0004H Asynchronous Data rate set 1
0005H Group 3 Fax rate set 1
0007H
a
Packet Data Service: Internet or ISO Protocol Stack (Revision 0)
0023H
Position Location Determination (PLD) Rate Set 1
0024H Position Location Determination (PLD) Rate Set 2
0009H 13K loopback
0038H Selectable Mode Vocoder (SMV)
000CH Asynchronous Data rate set 2
000DH Group 3 Fax rate set 2
0006H SMS rate set 1
000EH SMS rate set 2
000FH
a
Packet Data Service: Internet or ISO Protocol Stack (14.4 kbps
0012H OTAPA Rate Set 1
0013H OTAPA Rate Set 2
0020H IS-2000 Test Data
0036H IS-2000 Markov
0037H IS-2000 Loopback
9
TIA-2001.4-C
361 Section 4
Table 4.2.53-1 (Cont.) Service Option Values 1
0016H
a
High Speed Packet Data Service:
Internet or ISO Protocol Stack (RS1 forward, RS1 reverse)
0017H
a
0018H
a
0019H
a
0021H (3G High Speed Packet Data)
0025H (ISDN Interworking Service (64 kbps))
003CH
b
Link-Layer Assisted Header Removal
003DH
b
Link-Layer Assisted Robust Header Compression
1007H
a
Packet Data Service: Internet or ISO Protocol Stack, Revision 1 (9.6 or
14.4 kbps
a. These values are only used to indicate intergeneration handoff (refer to [13]). Any 2
other use of these values is outside the scope of this version of the standard. 3
b. This value can only be assigned to auxiliary services instances (e.g. when an SO33 4
has been allocated ) 5
6
7
TIA-2001.4-C
Section 4 362
4.2.54 ADDS User Part 1
This element contains the user information portion of an ADDS message. That is, it 2
carries the application data message. 3
4.2.54 ADDS User Part
7 6 5 4 3 2 1 0 Octet
Length 2
Reserved Data Burst Type 3
Application Data Message 4-n
Length: 4
This field is defined as the number of octets following the Length field 5
and has a value greater than zero. 6
Data Burst Type: 7
For CDMA: the 6-bit Data Burst Type defined in [25] is contained in 9
bits 5 through 0. 10
For dormant mode packet data handoffs the Data Burst Type field is set 11
to Asynchronous Data Services (00 0001). For CCPD Mode, the Data 12
Burst Type field is set to Short Data Burst (00 0110). 13
Application Data Message: 14
This field has variable length and is encoded as follows: 15
For CDMA SMS Services, the Application Data Message is the CDMA 16
SMS Transport Layer Message defined in [20]. 17
For CDMA PLD Services, the Application Data Message is defined in 18
[23]. 19
For AMPS Extended Protocol Enhanced Services, the Application Data 20
Message field consists of the IS-91 message fields. If necessary, 21
padding bits with a value of 0 are added at the end to make an integral 22
number of octets. For the specific instance of the CLI Order, the 23
Application Data Message is the 4-bit DIGIT fields. No padding bits 24
are used. For the specific instance of the Short Message, the 25
Application Data Message is the 6-bit CHAR fields. If necessary, 26
padding bits are added to make an integer number of octets. For the 27
specific instance of the Voice Mail Message, the Application Data 28
Message is the 6-bit CHAR fields. If necessary, padding bits are added 29
to make an integer number of octets. 30
For Alert with Information SMS Services, the Application Data 31
Message is the Teleservice Identifier followed by one or more 32
Teleservice Sub-parameters (refer to 4.3.1.4.2 of [20]). 33
For Short Data Burst, the Application Data Message is the SDB as 34
specified in [22]. If this element is used as part of the ADDS Transfer 35
message to support Short Data Burst, it does not include the Short Data 36
Burst application data in the Application Data Message field. 37
No data is present in the Application Data Message field for CCPD 38
mode, or dormant mode packet data handoffs. 39
TIA-2001.4-C
363 Section 4
4.2.55 IS-2000 Service Configuration Record 1
This information element contains the service configuration record as defined in [5] when 2
the call is TIA/EIA/IS-2000, and as defined in [10] when the call is TIA/EIA/IS-95. 3
4.2.55 I S-2000 Service Configuration Record
7 6 5 4 3 2 1 0 Octet
Bit-Exact Length Octet Count 2
Reserved Bit-Exact Length Fill Bits 3
(MSB) 4

Seventh
Fill Bit
if needed
Sixth Fill
Bit if
needed
Fifth Fill
Bit if
needed
Fourth
Fill Bit
if needed
Third
Fill Bit
if needed
Second
Fill Bit
if needed
First Fill
Bit if
needed
k
Element Identifier: 4
This information element is used on multiple interfaces. When the 5
information element is included in a message that is sent on the A1 6
interface, the Element Identifier field is coded as 0EH. When the 7
information element is included in a message sent on the A7 interface, 8
the Element Identifier field is coded as 10H. 9
Bit-Exact Length Octet Count: 10
Bit-Exact Length Octet Count field. 12
Reserved: 13
Bit-Exact Length Fill Bits: 15
This field contains a binary value indicating the number of fill bits 16
contained in the last octet of this element. If this field contains a non- 17
zero value, the indicated number of fill bits are set to 0 and occupy 18
the low order bit positions of the last octet of this element. 19
IS-2000 Service Configuration Record Content: 20
This field contains a Service Configuration Record coded according to 21
[5] when the call is cdma2000
. This field is coded according to [10] 22

when the call is TIA/EIA/IS-95. The value begins in the high order bit 23
position of octet 4 of this element and extends into the last octet of this 24
element. 25
Nth Fill Bit if needed: 26
Bit positions in the last octet that are not used, if any, are considered fill 27
bits, are set to 0, and occupy the low order bit positions of the last 28
octet. 29
30
TIA-2001.4-C
Section 4 364
4.2.56 IS-2000 Non-Negotiable Service Configuration Record 1
This information element contains the non-negotiable service configuration record as 2
defined in [5]. 3
4.2.56 I S-2000 Non-Negotiable Service Configuration Record
7 6 5 4 3 2 1 0 Octet
(MSB) 4

Seventh
Fill Bit
if needed
Sixth Fill
Bit if
needed
Fifth Fill
Bit if
needed
Fourth
Fill Bit
if needed
Third
Fill Bit
if needed
Second
Fill Bit
if needed
First Fill
Bit if
needed
k
Reserved: 7
IS-2000 Non-Negotiable Service Configuration Record Content: 14
This field contains a Non-Negotiable Service Configuration Record 15
coded according to [5]. The value begins in the high order bit position 16
of octet 4 of this element and extends into the last octet of this element. 17
Nth Fill Bit if needed: 18
octet. 21
22
TIA-2001.4-C
365 Section 4
4.2.57 IS-2000 Mobile Capabilities 1
This element contains information about the IS-2000-specific capabilities of the MS. 2
4.2.57 I S-2000 Mobile Capabilities
7 6 5 4 3 2 1 0 Octet
Length 2
Reserved ERAM
Supported
DCCH
Supported
FCH
Supported
OTD
Supported
Enhanced
RC CFG
Supported
QPCH
Supported
3
FCH Information: Bit-Exact Length Octet Count 4
Reserved Geo Location Type Geo
Location
Included
FCH Information:
5
(MSB) 6

Seventh
Fill Bit
if needed
Sixth Fill
Bit if
needed
Fifth Fill
Bit if
needed
Fourth
Fill Bit
if needed
Third
Fill Bit
if needed
Second
Fill Bit
if needed
First Fill
Bit if
needed
k
DCCH Information: Bit-Exact Length Octet Count k+1
Reserved DCCH Information:
k+2
(MSB) k+3

Seventh
Fill Bit
if needed
Sixth Fill
Bit if
needed
Fifth Fill
Bit if
needed
Fourth
Fill Bit
if needed
Third
Fill Bit
if needed
Second
Fill Bit
if needed
First Fill
Bit if
needed
m
Length: 3
Length field. 5
Reserved (octet 3) : 6
ERAM Supported: 8
This field is set to 1 if MS indicated that it supports Enhanced Rate 9
Adaptation Mode, otherwise it is set to 0. 10
DCCH Supported: 11
This field is set to 1 if MS indicated that it supports the IS-2000 12
DCCH, otherwise it is set to 0. 13
FCH Supported: 14
This field is set to 1 if the MS indicated that it supports the IS-2000 15
FCH, otherwise it is set to 0. 16
TIA-2001.4-C
Section 4 366
OTD Supported: 1
This field has a value of 1 if the MS supports Orthogonal Transmit 2
Diversity and a value of 0 otherwise. 3
Enhanced RC CFG Supported: 4
This field indicates whether the MS supports any radio configuration in 5
radio class 2. A value of 1 indicates support, and a value of 0 6
indicates no support. 7
QPCH Supported: 8
This field indicates whether the MS supports the IS-2000 Quick Paging 9
Channel (QPCH). A value of 1 indicates support, and a value of 0 10
indicates no support. 11
FCH Information: Bit-Exact Length Octet Count: 12
This field contains the total number of octets in the FCH Information 13
Content field represented as a binary value. 14
Reserved (octet 5) : 15
Geo_Location_Type: 17
If Geo_Location_Included is set to 1 this field is included and set as 18
follows: 19
000 No MS assisted geo-location capabilities 20
001 [23] capable (Advanced Forward Link Triangulation only 21
(AFLT)) 22
010 [23] capable (Advanced Forward Link Triangulation and 23
Global Positioning Systems 24
011 Global Positioning Systems Only 25
All Other values reserved. 26
If Geo_Location_Included is set to 0 this field is included and set to 27
000. 28
Geo_Location_Included: 29
This field is set to 1 if geo-location capabilities about the mobile are 30
included. Geo Location is not supported by mobiles with 31
MOB_P_REV less than '7'. This field is set to 0 if no geo-location 32
capabilities are included and the MSC shall ignore the contents of the 33
Geo_Location_Type field. 34
FCH Information: Bit-Exact Length Fill Bits: 35
contained in the last octet used for the FCH Information Content field. 37
FCH Information Content: 38
The FCH Capabilities Information field is coded per [5] section 39
2.7.4.27.1. 40
Nth Fill Bit if needed (octet k): 41
If the FCH Information: Bit-Exact Length Fill Bits field contains a 42
non-zero value, the indicated number of fill bits are set to 0 and 43
occupy the low order bit positions of the last octet used for the FCH 44
Information Content field. 45
TIA-2001.4-C
367 Section 4
Reserved (octet k+2) : 1
DCCH Information: Bit-Exact Length Octet Count: 3
This field contains the total number of octets in the DCCH Information 4
Content field represented as a binary value. 5
DCCH Information: Bit-Exact Length Fill Bits 6
contained in the last octet of the DCCH Information Content field. 8
DCCH Information Content: 9
The DCCH Capabilities Information field is coded per [5] section 10
2.7.4.27.2. 11
Nth Fill Bit if needed (octet m): 12
If the DCCH Information: Bit-Exact Length Fill Bits field contains 13
a non-zero value, the indicated number of fill bits are set to 0 and 14
occupy the low order bit positions of the last octet used for the DCCH 15
Information Content field. 16
17
18
TIA-2001.4-C
Section 4 368
4.2.58 Protocol Type 1
This information element contains the Link Layer / Network Layer Protocol Type used 2
by the PDSN. 3
4.2.58 Protocol Type
7 6 5 4 3 2 1 0 Octet
Length 2
(MSB) Protocol Type 3
(LSB) 4
Length: 4
Length field. 6
Protocol Type: 7
This field indicates the protocol type in use at a PDSN for an existing 8
packet connection. This field provides the ability for a target BS/PCF to 9
properly accept a hard handoff of a packet data call. The value is as 10
defined in the [17]. 11
12
TIA-2001.4-C
369 Section 4
4.2.59 MS Information Records 1
This information element contains a list of cdma2000
Information Records. Examples 2

of such information records are signal, display, calling party ASCII number, message 3
waiting indicator, etc. This information element was referred to as IS-95 Information 4
Records in some previous versions of this standard. 5
The BS shall transparently transmit the contents from octet 3 to the end of this element 6
without verifying or modifying them. 7
4.2.59 MS Information Records
7 6 5 4 3 2 1 0 Octet
Length 2
Information Record Type - 1 3
Information Record Length - 1 4
(MSB) Information Record Content - 1 5

(LSB) j
Information Record Type - 2 j+1
Information Record Length - 2 j+2
(MSB) Information Record Content 2 j+3

(LSB) k

Information Record Type - n m
Information Record Length - n m+1
(MSB) Information Record Content - n m+2

(LSB) n
Length: 8
This field contains the number of bytes in this element following this 9
field as a binary number. 10
Information Record Type: 11
For coding of this field refer to [1]~[6]. 12
Information Record Length: 13
This field indicates the number of octets in the immediately following 14
Information Record Content field in this element. 15
Information Record Content: 16
For coding of this field refer to [1] to [6]. 17
18
19
TIA-2001.4-C
Section 4 370
4.2.60 Extended Handoff Direction Parameters 1
This element is used by a target BS to provide information to the source BS for two 2
purposes. The first purpose is to create the Extended Handoff Direction Message, General 3
Handoff Direction Message or Universal Direction Message to be sent to the MS. The 4
second purpose is to create the cdma2000
In-Traffic System Parameters message. 5

4.2.60 Extended Handoff Direction Parameters
7 6 5 4 3 2 1 0 Octet
Length 2
Search Window A Size (Srch_Win_A) Search Window N Size (Srch_Win_N) 3
Search Window R Size (Srch_Win_R) Add Pilot Threshold (T_Add) high order bits 4
T_Add low order bits Drop Pilot Threshold (T_Drop) 5
Compare Threshold (T_Comp) Drop Timer Value (T_TDrop) 6
Neighbor Max Age (Nghbor_Max_AGE) Reserved Target BS Values
Included
7
Reserved SOFT_SLOPE 8
Reserved ADD_INTERCEPT 9
Reserved DROP_INTERCEPT 10
Target BS P_REV 11
Unless listed below, refer to [1]~[6] for coding of the parameters listed in this element. 6
Length: 7
This field contains the number of bytes in this element following this 8
field as a binary number. 9
Target BS Values Included: 10
Target BS always codes this field to 10. The source BS will uses this 11
field to determine which fields within this element were successfully 12
conveyed from the target BS via the ANSI-41 network [9, 27, 28]. At 13
the source BS, this field is interpreted as follows: 14
00 indicates that only Search Window A Size field is valid 15
01 indicates that Search Window A Size field, Add Pilot 16
Threshold field, Drop Pilot Threshold field, Compare 17
Threshold field, and Drop Timer Value field are valid and 18
10 indicates that all fields in this IE are valid. 19
A value of 11 is reserved. The source BS shall ignore the 20
fields that are not valid as determined by this field. 21
22
TIA-2001.4-C
371 Section 4
4.2.61 CDMA Serving One Way Delay 1
This element specifies the estimated one-way delay from the MS to the cell associated 2
with the REF_PN (refer to [1]~[6]). It is coded as follows: 3
4.2.61 CDMA Serving One Way Delay
7 6 5 4 3 2 1 0 Octet
Length 2
Cell Identifier 3-var
(MSB) CDMA Serving One Way Delay m
CDMA Serving One Way Delay (LSB) m+1
Reserved Resolution m+2
(MSB) CDMA Serving One Way Delay Time Stamp m+3
(LSB) m+4
Length: 4
This field contains the number of octets in this element following the 5
Length field. 6
Cell Identifier: 7
This field identifies the reference cell. This field is comprised of a Cell 8
Identification Discriminator and a Cell Identification and shall be 9
formatted according to octets 3 through the end of the Cell Identifier 10
element defined in section 4.2.17. The allowable cell discriminator 11
values are 0000 0010, and 0000 0111. 12
CDMA Serving One Way Delay: 13
This field is the one-way delay from the MS to the cell associated with 14
the REF_PN (refer to [1]~[6]) as estimated by the BS. 15
Reserved: 16
Resolution:This field indicates the units of the calculated the CDMA 18
Serving One Way Delay. The allowable values are: 19
00 100 ns 20
01 50 ns 21
10 1/16 PN Chip 22
11 - reserved 23
CDMA Serving One Way Delay Time Stamp: 24
This field is a 16-bit binary number derived from the base stations 64- 25
bit System Time at the time that the One Way Delay was measured. 26
The time stamp is in units of 80 ms. 27
28
TIA-2001.4-C
Section 4 372
4.2.62 Radio Environment and Resources 1
This element indicates the environment and availability of resources for a new call 2
establishment. Four inter-related factors are included: availability of radio resources, pre- 3
allocation of radio resources by the BS, and an evaluation of the forward and reverse 4
radio environments by the BS (interference, power level, etc.) 5
The BS evaluation of the radio environment is manufacturer-specific, but can be 6
generalized to: acceptable / marginally acceptable / poor. 7
4.2.62 Radio Environment and Resources
7 6 5 4 3 2 1 0 Octet
Reserved Include
Priority
Forward Reverse Alloc Avail 2
Reserved: 8
Include Priority: 10
This field indicates whether the actual priority of the call is required. 11
This bit is set to 1 to request the MSC to include the actual priority in 12
the Assignment Request message. Otherwise, it is set to 0. Note - The 13
BS should include this field to indicate to the MSC that no lower 14
priority channels are available when PACA service is requested and a 15
channel reservation method is used to support the call. 16
Forward: 17
Reverse: 19
Alloc: 21
The Alloc field indicates that radio resources have been allocated for 22
the call. This field is coded as shown in table 4.2.62-1. 23
Avail: 24
The Avail field indicates that resources are available and can be 25
allocated for this call. This field is coded as shown in table 4.2.62-1. 26
The setting {Alloc = 0, Avail = 1} is used when the BS does not do early traffic 27
channel assignment and it either has resources or does not know whether it has resources. 28
29
TIA-2001.4-C
373 Section 4
Table 4.2.62-1 Radio Environment and Resources 1
Field Values Description
Forward
00 Not reported.
01 Forward radio environment is acceptable.
10 Forward radio environment is marginally acceptable.
11 Forward radio environment is poor.
Reverse
00 Not reported.
01 Reverse radio environment is acceptable.
10 Reverse radio environment is marginally acceptable.
11 Reverse radio environment is poor.
Alloc
0 Resources are not allocated.
1
a
Resources are allocated.
Avail
0
a
Resources are not available.
1 Resources are available.
a. It is an illegal (and illogical) combination to have the Alloc field set to 1 and the 2
Avail field set to 0. 3
4
TIA-2001.4-C
Section 4 374
4.2.63 Called Party ASCII Number 1
This element contains the called party number in ASCII format. It is coded as shown 2
below. 3
4.2.63 Called Party ASCII Number
7 6 5 4 3 2 1 0 Octet
Length 2
ext = 1 Type of Number Numbering Plan Identification 3
ASCII character 1 4
ASCII character 2 5

ASCII character n n
Length: 4
Length field. 6
For the coding of the Type of Number and Numbering Plan Identification fields refer to 7
[29]. 8
9
TIA-2001.4-C
375 Section 4
4.2.64 IS-2000 Cause Value 1
This information element contains the cause indication sent by a cdma2000
MS. 2
4.2.64 I S-2000 Cause Value
7 6 5 4 3 2 1 0 Octet
Length 2
IS-2000 Cause Information variable
Length: 3
Length field. 5
IS-2000 Cause Information: 6
The content, values and format of this field are as specified for the 7
ORDQ field of the Reject Order in cdma2000
systems. Refer to [5]. 8

This information element is referred to as IS-95 cause value in previous versions of this 9
standard. 10
11
TIA-2001.4-C
Section 4 376
4.2.65 Authentication Event 1
This information element is sent by the BS to the MSC when an unexpected 2
authentication event occurs. 3
4.2.65 Authentication Event
7 6 5 4 3 2 1 0 Octet
Length 2
Event 3
Length: 4
This field indicates the number of octets in this element following this 5
Length field. 6
Event: 7
The coding of this field is as follows: 8
01H The BS is operating in authentication required mode, but 9
authentication parameters (AUTHR, RANDC and COUNT) 10
were NOT received from the MS. 11
02H The BS is operating in authentication required mode, but the 12
MS provided RANDC did not match the BS provided 13
RAND(s). 14
03H The BS is operating in authentication required mode, but the 15
authentication was recently requested and a new 16
authentication is not required. Refer to section 2.6.3.1. 17
All other values reserved. 18
19
TIA-2001.4-C
377 Section 4
4.2.66 Authentication Data 1
This element contains the authentication data used as input to the authentication 2
algorithm. 3
4.2.66 Authentication Data
7 6 5 4 3 2 1 0 Octet
Length 2
(MSB) Auth-Data 3
4
(LSB) 5
Length: 4
Length field. 6
Auth-Data: 7
The value of this field is derived from the last six digits or characters 8
sent by the MS as described in [5]. 9
10
TIA-2001.4-C
Section 4 378
4.2.67 PSMM Count 1
This element indicates the number of Pilot Strength Measurement Messages to be sent, 2
or, if this element is 0, it indicates that the geographic location of the MS is to be 3
determined by the BS, if the BS is capable of determining the geographic location. 4
4.2.67 PSMM Count
7 6 5 4 3 2 1 0 Octet
Length 2
Reserved PSMM Count 3
Length: 5
Length field. 7
PSMM Count: 8
This 4-bit field contains the Pilot Strength Measurement Message 9
Count. The PSMM Count indicates the number of PSMM Messages 10
and is a value between 0000 and 1010. If the PSMM Count is 0 then 11
the BS shall calculate the MSs location if it is capable of determining 12
the geographic location. If the PSMM Count is 0, and if the BS is not 13
capable of determining the geographic location , then the BS shall 14
return the CDMA One Way Delay information element in the response. 15
16
TIA-2001.4-C
379 Section 4
4.2.68 Geographic Location 1
This Information Element contains the geographic location of an MS. 2
4.2.68 Geographic Location
7 6 5 4 3 2 1 0 Octet
Length 2
(MSB) Calling Geodetic Location (CGL) 3

(LSB) k
Length: 3
Length field. 5
CGL: 6
Refer to [30] for population of the Calling Geodetic Location (CGL). 7
8
TIA-2001.4-C
Section 4 380
4.2.69 Downlink Radio Environment List 1
This element contains a list of Downlink Radio Environments. 2
4.2.69 Downlink Radio Environment List
7 6 5 4 3 2 1 0 Octet
Length 2
Downlink Radio Environment List entry 1 3

Downlink Radio Environment List entry n k
Length: 3
Length field. 5
Downlink Radio Environment List entry: 6
This field is coded as specified in section 4.2.22 from octet 2 to the end. 7
8
TIA-2001.4-C
381 Section 4
4.2.70 Circuit Group 1
This element contains a list of circuit identities represented by a beginning circuit identity 2
code value, a count, and an optional bitmap. Refer to the details below. 3
4.2.70 Circuit Group
7 6 5 4 3 2 1 0 Octet
Length 2
Reserved All
Circuits
Inclusive 3
Count 4
(MSB) First CIC (most significant bits) 5
First CIC (least significant bits) (LSB) 6
(first
unused
bit - if
any)
(second
unused
bit - if
any)
(third
unused
bit - if
any)
(fourth
unused
bit - if
any)
(fifth
unused
bit - if
any)
(sixth
unused
bit - if
any)
(seventh
unused
bit - if
any)

7
Circuit Bitmap 8

(corresp.
to value
in First
CIC
field)

k
Length: 4
Length field. 6
Reserved: 7
All Circuits: 9
This field is used to indicate that all circuits between the MSC and BS 10
are to be affected by the operation specified by the message when this 11
field is set to 1. In this case, only the first three octets of this element 12
are used. If this field is set to 0, the remaining fields of this element 13
specify the affected circuits. 14
Inclusive: 15
This field is used to indicate whether all circuits with identifiers in the 16
range [First CIC, First CIC + Count - 1] are represented by this 17
element. If this field is set to 1, then all circuits with identifiers in the 18
range are included and there is no Circuit Bitmap field included in this 19
element. If this field is set to 0, then not all circuits with identifiers in 20
the range are included. In this case, the Circuit Bitmap field identifies 21
the circuits that are included. 22
NOTE: When this element is used in a message that has a preceding 23
mandatory Circuit Identity Code element, the first value in the range of 24
TIA-2001.4-C
Section 4 382
circuits identified by this element in the message shall be the value 1
contained within the Circuit Identity Code element. 2
Count: 3
This is a binary encoded field that represents a count of the number of 4
circuits represented by this element including the given Circuit Identity 5
Code value in octets 5 and 6. 6
First CIC: 7
This field contains a Circuit Identity Code value formatted as shown in 8
octets 2 and 3 of 4.2.19. 9
Circuit Bitmap: 10
This variable sized field contains an integral number of octets 11
sufficiently large to contain (Count) bits. That is, the number of octets 12
in this field is equal to: 13

( )
# $
8 / Count
14
Any unused bits occur in octet 7, beginning in bit position 7, and are set 15
to 0. Bit 0 in the highest numbered octet in the Circuit Bitmap field 16
corresponds to the circuit represented by the value in the First CIC 17
field. Bit 1 in that octet corresponds to the circuit represented by the 18
(value in the First CIC field) + 1, etc. 19
A bit in the Circuit Bitmap field that has a value of 1 indicates that the 20
corresponding circuit is included in the set of circuits referenced by this 21
element. A value of 0 indicates that the corresponding circuit is not 22
included in the set of circuits referenced by this element. 23
24
TIA-2001.4-C
383 Section 4
4.2.71 PACA Timestamp 1
PACA Timestamp indicates the time when the PACA call was originally queued. 2
4.2.71 PACA Timestamp
7 6 5 4 3 2 1 0 Octet
Length 2
(MSB) PACA Queuing Time 3
4
5
(LSB) 6
Length: 3
Length field. 5
PACA Queuing Time: 6
A binary value representing the time of the service request. The lower 7
the binary value the earlier the time. 8
9
TIA-2001.4-C
Section 4 384
4.2.72 PACA Order 1
The purpose of this element is to allow the sender to instruct the receiver to take 2
appropriate action upon receiving the PACA Update message. 3
4.2.72 PACA Order
7 6 5 4 3 2 1 0 Octet
Length 2
Reserved PACA Action Required 3
Length: 4
Length field. 6
Reserved: 7
This field shall be set to 00000. 8
PACA Action Required: 9
Table 4.2.72-1 PACA Order - PACA Action Required 11
PACA Action
Required
Value (binary)

Description
000 Reserved
001 Update Queue Position and notify MS
010 Remove MS from the queue and release MS
011 Remove MS from the queue
100 MS Requested PACA Cancel
101 BS Requested PACA Cancel
12
13
TIA-2001.4-C
385 Section 4
4.2.73 PACA Reorigination Indicator 1
This element indicates whether the access attempt is a user directed origination or a 2
PACA re-origination. This element is present only when the MS sends a priority service 3
request. 4
4.2.73 PACA Reorigination Indicator
7 6 5 4 3 2 1 0 Octet
Length 2
Reserved PRI 3
Length: 5
Length field. 7
Reserved : 8
PRI: 10
(PACA Reorigination Indicator) This field is set to 1 to indicate that 11
this is a PACA reorigination; otherwise it is set to 0. 12
13
14
TIA-2001.4-C
Section 4 386
4.2.74 Access Network Identifiers 1
The Access Network Identifiers (ANID), consisting of PZID, SID and NID, uniquely 2
identify the PCF. The Previous and Current ANIDs (PANID and CANID) are used by the 3
PDSN to determine if it currently owns the call. If so, the PDSN does not need to send 4
agent advertisements. If not, then the PDSN may need to trigger a MIP Registration 5
Request so the Foreign Agent / Home Agent tunnel is set up properly. 6
4.2.74 Access Network Identifiers
7 6 5 4 3 2 1 0 Octet
Length 2
Reserved (MSB) SID 3
(LSB) 4
(MSB) NID 5
(LSB) 6
PZID 7
Length: 7
Length field. 9
SID: 10
This two octet field is coded to the value that uniquely identifies the 11
cellular or PCS system. 12
NID: 13
network within a cellular or PCS system. 15
PZID: 16
This one octet field is coded to the value that uniquely identifies the 17
Packet Control Function (PCF) coverage area within a particular 18
SID/NID area. The combined SID/NID/PZID triplet is unique to a PCF. 19
20
TIA-2001.4-C
387 Section 4
4.2.75 Source RNC to Target RNC Transparent Container 1
This information element is used to contain DS radio parameters to be passed from the 2
source BS to the target BS in the Handoff Required and Handoff Request messages. The 3
information in this element is transparent to the MSC. 4
4.2.75 Source RNC to Target RNC Transparent Container
7 6 5 4 3 2 1 0 Octet
Length 2
(MSB) Container 3

(LSB) k
Length: 5
Length field. 7
Container: 8
This field contains the Source RNC to Target RNC Transparent 9
Container element as defined in [36]. 10
11
TIA-2001.4-C
Section 4 388
4.2.76 Target RNC to Source RNC Transparent Container 1
This information element is used to contain DS radio parameters to be passed from the 2
target BS to the source BS in the Handoff Request Acknowledge and Handoff Command 3
messages. The information in this element is transparent to the MSC. 4
4.2.76 Target RNC to Source RNC Transparent Container
7 6 5 4 3 2 1 0 Octet
Length 2
(MSB) Container 3

(LSB) k
Length: 5
Length field. 7
Container: 8
This field contains the Target RNC to Source RNC Transparent 9
Container element as defined in [36]. 10
11
TIA-2001.4-C
389 Section 4
4.2.77 Service Option Connection Identifier (SOCI) 1
The purpose of the Service Option Connection Identifier is to distinguish multiple 2
parallel service option connections within one MS between BS and MSC. It is coded as 3
follows: 4
4.2.77 Service Option Connection Identifier (SOCI)
7 6 5 4 3 2 1 0 Octet
Length 2
Reserved Service Option Connection
Identifier
3
Length: 5
Length field. 7
Reserved: 8
Service Option Connection Identifier : 10
SOCI values are always assigned by the BS. At the beginning of a 11
circuit-based service option connection between the BS and the MSC, 12
an unused SOCI value is chosen and assigned to this service option 13
connection. It then remains fixed for the lifetime of the service option 14
connection. After a service option connection ends, the associated 15
SOCI value is freed and may be re-used. 16
For packet data sessions, an unused SOCI value for the MS is chosen 17
and assigned to the packet data session when it transitions to the Active 18
State. It then remains fixed for as long as the packet data session is 19
active. After a packet data session transitions out of Active State, the 20
associated SOCI value for the MS is freed and may be re-used. 21
This field has a range of 001 to 110 and all other values are 22
reserved. 23
24
TIA-2001.4-C
Section 4 390
4.2.78 Service Option List 1
This element indicates a list of the service option instances requested by the MS, or by 2
the network. It is coded as follows: 3
4.2.78 Service Option List
7 6 5 4 3 2 1 0 Octet
Length 2
Number of Service Option instances 3
Reserved SR_ID -1 SOCI- 1 4
(MSB) Service Option 1 5
(LSB) 6

Reserved SR_ID -n SOCI - n k
(MSB) Service Option - n k+1
(LSB) k+2
Length: 4
Length field. 6
Number of Service Option Instances: 7
This field contains the number of service options included in this 8
element. 9
Reserved: 10
SR_ID: 12
This 3-bit field is used to uniquely identify a packet data service 13
instance in the MS. This field contains the MN Service Reference 14
Identifier value as defined in ([1]~[6]). 15
Service Option Connection Identifier (SOCI): 16
If concurrent services are supported this 3-bit field is used to 17
distinguish multiple parallel service option connections within one MS 18
between BS and MSC. It shall be formatted according to Service 19
Option Connection Identifier element defined in section 4.2.77. When 20
this information element contains multiple packet data service 21
instances, this field shall have the same value for all packet data service 22
instances. If concurrent services are not supported this shall be set to 23
any valid value. 24
Service Option: 25
This field contains the Service Option value associated with the service 26
option instance identified in the corresponding Service Option 27
Connection Identifier and SR_ID fields. It shall be formatted according 28
to octets 2 through the end of the Service Option element defined in 29
section 4.2.53. 30
31
TIA-2001.4-C
391 Section 4
4.2.79 AMPS Hard Handoff Parameters 1
This element is used to deliver information needed by the source BS to perform hard 2
handoff to an AMPS system. 3
4.2.79 AMPS Hard Handoff Parameters
7 6 5 4 3 2 1 0 Octet
Length 2
Reserved Encryption Mode 3
Length: 4
Length field. 6
Reserved: 7
Encryption Mode: 9
The Encryption Mode indicates whether encryption is to be used for the 10
messages on the forward and reverse traffic channels. The encoding of 11
this field is as follows: 12
00 Encryption disabled 13
01 Encryption enabled. 14
15
TIA-2001.4-C
Section 4 392
4.2.80 Band Class 1
This information element specifies the frequency band. 2
4.2.80 Band Class
7 6 5 4 3 2 1 0 Octet
Length 2
Length: 3
Length field. 5
Reserved: 6
Band Class:The coding of this field is specified in Table 4.2.80-1. This 8
table contains band class values defined in [25]. If there are any 9
discrepancies between this table and [25], the latter shall be considered 10
correct. 11
Table 4.2.80-1 Band Class 12
0 0000 800 MHz Cellular System
0 0001 1.850 to 1.990 GHz Broadband PCS
0 0010 872 to 960 MHz TACS band
0 0011 832 to 925 MHz JTACS band
0 0100 1.750 to 1.870 GHz Korean PCS band
0 0101 NMT-450 band
0 0110 IMT-2000 band
0 0111 North American 700 MHz Cellular Band
0 1000 1.710 to 1.880 GHz PCS
0 1001 880 to 960 MHz Band
0 1010 Secondary 800 MHz Band
13
14
TIA-2001.4-C
393 Section 4
4.2.81 Information Record Requested 1
This information element contains the Status Information Record Type(s) that the MSC 2
includes in the Status Request message to the BS. Examples of such Information Record 3
Types are: Call mode, terminal information, roaming information, security status, mobile 4
identity, etc. 5
4.2.81 Information Record Requested
7 6 5 4 3 2 1 0 Octet
Length 2
Information Record Type 1 3

Information Record Type n variable
Length: 6
Length field. 8
Information Record Type: 9
For coding of the Information Record Type refer to [5]. 10
11
TIA-2001.4-C
Section 4 394
4.2.82 Anchor PDSN Address 1
This element is used to deliver the IPv4 address of the A11 interface of the anchor PDSN 2
for fast handoff. 3
4.2.82 Anchor PDSN Address
7 6 5 4 3 2 1 0 Octet
Length 2
(MSB) Anchor PDSN Address 3
4
5
(LSB) 6
Length: 4
Length field. 6
Anchor PDSN Address: 7
This field contains an IPv4 address for an anchor PDSN. 8
9
10
TIA-2001.4-C
395 Section 4
4.2.83 Protocol Revision 1
This Protocol Revision element contains the protocol revision supported by the MS 2
(MOB_P_REV). The BS uses this information to determine the P_REV_IN_USE so that 3
the PD (Protocol Discriminator) field in the associated air interface message can be set 4
correctly. The coding of the PD field is specified in [4]. 5
4.2.83 Protocol Revision
7 6 5 4 3 2 1 0 Octet
Length 2
MOB_P_REV 3
Length: 6
Length field. 8
MOB_P_REV: 9
This field contains the MSs protocol revision (MOB_P_REV) as 10
defined in [1]~[6]. 11
12
TIA-2001.4-C
Section 4 396
4.2.84 Anchor P-P Address 1
This element is used to deliver the IPv4 address of the P-P interface of the anchor PDSN 2
for fast handoff. 3
4.2.84 Anchor P-P Address
7 6 5 4 3 2 1 0 Octet
Length 2
(MSB) Anchor P-P Address 3
4
5
(LSB) 6
Length: 4
Length field. 6
Anchor P-P Address: 7
This field contains an IPv4 address of the P-P interface for an anchor 8
PDSN. 9
10
TIA-2001.4-C
397 Section 4
4.2.85 Origination Continuation Indicator 1
This type 2 information element is used to inform the MSC that the CM Service Request 2
message is to be followed by a CM Service Request Continuation message. Refer to 3
section 4.1.3 for additional information on type 2 IEs. 4
4.2.85 Origination Continuation Indicator
7 6 5 4 3 2 1 0 Octet
5
6
TIA-2001.4-C
Section 4 398
4.2.86 IS-2000 Redirection Record 1
This information element contains information to allow an MS to be redirected to a 2
CDMA network. 3
4.2.86 IS-2000 Redirection Record
7 6 5 4 3 2 1 0 Octet
Length 2
Redirection Record Type 3
Redirection Record Length 4
(MSB) Redirection Record Content (first octet) 5

Redirection Record Content (last octet) (LSB) j
Length: 4
Length field. 6
Redirection Record Type: 7
For the coding of this field, refer to [1] to [6]. 8
Redirection Record Length: 9
For the coding of this field, refer to [1] to [6]. 10
Redirection Record Content: 11
For the coding of this field, refer to [1]~[6]. 12
13
14
TIA-2001.4-C
399 Section 4
4.2.87 Return Cause 1
This information element is included upon MS registration or origination following a 2
service redirection failure, and it indicates the reason for the failure. 3
4.2.87 Return Cause
7 6 5 4 3 2 1 0 Octet
Reserved Return_Cause 2
Return_Cause: 4
Reason of the MS registration or origination. The BS shall set this field 5
to the Return cause value shown in Table 4.2.87-1 corresponding to the 6
service redirection failure condition. 7
Table 4.2.87-1 Return Cause 8
0000 Normal access.
0001 Service redirection failed as a result
of system not found.
of protocol mismatch.
of registration rejection.
of wrong SID.
of wrong NID.
9
10
TIA-2001.4-C
Section 4 400
4.2.88 Service Redirection Info 1
This information element contains information to redirect an MS in the event it cannot 2
obtain service on the system to which it was directed. 3
4.2.88 Service Redirection Info
7 6 5 4 3 2 1 0 Octet
A1 Element Identifier
1
Length
2
Reserved Excl_P_
REV_Ind
Redirect
_P_REV
_Incl
Redirect
Type
Reserved Return If
Fail
3
(MSB)
REDIRECT_P_MIN
(LSB) 4
(MSB)
REDIRECT_P_MAX
(LSB) 5
Length: 4
Length field. 6
Reserved: 7
These fields are coded as all zeroes. 8
Excl_P_REV_Ind: 9
Excluding mobile protocol revision indicator. 10
0 = all mobile stations with a protocol revision in the range 11
[REDIRECT_P_MIN, REDIRECT_P_MAX] are included in Global 12
Service Redirection. 13
1 = all mobile stations with a protocol revision in the range 14
[REDIRECT_P_MIN, REDIRECT_P_MAX] are excluded from 15
Global Service Redirection. 16
Redirect_P_REV_Incl: 17
Redirection mobile protocol revision included 18
0 = this redirection applies to all mobile stations, 19
1 = this redirection applies to all mobile stations of some specific 20
protocol revisions 21
If this field set to 0, then the following fields Excl_P_REV_Ind, 22
REDIRECT_P_MIN, and REDIRECT_P_MAX are ignored. 23
Redirect Type: 24
Redirection type indicator: 25
0 = Normal redirection. 26
1 = NDSS redirection. 27
Return If Fail: 28
Return if fail indicator: 29
0 = The MS is not required to return to this system upon failure to 30
obtain service from the redirected system. 31
1 = The MS should return to this system upon failure to obtain service 32
from the redirected system. 33
REDIRECT_P_MIN: 34
Minimum redirection protocol revision. 35
TIA-2001.4-C
401 Section 4
This field indicates the minimum protocol revision of which MSs are 1
subjected to as specified by the action contained in 2
EXCL_P_REV_IND (i.e., to be redirected or excluded from 3
redirection). The value is equal to or greater than six. 4
REDIRECT_P_MAX: 5
Maximum redirection protocol revision. 6
This field indicates the maximum protocol revision of which MSs are 7
subjected to as specified by the action contained in 8
EXCL_P_REV_IND (i.e., to be redirected or excluded from 9
redirection). The value is equal to or greater than REDIRECT_P_MIN. 10
11
TIA-2001.4-C
Section 4 402
4.2.89 Packet Session Parameters 1
This variable length element contains an MSs packet data session parameters. 2
4.2.89 Packet Session Parameters
7 6 5 4 3 2 1 0 Octet
Length 2
Reserved SR_ID k
Data Length k+1
Parameter Identifier 1 k+2
Parameter 1 Length k+3
Parameter Value 1 k+4

Parameter Identifier n m
Parameter n Length m+1
Parameter Value n m+2

Reserved SR_ID n
Data Length n+1
Parameter Identifier 1 n+2
Parameter 1 Length n+3
Parameter Value 1 n+4

Parameter Identifier n p
Parameter n Length p+1
Parameter Value n p+2
Length: 3
Length field. 5
Reserved: 6
SR_ID: 8
This field indicates the type of data included. If parameters specific to a 9
PDSI are included, this field is set to the SR_ID of the PDSI (001-110). 10
If parameters specific to the packet data session are included, this field 11
is set to 111. 12
TIA-2001.4-C
403 Section 4
Data Length: 1
This field indicates the number of octets of data for the specified 2
SR_ID that follow, where the data consists of the Parameter Identifier 1 3
octet through the last octet of Parameter Value n. 4
5
Parameter Identifier: 6
This field uniquely identifies the parameter in the Parameter field 7
associated with the packet data service instance or packet data session 8
indicated by the preceding SR_ID and is coded as follows: 9
01H: RN-PDIT [17] 10
02H-FFH: Reserved 11
Parameter Length 12
This field specifies the length of the Parameter Value field in octets. 13
Parameter Value: 14
This field contains the value of the parameter associated with the 15
packet data session or packet data service instance identified by the 16
Parameter Identifier field. This field is coded as specified in [17]. 17
18
TIA-2001.4-C
Section 4 404
4.2.90 Service Reference Identifier (SR_ID) 1
This information element contains the SR_ID for a service instance. The purpose of the 2
SR_ID is to distinguish between multiple service instances within one MS. 3
4.2.90 Service Reference Identifier (SR_ID)
7 6 5 4 3 2 1 0 Octet
Length 2
Reserved SR_ID 3
Length: 4
Length field. 6
Reserved: 7
SR_ID: 9
This field contains the SR_ID of a service instance. Refer to [3]. Up to 10
six service instances are supported. 11
TIA-2001.4-C
405 Section 5
5.0 Timer Definitions 1
2
5.1 Timer Values 3
The following table is in units of seconds unless otherwise noted. 4
Table 5.1-1 Timer Values and Ranges Sorted by Name 5
Timer
Name
Default
Value
(seconds)
Range of
Values
(seconds)

Granularity
(seconds)
Section
Reference

Classification
T
1

55 0 255 1 5.2.5.1 Facilities Management
T
2

T
4

T
7

10 0 255 1 5.2.4.1 Handoff
T
8

Refer to section 5.2.4.2. 5.2.4.2 Handoff
T
9

10 0 255 1 5.2.4.3 Handoff
T
10

5 0 99 1 5.2.1.1 Call Processing
T
11

5 0 99 1 5.2.4.4 Handoff
T
12

T
13

T
16

T
20

5 0 99 1 5.2.1.2 Call Processing
T
60

5 0 99 1 5.2.2.4 Supplementary Services
T
62

5 0 - 99 1 5.2.2.2 Supplementary Services
T
63

5 0-170 1 5.2.2.3 Supplementary Services
T
300

1.5 0 - 99 0.1 5.2.1.3 Call Processing
T
301

30 0 - 60 1 5.2.1.4 Call Processing
T
303

T
306

T
308

T
309

5 0 - 90 1 5.2.5.7 Facilities Management
T
311

1 0 - 5 0.1 5.2.1.8 Call Processing
T
312

T
314

T
315

6
TIA-2001.4-C
Section 5 406
Table 5.1-1 (Cont.) Timer Values and Ranges Sorted by Name 1
Timer
Name
Default
Value
(seconds)
Range of
Values
(seconds)

Granularity
(seconds)
Section
Reference

Classification
T
3113

5 0-170 1 5.2.1.14 Call Processing
T
3210

30 0 - 99 1 5.2.3.1 Mobility Management
T
3220

T
3230

T
3231

5 0-99 1 5.2.1.13 Call Processing
T
3260

T
3270

T
3271

T
3272

T
3280

15 0 - 99 1 5.2.1.16 Call Processing
T
ordreg

T
paca1

T
paca2

T
softpos

10 0 - 99 1 5.2.2.1 Supplementary Services
T
waitho

Refer to section 5.2.4.5 5.2.4.5 Handoff
3
5.2.1 Call Processing Timers 4
5.2.1.1 T
10
5
This MSC timer is started when the Assignment Request message is sent, and stopped 6
when the Assignment Complete message or Assignment Failure message is received. 7
5.2.1.2 T
20
8
This BS timer is started when the Assignment Failure message is sent, and stopped when 9
the Assignment Request message (retry) or Service Release message is received or when 10
the MSC initiates call clearing. 11
5.2.1.3 T
300
12
This BS timer is started when a Clear Request message is sent. It is stopped when a Clear 13
Command message is received. 14
TIA-2001.4-C
407 Section 5
5.2.1.4 T
301
1
This MSC timer is started when the Assignment Complete message is received, and 2
stopped when the Connect or a Flash with Information message is received (ring time- 3
out, max. 60 seconds). This timer is only set for mobile terminated voice calls. 4
5.2.1.5 T
303
5
BS timer T
303
for MS origination is started when the CM Service Request message is 6
sent. For MS termination, the timer is started when the Paging Response message is sent. 7
In both cases, the timer is stopped when the Assignment Request message, Clear 8
Command message, PACA Command message or Service Redirection message is 9
received, or the SCCP connection is refused or released by the MSC. 10
This timer is also started when the Additional Service Request message is sent. In this 11
case, it is stopped when the BS receives an Assignment Request message or Service 12
Release message from the MSC. 13
5.2.1.6 T
306
14
BS timer T
306
is started when the Handoff Commenced message is sent and stopped 15
when the Clear Command message is received. 16
5.2.1.7 T
308
17
This timer is started when the Service Release message is sent, and stopped when the 18
Service Release Complete message is received. This timer is used at both the MSC and 19
BS. 20
5.2.1.8 T
311
21
This BS timer is started when the BS Service Request message is sent, and stopped when 22
the BS Service Response message is received. 23
5.2.1.9 T
314
24
This MSC timer is started when the Additional Service Notification message is sent, and 25
stopped when the Additional Service Request message is received. 26
5.2.1.10 T
315
27
This MSC timer is started when the Clear Command message is sent, and stopped when 28
the Clear Complete message is received. 29
5.2.1.11 T
paca1
30
This MSC timer is started when the PACA Command message is sent and is stopped 31
when a PACA Command Ack Message is received. 32
TIA-2001.4-C
Section 5 408
5.2.1.12 T
paca2
1
This MSC or BS timer is started when the PACA Update message is sent and is stopped 2
when a PACA Update Ack Message is received. 3
5.2.1.13 T
3231
4
This MSC timer is started when the SCCP Connection Request primitive is sent, and is 5
stopped when an SCCP Connection Confirm primitive or an SCCP Connection Refused 6
primitive is received. For use of these timers, refer to [12]. 7
5.2.1.14 T
3113
8
This MSC timer is started when the Paging Request message or an ADDS Page message 9
is sent, and is stopped when the Page Response message or an ADDS Page Ack message 10
is received. The value of this timer should be set based on BS needs. Typically it will be 11
larger than the sum of the slot cycle length and the maximum access attempt duration. 12
5.2.1.15 T
3230
13
This BS timer is started when any message contained in the Complete Layer 3 14
information message is sent, and is stopped when an SCCP Connection Confirm 15
primitive or an SCCP Connection Refused primitive is received. For use of these timers, 16
refer to [12]. 17
5.2.1.16 T
3280
18
This MSC timer is started when the Privacy Mode Command message is sent, and 19
stopped when the Privacy Mode Complete message is received. 20
5.2.1.17 T
312
21
This timer is started when the MSC receives a CM Service Request message containing 22
an Origination Continuation Indicator, and stopped when the MSC receives a CM Service 23
Request Continuation message. 24
5.2.2 Supplementary Services Timers 25
5.2.2.1 T
softpos
26
MSC timer T
softpos
is started when the Radio Measurements for Position Request 27
message is sent and stopped when the Radio Measurements for Position Response 28
5.2.2.2 T
62
30
MSC timer T
62
is started when the Flash with Information message is sent and stopped 31
when the Flash with Information Ack message is received. 32
TIA-2001.4-C
409 Section 5
5.2.2.3 T
63
1
MSC timer T
63
is started when the a Feature Notification message is sent containing a 2
Tag element and stopped when the Feature Notification Ack message is received. The 3
value of this timer should be set based on BS needs. Typically it will be larger than the 4
sum of the slot cycle length plus the maximum access attempt duration. 5
5.2.2.4 T
60
6
The BS starts this timer when the ADDS Transfer message is sent to the MSC with the 7
ADDS User Part element Data Burst Type field set equal to Short Data Burst or 8
Asynchronous Data Services to authenticate an MS for a Short Data Burst, CCPD Mode, 9
or a Dormant Mode Handoff. The BS stops this timer when the ADDS Transfer Ack 10
message is received from the MSC with the authentication results for the MS. In the 11
event that a traffic channel is required during a dormant mode handoff, this timer shall be 12
stopped when the BS sends a CM Service Request message to the MSC. 13
5.2.3 Mobility Management Timers 14
5.2.3.1 T
3210
15
This BS timer is started when the Location Updating Request message is sent, and is 16
stopped when a Location Updating Accept message a Location Updating Reject message 17
or a Service Redirection message is received. 18
5.2.3.2 T
3220
19
This BS timer is started when the Parameter Update Request message is sent, and is 20
stopped when the Parameter Update Confirm message is received. 21
5.2.3.3 T
3260
22
This MSC timer is started when the Authentication Request message is sent, and is 23
stopped when the Authentication Response message is received. 24
5.2.3.4 T
3270
25
This MSC timer is started when the SSD Update Request message is sent, and is stopped 26
when the Base Station Challenge message is received. 27
5.2.3.5 T
3271
28
This MSC timer is started when the Base Station Challenge Response message is sent, 29
and is stopped when the SSD Update Response message is received. 30
5.2.3.6 T
3272
31
This MSC timer is started when the Status Request message is sent and is stopped when 32
the Status Response message is received. 33
TIA-2001.4-C
Section 5 410
5.2.3.7 T
ordreg
1
This MSC timer is started when the Registration Request message for an MS is sent to 2
the BS and is stopped when the Location Updating Request message for the MS is 3
received from the BS. The value of this timer should be set based on BS needs. Typically 4
it will be larger than the sum of the slot cycle length plus the maximum access attempt 5
duration. 6
For MSs not operating in slotted mode, the default value, or operator configured value of 7
this timer if set, shall be used. 8
5.2.4 Handoff Timers 9
5.2.4.1 T
7
10
The source BS starts this timer when sending the Handoff Required message to the MSC. 11
If strength measurements are being performed, then the timer is started at the time that 12
the Strength Measurement Request message is sent to the MSC. Therefore, the timer 13
represents the time between successive handoff attempts for the same mobile connection. 14
It is recommended that this timer value be long enough to cover all message exchanges 15
with potential targets as well as the maximum time to transmit all transmissions of the 16
Handoff Command message (refer to timer T
8
), and handoff queuing time, if supported. 17
Timer T
7
is stopped when a Handoff Command message or a Handoff Required Reject 18
5.2.4.2 T
8
20
The source BS starts this timer when sending the handoff instruction to the MS. It is 21
recommended that this timer value include all the time necessary to successfully 22
complete handoff execution (i.e., time to send all transmissions of a handoff instruction 23
plus the time to access the target or detect that the MS has not left the source BS). The BS 24
stops this timer when it receives an acknowledgement from the MS. 25
5.2.4.3 T
9
26
The target BS starts this timer when sending the Handoff Request Acknowledge message 27
to the MSC. It is stopped when the MS is acquired or when the MSC sends a Clear 28
Command message to the BS. It represents the time to reserve the target channel while 29
waiting for the MS to arrive on the target channel. This should be at least as long as T
8
. 30
5.2.4.4 T
11
31
This MSC timer is started when the Handoff Request message is send to the BS and is 32
stopped when the Handoff Request Acknowledge message or the Handoff Failure 33
5.2.4.5 T
waitho
35
This BS timer is started when the source BS sends a General Handoff Direction Message 36
to the MS with an indication that the MS is allowed to return to the source BS if it cannot 37
acquire the target BS. This timer is stopped if the source BS receives a Candidate 38
Frequency (CF) Search Report Message, or upon receipt of a Clear Command message 39
TIA-2001.4-C
411 Section 5
from the MSC. The source BS shall wait until this timer expires (if the timer is started) 1
before sending the Handoff Commenced message to the MSC. 2
5.2.5 Facility Management Timers 3
5.2.5.1 T
1
4
The BS starts this timer when the Block or Unblock message is sent and stops it when the 5
Block Acknowledge or Unblock Acknowledge message is received. 6
5.2.5.2 T
2
7
Timer T
2
represents the Reset guard period in the MSC. To avoid a deadlock situation 8
during a BS triggered global reset procedure, timer T
2
(MSC) should always be less than 9
timer T
4
(BS). 10
5.2.5.3 T
4
11
The BS starts this timer when the Reset message is sent and stops it when the Reset 12
Acknowledge message is received. If timer T
4
expires without receiving a Reset 13
Acknowledge message, the BS repeats the Reset procedure. To avoid a deadlock 14
situation during a BS triggered global reset procedure, timer T
2
(MSC) should always be 15
less than timer T
4
(BS). 16
5.2.5.4 T
12
17
This MSC or BS timer is started when a Reset Circuit message is sent and stopped when 18
a Reset Acknowledge message is received. At the MSC, this timer is also stopped when a 19
Block message is received from the BS. 20
5.2.5.5 T
13
21
Timer T
13
represents a Reset guard period at the BS. To avoid a deadlock situation 22
during a MSC triggered global reset procedure, timer T
13
(BS) should always be less 23
than timer T
16
(MSC). 24
5.2.5.6 T
16
25
The MSC starts this timer when a Reset message is sent and stops it when a Reset 26
Acknowledge message is received. If timer T
16
expires without receiving a Reset 27
Acknowledge message, the MSC repeats the Reset procedure. To avoid a deadlock 28
situation during a MSC triggered global reset procedure, timer T
13
(BS) should always be 29
less than timer T
16
(MSC). 30
5.2.5.7 T
309
31
The MSC starts this timer when the Transcoder Control Request message is sent, and 32
stops it when the Transcoder Control Acknowledge message is received. 33
TIA-2001.4-C
Section 5 412
1
2

TIA-2001.5-C
1
2
3
4
5
Access Network Interfaces Part 5 (A3 and A7 6
Interfaces) 7

TIA-2001.5-C

1
3

TIA-2001.5-C
i
Table of Contents 1
2
1.0 Introduction ........................................................................................................................................ 1 3
1.1 Overview........................................................................................................................................ 1 4
1.1.1 Purpose ................................................................................................................................... 1 5
1.1.2 Scope ...................................................................................................................................... 1 6
1.2 References ...................................................................................................................................... 1 7
1.2.1 TIA / EIA................................................................................................................................ 1 8
1.2.2 3GPP2..................................................................................................................................... 2 9
1.3 Terminology ................................................................................................................................... 3 11
1.3.1 Acronyms................................................................................................................................ 3 12
1.3.2 Definitions .............................................................................................................................. 5 13
1.5 Forward Compatibility Guidelines ................................................................................................. 7 15
1.6 Message Processing Guidelines...................................................................................................... 7 16
1.7 Message Definition Guidelines....................................................................................................... 8 17
2.1 A3 Messages Procedures .............................................................................................................. 11 19
2.1.1 A3-Connect........................................................................................................................... 11 20
2.1.2 A3-Connect Ack ................................................................................................................... 12 23
2.1.3 A3-Remove........................................................................................................................... 12 26
2.1.4 A3-Remove Ack ................................................................................................................... 12 29
2.1.5 A3-Drop................................................................................................................................ 13 32
2.1.6 A3-Propagation Delay Measurement Report ........................................................................ 13 35
2.1.7 A3-Physical Transition Directive ......................................................................................... 13 38
2.1.8 A3-Physical Transition Directive Ack.................................................................................. 14 41
2.1.9 A3-Traffic Channel Status .................................................................................................... 14 44
2.1.10 A3-IS-95 FCH Forward........................................................................................................ 15 47
2.1.11 A3-IS-95 FCH Reverse......................................................................................................... 15 50
2.1.12 A3-IS-2000 FCH Forward.................................................................................................... 16 53
TIA-2001.5-C
ii
2.1.13 A3-IS-2000 FCH Reverse..................................................................................................... 16 1
2.1.14 A3-IS-2000 DCCH Forward................................................................................................. 17 4
2.1.15 A3-IS-2000 DCCH Reverse ................................................................................................. 18 7
2.1.16 A3-IS-2000 SCH Forward.................................................................................................... 18 10
2.1.17 A3-IS-2000 SCH Reverse..................................................................................................... 19 13
2.1.18 A3-FCH Forward Traffic Frame........................................................................................... 20 16
2.1.19 A3-FCH Reverse Traffic Frame ........................................................................................... 20 19
2.1.20 A3-DCCH Forward Traffic Frame ....................................................................................... 21 22
2.1.21 A3-DCCH Reverse Traffic Frame ........................................................................................ 22 25
2.1.22 A3-SCH Reverse Traffic Frame ........................................................................................... 23 28
2.2 A7 Messages................................................................................................................................. 23 31
2.2.1 A7-Handoff Request ............................................................................................................. 23 32
2.2.2 A7-Handoff Request Ack ..................................................................................................... 24 35
2.2.3 A7-Drop Target .................................................................................................................... 24 38
2.2.4 A7-Drop Target Ack............................................................................................................. 24 41
2.2.5 A7-Target Removal Request ................................................................................................ 25 44
2.2.6 A7-Target Removal Response .............................................................................................. 25 47
2.2.7 A7-Burst Request.................................................................................................................. 26 50
2.2.8 A7-Burst Response ............................................................................................................... 26 53
2.2.9 A7-Burst Commit ................................................................................................................. 27 56
TIA-2001.5-C
iii
2.2.10 A7-Burst Release .................................................................................................................. 27 3
2.2.11 A7-Reset ............................................................................................................................... 28 6
2.2.12 A7-Reset Acknowledge ........................................................................................................ 28 9
2.2.13 A7-Paging Channel Message Transfer ................................................................................. 29 12
2.2.14 A7-Paging Channel Message Transfer Ack.......................................................................... 29 15
2.2.15 A7-Access Channel Message Transfer ................................................................................. 30 18
2.2.16 A7-Access Channel Message Transfer Ack.......................................................................... 30 21
3.0 Message Formats .............................................................................................................................. 31 24
3.1 A3 Interface Message Formats ..................................................................................................... 31 25
3.1.1 A3-Connect........................................................................................................................... 31 26
3.1.2 A3-Connect Ack ................................................................................................................... 35 27
3.1.3 A3-Remove........................................................................................................................... 38 28
3.1.4 A3-Remove Ack ................................................................................................................... 41 29
3.1.5 A3-Drop................................................................................................................................ 43 30
3.1.6 A3-Propagation Delay Measurement Report ........................................................................ 45 31
3.1.7 A3-Physical Transition Directive ......................................................................................... 47 32
3.1.8 A3-Physical Transition Directive Ack.................................................................................. 51 33
3.1.9 A3-Traffic Channel Status .................................................................................................... 54 34
3.1.10 A3-IS-95 FCH Forward ........................................................................................................ 56 35
3.1.11 A3-IS-95 FCH Reverse......................................................................................................... 57 36
3.1.12 A3-IS-2000 FCH Forward .................................................................................................... 58 37
3.1.13 A3-IS-2000 FCH Reverse..................................................................................................... 59 38
3.1.14 A3-IS-2000 DCCH Forward................................................................................................. 60 39
3.1.15 A3-IS-2000 DCCH Reverse.................................................................................................. 61 40
3.1.16 A3-IS-2000 SCH Forward .................................................................................................... 62 41
3.1.17 A3-IS-2000 SCH Reverse..................................................................................................... 63 42
3.1.18 A3-FCH Forward Traffic Frame........................................................................................... 64 43
3.1.19 A3-FCH Reverse Traffic Frame ........................................................................................... 66 44
3.1.20 A3-DCCH Forward Traffic Frame ....................................................................................... 68 45
3.1.21 A3-DCCH Reverse Traffic Frame ........................................................................................ 70 46
3.1.22 A3-SCH Reverse Traffic Frame ........................................................................................... 72 47
3.2 A7 Interface Message Formats ..................................................................................................... 73 48
3.2.1 A7-Handoff Request ............................................................................................................. 73 49
3.2.2 A7-Handoff Request Ack ..................................................................................................... 81 50
3.2.3 A7-Drop Target .................................................................................................................... 87 51
3.2.4 A7-Drop Target Ack............................................................................................................. 89 52
3.2.5 A7-Target Removal Request ................................................................................................ 91 53
3.2.6 A7-Target Removal Response .............................................................................................. 93 54
3.2.7 A7-Burst Request.................................................................................................................. 95 55
3.2.8 A7-Burst Response ............................................................................................................... 99 56
TIA-2001.5-C
iv
3.2.9 A7-Burst Commit ............................................................................................................... 103 1
3.2.10 A7-Burst Release ................................................................................................................ 107 2
3.2.11 A7-Reset ............................................................................................................................. 110 3
3.2.12 A7-Reset Acknowledge ...................................................................................................... 111 4
3.2.13 A7-Paging Channel Message Transfer ............................................................................... 112 5
3.2.14 A7-Paging Channel Message Transfer Ack........................................................................ 115 6
3.2.15 A7-Access Channel Message Transfer ............................................................................... 116 7
3.2.16 A7-Access Channel Message Transfer Ack........................................................................ 118 8
4.0 Information Element Definitions.................................................................................................... 119 9
4.1 Generic Information Element Encoding..................................................................................... 119 10
4.1.1 Conventions ........................................................................................................................ 119 11
4.1.2 Information Element Identifiers.......................................................................................... 120 12
4.1.3 A3 and A7 Interface Information Elements........................................................................ 122 13
4.1.4 Additional Coding and Interpretation Rules for Information Elements.............................. 122 14
4.1.5 Cross Reference of Information Elements With Messages................................................. 122 15
4.2 Information Elements ................................................................................................................. 131 16
4.2.1 Message Type II ................................................................................................................. 131 17
4.2.2 Physical Channel Info......................................................................................................... 133 18
4.2.3 Mobile Identity ................................................................................................................... 135 19
4.2.4 Cause .................................................................................................................................. 137 20
4.2.5 Cell Identifier...................................................................................................................... 139 21
4.2.6 Cell Identifier List............................................................................................................... 141 22
4.2.7 Downlink Radio Environment ............................................................................................ 142 23
4.2.8 Reverse Pilot Gating Rate................................................................................................... 144 24
4.2.9 Quality of Service Parameters ............................................................................................ 145 25
4.2.10 Forward Burst Radio Info................................................................................................... 146 26
4.2.11 Reverse Burst Radio Info.................................................................................................... 149 27
4.2.12 Software Version ................................................................................................................ 151 28
4.2.13 IS-2000 Service Configuration Record............................................................................... 152 29
4.2.14 Forward Layer 3 IS-2000 FCH/DCCH Data....................................................................... 153 30
4.2.15 Reverse Layer 3 IS-2000 FCH/DCCH Data ....................................................................... 155 31
4.2.16 Forward Layer 3 IS-2000 SCH Data................................................................................... 165 32
4.2.17 Reverse Layer 3 IS-2000 SCH Data ................................................................................... 167 33
4.2.18 CDMA Serving One Way Delay ........................................................................................ 170 34
4.2.19 Neighbor List ...................................................................................................................... 171 35
4.2.20 A3 Signaling Address ......................................................................................................... 172 36
4.2.21 SDU ID............................................................................................................................... 173 37
4.2.22 A3 Traffic Circuit ID.......................................................................................................... 174 38
4.2.23 Call Connection Reference ................................................................................................. 175 39
4.2.24 PMC Cause ......................................................................................................................... 176 40
4.2.25 Band Class .......................................................................................................................... 177 41
4.2.26 Correlation ID..................................................................................................................... 178 42
4.2.27 IS-2000 Non-Negotiable Service Configuration Record .................................................... 179 43
4.2.28 One Way Propagation Delay Record.................................................................................. 180 44
4.2.29 Forward Layer 3 Data......................................................................................................... 181 45
4.2.30 Reverse Layer 3 Data.......................................................................................................... 184 46
4.2.31 CDMA Long Code Transition Info..................................................................................... 188 47
4.2.32 Channel Element ID ........................................................................................................... 189 48
4.2.33 Message CRC ..................................................................................................................... 190 49
4.2.34 Channel Element Status...................................................................................................... 191 50
4.2.35 Cause List ........................................................................................................................... 192 51
4.2.36 Privacy Info ........................................................................................................................ 193 52
4.2.37 A3 Connect Information ..................................................................................................... 195 53
4.2.38 A3 Connect Ack Information ............................................................................................. 201 54
4.2.39 A3 Remove Information ..................................................................................................... 204 55
4.2.40 A3 Drop Information .......................................................................................................... 206 56
TIA-2001.5-C
v
4.2.41 Air Interface Message......................................................................................................... 208 1
4.2.42 Layer 2 Ack Request/Results.............................................................................................. 209 2
4.2.43 A7 Originating ID............................................................................................................... 210 3
4.2.44 A7 Destination ID............................................................................................................... 211 4
4.2.45 A3 Destination ID............................................................................................................... 212 5
4.2.46 IS-2000 Power Control Info................................................................................................ 213 6
4.2.47 IS-2000 Forward Power Control Mode............................................................................... 215 7
4.2.48 IS-2000 FPC Gain Ratio Info.............................................................................................. 216 8
4.2.49 FCH/DCCH Forward Air Interval Control ......................................................................... 218 9
4.2.50 FCH/DCCH Reverse Air Interval Control.......................................................................... 220 10
4.2.51 SCH Reverse Air Interval Control ...................................................................................... 223 11
4.2.52 Forward 20 ms Data............................................................................................................ 225 12
4.2.53 Reverse 20 ms Data ............................................................................................................ 226 13
4.2.54 Forward 5 ms Data.............................................................................................................. 227 14
4.2.55 Reverse 5 ms Data .............................................................................................................. 228 15
4.2.56 Cell Commitment Info List................................................................................................. 229 16
4.2.57 Extended Neighbor List ...................................................................................................... 231 17
4.2.58 A7 Burst Retry Delay List .................................................................................................. 233 18
4.2.59 IS-95 Channel Identity........................................................................................................ 234 19
4.2.60 Extended Handoff Direction Parameters ............................................................................ 236 20
4.2.61 Rescue Request Info ........................................................................................................... 237 21
4.2.62 A3 Traffic IP Address......................................................................................................... 238 22
5.0 Timer Definitions ........................................................................................................................... 239 23
5.1 Timer Values .............................................................................................................................. 239 24
5.2 A3/A7 Timer Definitions............................................................................................................ 239 25
5.2.1 T
bstreq
................................................................................................................................... 239 26
5.2.2 T
bstcom
.................................................................................................................................. 239 27
5.2.3 T
conn3
................................................................................................................................... 240 28
5.2.4 T
discon3
.................................................................................................................................. 240 29
5.2.5 T
drptgt
.................................................................................................................................... 240 30
5.2.6 T
horeq
.................................................................................................................................... 240 31
5.2.7 T
tgtrmv
................................................................................................................................... 240 32
5.2.8 T
chanstat
................................................................................................................................. 240 33
5.2.9 T
physical
................................................................................................................................. 240 34
5.2.10 T
acm
..................................................................................................................................... 241 35
5.2.11 T
pcm
..................................................................................................................................... 241 36
5.2.12 T
2
........................................................................................................................................ 241 37
5.2.13 T
4
........................................................................................................................................ 241 38
39
40
41
TIA-2001.5-C
vi
List of Figures 1
2
Figure 4.1.3-1 A3/A7 Information Element Generic Layout ................................................................. 122 3
4
5
TIA-2001.5-C
vii
List of Tables 1
2
Table 4.1.2-1 A3/A7 Information Element Identifiers Sorted by Identifier Value ............................... 120 4
Table 4.1.5-1 Cross Reference of Information Elements with Messages ............................................. 123 5
Table 4.2.1-1 A3 and A7 Message Type II Values ............................................................................... 131 6
Table 4.2.2-1 A3 Traffic Channel Protocol Stack................................................................................. 133 7
Table 4.2.2-2 Reverse Pilot Gating Rate............................................................................................... 134 8
Table 4.2.2-3 Physical Channel Info - Physical Channel ...................................................................... 134 9
Table 4.2.3-1 Mobile Identity - Type of Identity Coding...................................................................... 135 10
Table 4.2.4-1 Cause Class Values......................................................................................................... 137 11
Table 4.2.4-2 Cause Values .................................................................................................................. 138 12
Table 4.2.5-1 Cell Identifier - Cell Identification Discriminator List ................................................... 139 13
Table 4.2.5-4 Cell Identifier - Cell Identification Discriminator = 0000 0111................................... 139 14
Table 4.2.8-1 Reverse Pilot Gating Rate - Pilot Gating Rate................................................................ 144 15
Table 4.2.10-1 Forward Burst Radio Info Coding Indicator ......................................................... 146 16
Table 4.2.11-1 Reverse Burst Radio Info Coding Indicator.......................................................... 149 17
Table 4.2.15-1 Reverse Layer 3 IS-2000 FCH/DCCH Data - Time Scale for the PATE................. 156 18
Table 4.2.15-2 IS-2000 Frame Content - Special Frame Content Parameters ................................. 157 19
Table 4.2.15-3 IS-2000 Frame Content - FCH Frame Content Parameters ..................................... 157 20
Table 4.2.15-4 IS-2000 Frame Content - DCCH Frame Content Parameters .................................. 158 21
Table 4.2.15-5 IS-2000 Frame Content - SCH Frame Content Parameters for 20 ms Frames......... 158 22
Table 4.2.15-6 IS-2000 Frame Content - SCH Frame Content Parameters for 40 ms Frames*....... 159 23
Table 4.2.15-7 IS-2000 Frame Content - SCH Frame Content Parameters for 80 ms Frames*....... 160 24
Table 4.2.15-8 Signal to Noise Ratio Values ................................................................................... 162 25
Table 4.2.17-1 Reverse Layer 3 IS-2000 SCH Data - Time Scale for the PATE............................. 168 26
Table 4.2.20-1 A3 Address Identifier Type ..................................................................................... 172 27
Table 4.2.24-1 PMC Cause Values .................................................................................................. 176 28
Table 4.2.25-1 Band Class ............................................................................................................... 177 29
Table 4.2.29-1 Forward Layer 3 Data - Rate Set Indicator .............................................................. 181 30
Table 4.2.29-2 Forward Layer 3 Data - Forward Traffic Channel Rate........................................... 182 31
Table 4.2.29-3 Forward Layer 3 Data - Forward Traffic Channel Information ............................... 182 32
Table 4.2.29-4 Forward Layer 3 Data - Layer 3 Fill ........................................................................ 183 33
Table 4.2.30-2 Reverse Layer 3 Data - Time Scale for the Packet Arrival Time Error ................... 185 34
Table 4.2.30-3 Reverse Layer 3 Data - Rate Set Indicator............................................................... 185 35
Table 4.2.30-4 Reverse Layer 3 Data - Reverse Traffic Channel Rate ............................................ 186 36
Table 4.2.30-5 Reverse Layer 3 Data - Reverse Traffic Channel Information Bits ......................... 187 37
Table 4.2.30-6 Reverse Layer 3 Data - Layer 3 Fill Bits ................................................................. 187 38
Table 4.2.36-1 Privacy Info - Privacy Mask Type ........................................................................... 194 39
Table 4.2.46-1 Subchannel Gain Values .......................................................................................... 214 40
Table 4.2.48-1 Independent Soft Handoff Legs ............................................................................... 217 41
Table 4.2.50-1 Reverse Layer 3 FCH/DCCH Data - Time Scale for the PLATE............................ 220 42
Table 4.2.51-1 Reverse Layer 3 IS-2000 SCH Data - Time Scale for the PATE............................. 224 43
Table 4.2.62-1 A3 Traffic IP Address Type and Format.................................................................. 238 44
Table 5.1-1 Timer Values and Ranges Sorted by Name ........................................................................ 239 45
46
47
TIA-2001.5-C
viii
1
3
4
5
6
7
TIA-2001.5-C
1 Section 1
1.0 Introduction 1
2
1.1 Overview 3
timers used to define the A3 and A7 interfaces. 5
1.1.1 Purpose 6
The purpose of this document is to provide the standard for interfacing a Base Station 7
(BS) with one or more BSs. This document defines the functional capabilities, including 8
services and features, of the specified interface. These services and features are the 9
defining characteristics that are the basis for the overall system standard. 10
1.1.2 Scope 11
Reference Point A
ter
defined in the TR45 Network Reference Model shown in [21]. 13
Descriptions of the specified functional capabilities that provide wireless telecommun- 15
ications services across the BS-BS interface as defined in the TR45 Network Reference 16
Model; 17
source BS and the target BS, without prescribing specific implementations; 19
Descriptions of the BS-BS interface standard that support DS-41 and cdma2000
1
20
systems. 21
1.2 References 22
23
1.2.1 TIA / EIA 24
with the 3GPP2 references, provided in section 1.2.2. 27

[2] TIA/EIA/IS-2000.2-C, Physical Layer Standard for cdma2000
Spread 30
[3] TIA/EIA/IS-2000.3-C, Medium Access Control (MAC) Standard for cdma2000
32

1
cdma2000

TIA-2001.5-C
Section 1 2
[4] TIA/EIA/IS-2000.4-C, Signaling Link Access Control (LAC) Standard for 1
cdma2000

[5] TIA/EIA/IS-2000.5-C, Upper Layer (Layer 3) Signaling Standard for 3
cdma2000

[6] TIA/EIA/IS-2000.6-C, Analog Signaling Standard for cdma2000
Spread 5
[7] Reserved. 7
[8] Reserved. 8
[9] TIA/EIA-41-D, Cellular Radiotelecommunications Intersystem Operations, 9
December 1997. 10
[10] TIA/EIA-95-B; Mobile Station - Base Station Compatibility Standard for 11
Wideband Spread Spectrum Cellular Systems, March 1999. 12
[11] Reserved. 13
Access 14
[13] TIA--2001.3-C, Interoperability Specification (IOS) for cdma2000
Access 16
[14] Reserved. 18
[15] Reserved. 19
[16] Reserved. 20
[17] Reserved. 21
[18] TIA/EIA/IS-637-B, Short Message Service for Wideband Spread Spectrum 22
[19] TIA/EIA/TSB29-D, International Implementation of Wireless 24
Telecommunication Systems Compliant with TIA/EIA-41, December 2000. 25
cdma2000
Spread Spectrum Standards, January 2002. 27

[22] TIA/EIA-97-C, Base Station Minimum Performance, December 1999. 29
1.2.2 3GPP2 30

Spread Spectrum 35
37
cdma2000

41
Spread 43
[7] Reserved. 45
[8] Reserved. 46
[9] Reserved. 47
[10] Reserved. 48
[11] Reserved. 49
Access 50
TIA-2001.5-C
3 Section 1
Access 1
[14] Reserved. 3
[15] Reserved. 4
[16] Reserved. 5
[17] Reserved. 6
[18] Reserved. 7
[19] 3GPP2 N.S0017-A, International Implementation of Wireless 8
Telecommunication Systems Compliant with TIA/EIA-41, March 2001. 9
[20] 3GPP2 C.R1001-C, Administration of Parameter Value Assignments for CDMA 10
Spread Spectrum 12
[22] 3GPP2 C.S0010-0, Base Station Minimum Performance, December 1999. 14
15
[23] ITU-T Recommendation X.25, October 1996. 18
1.3 Terminology 19
20
1.3.1 Acronyms 21
22
Acronym Meaning
ARFCN Absolute Radio Frequency Channel Number
ASCII American Standard Code for Information Interchange
ATM Asynchronous Transfer Mode
BS Base Station
CCSH Code Combining Soft Handoff
CDG CDMA Development Group
CE Channel Element
CI Cell Identity
CID Connection Identifier (used with reference to AAL2)
CRC Cyclic Redundancy Code (or check)
TIA-2001.5-C
Section 1 4
Acronym Meaning
DTX Discontinuous Transmission
EIB Erasure Indicator Bit
ESCAM Extended Supplemental Channel Assignment Message
FER Frame Error Rate
FPC Forward Power Control
FQI Frame Quality Indicator
FSN Frame Sequence Number
GR Gain Ratio
IMT International Mobile Telecommunications
IS Interim Standard
ITU International Telecommunications Union
JTACS Japanese Total Access Communications
LAC Location Area Code
LCM Long Code Mask
MCC Mobile Country Code
MNC Mobile Network Code
MS Mobile Station
MUX Multiplexer
NMT Nordic Mobile Telephone
Provisioning
OLT Outer Loop Threshold
OTD Orthogonal Transmit Diversity
PATE Packet Arrival Time Error
PCS Personal Communications System
PMC Packet Mode Channel
PN Pilot Number
PWR Power
TIA-2001.5-C
5 Section 1
Acronym Meaning
QIB Quality Indicator Bit
QOF Quasi Orthogonal Function
RC1 Radio Configuration 1
RF Radio Frequency
RPC Reverse Power Control
RSSI Received Signal Strength Indicator
SCTP Stream Control Transmission Protocol
SIR Signal to Interference Ratio
SLC Sector Link Count
SR3 Spreading Rate 3 (3X)
TACS Total Access Communications
TCP Transmission Control Protocol
VCCI Virtual Channel Connection Identifier
1.3.2 Definitions 1
DS-41. An operational mode in which the BS and MS operate with the direct spread (DS) 3
radio layers of the UMTS system defined by 3GPP, and the upper layers defined in 4
CDMS2000 that conform to and interoperate with ANSI-41 based networks. 5
For each A3 and A7 message there are a number of information elements that are 7
individually defined in section 4.2. Each information element in a given message is 8
of being either required (R) or conditional (C) (see below). Some information elements 12
are reused in multiple messages. 13
14
TIA-2001.5-C
Section 1 6
Source BS -> Target BS Element flows from the Source BS to the Target BS
Target BS -> Source BS Element flows from the Target BS to the Source BS
M Information elements which are mandatory for the message. 7
O Information elements which are optional for the message. 8
An information element can very well be mandatory for some messages and optional for 19
other messages. 20
The bitmap tables in the message subsections of 3.0 are patterned after the format for the 21
information elements of section 4.2 and use the following conventions: 22
double lines. 26
element. 29
indicates: 34
<octet 1> 39
TIA-2001.5-C
7 Section 1
<octet m> 1
ssss ssss 7
ssss ssss 9
implemented to later revision levels the following guidelines are defined for the 13
standard. 15
version of the protocol may send information to an entity implemented at a lower level of 18
the protocol which is outside the protocol definition supported at that receiving entity. 19
message processing guidelines are invoked to ensure predictable network behavior. 23
If the receiving entity is implemented to IOS v3.0 or greater, then the sending entity shall 24
send messages that are correctly formatted for the version of the IOS declared to be 25
implemented by the sending entity. 26
If the receiving entity is implemented to a CDG IOS version less than 3.1.0, then if the 27
sending entity is at an equal or greater version than the receiver, the sending entity shall 28
format messages according to the version of the protocol implemented at the receiving 29
entity. 30
For example, a CDG IOS version 3.1.0 entity by using the following guidelines may be 31
capable of ignoring additional new elements or fields within elements sent by an entity 32
implemented to an IOS version higher than 3.1.0. 33
optional required information elements as indicated in the message tables in section 38
3.0. 39
TIA-2001.5-C
Section 1 8
Refer also to message processing guidelines 9 and 10 below. 12
processed. 19
reserved or is otherwise not defined in the revision level implemented this field 24
possible. In this situation, all other information elements in the message shall be 26
entity. 30
be ignored. 34
The old use of the element identifier shall be supported within the context of the old 46
messages in which it was used. 47
TIA-2001.5-C
9 Section 1
received. 3
future revisions. 5
not change. 7
14
TIA-2001.5-C
Section 1 10
1
3
4
5
6
7
TIA-2001.5-C
11 Section 2
Efficient inter-BS soft handoff is supported via direct BS to BS signaling and traffic 2
connections between base stations. The A3 and A7 interfaces are used to support this 3
form of inter-BS soft handoff. 4
The A3 interface, composed of signaling and user traffic subchannels, provides the ability 5
to establish and remove A3 traffic connections. The A3 interface also provides support 6
for operational procedures, such as turning on/off voice privacy or changing the service 7
configuration of a call. 8
The A7 interface provides direct BS to BS signaling for the support of efficient soft 9
handoff. Only a call release procedure should interrupt any handoff procedure. Multiple 10
concurrent A7 Handoff Add procedures are prohibited for the same physical channel on 11
the same call. Multiple concurrent A7 Handoff Drop procedures for the same physical 12
channel on the same call are prohibited. A3 and A7 interface messages are not applicable 13
to DS-41 base stations. 14
2.1 A3 Messages Procedures 15
This section contains message procedures for the A3 interface. 16
2.1.1 A3-Connect 17
The A3-Connect message is sent from the target BS to the source BS to initiate or add 18
cells to one or more A3 user traffic connection. An A3-Connect Ack message is expected 19
in response. 20
Upon receiving the A3 Signaling Address information in the A7-Handoff Request 22
message, if a new connection is required, the receiving BS begins the process of 23
establishing the A3 signaling connection with the source BS. The A3 Signaling Address 24
is used by the target BS to allocate a logical circuit to be used for A3 signaling. The SDU 25
ID identifies the particular instance of the SDU function. If the A3 Signaling Address 26
information is not present in the A7-Handoff Request message, the receiving BS shall 27
select the A7 signaling link from which the A7-Handoff Request message is received as 28
the A3 signaling link. 29
All cells in softer handoff are power combined and share a single A3 traffic connection. 30
Following the selection of the A3 signaling link, the A3-Connect message is sent from 31
the target BS to the source BS. The target BS expects an A3-Connect Ack message 32
indicating the result of processing the A3-Connect message and, therefore, starts timer 33
T
conn3
. 34
If timer T
conn3
expires before receipt of an A3-Connect Ack message, the target BS shall 36
include all new cells that would have been added by the A3-Connect message to the list 37
of non-committed cells in the A7-Handoff Request Ack message. 38
TIA-2001.5-C
Section 2 12
2.1.2 A3-Connect Ack 1
The A3-Connect Ack message is sent from the source BS to the target BS to indicate the 2
result of processing the A3-Connect message. 3
After processing the A3-Connect message from the target BS, the source BS indicates 5
success/failure to the target BS by sending an A3-Connect Ack message. Upon receipt of 6
the A3-Connect Ack message, the target BS stops timer T
conn3
. 7
If the A3-Connect Ack message indicates that A3-Traffic Channel Status messages are to 8
be sent, then the source BS starts timer T
chanstat
to await A3-Traffic Channel Status 9
message(s) for all new cells on each A3 connection. One instance of this timer is started 10
for each A3 connection to which one or more cells are being added. 11
If an instance of timer T
chanstat
expires, the source BS may assume that a failure has 13
occurred at the target BS during activation of the transmitter(s)/receiver(s) and delete the 14
unreported cells from the active set attached to the A3 connection. The source BS may 15
then send an A7-Drop Target message to the target BS to cleanly remove those cells from 16
2.1.3 A3-Remove 18
A target BS uses the A3-Remove message to request that the source BS remove the 19
indicated cells from the indicated A3 connections. This might result in the removal of an 20
entire A3 traffic subchannel if the last cell on that traffic subchannel is removed. 21
The target BS sends an A3-Remove message to the source BS requesting removal of the 23
indicated cells from one or more A3 connection. The target BS starts timer T
discon3
.The 24
source BS replies with an A3-Remove Ack message. If the last cell is removed from an 25
A3 traffic subchannel, the entire A3 traffic subchannel is also terminated. 26
If timer T
discon3
expires, the target BS may resend the A3-Remove message. 28
2.1.4 A3-Remove Ack 29
The A3-Remove Ack message is used by the source BS to notify the target BS that sent 30
the A3-Remove message of the outcome of processing the A3-Remove message. 31
The source BS sends an A3-Remove Ack message to the target BS that sent the A3- 33
Remove message to indicate the results of processing the A3-Remove message. One A3- 34
Remove Ack message is sent in response to each A3-Remove message. If the source BS 35
does not recognize an A3 user traffic connection identified in the A3-Remove message as 36
TIA-2001.5-C
13 Section 2
being associated with the Call Connection Reference value included in that this message, 1
it shall send an appropriate cause for the failure in the A3-Remove Ack message. Upon 2
receipt of the A3-Remove Ack message, the target BS stops timer Tdiscon3. Upon 3
receipt of the A3-Remove Ack message, the target BS stops timer T
discon3
. 4
None. 6
2.1.5 A3-Drop 7
The purpose of the A3-Drop message is to indicate that the source BS is removing the 8
indicated A3 traffic subchannel, e.g., as a result of OAM&P intervention. 9
The source BS may send an A3-Drop message to indicate that the A3 traffic subchannel 11
between the receiving BS and the source BS is about to be terminated. This is a unilateral 12
action taken by the source BS. An appropriate cause value shall be included. 13
None. 15
2.1.6 A3-Propagation Delay Measurement Report 16
This message is sent from the target BS to the source BS over the A3 signaling interface. 17
It contains the CDMA serving one way delay measured at the target BS. 18
This message is sent from the target BS to the source BS over the A3 signaling interface 20
immediately following the acquisition of the MS and subsequently whenever the 21
propagation delay changes by two or more PN chips. 22
None. 24
2.1.7 A3-Physical Transition Directive 25
This message is sent from the source BS to the target BS over the A3 interface. It 26
conveys a change to an allocated physical channel at the target BS as well as the expected 27
time of execution for the change. 28
When an allocated physical channel is to be changed for a call, the source BS shall 30
transmit an A3-Physical Transition Directive to a target BS and start timer T
physical
. 31
TIA-2001.5-C
Section 2 14
If a change to an allocated physical channel is already pending at the target BS, the 1
reception of this message replaces the pending operation and the pending action time. 2
The new transition may place the BS into the same state it already is supporting, thus 3
effectively canceling the previously pending transition. 4
If timer T
physical
expires, the message may be resent. 6
2.1.8 A3-Physical Transition Directive Ack 7
This A3 message is sent from the target BS to the source BS over the A3 signaling 8
interface to convey the outcome of processing an A3-Physical Transition Directive 9
message. 10
Upon receipt of an A3-Physical Transition Directive from the source BS, the target BS 12
shall transmit an A3-Physical Transition Directive Ack message to the source BS to 13
indicate the outcome of processing the received message. The source BS shall stop timer 14
T
physical
upon receipt of the A3-Physical Transition Directive Ack message. 15
None. 17
2.1.9 A3-Traffic Channel Status 18
The A3-Traffic Channel Status message is used by the target BS to notify the source BS 19
that radio transmission on the forward link has begun for the indicated cells, and that the 20
corresponding receivers have been activated. This message is sent when the A3-Connect 21
Ack message indicates that it is requested. 22
When the target BS needs to notify the source BS of a status change relative to a specific 24
set of cells on one A3 connection, it sends an A3-Traffic Channel Status message. 25
This message can be used to note that the indicated set of cells has begun receiving 26
forward frames from the source BS and has begun transmitting on the forward radio link. 27
The target BS may not send this message in response to an A3-Connect Ack message, if 28
its transmitters(s)/receiver(s) are not turned on (i.e., the radio transmission on the forward 29
link has not begun for the indicated cells). 30
Multiple instances of this message may be sent relative to a single A3 connection if, for 31
instance, transmitter(s)/receiver(s) are activated at different times. However, all cells 32
referenced within a single instance of this message shall be attached to the same A3 33
connection. 34
The source BS stops the instance of timer T
chanstat
for the A3 connection when the A3- 35
Traffic Channel Status message(s) have been received containing references to all cells 36
added to the A3 connection by the A3-Connect message. 37
TIA-2001.5-C
15 Section 2
None. 2
2.1.10 A3-IS-95 FCH Forward 3
This message is sent from the source BS to the target BS on the A3 user traffic 4
subchannel for subchannels of type IS-95 FCH. It contains the Forward Traffic 5
Channel frame for the served MS along with control information. 6
This message is sent from the source BS to the target BS on A3 user traffic subchannel 8
connections of type IS-95 FCH once every 20 ms. 9
The forward path delay shall be according to the delay budget requirements table in [12] 10
measured from the time the first bit of the frame is transmitted from the source BS to the 11
time the first bit of the frame is transmitted over the air interface at the channel element 12
(CE) for any soft handoff leg. This assumes a maximum delay on the A3 traffic 13
connection according to the delay budget requirements table in [12]. The delay limits 14
defined above do not apply to satellite applications. 15
Forward Frame Sequence Number Alignment clarification: 16
The SDU function may use the Packet Arrival Time Error (PATE) and Sequence Number 17
information received in the A3-IS-95 FCH Reverse message to ensure that all target BSs 18
involved in soft handoff for a call simultaneously transmit identical forward air frames 19
during identical 20 ms frame boundaries. 20
None. 22
2.1.11 A3-IS-95 FCH Reverse 23
This message is sent from the target BS to the source BS on A3 user traffic subchannel 24
connections of type IS-95 FCH once every 20 ms. It contains the decoded Reverse 25
Traffic Channel frame received from the served MS along with control information. 26
This message is sent from the target BS to the source BS on the A3 user traffic 28
subchannel connections of type IS-95 FCH once every 20 ms following the decoding 29
of the Reverse Traffic Channel frame. 30
The reverse speech path delay shall be according to the delay budget requirements table 31
in [12] from the time the last bit of the frame is received on the air interface at the 32
channel element of any soft handoff leg to the time the last bit of the frame is received at 33
the source BS. This assumes a maximum delay on the A3 traffic connection according to 34
the delay budget requirements table in [12]. 35
The delay limits defined above do not apply to satellite applications. 36
TIA-2001.5-C
Section 2 16
Forward Frame Alignment Requirements: 1
As part of the reverse-link processing, each target BTS channel element shall estimate the 2
arrival time error for the A3-IS-95 FCH Forward message last received and shall set the 3
PATE field of the next transmitted A3 IS-95 FCH Reverse message to this value. 4
If the value cannot be represented within the maximum range of the PATE, it shall be set 5
to the maximum positive value. Positive PATE values indicate that the message arrived 6
too late to be transmitted in the correct air frame. Negative PATE values indicate that the 7
message arrived too early and therefore is required to be buffered before transmission. A 8
zero PATE value indicates that the message arrived at the optimum time for processing 9
and transmission. 10
None. 12
This message is sent from the source BS to the target BS on the A3 cdma2000
user 14
traffic subchannel channel for subchannel of type FCH. It contains the Forward air- 15
frame for the served MS along with control information. 16
This message is sent from the source BS to the target BS on A3 IS-2000 user traffic 18
subchannel connections of type FCH. FCH messages are sent once every 20 ms. 19
The forward path message delay shall be according to the delay budget requirements 20
table in [12] from the time the first bit of the frame is transmitted from the source BS to 21
the time the first bit of the frame is transmitted over the air interface at the channel 22
element for any soft handoff leg. This assumes a maximum transmission and queuing 23
delay on the A3 traffic connection according to the delay budget requirements table in 24
[12]. The delay limits defined above do not apply to satellite applications. 25
The SDU function may use the PATE and Sequence Number information received in the 27
A3-IS-2000 FCH Reverse message to ensure that all BSs involved in soft handoff for a 28
call simultaneously transmit identical forward air frames during identical 20 ms frame 29
boundaries. 30
None. 32
This message is sent from the target BS to the source BS on A3 cdma2000
user traffic 34
subchannel connections of type IS-2000 FCH (cdma2000
FCH). It contains the 35

decoded Reverse Traffic Channel frame received from the served MS along with control 36
information. 37
TIA-2001.5-C
17 Section 2
This message is sent to the source BS on the A3 IS-2000 user traffic subchannel 2
connections of type IS-2000 FCH following the decoding of the Reverse Traffic 3
Channel frame. IS-2000 FCH frames are sent once every 20 ms. 4
The reverse path message delay shall be according to the delay budget requirements table 5
in [12] measured from the time the last bit of the frame is received on the air interface at 6
the channel element of any soft handoff leg to the time the last bit of the frame is received 7
at the source BS. This assumes a maximum transmission and queuing delay on the A3 8
traffic connection according to the delay budget requirements table in [12]. The delay 9
limits defined above do not apply to satellite applications. 10
arrival time error for the A3-IS-2000 FCH Forward message last received and shall set 13
the PATE field of the next transmitted A3-IS-2000 FCH Reverse message to this value. 14
None. 22
2.1.14 A3-IS-2000 DCCH Forward 23
This message is sent from the source BS to the target BS on the A3 IS-2000 user traffic 24
subchannel for subchannels of type IS-2000 DCCH. It contains the Forward air-frame 25
for the served MS along with control information. 26
subchannel connections of type IS-2000 DCCH. IS-2000 DCCH frames are sent once 29
every 20 ms. 30
table in [12]measured from the time the first bit of the frame is transmitted from the 32
source BS to the time the first bit of the frame is transmitted over the air interface at the 33
channel element for any soft handoff leg. This assumes a maximum transmission and 34
queuing delay on the A3 traffic connection according to the delay budget requirements 35
table in [12]. The delay limits defined above do not apply to satellite applications. 36
A3-IS-2000 DCCH Reverse message to ensure that all BSs involved in soft handoff for a 39
TIA-2001.5-C
Section 2 18
call simultaneously transmit identical forward air frames during identical frame 1
boundaries. 2
None. 4
2.1.15 A3-IS-2000 DCCH Reverse 5
This message is sent from the target BS to the source BS on A3 IS-2000 user traffic 6
subchannel connections of type IS-2000 DCCH. It contains the decoded Reverse 7
Traffic Channel frame received from the served MS along with control information. 8
This message is sent from the target BS to the source BS on the A3 IS-2000 user traffic 10
subchannel connections of type IS-2000 DCCH following the decoding of the Reverse 11
Traffic Channel frame. IS-2000 DCCH frames are sent once every 20 ms. 12
arrival time error for the A3-IS-2000 DCCH Forward message last received and shall set 21
the PATE field of the next transmitted A3-IS-2000 DCCH Reverse message to this value. 22
None. 30
2.1.16 A3-IS-2000 SCH Forward 31
This message is sent from the source BS to the target BS on the A3 user traffic 32
subchannel connections of type IS-2000 SCH. It contains the Forward Traffic Channel 33
frame for the served MS along with control information. 34
subchannel connections of type IS-2000 SCH SCH frames are sent once every 20 ms. 37
TIA-2001.5-C
19 Section 2
Furthermore, IS-2000 SCH messages containing Null frame content may be suppressed 1
(i.e., not transmitted) on the A3 connection according to the restrictions outlined in the 2
message format definition. 3
table in [12] measured from the time the first bit of the frame is transmitted from the 5
If the SDU has no data to forward to the target BS during a traffic burst, the SDU shall 10
set the Frame Content field of this message to Null (7FH). 11
A3-IS-2000 SCH Reverse message to ensure that all BSs involved in soft handoff for a 14
call simultaneously transmit identical forward air frames during identical 20 ms frame 15
boundaries. 16
None. 18
2.1.17 A3-IS-2000 SCH Reverse 19
This message is sent from the target BS to the source BS on A3 IS-2000 user traffic 20
subchannel connections of type IS-2000 SCH. It contains the decoded Reverse Traffic 21
Channel frame received from the served MS along with control information. 22
This message is sent from the target BS to the source BS on the A3 IS-2000 user traffic 24
subchannel connections of type IS-2000 SCH following the decoding of the Reverse 25
Traffic Channel frame. IS-2000 SCH frames are sent once every 20 ms. Furthermore, IS- 26
2000 SCH messages containing Null frame content may be suppressed (i.e., not 27
transmitted) on the A3 connection according to the restrictions outlined in the message 28
format definition. 29
arrival time error for the A3-IS-2000 SCH Forward message last received and shall set 38
the PATE field of the next transmitted A3-IS-2000 SCH Reverse message to this value. 39
TIA-2001.5-C
Section 2 20
and transmission. 6
None. 8
2.1.18 A3-FCH Forward Traffic Frame 9
This A3 message is sent from the source BS to the target BS over A3 user traffic 11
subchannel connections of type IS-2000 FCH. It may be used to send up to one 20 ms 12
forward traffic channel frame and up to four 5 ms forward traffic channel frames to the 13
target BS for transmission to the MS during the specified 20 ms interval. This message 14
also contains control information associated with the 20 ms interval. One and only one 15
A3-FCH Forward Traffic Frame message is sent for each 20 ms interval. This A3 16
message is only used if a 5 ms signaling message is being sent to the BTS. If no 5 ms 17
signaling message is to be included, the A3-IS-2000 FCH Forward message (2.1.12) shall 18
be used instead. This A3 message may also be used to send a 20 ms traffic frame without 19
a 5 ms signaling message if agreed to by both vendors. This message shall not be sent to 20
implementations running a version of the IOS earlier than TIA/EIA-2001-A (IOS V4.1). 21
A3-IS-2000 FCH Reverse message to ensure that all BSs involved in soft handoff for a 30
boundaries. 32
None. 34
2.1.19 A3-FCH Reverse Traffic Frame 35
This A3 message is sent from the target BS to the source BS over A3 user traffic 37
subchannel connections of type IS-2000 FCH. It is used by the target BS to send up to 38
one 20 ms decoded reverse link traffic channel frame and up to four 5 ms decoded 39
reverse link traffic channel frames and control information to the source BS for a given 40
20 ms interval. This message is not to be suppressed due to streaming feedback required 41
TIA-2001.5-C
21 Section 2
for EIB-based power control. One and only one A3-FCH Reverse Traffic Frame message 1
is sent for each 20 ms interval. This A3 message is only used if a 5 ms signaling message 2
has been received from the BTS. If no 5 ms signaling message is to be included, the A3- 3
IS-2000 FCH Reverse message (2.1.13) should be used instead. This message shall not be 4
sent to implementations running a version of the IOS earlier than TIA/EIA-2001-A (IOS 5
v4.1). This A3 message may also be used to send a 20 ms traffic frame without a 5 ms 6
signaling message if agreed to by both vendors. 7
arrival time error for the A3-IS-2000 FCH Forward message last received and shall set 16
the PATE field of the next transmitted A3-IS-2000 FCH Reverse message to this value. 17
None. 25
2.1.20 A3-DCCH Forward Traffic Frame 26
This A3 message is sent from the source BS to the target BS over A3 user traffic 28
subchannel connections of type IS-2000 DCCH. It may be used to send up to one 20 29
ms forward traffic channel frame and up to four 5 ms forward traffic channel frames to 30
the target BS for transmission to the MS during the specified 20 ms interval. This 31
message also contains control information associated with the 20 ms interval. One and 32
only one A3-DCCH Forward Traffic Frame message is sent for each 20 ms interval. This 33
A3 message is only used if a 5 ms signaling message is being sent to the BTS. If no 5 ms 34
signaling message is to be included, the A3-IS-2000 DCCH Forward message (2.1.14) 35
should be used instead. [20] This message shall not be sent to implementations running a 36
version of the IOS earlier than TIA/EIA-2001-A (IOS V4.1). This A3 message may also 37
be used to send a 20 ms traffic frame without a 5 ms signaling message if agreed to by 38
both vendors. 39
TIA-2001.5-C
Section 2 22
A3-IS-2000 DCCH Reverse message to ensure that all BSs involved in soft handoff for a 5
boundaries. 7
None. 9
2.1.21 A3-DCCH Reverse Traffic Frame 10
This A3 message is sent from the target BS to the source BS over A3 user traffic 12
subchannel connections of type IS-2000 DCCH. It is used by the target BS to send up 13
to one 20 ms decoded reverse link traffic channel frame and up to four 5 ms decoded 14
reverse link traffic channel frames and control information to the source BS for a given 15
20 ms interval. This message is not to be suppressed due to streaming feedback required 16
for EIB-based power control. One and only one A3-DCCH Reverse Traffic Frame 17
message is sent for each 20 ms interval. This A3 message is only used if a 5 ms signaling 18
message has been received from the BTS. If no 5 ms signaling message is to be included, 19
the A3-IS-2000 DCCH Reverse message (2.1.15) should be used instead. This message 20
shall not be sent to implementations running a version of the IOS earlier than IOS V4.1. 21
This A3 message may also be used to send a 20 ms traffic frame without a 5 ms signaling 22
message if agreed to by both vendors. 23
arrival time error for the A3-IS-2000 DCCH Forward message last received and shall set 32
the PATE field of the next transmitted A3-IS-2000 DCCH Reverse message to this value. 33
None. 41
TIA-2001.5-C
23 Section 2
2.1.22 A3-SCH Reverse Traffic Frame 1
This A3 message is sent from the target BS to the source BS over A3 cdma2000
user 3
traffic subchannel connections of type IS-2000 SCH. It is used by the target BS to send 4
one 20 ms decoded reverse link traffic channel frame and control information to the 5
source BS for a given 20 ms interval. This message is not to be suppressed due to 6
streaming feedback required for EIB-based power control. One and only one A3-SCH 7
Reverse Traffic Frame message is sent for each 20 ms interval. 8
arrival time error for the A3-IS-2000 SCH Forward message last received and shall set 17
the PATE field of the next transmitted A3-IS-2000 SCH Reverse message to this value. 18
None. 26
2.2 A7 Messages 27
A7 interface messages are not applicable to DS-41 base stations. 28
This section describes the messages and procedures used between base stations on an A7 29
connection to support direct BS to BS soft/softer handoff, access handoff, access probe 30
handoff, and channel assignment into soft/softer handoff. 31
2.2.1 A7-Handoff Request 32
The A7-Handoff Request message is used by the source BS to request that a target BS 33
allocate resources in one or more cells for support of a call association. 34
When the source BS decides that one or more cells at a target BS are needed to support 36
one or more physical channel connections for a call, the source BS sends an A7-Handoff 37
TIA-2001.5-C
Section 2 24
Request message to the target BS to indicate the resources required. The source BS then 1
starts timer T
horeq
. 2
If timer T
horeq
expires, the source BS may resend the A7-Handoff Request message. 4
2.2.2 A7-Handoff Request Ack 5
The A7-Handoff Request Ack message is used by the target BS to respond to a request 6
that it allocate resources in one or more cells for support of one or more physical channel 7
connections for a call association. 8
When the target BS receives an A7-Handoff Request message, it determines what 10
internal resources are needed to support the requested physical channels for the call 11
association. Once those resources are allocated and the A3-Connect Ack message(s) has 12
been received, the target BS responds by sending an A7-Handoff Request Ack message 13
to the source BS. Upon receipt of the A7-Handoff Request Ack message, the source BS 14
stops timer T
horeq
. 15
None. 17
2.2.3 A7-Drop Target 18
The A7-Drop Target message is used by the source BS to request that a target BS 19
deallocate resources in one or more cells currently being used for support of one or more 20
physical channel connections for a call association. 21
When the source BS decides that one or more cells at a target BS are no longer needed to 23
support one or more physical channel connections for a call association, the source BS 24
sends an A7-Drop Target message to the target BS to indicate the resources that are no 25
longer required. The source BS then starts timer T
drptgt
. 26
If timer T
drptgt
expires, the source BS may resend the A7-Drop Target message. 28
2.2.4 A7-Drop Target Ack 29
The A7-Drop Target Ack message is used by the target BS to respond to a request that it 30
deallocate resources in one or more cells currently being used for support of one or more 31
TIA-2001.5-C
25 Section 2
When the target BS receives an A7-Drop Target message, it determines what resources 2
are no longer needed to support the call association. Once those resources are 3
deallocated, the target BS responds by sending an A7-Drop Target Ack message to the 4
source BS. Upon receipt of the A7-Drop Target Ack message, the source BS stops timer 5
T
drptgt
. 6
None. 8
2.2.5 A7-Target Removal Request 9
The A7-Target Removal Request message is used by the target BS to request that a 10
source BS remove one or more cells currently being used for support of one or more 11
When the target BS decides that one or more cells can no longer provide support for a 14
call association, the target BS sends an A7-Target Removal Request message to the 15
source BS to indicate the resources that can no longer be provided. The target BS then 16
starts timer T
tgtrmv
. 17
The target BS shall indicate in this message, on a cell by cell basis, whether its request 18
may be denied by the source BS. 19
If timer T
tgtrmv
expires, the target BS may resend the A7-Target Removal Request 21
message. 22
2.2.6 A7-Target Removal Response 23
The A7-Target Removal Response message is used by the source BS to respond to a 24
request that it deallocate resources in one or more cells currently being used for support 25
of a call association. This message can be used by the source BS to either accept or deny 26
the request by the target BS that the cells be removed from the call association. 27
When the source BS receives an A7-Target Removal Request message, it determines 29
whether to remove the indicated cells from support of the call association. Once the 30
decision has been made, the resources deallocated, and the MS instructed to remove 31
appropriate entries from its active set, the source BS responds by sending an A7-Target 32
Removal Response message to the target BS. 33
tgtrmv
. 34
TIA-2001.5-C
Section 2 26
None. 2
2.2.7 A7-Burst Request 3
The A7-Burst Request message is used by the source BS to request that a target BS 4
reserve a set of radio resources in support of a traffic burst. 5
When the source BS determines that a traffic burst is required in support of a particular 7
service instance, it determines the cells needed to support the traffic burst, sends an A7- 8
Burst Request message to the target BS, and starts timer T
bstreq
. This message requests 9
that the target BS reserve the indicated radio resources for a traffic burst beginning at a 10
particular time and for a particular duration. This message may also be used to request an 11
extension of an existing traffic burst by specifying the appropriate beginning and duration 12
times. An extension to an existing traffic burst is indicated in this message by setting the 13
start time equal to the end time of the existing traffic burst, with the same Walsh code and 14
data rate. 15
If timer T
bstreq
expires, the source BS may resend the A7-Burst Request message. The 17
A7-Burst Request message shall only contain the cells for which the source BS has not 18
received an A7-Burst Response message. 19
2.2.8 A7-Burst Response 20
The A7-Burst Response message is used by the target BS to respond to a request that it 21
reserve radio resources in one or more cells to support a traffic burst. 22
When the target BS receives an A7-Burst Request message, it determines whether it can 24
provide the requested radio resources in support of the traffic burst. If a traffic burst for 25
the same service instance was already committed (and possibly active) at the time the A7- 26
Burst Request message is received, the target BS shall examine the start time, duration, 27
and requested resources to determine if this request extends the traffic burst. The target 28
BS then creates one or more A7-Burst Response message(s) indicating its ability to 29
support the requested traffic burst for each of the cells included in the A7-Burst Request 30
message. A response shall be provided for every cell in the A7-Burst Request message. 31
There can be at most one committed cell in each A7-Burst Response message, and 32
multiple uncommitted cells. The target BS starts an instance of timer T
bstcom
for each A7- 33
Burst Response message (i.e., one timer for each cell with reserved resources). The 34
bstreq
when it receives A7-Burst Response message(s) accounting 35
for all cells that were in the A7-Burst Request message. 36
TIA-2001.5-C
27 Section 2
If timer T
bstcom
expires, the target BS shall free all radio resources reserved by the 2
committed cell included in this message. The target BS shall send an A7-Burst Release 3
message to inform the source BS that the resources were released. 4
2.2.9 A7-Burst Commit 5
The A7-Burst Commit message is sent from the source BS to the target BS to indicate the 6
target radio resources that are to be used to support a traffic burst. 7
When the source BS has gathered traffic burst commitment information from target BSs 9
and has prepared the frame selector(s) to support the traffic burst, it sends an A7-Burst 10
Commit message to the target BSs for each cell which is to support the traffic burst to 11
indicate the committed target radio resources. There can be at most in each direction one 12
committed cell in each A7-Burst Commit message. 13
Note that the source BS is not required to wait for all A7-Burst Responses before 14
committing the burst, but it shall not send an A7-Burst Commit message for a given cell 15
until after receiving the corresponding A7-Burst Response message for that cell. When 16
the target BS receives this message, it shall prepare all indicated resources for support of 17
the traffic burst. A burst time that requires the message to be pending for more than 7/8 of 18
the modulo window in the future from its time of arrival shall be considered late and the 19
message shall be processed immediately. The duration shall still be calculated from the 20
start time specified in the message. 21
If the A7-Burst Commit message indicates that only part of the resources reserved by the 22
cell are to be used for supporting the traffic burst, the remainder of the resources reserved 23
by that cell may be freed by the target BS. Note that the A7-Burst Release message (not 24
A7-Burst Commit) is sent if none of the resources that were reserved by the cell are to be 25
used to support the traffic burst. Upon receipt of the A7-Burst Commit message for a 26
given cell, the target BS stops the corresponding timer T
bstcom
. 27
None. 29
2.2.10 A7-Burst Release 30
The A7-Burst Release message is used by the source BS to request the target BS to 31
release the set of target radio resources or by the target BS to inform the source BS that 32
target radio resources have been released for one or more cells associated with a traffic 33
burst. 34
The source BS may send this message to the target BS anytime after receiving an A7- 36
Burst Response message for the included cell(s), before or during a traffic burst to 37
request release of radio resources. The target BS may send this message to the source BS 38
anytime after sending an A7-Burst Response message for the specified cell(s), before or 39
TIA-2001.5-C
Section 2 28
during a traffic burst to inform the source BS that radio resources have been released. 1
There can be multiple cells in each A7-Burst Release message. 2
Upon receipt of this message, the target (source) BS immediately terminates the burst if it 3
is in progress and releases all associated resources. 4
If timer T
bstcom
is running for a given cell when an A7-Burst Release message is received 5
from the source BS for the same cell, then the target BS shall stop timer T
bstcom
. 6
None. 8
2.2.11 A7-Reset 9
In the event of a failure or initialization at a BS that has resulted in the loss of transaction 10
reference information, an A7-Reset message is sent to other known BSs to indicate the 11
reason for the reset. 12
Upon initialization, a (first) BS shall send an A7-Reset message to other known BSs and 14
start timer T
4.
15
Upon receipt of the A7-Reset message from a BS, the receiving (second) BS releases 16
affected virtual calls and erases all affected references. After a guard period of T
2
17
seconds an A7-Reset Acknowledge message is returned to the first BS indicating that all 18
references have been cleared. 19
If timer T
4
is running at the second BS when the A7-Reset message is received from the 20
first BS, the second BS shall stop timer T
4
, start timer T
2
, complete initialization, and 21
return an A7-Reset Acknowledge message to the first BS when timer T
2
expires. 22
If a BS sends an A7-Reset message to another BS and receives no A7-Reset 24
Acknowledge message within period T
4
, then it shall repeat the entire reset procedure 25
with respect to that other BS. It is not necessary to repeat the reset procedure with respect 26
to the MSC or to other BSs. 27
If an A7-Reset message is received that contains a protocol version less than the protocol 28
version of the receiver but unknown to the receiver, then the receiver may raise an 29
OAM&P flag and choose not to respond to the sender. 30
2.2.12 A7-Reset Acknowledge 31
The A7-Reset Acknowledge message is sent in response to an A7-Reset message. 32
TIA-2001.5-C
29 Section 2
When a (second) BS has received an A7-Reset message from another (first) BS, the 2
second BS sends an A7-Reset Acknowledge message to the first BS after a guard period 3
of T
2
seconds to indicate that the A7-Reset message was received and that all references 4
have been cleared. When the first BS receives the A7-Reset Acknowledge message, it 5
stops timer T
4
if it is running and begins normal operation. 6
None. 8
2.2.13 A7-Paging Channel Message Transfer 9
The A7-Paging Channel Message Transfer message is sent by a source BS to request that 10
a particular message be sent on the specified paging channel(s). 11
When a source BS sends a message to an MS on the paging channel(s) of another BS, it 13
encapsulates that message in an A7-Paging Channel Message Transfer message and 14
sends it to the other BS. 15
A Layer 2 acknowledgment indication can be requested. If such an acknowledgment is 16
received from the MS, an A7-Paging Channel Message Transfer ACK message is used to 17
convey that information back to the source BS. If a Layer 2 acknowledgment indication 18
is requested by the source BS, it starts timer T
pcm
. 19
When a BS receives this message, it shall complete any final formatting of the contained 20
message and then send the message to the MS on the specified paging channel(s). If a 21
Layer 2 acknowledgment is requested by the source BS, the message sent to the MS shall 22
request a Layer 2 acknowledgment from the MS. 23
If timer T
pcm
expires, the source BS may send this message again, or may initiate failure 25
handling. 26
2.2.14 A7-Paging Channel Message Transfer Ack 27
The A7-Paging Channel Message Transfer Ack message is used to respond to a request 28
for a Layer 2 acknowledgment included in an A7-Paging Channel Message Transfer 29
message. 30
When an A7-Paging Channel Message Transfer message containing a request for a Layer 32
2 acknowledgment is received by a target BS, the target BS transmits the paging channel 33
message to the MS with a Layer 2 acknowledgment request included and starts its 34
internal Layer 2 timer (refer to [1]~[6]) to await the Layer 2 acknowledgment. 35
TIA-2001.5-C
Section 2 30
When a Layer 2 acknowledgment arrives from the MS, the target BS sends the A7- 1
Paging Channel Message Transfer Ack message to convey that information to the source 2
BS that had requested the Layer 2 acknowledgment. If the internal Layer 2 timer at the 3
target BS expires, this message is also sent conveying the fact that the Layer 2 4
acknowledgment time-out has occurred. When the source BS receives the A7-Paging 5
Channel Message Transfer Ack it stops timer T
pcm
if it is running. 6
None. 8
2.2.15 A7-Access Channel Message Transfer 9
The A7-Access Channel Message Transfer message is sent by a target BS to the source 10
BS to notify the source BS of the reception of an access channel message when the access 11
channel message contains an access handoff list that indicates that the receiving BS is not 12
the first accessed BS. 13
When a BS (target BS) receives an access channel message containing an access handoff 15
list that indicates that the receiving BS is not the first attempted BS (i.e., is not the source 16
BS), it shall encapsulate that message in the A7-Access Channel Message Transfer 17
message, forward it to the source BS, and start timer T
acm
. The target BS is responsible 18
for sending the Layer 2 acknowledgment for such forwarded access channel messages. 19
The source BS sends an acknowledgment for this message to the target BS using the A7- 20
Access Channel Message Transfer Ack message. 21
If timer T
acm
expires, the target BS may resend this message. 23
2.2.16 A7-Access Channel Message Transfer Ack 24
The A7-Access Channel Message Transfer Ack message is sent by the source BS to 25
acknowledge the A7-Access Channel Message Transfer message received from the target 26
BS. 27
When the source BS receives the A7-Access Channel Message Transfer message from 29
the target BS, it shall send an acknowledgment for this message to the target BS using the 30
A7-Access Channel Message Transfer Ack message. The target BS stops timer T
acm
. 31
None. 33
34
TIA-2001.5-C
31 Section 3
2
3.1 A3 Interface Message Formats 3
The A3 interface carries coded user information (voice/data) and signaling information 5
between the source BS SDU function and the channel element component (BTS) of the 6
target BS. This is a logical description of the endpoints of the A3 interface. The physical 7
endpoints are beyond the scope of this specification. 8
3.1.1 A3-Connect 9
This A3 message is sent from the target BTS to the source BS (SDU) to initiate or add 10
cells to one or more A3 user traffic connections. 11
Reference
Element
Direction
Type
Message Type II 4.2.1 BTS -> SDU M
Call Connection Reference 4.2.23 BTS -> SDU O R
Correlation ID 4.2.26 BTS -> SDU O
a
C
SDU ID 4.2.21 BTS -> SDU O
b
C
A3 Connect Information 4.2.37 BTS -> SDU O
c,d
R
A3 Traffic IP Address 4.2.62 BTS -> SDU O
e
C
a. If this element is included in this message, it shall be returned in the A3-Connect 12
Ack message. 13
b. If this element was included in the A7-Handoff Request message, it is required in 14
this message. 15
c. At least one instance of this element is required in this message. Multiple instances 16
of this element may be present in this message. If any A3 Traffic IP Address IE is 17
included, then the length of the Traffic Circuit ID field is set to zero. 18
d. If the physical channel type is SCH, then the Extended Handoff Direction Parameters 19
Field Length shall be set to 0 and the following fields shall be ignored in the Cell 20
Information Record: QOF_Mask, PWR_Comb_Ind, Pilot_PN, Code_Chan, Upper 21
QOF Mask, Lower QOF Mask, Upper Code Channel, Lower Code Channel, SR3 22
Incl. 23
e. The A3 Traffic IP Address IE contains the target BS IP address and is included if an 24
IP-Based protocol stack is used for A3 user traffic. Multiple target BS legs can be 25
added, so multiple instances of the A3 Traffic IP Address IEs can be included. The 26
instances of the A3 Traffic IP Address IE shall be in the same order and shall be in 27
one to one correspondence with the occurrences of the A3 Connect Information IE. 28
29
TIA-2001.5-C
Section 3 32
The following table shows the bitmap layout for the A3-Connect message. 1
3.1.1 A3-Connect
7 6 5 4 3 2 1 0 Octet
! !! ! Message Type II = [01H] 1
! !! ! Call Connection Reference: A3/A7 Element Identifier = [3FH] 1
Length = [08H] 2
(MSB) Market ID = <any value> 3
(LSB) 4
(MSB) Generating Entity ID = <any value> 5
(LSB) 6
(MSB) Call Connection Reference = <any value> 7
8
9
(LSB) 10
! !! ! Correlation ID: A3/A7 Element Identifier = [13H] 1
Length = [04H] 2
(MSB) Correlation Value = <any value> 3
4
5
(LSB) 6
! !! ! SDU ID: A3/A7 Element Identifier = [4CH] 1
Length = [01H to 06H] 2
(MSB) SDU ID = <any value> 3

(LSB) n
! !! ! A3 Connect Information: A3/A7 Element Identifier = [1BH] 1
Reserved = [000] Physical Channel Type
= [0H IS-95 Fundamental Channel,
1H Fundamental Channel (FCH),
2H Supplemental Channel (SCH_0),
3H Dedicated Control Channel
(DCCH),
4H Supplemental Channel (SCH_1)]
New A3
Indicator
= [0,1]
(exist,
new)
3
Length of Cell Info Record = <variable> 4
Cell I nfo Record {1+:
Cell Identification Discriminator = [07H] j
(MSB) MSCID = <any value> j+1
j+2
TIA-2001.5-C
33 Section 3
3.1.1 A3-Connect
7 6 5 4 3 2 1 0 Octet
(LSB) j+3
Reserve
d = [0]
CCS
H =
[0,1]
SR3
Incl
=
[0,1]
QOF
Mask =
[00, 01,
10, 11]
New
Cell
Indicator
= [0,1]
(old,
new)
PWR_Comb_Ind
= [0,1]
(no, yes)
(MSB) j+6
Pilot_PN = <any value> (LSB) j+7
Code Channel = [00H - FFH] j+8
Reserved = [000] Rev
FCH
Gating
= [0,1]
Lower QOF
Mask =
[00, 01, 10, 11]
Upper QOF Mask =
[00, 01, 10, 11]
j+9
Lower Code Channel = [00H - FFH] J+10
Upper Code Channel = [00H - FFH] j+11
}Cell I nfo Record
Length of Traffic Circuit ID = [00H, 05H] k
Traffic Circuit I D {0, 1:
Length of Traffic Circuit Identifier = [02H] k+1
(MSB) Traffic Circuit Identifier = <any value> k+2
(LSB) k+3
Length of Traffic Connection Identifier = [01H] k+4
Traffic Connection Identifier = [00H-FFH]
(AAL2 CID)
k+5
}Traffic Circuit I D
Extended Handoff Direction Parameters Field Length = [09H] p
Extended Handoff Direction Parameters {1+:
Search Window A Size (Srch_Win_A)
= [0H-FH]
Search Window N Size (Srch_Win_N) =
[0H-FH]
p+1
Search Window R Size (Srch_Win_R)
= [0H-FH]
Add Pilot Threshold (T_Add) high order =
[0H-FH]
p+2
T_Add (low order)
= [00-11]
Drop Pilot Threshold (T_Drop) = [000000-111111] p+3
= [0H-FH]
= [0H-FH]
p+4
TIA-2001.5-C
Section 3 34
3.1.1 A3-Connect
7 6 5 4 3 2 1 0 Octet
Neighbor Max Age
(Nghbor_Max_AGE)
= [0H-FH]
Reserved = [0000] p+5
Reserved = [00] SOFT_SLOPE = [00 0000 - 11 1111] p+6
Reserved = [00] ADD_INTERCEPT = [00 0000 - 11 1111] p+7
Reserved = [00] DROP_INTERCEPT = [00 0000 - 11 1111] p+8
Target BS P_REV = [00H FFH] p+9
}Extended Handoff Direction Parameters
Length of Channel Element ID = <variable> Q
(MSB) Channel Element ID = <any value> q+1

(LSB) r
A3 Originating I D {1+:
Length of A3 Originating ID = [00H - 08H] r
(MSB) A3 Originating ID = <any value> r+1

(LSB) S
}A3 Originating I D
! !! ! A7 Destination ID: A3/A7 Element Identifier = [2DH] s+1
Length of A7 Destination ID = [00H - 08H] s+2
(MSB) A7 Destination ID = <any value> s+3

(LSB) t
}A3 Connect I nformation
! !! ! A3 Traffic IP Address: A3/A7 Element Identifier = [71H] 1
Length = [07H] 2
Address Type = [01H (IPv4)] 3
(MSB) 4
IP Address = <any value> 5
6
(LSB) 7
(MSB) Port = [0000H-FFFFH] 8
(LSB) 9
1
TIA-2001.5-C
35 Section 3
3.1.2 A3-Connect Ack 1
This A3 channel message is sent from the source BS (SDU) to the target BS (BTS) to 2
indicate the result of processing the A3-Connect message. 3
Reference
Element
Direction
Type
Message Type II 4.2.1 SDU -> BTS M
Call Connection Reference 4.2.23 SDU -> BTS O R
Correlation ID 4.2.26 SDU -> BTS O
a
C
A3 Connect Ack Information 4.2.38 SDU -> BTS O
b
R
A3 Traffic IP Address 4.2.62 SDU -> BTS O
c
C
a. If this element was included in the A3-Connect message, the value shall be returned 4
in this message. 5
b. One instance of this element shall appear in this message for each corresponding A3 6
Connect Information element in the A3-Connect message that is being responded to. 7
If any A3 Traffic IP Address IE is included, then the length of the Traffic Circuit ID 8
field is set to zero. 9
c. The A3 Traffic IP Address IE is included if an IP-Based protocol stack is used for 10
A3 user traffic. N+1 instances of the A3 Traffic IP Address IE shall be included, 11
where N is the number of instances of the A3 Connect Ack Information IE in this 12
message. The first N instances of the A3 Traffic IP Address IE each contain a target 13
BS IP address and shall be in the same order and shall be in one to one 14
correspondence with the occurrences of the A3 Connect Ack Information IE. The 15
N+1th instance of the A3 Traffic IP Address IE contains the source BS IP address 16
and shall be included after the instances containing the target BS IP addresses. 17
The following table shows the bitmap layout for the A3-Connect Ack message. 18
3.1.2 A3-Connect Ack
7 6 5 4 3 2 1 0 Octet
Length = [08H] 2
(LSB) 4
(LSB) 6
8
9
(LSB) 10
Length = [04H] 2
TIA-2001.5-C
Section 3 36
7 6 5 4 3 2 1 0 Octet
4
5
(LSB) 6
! !! ! A3 Connect Ack Information{1+: A3/A7 Element Identifier = [1CH] 1
Reserved = [00] Soft Handoff Leg #
= [0000 to 1111]
PMC
Cause
Present
= [1]
(yes)
xmit
notify
(send
A3-TCH
Status)
= [0,1]
(no, yes)
3
(LSB) k+3
(AAL2 CID)
k+5
Length of Channel Element ID = <variable> j
(MSB) Channel Element ID = <any value> j+1

(LSB) k
PMC Cause =
[00H (No error),
02H (Already connected),
03H (Illegal A3 connect),
0AH (No resources available)]
k+1
A3 Originating I D {1+:
Length of A3 Originating ID = [00H - 08H] p
(MSB) A3 Originating ID = <any value> p+1

(LSB) q
}A3 Originating I D
TIA-2001.5-C
37 Section 3
7 6 5 4 3 2 1 0 Octet
A3 Destination I D {1+:
Length of A3 Destination ID = [00H - 08H] r
(MSB) A3 Destination ID = <any value> r+1

(LSB) s
}A3 Destination I D
}A3 Connect Ack I nformation
Length = [07H] 2
(MSB) 4
6
(LSB) 7
(LSB) 9
1
TIA-2001.5-C
Section 3 38
3.1.3 A3-Remove 1
This A3 message is sent from the target BS (BTS) to the source BS (SDU) to request that 2
cells be removed from the A3 connections identified in this message. 3
Reference
Element
Direction
Type
Correlation ID 4.2.26 BTS -> SDU O
a
C
b
C
A3 Remove Information 4.2.39 BTS -> SDU O
c
R
A3 Traffic IP Address 4.2.62 BTS -> SDU O
d
C
a. If this element is included in this message, the value shall be returned in the A3- 4
Remove Ack message. 5
b. If this element was included in the A7-Handoff Request message, it is required in 6
this message. 7
c. At least one instance of this element shall appear in this message. Multiple instances 8
of this element may be present in this message. Each instance of this element 9
pertains to one A3 traffic connection. If any A3 Traffic IP Address IE is included, 10
then the Length of the Traffic Circuit ID field is set to zero. 11
d. The A3 Traffic IP Address IE contains the target BS IP address and is included if an 12
added, so multiple instances of the A3 Traffic IP Address IE can be included. The 14
one to one correspondence with the occurrences of the A3 Remove Information IE. 16
The following table shows the bitmap layout for the A3-Remove message. 17
3.1.3 A3-Remove
7 6 5 4 3 2 1 0 Octet
Length = [08H] 2
(LSB) 4
(LSB) 6
8
9
(LSB) 10
Length = [04H] 2
TIA-2001.5-C
39 Section 3
3.1.3 A3-Remove
7 6 5 4 3 2 1 0 Octet
4
5
(LSB) 6

(LSB) n
! !! ! A3 Remove Information: A3/A7 Element Identifier = [20H] 1
(LSB) k+3
(AAL2 CID)
k+5
Number of Cells to be Removed = <any value> 1
Cell I dentifier {1+:
4
(LSB) 5
}Cell I dentifier
Length of A3 Destination ID = [00H - 08H] q
(MSB) A3 Destination ID = <any value> q+1

(LSB) r
}A3 Destination I D
TIA-2001.5-C
Section 3 40
3.1.3 A3-Remove
7 6 5 4 3 2 1 0 Octet
Length of A7 Destination ID = [00H - 08H] s
(MSB) A7 Destination ID = <any value> s+1

(LSB) t
}A3 Remove I nformation
Length = [07H] 2
(MSB) 4
6
(LSB) 7
(LSB) 9
1
TIA-2001.5-C
41 Section 3
3.1.4 A3-Remove Ack 1
This A3 message is sent from the source BS (SDU) to the target BS (BTS) to 2
acknowledge completion of the request to remove cells from A3 connections. 3
Reference
Element
Direction
Type
Correlation ID 4.2.26 SDU -> BTS O
a
C
A3 Destination ID 4.2.45 SDU -> BTS O
b
C
c
C
Cause 4.2.4 SDU -> BTS O
d
C
a. If this element was included in the A3-Remove message, the value shall be returned 4
in this message. 5
b. For each instance of the A3 Remove Information element in the A3-Remove 6
message, an instance of the A3 Destination ID element shall be included in this 7
message if the A3 Originating ID field was included in the A3 Connect Information 8
element of the A3-Connect message that established the corresponding traffic 9
connection. 10
c. If the A7 Originating ID element was included in the corresponding A7-Handoff 11
Request message, and the A3 Flag field was set to 1, then the A7 Destination ID 12
element shall be included in this message and contain the value of the A7 13
Originating ID. 14
d. This information element is included when the Call Connection Reference value that 15
was received in the A3-Remove message is invalid. 16
The following table shows the bitmap layout for the A3-Remove Ack message. 17
3.1.4 A3-Remove Ack
7 6 5 4 3 2 1 0 Octet
Length = [08H] 2
(LSB) 4
(LSB) 6
8
9
(LSB) 10
Length = [04H] 2
TIA-2001.5-C
Section 3 42
3.1.4 A3-Remove Ack
7 6 5 4 3 2 1 0 Octet
4
5
(LSB) 6
! !! ! A3 Destination ID: A3/A7 Element Identifier = [55H] 1
Length of A3 Destination ID = [01H - 08H] 2
(MSB) A3 Destination ID = <any value> 3

(LSB) m
}A3 Destination I D
! !! ! A7 Destination ID: A3/A7 Element Identifier = [2DH] n+1
Length of A7 Destination ID = [01H - 08H] n+2
(MSB) A7 Destination ID = <any value> n+3

(LSB) p
! !! ! Cause: A3/A7 Element Identifier = [08H] 1
Length = [01H] 2
ext =
[0]
Cause Value =
[6FH (Invalid call connection reference)]
3
1
TIA-2001.5-C
43 Section 3
3.1.5 A3-Drop 1
This optional A3 message is sent to notify a target BS (BTS) that the A3 traffic 2
subchannel is about to be dropped. 3
Reference
Element
Direction
Type
A3 Drop Information 4.2.40 SDU -> BTS O
a
R
Cause List 4.2.35 SDU -> BTS O
b
R
c
C
a. One instance of this element shall appear in this message for each A3 connection that 4
is being dropped by the SDU function. If any A3 Traffic IP Address IE is included, 5
then the length of the Traffic Circuit ID field is set to zero. 6
b. The items in this list shall be in the same order and shall be in one to one 7
correspondence with the occurrences of the A3 Drop Information element. Each 8
entry indicates the reason for dropping the associated A3 connection. 9
c. The A3 Traffic IP Address IE contains the target BS IP address and is included if an 10
dropped, so multiple instances of the A3 Traffic IP Address IE can be included. The 12
one to one correspondence with the occurrences of the A3 Drop Information IE. 14
The following table shows the bitmap layout for the A3-Drop message. 15
3.1.5 A3-Drop
7 6 5 4 3 2 1 0 Octet
Length = [08H] 2
(LSB) 4
(LSB) 6
8
9
(LSB) 10
! !! ! A3 Drop Information: A3/A7 Element Identifier = [1EH] 1
Length of Traffic Circuit ID = [00H, 05H] 3
Traffic Circuit I D {0,1:
TIA-2001.5-C
Section 3 44
3.1.5 A3-Drop
7 6 5 4 3 2 1 0 Octet
Length of Traffic Circuit Identifier = [02H] 4
(MSB) Traffic Circuit Identifier = <any value> 5
(LSB) 6
Length of Traffic Connection Identifier = [01H] 7
(AAL2 CID)
8
Length of Channel Element ID = <variable> 9
(MSB) Channel Element ID = <any value> 10

(LSB) k
Length of A3 Destination ID = [00H - 08H] m
(MSB) A3 Destination ID = <any value> m+1

(LSB) n
}A3 Destination I D
}A3 Drop I nformation
! !! ! Cause List: A3/A7 Element Identifier = [19H] 1
Cause Value {1+:
Reserved
= [0]
Cause Value =
12H (Invalid call),
p
}Cause Value
Length = [07H] 2
(MSB) 4
6
(LSB) 7
(LSB) 9
1
TIA-2001.5-C
45 Section 3
3.1.6 A3-Propagation Delay Measurement Report 1
This A3 message is sent from the target BS (BTS) to the source BS (SDU) immediately 2
following the acquisition of the MS and subsequently whenever the delay changes by two 3
or more PN chips. 4
Reference
Element
Direction
Type
One Way Propagation Delay Record 4.2.28 BTS -> SDU O R
a
C
A3 Destination ID 4.2.45 BTS -> SDU O
b
C
c
C
a. If this element was included in the A7-Handoff Request message, it is required in 5
this message. 6
b. If the A3 Originating ID field was included in the corresponding A3 Connect Ack 7
Information element of an A3-Connect Ack message that established the traffic 8
connection for the cell, then the A3 Destination ID element shall contain this 9
information and be included in this message. 10
Originating ID. 14
The following table shows the bitmap layout for the A3-Propagation Delay Measurement 15
Report message. 16
3.1.6 A3-Propagation Delay Measurement Report
7 6 5 4 3 2 1 0 Octet
Length = [08H] 2
(LSB) 4
(LSB) 6
8
9
(LSB) 10
! !! ! One Way Propagation Delay Record: A3/A7 Element Identifier = [09H] 1
Length = [08H] 2
TIA-2001.5-C
Section 3 46
3.1.6 A3-Propagation Delay Measurement Report
7 6 5 4 3 2 1 0 Octet
5
(LSB) 6
(MSB) CDMA Serving One Way Delay = [0000H-FFFFH] (x100ns) 9
(LSB) 10

(LSB) n

(LSB) p
! !! ! A7 Destination ID: A3/A7 Element Identifier = [2DH] 1

(LSB) q
1
TIA-2001.5-C
47 Section 3
3.1.7 A3-Physical Transition Directive 1
This A3 message is sent from the source BS (SDU) to the target BS (BTS). It conveys a 2
change to an allocated physical channel at the target BS (BTS) as well as the time of 3
execution for the change. This message shall be sent once for each A3 traffic connection 4
for the same MS. 5
Reference
Element
Direction
Type
CDMA Long Code Transition Info 4.2.31 SDU -> BTS O
c
C
Channel Element ID 4.2.32 SDU -> BTS O
a, b
C
Privacy Info 4.2.36 SDU -> BTS O
g
C
A3 Traffic Circuit ID 4.2.22 SDU -> BTS O
b
C
Reverse Pilot Gating Rate 4.2.8 SDU -> BTS O
d
C
IS-2000 Forward Power Control Mode 4.2.47 SDU -> BTS O
e
C
f
C
IS-2000 Power Control Info 4.2.46 SDU -> BTS O
h
C
IS-2000 FPC Gain Ratio Info 4.2.48 SDU -> BTS O
i
C
b,j
C
a. If this element was included in the A3-Connect message, its value shall be included 6
in this element. 7
b. Only one of the following IEs shall be present in this message Channel Element ID, 8
A3 Traffic Circuit ID, or A3 Traffic IP Address element. 9
c. This element shall be included when the purpose of this message is to cause a change 10
to the long code key in use for encrypting the physical channel. If the Privacy Info 11
element is not present, then the Private Long Code Mask value most recently 12
received in A7-Handoff Request shall apply. 13
d. This element shall be included when the purpose of this message is to cause a change 14
in the pilot gating rate of the physical channel. 15
e. This element shall be included when the purpose of this message is to cause a change 16
in the forward power control mode. 17
f. If the A3 Originating ID field was included in the corresponding A3 Connect 18
Information element of an A3-Connect message that established the traffic 19
connection, then the A3 Destination ID element shall contain this information and be 20
included in this message.Each instance of this element corresponds to one cell in the 21
Cell Identifier List. 22
g. This element shall be included when the source BS informs the target BS of a new 23
Private Long Code Mask value. 24
h. This element shall be included when the purpose of this message is to cause a change 25
in the Mobile Pilot Gain (FPC_PRI_CHAN and FPC_SUBCHAN_GAINs), for the 26
physical channel (FCH or DCCH) measured by the primary power control 27
subchannel. The action time is immediate. 28
TIA-2001.5-C
Section 3 48
i. This element shall be included when the purpose of this message is to cause a change 1
in the Initial Gain Ratio, Gain Adjust Step Size or Min/Max Gain Ratios for the 2
physical channel (FCH or DCCH) measured by the primary power control 3
subchannel. The action time is immediate. 4
j. The A3 Traffic IP Address IE contains the target IP address and is included if an IP- 5
Based protocol stack is used for A3 user traffic. 6
The following table shows the bitmap layout for the A3-Physical Transition Directive 7
message. 8
3.1.7 A3-Physical Transition Directive
7 6 5 4 3 2 1 0 Octet
Length = [08H] 2
(LSB) 4
(LSB) 6
8
9
(LSB) 10
! !! ! CDMA Long Code Transition Info: A3/A7 Element Identifier = [0EH] 1
Length = [02H] 2
Reserved = [0000000] LCM_TYPE
= [0,1]
(public,
private)
3
ACTION_TIME = [00H-FFH] 4
! !! ! Channel Element ID: A3/A7 Element Identifier = [17H] 1
(MSB) Channel Element ID = <any value> 3

(LSB) m
! !! ! Privacy Info: A3/A7 Element Identifier = [1DH] 1
Length = [08H] 2
Reserved
= [0]
Privacy Mask Type = [00010] (private) Status
= [0,1]
Available
= [0,1]
3
Privacy Mask Length = [06H] 4
(MSB) Privacy Mask = <any value> 5
TIA-2001.5-C
49 Section 3
7 6 5 4 3 2 1 0 Octet

(LSB) 10
! !! ! A3 Traffic Circuit ID: A3/A7 Element Identifier = [00H, 03H] 1
Length = [05H] 2
Length of Traffic Circuit Identifier = [02H] 3
(MSB) Traffic Circuit Identifier = <any value> 4

(LSB) 5
Length of Traffic Connection Identifier = [01H] 6
(AAL2 CID)
7
! !! ! Reverse Pilot Gating Rate: A3/A7 Element Identifier = [06H] 1
Length = [02H] 2
Reserved = [0000 00] Pilot Gating Rate
= [00, 01, 10]
3
ACTION_TIME = [00H FFH] 4
! !! ! IS-2000 Forward Power Control Mode: A3/A7 Element Identifier = [14H] 1
Length = [02H] 2
Reserved = [0000 0] FPC_MODE = [000 110] 3
Action
Time
Flag
= [0,1]
Reserved
= [0]
ACTION_TIME = [00 0000 11 1111] 4

(LSB) k
}A3 Destination I D
! !! ! IS-2000 Power Control Info: A3/A7 Element Identifier = [0BH] 1
Length = [05H] 2
FPC_
PRI_
CHAN =
[0,1]
Rese
rved
= [0]
Rev_Pwr_
Cntl_Dela
y_Incl =
[0,1]
Rev_Pwr_Cntl_Delay
=
[00 11]
Count of Subchan Gains =
[011]
3
Reserved = [000] FPC_SUBCHAN_GAIN 1 = [0 0000 1 1111] 4
TIA-2001.5-C
Section 3 50
7 6 5 4 3 2 1 0 Octet
! !! ! IS-2000 FPC Gain Ratio Info: A3/A7 Element Identifier = [15H] 1
Length = [08H] 2
Initial Gain Ratio = [00H FFH] 3
Reserved
= [0]
Gain Adjust Step Size = [0H FH] Count of Gain Ratio Pairs =
[011]
4
Min Gain Ratio 1 = [00H FFH] 5
Max Gain Ratio 1 = [00H FFH] 6
Length = [07H] 2
(MSB) 4
6
(LSB) 7
(LSB) 9
1
2
TIA-2001.5-C
51 Section 3
3.1.8 A3-Physical Transition Directive Ack 1
This A3 signaling message is sent from the target BS (BTS) to the source BS (SDU) 2
interface to convey the outcome of processing an A3-Physical Transition Directive. 3
Reference
Element
Direction
Type
Cell Identifier List (Committed) 4.2.6 BTS -> SDU O
f
C
a
C
PMC Cause 4.2.24 BTS -> SDU O
b
C
Cell Identifier List (Uncommitted) 4.2.6 BTS -> SDU O
c
C
d
C
e
C
this message. 5
b. Allowable PMC Cause values are: Private long code not available or not supported, 6
Requested reverse pilot gating rate not supported, Requested FPC mode change 7
failed. 8
c. This element shall be included when the PMC Cause element is present. 9
d. If the A3 Originating ID field was included in the corresponding A3 Connect Ack 10
connection for these cells, then the A3 Destination ID element shall contain this 12
information and be included in this message. Each instance of this element 13
corresponds to one cell in the Cell Information Record (Committed) or 14
(Uncommitted). 15
e. If the A7 Originating ID element was included in the corresponding A7-Handoff 16
Originating ID. 19
f. This information element contains the list of cells which were able to accommodate 20
the change proposed in the A3-Physical Transition Directive message. 21
The following table shows the bitmap layout for the A3-Physical Transition Directive 22
Ack message. 23
3.1.8 A3-Physical Transition Directive Ack
7 6 5 4 3 2 1 0 Octet
! !! ! Message Type II = [0AH] 1
Length = [08H] 2
(LSB) 4
TIA-2001.5-C
Section 3 52
7 6 5 4 3 2 1 0 Octet
(LSB) 6
8
9
(LSB) 10
! !! ! Cell Identifier List (Committed): A3/A7 Element Identifier = [1AH] 1
Cell I dentification {1+:
j+1
(LSB) j+2

(LSB) n
! !! ! PMC Cause: A3/A7 Element Identifier = [05H] 1
Length = [01H] 2
PMC Cause Value =
[05H (Requested reverse pilot gating rate not supported),
08H (Requested FPC mode change failed),
0DH (Private long code not available or not supported),
0FH (Requested privacy configuration unavailable)]
3
! !! ! Cell Identifier List (Uncommitted): A3/A7 Element Identifier = [1AH] 1
j+1
(LSB) j+2
TIA-2001.5-C
53 Section 3
7 6 5 4 3 2 1 0 Octet

(LSB) k
}A3 Destination I D

(LSB) k
1
TIA-2001.5-C
Section 3 54
3.1.9 A3-Traffic Channel Status 1
This A3 message is sent from the target BS (BTS) to the source BS (SDU) to provide 2
status information with respect to one or more cells on an A3 connection. 3
Reference
Element
Direction
Type
Cell Identifier List 4.2.6 BTS -> SDU O R
Channel Element Status 4.2.34 BTS -> SDU O R
a
C
b
C
c
C
this message. 5
b. If the A3 Originating ID field was included in the corresponding A3 Connect Ack 6
connection for these cells, then the A3 Destination ID element shall contain this 8
information and be included in this message. Each instance of this element 9
corresponds to one cell in the Cell Identifier List. 10
Originating ID. 14
The following table shows the bitmap layout for the A3-Traffic Channel Status message. 15
3.1.9 A3-Traffic Channel Status
7 6 5 4 3 2 1 0 Octet
! !! ! Message Type II = [0DH] 1
Length = [08H] 2
(LSB) 4
(LSB) 6
8
9
(LSB) 10
! !! ! Cell Identifier List: A3/A7 Element Identifier = [1AH] 1
TIA-2001.5-C
55 Section 3
3.1.9 A3-Traffic Channel Status
7 6 5 4 3 2 1 0 Octet
j+1
(LSB) j+2
! !! ! Channel Element Status: A3/A7 Element Identifier = [18H] 1
Length = [01H] 2
Reserved = [0000000] Xmit On
= [0,1]
(Off, On)
3

(LSB) n

(LSB) k
}A3 Destination I D

(LSB) k
1
TIA-2001.5-C
Section 3 56
This A3 message is sent from the source BS (SDU) to the target BS (BTS) over A3 IS-95 2
user traffic subchannels of type IS-95 FCH (TIA/EIA/IS-95 Fundamental Channel). It is 3
used to send a Forward Traffic Channel frame to the target BS (BTS) for transmission to 4
the MS. This message includes the entire Forward Traffic Channel frame and some 5
control information. 6
Note: This message is the same as the A3-CEData Forward message in previous versions 7
of this standard. The name was changed to differentiate it from the A3-IS-2000 FCH 8
Forward message. 9
Reference
Element
Direction
Type
Forward Layer 3 Data 4.2.29 SDU -> BTS M
Message CRC 4.2.33 SDU -> BTS M
The following table shows the bitmap layout for the A3-IS-95 FCH Forward message. 10
3.1.10 A3-IS-95 FCH Forward
7 6 5 4 3 2 1 0 Octet
! !! ! Forward Layer 3 Data {1:
Reserved = [0000]

Sequence Number = [0000-1111] 1
Forward Traffic Channel Gain = [00H-80H] 2
Reverse Traffic Channel E
w
/N
t
= [00H-0FFH] 3
Rate Set Indicator = [0H,1H] Forward Traffic Channel Rate = [0H-3H] 4
Reserved = [0000] Power Control Subchannel Count = [1H-6H] 5
(MSB) Forward Traffic Channel Information + Layer 3 Fill = <any value> 6

(LSB) n
}Forward Layer 3 Data
(MSB) ! !! ! Message CRC = [0000H-FFFFH] 1
(LSB) 2
11
TIA-2001.5-C
57 Section 3
This A3 message is sent from the target BS (BTS) to the source BS over A3 user traffic 2
subchannels of type IS-95 FCH (TIA/EIA/IS-95 Fundamental Channel). It is used by 3
the target BS (BTS) to send a decoded Reverse Traffic Channel Frame and control 4
information. 5
This message is the same as the A3-CEData Reverse message in previous versions of this 6
standard. The name was changed to differentiate it from the A3-IS-2000 FCH Reverse 7
message. 8
Reference
Element
Direction
Type
Reverse Layer 3 Data 4.2.30 BTS -> SDU M
Message CRC 4.2.33 BTS -> SDU M
The following table shows the bitmap layout for the A3-IS-95 FCH Reverse message. 9
3.1.11 A3-IS-95 FCH Reverse
7 6 5 4 3 2 1 0 Octet
! !! ! Reverse Layer 3 Data {1:

Soft Handoff Leg #
= [0000 - 1111]
Sequence Number = [0000-1111] 1
Reverse Traffic Channel Quality = [00H-FFH] 2
Scaling = [00-11] Packet Arrival Time Error = [000000-111111] 3
Rate Set Indicator = [0H,1H] Reverse Traffic Channel Rate = [0H-6H] 4
Reserved = [0000] EIB =
[0,1]
5
(MSB) Reverse Traffic Channel Information + Layer 3 Fill = <any value> 6

(LSB) n
}Reverse Layer 3 Data
(MSB) ! !! ! Message CRC = [0000H-FFFFH] m
(LSB) m+1
10
11
TIA-2001.5-C
Section 3 58
This A3 message is sent from the source BS (SDU) to the target BS (BTS) over A3 IS- 2
2000 user traffic subchannels of type IS-2000 FCH (cdma2000
Fundamental 3
Channel). It is used to send a Forward Link air-frame to the target BS (BTS) for 4
transmission to the MS. This message includes the entire Forward Link air-frame data 5
and some control information. FCH Forward messages are not to be suppressed due to 6
streaming gain-settings required for EIB-based power control. 7
Reference
Element
Direction
Type
Forward Layer 3 IS-2000 FCH/DCCH Data 4.2.14 SDU -> BTS M
The following table shows the bitmap layout for the A3-IS-2000 FCH Forward messages. 8
3.1.12 A3-IS-2000 FCH Forward
7 6 5 4 3 2 1 0 Octet
! !! ! Message Type II = [0BH] 1
! !! ! Forward Layer 3 I S-2000 FCH/DCCH Data {1:
FPC: SLC = [0001 to 0110] FSN = [0000 to 1111] 1
FPC: GR = [00H - FFH] 2
RPC: OLT = [00H - FFH] 3
IS-2000 Frame Content = [00H-08H, 0AH-12H] 4
(MSB) Forward Link Information + Layer 3 Fill = <any value> 5

(LSB) n
}Forward Layer 3 I S-2000 FCH/DCCH Data
(LSB) 2
9
10
TIA-2001.5-C
59 Section 3
This A3 message is sent from the target BS (BTS) to the source BS (SDU) over A3 IS- 2
Fundamental 3
Channel). It is used by the target BS (BTS) to send a decoded Reverse Link air-frame and 4
control information to the source BS (SDU). IS-2000 FCH Reverse messages are not to 5
be suppressed due to streaming feedback required for EIB-based power control. 6
Reference
Element
Direction
Type
Message Type II 4.2.1 BTS->SDU M
Reverse Layer 3 IS-2000 FCH/DCCH Data 4.2.15 BTS->SDU M
Message CRC 4.2.33 BTS->SDU M
The following table shows the bitmap layout for the A3-IS-2000 FCH Reverse message. 7
3.1.13 A3-IS-2000 FCH Reverse
7 6 5 4 3 2 1 0 Octet
! !! ! Message Type II = [0CH] 1
! !! ! Reverse Layer 3 I S-2000 FCH/DCCH Data {1:
Soft Handoff Leg #
= [0000 - 1111]
FSN = [0000 to 1111] 1
FQI
= [0,1]
Reverse Link Quality
= [000 0000 111 1111]
2
Scaling
= [00 11]
Packet Arrival Time Error
= [00 0000 11 1111]
3
IS-2000 Frame Content = [00H-08H, 0AH-12H, 7DH, 7EH] 4
RPC: S = [0000 000 1111 111] QIB/EIB
= [0,1]
5
(MSB) Reverse Link Information + Layer 3 Fill = <any value> 6

(LSB) n
}Reverse Layer 3 I S-2000 FCH/DCCH Data
(LSB) 2
8
9
TIA-2001.5-C
Section 3 60
3.1.14 A3-IS-2000 DCCH Forward 1
2000 user traffic subchannels of type IS-2000 DCCH (cdma2000
Dedicated Control 3
transmission to the MS. This message includes the entire Forward Link air-frame data 5
and some control information. IS-2000 DCCH Forward messages are not to be 6
suppressed due to streaming gain-settings required for EIB-based power control. 7
Reference
Element
Direction
Type
Forward Layer 3 IS-2000 FCH/DCCH Data 4.2.14 SDU -> BTS M
The following table shows the bitmap layout for the A3-IS-2000 DCCH Forward 8
messages. 9
3.1.14 A3-IS-2000 DCCH Forward
7 6 5 4 3 2 1 0 Octet
! !! ! Message Type II = [0EH] 1
! !! ! Forward Layer 3 I S-2000 FCH/DCCH Data {1:
FPC: SLC = [0001 to 0110] FSN = [0000 to 1111] 1
FPC: GR = [00H - FFH] 2
IS-2000 Frame Content = [00H, 20H, 21H, 7FH] 4

(LSB) n
}Forward Layer 3 I S-2000 FCH/DCCH Data
(LSB) 2
10
11
TIA-2001.5-C
61 Section 3
3.1.15 A3-IS-2000 DCCH Reverse 1
Dedicated Control 3
control information to the source BS (SDU). IS-2000 DCCH Reverse messages are not to 5
be suppressed due to streaming feedback required for EIB-based power control. 6
Reference
Element
Direction
Type
Reverse Layer 3 IS-2000 FCH/DCCH Data 4.2.15 BTS -> SDU M
The following table shows the bitmap layout for the A3-IS-2000 DCCH Reverse 7
message: 8
3.1.15 A3-IS-2000 DCCH Reverse
7 6 5 4 3 2 1 0 Octet
! !! ! Message Type II = [0FH] 1
! !! ! Reverse Layer 3 I S-2000 FCH/DCCH Data {1:
Soft Handoff Leg #
= [0000 - 1111]
FSN = [0000 to 1111] 1
FQI
= [0,1]
= [000 0000 111 1111]
2
Scaling
= [00 11]
= [00 0000 11 1111]
3
IS-2000 Frame Content = [00H, 20H, 21H, 7EH, 7FH] 4
RPC: S = [0000 000 1111 111] QIB/EIB
= [0,1]
5

(LSB) n
}Reverse Layer 3 I S-2000 FCH/DCCH Data
(LSB) 2
9
10
TIA-2001.5-C
Section 3 62
3.1.16 A3-IS-2000 SCH Forward 1
2000 user traffic subchannels of type IS-2000 SCH (cdma2000
Supplemental 3
transmission to the MS. This message includes the entire Forward Link air-frame and 5
some control information. 6
Reference
Element
Direction
Type
Forward Layer 3 IS-2000 SCH Data 4.2.16 SDU -> BTS M
The following table shows the bitmap layout for the A3-IS-2000 SCH Forward message. 7
3.1.16 A3-IS-2000 SCH Forward
7 6 5 4 3 2 1 0 Octet
! !! ! Forward Layer 3 I S-2000 SCH Data {1:
FPC: SLC = [0001 to 0110] FSN = [0000 to 1111] 1
FPC: GR = [00H FFH] 2
IS-2000 Frame Content = [00H, 32H 36H, 3DH 40H, 7FH] 3

(LSB) n
}Forward Layer 3 I S-2000 SCH Data
(LSB) 2
8
9
TIA-2001.5-C
63 Section 3
3.1.17 A3-IS-2000 SCH Reverse 1
Supplemental 3
control information. The target BS (BTS) may use the A3-IS-2000 SCH Reverse 5
Message to send Idle frames to the source BS (SDU) for the purpose of synchronization 6
of the A3 link. 7
Reference
Element
Direction
Type
Reverse Layer 3 IS-2000 SCH Data 4.2.17 BTS -> SDU M
The following table shows the bitmap layout for the A3-IS-2000 SCH Reverse message. 8
3.1.17 A3-IS-2000 SCH Reverse
7 6 5 4 3 2 1 0 Octet
! !! ! Reverse Layer 3 I S-2000 SCH Data {1:
Soft Handoff Leg #
= [0000 - 1111]
FSN = [0000 to 1111] 1
FQI
= [0,1]
= [000 0000 111 1111]
2
Scaling
= [00 11]
= [00 0000 11 1111]
3
IS-2000 Frame Content = [00H, 32H 36H, 3DH 40H, 7EH, 7FH] 4

(LSB) n
}Reverse Layer 3 I S-2000 SCH Data
(LSB) 2
9
10
TIA-2001.5-C
Section 3 64
3.1.18 A3-FCH Forward Traffic Frame 1
Fundamental 3
Channel). It may be used to send up to one 20 ms forward traffic channel frame and up to 4
four 5 ms forward traffic channel frames to the target BS (BTS) for transmission to the 5
MS during the specified 20 ms interval. This message also contains control information 6
associated with the 20 ms interval. One and only one A3-FCH Forward Traffic Frame 7
message is sent for each 20 ms interval. This A3 message is only used if a 5 ms signaling 8
message is being sent to the BTS. If no 5 ms signaling message is to be included, the A3- 9
IS-2000 FCH Forward message (3.1.12) should be used instead. This A3 message may 10
also be used to send a 20 ms traffic frame without a 5 ms signaling message if agreed to 11
by both vendors. This message shall not be sent to implementations running a version of 12
the IOS earlier than V4.1. 13
Reference
Element
Direction
Type
FCH/DCCH Forward Air Interval Control 4.2.49 SDU -> BTS O R
Forward 20 ms Data 4.2.52 SDU -> BTS O
a,c
C
b,c
C
Message CRC 4.2.33 SDU -> BTS O R
a. This information element is included when a 20 ms forward FCH traffic channel 14
frame is to be sent in the 20 ms interval. 15
b. This information element is used to support 5 ms signaling messages. This 16
information element is included when a 5 ms forward traffic channel frame is to be 17
sent in the 20 ms interval. Up to four instances of this element may be present in this 18
message in order of transmission over the air interface, as indicated by the Air 19
Interval Content Mask in the FCH/DCCH Forward Air Interval Control element. If 20
four instances of this information element are present, then the Forward 20 ms Data 21
Information element shall not be present. 22
c. At least one instance of either the Forward FCH 20 ms Data or the 5 ms Data 23
information element shall be present, unless the IS-2000 Frame Content type in the 24
FCH/DCCH Forward Air Interval Control element is set to Null or Idle. 25
The following table shows the bitmap layout for the A3-FCH Forward Traffic Channel 26
Frame. 27
3.1.18 A3-FCH Forward Traffic Frame
7 6 5 4 3 2 1 0 Octet
! !! ! FCH/DCCH Forward Air I nterval Control {1:
FPC:SLC = [0001 to 0110] FSN = [0000 to 1111] 1
FPC: GR = [00H - FFH] 2
IS-2000 Frame Content = [00H-08H, 0AH-12H, 7FH] 4
Reserved = [000] Air Interval Content Mask = [0 0000 1 1110] 5
TIA-2001.5-C
65 Section 3
3.1.18 A3-FCH Forward Traffic Frame
7 6 5 4 3 2 1 0 Octet
}FCH/DCCH Forward Air I nterval Control
! !! ! Forward 20 ms Data {0..1:

(LSB) n
}Forward 20 ms Data
(MSB) Forward Link Information = <000000H-FFFFFFH> k
k+1
(LSB) k+2
}Forward 5 ms Data
(LSB) 2
1
2
TIA-2001.5-C
Section 3 66
3.1.19 A3-FCH Reverse Traffic Frame 1
Fundamental 3
Channel). It is used by the target BS (BTS) to send up to one 20 ms decoded reverse link 4
traffic channel frame and up to four 5 ms decoded reverse link traffic channel frames and 5
control information to the source BS (SDU) for a given 20 ms interval. This message is 6
not to be suppressed due to streaming feedback required for EIB-based power control. 7
One and only one A3-FCH Reverse Traffic Frame message is sent for each 20 ms 8
interval. This A3 message is only used if a 5 ms signaling message has been received 9
from the BTS. If no 5 ms signaling message is to be included, the A3-IS-2000 FCH 10
Reverse message (3.1.13) should be used instead. This A3 message may also be used to 11
send a 20 ms traffic frame without a 5 ms signaling message if agreed to by both vendors. 12
This message shall not be sent to implementations running a version of the IOS earlier 13
than V4.1. 14
Reference
Element
Direction
Type
FCH/DCCH Reverse Air Interval Control 4.2.50 BTS->SDU O R
Reverse 20 ms Data 4.2.53 BTS->SDU O
a,c
C
b,c
C
Message CRC 4.2.33 BTS->SDU O R
a. This information element is included when a 20 ms reverse FCH traffic channel 15
frame is decoded in the 20 ms interval. 16
information element is included when a 5 ms reverse traffic channel frame is 18
decoded in the 20 ms interval. Up to four instances of this element may be present in 19
this message in order of reception over the air interface, as indicated by the Air 20
Interval Content Mask in the FCH/DCCH Reverse Air Interval Control element. If 21
c. At least one instance of either the Reverse 20 ms Data or the Reverse 5 ms Data 24
FCH/DCCH Reverse Air Interval Control element is set to Null or Idle. 26
27
TIA-2001.5-C
67 Section 3
The following table shows the bitmap layout for the A3-FCH Reverse Traffic Channel 1
Frame. 2
3.1.19 A3-FCH Reverse Traffic Frame
7 6 5 4 3 2 1 0 Octet
! !! ! FCH/DCCH Reverse Air I nterval Control {1:
Soft Handoff Leg # = [0000 to 1111] FSN = [0000 to 1111] 1
Scaling = [00-11] Packet Arrival Time Error = [00 0000 11 1111] 2
IS-2000 Frame Content = [00H-08H, 0AH-12H, 7DH, 7EH, 7FH] 3
FPC: S = [0000 000 1111 111] EIB/QIB
= [0,1]
4
Reverse Traffic Channel Quality {1..4:
FQI =
[0,1]
Reverse Link Quality = [000 0000 111 1111] n
}Reverse Traffic Channel Quality
}FCH/DCCH Reverse Air I nterval Control
! !! ! Reverse 20 ms Data {0..1:

(LSB) k
}Reverse 20 ms Data
(MSB) Reverse Link Information = <000000H-FFFFFFH> 1
2
(LSB) 3
}Reverse 5 ms Data
(MSB)s ! !! ! Message CRC = [0000H-FFFFH] 1
(LSB) 2
3
4
TIA-2001.5-C
Section 3 68
3.1.20 A3-DCCH Forward Traffic Frame 1
DCCH Channel). It 3
may be used to send up to one 20 ms forward traffic channel frame and up to four 5 ms 4
forward traffic channel frames to the target BS (BTS) for transmission to the MS during 5
the specified 20 ms interval. This message also contains control information associated 6
with the 20 ms interval. One and only one A3-DCCH Forward Traffic Frame message is 7
sent for each 20 ms interval. This A3 message is only used if a 5 ms signaling message is 8
being sent to the BTS. If no 5 ms signaling message is to be included, the A3-IS-2000 9
DCCH Forward message (3.1.14) should be used instead. This A3 message may also be 10
used to send a 20 ms traffic frame without a 5 ms signaling message if agreed to by both 11
vendors. This message shall not be sent to implementations running a version of the IOS 12
earlier than V4.1. 13
Reference
Element
Direction
Type
FCH/DCCH Forward Air Interval Control 4.2.49 SDU -> BTS O R
a,c
C
b,c
C
Message CRC 4.2.33 SDU -> BTS O R
a. This information element is included when a 20 ms forward DCCH traffic channel 14
frame is to be sent in the 20 ms interval. 15
information element is included when a 5 ms forward traffic channel frame is to be 17
sent in the 20 ms interval. Up to four instances of this element may be present in this 18
message in order of transmission over the air interface, as indicated by the Air 19
Interval Content Mask in the FCH/DCCH Forward Air Interval Control element. If 20
c. At least one instance of either the Forward 20 ms Data or the 5 ms Data information 23
element shall be present, unless the IS-2000 Frame Content type in the FCH/DCCH 24
Forward Air Interval Control element is set to Null or Idle. 25
The following table shows the bitmap layout for the A3-DCCH Forward Traffic Channel 26
Frame. 27
3.1.20 A3-DCCH Forward Traffic Frame
7 6 5 4 3 2 1 0 Octet
! !! ! FCH/DCCH Forward Air I nterval Control {1:
FPC:SLC = [0001 to 0110] FSN = [0000 to 1111] 1
FPC: GR = [00H - FFH] 2
IS-2000 Frame Content = [00H, 20H, 21H, 7FH] 4
TIA-2001.5-C
69 Section 3
3.1.20 A3-DCCH Forward Traffic Frame
7 6 5 4 3 2 1 0 Octet
}FCH/DCCH Forward Air I nterval Control

(LSB) n
}Forward 20 ms Data
(MSB) Forward Link Information = <000000H-FFFFFFH> k
k+1
(LSB) k+2
}Forward 5 ms Data
(LSB) 2
1
TIA-2001.5-C
Section 3 70
3.1.21 A3-DCCH Reverse Traffic Frame 1
DCCH Channel). It 3
is used by the target BS (BTS) to send up to one 20 ms decoded reverse link traffic 4
channel frame and up to four 5 ms decoded reverse link traffic channel frames and 5
control information to the source BS (SDU) for a given 20 ms interval. This message is 6
not to be suppressed due to streaming feedback required for EIB-based power control. 7
One and only one A3-DCCH Reverse Traffic Frame message is sent for each 20 ms 8
interval. This A3 message is only used if a 5 ms signaling message has been received 9
from the BTS. If no 5 ms signaling message is to be included, the A3-IS-2000 DCCH 10
Reverse message (3.1.15) should be used instead. This A3 message may also be used to 11
send a 20 ms traffic frame without a 5 ms signaling message if agreed to by both vendors. 12
This message shall not be sent to implementations running a version of the IOS earlier 13
than V4.1. 14
Reference
Element
Direction
Type
FCH/DCCH Reverse Air Interval Control 4.2.50 BTS->SDU O R
a,c
C
b,c
C
a. This information element is included when a 20 ms reverse DCCH traffic channel 15
frame is decoded in the 20 ms interval. 16
information element is included when a 5 ms reverse traffic channel frame is 18
decoded in the 20 ms interval. Up to four instances of this element may be present in 19
this message in order of reception over the air interface, as indicated by the Air 20
Interval Content Mask in the FCH/DCCH Reverse Air Interval Control element. If 21
c. At least one instance of either the Reverse 20 ms Data or the Reverse 5 ms Data 24
FCH/DCCH Reverse Air Interval Control element is set to Null. 26
The following table shows the bitmap layout for the A3-DCCH Reverse Traffic Channel 27
Frame. 28
3.1.21 A3-DCCH Reverse Traffic Frame
7 6 5 4 3 2 1 0 Octet
! !! ! FCH/DCCH Reverse Air I nterval Control {1:
IS-2000 Frame Content = [00H, 20H, 21H, 7EH, 7FH] 3
FPC: S = [0000 000 1111 111] EIB/QIB
= [0,1]
4
TIA-2001.5-C
71 Section 3
3.1.21 A3-DCCH Reverse Traffic Frame
7 6 5 4 3 2 1 0 Octet
FQI =
[0,1]
Reverse Link Quality = [000 0000 111 1111] n
}FCH/DCCH Reverse Air I nterval Control

(LSB) n
}Reverse 20 ms Data
(MSB) Reverse Link Information = <000000H-FFFFFFH> 1
2
(LSB) 3
}Reverse 5 ms Data
(LSB) 2
1
TIA-2001.5-C
Section 3 72
3.1.22 A3-SCH Reverse Traffic Frame 1
Supplemental 3
Channel). It is used by the target BS (BTS) to send one 20 ms decoded reverse link traffic 4
channel frame and control information to the source BS (SDU) for a given 20 ms interval. 5
This message is not to be suppressed due to streaming feedback required for EIB-based 6
power control. This message shall not be sent to implementations running versions of the 7
IOS earlier than IOS V4.1. 8
Reference
Element
Direction
Type
Message Type II 4.2.1 BTS->SDU O R
SCH Reverse Air Interval Control 4.2.51 BTS->SDU O R
a
C
a. The 20 ms Forward Data IE is present unless the IS-2000 Frame Content type is set 9
to Idle, Erasure, or Null. 10
The following table shows the bitmap layout for the A3-SCH Reverse Traffic Channel 11
Frame. 12
3.1.22 A3-SCH Reverse Traffic Frame
7 6 5 4 3 2 1 0 Octet
! !! ! SCH Reverse Air I nterval Control {1:
IS-2000 Frame Content = [00H, 32H 36H, 3DH 40H, 7EH, 7FH] 3
Reserved = [0000 000] EIB =
[0,1]
4
FQI =
[0,1]
Reverse Link Quality = [000 0000 111 1111] 5
}SCH Reverse Air I nterval Control
! !! ! Reverse 20 ms Data {1:
(MSB) Reverse Link Information + Layer 3 Fill = <variable> 1

(LSB) n
}Reverse 20 ms Data
(LSB) 2
13
TIA-2001.5-C
73 Section 3
3.2 A7 Interface Message Formats 1
3.2.1 A7-Handoff Request 3
This A7 interface message is sent from the source BS to the target BS to request 4
allocation of resources to support soft/softer handoff for a call. 5
Reference
Element Direction Type
Message Type II 4.2.1 Source BS -> Target BS M
Call Connection Reference 4.2.23 Source BS -> Target BS O R
Cell Identifier List 4.2.6 Source BS -> Target BS O
a
C
IS-95 Channel Identity 4.2.60 Source BS -> Target BS O
b,f
C
Band Class 4.2.25 Source BS -> Target BS O R
Downlink Radio Environment 4.2.7 Source BS -> Target BS O R
CDMA Serving One Way Delay 4.2.18 Source BS -> Target BS O R
Privacy Info 4.2.36 Source BS -> Target BS O
n
C
A3 Signaling Address 4.2.20 Source BS -> Target BS O
c
C
Correlation ID 4.2.26 Source BS -> Target BS O
k
C
SDU ID 4.2.21 Source BS -> Target BS O
d
C
Mobile Identity (IMSI) 4.2.3 Source BS -> Target BS O
e
R
Mobile Identity (ESN) 4.2.3 Source BS -> Target BS O
e,q
C
Physical Channel Info 4.2.2 Source BS -> Target BS O
f,l
C
Quality of Service Parameters 4.2.9 Source BS -> Target BS O
g,f
C
IS-2000 Power Control Info 4.2.46 Source BS -> Target BS O
h,f
C
IS-2000 Forward Power Control Mode 4.2.47 Source BS -> Target BS O
i,f
C
IS-2000 FPC Gain Ratio Info 4.2.48 Source BS -> Target BS O
j,f
C
A7 Originating ID 4.2.43 Source BS -> Target BS O
m
C
IS-2000 Service Configuration Record 4.2.13 Source BS ->Target BS O
r
C
Rescue Request Info 4.2.60 Source BS ->Target BS O
o
C
4.2.27 Source BS ->Target BS O
p
C
a. The list of cell identifiers shall be assumed by the target BS to be in priority order 6
with the highest priority cell listed first. 7
b. The target BS shall consider only the following fields valid in this element: A3/A7 8
Element ID, Length, Frame Offset, Freq. Included and ARFCN. All other fields shall 9
be ignored by the target BS. 10
c. If this element is omitted, the target BS shall send all A3 signaling messages related 11
to the call to the same A7 signaling address as is used to reply to this A7 message. 12
d. This element is optionally included by the source BS. If included, the value shall be 13
saved and used by the target BS on A3 signaling messages. 14
e. This element shall be included for OAM&P purposes. 15
TIA-2001.5-C
Section 3 74
f. Either the {IS-95 Channel Identity} element as a set, or the {Physical Channel Info, 1
Quality of Service, IS-2000 Power Control Info, IS-2000 Forward Power Control 2
Mode, and IS-2000 FPC Gain Ratio} elements as a set shall be present in this 3
message, but elements from both sets shall not be present simultaneously. The IS-95 4
Channel Identity element is being kept in this revision of this specification for 5
backward compatibility. For backward compatibility, the {IS-95 Channel Identity} 6
set shall be sent to BSs implemented to any v3.x version of the IOS. 7
g. This element is only used for packet data calls. This information is included if 8
available at the source BS. In this version of this standard, this element is used to 9
carry the current non-assured mode priority of the packet data session. 10
h. This element shall be included when the physical channel (FCH or DCCH) measured 11
by the primary power control subchannel is included in the Frame Selector Info 12
Information Element. It provides information about power control for the call. (Note: 13
information for the secondary power control subchannel is sent in the A7-Burst 14
Commit message.) 15
i. This element shall be included when the physical channel (FCH or DCCH) measured 16
Information Element. (Note: information for the secondary power control subchannel 18
is sent in the A7-Burst Commit message.) 19
j. This element shall be included when the physical channel (FCH or DCCH) measured 20
Information Element. It provides information used for forward gain equalization for 22
the primary power control subchannel. (Note: information for the secondary power 23
control subchannel is sent in the A7-Burst Commit message.) 24
k. If this element is included in this message, it shall be returned in the A7-Handoff 25
Request Ack message. 26
l. A maximum of two supplemental channels (SCH) are supported by this version of 27
this specification. 28
m. This element is optionally included by the source BS. If included, the value shall be 29
saved and used by the target BS in subsequent A7 messages for this call association. 30
If the A3 Flag field is set to 1, then the value shall also be used by the target BS in 31
all subsequent A3 messages. 32
n. This element is included if the Privacy Mask is available. 33
o. This information element is only included if a rescue channel procedure is requested. 34
p. This element shall be included if the IS-2000 Service Configuration Record element 35
is included. The source BS shall include this information element if it has this 36
information available. 37
q. This information element is included for OAM&P purposes if this information is 38
available at the source BS. 39
r. The source BS shall include this information element if it has this information 40
available. 41
42
TIA-2001.5-C
75 Section 3
The following table shows the bitmap layout for the A7-Handoff Request message. 1
3.2.1 A7-Handoff Request
7 6 5 4 3 2 1 0 Octet
Length = [08H] 2
(LSB) 4
(LSB) 6
8
9
(LSB) 10
Cell I dentification) {1+:
j+1
(LSB) j+2
Length = [05H] 2
Hard
Handoff =
[0]
(Ignored)
[000]
(Ignored)
Walsh Code Channel Index = [00H] (Ignored) 4
Pilot PN Code (low part) = [00H] (Ignored) 5
Pilot PN
Code
(high
part)
= [0]
(Ignored)
Power
Combined
= [0]
(Ignored)
Freq.
included
= [1]
= [000-111]
6
TIA-2001.5-C
Section 3 76
7 6 5 4 3 2 1 0 Octet
! !! ! Band Class: A7 Element Identifier = [5DH] 1
Length = [01H] 2
Reserved = [000]
Band Class = [00001(PCS),
00010 (TACS),
00011 (JTACS),
00100 (Korean PCS),
00101 (NMT-450),
00110 (IMT-2000),
00111 (North American 700 MHz
Cellular Band)]
3
! !! ! Downlink Radio Environment: A3/A7 Element Identifier = [29H] 1
Downlink Radio Environment {1+:
j+1
(LSB) j+2
Reserved = [00] Downlink Signal Strength Raw = [000000] (Ignored) j+5
(MSB) CDMA Target One Way Delay j+6
(LSB) j+7
}Downlink Radio Environment
Length = [09H] 2
5
(LSB) 6
(MSB) CDMA Serving One Way Delay = [0000H-FFFFH] 9
(LSB) 10
10]
11
(LSB) k+4
TIA-2001.5-C
77 Section 3
7 6 5 4 3 2 1 0 Octet
! !! ! Privacy Info: A3/A7 Element Identifier = [1AH] 1
Privacy Mask I nformation {1+:
Reserved
= [0]
Privacy Mask Type = [00001,00010]
(public, private)
Status
= [0,1]
Available
= [0,1]
j
Privacy Mask Length = <06H> j+1
(MSB) Privacy Mask = <any value> j+2

(LSB) k
}Privacy Mask I nformation
! !! ! A3 Signaling Address: A7 Element Identifier = [49H] 1
Length = [07H] 2
Address Type = [01H] (IPv4) 3
(MSB) TCP or SCTP Port 4
(LSB) 5
(MSB) A3 Address = <any value> 6
7
8
(LSB) 9
Length = [04H] 2
4
5
(LSB) 6

(LSB) m
Indicator
= [1,0]
Type of Identity
= [110] (IMSI)
3
TIA-2001.5-C
Section 3 78
7 6 5 4 3 2 1 0 Octet

Length = [05H] 2
Indicator
= [0]
Type of Identity
= [101] (ESN)
3
5
6
(LSB) 7
! !! ! Physical Channel Info: A7 Element Identifier = [07H] 1
Length =[06H] 2
Reserved = [000] Rev_FC
H_Gatin
g =
[0,1]
Frame Offset = [0H FH] 3
A3 Traffic Channel Protocol
Stack = [001, 010]
Pilot Gating Rate =
[00, 01, 10]
ARFCN (high part)
= [000-111]
4
Reserved = [0000] OTD=[0,1] Count of Physical Channels
= [001 100]
6
Physical Channel 2 =
0H N/A,
1H FCH,
2H SCH_0,
3H DCCH
0H IS-95,
1H FCH,
2H SCH_0,
3H DCCH
7
0H N/A,
1H FCH,
2H SCH_0,
3H DCCH,
4H SCH_1
0H N/A,
1H FCH,
2H SCH_0,
3H DCCH,
4H SCH_1
8
! !! ! Quality of Service Parameters: A7 Element Identifier = [0FH] 1
Length = [01H] 2
Reserved = [0000] Non-Assured Mode Packet Priority = [0000
1101]
3
! !! ! IS-2000 Power Control Info: A7 Element Identifier = [0BH] 1
Length = [04H] 2
TIA-2001.5-C
79 Section 3
7 6 5 4 3 2 1 0 Octet

FPC_
PRI_
CHAN =
[0,1]
Reserved
= [00]
Rev_Pwr_
Cntl_Dela
y_Incl =
[0,1]
Rev_Pwr_Cntl
_Delay =
[00 11]
Count of Subchan Gains =
[011]
3
! !! ! IS-2000 Forward Power Control Mode: A7 Element Identifier = [14H] 1
Length = [02H] 2
Reserved = [00000] FPC_MODE = [000 110] 3
Action
Time
Flag
= [1]
Reserved
= [0]
ACTION_TIME = [00 0000] (Ignored) 4
Length = [08H] 2
Reserved
= [0]
[011]
4
! !! ! A7 Originating ID: A3/A7 Element Identifier = [2CH] 1
Length = [02H - 09H] 2
Reserved = [0000 000] A3 Flag =
[0,1]
3
(MSB) A7 Originating ID = <any value> 4

(LSB) k
! !! ! I S-2000 Service Configuration Record: A3/A7 Element Identifier = [10H] 1
Reserved
= [0000 0]
= [000 111]
3
(MSB) 4
TIA-2001.5-C
Section 3 80
7 6 5 4 3 2 1 0 Octet

Seventh
Fill Bit
if needed
= [0 (if
used as a
fill bit)]
Sixth Fill
Bit if
needed
= [0 (if
used as a
fill bit)]
Fifth Fill
Bit if
needed
= [0 (if
used as a
fill bit)]
Fourth
Fill Bit
if needed
= [0 (if
used as a
fill bit)]
Third
Fill Bit
if needed
= [0 (if
used as a
fill bit)]
Second
Fill Bit
if needed
= [0 (if
used as a
fill bit)]
First Fill
Bit if
needed
= [0 (if
used as a
fill bit)]
k
! !! ! Rescue Request Info: A7 Element Identifier = [32H] 1
Length = [01H] 2
Reserved = [0000 000] Transmit
Flag =
[0,1]
3
! !! ! I S-2000 Non-Negotiable Service Configuration Record: A7 Element Identifier =
[33H]
1
= [00H to FFH]
2
Reserved
= [0000 0]
= [000 to 111]
3
(MSB) 4
= <any value>

Seventh
Fill Bit
if needed
= [0 (if
used as a
fill bit)]
Sixth Fill
Bit if
needed
= [0 (if
used as a
fill bit)]
Fifth Fill
Bit if
needed
= [0 (if
used as a
fill bit)]
Fourth
Fill Bit
if needed
= [0 (if
used as a
fill bit)]
Third
Fill Bit
if needed
= [0 (if
used as a
fill bit)]
Second
Fill Bit
if needed
= [0 (if
used as a
fill bit)]
First Fill
Bit if
needed
= [0 (if
used as a
fill bit)]
k
1
TIA-2001.5-C
81 Section 3
3.2.2 A7-Handoff Request Ack 1
This A7 interface message is sent from the target BS to the source BS to respond to a 2
request for allocation of resources to support soft/softer handoff for a call. 3
Reference
Message Type II 4.2.1 Target BS -> Source BS M
Call Connection Reference 4.2.23 Target BS -> Source BS O R
Cell Identifier List (committed) 4.2.6 Target BS -> Source BS O
a,f
C
Correlation ID 4.2.26 Target BS -> Source BS O
b
C
Neighbor List 4.2.19 Target BS -> Source BS O
c,f,i
C
Cell Identifier List (uncommitted) 4.2.6 Target BS -> Source BS O
d,f
C
Cause List 4.2.35 Target BS -> Source BS O
e,f
C
A7 Originating ID 4.2.43 Target BS -> Source BS O
g
C
A7 Destination ID 4.2.44 Target BS -> Source BS O
h
C
Cell Commitment Info List 4.2.56 Target BS -> Source BS O
f
C
Extended Neighbor List 4.2.57 Target BS -> Source BS O
i
C
Physical Channel Info 4.2.2 Target BS -> Source BS O
j
C
a. If there are no committed cells, the length field of this element shall be set to zero. 4
b. This field is required if a Correlation ID value was included on the A7-Handoff 5
Request message to which this message is a response. 6
c. There may be multiple instances of the Neighbor List element. The number and 7
order of instances of the Neighbor List element shall match the number and order of 8
cell identifiers in the Cell Identifier List (committed) element. 9
d. If one or more cells that were requested are not being committed to the call 10
association by the target BS, then this element is required when the receiver of this 11
message is implemented to any v3.x version of the IOS. It shall contain the cell 12
identifiers of all uncommitted cells. 13
e. If one or more cells that were requested are not being committed to the call 14
association by the target BS, then this element is required to indicate the reasons on a 15
cell by cell basis when the receiver of this message is implemented to any v3.x 16
version or later of the IOS specification. The number and order of the cause values in 17
this list shall match the number and order of cell identifiers in the Cell Identifier List 18
(uncommitted) element. 19
f. Either the {Cell Identifier List (committed), Neighbor List, Cell Identifier List 20
(uncommitted)} elements as a set, or the {Cell Commitment Info List} element as a 21
set shall be present in this message, but elements from both sets shall not be present 22
simultaneously. For backward compatibility, the {Cell Identifier List (committed), 23
Neighbor List, Cell Identifier List (uncommitted)} set of elements shall be sent to 24
BSs implemented to any v3.x version of the IOS. 25
g. This element is optionally included by the target BS. If included, the value shall be 26
saved and used by the source BS in subsequent A7 messages for this call association. 27
h. This element is required if an A7 Originating ID value was included in the 28
corresponding A7-Handoff Request message. 29
TIA-2001.5-C
Section 3 82
i. Either the Neighbor List information element or the Extended Neighbor List 1
information element may be included, but not both. 2
j. The Physical Channel Info IE is required if the target BS allocates any parameters 3
different than those received from the source BS in the Physical Channel Info IE of 4
the Handoff Request message. 5
The following table shows the bitmap layout for the A7-Handoff Request Ack message. 6
3.2.2 A7-Handoff Request Ack
7 6 5 4 3 2 1 0 Octet
Length = [08H] 2
(LSB) 4
(LSB) 6
8
9
(LSB) 10
! !! ! Cell Identifier List (committed): A3/A7 Element Identifier = [1AH] 1
j+1
(LSB) j+2
Length = [04H] 2
4
5
(LSB) 6
! !! ! Neighbor List: A3/A7 Element Identifier = [48H] 1
Number of Neighbors = [00H-FFH] 3
TIA-2001.5-C
83 Section 3
7 6 5 4 3 2 1 0 Octet
Neighbor I nfo {1+:
Pilot PN Code (low part) = [00H-FFH] k
Pilot PN
Code
(high
part)
= [0,1]
Short Cell Identification Discriminator = [000 0111]
(Discriminator Type = 7)
k+1
(MSB) MSCID = <any value> k+2
k+3
(LSB) k+4
(MSB) Cell = [001H-FFFH] k+5
(LSB) Sector = [0H-FH] (0H = Omni) k+6
}Neighbor I nfo
! !! ! Cell Identifier List (uncommitted): A3/A7 Element Identifier = [1AH] 1
j+1
(LSB) j+2
Cause Value {1+:
TIA-2001.5-C
Section 3 84
7 6 5 4 3 2 1 0 Octet
Reserved
= [0]
Cause Value =
= [07H (OAM&P intervention),
11H (Service option not available),
35H (Requested FPC mode change failed),
40H (Ciphering algorithm not supported),
41H (Private long code not available or not supported),
42H (Requested MUX option or rates not available),
43H (Requested privacy configuration unavailable),
44H (SCH not supported)]
k
}Cause Value
! !! ! A7 Originating ID: A3/A7 Element Identifier = [2CH] 1
Length = [02H - 09H] 2
Reserved = [0000 000] A3 Flag
= [0,1]
3
(MSB) A7 Originating ID = <any value> 4

(LSB) k
Length = [01H - 08H] 2

(LSB) k
! !! ! Cell Commitment Info List: A3/A7 Element Identifier = [72H] 1
Cell Discriminator Type = [07H] 3
Cell Commitment I nfo{1+:
j+1
(LSB) j+2
TIA-2001.5-C
85 Section 3
7 6 5 4 3 2 1 0 Octet
Count of Physical Channels
= [001 - 100]
Committed = [0
(No),
1 (Yes)]
Physical Channel 1 = [0H - 4H] j+5
Reserved = [000] Committed = [0,1] Physical Channel 2 = [0H - 4H] j+6
Neighbor List {1:
Length of Neighbor List = <variable> k
Number of Neighbors = [00H-FFH] k+10
Neighbor I nfo {1+:
Pilot PN Code (low part) = [00H-FFH] m
Pilot PN
Code
(high
part)
= [0,1]
m+1
(MSB) MSCID = <any value> m+2
m+3
(LSB) m+4
(MSB) Cell = [001H-FFFH] m+5
(LSB) Sector = [0H-FH] (0H = Omni) m+6
}Neighbor I nfo
}Neighbor List
}Cell Commitment I nfo
! !! ! Extended Neighbor List: A3/A7 Element Identifier = [73H] 1
Number of Neighbors = [00H-FFH] 3
Neighbor Record Length = [00H-FFH] 4
Neighbor I nfo {1+:
Pilot PN Code (low part) = [00H-FFH] k
Pilot PN
Code
(high
part)
= [0,1]
k+1
(MSB) MSCID = <any value> k+2
k+3
(LSB) k+4
TIA-2001.5-C
Section 3 86
7 6 5 4 3 2 1 0 Octet
(MSB) Cell = [001H-FFFH] k+5
(LSB) Sector = [0H-FH] (0H = Omni) k+6
BS ID (high octet) = [00H FFH] k+7
BS ID (low octet) = [00H FFH] k+8
Neighbor Type =
[01H (IS-95A/95B),
02H (IS-2000),
03H (IS-95A/B and IS-2000)]
k+9
Band Class = [0000 0 1111 1] ARFCN (high bits) = [000-
111]
k+10
ARFCN (low bits) = [00H FFH] k+11
}Neighbor I nfo
! !! ! Physical Channel Info: A3/A7 Element Identifier = [07H] 1
Length =[06H] 2
Reserved = [000] Rev_FCH_Gating =
[0,1]
(ignored)
Frame Offset = [0H FH] 3
A3 Traffic Channel
Protocol Stack =
[001;010]
Pilot Gating Rate = [00, 01,
10]
ARFCN (high part)
= [000-111]
4

Reserved = [0000] OTD=[0,1] Count of Physical
Channels = [001 100]
6
0H N/A,
1H FCH,
2H SCH_0,
3H DCCH
0H IS-95,
1H FCH,
2H SCH_0,
3H DCCH
7
0H N/A,
1H FCH,
2H SCH_0,
3H DCCH,
4H SCH_1
0H N/A,
1H FCH,
2H SCH_0,
3H DCCH,
4H SCH_1
8
1
TIA-2001.5-C
87 Section 3
3.2.3 A7-Drop Target 1
This A7 interface message is sent from the source BS to the target BS to request de- 2
allocation of resources being used to support soft/softer handoff for a call. 3
Reference
a
R
b
C
A7 Destination ID 4.2.44 Source BS -> Target BS O
c
C
a. When the A7 target drop procedure is used during call release scenarios, the A7- 4
Drop Target message shall contain the Cell Identifier List with zero cells included. In 5
this case, the source should wait some implementation specific period of time to 6
allow any in progress Adds or Drops to complete prior to sending the A7-Drop 7
Target message. 8
b. If this element is included in this message, then the target BS shall include the value 9
in the A7-Drop Target Ack message. 10
c. This element is required if an A7 Originating ID value was included in an A7- 11
Handoff Request Ack message previously received from the target BS for this call 12
association. 13
The following table shows the bitmap layout for the A7-Drop Target message. 14
3.2.3 A7-Drop Target
7 6 5 4 3 2 1 0 Octet
Length = [08H] 2
(LSB) 4
(LSB) 6
8
9
(LSB) 10
TIA-2001.5-C
Section 3 88
3.2.3 A7-Drop Target
7 6 5 4 3 2 1 0 Octet
j+1
(LSB) j+2
Length = [04H] 2
4
5
(LSB) 6
Length = [01H - 08H] 2

(LSB) k
1
TIA-2001.5-C
89 Section 3
3.2.4 A7-Drop Target Ack 1
request for de-allocation of resources being used to support soft/softer handoff for a call. 3
Reference
a
C
b
C
a. This field is required if a Correlation ID value was included in the A7-Drop Target 4
message to which this message is a response. 5
b. This element is required if an A7 Originating ID value was included in an A7- 6
Handoff Request message previously received from the source BS for this call 7
association. 8
The following table shows the bitmap layout for the A7-Drop Target Ack message. 9
3.2.4 A7-Drop Target Ack
7 6 5 4 3 2 1 0 Octet
Length = [08H] 2
(LSB) 4
(LSB) 6
8
9
(LSB) 10
Length = [04H] 2
4
5
(LSB) 6
Length = [01H - 08H] 2
TIA-2001.5-C
Section 3 90
3.2.4 A7-Drop Target Ack
7 6 5 4 3 2 1 0 Octet

(LSB) k
1
TIA-2001.5-C
91 Section 3
3.2.5 A7-Target Removal Request 1
This A7 interface message is sent from the target BS to the source BS to request the de- 2
allocation of resources being used to support soft/softer handoff for a call. 3
Reference
Cell Identifier List (target) 4.2.6 Target BS -> Source BS O
a
R
a,b,d
R
c
C
d
C
a. The number and order of entries in the Cell Identifier list (target) element shall 4
match the number and order of entries in the Cause List element. 5
b. The allowable cause values are broken into two categories, those which indicate that 6
the source BS may remove the resources, and those that indicate that the source BS 7
shall remove the resources. 8
Cause values indicating that the source BS may remove the resources are: OAM&P 9
intervention. 10
Cause values indicating that the source BS shall remove the resources are: 11
Equipment failure. 12
c. If this element is included in this message, the value shall be returned in the A7- 13
Target Removal Response message. 14
d. This element is required if an A7 Originating ID value was included in an A7- 15
association. 17
The following table shows the bitmap layout for the A7-Target Removal Request 18
message. 19
3.2.5 A7-Target Removal Request
7 6 5 4 3 2 1 0 Octet
Length = [08H] 2
(LSB) 4
(LSB) 6
8
9
(LSB) 10
TIA-2001.5-C
Section 3 92
3.2.5 A7-Target Removal Request
7 6 5 4 3 2 1 0 Octet
! !! ! Cell Identifier List (target): A3/A7 Element Identifier = [1AH] 1
j+1
(LSB) j+2
Cause Value {1+:
Reserved
= [0]
Cause Value =
= [07H (OAM&P intervention),
k
}Cause Value
Length = [04H] 2
4
5
(LSB) 6
Length = [01H - 08H] 2

(LSB) k
1
TIA-2001.5-C
93 Section 3
3.2.6 A7-Target Removal Response 1
This A7 interface message is sent from the source BS to the target BS to respond to a 2
request for the de-allocation of resources being used to support soft/softer handoff for a 3
call. 4
Reference
a
C
Cause List 4.2.35 Source BS -> Target BS O
b,c
C
Cell Identifier List (not removed) 4.2.6 Source BS -> Target BS O
c
C
d
C
a. This element is required if a Correlation ID value was included on the A7-Target 5
Removal Request message to which this message is a response. 6
b. This element is included by the source BS only if one or more cells are not to be 7
removed from the soft/softer handoff as requested by the target BS. Allowable cause 8
values are: Uplink quality, Uplink strength, Downlink quality, Downlink strength. 9
c. If the Cause List element is included in this message, then the instances of cause 10
value in that element shall match the number and order of cell identifiers in this list. 11
d. This element is required if an A7 Originating ID value was included in an A7- 12
association. 14
The following table shows the bitmap layout for the A7-Target Removal Response 15
message. 16
3.2.6 A7-Target Removal Response
7 6 5 4 3 2 1 0 Octet
Length = [08H] 2
(LSB) 4
(LSB) 6
8
9
(LSB) 10
Length = [04H] 2
TIA-2001.5-C
Section 3 94
3.2.6 A7-Target Removal Response
7 6 5 4 3 2 1 0 Octet
4
5
(LSB) 6
Cause Value {1+:
Reserved
= [0]
Cause Value =
= [02H (Uplink quality),
03H (Uplink strength),
04H (Downlink quality),
05H (Downlink strength)]
k
}Cause Value
! !! ! Cell Identifier List (not removed): A3/A7 Element Identifier = [1AH] 1
j+1
(LSB) j+2
Length = [01H - 08H] 2

(LSB) k
1
2
TIA-2001.5-C
95 Section 3
3.2.7 A7-Burst Request 1
This A7 interface message is sent from the source BS to the target BS to request the 2
reservation of resources in support of a traffic burst. 3
Reference
Correlation ID 4.2.26 Source BS -> Target BS O R
a
R
Mobile Identity (ESN) 4.2.3 Source BS -> Target BS O
a
C
b
C
Forward Burst Radio Info 4.2.10 Source BS -> Target BS O
c
C
Reverse Burst Radio Info 4.2.11 Source BS -> Target BS O
d
C
e
C
a. This element may be included for OAM&P purposes. 4
b. The list of cell identifiers shall be assumed by the target BS to be in priority order 5
with the highest priority cell listed first. 6
c. This element is only included when forward link radio resources are to be allocated 7
to the burst. 8
d. This element is only included when reverse link radio resources are to be allocated to 9
the burst. 10
e. This element is required if an A7 Originating ID value was included in an A7- 11
association. 13
The following table shows the bitmap layout for the A7-Burst Request message. 14
3.2.7 A7-Burst RequestError! Reference source not found.
7 6 5 4 3 2 1 0 Octet
Length = [08H] 2
(LSB) 4
(LSB) 6
8
9
(LSB) 10
TIA-2001.5-C
Section 3 96
7 6 5 4 3 2 1 0 Octet
Length = [04H] 2
4
5

(LSB) 6
! !! ! Mobile Identity (IMSI): A3/A7 Element Identifier = [0DH] 1
Indicator
= [1,0]
Type of Identity
= [110] (IMSI)
3

! !! ! Mobile Identity (ESN): A3/A7 Element Identifier = [0DH] 1
Length = [05H] 2
Indicator
= [0]
Type of Identity
= [101] (ESN)
3
5
6
(LSB) 7
Cell Discriminator Type = [07H] 3
Cell I dentification{1+:
j+1
(LSB) j+2
! !! ! Forward Burst Radio Info: A3/A7 Element Identifier = [11H] 1
Length = [14H] 2
TIA-2001.5-C
97 Section 3
7 6 5 4 3 2 1 0 Octet
Forward Burst Radio I nfo {1..2:
Coding Indicator
= [00, 01]
SCH_ID
= [0,1]
QOF Mask
= <any value>
(Ignored)
Forward Code Channel Index
(high part)
= <any value> (Ignored)
j
Forward Code Channel Index (low part) = <any value> (Ignored) J+1
Pilot PN Code (low part) = <any value> (Ignored) J+2
Pilot PN
Code
(high
part) =
<any
value>
(Ignored)
Reserved =[00] CCSH
Encoder
Type
= [0,1]
(Ignored)
Forward Supplemental Channel Rate
= [0000 1111]
J+3
Reserved
= [000]
Forward Supplemental Channel Start Time
= [0 0000 1 1111]
J+4
SR3 Incl
= [0,1]
Start Time Unit
= [000 111]
Forward Supplemental Channel Duration
= [0000 1111]
J+5
= <any value>
(Ignored)
Lower Forward Code Channel
Index (high part)
J+6
Lower Forward Code Channel Index (low part) = <any value> (Ignored) J+7
= <any value>
(Ignored)
Upper Forward Code Channel
Index (high part)
j+8
Upper Forward Code Channel Index (low part) = <any value> (Ignored) j+9
}Forward Burst Radio I nfo
! !! ! Reverse Burst Radio Info: A3/A7 Element Identifier = [12H] 1
Length = [04H] 2
Coding Indicator
= [00, 01]
Reserved = [00] Reverse Supplemental Channel Rate
= [0000 1111]
3
Reserved = [000] Reverse Supplemental Channel Start Time = [0 0000 1
1111]
4
Rev
Walsh
ID
= <any
value>
(Ignored)
Start Time Unit
= [000 111]
Reverse Supplemental Channel Duration
= [0000 1111]
5
Reserved = [0H] Rev_Burst_DTX_Duration = [0H FH] 6
TIA-2001.5-C
Section 3 98
7 6 5 4 3 2 1 0 Octet
Length = [01H - 08H] 2

(LSB) k
1
TIA-2001.5-C
99 Section 3
3.2.8 A7-Burst Response 1
request for reservation of resources to support a traffic burst. Note that one or more A7- 3
Burst Response messages may be used to respond to a single A7-Burst Request message. 4
A result (committed or uncommitted) shall be provided for all cells in the A7-Burst 5
Request message. Each A7-Burst Response message includes at most one committed cell. 6
Reference
Correlation ID 4.2.26 Target BS -> Source BS O R
Cell Identifier List (Committed) 4.2.6 Target BS -> Source BS O
c
C
Cell Identifier List (Uncommitted) 4.2.6 Target BS -> Source BS O
d
C
Forward Burst Radio Info 4.2.10 Target BS -> Source BS O
a,g,h
C
Reverse Burst Radio Info 4.2.11 Target BS -> Source BS O
b,g,h
C
e
C
d,f
C
A7 Burst Retry Delay List 4.2.58 Target BS -> Source BS O
i
C
a. This element is only included when this message includes information about forward 7
link radio resources that have been reserved at the cell indicated in the Cell Identifier 8
List (Committed) element. 9
b. This element is only included when this message includes information about reverse 10
link radio resources that have been reserved at the cell indicated in the Cell Identifier 11
List (Committed) element. 12
c. This element is only included when this message includes information about a cell 13
with radio resources reserved for the forward and/or reverse burst indicated in the 14
Forward and/or Reverse Burst Radio Info element. 15
d. This element is only included when this message includes one or more requested 16
cells that are not being reserved. 17
e. This element is required if an A7 Originating ID value was included in an A7- 18
association. 20
f. The items in this list shall be in the same order and shall be in one to one 21
correspondence with the cells listed in the Cell Identifier List (Uncommitted) 22
element. Each entry indicates the reason for not committing the associated cell. 23
g. If this message is in response to a request for a burst extension (refer to definition of 24
burst extension in section 2.2.7.1), then the start time and rate shall be the same as in 25
the corresponding A7-Burst Request message. 26
h. The Forward (Reverse) Supplemental Channel Start Time shall not overlap with 27
another burst on the Forward (Reverse) Supplemental Channel. The Supplemental 28
Channel Rate shall not exceed the Rate specified in the corresponding A7-Burst 29
Request message; however, the Supplemental Channel Duration may be any value. 30
i. This optional element may be included by the target BS to indicate a burst retry 31
delay for the uncommitted cell(s) for a given call connection reference. The source 32
TIA-2001.5-C
Section 3 100
BS should use this information to determine when to send another A7-Burst Request 1
for the same resources, another request is sent. 2
The items in this list shall be in the same order and shall be in one to one 3
correspondence with the cells listed in the Cell Identifier List (Uncommitted) 4
element. Each entry indicates the retry delay for the associated cell. 5
The following table shows the bitmap layout for the A7-Burst Response message. 6
3.2.8 A7-Burst ResponseError! Reference source not found.
7 6 5 4 3 2 1 0 Octet
Length = [08H] 2
(LSB) 4
(LSB) 6
8
9
(LSB) 10
Length = [04H] 2
4
5
(LSB) 6
! !! ! Cell Identifier List (committed): A3/A7 Element Identifier = [1AH] 1
Cell I dentification {1:
j+1
(LSB) j+2
! !! ! Cell Identifier List (uncommitted): A3/A7 Element Identifier = [1AH] 1
TIA-2001.5-C
101 Section 3
7 6 5 4 3 2 1 0 Octet
j+1
(LSB) j+2
Length = [0AH, 14H] 2
Coding Indicator
= [00, 01]
SCH_ID
= [0, 1]
QOF Mask
= [00 11]
(high part)
= [000 111]
k
Forward Code Channel Index (low part) = [00H FFH] k+1
Pilot PN Code (low part) = [00H FFH] k+2
Pilot PN
Code
(high
part)
[0,1]
Reserved =
[00]
CCSH Encoder
Type
= [0,1]
(Ignored)
= [0000 1111]
k+3
Reserved
= [000]
= [0 0000 1 1111]
k+4
SR3 Incl
= [0, 1]
Start Time Unit
= [000 111]
= [0000 1111]
k+5
= <any value>
Lower Forward Code Channel
Index (high part)
= <any value>
k+6
Lower Forward Code Channel Index (low part) = <any value> k+7
= <any value>
Upper Forward Code Channel
Index (high part)
= <any value>
k+8
Upper Forward Code Channel Index (low part) = <any value> k+9
Length = [04H] 2
Coding Indicator
= [00, 01]
= [0000 1111]
3
TIA-2001.5-C
Section 3 102
7 6 5 4 3 2 1 0 Octet
Reserved = [000] Reverse Supplemental Channel Start Time = [0 0000
1 1111]
4
Rev
Walsh
ID
= <any
value>
(Ignored)
Start Time Unit
= [000 111]
= [0000 1111]
5
Length = [01H - 08H] 2

(LSB) k
Cause Value {1+:
Reserved
= [0]
Cause Value = [20H (Equipment failure),
40H (Ciphering algorithm not supported),
41H (Private long code not available or not supported),
42H (Requested MUX option or rates not available),
43H (Requested privacy configuration not available)]
n
}Cause Value
! !! ! A7 Burst Retry Delay List: A3/A7 Element Identifier = [70H] 1
Burst Retry Delay {1+:
Reserved = [0000] Burst Retry Delay = [0000 1010] p
}Burst Retry Delay
1
TIA-2001.5-C
103 Section 3
3.2.9 A7-Burst Commit 1
This A7 interface message is sent from the source BS to the target BS to commit a set of 2
resources that have been reserved to support a traffic burst. This message can contain at 3
most one cell in each direction. 4
Reference
Cell Identifier List (Forward) 4.2.6 Source BS -> Target BS O
a
R
Cell Identifier List (Reverse) 4.2.6 Source BS -> Target BS O
a
R
Forward Burst Radio Info 4.2.10 Source BS -> Target BS O
b,h
C
Reverse Burst Radio Info 4.2.11 Source BS -> Target BS O
c,h
C
d
C
IS-2000 FPC Gain Ratio Info 4.2.48 Source BS -> Target BS O
e
C
f
C
Downlink Radio Environment 4.2.7 Source BS -> Target BS O
g
R
a. The length field of this element shall be set to 0 if no resources are to be allocated 5
in the indicated direction. 6
b. This element is only included when forward link radio resources are to be allocated 7
to the burst. 8
c. This element is only included when reverse link radio resources are to be allocated to 9
the burst. 10
d. This element shall be included when supporting a secondary power control 11
subchannel for the SCH. The Action Time Flag shall be set to 1 and the 12
ACTION_TIME field shall be ignored. The FPC_MODE value shall go into effect at 13
the earlier of the burst start times indicated in the Forward Burst Radio Info and/or 14
Reverse Burst Radio Info element. 15
e. This element shall be included when supporting a secondary power control 16
subchannel. It provides information used for forward gain equalization for the SCH. 17
f. This element is required if an A7 Originating ID value was included in an A7- 18
association. 20
g. This element is the CDMA Target One Way Delay for the cells listed in the Cell 21
Identifier List (Forward) and Cell Identifier List (Reverse) IEs. 22
h. If this message corresponds to a request for a burst extension (refer to definition of 23
burst extension in section 2.1.14.1), then the start time and rate shall be the same as 24
in the corresponding A7-Burst Response message. 25
26
TIA-2001.5-C
Section 3 104
The following table shows the bitmap layout for the A7-Burst Commit message. 1
3.2.9 A7-Burst CommitError! Reference source not found.
7 6 5 4 3 2 1 0 Octet
Length = [08H] 2
(LSB) 4
(LSB) 6
8
9
(LSB) 10
! !! ! Cell Identifier List (Forward): A3/A7 Element Identifier = [1AH] 1
Length = [00H, 06H] 2
Cell I dentification {
j+1
(LSB) j+2
! !! ! Cell Identifier List (Reverse): A3/A7 Element Identifier = [1AH] 1
Length = [00H, 06H] 2
Cell I dentification {
j+1
(LSB) j+2
Length = [0AH, 14H] 2
TIA-2001.5-C
105 Section 3
7 6 5 4 3 2 1 0 Octet
Coding Indicator
= [00, 01]
SCH_ID
= [0, 1]
QOF Mask
= [00 11]
(high part)
= [000 111]
k
Forward Code Channel Index (low part) = [00H FFH] k+1
Pilot PN Code (low part) = [00H FFH] k+2
Pilot PN
Code
(high
part)
[0,1]
Reserved =[00] CCSH
Encoder
Type
= [0,1]
= [0000 1111]
k+3
Reserved
= [000]
= [0 0000 1 1111]
k+4
SR3 Incl
= [0, 1]
Start Time Unit
= [000 111]
= [0000 1111]
k+5
= [00,01,10,11]
Index (high part) = <any value>
k+6
Lower Walsh Code Channel Index (low part) = <any value> k+7
= [00,01,10,11]
Index (high part) = <any value>
k+8
Upper Walsh Code Channel Index (low part) = <any value> k+9
Length = [04H] 2
Coding Indicator
= [00, 01]
= [0000 1111]
3
1111]
4
Rev
Walsh
ID
= [0,1]
Start Time Unit
= [000 111]
= [0000 1111]
5
Length = [02H] 2
Action
Time
Flag
= [1]
Reserved
= [0]
ACTION_TIME = [00 0000] (Ignored) 4
TIA-2001.5-C
Section 3 106
7 6 5 4 3 2 1 0 Octet
Length = [08H] 2
Reserved
= [0]
[011]
4
Length = [01H - 08H] 2

(LSB) k
! !! ! Downlink Radio Environment: A3/A7 Element Identifier = [29H] 1
Number of Cells = [01H, 02H] 3
Downlink Radio Environment {1..2:
j+1
(LSB) j+2
Reserved = [00] Downlink Signal Strength Raw = [000000] (Ignored) j+5
(MSB) CDMA Target One Way Delay = <any value> j+6
(LSB) j+7
}Downlink Radio Environment
1
TIA-2001.5-C
107 Section 3
3.2.10 A7-Burst Release 1
This A7 interface message is sent from the source BS to the target BS to release a set of 2
resources which have been reserved to support a traffic burst. It may be sent at any time 3
after A7-Burst Response has been received (sent) for the indicated cell(s). This message 4
can also be sent either from the source BS to the target BS or from the target BS to the 5
source BS to terminate a burst early at one or more cells. 6
Reference
Message Type II 4.2.1 Source BS <-> Target BS M
Call Connection Reference 4.2.23 Source BS <-> Target BS O R
Correlation ID 4.2.26 Source BS <-> Target BS O
d
C
Cell Identifier List (Forward) 4.2.6 Source BS <-> Target BS O
a
R
Cell Identifier List (Reverse) 4.2.6 Source BS <-> Target BS O
a
R
b
C
A7 Destination ID 4.2.44 Source BS <-> Target BS O
c
C
Cause (Forward) 4.2.4 Source BS <-> Target BS O
e
C

Cause (Reverse) 4.2.4 Source BS <-> Target BS O
f
C

a. The length field of this element shall be set to 0 if no resources are being released 7
in the indicated direction. 8
b. This element is included if the source BS requires a change to the FPC Mode at the 9
target BS. 10
c. This element is required when this message is sent from the source BS if an A7 11
Originating ID value was included in an A7-Handoff Request Ack message 12
previously received from the target BS for this call association. This element is 13
required when this message is sent from the target BS if an A7 Originating ID value 14
was included in an A7-Handoff Request message previously received from the 15
source BS for this call association. 16
d. This element is required when this message is sent to the target BS to release 17
resources that were reserved but will not be used to support a traffic burst. The value 18
shall be the same as the value in the corresponding A7-Burst Response message. 19
If this element is absent then the Burst Release message shall be interpreted as 20
releasing the entire burst on the specified cell (if a continuation of this burst has been 21
scheduled, the continuation is also considered released). 22
e. This information element is included when the Cell Identifier List (Forward) 23
information element contains cells that are being released. 24
f. This information element is included when the Cell Identifier List (Reverse) 25
information element contains cells that are being released. 26
27
TIA-2001.5-C
Section 3 108
The following table shows the bitmap layout for the A7-Burst Release message. 1
3.2.10 A7-Burst Release
7 6 5 4 3 2 1 0 Octet
Length = [08H] 2
(LSB) 4
(LSB) 6
8
9
(LSB) 10
Length = [04H] 2
4
5
(LSB) 6
! !! ! Cell Identifier List (Forward): A3/A7 Element Identifier = [1AH] 1
j+1
(LSB) j+2
! !! ! Cell Identifier List (Reverse): A3/A7 Element Identifier = [1AH] 1
j+1
(LSB) j+2
TIA-2001.5-C
109 Section 3
3.2.10 A7-Burst Release
7 6 5 4 3 2 1 0 Octet
Length = [02H] 2
Action
Time
Flag
= [0,1]
Reserved
= [0]
ACTION_TIME = [00 0000 11 1111] 4

(LSB) n
! !! ! Cause (Forward): A3/A7 Element Identifier = [08H] 1
Length = [01H] 2
ext = [0] Cause Value = [01H (Radio interface failure)
0EH (Better cell),
51H (FPC initial gain too high)]
3
! !! ! Cause (Reverse): A3/A7 Element Identifier = [08H] 1
Length = [01H] 2
ext = [0] Cause Value = [01H (Radio interface failure)
0EH (Better cell),
51H (FPC initial gain too high)]
3
1
2
TIA-2001.5-C
Section 3 110
3.2.11 A7-Reset 1
This A7 message can be sent between two BSs. It indicates to the receiving entity that the 2
transmitting entity has failed and has lost memory of the connections in progress, 3
connections set up, and associated references. 4
Reference
Message Type II 4.2.1 First BS -> Second BS M
Cause 4.2.4 First BS -> Second BS O R
Software Version 4.2.12 First BS -> Second BS O R
5
The following table shows the bitmap layout for the A7-Reset message. 6
3.2.11 A7-Reset
7 6 5 4 3 2 1 0 Octet
! !! ! Message Type II = [8AH] 1
Length = [01H] 2
ext =
[0]
Cause Value = [07H (OAM&P intervention),
3
! !! ! Software Version: A3/A7 Element Identifier = [31H] 1

7
8
TIA-2001.5-C
111 Section 3
3.2.12 A7-Reset Acknowledge 1
This A7 message can be sent between two BSs. It indicates to the receiving entity that the 2
transmitting entity has cleared all calls and reset all references, and is ready to resume 3
service. 4
Reference
Message Type II 4.2.1 First BS <-Second BS M
Software Version 4.2.12 First BS <- Second BS O R
The following table shows the bitmap layout for the A7-Reset Acknowledge message. 5
3.2.12 A7-Reset Acknowledge
7 6 5 4 3 2 1 0 Octet
! !! ! Message Type II = [8BH] 1
! !! ! Software Version: A3/A7 Element Identifier = [31H] 1

6
7
TIA-2001.5-C
Section 3 112
3.2.13 A7-Paging Channel Message Transfer 1
This A7 interface message is sent from the source BS to the target BS to request the 2
sending of the contained message on the specified paging channels to an MS. 3
Reference
a
C
b
R
c
R
Air Interface Message 4.2.41 Source BS -> Target BS O R
Layer 2 Ack Request/Results 4.2.42 Source BS -> Target BS O
d
C
Physical Channel Info 4.2.2 Source BS -> Target BS O
e
R
a. If this element is included in this message, the value shall be returned in the A7- 4
Paging Channel Message Transfer Ack message. 5
b. This element shall contain the IMSI sent by the MS. 6
c. This element indicates the cells at the target BS on whose paging channel(s) the air- 7
interface message is to be sent. 8
d. This element is included if the source BS wants a Layer 2 acknowledgment from the 9
MS. 10
e. This element indicates the ARFCN to be used for paging. All other fields shall be 11
ignored. 12
The following table shows the bitmap layout for the A7-Paging Channel Message 13
Transfer message. 14
3.2.13 A7-Paging Channel Message Transfer
7 6 5 4 3 2 1 0 Octet
! !! ! Message Type II = [8CH] 1
Length = [04H] 2
4
5
(LSB) 6
Indicator
= [1,0]
Type of Identity
= [110] (IMSI)
3

TIA-2001.5-C
113 Section 3
7 6 5 4 3 2 1 0 Octet
j+1
(LSB) j+2
! !! ! Air Interface Message: A3/A7 Element Identifier = [21H] 1
TIA/EIA/IS-2000 Message Type = <00H to FFH> 3
Air Interface Message Length = <variable> 4
(MSB) Air Interface Message = <any value> 5

(LSB) k
! !! ! Layer 2 Ack Request/Results: A3/A7 Element Identifier = [23H] 1
Length = [01H] 2
Reserved = [0000 000] Layer 2
Ack
= [0/1]
3
! !! ! Physical Channel Info: A3/A7 Element Identifier = [07H] 1
Length =[06H] 2
Reserved = [000] Rev_FCH_Gating
=
[0,1]
Frame Offset = [0H] (ignored) 3
A3 Traffic Channel
Protocol Stack = [000]
(ignored)
Pilot Gating Rate = [00]
(ignored)
ARFCN (high part)
= [000-111]
4
Reserved = [0000] OTD=[0]
(ignored)
Count of Physical
Channels = [000]
(ignored)
6
TIA-2001.5-C
Section 3 114
7 6 5 4 3 2 1 0 Octet
0H (ignored)

0H (ignored)
7
0H (ignored)
0H (ignored)
8
1
TIA-2001.5-C
115 Section 3
3.2.14 A7-Paging Channel Message Transfer Ack 1
This A7 interface message is sent from the target BS to the source BS to report the results 2
of sending an air interface message on the specified paging channel when a layer 2 3
acknowledgment had been requested by the source BS. 4
Reference
a
C
Layer 2 Ack Request/Results 4.2.42 Target BS -> Source BS O
b
C
Cause 4.2.4 Target BS -> Source BS O
c
C
a. This element is included if the A7-Paging Channel Message Transfer contained this 5
element. It contains the value received in that message. 6
b. This element is included to indicate success or failure in receiving a Layer 2 7
acknowledgment from the MS. Either this element or the Cause element shall be 8
present in this message, but not both simultaneously. 9
c. Inclusion of this element indicates a failure to send the paging channel message as 10
requested in the A7-Paging Channel Message Transfer message. 11
The following table shows the bitmap layout for the A7-Paging Channel Message 12
Transfer Ack message. 13
3.2.14 A7-Paging Channel Message Transfer Ack
7 6 5 4 3 2 1 0 Octet
! !! ! Message Type II = [8DH] 1
Length = [04H] 2
4
5
(LSB) 6
! !! ! Layer 2 Ack Request/Results: A3/A7 Element Identifier = [23H] 1
Length = [01H] 2
Reserved = [0000 000] Layer 2
Ack
= [0/1]
3
Length = [01H] 2
3
14
15
TIA-2001.5-C
Section 3 116
3.2.15 A7-Access Channel Message Transfer 1
This A7 interface message is sent from the target BS to the source BS to notify the source 2
BS of the reception of the contained message on the specified access channel. 3
Reference
a
C
Mobile Identity (IMSI) 4.2.3 Target BS -> Source BS O
b
R
Cell Identifier 4.2.5 Target BS -> Source BS O
c
R
Air Interface Message 4.2.41 Target BS -> Source BS O R
a. If this element is included in this message, then the value shall be returned in the A7- 4
Access Channel Message Transfer Ack message. 5
b. This element shall contain the IMSI sent by the MS. 6
c. This element indicates the cell at the target BS on whose access channel the air- 7
interface message was received. 8
The following table shows the bitmap layout for the A7-Access Channel Message 9
Transfer message. 10
3.2.15 A7-Access Channel Message Transfer
7 6 5 4 3 2 1 0 Octet
! !! ! Message Type II = [8EH] 1
Length = [04H] 2
4
5
(LSB) 6
Indicator
= [1,0]
Type of Identity
= [110] (IMSI)
3

! !! ! Cell Identifier: A7 Element Identifier = [0AH] 1
Length = [06H] 2
TIA-2001.5-C
117 Section 3
3.2.15 A7-Access Channel Message Transfer
7 6 5 4 3 2 1 0 Octet
5
(LSB) 6
! !! ! Air Interface Message: A3/A7 Element Identifier = [21H] 1
TIA/EIA/IS-2000 Message Type = <00H to FFH> 3
Air Interface Message Length = <variable> 4
(MSB) Air Interface Message = <any value> 5

(LSB) k
1
2
TIA-2001.5-C
Section 3 118
3.2.16 A7-Access Channel Message Transfer Ack 1
This A7 interface message is sent from the source BS to the target BS to acknowledge the 2
receipt of the A7-Access Channel Message Transfer message. 3
Reference
a
C
a. This field is required if a Correlation ID value was included on the A7-Access 4
Channel Message Transfer message to which this message is a response. 5
The following table shows the bitmap layout for the A7-Access Channel Message 6
Transfer Ack message. 7
3.2.16 A7-Access Channel Message Transfer Ack
7 6 5 4 3 2 1 0 Octet
! !! ! Message Type II = [8FH] 1
Length = [04H] 2
4
5
(LSB) 6
8
TIA-2001.5-C
119 Section 4
occurrences on a specific A
n
interface. Insofar as possible, the same Information Element 10
Identifier shall be used for a given information element when it is used on more than one 11
of the A
n
interfaces. 12
bytes: 15
2, etc. 19
section 3.0. 23
The Information Element Identifier is included for all signaling messages on the A3 and 24
A7 interfaces. 25
All unused and reserved bits are set to 0, unless otherwise indicated. 26
For future expansion purposes, some information elements have fields within them that 27
have been reserved. 28
29
TIA-2001.5-C
Section 4 120
includes a reference to the section where the information element coding can be found 5
and a column indicating on which interface(s) the element is used. A listing of 6
information elements, sorted by name, is included in Table 4.1.5-1, which also specifies 7
the messages in which each information element is used. 8
9
Table 4.1.2-1 A3/A7 Information Element Identifiers Sorted by Identifier Value
Element Name IEI
(Hex)
Interface(s) Reference
A3 Traffic Circuit ID 03H A3 4.2.22
PMC Cause 05H A3 4.2.24
Reverse Pilot Gating Rate 06H A3 4.2.8
Physical Channel Info 07H A7 4.2.2
Cause 08H A3, A7 4.2.4
One Way Propagation Delay Record 09H A3 4.2.28
Cell Identifier 0AH A7 4.2.5
IS-2000 Power Control Info 0BH A3, A7 4.2.46
CDMA Serving One Way Delay 0CH A7 4.2.18
Mobile Identity 0DH A7 4.2.3
CDMA Long Code Transition Info 0EH A3 4.2.31
Quality of Service Parameters 0FH A7 4.2.9
IS-2000 Service Configuration Record 10H A7 4.2.13
Forward Burst Radio Info 11H A7 4.2.10
Reverse Burst Radio Info 12H A7 4.2.11
Correlation ID 13H A3, A7 4.2.26
IS-2000 Forward Power Control Mode 14H A3, A7 4.2.47
IS-2000 FPC Gain Ratio Info 15H A3, A7 4.2.48
Channel Element ID 17H A3 4.2.32
Channel Element Status 18H A3 4.2.34
Cause List 19H A3, A7 4.2.35
Cell Identifier List 1AH A3, A7 4.2.6
A3 Connect Information 1BH A3 4.2.37
A3 Connect Ack Information 1CH A3 4.2.38
Privacy Info 1DH A7 4.2.36
A3 Drop Information 1EH A3 4.2.40
A3 Remove Information 20H A3 4.2.39
TIA-2001.5-C
121 Section 4
Table 4.1.2-1 A3/A7 Information Element Identifiers Sorted by Identifier Value
Element Name IEI
(Hex)
Interface(s) Reference
Air Interface Message 21H A7 4.2.41
IS-95 Channel Identity 22H A7 4.2.59
Layer 2 Ack Request/Results 23H A7 4.2.42
Downlink Radio Environment 29H A7 4.2.7
A7 Originating ID 2CH A7 4.2.43
A7 Destination ID 2DH A3, A7 4.2.44
Software Version 31H A7 4.2.12
Rescue Request Info 32H A7 4.2.61
Record
33H A7 4.2.27
Call Connection Reference 3FH A3, A7 4.2.23
Neighbor List 48H A7 4.2.19
A3 Signaling Address 49H A7 4.2.20
SDU ID 4CH A3, A7 4.2.21
A3 Destination ID 55H A3 4.2.45
Band Class 5DH A7 4.2.25
FCH/DCCH Forward Air Interval Control 62H A3 4.2.49
FCH/DCCH Reverse Air Interval Control 63H A3 4.2.50
SCH Reverse Air Interval Control 65H A3 4.2.51
A7 Burst Retry Delay List 70H A3 4.2.58
A3 Traffic IP Address 71H A3 4.2.62
Cell Commitment Info List 72H A3,A7 4.2.56
Extended Neighbor List 73H A3/A7 4.2.57
Forward 20 ms Data None A3 4.2.52
Forward 5 ms Data None A3 4.2.54
Forward Layer 3 Data None A3 4.2.29
Forward Layer 3 IS-2000 FCH/DCCH Data None A3 4.2.14
Forward Layer 3 IS-2000 SCH Data None A3 4.2.16
Message CRC None A3 4.2.33
Message Type II None A3/A7 4.2.1
Reverse 20 ms Data None A3 4.2.53
Reverse 5 ms Data None A3 4.2.55
Reverse Layer 3 Data None A3 4.2.30
Reverse Layer 3 IS-2000 FCH/DCCH Data None A3 4.2.15
Reverse Layer 3 IS-2000 SCH Data None A3 4.2.17
TIA-2001.5-C
Section 4 122
4.1.3 A3 and A7 Interface Information Elements 1
All information elements carried exclusively on the A3 and A7 interfaces in signaling 2
messages (i.e. excluding IEs carrying control channel and traffic frames or the Message 3
Type II and the Message CRC IEs) shall be coded with an Information Element 4
Identifier, a Length field, and a value part as shown in the following figure. 5
Information Element Identifier
Length
Value
6
Figure 4.1.3-1 A3/A7 Information Element Generic Layout 7
The value component of the information element may be composed of one or more fields 8
of varying sizes. 9
Elements 11
occurrences on a specific A3 and A7 interfaces. Insofar as possible, the same Information 13
than one of the A3 and A7 interfaces. 15
Where the description of the information element in this standard contains unused bits, 18
implementation, messages shall not be rejected simply because a spare bit is set to 1. 20
a message may contain an information element, the content of which is zero length. This 22
shall be interpreted by the receiver as equivalent to that information element being 23
absent. 24
The following table provides a cross reference between the elements and the messages 26
defined in this specification. 27
TIA-2001.5-C
123 Section 4
Table 4.1.5-1 Cross Reference of Information Elements with Messages
A3 Connect Ack Information 4.2.38 1CH A3-Connect Ack 3.1.2
A3 Connect Information 4.2.37 1BH A3-Connect 3.1.1
A3 Destination ID 4.2.45 55H A3-Remove Ack 3.1.4
A3-Propagation Delay
Measurement Report
3.1.6
A3-Physical Transition
Directive
3.1.7
Directive Ack
3.1.8
A3-Traffic Channel Status 3.1.9
A3 Drop Information 4.2.40 1EH A3-Drop 3.1.5
A3 Remove Information 4.2.39 20H A3-Remove 3.1.3
A3 Signaling Address 4.2.20 49H A7-Handoff Request 3.2.1
A3 Traffic Circuit ID 4.2.22 03H A3-Physical Transition
Directive
3.1.7
A3 Traffic IP Address 4.2.62 71H A3-Connect 3.1.1
A3-Connect Ack 3.1.2
A3-Remove 3.1.3
A3-Drop 3.1.5
Directive
3.1.7
A7 Burst Retry Delay List 4.2.58 70H A7-Burst Response 33
A7 Destination ID 4.2.44 2DH A3-Propagation Delay
Measurement Report
3.1.6
A3 Remove Ack 3.1.4
Directive Ack
3.1.8
A7-Handoff Request Ack 3.2.2
A7-Drop Target 3.2.3
A7-Drop Target Ack 3.2.4
A7-Target Removal Request 3.2.5
A7-Target Removal Response 3.2.6
A7-Burst Request 3.2.7
A7-Burst Response 3.2.8
A7-Burst Commit 3.2.9
A7-Burst Release 3.2.10
A7 Originating ID 4.2.43 2CH A7-Handoff Request 3.2.1
TIA-2001.5-C
Section 4 124
Air Interface Message 4.2.41 21H A7-Access Channel Message
Transfer
3.2.15
A7-Paging Channel Message
Transfer
3.2.13
Band Class 4.2.25 5DH A7-Handoff Request 3.2.1
Call Connection Reference 4.2.23 3FH A3-Physical Transition
Directive
3.1.7
Directive Ack
3.1.8
A3-Connect 3.1.1
A3-Drop 3.1.5
Measurement Report
3.1.6
A3-Remove 3.1.3
A3-Remove Ack 3.1.4
A7-Handoff Request 3.2.1
Cause 4.2.4 08H A7-Paging Channel Message
Transfer Ack
3.2.14
A7-Reset 3.2.11
A3 -Remove Ack 3.1.4

Cause List 4.2.35 19H A3-Drop 3.1.5
TIA-2001.5-C
125 Section 4
CDMA Long Code Transition Info 4.2.31 0EH A3-Physical Transition
Directive
3.1.7
CDMA Serving One Way Delay 4.2.18 0CH A7-Handoff Request 3.2.1
Cell Commitment Info List 4.2.56 72H A7-Handoff Request Ack 3.2.2
Cell Identifier 4.2.5 0AH A7-Access Channel Message
Transfer
3.2.15
Cell Identifier List 4.2.6 1AH A3-Traffic Channel Status 3.1.9
Transfer
3.2.13
Directive Ack
3.1.8
Channel Element ID 4.2.32 17H A3-Physical Transition
Directive
3.1.7
Channel Element Status 4.2.34 18H A3-Traffic Channel Status 3.1.9
Correlation ID 4.2.26 13H A3-Connect 3.1.1
A3-Remove 3.1.3
A3-Remove Ack 3.1.4
A7-Access Channel Message
Transfer
3.2.15
Transfer Ack
3.2.16
TIA-2001.5-C
Section 4 126
Transfer
3.2.13
Transfer Ack
3.2.14
Downlink Radio Environment 4.2.7 29H A7-Handoff Request 3.2.1
Extended Neighbor List 4.2.57 73H A7-Handoff Request Ack 3.2.2
FCH/DCCH Forward Air Interval
Control
4.2.49 62H A3-FCH Forward Traffic
Frame
3.1.18
A3-DCCH Forward Traffic
Frame
3.1.20
FCH/DCCH Reverse Air Interval
Control
4.2.50 63H A3-DCCH Reverse Traffic
Frame
3.1.21
A3-FCH Reverse Traffic
Frame
3.1.19
Forward 20 ms Data 4.2.52 None A3-FCH Forward Traffic
Frame
3.1.18
Frame
3.1.20
Forward 5 ms Data 4.2.54 None A3-FCH Forward Traffic
Frame
3.1.18
Frame
3.1.20
Forward Burst Radio Info 4.2.10 11H A7-Burst Request 3.2.7
Forward Layer 3 Data 4.2.29 None A3-IS-95 FCH Forward 3.1.10
Forward Layer 3 IS-2000 FCH/DCCH
Data
4.2.14 None A3-IS-2000 FCH Forward 3.1.12
A3-IS-2000 DCCH Forward 3.1.14
Forward Layer 3 IS-2000 SCH Data 4.2.16 None A3-IS-2000 SCH Forward 3.1.16
IS-2000 FPC Gain Ratio Info 4.2.48 15H A7-Handoff Request 3.2.1
Directive
3.1.7
IS-2000 Forward Power Control Mode 4.2.47 14H A3-Physical Transition
Directive
3.1.7
TIA-2001.5-C
127 Section 4
IS-2000 Power Control Info 4.2.46 0BH A7-Handoff Request 3.2.1
Directive
3.1.7
4.2.27 33H A7-Handoff Request 3.2.1
IS-2000 Service Configuration Record 4.2.13 10H A7-Handoff Request 3.2.1
IS-95 Channel Identity 4.2.59 22H A7-Handoff Request 3.2.1
Layer 2 Ack Request/Results 4.2.42 23H A7-Paging Channel Message
Transfer
3.2.13
Transfer Ack
3.2.14
Message CRC 4.2.33 None A3-IS-95 FCH Forward 3.1.10
A3-IS-95 FCH Reverse 3.1.11
A3-IS-2000 DCCH Reverse 3.1.15
A3-IS-2000 FCH Forward 3.1.12
A3-IS-2000 SCH Forward 3.1.16
A3-IS-2000 SCH Reverse 3.1.17
A3-FCH Forward Traffic
Frame
3.1.18
Frame
3.1.20
Frame
3.1.19
A3-DCCH Reverse Traffic
Frame
3.1.21
A3-SCH Reverse Traffic
Frame
3.1.22
Message Type II 4.2.1 None A3-Physical Transition
Directive
3.1.7
Directive Ack
3.1.8
A3-IS-95 FCH Forward 3.1.10
A3-Connect 3.1.1
TIA-2001.5-C
Section 4 128
A3-Drop 3.1.5
A3 IS-2000 FCH Forward 3.1.12
A3 IS-2000 FCH Reverse 3.1.13

Measurement Report
3.1.6
A3-Remove 3.1.3
A3-Remove Ack 3.1.4
A3 IS-2000 SCH Forward 3.1.16
A3 IS-2000 SCH Reverse 3.1.17
Transfer
3.2.15
Transfer Ack
3.2.16
Transfer
3.2.13
Transfer Ack
3.2.14
A7-Reset 3.2.11
A7-Reset Acknowledge 3.2.12
A3-FCH Forward Traffic
Frame
3.1.18
Frame
3.1.20
Frame
3.1.19
Frame
3.1.21
Frame
3.1.22
TIA-2001.5-C
129 Section 4
Mobile Identity 4.2.3 0DH A7 Burst Request 3.2.7
Transfer
3.2.15
Transfer
3.2.13
Neighbor List 4.2.19 48H A7-Handoff Request Ack 3.2.2
One way Propagation Delay Record 4.2.28 09H A3-Propagation Delay
Measurement Report
3.1.6
Physical Channel Info 4.2.2 07H A7-Handoff Request 3.2.1
Transfer
3.2.13
PMC Cause 4.2.24 05H A3-Physical Transition
Directive Ack
3.1.8
Privacy Info 4.2.36 1DH A7-Handoff Request 3.2.1
Directive
3.1.7
Quality of Service Parameters 4.2.9 0FH A7-Handoff Request 3.2.1
Rescue Request Info 4.2.61 32H A7-Handoff Request 3.2.1
Reverse 20 ms Data 4.2.53 None A3-FCH Reverse Traffic
Frame
3.1.19
Frame
3.1.21
Frame
3.1.22
Reverse 5 ms Data 4.2.55 None A3-FCH Reverse Traffic
Frame
3.1.19
Frame
3.1.21

Reverse Burst Radio Info 4.2.11 12H A7-Burst Request 3.2.7
Reverse Layer 3 Data 4.2.30 None A3-IS-95 FCH Reverse 3.1.11
Reverse Layer 3 IS-2000 FCH/DCCH
Data
4.2.15 None A3-IS-2000 FCH Reverse 3.1.13
Reverse Layer 3 IS-2000 SCH Data 4.2.17 None A3-IS-2000 SCH Reverse 3.1.17
Reverse Pilot Gating Rate 4.2.8 06H A3-Physical Transition
Directive
3.1.7
TIA-2001.5-C
Section 4 130
SCH Reverse Air Interval Control 42.51 65H A3-SCH Reverse Traffic
Frame
3.1.22
SDU ID 4.2.21 4CH A3-Physical Transition
Directive Ack
3.1.8
A3-Connect 3.1.1
Measurement Report
3.1.6
A3-Remove 3.1.3
Software Version 4.2.12 31H A7-Reset 3.2.11
A7-Reset Acknowledge 3.2.12
1
2
TIA-2001.5-C
131 Section 4
2
4.2.1 Message Type II 3
The Message Type II element is used to indicate the type of a message on the A3 and A7 4
interfaces. 5
Element Format: 6
4.2.1 Message Type II
7 6 5 4 3 2 1 0 Octet
Message Type II 1
7
Table 4.2.1-1 A3 and A7 Message Type II Values

Message Name
Message
Type II
Value

Interface

Section
Reference
A3-Connect 01H A3 3.1.1
A3-Connect Ack 02H A3 3.1.2
A3-Remove 03H A3 3.1.3
A3-Remove Ack 04H A3 3.1.4
A3-Drop 05H A3 3.1.5
A3-Propagation Delay Measurement Report 06H A3 3.1.6
A3-IS-95 FCH Forward 07H A3 3.1.10
A3-IS-95 FCH Reverse 08H A3 3.1.11
A3-Physical Transition Directive 09H A3 3.1.7
A3-Physical Transition Directive Ack 0AH A3 3.1.8
A3-IS-2000 FCH Forward 0BH A3 3.1.12
A3-IS-2000 FCH Reverse 0CH A3 3.1.13
A3-Traffic Channel Status 0DH A3 3.1.9
A3-IS-2000 DCCH Forward 0EH A3 3.1.14
A3-IS-2000 DCCH Reverse 0FH A3 3.1.15
A3-IS-2000 SCH Forward 10H A3 3.1.16
A3-IS-2000 SCH Reverse 11H A3 3.1.17
A3-FCH Forward Traffic Frame 12H A3 3.1.18
A3-DCCH Forward Traffic Frame 13H A3 3.1.20
A3-FCH Reverse Traffic Frame 15H A3 3.1.19
A3-DCCH Reverse Traffic Frame 16H A3 3.1.21
A3-SCH Reverse Traffic Frame 17H A3 3.1.22
TIA-2001.5-C
Section 4 132
Table 4.2.1-1 A3 and A7 Message Type II Values

Message Name
Message
Type II
Value

Interface

Section
Reference
A7-Handoff Request 80H A7 3.2.1
A7-Handoff Request Ack 81H A7 3.2.2
A7-Drop Target 82H A7 3.2.3
A7-Drop Target Ack 83H A7 3.2.4
A7-Target Removal Request 84H A7 3.2.5
A7-Target Removal Response 85H A7 3.2.6
(unused value available) 86H
A7-Reset 8AH A7 3.2.11
A7-Reset Acknowledge 8BH A7 3.2.12
A7-Paging Channel Message Transfer 8CH A7 3.2.13
A7-Paging Channel Message Transfer Ack 8DH A7 3.2.14
A7-Access Channel Message Transfer 8EH A7 3.2.15
A7-Access Channel Message Transfer Ack 8FH A7 3.2.16
A7-Burst Request 90H A7 3.2.7
A7-Burst Response 91H A7 3.2.8
A7-Burst Commit 92H A7 3.2.9
A7-Burst Release 93H A7 3.2.10
1
TIA-2001.5-C
133 Section 4
4.2.2 Physical Channel Info 1
This element provides information about a set of physical channels for a call association. 2
4.2.2 Physical Channel Info
7 6 5 4 3 2 1 0 Octet
A3/A7 Element Identifier 1
Length 2
Reserved Rev_FCH_
Gating
Frame Offset 3
A3 Traffic Channel
Protocol Stack
Pilot Gating Rate
(MSB) 4
ARFCN
(LSB) 5
Reserved OTD Count of Physical Channels 6
Physical Channel 2 Physical Channel 1 7
Physical Channel 4 Physical Channel 3 8
Length: 3
Length field. This field shall be set to 06H. 5
Rev_FCH_Gating: 6
This field is used to indicate reverse FCH gating capability. It is set to 7
1 if the BS allows the MS to perform reverse FCH gating; otherwise 8
it is set to 0. 9
Frame Offset: 10
This field indicates the frame offset for the given physical channel. 11
A3 Traffic Channel Protocol Stack: 12
This field indicates the protocol stack to be used with A3 traffic 13
channels attached to the given physical channels. Valid values are 14
shown in Table 4.2.2-1. 15
When using an ATM-based protocol stack, the VCCI and CID are used 16
for addressing. When using an IP-based protocol stack, the IP address 17
and port number are used for addressing. 18
Table 4.2.2-1 A3 Traffic Channel Protocol Stack 19
Binary Value Protocol Stack
001 AAL2 / ATM / Physical Layer
010 UDP / IP / L2 / Physical Layer (IP-Based)
Pilot Gating Rate: 20
The actual Reverse Pilot Gating Rate. This field is used to indicate the 21
gating rate for the Reverse Pilot channel as shown in Table 4.2.2-2. 22
This field is used for the DCCH. If the FCH is being used this field is 23
set to 00 (i.e. there is no pilot gating on the FCH). 24
TIA-2001.5-C
Section 4 134
Table 4.2.2-2 Reverse Pilot Gating Rate 1
00 Gating rate 1
01 Gating rate 1/2
10 Gating rate 1/4
11 Reserved
ARFCN: 2
This field indicates the Absolute Radio Frequency Channel Number 3
relative to the band class for the call association. For 3X systems, the 4
channel number refers to the center frequency channel. 5
NOTE: The Frame Offset, A3 Traffic Channel Protocol Stack, Pilot Gating Rate and 6
ARFCN are the same for ALL physical channels of a call association. 7
OTD: 8
to 0 otherwise. 10
Count of Physical Channels: 11
The number of physical channels represented in this element. In this 12
version of the standard the value shall be 1H, 2H, 3H, or 4H. If the 13
value is 1H, then Physical Channel 2, Physical Channel 3, and Physical 14
Channel 4 shall be coded as 0000. If the value is 02H, then Physical 15
Channel 3 and Physical Channel 4 shall be coded as 0000. If the value 16
is 03H, then Physical Channel 4 shall be coded as 0000. 17
Physical Channel n: 18
These fields contain the binary values used to indicate the type of 19
physical channel associated with the indicated cells. Valid values are 20
shown in Table 4.2.2-3. 21
Table 4.2.2-3 Physical Channel Info - Physical Channel 22
Value (hex) Physical Channel Type
0H IS-95 Fundamental Channel TIA/EIA/IS-95
1H Fundamental Channel (FCH) TIA/EIA/IS-2000
2H Supplemental Channel (SCH_0) TIA/EIA/IS-2000
3H Dedicated Control Channel (DCCH) TIA/EIA/IS-2000
23
24
TIA-2001.5-C
135 Section 4
Serial Number (ESN) or the International Mobile Subscriber Identity (IMSI). 3
Reserved field. The following is the Mobile Identity element coding: TIA/EIA/IS-2000. 6
Warning: The length limit for this information element was 10 octets in IOS v2.0a, IOS 7
v2.1, and IOS v3.0.0. Care needs to be exercised for interoperability with 8
implementations based on the previous standard. 9
7 6 5 4 3 2 1 0 Octet
Length 2
Indicator
Type of Identity 3

The Length field is defined as the number of octets following the Length field. 10
The Type of Identity is defined as follows: 11

101 ESN
110 IMSI
The Odd/Even Indicator (octet 3; bit 3) field is set to 0 for an even number of digits and 13
to 1 for an odd number of identity digits. 14
The identity digits (octet 3 etc.) are coded as follows: 15
The International Mobile Subscriber Identifier fields are coded using BCD coding format. 16
If the number of identity digits is even then bits 4 to 7 of the last octet shall be filled with 17
an end mark coded as 1111. 18
19
TIA-2001.5-C
Section 4 136
The ESN is not separated into digits, and occupies octets 4-7 with the most significant bit 1
in octet 4 bit 7. Identity Digit 1 in octet 3 is unused and coded as 0000. 2
3
7 6 5 4 3 2 1 0 Octet
Length 2
Reserved Type of Identity 3
Priority Message ID 4
Zone ID 5
(MSB) Service 6
(LSB) 7
Language 8
Length: 4
Length field. 6
Type of Identity: 7
This field is defined as shown in Table 4.2.3-1 above. 8
9
10
11
12
TIA-2001.5-C
137 Section 4
4.2.4 Cause 1
4.2.4 Cause
7 6 5 4 3 2 1 0 Octet
Length 2
0/1 Cause Value 3
A Cause information element exists for multiple interfaces. The cause values defined in 4
this document are specific to the A7 interface. 5
The Length is defined as the number of octets following the Length field. 6
The Cause Value field is a single octet field if the extension bit (bit 7) is set to 0. If bit 7 7
of octet 3 is set to 1 then the cause value is a two octet field. If the value of the first 8
octet of the cause field is 1XXX 0000 then the second octet is reserved for national 9
applications, where XXX indicates the Cause Class as indicated in the table below. 10
Table 4.2.4-1 Cause Class Values 11
000 Normal event
001 Normal event
010 Resource Unavailable
110 Protocol error
111 Interworking
12
13
TIA-2001.5-C
Section 4 138
Table 4.2.4-2 Cause Values 1
6 5 4 3 2 1 0 Hex
Value
Cause
0 0 0 0 0 0 1 01 Radio interface failure
0 0 0 0 0 1 0 02 Uplink quality
0 0 0 0 0 1 1 03 Uplink strength
0 0 0 0 1 0 0 04 Downlink quality
0 0 0 0 1 0 1 05 Downlink strength
0 0 0 1 1 1 0 0E Better cell (power budget)
0 0 1 0 0 1 0 12 Invalid call
0 1 0 0 0 0 1 21 No radio resource available
0 1 0 0 1 0 1 25 BS not equipped
0 1 0 0 1 1 1 27 2G only sector
0 1 0 1 0 0 0 28 2G only carrier
0 1 1 0 1 0 1 35 Requested FPC mode change failed
1 0 0 0 0 0 0 40 Ciphering algorithm not supported
1 0 0 0 0 0 1 41 Private long code not available or not supported.
1 0 0 0 0 1 0 42 Requested MUX option or rates not available.
1 0 0 0 0 1 1 43 Requested privacy configuration unavailable
1 0 0 0 1 0 0 44 SCH not supported
1 0 1 0 0 0 1 51 FPC initial gain too high
1 1 0 1 1 1 1 6F Invalid call connection reference
All other values
2
3
TIA-2001.5-C
139 Section 4
4.2.5 Cell Identifier 1
This element uniquely identifies a particular cell and is of variable length depending on 2
how the cell is identified. The fields of this element are shown below: 3
4.2.5 Cell Identifier
7 6 5 4 3 2 1 0 Octet
Length 2
Cell Identification Var.
Length: 4
Length field. The length depends on the Cell Identification 6
Discriminator (octet 3). 7
Cell Identifier Discriminator: 8
The Cell Identification Discriminator is a binary number indicating if 9
the whole or a part of the Cell Global Identification (e.g., one or more 10
of the following: MCC, MNC, LAC, MSCID, CI) is used for cell 11
identification in octets 4 through n. The Cell Identification 12
Discriminator is coded as follows: 13
Table 4.2.5-1 Cell Identifier - Cell Identification Discriminator List 14
0000 0111
a
IS-41 whole Cell Global Identification is used to identify the cell.
a. When the Cell Identifier is used to identify a cell controlled by another MSC, type 15
0000 0111 is used. 16
Cell Identifier: 17
referenced. It is coded as indicated below, depending on the value of 19
the Cell Identifier Discriminator. The fields shall be coded as shown 20
below: 21
7 6 5 4 3 2 1 0 Octet
MSCID 4
5
6
Cell 7
Sector 8
MSCID: 23
TIA-2001.5-C
Section 4 140
Cell/Sector: 3
In the CI value field bit 7 of octet 7 is the most significant bit and bit 0 4
of octet 8 is the least significant bit. Bits 3 to 0 of octet 8 contain the 5
sector number (0H = omni). The coding of the cell identity is the 6
responsibility of each administrator. Coding using full hexadecimal 7
representation may be used. The cell identity consists of 2 octets 8
maximum. If an administration has chosen N bits for the cell identity 9
where N <16 then the additional bits up to 16 are coded with a 0 in 10
each in the following way: 11
each. 13
17
18
TIA-2001.5-C
141 Section 4
4.2.6 Cell Identifier List 1
fields: 3
4.2.6 Cell Identifier List
7 6 5 4 3 2 1 0 Octet
Length 2

The Length field is a binary value indicating the number of octets following the Length 4
field. [126] The Cell Identification Discriminator and Cell Identification fields are coded 5
as in the Cell Identifier information element; refer to 4.2.5. 6
7
TIA-2001.5-C
Section 4 142
4.2.7 Downlink Radio Environment 1
This element includes signal strength measurement information that was made by the 2
MS. It is of variable length and is coded as follows: 3
4.2.7 Downlink Radio Environment
7 6 5 4 3 2 1 0 Octet
Length 2
Number of cells 3
Cell Identification 1 5-k
Reserved Downlink Signal Strength Raw k+1
CDMA Target One Way Delay (high part) k+2
CDMA Target One Way Delay (low part) k+3

Cell Identification n m-n
Reserved Downlink Signal Strength Raw n+1
CDMA Target One Way Delay (high part) n+2
CDMA Target One Way Delay (low part) n+3
Octet 3 indicates the number of cells represented by this element. For each cell, the Cell 5
Identification, Downlink Signal Strength Raw, and CDMA Target One Way Delay fields 6
are replicated. 7
In octet 4, the Cell Identification Discriminator is coded per section 4.2.5. It applies to all 8
Cell Identification fields present in this element. 9
The Cell Identification is coded as per the equivalent octets described in section 4.2.5, 10
and shall uniquely identify one cell. Only one cell can be indicated per replication. 11
Downlink Signal Measurement Raw is an average signal level measured by the MS for 12
the specified cell. The method of measurement is unique to the signaling system. The 13
signal level is the last measurement average received from the MS in its raw, not 14
normalized format. 15
The range of values for this field is 0 to 63 where the units are defined by 16
! "
2 10
10
log PS
17
where PS is the strength of this pilot measured as the sum of ratios of received 18
pilot energy per chip to the total received spectral density (noise and signals) 19
of at most k usable multi-path components, where k is the number of 20
demodulating elements supported by the MS. 21
TIA-2001.5-C
143 Section 4
The CDMA Target One Way Delay field shall contain the estimated one-way delay from 1
the MS to the associated target cell, according to the information reported by the MS. 2
The CDMA Target One Way Delay is specified as a twos-compliment value, expressed 3
in units of 100 ns. 4
The BS calculates the value of the CDMA Target One Way Delay as follows: 5
! (Target PN phase measured by the MS - Target pilot offset index 64 + 6
CDMA Serving One Way Delay in PN chips) / 0.12288 " 7
where: 8
The target PN phase is reported by the MS in the Pilot Strength 9
Measurement Message. 10
The target pilot offset index is derived by the BS from information in 11
the Pilot Strength Measurement Message. 12
The CDMA Serving One Way Delay is maintained in information 13
known to the one way propagation delay estimated by the BS in 14
relation to CDMA System Time, refer to [2]. Refer also to section 15
4.2.18, CDMA Serving One Way Delay. 16
17
TIA-2001.5-C
Section 4 144
4.2.8 Reverse Pilot Gating Rate 1
This element indicates the Reverse Pilot Gating Rate to be used by the MS as well as the 2
explicit time of transition to the new gating rate. The BTS uses this information to 3
process inner loop power control. 4
4.2.8 Reverse Pilot Gating Rate
7 6 5 4 3 2 1 0 Octet
Length 2
Reserved Pilot Gating Rate 3
ACTION_TIME 4
Length: 5
Length field. 7
Reserved: 8
All reserved bits shall be set to 0. 9
Pilot Gating Rate: 10
The actual Reverse Pilot Gating Rate. This field is used to indicate the 11
gating rate for the Reverse Pilot channel as shown in Table 4.2.8-1. 12
This field is used for the DCCH. If the FCH is being used, then this 13
field is set to 00, i.e., there is no pilot gating on the FCH. 14
Table 4.2.8-1 Reverse Pilot Gating Rate - Pilot Gating Rate 15
00 No Gating
01 Gating rate 1/2
10 Gating rate 1/4
11 Reserved
ACTION_TIME: 16
This field shall be set by the BS to the CDMA System Time (refer to 17
[1]~[6]) in units of 80 ms (modulo 64) at which the transition to the 18
new reverse pilot gating rate is to take effect. This field shall have the 19
same setting as was conveyed to the MS in a Resource Allocation 20
Message, Resource Allocation Mini-Message, Universal Direction 21
Handoff Message, Extended Release Message, or Extended Release 22
Mini-Message on the forward traffic channel (refer to [5]). The action 23
time value conveyed to the MS is derived by taking the least significant 24
6 bits of this 8-bit field. 25
26
TIA-2001.5-C
145 Section 4
This element identifies the Quality of Service for a given packet service. In this version 2
of this standard the only information carried is non-assured mode packet priority. 3
7 6 5 4 3 2 1 0 Octet
Length 2
Length: 4
Length field. 6
Reserved: 7
13
TIA-2001.5-C
Section 4 146
4.2.10 Forward Burst Radio Info 1
This element contains information on the radio resources requested/committed by the 2
source/target BS for a Forward link traffic burst. 3
4.2.10 Forward Burst Radio Info
7 6 5 4 3 2 1 0 Octet
Length 2
Forward Burst Radio I nfo {1,2:
Coding Indicator SCH_ID QOF Mask Forward Code Channel Index
(high part)
n
Forward Code Channel Index (low part) n+1
Pilot PN
Code
(high part)
Reserved CCSH
Encoder
Type
Forward Supplemental Channel Rate n+3
Reserved Forward Supplemental Channel Start Time n+4
SR3_Incl Start Time Unit Forward Supplemental Channel Duration n+5
Reserved Lower QOF Mask Upper Forward Code Channel
Index (high part)
n+6
Lower Forward Code Channel Index (low part) n+7
Reserved Upper QOF Mask Lower Forward Code Channel
Index (high part)
n+8
Upper Forward Code Channel Index (low part) n+9
} Forward Burst Radio I nfo
Length: 4
Length field. 6
Coding Indicator: 7
This field indicates the type of channel coding to be applied to the 8
supplemental channel (SCH) during the duration of the traffic burst. 9
Table 4.2.10-1 Forward Burst Radio Info Coding Indicator 10
Value Privacy Mask Type
00 Convolutional Coding
01 Turbo Coding
QOF Mask: 11
This field contains the QOF (Quasi Orthogonal Function) mask index, 12
as indexed in [2]. For 3X Multi-Carrier systems, this QOF mask is used 13
with the center frequency channel. 14
TIA-2001.5-C
147 Section 4
SCH ID: 1
This field identifies the Forward Supplemental Channel to which the 2
Burst Radio Info element is associated. 3
Forward Code Channel Index: 4
call. For 3X 6
Multi-Carrier systems, this Walsh code is used with the center 7
frequency channel. 8
Pilot PN Code: 9
CCSH Encoder Type: 12
This bit indicates the type of turbo encoder to be applied to the 13
supplemental channel (SCH) during the duration of the traffic burst. A 14
value of 0 indicates default encoder type, and a value of 1 indicates 15
complementary encoder type. If CCSH encoding is not being used, then 16
this field shall be set to default encoder type 0. 17
Forward Supplemental Channel Rate: 18
This field indicates the bandwidth on the forward SCH to be used for 19
the traffic burst. The field shall be coded as in the Extended 20
Supplemental Channel Assignment Message (ESCAM) in [5]. In the 21
case of a burst extension (refer to definition of burst extension in 22
section 2.2.14.1), this field shall contain the same value in the A7-Burst 23
Request, A7-Burst Response and A7-Burst Commit messages. 24
Forward Supplemental Channel Start Time: 25
This field indicates the System Time, in Burst Action Time Units, 26
specified by the Start Time Unit field (modulo 32), at which the burst is 27
to start. 28
A burst start time that is more than 7/8 of the modulo window in the 29
future, from its time of arrival, shall be considered late and the message 30
shall be processed immediately. In the case of a burst extension (refer 31
to definition of burst extension in section 2.2.14.1), this field shall 32
contain the same value in the A7-Burst Request, A7-Burst Response 33
and A7-Burst Commit messages. 34
SR3_Incl: 35
This field indicates the use of Spreading Rate 3 (3X). The bit shall be 36
set to 1 if 3X Multi-Carrier is being used, and set to 0 otherwise. 37
Start Time Unit: 38
This field indicates the units of Forward Supplemental Channel Start 39
Time. This field shall be set to one less than the number of 20 ms 40
frames that determines the Start Time Unit. 41
Forward Supplemental Channel Duration: 42
This field contains a binary value indicating the duration of a burst. 43
This field shall be set to 0000 to indicate that the burst in effect at the 44
time this message is received is to stop at the Burst Action Time. The 45
field shall be coded to 1111 to indicate a burst of infinite duration 46
starting at Burst Action Time. Other values for this field are set 47
according to Table 3.7.3.3.2.37-3 of [5]. 48
TIA-2001.5-C
Section 4 148
Lower QOF Mask: 1
as specified in [2] that is used with the lower frequency channel in a 3X 3
system. This field is ignored if SR3_Incl is set to 0. 4
Lower Walsh Code Channel Index: 5

call. The high 7
with the lower frequency channel. This field is ignored if SR3_Incl is 9
set to 0. 10
Upper QOF Mask: 11
as specified in [2] that is used with the upper frequency channel in a 3X 13
Upper Walsh Code Channel Index: 15

call. The high 17
with the upper frequency channel. This field is ignored if SR3_Incl is 19
set to 0. 20
21
TIA-2001.5-C
149 Section 4
4.2.11 Reverse Burst Radio Info 1
This element contains information on the radio resources requested/committed by the 2
source/target BS for a Reverse link traffic burst. 3
4.2.11 Reverse Burst Radio Info
7 6 5 4 3 2 1 0 Octet
Length 2
Coding Indicator Reserved Reverse Supplemental Channel Rate 3
1111]
4
Rev
Walsh ID
Start Time Unit Reverse Supplemental Channel Duration 5
Reserved Rev_Burst_DTX_Duration 6
Length: 4
Length field. 6
Coding Indicator: 7
This field indicates the type of channel coding to be applied to the 8
supplemental channel (SCH) during the duration of the traffic burst. 9
Table 4.2.11-1 Reverse Burst Radio Info Coding Indicator 10
00 Convolutional Coding
01 Turbo Coding
Reverse Supplemental Channel Rate: 11
This field indicates the bandwidth on the Reverse SCH to be used for 12
the traffic burst. The field shall be coded as in the Extended 13
Supplemental Channel Assignment Message (ESCAM) in [5]. In the 14
case of a burst extension (refer to definition of burst extension in 15
section 2.2.14.1), this field shall contain the same value in the A7-Burst 16
Request, A7-Burst Response and A7-Burst Commit messages. 17
Reverse Supplemental Channel Start Time: 18
This field indicates the System Time, in Burst Action Time Units, 19
specified by the Start Time Unit field (modulo 32), at which the burst is 20
to start. 21
A burst start time that is more than 7/8 of the modulo window in the 22
future, from its time of arrival, shall be considered late and the message 23
shall be processed immediately. In the case of a burst extension (refer 24
to definition of burst extension in section 2.2.14.1), this field shall 25
contain the same value in the A7-Burst Request, A7-Burst Response 26
and A7-Burst Commit messages. 27
TIA-2001.5-C
Section 4 150
Rev Walsh ID: 1
This field shall be coded as in the Extended Supplemental Channel 2
Assignment Message (ESCAM) in [5], to indicate the Walsh cover ID 3
that the MS is to use when transmitting on the Reverse Supplemental 4
Channel. 5
Start Time Unit: 6
This field indicates the units of Reverse Supplemental Channel Start 7
Time. This field shall be set to one less than the number of 20 ms 8
frames that determines the Start Time Unit. 9
Reverse Supplemental Channel Duration: 10
This field contains a binary value indicating the duration of a burst. 11
This field shall be set to 0000 to indicate that the burst is to stop at the 12
Burst Action Time. The field shall be coded to 1111 to indicate a 13
burst of infinite duration starting at Burst Action Time. Other values for 14
this field are set according to Table 3.7.3.3.2.37-3 of [5]. 15
Rev_Burst_DTX_Duration: 16
This field shall be coded as in the Extended Supplemental Channel 17
Assignment Message (ESCAM) in [5], to indicate the maximum 18
duration of time in units of 20 ms that the MS is allowed to stop 19
transmission on the Reverse SCH before resuming transmission on the 20
Reverse SCH within the reverse assignment burst duration. 21
22
TIA-2001.5-C
151 Section 4
message. Its definition is a BS and MSC manufacturer concern. 3
7 6 5 4 3 2 1 0 Octet
Length 2
Each version of this standard is published with a version number in the form X.Y.Z. 4
These three values shall be placed in octets 3, 4, and 5 respectively as binary values. 5
Each separate software load from a manufacturer shall have some software load identity. 6
In addition, the carrier may require the exchange of specific information between entities 7
in their network. This information shall be placed in octets 6-n in ASCII format as agreed 8
10
TIA-2001.5-C
Section 4 152
This information element contains the service configuration record as defined in [2] for a 2
cdma2000
call and as defined in [10] for a TIA/EIA/IS-95 call. 3

4.2.13 I S-2000 Service Configuration Record
7 6 5 4 3 2 1 0 Octet
(MSB) 4

Seventh
Fill Bit
if needed
Sixth Fill
Bit if
needed
Fifth Fill
Bit if
needed
Fourth
Fill Bit
if needed
Third
Fill Bit
if needed
Second
Fill Bit
if needed
First Fill
Bit if
needed
k
Length field. 6
[1] when the call is TIA/EIA/IS-2000. This field is coded according to 14
[10] when the call is TIA/EIA/IS-95. The value begins in the high order 15
bit position of octet 4 of this element and extends into the last octet of 16
this element. Bit positions in the last octet that are not used, if any, are 17
considered fill bits, are set to 0, and occupy the low order bit positions 18
of the last octet. 19
20
TIA-2001.5-C
153 Section 4
4.2.14 Forward Layer 3 IS-2000 FCH/DCCH Data 1
This element contains the CDMA Forward Fundamental and Dedicated Control Channel 2
Frame and control information for packets flowing in the SDU to BTS direction. 3
4.2.14 Forward Layer 3 I S-2000 FCH/DCCH Data
7 6 5 4 3 2 1 0 Octet
FPC: SLC FSN 1
FPC: GR 2
RPC: OLT 3
IS-2000 Frame Content 4
Forward Link Information Var.
Frame Sequence Number (FSN): 4
The SDU shall set this field to CDMA System Time in frames, modulo 5
16 (refer to 1.2 of [2]) corresponding to the transmission time of the 6
frame over the air in the forward direction. 7
Forward Link Power Control: Sector Link Count (FPC: SLC): 8
This parameter indicates the number of legs (also known as 9
independent power control subchannels) involved in soft handoff. 10
Multiple sectors in softer handoff with each other are counted as a 11
single leg. This is useful for forward link gain equalization. 12
Forward Link Power Control: Gain Ratio (FPC: GR): 13
This parameter is required for QIB/EIB (50Hz) power control. It is also 14
useful during transitions of: soft handoff states, transmission rates, and 15
FER target values. 16
The SDU shall set this field to the binary value of 17
Min(!(A
t
/ A
p
) 128 ", 255 ) 18
where A
t
is the full-rate Forward Link gain (in volts), and A
p
is the 19
smallest Pilot Channel gain (in volts). The SDU shall set the FPC: GR 20
field in the range of 0 through 255. 21
If this field is set to zero, it shall be ignored. 22
Reverse Link Power Control: Outer-loop Threshold (RPC: OLT): 23
For RC1 and RC2, the SDU shall set this field to the desired Reverse 24
Traffic Channel E
w
/N
t
; i.e. the ratio of the total demodulated Walsh 25
symbol energy to total received power spectral density on the RF 26
channel. E
w
/N
t
is thus a composite value. 27
The SDU shall set this field in the range of 0 through 255 28
corresponding to 0dB to 31.875dB in units of 0.125dB. 29
For RC3 and all other higher RC, the SDU shall set this field to the 30
desired Reverse Pilot Ec/Io; i.e. the ratio of R-PICH chip energy to 31
total received power spectral density on the RF channel. 32
The SDU shall set the RPC: OLT field in the range of 0 through 255 33
corresponding to 31.875dB to 0dB in units of 0.125dB. 34
IS-2000 Frame Content: 35
The IS-2000 Frame Content parameter uniquely identifies the data rate 36
and number of information bits. The value is taken from Table 4.2.15- 37
TIA-2001.5-C
Section 4 154
2, Table 4.2.15-3, or Table 4.2.15-4The IS-2000 Frame Content 1
parameter uniquely identifies the symbol repetition rate and number of 2
information bits. 3
Forward Link Information: 4
The SDU shall set this field to the Forward Link Information that the 5
BTS is to send to the MS. The SDU shall include the number of 6
Information Bits from Table 4.2.15-2, Table 4.2.15-3, or Table 4.2.15-4 7
corresponding to the data rate of the Forward Link frame. The SDU 8
shall set the Information Bits to the information bits supplied by the 9
Multiplex Option Sublayer. The bit order shall be as specified in [1]. 10
Layer 3 Fill: 11
The SDU shall include the number of bits in the Layer 3 Fill column of 12
Table 4.2.15-3 or Table 4.2.15-4 corresponding to the data rate of the 13
Traffic Channel frame. The Layer 3 Fill bits shall be set to 0. The fill 14
bits are added at the end of the frame in the lower order bit positions 15
after the Forward Link Information. 16
17
TIA-2001.5-C
155 Section 4
4.2.15 Reverse Layer 3 IS-2000 FCH/DCCH Data 1
This element contains the CDMA Reverse Fundamental and Dedicated Control Channel 2
frame and control information for packets flowing in the BTS to SDU direction. 3
4.2.15 Reverse Layer 3 I S-2000 FCH/DCCH Data
7 6 5 4 3 2 1 0 Octet
Soft Handoff Leg # FSN 1
FQI Reverse Link Quality 2
Scaling Packet Arrival Time Error 3
RPC: S
QIB/
EIB
5
Reverse Link Information + Layer 3 Fill Var.
Soft Handoff Leg #: 4
This field is used to carry the soft handoff leg number as indicated by 5
the source BS on the A3-Connect Ack message. The target BS shall set 6
this field to the value contained in the Soft Handoff Leg # field in the 7
A3 Connect Ack Information element of the A3-Connect Ack message. 8
The BTS shall set this field to CDMA System Time in frames, modulo 10
16 (refer to section 1.3 of [2]) corresponding to the receive time of the 11
air interface frame in the reverse direction. 12
Frame Quality Indicator (FQI): 13
If the traffic frame contains Reverse Link Information, then the BTS 14
shall set the FQI (Frame Quality Indicator) field to 1 if the Reverse 15
Traffic Frame CRC passes, and 0 if the CRC fails. 16
If there is no reverse traffic frame
1
, the BTS shall (using an 17
implementation specific algorithm) set the FQI field to 1 if it can 18
determine that a reverse traffic frame CRC would have passed, and 0 19
otherwise. 20
Reverse Link Quality: 21
If the reverse traffic frame contains Reverse Link Information, then the 22
BTS shall set the Reverse Link Quality field to the Inverted Re- 23
Encoded Symbol Error Rate or equivalent metric. The Inverted Re- 24
Encoded SER is the binary value of: 25
127 - !(Min[Re-Encoded Symbol Error Rate , 255]) / 2" 26
where the value of ! is used to normalize the number of symbols to the 27
1x repetition rate as listed in the IS-2000 Frame Content element. 28
(Reference: [2], Table 2.1.3.1.5-1 Code Symbol Repetition). 29
The Inverted Re-Encoded Symbol Error Rate is the number of errors 30
found when comparing the received symbols at the input of the channel 31
decoder and the re-encoded symbols at the output of the channel 32

1
There is no Reverse Traffic Frame when only a reverse pilot channel exists. For
example, this occurs during call setup before the BTS has acquired the reverse traffic
channel, and it occurs when the DCCH is in DTX mode.
TIA-2001.5-C
Section 4 156
decoder. The Inverted Re-Encoded Symbol Error Rate computation 1
shall include the erasure indicator bit (E), if applicable; the information 2
bits; the frame quality indicator (F), if applicable; and the encoder tail 3
bits (T), if applicable. 4
2
detected by the BTS, the Reverse 5
Link Quality field shall be set to 000 0000. 6
If a frame erasure is detected by the BTS and the channel element has 7
lost finger lock, then Reverse Link Quality field may (optionally) be set 8
to 000 0001 to indicate that the MS is not acquired. If the lost finger 9
lock option is not asserted, then the Reverse Link Quality field shall be 10
set to 000 0000 for all erasures. 11
Scaling: 12
The BTS shall set this field to the time scale for the Packet Arrival 13
Time Error (PATE) field. Values are indicated in the table below. 14
Table 4.2.15-1 Reverse Layer 3 IS-2000 FCH/DCCH Data - Time Scale for the PATE 15
Scaling Field Value Time Units PATE Range
00 0.125 ms 3.875 ms
01 1.0 ms 31.0 ms
10 1.25 ms 38.75 ms
11 5.0 ms 155 ms
Packet Arrival Timer Error (PATE): 16
The BTS shall set this field to the time difference between the time at 17
which the A3-IS-2000 FCH/DCCH Forward message arrives at the 18
BTS minus the expected arrival time in units specified by the Scaling 19
field. This value is expressed in 2s complement format. It has a value 20
in the range 31 time units, as determined by the Scaling field. 21
The IS-2000 Frame Content field is used to indicate the code symbol 23
repetition rate and number of information bits contained in the 24
information element. Special Frame Content parameters are defined to 25
facilitate in-band signaling between the source BS and target BS. The 26
IS-2000 Frame Content parameter uniquely identifies the data rate and 27
number of information bits. The value is taken from Table 4.2.15-2, 28
Table 4.2.15-3, or Table 4.2.15-4. 29
30

2
TIA-2001.5-C
157 Section 4
Table 4.2.15-2 IS-2000 Frame Content - Special Frame Content Parameters 1
Description I S-2000
Frame
Content
(hex)
Name
Forward Reverse
00 Idle
1
May be used for synchronization
when air interface resources are
not allocated. Refer to [13].
Used for synchronization when
the BTS has not yet acquired the
traffic channel, or when air
interface resources are not
allocated.
7D Full Rate
Likely
Not Applicable Radio Configuration 1, Full Rate
Likely
7E Erasure
1
Not Applicable. Insufficient Physical Layer Frame
Quality to determine data rate.
7F Null
1
Used during DTX mode (when
transmitting Null traffic Channel
frames to the MS).

Used during DTX mode (when
there is only a pilot channel and
no frames are being received on
the traffic channel).

1. The number of Information Bits for these frame content types is 0. 2
Table 4.2.15-3 IS-2000 Frame Content - FCH Frame Content Parameters 3
Frame
Content
(hex)
Radio
Configuration
Data Rate
(bps)
Number of
Layer 3 Fill
Bits
Number of
Information Bits
01h 9600 4 172
02 4800 0 80
03 2400 0 40
04
Forward: 1
and
Reverse: 1
1200 0 16
05 14400 4 268
06 7200 3 125
07 3600 1 55
08
Forward: 2
and
Reverse: 2
1800 3 21
09 unused - -
0A 9600 (20 ms) 4 172
0B 4800 0 80
0C 2700 0 40
0D
Forward:
3,4,6,7
and
Reverse: 3,5
1500 0 16
4
TIA-2001.5-C
Section 4 158
Table 4.2.15-3 (Cont.) IS-2000 Frame Content - FCH Frame Content Parameters 1
Frame
Content
(hex)
Radio
Configuration
Data Rate
(bps)
Number of
Layer 3 Fill
Bits
Number of
Information Bits
0E Unused - -
0F 14400 5 267
10 7200 3 125
11 3600 1 55
12
Forward: 5,8,9
and
Reverse:
4,6
1800 3 21
2
Table 4.2.15-4 IS-2000 Frame Content - DCCH Frame Content Parameters 3
Frame
Content
(hex)
Radio
Config-
uration
Data Rate
(bps)
Number of
Layer 3 Fill
Bits
Number of
Information Bits
20 Forward:
3,4,6,7
Reverse:
3,5
9600 4
172
21 Forward:
5,8,9
Reverse:
4,6
14400 5 267
4
Table 4.2.15-5 IS-2000 Frame Content - SCH Frame Content Parameters for 20 ms Frames 5
Frame
Content
(hex)
Radio
Config-
uration
Data Rate
(bps)
Number of
Layer 3 Fill
Bits
Number of
Information Bits
30 Reverse: 5
Forward: 7
614400 0 12264
31 307200 0 6120
32 153600 0 3048
33 76800 0 1512
34 38400 0 744
35 19200 0 360
36 9600 4 172
37 4800 0 80
38 2700 0 40
39
Reverse: 3

Forward:
3,4,6
1500 0 16
6
TIA-2001.5-C
159 Section 4
Table 4.2.15-5 (Cont.) IS-2000 Frame Content - SCH Frame Content Parameters for 20 ms 1
Frames 2
Frame
Content
(hex)
Radio
Config-
uration
Data Rate
(bps)
Number of
Layer 3 Fill
Bits
Number of
Information Bits
3A 1036800 0 20712
3B
Reverse: 6
Forward: 9 460800 0 9192
3C 230400 0 4584
3D 115200 0 2280
3E 57600 0 1128
3F 28800 0 552
40 14400 4 268
41 7200 3 125
42 3600 1 55
43
Reverse: 4

Forward:
5,8
1800 3 21
90-9F 3-9

Flex Rate
1

3
1
For Flex Rate, the four least significant bits in this field shall be set to FOR_SCH_NUM_BITS_IDX 4
(refer to [5]). 5
6
Table 4.2.15-6 IS-2000 Frame Content - SCH Frame Content Parameters for 40 ms Frames* 7
Frame
Content
Radio
Configuration
Data Rate
3

(bps)
Number of
Layer 3 Fill
Bits
Number of Info.
Bits
50 Reverse: 5
Forward: 7
307200 0 12264
51 153600 0 6120
52 76800 0 3048
53 38400 0 1512
54 19200 0 744
55 9600 0 360
56 4800 4 172
57 2400 0 80
58
Reverse: 3

Forward:
3,4,6
1350 0 40
8

3
These rates are not supported by [1] to [6] MAC and Signaling Layers, and are not supported in this
version of this standard.
TIA-2001.5-C
Section 4 160
Table 4.2.15-6 (Cont.) IS-2000 Frame Content - SCH Frame Content Parameters for 40 ms 1
Frames* 2
59 518400 0 20712
5A
Reverse: 6
Forward: 9 230400 0 9192
5B 115200 0 4584
5C 57600 0 2280
5D 28800 0 1128
5E 14400 0 552
5F 7200 5 267
60 3600 3 125
61
Reverse: 4

Forward:
5,8
1800 1 55
* - Note that 40 ms Frames are not supported in this version of this standard. 3
Table 4.2.15-7 IS-2000 Frame Content - SCH Frame Content Parameters for 80 ms Frames* 4
Frame
Content
Radio
Configuration
Data Rate
4

(bps)
Number of
Layer 3 Fill
Bits
Number of Info.
Bits
62 Reverse: 5
Forward: 7
153600 0 12264
63
76800
0 6120
64 38400 0 3048
65 19200 0 1512
66 9600 0 744
67 4800 0 360
68 2400 4 172
69
Reverse: 3

Forward:
3,4,6
1200 0 80
6A 259200 0 20712
6B
Reverse: 6
Forward: 9 115200 0 9192
6C 57600 0 4584
6D 28800 0 2280
6E 14400 0 1128
6F 7200 0 552
70 3600 5 267
71
Reverse: 4

Forward:
5,8
1800 3 125
*- Note that 80 ms frames are not supported in this version of this standard. 5
6

4
These rates are not supported by [1] to [6] MAC and Signaling Layers, and are not
supported in this version of this standard.
TIA-2001.5-C
161 Section 4
Forward Power Control- Signal Power (RPC: S): 1
This field may be used for voice calls, subject to inter-vendor 2
agreements. 3
The BTS shall set this field to the current S: S= SIR + RSSI in dBm 4
5
The SIR (Signal to Interference Ratio) is a signal to noise plus 6
interference ratio. It is called SIR because the noise term is treated as 7
being insignificant compared to the interference power. The RSSI is the 8
BTS received signal strength indication. 9
10
The S can be arrived at by using the table below. A 6 bit dynamic range 11
value for SIR and a 6 bit dynamic range value for RSSI are looked up 12
and added together to obtain the 7 bit S value. This metric is used to 13
determine the reduced active set. Refer to [22]. 14
15
TIA-2001.5-C
Section 4 162
Table 4.2.15-8 Signal to Noise Ratio Values 1
RSSI (dBm) Ec/Io (dB) 6 bit dynamic
range
-120.0 -31.5 0
-119.5 -31.0 1
-119.0 -30.5 2
-118.5 -30.0 3
-118.0 -29.5 4
-117.5 -29.0 5
-117.0 -28.5 6
-116.5 -28.0 7
-116.0 -27.5 8
-115.5 -27.0 9
-115.0 -26.6 10
-114.5 -26.0 11
-114.0 -25.5 12
-113.5 -25.0 13
-113.0 -24.5 14
-112.5 -24.0 15
-112.0 -23.5 16
-111.5 -23.0 17
-111.0 -22.5 18
-110.5 -22.0 19
-110.0 -21.5 20
-109.5 -21.0 21
-109.0 -20.5 22
-108.5 -20.0 23
-108.0 -19.5 24
-107.5 -19.0 25
-107.0 -18.5 26
-106.5 -18.0 27
-106.0 -17.5 28
-105.5 -17.0 29
2
TIA-2001.5-C
163 Section 4
Table 4.2.15-8 (Cont.) Signal to Noise Ratio Values 1
RSSI (dBm) Ec/Io (dB) 6 bit dynamic
range
-105.0 -16.5 30
-104.5 -16.0 31
-104.0 -15.5 32
-103.5 -15.0 33
-103.0 -14.5 34
-102.5 -14.0 35
-102.0 -13.5 36
-101.5 -13.0 37
-101.0 -12.5 38
-100.5 -12.0 39
-100.0 -11.5 40
-99.5 -11.0 41
-99.0 -10.5 42
-98.5 -10.0 43
-98.0 -9.5 44
-97.5 -9.0 45
-97.0 -8.5 46
-96.5 -8.0 47
-96.0 -7.5 48
-95.5 -7.0 49
-95.0 -6.5 50
-94.5 -6.0 51
-94.0 -5.5 52
-93.5 -5.0 53
-93.0 -4.5 54
-92.5 -4.0 55
-92.0 -3.5 56
-91.5 -3.0 57
-91.0 -2.5 58
-90.5 -2.0 59
-90.0 -1.5 60
-89.5 -1.0 61
-89.0 -.5 62
-88.5 0 63
QIB (Quality Indicator Bit)/EIB (Erasure Indicator Bit): 2
When FPC_MODE is not equal to 011 or 100, then the BTS shall 3
set this field to 0. When FPC_MODE is equal to 011 or 100, then 4
the BTS shall set this field to 1 if the QIB/EIB received from the MS 5
is 1; otherwise, the BTS shall set this field to 0. Furthermore, 6
FPC_MODE equal to 011 or 100 implies that a Reverse Layer 3 7
DCCH Data frame is generated at least once per 20 ms to convey 8
QIB/EIB status. 9
Reverse Link Information: 10
The BTS shall set this field to the Reverse Link Information that the 11
BTS received from the MS. The BTS shall include the number of bits 12
in the Information column of Table 4.2.15-2, Table 4.2.15-3, or Table 13
4.2.15-4. corresponding to the transmission rate of the Reverse Link 14
frame. The BTS shall set the Information Bits to the information bits 15
received from the MS which correspond to the Multiplex Sublayer in 16
TIA-2001.5-C
Section 4 164
use (refer to [1]~[6]). The BTS shall use the bit order specified in 1
[1]~[6]. 2
Layer 3 Fill: 3
Table 4.2.15-2, Table 4.2.15-3, or Table 4.2.15-4 corresponding to the 5
transmission rate of the Traffic Channel frame. The Layer 3 Fill bits 6
shall be set to 0. The fill bits are added at the end of the frame in the 7
lower order bit positions after the Reverse Link Information. 8
9
TIA-2001.5-C
165 Section 4
4.2.16 Forward Layer 3 IS-2000 SCH Data 1
This element contains the CDMA Forward Supplemental Link Frame and control 2
information for packets flowing in the source BS (SDU) to target BS (BTS) direction. 3
The frame content parameter is optionally set to Null for soft handoff legs incurring the 4
greatest transmission loss. This can be determined by the reverse link signal to noise ratio 5
(S). The signal to noise ratio can be obtained from the Reverse Layer 3 FCH/DCCH Data 6
element Signal to Noise Ratio parameter. A threshold, driven by the Service Option 7
and/or QoS, can be used for transmission selection. Depending on the threshold, either 8
the best forward link or a best subset of the forward links is selected for transmission on 9
the A3 interface, and subsequently on the air interface. Note that appropriate action-time 10
coordinated signaling with the MS is required to exercise this option. 11
4.2.16 Forward Layer 3 I S-2000 SCH Data
7 6 5 4 3 2 1 0 Octet
FPC: SLC FSN 1
FPC: GR 2
Forward Link Information + Layer 3 Fill Var.
This parameter is required for EIB (50Hz) power control. 22
Min(![(A
d
/A
p
)*SQRT( 9600 /Rate )] 128 ", 255 ) 24
where A
d
is the Forward Link SCH gain (in volts), and A
p
is the 25
smallest common Pilot Channel gain (in volts). (IS-2000 supports 26
multiple pilots.) 27
Note: The BTS determines the Forward Link SCH gain as follows: 28
A
d
= FPC:GR*A
p
*SQRT(Rate/9600)/128. 29
If this field is set to zero, it shall be ignored. 30
he IS-2000 Frame Content parameter uniquely identifies the data rate 32
2, Table 4.2.15-3, or Table 4.2.15-4. The IS-2000 Frame Content 34
parameter uniquely identifies the symbol repetition rate and number of 35
information bits. 36
TIA-2001.5-C
Section 4 166
BTS is to send to the MS. The SDU shall include the number of bits in 3
the Information column of Table 4.2.15-2 or Table 4.2.15-5 4
corresponding to the transmission rate of the Forward Link frame. The 5
SDU shall set the Information Bits to the information bits supplied by 6
the Multiplex Option Sublayer. The bit order shall be as specified in 7
[1]. 8
Layer 3 Fill: 9
Table 4.2.15-2 or Table 4.2.15-5 corresponding to the transmission rate 11
of the Traffic Channel frame. The Layer 3 Fill bits shall be set to 0. 12
The fill bits are added at the end of the frame in the lower order bit 13
positions after the Forward Link Information. 14
15
TIA-2001.5-C
167 Section 4
4.2.17 Reverse Layer 3 IS-2000 SCH Data 1
This element contains the CDMA Reverse Supplemental Link frame and control 2
information for packets flowing in the BTS to SDU direction. 3
4.2.17 Reverse Layer 3 I S-2000 SCH Data
7 6 5 4 3 2 1 0 Octet
Reverse Link Information + Layer 3 Fill Var.
When IDLE frames are sent on the forward link for purposes of 13
obtaining PATE for an upcoming SCH data burst, the FSN of the 14
reverse IDLE SCH frame should be ignored. The timing of the reverse 15
SCH IDLE frame may be asynchronous to future demodulated reverse 16
SCH data timing. 17
Traffic Frame CRC passes. Otherwise, the BTS shall set this field to 0 21
if the CRC fails or if there is no Reverse Link Information
5
. 22
BTS shall set this field to the Inverted Re-Encoded Symbol Error Rate 25
(SER) or equivalent metric. The Inverted Re-Encoded SER is the 26
binary value of: 27
1x repetition rate as listed in the IS-2000 Frame Content element. (refer 30
to [2]). 31

5
There is no Reverse Link Information when only a reverse pilot channel exists. For
channel, and it occurs when the SCH is in DTX mode.
TIA-2001.5-C
Section 4 168
6
Scaling: 12
The BTS shall set this field to the time scale for the PATE field. Values 13
are indicated in the table below. This field shall be set to 11 if no A3- 14
IS-2000 SCH Forward message was received. 15
Table 4.2.17-1 Reverse Layer 3 I S-2000 SCH Data - Time Scale for the PATE 16
Field Value Time Units PATE Range
00 0.125 ms 3.875 ms
01 1.0 ms 31.0 ms
10 1.25 ms 38.75 ms
11 5.0 ms 155 ms
which the A3-IS-2000 SCH Forward message arrives at the BTS minus 19
the expected arrival time in units specified by the Scaling field. This 20
value is expressed in 2s complement format. It has a value in the range 21
31 time units, as determined by the Scaling field. This field shall be 22
set to 00 0000 if no A3-IS-2000 SCH Forward message was received. 23
he IS-2000 Frame Content parameter uniquely identifies the data rate 25
2, Table 4.2.15-3, or Table 4.2.15-4.. 27
The Frame Content parameter uniquely identifies the symbol repetition 28
rate and number of information bits. 29
BTS received from the MS. The BTS shall include the number of bits 32
in the Information column Table 4.2.15-2 or Table 4.2.15-5 33
corresponding to the transmission rate of the Reverse Link frame. The 34
BTS shall set the Information Bits to the information bits received from 35
the MS which correspond to the Multiplex Sublayer in use (refer to 36
[1]~[6]). The BTS shall use the bit order specified in [1]~[6]. 37

6
example, this occurs when the SCH is in DTX mode.
TIA-2001.5-C
169 Section 4
Layer 3 Fill: 1
Table 4.2.15-2 or Table 4.2.15-5 corresponding to the transmission rate 3
of the Traffic Channel frame. The Layer 3 Fill bits shall be set to 0. 4
The fill bits are added at the end of the frame in the lower order bit 5
positions after the Reverse Link Information. 6
7
TIA-2001.5-C
Section 4 170
1
4.2.18 CDMA Serving One Way Delay 2
This element specifies the estimated one-way delay from the MS to the cell associated 3
with the REF_PN (refer to [1]~[6]). It is coded as follows: 4
4.2.18 CDMA Serving One Way Delay
7 6 5 4 3 2 1 0 Octet
Length 2
Cell Identifier 3-var
(MSB) CDMA Serving One Way Delay m
CDMA Serving One Way Delay (LSB) m+1
Reserved Resolution m+2
(MSB) CDMA Serving One Way Delay Time Stamp m+3
(LSB) m+4
The Length field contains the number of octets in this element following the Length field. 5
The Cell Identifier field identifies the reference cell. This field is comprised of a Cell 6
Identification Discriminator and a Cell Identification and shall be formatted according to 7
octets 3 through the end of the Cell Identifier element defined in section 4.2.5. The 8
allowable cell discriminator values are 0000 0010, and 0000 0111. 9
The CDMA Serving One Way Delay field is the one-way delay from the MS to the cell 10
associated with the REF_PN (refer to [1]~[6]) as estimated by the BS. 11
The Resolution field indicates the units used to calculate the CDMA Serving One Way 12
Delay. The allowable values are: 13
00 100 ns 14
01 50 ns 15
10 1/16 TIA/EIA-95 PN Chip 16
11 reserved 17
The CDMA Serving One Way Delay Time Stamp is a 16-bit binary number that contains 18
the 16 least significant bits of the 36-bit SYS_TIME at the time that the One Way Delay 19
was measured. The SYS_TIME is counted at the BS in units of 80 ms. 20
21
TIA-2001.5-C
171 Section 4
4.2.19 Neighbor List 1
This element contains a list of the target BS neighbor cells. This list may be used by the 2
source BS to update the MS neighbor list. 3
4.2.19 Neighbor List
7 6 5 4 3 2 1 0 Octet
Length 2
Number of Neighbors 3
PILOT_PN 1 (LSB) 4
PILOT_PN
1
(MSB)
Short Cell Identification Discriminator 1 5

PILOT_PN n (LSB) k
PILOT_PN
n
(MSB)
Short Cell Identification Discriminator n k+1
Cell Identification n
The Length field is a binary value indicating the number of octets following the Length 4
field. 5
The Number of Neighbors field contains the number of neighboring cells included in this 6
element. 7
There is one instance of the next three fields for each cell in the neighbor list. 8
The PILOT PN Code is one of the 511 unique values for the pilot PN sequence offset 9
index. The offsets are in increments of 64 PN chips. 10
The Short Cell Identification Discriminator field is identical to Cell Identification 11
Discriminator field specified in section 4.2.5 except that only the least significant seven 12
bits of the eight bits of the Cell Identification Discriminator value are used. 13
The Cell Identification field is identical to Cell Identification field specified in section 14
4.2.5. 15
16
TIA-2001.5-C
Section 4 172
4.2.20 A3 Signaling Address 1
This information element identifies the network node that contains the instance of the 2
SDU in use for the call. The target BS is responsible for checking whether a connection 3
with the same destination address exists. If such a connection does exist, that existing 4
connection shall be used to carry A3 signaling messages sent and received by the target 5
BS. 6
4.2.20 A3 Signaling Address
7 6 5 4 3 2 1 0 Octet
Length 2
Address Type 3
(MSB) TCP/SCTP Port 4
(LSB) 5
(MSB) A3 Address 6

(LSB) k
Length: 7
Length field. 9
Address Type: 10
This field indicates the type and format of the A3 Address that follows. 11
TCP/SCTP Port: 12
This field contains the TCP or the SCTP Port address for the A3 13
signaling connection. 14
A3 Address: 15
This field has a variable length that is dependent on the Type field. The 16
internal format of this field may be specified via the Type field. 17
Table 4.2.20-1 A3 Address Identifier Type 18
Type Format of the A3 Address Length of A3 Address
1 Internet Protocol IPv4 4 octets
2 Internet Protocol IPv6 Var.
19
20
TIA-2001.5-C
173 Section 4
4.2.21 SDU ID 1
This information element identifies a particular SDU instance within an SDU Node. 2
4.2.21 SDU ID
7 6 5 4 3 2 1 0 Octet
Length 2
(MSB) SDU Identifier 3

(LSB) k
Length: 3
Length field. 5
SDU Identifier: 6
This field has a variable length. The actual length is indicated in the 7
Length field and is dependent upon the particular implementation. In 8
this version of this standard, this value shall be no more than 6 octets 9
long. 10
11
TIA-2001.5-C
Section 4 174
4.2.22 A3 Traffic Circuit ID 1
This information element is used to identify a particular circuit (virtual/physical) between 2
a BTS and a source BS/SDU. It is useful particularly when multiple circuits supporting 3
A3 user traffic connections may exist between the BTS and the source BS/SDU, e.g., 4
multiple ATM virtual circuits running the AAL2 protocol. 5
4.2.22 A3 Traffic Circuit ID
7 6 5 4 3 2 1 0 Octet
Length 2
Length of Traffic Circuit Identifier 3
(MSB) Traffic Circuit Identifier 4

(LSB) n
Length of Traffic Connection Identifier n+1
(MSB) Traffic Connection Identifier n+2

(LSB) p
Length: 6
Length field. 8
Length of Traffic Circuit Identifier: 9
This field indicates the length in octets of the Traffic Circuit Identifier. 10
The Traffic Circuit Identifier field shall be exactly two octets in length. 11
Traffic Circuit Identifier: 12
The value contained within this field is configured for a particular 13
circuit (virtual/physical) by agreements between the network operator 14
and the manufacturers involved. This field is regarded as the Virtual 15
Channel Connection Identifier (VCCI). 16
Length of Traffic Connection Identifier: 17
This field indicates the length in octets of the Traffic Connection 18
Identifier. 19
Traffic Connection Identifier: 20
This field contains a value that is unique within the traffic circuit and 21
identifies a single logical connection within that traffic circuit. This 22
field is regarded as the CID of an AAL2 virtual circuit. If this field is 23
omitted, all circuits within the specified VCCI are indicated. 24
25
TIA-2001.5-C
175 Section 4
4.2.23 Call Connection Reference 1
This information element contains a globally unique identification for a call connection. 2
4.2.23 Call Connection Reference
7 6 5 4 3 2 1 0 Octet
Length 2
(MSB) Market ID 3
Market ID (continued) (LSB) 4
(MSB) Generating Entity ID 5
Generating Entity ID (continued) (LSB) 6
(MSB) Call Connection Reference Value 7
8
9
(LSB) 10
Length: 3
Length field. 5
Market ID: 6
This field represents a unique market ID that is specified by the service 7
provider (refer to [19]). 8
Generating Entity ID: 9
This two octet field represents a unique code assigned by the operator 10
to the entity that generates this Call Connection Reference value. 11
Call Connection Reference Value: 12
This four octet field may contain any value. It is assigned by the 13
generating entity whose responsibility it is to guarantee its uniqueness. 14
15
TIA-2001.5-C
Section 4 176
4.2.24 PMC Cause 1
This element is used to indicate the outcome of processing an A3 or A7 interface 2
message. 3
4.2.24 PMC Cause
7 6 5 4 3 2 1 0 Octet
Length 2
PMC Cause Value 3
The PMC Cause Value field is coded as follows: 4
Table 4.2.24-1 PMC Cause Values 5
PMC Cause
Value
(Hex)
Description
00H No error
01H Awaiting connect
02H Already connected
03H Illegal A3 connect
04H Illegal A3 remove
05H Requested reverse pilot gating rate not supported
06H DTMF continuous tone generation not active
07H Unrecognized message
08H Requested FPC mode change failed
09H Invalid state
0AH No resources available
0BH Reserved (available value)
0CH Illegal operation
0DH Private long code not available or not supported
0EH Requested MUX option or rates not available
0FH Requested privacy configuration unavailable
6
TIA-2001.5-C
177 Section 4
4.2.25 Band Class 1
This information element specifies the frequency band. 2
4.2.25 Band Class
7 6 5 4 3 2 1 0 Octet
Length 2
The Length field contains the number of octets in this element following the Length field. 3
The coding of the Band Class field is specified in Table 4.2.25-1. This table contains 4
band class values defined in [20]. If there are any discrepancies between this table and 5
[20], the latter shall be considered correct. 6
Table 4.2.25-1 Band Class 7
0 0000 800 MHz Cellular System
0 0001 1.850 to 1.990 GHz Broadband PCS
0 0010 872 to 960 MHz TACS band
0 0011 832 to 925 MHz JTACS band
0 0100 1.750 to 1.870 GHz Korean PCS band
0 0101 NMT-450 band
0 0110 IMT-2000 band
0 0111 North American 700 MHz Cellular Band
8
9
TIA-2001.5-C
Section 4 178
4.2.26 Correlation ID 1
This information element is used to correlate request and response messages. 2
4.2.26 Correlation ID
7 6 5 4 3 2 1 0 Octet
Length 2
(MSB) Correlation Value 3
4
5
(LSB) 6
Length: 3
Length field. 5
Correlation Value: 6
This field contains a value that allows the network entity to correlate a 7
request-response pair of messages. The value is a manufacturer 8
concern. In this revision of this standard, this value shall be exactly 4 9
octets in length. 10
11
12
TIA-2001.5-C
179 Section 4
4.2.27 IS-2000 Non-Negotiable Service Configuration Record 1
This information element contains the non-negotiable service configuration record as 2
defined in [5]. 3
4.2.27 I S-2000 Non-Negotiable Service Configuration Record
7 6 5 4 3 2 1 0 Octet
(MSB) 4

Seventh
Fill Bit
if needed
Sixth Fill
Bit if
needed
Fifth Fill
Bit if
needed
Fourth
Fill Bit
if needed
Third
Fill Bit
if needed
Second
Fill Bit
if needed
First Fill
Bit if
needed
k
This field contains the total number of octets in this element following 5
this field represented as a binary value. 6
IS-2000 Non-Negotiable Service Configuration Record Content: 12
This field contains a Non-Negotiable Service Configuration Record 13
coded according to [5]. The value begins in the high order bit position 14
of octet 4 of this element and extends into the last octet of this element. 15
octet. 18
19
20
TIA-2001.5-C
Section 4 180
4.2.28 One Way Propagation Delay Record 1
This element contains the CDMA serving one-way propagation delay and the Cell 2
Identification. 3
4.2.28 One Way Propagation Delay Record
7 6 5 4 3 2 1 0 Octet
Length 2
(MSB) Cell Identification 4
Cell Identification (LSB) m
(MSB) CDMA Serving One way Delay m+1
CDMA Serving One way Delay (LSB) n
Length: 4
Length field. 6
This field uses the Cell Identification Discriminator values used with 8
the Cell Identifier element (refer to section 4.2.5) to describe the format 9
of the immediately following Cell_ID. Cell discriminator type 0000 10
0111 is used. 11
This is the cell identification as described in section 4.2.5 for which the 13
propagation delay measurement is included in this record. It shall be 14
formatted according to octets 4 through the end of the Cell Identifier 15
element defined in section 4.2.5. 16
CDMA Serving One Way Delay: 17
This is the CDMA serving one-way delay in units of 100 ns. 18
19
TIA-2001.5-C
181 Section 4
4.2.29 Forward Layer 3 Data 1
This element contains the CDMA Forward Traffic Channel Frame and control 2
information for packets flowing in the SDU to BTS direction. 3
4.2.29 Forward Layer 3 Data
7 6 5 4 3 2 1 0 Octet
Reserved Sequence Number 1
Forward Traffic Channel Gain 2
Reverse Traffic Channel
E N
w T
3
Rate Set Indicator Forward Traffic Channel Rate 4
Reserved Power Control Subchannel Count 5
Forward Traffic Channel Information +Layer 3 Fill Var.
Reserved: 4
The SDU shall set this field to 0000. 5
Sequence Number: 6
Forward Traffic Channel Gain: 10
Min(!(A
t
/ A
p
) 128", 255) 12
where A
t
is the full-rate Forward Traffic Channel gain (in volts), and A
p
13
is the Pilot Channel gain (in volts). 14
Reverse Traffic Channel
E N
w T : 15
The SDU shall set this field to the desired Reverse Traffic Channel 16
E
w
/N
t
, where E
w
/N
t
is the ratio of the total demodulated Walsh symbol 17
energy to total received power spectral density on the RF channel. The 18
E
w
/N
t
The SDU shall set the Reverse Traffic Channel E
w
/N
t
field in the range 20
of 0 through 255 in units of 0.125dB. This provides a Reverse Traffic 21
Channel E
w
/N
t
in the range of 0 through 31.875 dB. 22
Rate Set Indicator: 23
The SDU shall set this field to correspond to the Rate Set of the traffic 24
channel frame as follows. 25
Table 4.2.29-1 Forward Layer 3 Data - Rate Set Indicator 26
Field Value Meaning
0000 Rate Set 1
0001 Rate Set 2
TIA-2001.5-C
Section 4 182
Forward Traffic Channel Rate: 1
The SDU shall set the field to the rate at which the BTS is to send the 2
Forward Traffic Channel Information to the MS. 3
If this field indicates Idle Frame, then the BTS shall not transmit an 4
air interface frame, but shall ignore all but the Sequence Number and 5
Frame Type fields and shall use this frame to adjust the frame arrival 6
time. 7
The SDU shall set this field as follows: 8
Table 4.2.29-2 Forward Layer 3 Data - Forward Traffic Channel Rate 9
Field Value Rate Set 1 Transmission
Rate
Rate Set 2 Transmission
Rate
0000 9600 bps (Full Rate) 14400 bps (Full Rate)
0001 4800 bps (Half Rate) 7200 bps (Half Rate)
0010 2400 bps (Quarter Rate) 3600 bps (Quarter Rate)
0011 1200 bps (Eighth Rate) 1800 bps (Eighth Rate)
0100 Idle Frame Idle Frame
Reserved: 10
Power Control Subchannel Count: 12
The SDU shall set this field to the number of independent power 13
control subchannels involved in soft handoff. 14
Forward Traffic Channel Information: 15
The SDU shall set this field to the Forward Traffic Channel 16
Information that the BTS is to send to the MS. The SDU shall include 17
the number of bits in the Information column corresponding to the 18
transmission rate of the Forward Traffic Channel frame. The SDU shall 19
set the Information Bits to the information bits supplied by the 20
Multiplex Option Sublayer in use (refer to [1]~[6]). The bit order shall 21
be as specified in [1]~[6]. 22
Table 4.2.29-3 Forward Layer 3 Data - Forward Traffic Channel Information 23
Rate
Set
Transmission
Rate (bps)
Number of Information Bits
per Frame
1 9600 172
4800 80
2400 40
1200 16
0 0
2 14400 267
7200 125
3600 55
1800 21
TIA-2001.5-C
183 Section 4
Layer 3 Fill: 1
The SDU shall include the number of bits in the Layer 3 Fill column 2
corresponding to the transmission rate of the Traffic Channel frame. 3
The SDU shall set the Layer 3 Fill bits to 0. The fill bits are added at 4
the end of the frame in the lower order bit positions per the bit ordering 5
specified in this standard. 6
Table 4.2.29-4 Forward Layer 3 Data - Layer 3 Fill 7
Class Transmission
Rate (bps)
Number of Layer 3 Fill Bits
per Frame
Rate Set 1 9600 4
4800 0
2400 0
1200 0
0 0
Rate Set 2 14400 5
7200 3
3600 1
1800 3
8
9
TIA-2001.5-C
Section 4 184
4.2.30 Reverse Layer 3 Data 1
This element contains the CDMA Reverse Traffic Channel frame and control information 2
for packets flowing in the BTS to SDU direction. 3
4.2.30 Reverse Layer 3 Data
7 6 5 4 3 2 1 0 Octet
Soft Handoff Leg # Sequence Number 1
Reverse Traffic Channel Quality 2
Rate Set Indicator Reverse Traffic Channel Rate 4
Reserved EIB 5
Reverse Traffic Channel Information + Layer 3 Fill Var.
A3-Connect Ack Information element of the A3-Connect Ack message. 8
Sequence Number: 9
16 (refer to [2]) corresponding to the receive time of the air interface 11
frame in the reverse direction. 12
Reverse Traffic Channel Quality: 13
The Reverse Traffic Channel Quality shall consist of a one bit CRC 14
field and a seven bit Symbol Error Rate field. 15
If the Reverse Traffic Frame CRC passes, the BTS shall set the most 16
significant bit to 1. Otherwise, the BTS shall set this bit to 0. If the 17
Reverse Traffic Channel frame does not have a CRC, the BTS shall set 18
this bit to 0. 19
The BTS shall set the 7 least significant bits of this parameter to the 20
inverted Re-Encoded Symbol Error Rate or equivalent metric. The 21
inverted Re-Encoded Symbol Error Rate is the binary value of 22
1x repetition rate as listed in the IS-2000 Frame Content element. 25
(Reference: [2]). 26
If there is no reverse traffic frame detected by the BTS, the Reverse 27
If the channel element has lost finger lock, the Reverse Link Quality 29
field may (optionally) be set to 0000 0001 in the erasure frame to 30
indicate that the MS is not acquired. If the lost finger lock option is not 31
asserted, then the Reverse Link Quality field shall be set to 0000 0000 32
for all erasures. 33
If the most recently received forward frame received by the BTS from 34
the SDU was an Idle Frame, then the BTS shall set the Reverse Traffic 35
Channel Quality field to a value of 00H and shall send an Idle Frame to 36
the SDU. The SDU shall ignore the value of this field in Idle Frames. 37
TIA-2001.5-C
185 Section 4
The Re-Encoded Symbol Error Rate is the number of errors found when comparing the 1
received symbols at the input of the convolutional code decoder and the re-encoded 2
symbols at the output of the convolutional code decoder. 3
The Re-encoded Symbol Error Rate computation shall include the erasure indicator bit 4
(E), if applicable; the information bits; the Frame Quality Indicator (F), if applicable; and 5
the Encoder Tail Bits (T). 6
Scaling: 7
The BTS shall set this field to the time scale for the Packet Arrival 8
Time Error (PATE) field. Values are indicated in the table below. 9
Table 4.2.30-2 Reverse Layer 3 Data - Time Scale for the Packet Arrival Time Error 10
00 125 s 3.875 ms
01 1.0 ms 31.0 ms
10 1.25 ms 38.75 ms
which the A3-IS-95 FCH Forward message arrives at the BTS minus 13
31 time units, as determined by the Scaling field. 16
Rate Set Indicator: 17
The BTS shall set this field to correspond to the Rate Set of the traffic 18
channel frame as follows. If the BTS is sending an Idle Frame to the 19
SDU, the SDU shall ignore the contents of this field. 20
Table 4.2.30-3 Reverse Layer 3 Data - Rate Set Indicator 21
Field Value Meaning
0000 Rate Set 1
0001 Rate Set 2
Reverse Traffic Channel Rate: 22
The BTS shall set the field values as shown in the following table. The 23
BTS shall set the field value to 0101, idle, if it has not acquired the 24
MS. 25
TIA-2001.5-C
Section 4 186
Table 4.2.30-4 Reverse Layer 3 Data - Reverse Traffic Channel Rate 1
Field Value Rate Set 1 Transmission
Rate
Rate Set 2 Transmission Rate
0000 9600 bps (Full Rate) 14400 bps (Full Rate)
0001 4800 bps (Half Rate) 7200 bps (Half Rate)
0010 2400 bps (Quarter Rate) 3600 bps (Quarter Rate)
0011 1200 bps (Eighth Rate) 1800 bps (Eighth Rate)
0100 Erasure Erasure
0101 Idle Idle
0110 Rate Set 1 Full Rate Likely Reserved
Reverse Traffic Channel Information: 2
The BTS shall set this field to the Reverse Traffic Channel Information 3
that the BTS received from the MS. The BTS shall include the number 4
of bits in the Information column corresponding to the transmission 5
rate of the Reverse Traffic Channel frame. The BTS shall set the 6
Information Bits to the information bits received from the MS which 7
correspond to the Multiplex Sublayer in use (refer to [1]~[6]). The BTS 8
shall use the bit order specified in [1]~[6]. 9
10
TIA-2001.5-C
187 Section 4
Table 4.2.30-5 Reverse Layer 3 Data - Reverse Traffic Channel Information Bits 1
Class Transmission
Rate (bps)
Number of Information Bits
per Frame
Rate Set 1 9600 172
4800 80
2400 40
1200 16
Rate Set 2 14400 267
7200 125
3600 55
1800 21
Other Erasure 0
Idle 0
EIB (Erasure Indicator Bit): 2
When Rate Set 1 is being used, the BTS shall set this bit to 0. When 3
Rate Set 2 is being used, the BTS shall set this bit to 1 if the EIB 4
received from the MS is a 1; otherwise, the BTS shall set this bit to 5
0. 6
Reserved: 7
The BTS shall set this field to 0000000. 8
Layer 3 Fill: 9
The BTS shall include the number of bits in the Layer 3 Fill column 10
corresponding to the transmission rate of the Reverse Traffic Channel 11
frame. The BTS shall set the Layer 3 Fill bits to 0. The fill bits are 12
added at the end of the frame in the lower order bit positions per the bit 13
ordering specified in this standard. 14
Table 4.2.30-6 Reverse Layer 3 Data - Layer 3 Fill Bits 15
Class Transmission
Rate (bps)
Number of Layer 3 Fill Bits
per Frame
Rate Set 1 9600 4
4800 0
2400 0
1200 0
Rate Set 2 14400 5
7200 3
3600 1
1800 3
Other Erasure 0
Idle 0
16
17
TIA-2001.5-C
Section 4 188
4.2.31 CDMA Long Code Transition Info 1
This element provides the encryption mask type (public or private long code mask) to be 2
used by the BTS as well as the explicit time of transition to the new long code mask. 3
4.2.31 CDMA Long Code Transition Info
7 6 5 4 3 2 1 0 Octet
Length 2
Reserved LCM_TYPE 3
ACTION_TIME 4
Length: 4
Length field. 6
Reserved: 7
All reserved bits shall be set to 0. 8
LCM_TYPE: 9
Long code mask type. 10
0 Use Public long code mask. 11
1 Use Private long code mask. 12
ACTION_TIME: 13
The field shall be set by the BS to the CDMA System Time (refer to 14
[1]~[6]), in units of 80 ms (modulo 64) at which the transition to the 15
new long code mask is to take effect. This field shall have the same 16
setting as was conveyed to the MS in a Long Code Transition Request 17
Order on the Forward Traffic Channel (refer to [1]~[6]). The Action 18
Time value conveyed to the MS is derived by taking the least 19
significant 6 bits of this 8-bit field. 20
21
TIA-2001.5-C
189 Section 4
4.2.32 Channel Element ID 1
This information element identifies a particular channel element instance within a target 2
BS. 3
4.2.32 Channel Element ID
7 6 5 4 3 2 1 0 Octet
Length 2
(MSB) CE ID - octet 1 3

4
CE ID - octet m (LSB) m+2
Length: 4
Length field. The value in this field shall be in the range 1 through 6. 6
CE ID: 7
This field contains a value that the target BS uses to identify internal 8
resources. 9
10
TIA-2001.5-C
Section 4 190
4.2.33 Message CRC 1
This is a standard 16-bit message CRC computed over the Message Type II and the 2
Forward Layer 3 Data (or Reverse Layer 3 Data) information elements. It is the standard 3
generator polynomial g(x) = x
16
+x
12
+x
5
+1 as in [22]. The polynomial representing the 4
message over which the CRC is computed uses bit 7 of the Message Type II octet as the 5
coefficient of the highest order term and bit 0 of the octet that precedes the CRC IE as the 6
zero order term. 7
4.2.33 Message CRC
7 6 5 4 3 2 1 0 Octet
(MSB) CRC 1
(LSB) 2
8
TIA-2001.5-C
191 Section 4
4.2.34 Channel Element Status 1
This element contains the status of a set of channel elements at a target BS. 2
4.2.34 Channel Element Status
7 6 5 4 3 2 1 0 Octet
Length 2
Reserved Xmit
On
3
Length: 3
Length field. 5
Xmit On: 6
This field indicates whether the cells indicated in the accompanying 7
Cell Identifier List element currently have their transmitters and 8
receivers turned on. 9
0 = transmitter(s) and receiver(s) is(are) off. 10
1 = transmitter(s) and receiver(s) is(are) on. 11
12
TIA-2001.5-C
Section 4 192
4.2.35 Cause List 1
This element contains a list of cause values that can be correlated to a list of cells. 2
4.2.35 Cause List
7 6 5 4 3 2 1 0 Octet
Length 2
Reserved Cause Value 1 3

Reserved Cause Value n n+2
Length: 3
Length field. 5
Cause Value: 6
This field contains one of the cause values listed in section 4.2.4. 7
8
TIA-2001.5-C
193 Section 4
4.2.36 Privacy Info 1
This element contains the CDMA long code masks (public and private). 2
4.2.36 Privacy Info
7 6 5 4 3 2 1 0 Octet
Length 2
(MSB) Privacy Mask Information - 1, first octet 3

Privacy Mask Information - 1, last octet (LSB) j
(MSB) Privacy Mask Information - 2, first octet j+1

Privacy Mask Information - 2, last octet (LSB) k

(MSB) Privacy Mask Information - n, first octet m

Privacy Mask Information - n, last octet (LSB) n
Length: 3
Length field. 5
The Privacy Mask Information field is coded as follows: 6
4.2.36 Privacy Info
7 6 5 4 3 2 1 0 Octet
Reserved Privacy Mask Type Status Available 1
Privacy Mask Length 2
(MSB) Privacy Mask 3

(LSB) 8
Octet 1: 7
Bit 0 indicates if the algorithm is available (supported). Available is 8
coded 1, and not available is coded 0. 9
Bit 1, the status indication, is coded 1 to indicate active and 0 to indicate inactive. 10
Bits 2 through 6 contain the Privacy Mask Type; refer to the table 11
below. 12
Bit 7 is reserved. 13
Octet 2: 14
Contains a value indicating the number of octets in the following 15
Privacy Mask field. 16
TIA-2001.5-C
Section 4 194
Table 4.2.36-1 Privacy Info - Privacy Mask Type 1
00000 Not Used - Invalid value.
00001 Public Long Code Mask
00010 Private Long Code Mask
Public Long Code Mask: 2
Encryption parameter for cdma2000
. Key length is 42 bits, encoded in 3

6 octets, such that the 6 unused bits are set equal to 0, and occupy the 4
high-order positions of the most significant octet. 5
Private Long Code Mask: 6
Encryption parameter for cdma2000
. Key length is 42 bits, encoded in 7

6 octets, such that the 6 unused bits are set equal to 0, and occupy the 8
high-order positions of the most significant octet. 9
10
TIA-2001.5-C
195 Section 4
4.2.37 A3 Connect Information 1
This element contains information on one or more cells to be added to a single new or 2
existing A3 connection. 3
4.2.37 A3 Connect Information
7 6 5 4 3 2 1 0 Octet
Length 2
Reserved Physical Channel Type

New A3
Indicator
3
Length of Cell Info Record 4
Cell I nfo Record{
Cell Identification Discriminator 1 i
Cell Identification 1 Var.
Reserved CCSH SR3_Incl QOF_Mask 1 New Cell
Indicator
PWR_
Comb_
Ind

(MSB)
j
Pilot_PN 1 (LSB) j+1
Code_Chan 1 j+2
Reserved Rev_FCH_
Gating 1
Lower QOF_Mask
1
Upper QOF_Mask
1
j+3
Lower Code_Chan 1 j+4
Upper Code_Chan 1 j+5

Cell Identification Discriminator n k
Cell Identification n Var.
Reserved CCSH SR3_Incl QOF_Mask n New Cell
Indicator
PWR_
Comb_
Ind

(MSB)
l
Pilot_PN n (LSB) l+1
Code_Chan n l+2
Reserved Rev_FCH_
Gating 1
Lower
QOF_Mask n
Upper
QOF_Mask n
l+3
Lower Code_Chan n l+4
Upper Code_Chan n l+5
}Cell I nfo Record
Length of Traffic Circuit ID j
TIA-2001.5-C
Section 4 196
4.2.37 A3 Connect Information
7 6 5 4 3 2 1 0 Octet
(MSB) Traffic Circuit ID j+1

(LSB) k
Extended Handoff Direction Parameters Field Length k+1
Extended Handoff Direction Parameters - 1st cell, 1st octet k+2

Extended Handoff Direction Parameters - 1st cell, last octet m

Extended Handoff Direction Parameters - last cell, 1st octet n

Extended Handoff Direction Parameters - last cell, last octet o
Length of Channel Element ID o+1
(MSB) Channel Element ID - first octet o+2

Channel Element ID - last octet (LSB) p
Length of A3 Originating ID 1 p+1
(MSB) A3 Originating ID 1 p+2

(LSB) q

Length of A3 Originating ID n r
(MSB) A3 Originating ID n r+1

(LSB) s
Length of A7 Destination ID s+1
(MSB) A7 Destination ID s+2

(LSB) t
Length: 1
Length field. 3
New A3 Indicator: 4
This field indicates whether a new A3 connection is to be created. 5
TIA-2001.5-C
197 Section 4
0 = a new A3 connections is NOT to be created - this element refers 1
to an existing A3 connection. 2
1 = a new A3 connections IS to be created - this element refers to a 3
new A3 connection. 4
This field contains the binary value used to indicate a type of physical 6
channel associated with the indicated traffic connection. Valid values 7
are shown below. 8
Value (binary) Physical Channel Type
0000 IS-95 Fundamental Channel TIA/EIA/IS-95
0001 Fundamental Channel (FCH) TIA/EIA/IS-2000
0010 Supplemental Channel (SCH_0) TIA/EIA/IS-2000
0011 Dedicated Control Channel (DCCH) TIA/EIA/IS-2000
0100 Supplemental Channel (SCH_1) TIA/EIA/IS-2000
Length of Cell Info Record: 9
This field indicates the number of immediately following octets that 10
contain the Cell Info Record. 11
Cell Info Record: 12
This set of fields contains information on all cells attached to this A3 13
connection, whether they are being newly attached to this A3 14
connection by the current operation or they were previously attached by 15
an earlier operation. If, after power combining is applied in the reverse 16
direction, multiple frames exist at the BS, pre-selection is applied to 17
these frames and a single frame is sent in the reverse direction on the 18
A3 traffic connection. 19
of the immediately following Cell Identification. 23
This field contains the Cell Identification of a cell associated with this 25
A3 connection. It shall be formatted according to octets 4 through the 26
end of the Cell Identifier element defined in section 4.2.5. 27
CCSH: 28
This field shall be set to 1 if CCSH (Code Combining Soft Handoff) 29
is supported by the target BS, and set to 0 otherwise. This field is only 30
applicable to the Supplemental Channel and shall be set to 0 for all 31
other channel types. 32
SR3_Incl: 33
This field indicates the use of Spreading Rate 3 (3X). The bit shall be 34
set to 1 if 3X Multi-Carrier is being used, and set to 0 otherwise. 35
QOF_Mask: 36
This field contains QOF (Quasi Orthogonal Function) mask index. This 37
QOF mask index coincides with the QOF mask index of air interface 38
air message. 39
TIA-2001.5-C
Section 4 198
The BTS shall set this field to the QOF mask in the range 00 to 11 1
inclusive that is used with the code channel index. 2
New Cell Indicator: 3
This field indicates whether the corresponding cell is being newly 4
added to an A3 traffic connection by the current procedure or was 5
already existing on this A3 traffic connection. 6
0 = an existing cell 7
1 = a newly added cell 8
PWR_Comb_Ind: 9
Power Control symbol combining indicator. 10
If the Forward Traffic Channel associated with this pilot carries the 11
same closed loop power control subchannel bits as that of the previous 12
pilot in this message, the BTS shall set this field to 1. Otherwise, the 13
BTS shall set this field to 0. The first occurrence of this field in this 14
element shall be set to 0. All subsequent occurrences of this field in 15
this element shall be set to 1. 16
Pilot_PN: 17
This field contains the pilot PN sequence offset index for the associated 18
cell. 19
The BTS shall set this field to the pilot PN sequence offset for this pilot 20
in units of 64 PN chips. 21
Code_Chan: 22
This field contains the code channel index for the associated cell. 23
The BTS shall set this field to the code channel index (refer to [1]~[6]) 24
in the range 00H to FFH inclusive that is to be used on the Forward 25
Traffic Channel associated with this pilot. For 3X Multi-Carrier 26
systems, this code channel index is used with the center frequency 27
channel. For the Supplemental Channel, this field is ignored. 28
Rev_FCH_Gating: 29
This field is used to indicate the reverse FCH gating capability at the 30
target BS. It is set to 1 if the target cell allows the MS to perform 31
reverse FCH gating; otherwise it is set to 0. 32
If the target BS allows reverse FCH gating, the target BS uses the same 33
value of Rev_Pwr_Cntl_Delay that is specified by the source BS. 34
Otherwise, if the target BS does not allow reverse FCH gating, the leg 35
will not be added. 36
Lower QOF Mask: 37
as specified in [2] that is used with the lower frequency channel in a 3X 39
Lower Code Chan: 41
channelize the downlink RF bit stream in a cdma2000call The high 43
with the lower frequency channel. This field is ignored if SR3_Incl is 45
set to 0. For the Supplemental Channel, this field is ignored. 46
TIA-2001.5-C
199 Section 4
Upper QOF Mask: 1
as specified in [2] that is used with the upper frequency channel in a 3X 3
Upper Code Chan: 5

call. The high 7
with the upper frequency channel. This field is ignored if SR3_Incl is 9
set to 0. For the Supplemental Channel, this field is ignored. 10
Length of Traffic Circuit ID: 11
contain the A3 Traffic Circuit ID value for this A3 connection. 13
Traffic Circuit ID: 14
This field is formatted exactly the same as the A3 Traffic Circuit ID 15
element from octet 3 to the end (refer to section 4.2.22). 16
Extended Handoff Direction Parameters Field Length: 17
This field indicates the number of octets contained in each occurrence 18
of the Extended Handoff Direction Parameters field. 19
Extended Handoff Direction Parameters: 20
This field is formatted exactly the same as the Extended Handoff 21
Direction Parameters element (refer to section 4.2.60) from octet 3 to 22
the end, and is repeated for each cell attached to this A3 connection in a 23
one-to-one correspondence with the cells listed in the Cell Info Record. 24
Length of Channel Element ID: 25
contain the Channel Element ID value for this A3 connection. This 27
field shall be set to 0000 0000 if no Channel Element ID value is 28
included in this element. 29
Channel Element ID: 30
This field is formatted exactly the same as the Channel Element ID 31
element (section 4.2.32) from octet 3 to the end. If a value is included 32
in this field, i.e., if the Length of Channel Element ID field contains a 33
value other than 0000 0000, this value shall be saved and sent by the 34
SDU function to the target BS in all subsequent A3 signaling messages. 35
Length of A3 Originating ID: 36
This field indicates the number of octets in the A3 Originating ID 37
immediately following the Length field. The maximum value in this 38
version of this specification is 8 octets. This field shall be set to 0000 39
0000 if no A3 Originating ID value is included in this element. 40
A3 Originating ID: 41
This field contains an identifier chosen by this (the near end) BS for its 42
own use in quickly processing A3 signaling messages received from 43
the far end BS. For example, it may be used to identify a particular leg 44
of a particular call, or it may identify the resources supporting that leg 45
that are internal to this BS. If an A7 Originating ID is supplied by this 46
BS, then the far end BS includes this in the A3 Destination ID element 47
in subsequent A3 messages to this BS related to the traffic connection. 48
TIA-2001.5-C
Section 4 200
Each instance of this field corresponds to one Cell Identification listed 1
above. 2
Length of A7 Destination ID: 3
This field indicates the number of octets in the A7 Destination ID 4
0000 if no A7 Destination ID value is included in this element. 7
A7 Destination ID: 8
This field is formatted exactly the same as the A3 Destination ID 9
element (section 4.2.44) from octet 3 to the end. If the A7 Originating 10
ID was included in the associated A7-Handoff Request message and 11
the A3 Flag was set to 1, then this field should be set to the value of 12
the A7 Originating ID. 13
14
TIA-2001.5-C
201 Section 4
4.2.38 A3 Connect Ack Information 1
This element contains information on a new or existing A3 connection referenced in a 2
corresponding A3 Connect Information element from the A3-Connect message that is 3
being responded to. 4
4.2.38 A3 Connect Ack Information
7 6 5 4 3 2 1 0 Octet
Length 2
Reserved Soft Handoff Leg # PMC
Cause
Present
Xmit
Notify
3
Length of Traffic Circuit ID 4
(MSB) Traffic Circuit ID - first octet 5

Traffic Circuit ID - last octet (LSB) m
Length of Channel Element ID m+1
(MSB) Channel Element ID - first octet m+2

Channel Element ID - last octet (LSB) n
PMC Cause n+1
Length of A3 Originating ID 1 p
(MSB) A3 Originating ID 1 p+1

(LSB) q

Length of A3 Originating ID n r
(MSB) A3 Originating ID n r+1

(LSB) s

Length of A3 Destination ID 1 t
(MSB) A3 Destination ID 1 t+1

(LSB) u

Length of A3 Destination ID n v
TIA-2001.5-C
Section 4 202
4.2.38 A3 Connect Ack Information
7 6 5 4 3 2 1 0 Octet
(MSB) A3 Destination ID n v+1

(LSB) w
Length: 1
Length field. 3
Xmit Notify: 4
This field indicates whether the target BS shall send an A3-Traffic 5
Channel Status message indicating that the transmitter and receiver of 6
the cell(s) at the target BS have been activated. 7
0 = Target BS shall not send an A3-Traffic Channel Status message 8
upon activation of the transmitter(s) and receiver(s). 9
1 = Target BS shall send an A3-Traffic Channel Status message upon 10
activation of the transmitter(s) and receiver(s). 11
PMC Cause Present: 12
This field indicates whether the PMC Cause field is present. This field 13
is always coded as 1 for backward compatibility with previous 14
versions of the IOS. 15
1 = A PMC Cause value is present. 16
This field is used to carry the soft handoff leg number as determined by 18
the source BS. The value in this field shall be transferred to the Soft 19
Handoff Leg # field of the Reverse Layer 3 Data element in the A3- 20
FCH/DCCH/SCH Reverse messages sent to the source BS. 21
contain the A3 Traffic Circuit ID value for this A3 connection. This 24
field shall be set to 0000 0000 if no A3 Traffic Circuit ID value is 25
element from octet 3 to the end (refer to section 4.2.22). This field is 29
optional if the Channel Element ID field of this element contains a 30
value. 31
element (section 4.2.32) from octet 3 to the end. If a value was included 39
in the Channel Element ID field of the corresponding A3 Connect 40
Information element, this field shall be set to the value that was saved 41
from that element. 42
TIA-2001.5-C
203 Section 4
PMC Cause: 1
This field is formatted exactly the same as octet 3 of the PMC Cause 2
element. If no error has occurred in processing the corresponding 3
Connect Information element from the A3 Connect message, then this 4
field shall contain a value of No Error. If an error has occurred in 5
processing the corresponding A3 Connect Information element from 6
the A3-Connect message, this field shall contain an appropriate PMC 7
Cause value as found in 4.2.24. 8
Length of A3 Originating ID: 9
Length field. The maximum value in this version of this specification is 11
8 octets. This field shall be set to 0000 0000 if no A3 Originating ID 12
value is included in this element. 13
This field contains an identifier chosen by this (the near end) BS for its 15
own use in quickly processing A3 signaling messages received from 16
the far end BS. For example, it may be used to identify a particular leg 17
of a particular call, or it may identify the resources supporting that leg 18
that are internal to this BS. If an A7 Originating ID is supplied by this 19
BS, then the far end BS includes this in the A3 Destination ID element 20
in subsequent A3 messages to this BS related to the traffic connection. 21
Originating IDs are listed in the same order as the cells were listed in 22
the corresponding A3 Connect Info IE. 23
in the A3 Originating ID field of the corresponding A3 Connect 32
from that element. Each instance of this field corresponds to one cell 34
supporting the specified A3 Traffic Circuit ID. 35
36
37
TIA-2001.5-C
Section 4 204
4.2.39 A3 Remove Information 1
This element contains information on one or more cells to be removed from a single 2
existing A3 connection. 3
4.2.39 A3 Remove Information
7 6 5 4 3 2 1 0 Octet
Length 2
(MSB) Traffic Circuit ID 4

(LSB) j
Number of Cells To Be Removed j+1
Cell Identification Discriminator 1 j+2
(MSB) Cell Identification 1 j+3

(LSB) k

Cell Identification Discriminator n m
(MSB) Cell Identification n m+1

(LSB) n
Length of A3 Destination ID 1 q
(MSB) A3 Destination ID 1 q+1

(LSB) r

Length of A3 Destination ID n s
(MSB) A3 Destination ID n s+1

(LSB) t
Length of A7 Destination ID t+1
(MSB) A7 Destination ID t+2

(LSB) u
TIA-2001.5-C
205 Section 4
Length: 1
Length field. 3
contain the A3 Traffic Circuit ID value for this A3 connection. 6
element from octet 3 to the end (refer to section 4.2.22). 9
Number of Cells To Be Removed: 10
This field contains a count of the number of Removed Cell 11
Identification Discriminator/Cell Identification pairs that follow. 12
of the immediately following Cell Identification field. Cell 16
Identification Discriminator values 0000 0010 and 0000 0111 are 17
allowed. 18
This field contains the Cell Identification of a cell associated with this 20
A3 connection. This field is formatted according to octets 4 through the 21
end of the Cell Identifier element as defined in section 4.2.5. 22
in the A3 Originating ID field of the corresponding A3 Connect Ack 31
from that element. Each instance of this field corresponds to one Cell 33
Identification listed above. 34
element (section 4.2.44) from octet 3 to the end. If the A7 Originating 42
ID was included in the associated A7-Handoff Request message and 43
the A3 Flag was set to 1, then this field should be set to the value of 44
the A7 Originating ID. 45
46
TIA-2001.5-C
Section 4 206
4.2.40 A3 Drop Information 1
This element indicates an A3 connection that is being removed in its entirety. 2
4.2.40 A3 Drop Information
7 6 5 4 3 2 1 0 Octet
Length 2
(MSB) Traffic Circuit ID j

(LSB) m
Length of Channel Element ID m+1
(MSB) Channel Element ID - first octet m+2

Channel Element ID - last octet (LSB) n
Length of A3 Destination ID 1 q
(MSB) A3 Destination ID 1 q+1

(LSB) r

Length of A3 Destination ID n s
(MSB) A3 Destination ID n s+1

(LSB) t
Length: 3
Length field. 5
contain the A3 Traffic Circuit ID value for this A3 connection. This 8
field shall be set to 0000 0000 if no A3 Traffic Circuit ID value is 9
element from octet 3 to the end (refer to section 4.2.22). This field is 13
optional if the Channel Element ID field of this element contains a 14
value. 15
TIA-2001.5-C
207 Section 4
element from octet 3 to the end. If a value was included in the Channel 5
Element ID field of the corresponding A3 Connect Information 6
element, this field shall be set to the value that was saved from that 7
element. 8
in the A3 Originating ID field of the corresponding A3 Connect Ack 17
from that element. Each instance of this field corresponds to one cell 19
supporting the specified A3 Traffic Circuit ID. 20
21
TIA-2001.5-C
Section 4 208
4.2.41 Air Interface Message 1
This information element is used to contain an air-interface message or Layer 2 2
acknowledgement received/to be sent on a control channel(s) by a target BS. 3
4.2.41 Air Interface Message
7 6 5 4 3 2 1 0 Octet
Length 2
TIA/EIA/IS-2000 Message Type 3
Air Interface Message Length 4
(MSB) Air Interface Message 5

(LSB) k
Length: 4
Length field. 6
TIA/EIA/IS-2000 Message Type: 7
This field contains the type of the message contained in the following 8
Air Interface Message field. It is provided to allow simpler recognition 9
and handling by the BS. This field is coded the same as the 10
MSG_TYPE field defined in [4].Air Interface Message Length: 11
This field contains a binary value indicating the number of octets in the 12
following Air Interface Message field. 13
Air Interface Message: 14
This field contains the air-interface message received/to be sent on a 15
control channel(s). 16
17
TIA-2001.5-C
209 Section 4
4.2.42 Layer 2 Ack Request/Results 1
This information element is used to contain a Layer 2 acknowledgement request or 2
results received/to be sent on a control channel(s) by a target BS. 3
4.2.42 Layer 2 Ack Request/Results
7 6 5 4 3 2 1 0 Octet
Length 2
Reserved Layer 2
Ack
3
Length: 4
Length field. 6
Layer 2 Ack: 7
When this element is included in the A7-Paging Channel Message 8
Transfer message, this bit shall be set to 1 to indicate that a Layer 2 9
acknowledgment is requested by the source BS. 10
When this element is included in the A7-Paging Channel Message 11
Transfer Ack message this bit is set to 0 by the target BS to indicate 12
failure to receive a Layer 2 acknowledgment, and is set to 1 by the 13
target BS to indicate that a Layer 2 acknowledgment was received from 14
the MS. 15
16
TIA-2001.5-C
Section 4 210
4.2.43 A7 Originating ID 1
This element contains an identifier chosen by this (the near end) BS for its own use in 2
quickly processing A7 signaling messages received from the far end BS. For example, it 3
may be used to identify the resources supporting the call association that are internal to 4
this BS. If an A7 Originating ID is supplied by this BS, then the far end BS includes this 5
in the A7 Destination ID element in subsequent A7 messages to this BS for this call 6
association. 7
4.2.43 A7 Originating ID
7 6 5 4 3 2 1 0 Octet
Length 2
Reserved A3 Flag 3
(MSB) A7 Originating ID 4

(LSB) k
Length: 8
9 octets. 11
A3 Flag: 12
If this field is set to 1 in the A7-Handoff Request message, then the 13
value of the A7 Originating ID should be returned in the A7 14
Destination ID parameter in all A3 messages sent from the target BS to 15
the source BS. 16
This field has variable length. The actual length is indicated in the 18
long. This value is chosen by the sending BS and is a manufacturers 21
concern. 22
23
TIA-2001.5-C
211 Section 4
4.2.44 A7 Destination ID 1
This element contains an identifier chosen by the far end BS for its own use in quickly 2
processing A7 signaling messages. 3
If an A7 Originating ID was supplied by the far end BS, then the near end BS includes 4
this value in the A7 Destination ID element in subsequent A7 messages to the far end BS 5
for this call association. 6
4.2.44 A7 Destination ID
7 6 5 4 3 2 1 0 Octet
Length 2
(MSB) A7 Destination ID 3

(LSB) k
Length: 7
8 octets. 10
long. 15
16
TIA-2001.5-C
Section 4 212
4.2.45 A3 Destination ID 1
This element contains an identifier chosen by the far end BS for its own use in quickly 2
processing A3 signaling messages. 3
If an A3 Originating ID was supplied by the far end BS, then the near end BS includes 4
this value in the A3 Destination ID element in subsequent A3 messages to the far end BS 5
related to the traffic connection. 6
4.2.45 A3 Destination ID
7 6 5 4 3 2 1 0 Octet
Length 2
(MSB) A3 Destination ID 3

(LSB) k
Length: 7
Length field. The maximum value is 8 octets. 9
long. 14
15
TIA-2001.5-C
213 Section 4
4.2.46 IS-2000 Power Control Info 1
This element provides information about power control for IS-2000 channels, including 2
information used for forward gain equalization for a given IS-2000 power control 3
subchannel and information used for reverse power control delay for a given IS-2000 4
FCH reverse gating operation mode. 5
4.2.46 I S-2000 Power Control Info
7 6 5 4 3 2 1 0 Octet
Length 2
FPC_
PRI_
CHAN
Reserved Rev_Pwr
_Cntl_
Delay_Incl
Rev_Pwr_Cntl
_Delay
Count of Subchan Gains 3
Reserved FPC_SUBCHAN_GAIN 1 4
Length: 12
Length field. 14
FPC_PRI_CHAN: 15
This field indicates which forward link physical channel supports the 16
power control channel (0 = forward FCH, 1 = DCCH). 17
Rev_Pwr_Cntl_Delay_Incl: 18
This field indicates if the reverse link power control delay is specified 19
when the source BS is allowing the MS to perform reverse FCH gating. 20
The coding of this field is as follows: 21
0 if the following reverse power control delay field is 22
ignored 23
1 if the following reverse power control delay field is 24
meaningful. 25
Rev_Pwr_Cntl_Delay: 26
The base station shall set this field to the closed-loop reverse power 27
control delay used by the MS after handoff, minus one. The field is 28
coded in units of 1.25 ms. Refer to [2] and [5] for more details. 29
Count of Subchan Gains: 30
This field indicates the number of fields immediately following that 31
represent the FPC_SUBCHAN_GAIN value that applies to the call 32
depending on the number of independent soft handoff legs. In this 33
TIA-2001.5-C
Section 4 214
version of the IOS, the value of this field is 3. The number of 1
independent soft handoff legs is sent in the A3 traffic frame. When 2
determining the number of independent soft handoff legs, a set of legs 3
in softer handoff are counted as a single leg. These values are shown in 4
Table 4.2.46-1: 5
Table 4.2.46-1 Subchannel Gain Values 6
Count of Independent
Soft Handoff Legs FPC_SUBCHAN_GAIN
1 leg FPC_SUBCHAN_GAIN 1
2 legs FPC_SUBCHAN_GAIN 2
3 legs FPC_SUBCHAN_GAIN 3
FPC_SUBCHAN_GAIN n: 7
This field specifies the power gain level of the forward link power 8
control subchannel, relative to that of the 20 ms frames at 9600 bps or 9
14400 bps, on the F-FCH or F-DCCH that the forward power control 10
subchannel is punctured on, for a given number of independent soft 11
handoff legs as indicated in the previous table. The resolution is 0.25 12
dB. (Defined in [5] section 3.7.3.3.2.31, General Handoff Direction 13
Message.) 14
15
TIA-2001.5-C
215 Section 4
4.2.47 IS-2000 Forward Power Control Mode 1
This element specifies the forward power control mode for IS-2000 channels. 2
4.2.47 I S-2000 Forward Power Control Mode
7 6 5 4 3 2 1 0 Octet
Length 2
Reserved FPC_MODE 3
Action
Time
Flag
Reserved ACTION_TIME 4
Length: 3
Length field. 5
FPC_MODE: 6
This field specifies the forward power control operating mode. This 7
indicates the power control subchannel configuration on the reverse 8
pilot channel. (Defined in [2] Table 2.1.3.1.10.1-1.) 9
Action Time Flag: 10
This field indicates whether the FPC Mode change is immediate. If this 11
field is set to 1, it indicates that the FPC Mode change shall occur 12
immediately and the ACTION_TIME field shall be ignored. Otherwise 13
(set to 0) it indicates that the FPC Mode change shall occur at the 14
time specified in the ACTION_TIME field. 15
ACTION_TIME: 16
This field shall be set to the CDMA System Time (refer to section 1.3 17
of [2]) in units of 80 ms (modulo 64) at which the values specified in 18
the fields of this element take effect. If 19
(ACTION_TIME message arrival time) mod 64 > 56 20
the message shall be considered late and the message shall be processed 21
immediately. 22
23
TIA-2001.5-C
Section 4 216
4.2.48 IS-2000 FPC Gain Ratio Info 1
This element provides information used for forward gain equalization for a given IS-2000 2
power control subchannel. 3
4.2.48 I S-2000 FPC Gain Ratio Info
7 6 5 4 3 2 1 0 Octet
Length 2
Initial Gain Ratio 7
Reserved Gain Adjust Step Size Count of Gain Ratio Pairs 8
Min Gain Ratio 1 9
Max Gain Ratio 1 10
Min Gain Ratio 2 11
Max Gain Ratio 2 12
Min Gain Ratio 3 13
Max Gain Ratio 3 14
[NOTE: These fields apply either to the primary power control subchannel or to the 4
secondary power control subchannel, depending on what message this information 5
element is included in.] 6
Gain Adjust Step Size: 7
This field indicates the amount of forward channel gain change to be 8
used by the target BS when making gain adjustments on the physical 9
channel measured by the power control subchannel. The resolution is 10
0.25 dB. 11
Initial Gain Ratio: 12
This field indicates the initial forward link gain for the physical channel 13
measured by the power control subchannel. It is to be used at the cell 14
when adding a given soft handoff leg. 15
This field is ignored if the forward power control mode is 50 Hz (EIB). 16
The initial gain ratio is expressed according to the formula given for the 17
Forward Link Power Control: Gain Ratio (FPC: GR) in the A3 traffic 18
frame format for the corresponding physical channel. 19
Count of Gain Ratio Pairs: 20
This field indicates the number of pairs of octets immediately following 21
that represent the Min Gain Ratio and Max Gain Ratio values that 22
apply to the call depending on the number of independent soft handoff 23
legs. In this version of the IOS, the value of this field is 3. The number 24
of independent soft handoff legs is sent in the A3 traffic frame of the 25
corresponding physical channel. When determining the number of 26
independent soft handoff legs, a set of legs in softer handoff are 27
counted as a single leg. These values are shown in Table 4.2.48-1: 28
TIA-2001.5-C
217 Section 4
Table 4.2.48-1 Independent Soft Handoff Legs 1

Count of Independent
Soft Handoff Legs

Minimum
Gain Ratio

Maximum
Gain Ratio
1 leg Min Gain Ratio 1 Max Gain Ratio 1
2 legs Min Gain Ratio 2 Max Gain Ratio 2
3 legs Min Gain Ratio 3 Max Gain Ratio 3
Min Gain Ratio: 2
This field indicates the minimum allowed forward link gain for the 3
physical channel measured by the power control subchannel. 4
The minimum gain ratio is expressed according to the formula given 5
for the Forward Link Power Control: Gain Ratio (FPC: GR) in the A3 6
traffic frame format for the corresponding physical channel. 7
Max Gain Ratio: 8
This field indicates the maximum allowed forward link gain for the 9
physical channel measured by the power control subchannel. 10
The maximum gain ratio is expressed according to the formula given 11
for the Forward Link Power Control: Gain Ratio (FPC: GR) in the A3 12
traffic frame format for the corresponding physical channel. 13
14
TIA-2001.5-C
Section 4 218
4.2.49 FCH/DCCH Forward Air Interval Control 1
This element contains control information for the CDMA Forward Fundamental or 2
Dedicated Control Channel frames flowing in the SDU to BTS direction. 3
4.2.49 FCH/DCCH Forward Air Interval Control
7 6 5 4 3 2 1 0 Octet
FPC:SLC FSN 1
FPC: GR 2
RPC: OLT 3
Reserved Air Interval Content Mask 5
16 (refer to section 1.3 of [2]) corresponding to the transmission time of 11
the frame over the air in the forward direction. 12
This parameter is required for EIB (50Hz) power control. It is also 14
useful during transitions of: soft handoff states, transmission rates, and 15
FER target values. 16
Min(!(A
t
/ A
p
) 128 ", 255 ) 18
where A
t
is the full-rate Forward Link gain (in volts), and A
p
is the 19
smallest Pilot Channel gain (in volts). The SDU shall set the FPC: GR 20
field in the range of 0 through 255. 21
Reverse Link Power Control: Outer-loop Threshold (RPC: OLT): 22
For RC1 and RC2, the SDU shall set this field to the desired Reverse 23
Traffic Channel E
w
/N
t
; i.e. the ratio of the total demodulated Walsh 24
symbol energy to total received power spectral density on the RF 25
channel. The E
w
/N
t
corresponding to 0dB to 31.875dB in units of 0.125dB. 28
For RC3 and all other higher RC, the SDU shall set this field to the 29
desired Reverse Pilot Ec/Io; i.e. the ratio of R-PICH chip energy to 30
total received power spectral density on the RF channel. 31
corresponding to -31.875dB to 0dB in units of 0.125dB. 33
This field indicates the frame content type for the 20 ms air traffic 35
frame, with the specific values taken from Table 4.2.15-2, Table 36
4.2.15-3, or Table 4.2.15-4. 37
TIA-2001.5-C
219 Section 4
Air Interval Content Mask: 1
This field contains a mask indicating the presence of a 20 ms forward 2
traffic frame and/or 5 ms traffic frames to be transmitted by the BTS. 3
The bits of this mask are coded as follows: 4
0 = not included 5
1 = included 6
Bit 4 indicates the inclusion of a 20 ms forward traffic frame. 7
The inclusion of 5 ms traffic frames in a forward traffic frame is 8
indicated in bits 3 through 0. They are listed in time order, where bit 3 9
indicates the inclusion of a 5 ms forward traffic frame to be sent in the 10
first 5 ms sub-interval of the 20 ms interval, and bit 0 indicates the 11
inclusion of a 5 ms forward traffic frame to be sent in the fourth 5 ms 12
sub-interval of the 20 ms interval. If no 5 ms traffic frames are 13
included, bits 3 through 0 are coded to 0. 14
15
TIA-2001.5-C
Section 4 220
4.2.50 FCH/DCCH Reverse Air Interval Control 1
This element contains control information for the CDMA Forward Fundamental or 2
Dedicated Control Channel frames flowing in the BTS to SDU direction. 3
4.2.50 FCH/DCCH Reverse Air Interval Control
7 6 5 4 3 2 1 0 Octet
RPC: S EIB/QIB 4
Reserved Air Interval Content Mask 5
FQI Reverse Link Quality n
Scaling: 13
are indicated in the table below. 15
Table 4.2.50-1 Reverse Layer 3 FCH/DCCH Data - Time Scale for the PLATE 16
Scaling Field Value Time Units PATE Range
00 0.125 ms 3.875 ms
01 1.0 ms 31.0 ms
10 1.25 ms 38.75 ms
11 5.0 ms 155 ms
which the A3-Forward Layer 3 Data message arrives at the BTS minus 19
31 time units, as determined by the Scaling field. 22
frame, with the specific values taken from Table 4.2.15-2, Table 25
4.2.15-3, or Table 4.2.15-4. 26
TIA-2001.5-C
221 Section 4
Reverse Power Control- Signal to Noise Ratio (RPC: S): 1
This field is coded as defined in section 4.2.15. 2
EIB/QIB: 3
When FPC_MODE is not equal to 011, 101, or 100 the BTS shall 4
set this field to 0. When FPC_MODE is equal to 011, 101, or 5
100, the BTS shall set this field to 1 if the EIB/QIB relating to the 6
FCH/DCCH received from the MS is 1; otherwise, the BTS shall set 7
this field to 0. Furthermore, FPC_MODE equal to 011, 101, or 8
100 implies that a Reverse Layer 3 DCCH Data frame is generated at 9
least once per 20 ms to convey QIB status. 10
Air Interval Content Mask: 11
This field contains a mask indicating the presence of a 20 ms reverse 12
traffic frame and/or 5 ms traffic frames received by the BTS. The bits 13
of this mask are coded as follows: 14
0 = not included 15
1 = included 16
Bit 4 indicates the inclusion of a 20 ms reverse traffic frame. 17
The inclusion of 5 ms traffic frames in a reverse traffic frame is 18
indicated in bits 3 through 0. They are listed in time order, where bit 3 19
indicates the inclusion of a 5 ms reverse traffic frame received in the 20
first 5 ms sub-interval of the 20 ms interval, and bit 0 indicates the 21
inclusion of a 5 ms reverse traffic frame received in the fourth 5 ms 22
sub-interval of the 20 ms interval. If no 5 ms traffic frames are 23
included, bits 3 through 0 are coded to 0. 24
There are up to four instances of the Reverse Traffic Channel Quality 25
octet, corresponding to each included traffic frame as indicated by the 26
Air Interval Content Mask field, starting with bit 4. Reverse Traffic 27
Channel Quality consists of the following two fields: 28
Traffic Frame CRC passes, and 0 if the CRC fails. 32
7
, the BTS shall (using an 33
implementation specific algorithm) set the FQI field to 1 if it can 34
determine that a reverse traffic frame CRC would have passed, and 0 35
otherwise. 36
BTS shall set the Reverse Link Quality field to the Inverted Re- 39
Encoded Symbol Error Rate or equivalent metric. The Inverted Re- 40
Encoded SER is the binary value of: 41

7
channel, within SCH bursts when there is no data to send, or when the DCCH is in
DTX mode.
TIA-2001.5-C
Section 4 222
1x repetition rate as listed in the IS-2000 Frame Content element (refer 2
to [2], Table 2.1.3.1.5-1 Code Symbol Repetition). 3
8
, or if a frame erasure is detected by 11
the BTS, the Reverse Link Quality field shall be set to 000 0000. 12
13

8
TIA-2001.5-C
223 Section 4
4.2.51 SCH Reverse Air Interval Control 1
This element contains control information for the CDMA Supplemental Channel frames 2
flowing in the BTS to SDU direction. 3
4.2.51 SCH Reverse Air Interval Control
7 6 5 4 3 2 1 0 Octet
Reserved EIB 5
64 (refer to section 1.2 of [1]~[6]) corresponding to the receive time of 11
the air interface frame in the reverse direction. 12
When Idle frames are sent on the forward link for purposes of obtaining 13
PATE for an upcoming SCH data burst, the FSN of the reverse Idle 14
SCH frame should be ignored. The timing of the reverse SCH Idle 15
frame may be asynchronous to future demodulated reverse SCH data 16
timing. 17
Traffic Frame CRC passes. Otherwise, the BTS shall set this field to 0 21
if the CRC fails or if there is no Reverse Link Information
9
. 22
BTS shall set this field to the Inverted Re-Encoded Symbol Error Rate 25
(SER) or equivalent metric. The Inverted Re-Encoded SER is the 26
binary value of: 27
1x repetition rate as listed in the IS-2000 Frame Content element. (refer 30
to [2]). 31

9
There is no Reverse Link Information when only a reverse pilot channel exists. For
channel, and it occurs when the SCH is in DTX mode.
TIA-2001.5-C
Section 4 224
10
Scaling: 13
are indicated in the table below. This field shall be set to 11 if no A3- 15
IS-2000 SCH Forward message was received. 16
Table 4.2.51-1 Reverse Layer 3 I S-2000 SCH Data - Time Scale for the PATE 17
00 0.125 ms 3.875 ms
01 1.0 ms 31.0 ms
10 1.25 ms 38.75 ms
11 5.0 ms 155 ms
which the A3-IS-2000 SCH Forward message arrives at the BTS minus 20
31 time units, as determined by the Scaling field. This field shall be 23
set to 00 0000 if no A3-IS-2000 SCH Forward message was received. 24
frame, with the specific values taken from Table 4.2.15-5. 27
EIB (Erasure Indicator Bit): 28
When FPC_MODE is not equal to 101 or 110, then the BTS shall 29
set this field to 0. When FPC_MODE is equal to 101 or 110, then 30
the BTS shall set this field to 1 if the EIB relating to the SCH 31
received from the MS is 1; otherwise, the BTS shall set this field to 32
0. Furthermore, FPC_MODE equal to 101 or 110 implies that a 33
Reverse Layer 3 SCH Data frame is generated at least once per 20 ms 34
to convey EIB status. 35
36

10
example, this occurs when the SCH is in DTX mode.
TIA-2001.5-C
225 Section 4
4.2.52 Forward 20 ms Data 1
This element contains the 20 ms Forward Traffic Frame that the BTS is to send to the 2
MS. This element may contain a 20 ms traffic frame for either an FCH or a DCCH 3
physical channel. 4
4.2.52 Forward 20 ms Data
7 6 5 4 3 2 1 0 Octet
(MSB) Forward Link Information + Layer 3 Fill 1

(LSB) n
BTS is to send to the MS. The SDU shall include the number of 7
Information Bits from Table 4.2.15-2, Table 4.2.15-3, or Table 4.2.15- 8
4, corresponding to the data rate of the Forward Link frame. The SDU 9
shall set the Information Bits to the information bits supplied by the 10
Multiplex Option Sublayer. The bit order shall be as specified in [1]. 11
Layer 3 Fill: 12
The SDU shall include the number of Layer 3 Fill bits from Table 13
4.2.15-2, Table 4.2.15-3, or Table 4.2.15-4 corresponding to the data 14
rate of the Traffic Channel frame. The Layer 3 Fill bits shall be set to 15
0. The fill bits are added at the end of the frame in the lower order bit 16
positions after the Forward Link Information. 17
18
TIA-2001.5-C
Section 4 226
4.2.53 Reverse 20 ms Data 1
This element contains the 20 ms Reverse Traffic Frame that the BTS received from the 2
MS. This element may contain a 20 ms traffic frame for either an FCH or a DCCH 3
physical channel. 4
4.2.53 Reverse 20 ms Data
7 6 5 4 3 2 1 0 Octet
(MSB) Reverse Link Information + Layer 3 Fill 1

(LSB) n
BTS received from the MS. The BTS shall include the number of 7
Information bits from Table 4.2.15-2, Table 4.2.15-3, or Table 4.2.15- 8
5, corresponding to the data rate of the Reverse Link frame. The BTS 9
shall set the Information Bits to the information bits received from the 10
MS which correspond to the Multiplex Sublayer in use (refer to 11
[1]~[6]). The BTS shall use the bit order specified in [1]~[6]. 12
Layer 3 Fill: 13
The SDU shall include the number of Layer 3 Fill bits from Table 14
4.2.15-2, Table 4.2.15-3, or Table 4.2.15-4 corresponding to the data 15
rate of the Traffic Channel frame. The Layer 3 Fill bits shall be set to 16
0. The fill bits are added at the end of the frame in the lower order bit 17
positions after the Reverse Link Information. 18
19
TIA-2001.5-C
227 Section 4
4.2.54 Forward 5 ms Data 1
This information element is used to support 5 ms signaling messages. This element 2
contains a Forward 5 ms message that the BTS is to send to the MS. 3
4.2.54 Forward 5 ms Data
7 6 5 4 3 2 1 0 Octet
(MSB) Forward Link Information 1
2
(LSB) 3
The SDU shall set this field to the 5 ms Message Forward Link 5
Information that the BTS is to send to the MS. The SDU shall set the 6
Information Bits to the information bits supplied by the Multiplex 7
Option Sublayer. The bit order shall be as specified in [1]. 8
9
TIA-2001.5-C
Section 4 228
4.2.55 Reverse 5 ms Data 1
This information element is used to support 5 ms signaling messages. This element 2
contains a Reverse 5 ms message that the BTS received from the MS. 3
4.2.55 Reverse 5 ms Data
7 6 5 4 3 2 1 0 Octet
(MSB) Reverse Link Information 1
2
(LSB) 3
The BTS shall set this field to the 5 ms Message Reverse Link 5
Information that the BTS received from the MS. The BTS shall set the 6
Information Bits to the information bits received from the MS which 7
correspond to the Multiplex Sublayer in use (refer to [1]~[6]). The BTS 8
shall use the bit order specified in [1]~[6]. 9
10
TIA-2001.5-C
229 Section 4
4.2.56 Cell Commitment Info List 1
fields: 3
4.2.56 Cell Commitment Info List
7 6 5 4 3 2 1 0 Octet
Length 2
Cell Commitment I nfo 1 {
Count of Physical Channels Committed Physical Channel 1 9
Reserved Committed Physical Channel 2 10
Length of Neighbor List 1 13
Neighbor List 1 - first octet 14
Neighbor List 1 - second octet 15

Neighbor List 1 - last octet j
}Cell Commitment I nfo 1

Cell Commitment I nfo n {
Cell Identification n k - k+4
Reserved Committed Physical Channel 1 k+5
Length of Neighbor List n k+9
Neighbor List n - first octet k+10
Neighbor List n - second octet k+11

Neighbor List n - last octet l
}Cell Commitment I nfo n
Length: 4
Length field. 6
TIA-2001.5-C
Section 4 230
This field is coded per section 4.2.5. It applies to all Cell Identification 2
fields present in this element, except those in the Neighbor List(s). 3
There shall be one instance of the Cell Commitment Info (the following set of fields) for 4
each cell in the Cell Identifier List of the corresponding A7-Handoff Request message. 5
This field is coded as per the equivalent octets described in section 7
4.2.5, and shall uniquely identify one cell. Only one cell can be 8
indicated per replication. 9
Count of Physical Channels: 10
The number of physical channels represented in this element. The value 11
shall be The same as the Count of Physical Channels in the 12
corresponding A7-Handoff Request message. If the value is 1H, then 13
Physical Channel 2, Physical Channel 3, and Physical Channel 4 shall 14
be coded as 0000. If the value is 02H, then Physical Channel 3 and 15
Physical Channel 4 shall be coded as 0000. If the value is 03H, then 16
Physical Channel 4 shall be coded as 0000. Also, the corresponding 17
Committed field(s) shall be set to 0 and ignored. 18
Committed: 19
This field indicates whether the requested cell has been committed for 20
the physical channel indicated in associated octet. This field is set to 1 21
if the target BS has added the indicated cell for the indicated physical 22
channel; otherwise it is set to 0. 23
This field contains the binary value used to indicate a type of physical 25
channel. The physical channels shall be the same as in the Physical 26
Channel Info element in the corresponding A7-Handoff Request 27
message. Valid values are shown below. 28
Value (hex) Physical Channel Type
0H IS-95 Fundamental Channel TIA/EIA/IS-95
1H Fundamental Channel (FCH) TIA/EIA/IS-2000
3H Dedicated Control Channel (DCCH) TIA/EIA/IS-2000
Length of Neighbor List: 29
This field is a binary value indicating the number of octets in the 30
Neighbor List following the Length of Neighbor List field. The length 31
shall be set to 0 if the cell is uncommitted for all Physical Channels. 32
Neighbor List: 33
This field is formatted exactly the same as the Neighbor List element 34
from octet 3 to the end. It contains information on the neighbor cells of 35
the target BS indicated in the Cell Identification field. This list may be 36
used by the source BS to update the MS neighbor list. 37
TIA-2001.5-C
231 Section 4
4.2.57 Extended Neighbor List 1
This element contains a list of the target BS neighbor cells. This list may be used by the 2
source BS to update the MS neighbor list. 3
4.2.57 Extended Neighbor List
7 6 5 4 3 2 1 0 Octet
Length 2
Number of Neighbors 3
Neighbor Record length 4
PILOT_PN 1 (LSB) 5
PILOT_PN
1
(MSB)
Short Cell Identification Discriminator 1 = [07H] 6
Cell Identification 1 Var.
(m)
BS ID (high octet) m+7
BS ID (Low Octet) m+8
Neighbor Type m+9
Band Class ARFCN (high bits) m+10
ARFCN (low bits) m+11

PILOT_PN n (LSB) k
PILOT_PN
n
(MSB)
Short Cell Identification Discriminator n = [07H] k+1
Cell Identification n Var.
(m)
BS ID (high octet) m+k+2
BS ID (Low Octet) m+k+3
Neighbor Type m+k+4
Band Class ARFCN(high bits) m+k+5
ARFCN (low bits) m+k+6
Length: 4
Length field. 6
Number of Neighbors: 7
This field contains the number of neighboring cells included in this 8
element. 9
Neighbor Record length: 10
This field represents the size of the neighbor record. 11
TIA-2001.5-C
Section 4 232
There is one instance of the next three fields for each cell in the neighbor list. 1
PILOT PN Code: 2
The PILOT PN Code is one of the 511 unique values for the pilot PN 3
sequence offset index. The offsets are in increments of 64 PN chips. 4
Short Cell Identification Discriminator: 5
This field is identical to Cell Identification Discriminator field specified 6
in section 4.2.5 except that only the least significant seven bits of the 7
eight bits of the Cell Identification Discriminator value are used. 8
This field is identical to Cell Identification field specified in section 10
4.2.5. 11
BS ID: 12
This field contains the identification of the BS that the cell is 13
subtending to. 14
Neighbor Type: 15
This field indicates the type of the neighbor. 00H indicates 16
TIA/EIA/IS-95A or TIA/EIA/IS-95B CDMA. 01H indicates 17
TIA/EIA/IS-2000 CDMA. 02H indicates that TIA/EIA/IS-95A, 18
TIA/EIA/IS-95B, and TIA/EIA/IS-2000 are all supported. All others 19
values are reserved. 20
Band Class: 21
This field represents the band class of the neighbor cell. It shall be 22
coded as in 4.2.25. 23
ARFCN: 24
This field represents the radio frequency of the cell. It shall be coded as 25
in 4.2.59. 26
27
TIA-2001.5-C
233 Section 4
4.2.58 A7 Burst Retry Delay List 1
This element contains a list of Burst Retry Delays that can be correlated to a list of 2
uncommitted cells. Each Burst Retry Delay specifies the minimum time in seconds that 3
the source BS should wait before sending another A7-Burst Request message for a 4
corresponding cell for a given call instance / session. 5
4.2.58 A7 Burst Retry Delay List
7 6 5 4 3 2 1 0 Octet
Length 2
Reserved Burst Retry Delay 1 3

Reserved Burst Retry Delay n n
Length 6
Length field. 8
Burst Retry Delay: 9
This field contains the burst retry delay. The target BS shall set the 10
Burst Retry Delay field in the range of 0 through 10 corresponding to 0 11
s (seconds) to 50 s in 5 s increments. The value 0 indicates that the 12
source BS may send another A7-Burst Request message at any time. 13
14
TIA-2001.5-C
Section 4 234
This element specifies identity information for one or more TIA/EIA-95 radio channels. 2
7 6 5 4 3 2 1 0 Octet
Length 2
Hard
Handoff
Number of Channels to Add Frame Offset 3
Walsh Code Channel Index n
Pilot PN
Code (high
part)
Power
Combined
Freq.
included
Reserved ARFCN (high part) n+2
ARFCN (low part) n+3
Length is the number of octets that follow this octet. The length of this element is 3
variable because more than one target cell may be requested in a TIA/EIA-95 handoff. 4
Therefore, this element provides the flexibility to specify multiple TIA/EIA-95 channels 5
that the target BS can accommodate. 6
In this version of the standard the Hard Handoff field shall be set to 0. 7
In this version of the standard the Number of Channels field shall be set to 001. 8
The Frame Offset field contains the number of 1.25 ms intervals relative to system time 9
that the forward and reverse traffic channels are delayed by the source. If this element is 10
returned to the source with the hard handoff indicator bit set, this field contains the frame 11
offset delay required by the target. 12
The following four octets may be included multiple times: 13
The Walsh Code Channel Index (octet n) specifies one of 64 possible Walsh Codes used 14
to channelize the downlink RF bit stream in a TIA/EIA-95 call. 15
Octets n+1 and n+2 contain the Pilot PN Code. The Pilot PN Code is one of 511 unique 16
values for the Pilot Channel offset. The offsets are in increments of 64 PN chips. 17
The Power Combined field is a flag that, when set to 1, indicates diversity combining of 18
the power control sub-channel of this TIA/EIA-95 code channel with the previous 19
TIA/EIA-95 code channel listed in this element. In other words, if this is the second 20
replication of octets n through n+3, then the power control sub-channel of this TIA/EIA- 21
95 code channel is diversity combined with power control sub-channel of the previous 22
replication of octets n through n+3. The first occurrence of this field in the IS-95 Channel 23
Identity element is set to zero. 24
Frequency Included is a flag indicating whether the frequency assignment is included. A 25
0 indicates no frequency assignment is present, a 1 indicates a frequency assignment 26
is present and is specified in the ARFCN field of this element. For code channel 27
TIA-2001.5-C
235 Section 4
assignments that are on the same TIA/EIA-95 channel frequency, this field shall be set to 1
0. 2
The ARFCN (Absolute RF Channel Number) in octets n+2 and n+3 identifies the 3
TIA/EIA-IS-95 frequency being used in the current mobile connection. This ARFCN has 4
a range of 0-2047 to accommodate the various frequency bands. The frequency bands are 5
shown below for clarification. When the Frequency Included flag is set to zero, the 6
ARFCN field shall be set to all binary zeros. 7
The Frequency Bands reserved for TIA/EIA-95 signaling system in the North American 8
cellular band class are covered with the following channel numbering scheme: 9
A band allocation of 311 channels and numbered for TIA/EIA-95 as 1-311. 10
B band allocation of 289 channels and numbered for TIA/EIA-95 as 356-644. 11
B band allocation of 39 channels and numbered for TIA/EIA-95 as 739-777. 13
The Frequency Bands reserved in the North American PCS band class are covered with 15
the following channel numbering scheme: 16
A-F band allocation of channels numbered from 25-1175. 17
18
TIA-2001.5-C
Section 4 236
4.2.60 Extended Handoff Direction Parameters 1
This information element is included in this version of the standard because it is used to 2
define fields in the A3 Connect Information information element. Refer to section 4.2.37. 3
4.2.60 Extended Handoff Direction Parameters
7 6 5 4 3 2 1 0 Octet
Length 2
Search Window A Size (Srch_Win_A) Search Window N Size (Srch_Win_N) 3
Search Window R Size (Srch_Win_R) Add Pilot Threshold (T_Add) high order bits 4
T_Add low order bits Drop Pilot Threshold (T_Drop) 5
Compare Threshold (T_Comp) Drop Timer Value (T_TDrop) 6
Neighbor Max Age (Nghbor_Max_AGE) Reserved 7
Reserved SOFT_SLOPE 8
Reserved ADD_INTERCEPT 9
Reserved DROP_INTERCEPT 10
Target BS P_REV 11
For coding of the parameters listed in this element, refer to [1]~[6]. 4
5
TIA-2001.5-C
237 Section 4
4.2.61 Rescue Request Info 1
The Rescue Request Info element is used to indicate to the target BS that a rescue 2
channel is required for a call. The information element is coded as follows: 3
4.2.61 Rescue Request Info
7 6 5 4 3 2 1 0 Octet
Length 2
Reserved Transm
it Flag
3
Length: 4
Length field. 6
Transmit Flag: 7
The transmit flag indicates to the target BS when to start transmitting 8
traffic frames to the MS: 9
0 Do not transmit until MS is acquired 10
1 Begin to transmit immediately. 11
12
13
TIA-2001.5-C
Section 4 238
4.2.62 A3 Traffic IP Address 1
This information element is used to identify a particular address between a BTS and a 2
source BS/SDU. 3
4.2.62 A3 Traffic IP Address
7 6 5 4 3 2 1 0 Octet
Length 2
Address Type 3
(MSB) Address 4
5
6
(LSB) 7
(MSB) Port 8
(LSB) 9
Length: 4
Length field. 6
Address Type: 7
This field indicates the type and format of the A3 Traffic IP Address as 8
given in Table 4.2.62-1. In this version of the standard only Internet 9
Protocol IPv4 is supported. 10
11
Table 4.2.62-1 A3 Traffic IP Address Type and Format 12
Type Format of the A3 IP Address Length of the A3 IP Address
IP Address: 13
This field contains the IP address of the A3 User Traffic. This field has 14
a length and format that depends on the Type field. 15
Port: 16
This field contains the port address (e.g. the UDP port number). 17
TIA-2001.5-C
239 Section 5
2
5.1 Timer Values 3
Timer
Name
Default
Value
(seconds)
Range of
Values
(seconds)

Granularity
(seconds)
Section
Reference
T
acm

0.5 0 - 1.0 0.1 5.2.10
T
bstreq

0.1 0 1.0 0.1 5.2.1
T
bstcom

0.1 0 1.0 0.1 5.2.2
T
chanstat

0.5 0 1.0 0.1 5.2.8
T
conn3

0.5 0 1.0 0.1 5.2.3
T
discon3

0.5 0 1.0 0.1 5.2.4
T
drptgt

5 1 10 1 5.2.5
T
tgtrmv

5 1 10 1 5.2.7
T
horeq

1 0 - 5 0.1 5.2.6
T
pcm

1 0 - 2 0.1 5.2.11
T
physical

1 0 10 1 5.2.9
T
2

60 0 255 1 5.12
T
4

60 0 255 1 5.13
5.2 A3/A7 Timer Definitions 6
7
5.2.1 T
bstreq
8
The T
bstreq
timer is used by the source BS to wait for the A7-Burst Response message 9
from the target BS. This timer is started when the A7-Burst Request message is sent and 10
stopped when A7-Burst Response messages have been received for all cells in the 11
corresponding A7-Burst Request message. 12
5.2.2 T
bstcom
13
The T
bstcom
timer is used by the target BS to wait for the A7-Burst Commit message 14
from the source BS. This timer is started when the A7-Burst Response message is sent 15
and stopped when A7-Burst Commit or the A7-Burst Response message has been 16
received. 17
TIA-2001.5-C
Section 5 240
5.2.3 T
conn3
1
The T
conn3
timer is used by the target BS to wait for the A3-Connect Ack message. This 2
timer is started when the A3-Connect message is sent and stopped when the A3-Connect 3
Ack message is received. 4
5.2.4 T
discon3
5
The T
discon3
timer is used by the target BS to wait for the A3-Remove Ack message. This 6
timer is started when the A3-Remove message is sent and stopped when the A3-Remove 7
Ack message is received. 8
5.2.5 T
drptgt
9
The T
drptgt
timer is used by the source BS to wait for the A7-Drop Target Ack message. 10
This timer is started when the A7-Drop Target message is sent and stopped when the A7- 11
Drop Target Ack message is received. 12
5.2.6 T
horeq
13
The T
horeq
timer is used by the source BS to wait for the A7-Handoff Request Ack 14
message. This timer is started when the A7-Handoff Request message is sent and stopped 15
when the A7-Handoff Request Ack message is received. 16
5.2.7 T
tgtrmv
17
The T
tgtrmv
timer is used by the target BS to wait for the A7-Target RemovalResponse 18
message. This timer is started when the A7-Target Removal message is sent and stopped 19
when the A7-Target Removal Response message is received. 20
5.2.8 T
chanstat
21
The T
chanstat
timer is used by the source BS/SDU to wait for the A3-Traffic Channel 22
Status messages for all new cells on an A3 connection. This timer is started when the A3- 23
Connect Ack message indicating that A3-Traffic Channel Status messages are requested 24
is sent and stopped when A3-Traffic Channel Status message(s) have been received for 25
all new cells on the A3 connection. 26
5.2.9 T
physical
27
The T
physical
timer is used by the source BS/SDU to wait for the A3-Physical Transition 28
Directive Ack message for an A3 connection. This timer is started when the A3-Physical 29
Transition Directive message is sent and stopped when A3-Physical Transition Directive 30
Ack message has been received. 31
TIA-2001.5-C
241 Section 5
5.2.10 T
acm
1
This is a target BS timer. The timer is started when an A7-Access Channel Message 2
Transfer message is sent and stopped when an A7-Access Channel Message Transfer Ack 3
5.2.11 T
pcm
5
This is a source BS timer. The timer is started when an A7-Paging Channel Message 6
Transfer message is sent and stopped when an A7-Paging Channel Message Transfer Ack 7
5.2.12 T
2
9
Timer T
2
represents the A7-Reset guard period in the BS that receives the A7-Reset 10
message. To avoid a deadlock situation during an A7-Reset procedure, timer T
2
11
(second BS) should always be less than timer T
4
(first BSC). 12
5.2.13 T
4
13
The first BS starts this timer when the A7-Reset message is sent and stops it when the 14
A7-Reset Acknowledge message is received. If timer T
4
expires without receiving a A7- 15
Reset Acknowledge message, the first BS repeats the A7-Reset procedure. To avoid a 16
deadlock situation during a first BS triggered global reset procedure, timer T
2
(second 17
BS) should always be less than timer T
4
(first BS). 18
TIA-2001.5-C
Section 5 242
1
2

TIA-2001.6-C
1
2
3
4
5
Interfaces) 7

TIA-2001.6-C

1
3

TIA-2001.6-C
i
Table of Contents 1
2
1.0 Introduction ........................................................................................................................................ 1 3
1.1 Overview........................................................................................................................................ 1 4
1.1.1 Purpose ................................................................................................................................... 1 5
1.1.2 Scope ...................................................................................................................................... 1 6
1.2 References ...................................................................................................................................... 1 7
1.2.1 TIA / EIA................................................................................................................................ 1 8
1.2.2 3GPP2..................................................................................................................................... 2 9
1.3 Terminology ................................................................................................................................... 3 10
1.3.1 Acronyms................................................................................................................................ 3 11
1.3.2 Definitions .............................................................................................................................. 4 12
1.7 Message Definition Guidelines....................................................................................................... 7 16
2.0 Message Procedures ........................................................................................................................... 9 17
2.1 A8/A9 Interface Setup Procedures And Messages ......................................................................... 9 18
2.1.1 A9-Setup-A8........................................................................................................................... 9 19
2.1.1.1 Successful Operation .......................................................................................................... 9 20
2.1.1.2 Failure Operation................................................................................................................ 9 21
2.1.2 A9-Connect-A8..................................................................................................................... 10 22
2.1.3 A9-BS Service Request ........................................................................................................ 10 25
2.1.4 A9-BS Service Response...................................................................................................... 10 28
2.2 A8/A9 Interface Clearing Procedures and Messages.................................................................... 11 31
2.2.1 A8/A9 Interface Clearing Procedures................................................................................... 11 32
2.2.1.1 Clearing Scenarios ............................................................................................................ 11 33
2.2.2 A9-Release-A8 ..................................................................................................................... 11 34
2.2.3 A9-Release-A8 Complete ..................................................................................................... 12 37
2.2.4 A9-Disconnect-A8................................................................................................................ 12 40
2.3 A8/A9 Interface Handoff Procedures and Messages .................................................................... 13 43
2.3.1 A9-Air Link (AL) Connected ............................................................................................... 13 44
2.3.2 A9-Air Link (AL) Connected Ack........................................................................................ 13 47
2.3.3 A9-Air Link (AL) Disconnected........................................................................................... 14 50
2.3.4 A9-Air Link (AL) Disconnected Ack................................................................................... 14 53
TIA-2001.6-C
ii
2.4 A8/A9 Interface Maintenance Procedures and Messages............................................................. 14 1
2.4.1 A9-Version Info.................................................................................................................... 14 2
2.4.2 A9-Version Info Ack ............................................................................................................ 15 5
2.5 A9 Session Update Procedures..................................................................................................... 15 8
2.5.1 A9-Update-A8 ...................................................................................................................... 15 9
2.5.2 A9-Update-A8 Ack............................................................................................................... 16 12
2.6 A8/A9 Interface Data Delivery Procedures and Messages........................................................... 16 15
2.6.1 A9-Short Data Delivery........................................................................................................ 16 16
2.6.2 A9-Short Data Ack ............................................................................................................... 17 19
3.0 Message Formats .............................................................................................................................. 19 22
3.1 A9-Setup-A8................................................................................................................................. 19 23
3.2 A9-Connect-A8 ............................................................................................................................ 24 24
3.3 A9-Disconnect-A8........................................................................................................................ 28 25
3.4 A9-Release-A8 ............................................................................................................................. 31 26
3.5 A9-Release-A8 Complete............................................................................................................. 34 27
3.6 A9-BS Service Request ................................................................................................................ 36 28
3.7 A9-BS Service Response.............................................................................................................. 38 29
3.8 A9-AL (Air Link) Connected ....................................................................................................... 39 30
3.9 A9-AL (Air Link) Connected Ack................................................................................................ 42 31
3.10 A9-AL Disconnected.................................................................................................................... 45 32
3.11 A9-AL Disconnected Ack ............................................................................................................ 47 33
3.12 A9-Short Data Delivery................................................................................................................ 48 34
3.13 A9-Short Data Ack ....................................................................................................................... 50 35
3.14 A9-Update-A8 .............................................................................................................................. 52 36
3.15 A9-Update-A8 Ack....................................................................................................................... 55 37
3.16 A9-Version Info............................................................................................................................ 56 38
3.17 A9-Version Info Ack.................................................................................................................... 57 39
4.0 Information Element Definitions...................................................................................................... 59 40
4.1 Generic Information Element Encoding....................................................................................... 59 41
4.1.1 Conventions .......................................................................................................................... 59 42
4.1.2 Information Element Identifiers............................................................................................ 60 43
4.1.3 Additional Coding and Interpretation Rules for Information Elements................................ 61 44
4.1.4 Cross Reference of Information Elements With Messages................................................... 62 45
4.2 Information Elements ................................................................................................................... 66 46
4.2.1 Active Connection Time in Seconds..................................................................................... 66 47
4.2.2 Mobile Identity ..................................................................................................................... 67 48
4.2.3 Cause .................................................................................................................................... 68 49
4.2.4 SR_ID................................................................................................................................... 70 50
4.2.5 PDSN Address...................................................................................................................... 71 51
4.2.6 User Zone ID........................................................................................................................ 72 52
4.2.7 Quality of Service Parameters .............................................................................................. 73 53
4.2.8 Service Option ...................................................................................................................... 74 54
4.2.9 ADDS User Part ................................................................................................................... 75 55
4.2.10 Call Connection Reference ................................................................................................... 76 56
TIA-2001.6-C
iii
4.2.11 Correlation ID....................................................................................................................... 77 1
4.2.12 Anchor P-P Address ............................................................................................................. 78 2
4.2.13 A9 Message Type ................................................................................................................. 79 3
4.2.14 CON_REF ............................................................................................................................ 80 4
4.2.15 A9 Cell Identifier .................................................................................................................. 81 5
4.2.16 A8 Traffic ID........................................................................................................................ 83 6
4.2.17 A9 Indicators ........................................................................................................................ 85 7
4.2.18 Data Count ............................................................................................................................ 86 8
4.2.19 Access Network Identifiers................................................................................................... 87 9
4.2.20 IS-2000 Service Configuration Record................................................................................. 88 10
4.2.21 Software Version .................................................................................................................. 89 11
4.2.22 Anchor PDSN Address ......................................................................................................... 90 12
4.2.23 A9 PDSN Code..................................................................................................................... 91 13
4.2.24 RN-PDIT .............................................................................................................................. 92 14
4.2.25 Service Instance Info ............................................................................................................ 93 15
5.0 Timer Definitions ............................................................................................................................. 95 16
5.1 Timer Values ................................................................................................................................ 95 17
5.2 Timer Definitions ......................................................................................................................... 95 18
5.2.1 T
A8-setup
.................................................................................................................................. 95 19
5.2.2 T
discon9
.................................................................................................................................... 95 20
5.2.3 T
rel9
........................................................................................................................................ 95 21
5.2.4 T
alc9
....................................................................................................................................... 95 22
5.2.5 T
waitho9
................................................................................................................................... 96 23
5.2.6 T
bsreq9
..................................................................................................................................... 96 24
5.2.7 T
ald9
....................................................................................................................................... 96 25
5.2.8 T
sdd9
....................................................................................................................................... 96 26
5.2.9 T
upd9
....................................................................................................................................... 96 27
5.2.10 T
aldak
...................................................................................................................................... 96 28
5.2.11 T
vers9
...................................................................................................................................... 96 29
30
31
TIA-2001.6-C
iv
List of Tables 1
2
Table 4.1.2-1 A9 Information Element Identifiers Sorted by Identifier Value ....................................... 60 4
Table 4.1.4-1 Cross Reference of Information Elements with Messages ............................................... 62 5
Table 4.2.2-1 Mobile Identity - Type of Identity Coding........................................................................ 67 6
Table 4.2.3-1 Cause Class....................................................................................................................... 68 7
Table 4.2.3-2 Cause Values .................................................................................................................... 69 8
Table 4.2.8-1 Service Option Values ...................................................................................................... 74 9
Table 4.2.15-1 Cell Identifier ............................................................................................................. 81 10
Table 4.2.16-1 A8 Traffic ID - A8 Transport Protocol Stack ............................................................ 83 11
Table 4.2.16-2 A8 Traffic ID - Address Type.................................................................................... 84 12
Table 4.2.23-1 PDSN Code Values.................................................................................................... 91 13
Table 5.1-1 Timer Values and Ranges Sorted by Name .......................................................................... 95 14
15
16
TIA-2001.6-C
1 Section 1
1.0 Introduction 1
2
1.1 Overview 3
This document contains the message procedures, bitmaps, information elements and 4
1.1.1 Purpose 6
The purpose is to provide the standard for interfacing a PCF with one or more BSs. This 7
document defines the functional capabilities, including services and features, of the 8
specified interface. These services and features are the defining characteristics that are 9
the basis for the overall system standard. 10
1.1.2 Scope 11
Reference Point A
quinter
Descriptions of the specified functional capabilities that provide packet data services 15
across the BS-PCF interface; 16
BS and the PCF without prescribing specific implementations. 18
1.2 References 19
20
1.2.1 TIA / EIA 21
1
Spread 27
29
cdma2000

cdma2000

Spread 35
[7] Reserved. 37

1
cdma2000

TIA-2001.6-C
Section 1 2
[8] TIA-IS-835-C, cdma2000

[9] TIA/EIA-41-D, Cellular Radiotelecommunications Intersystem Operations, 2
December 1997. 3
[10] Reserved. 4
Access 5
[12] Reserved. 7
[13] TIA -2001.3-C, Interoperability Specification (IOS) for cdma2000
Access 8
Access 10
Access 12
[16] Reserved. 14
[17] Reserved. 15
[18] TIA/EIA-637-B, Short Message Service for Wideband Spread Spectrum 16
[19] TIA/EIA/IS-707-A-2, Data Service Options for Spread Spectrum Systems - 18
Addendum 2, March 2001. 19
[20] TIA/EIA/IS-801-1, Position Determination Service Standards for Dual Mode 20
Spread Spectrum Systems, March 2001. 21
[21] TIA/EIA/TSB29-D, International Implementation of Wireless 22
Telecommunication Systems Compliant with ANSI/TIA/EIA-41, December 2000. 23
cdma2000

1.2.2 3GPP2 27

Spread Spectrum 32
34
cdma2000

38
Spread 40
[7] Reserved. 42
[9] Reserved. 44
[10] Reserved. 45
Access 46
[12] Reserved. 48
Access 49
TIA-2001.6-C
3 Section 1
Access 1
Access 3
[16] Reserved. 5
[17] Reserved. 6
[19] 3GPP2 C.S0017-0-2, Data Service Options for Spread Spectrum Systems - 9
Addendum 2, August 2000. 10
[20] 3GPP2 C.S0022-0-1, Position Determination Service Standard for Dual Mode 11
Spread Spectrum Systems - Addendum, February 2001. 12
[21] 3GPP2 N.S0017-A, International Implementation of Wireless 13
Telecommunication Systems Compliant with TIA/EIA-41, March 2001. 14
[22] 3GPP2 C.R1001-C, Administration of Parameter Value Assignments for CDMA 15
Spread Spectrum 17
1.3 Terminology 19
20
1.3.1 Acronyms 21
22
Acronym Meaning
BS Base Station
CON_REF
CVSE
Connection Reference
Critical Vendor/Organization Specific Extension
DRS Data Ready to Send
IS Interim Standard
MS Mobile Station
TIA-2001.6-C
Section 1 4
Acronym Meaning
Provisioning
PCF
PDSI
Packet Control Function
Packet Data Service Instance
PPP Point-to-Point Protocol
P-P PDSN-PDSN Interface
PZID Packet Zone Identifier
SR_ID Session Reference ID
UZID User Zone ID
1.3.2 Definitions 1
Refer to [11] for definitions. 2
For each A9 interface message there are a number of information elements that are 4
individually defined in section 4. Each information element in a given message is tagged 5
with a reference in section 4, a direction indication (i.e., some elements within a message 6
are bi-directional and others are not), and a mandatory/optional type (M/O) indicator. 7
Information elements that are marked as optional carry an additional indication of being 8
either required (R) or conditional (C) (see below). Some information elements are reused 9
in multiple messages. 10
15
TIA-2001.6-C
5 Section 1
BS -> PCF Element flows from the BS to the PCF
PCF->BS Element flows from the PCF to the BS
An information element may be mandatory for some messages and optional for other 15
messages. 16
the information elements of section 4 and use the following conventions: 18
double lines. 22
element. 25
indicates: 30
<octet 1> 35
<octet m> 36
TIA-2001.6-C
Section 1 6
ssss ssss 1
ssss ssss 3
This standard is intended to accommodate new features and capabilities. To ensure that 5
equipment implemented to one revision level interoperates with equipment implemented 6
to later revision levels, the following guidelines are defined for the processing of 7
messages and for the development of messages in future revisions of this standard. 8
version of the protocol may send information to an entity implemented at a lower level of 11
the protocol which is outside the protocol definition supported at that receiving entity. 12
protocol version used by other entities in the network. In these cases, the message 15
processing guidelines detailed in section 1.6 are invoked to ensure predictable network 16
behavior. 17
If the receiving entity is implemented to TIA/EIA/IS-2001 (IOS V4.0) or greater, then the 18
sending entity shall send messages that are correctly formatted for the version of the IOS 19
declared to be implemented by the sending entity. 20
3. 26
Also refer to message processing guidelines 9 and 10 below. 38
processed. 45
TIA-2001.6-C
7 Section 1
reserved or is otherwise not defined in the revision level implemented, this field 5
possible. In this situation, all other information elements in the message shall be 7
entity. 11
be ignored. 15
received. 31
not change. 35
6. Mandatory Information elements shall be sent in the order specified in section 3. 36
42
43
TIA-2001.6-C
Section 1 8
1
3
4
5
6
7
TIA-2001.6-C
9 Section 2
2
2.1 A8/A9 Interface Setup Procedures And Messages 3
This section contains the messages used to set up an A8 connection. 4
2.1.1 A9-Setup-A8 5
This message is sent from the BS to the PCF to request the establishment of an A8 6
connection (if required). 7
When the BS receives a request for a packet data service instance (PDSI) activation from 9
the MS (e.g., origination message with DRS bit set to 1) or when the BS receives a 10
request for re-activation of a PDSI from the PCF (e.g., A9-BS Service Request) or MSC 11
(e.g., Paging Request), and the MS has responded to a page (if not already on a traffic 12
channel), it initiates service negotiation to put the PDSI onto radio traffic channels, sends 13
an A9-Setup-A8 message indicating normal call setup (i.e., the Handoff Indicator field of 14
the A9-Setup-A8 message is set to 0), and starts timer T
A8-setup
. If no other PDSI is 15
active, the BS shall wait until the MSC has authorized the activation of the packet data 16
session (e.g., the BS receives an Assignment Request message) before sending the A9- 17
Setup-A8 message. 18
When the MS performs a hard handoff during packet data services, the target BS sends an 19
A9-Setup-A8 message to the PCF to establish an A8 connection upon receipt of the 20
Handoff Request message from the MSC and starts timer T
A8-setup
. In this case, the BS 21
sets the Handoff Indicator field of the A9-Setup-A8 message to 1 and the Data Ready 22
Indicator to 1. 23
When the BS receives a request for a dormant handoff from the MS (e.g., origination 24
message with DRS bit set to 0 or including PREV_PZID, PREV_SID, or PREV_NID), 25
the BS sends the A9-Setup-A8 message to the PCF and starts timer T
A8-setup
. In this case, 26
the BS sets the Handoff Indicator to 0. If no other PDSI is active, the BS shall wait until 27
the MSC has accepted the dormant handoff request (e.g., the BS receives an Assignment 28
Request or ADDS Transfer Ack message) before sending the A9-Setup-A8 message. 29
When the BS receives a request for CCPD Mode (e.g., origination message with DRS bit 30
set to 1 and SDB_DESIRED_ONLY bit set to 1) or initiates CCPD Mode, it sends an 31
A9-Setup-A8 message indicating CCPD Mode (i.e., the CCPD Mode bit in the message 32
is set to 1) and starts timer T
A8-setup
. The BS shall wait until the MSC has accepted the 33
service request (e.g., the BS receives an ADDS Transfer Ack message) before sending 34
the A9-Setup-A8 message. 35
36
If the BS fails to receive an A9-Connect-A8 message or an A9-Release-A8 Complete 38
message in response to an A9-Setup-A8 message before the expiration of timer T
A8-setup
, 39
the BS may resend the A9-Setup-A8 message to the PCF a configurable number of times 40
and restart timer T
A8-setup
. If the BS fails to receive an A9-Connect-A8 message or an 41
A9-Release-A8 Complete message before timer T
A8-setup
expires after a configurable 42
number of tries or the BS does not resend the A9-Setup-A8 message, the BS shall initiate 43
TIA-2001.6-C
Section 2 10
release of the MS or service negotiation to remove the PDSI from the traffic channel (if 1
required). 2
2.1.2 A9-Connect-A8 3
This A9 message is used to respond to an A9-Setup-A8 message. 4
The PCF sends an A9-Connect-A8 message to the BS in response to an A9-Setup-A8 6
message. If establishment of an A10 connection is needed (e.g., during normal call 7
setup), this message shall be sent after the connection establishment is successful. If the 8
Handoff Indicator field of the A9-Setup-A8 message is set to 1, the PCF starts timer 9
T
waitho9
after sending the first A9-Connect-A8 message. The PCF stops timer T
waitho9
10
upon receipt of the A9-AL (Air Link) Connected message. Upon receiving the A9- 11
Connect-A8 message, the BS stops the timer T
A8-setup
. 12
If the timer T
waitho9
expires, the PCF should initiate clearing of the A8 connection by 14
sending an A9-Disconnect-A8 message to the BS. The PCF starts timer T
discon9
. 15
2.1.3 A9-BS Service Request 16
This A9 interface message is sent from the PCF to the BS to begin a BS initiated call 17
setup. 18
To initiate the reactivation of a dormant service instance, the PCF sends an A9-BS 20
Service Request message to the BS. The PCF starts timer T
bsreq9
and awaits the reception 21
of the A9-BS Service Response message. 22
If an A9-BS Service Response message is not received at the PCF before the expiration 24
of timer T
bsreq9
, then the PCF may resend the A9-BS Service Request message. 25
2.1.4 A9-BS Service Response 26
This A9 interface message is sent from the BS to the PCF in response to an A9-BS 27
Service Request. 28
The BS shall send an A9-BS Service Response message to the PCF originating the A9- 30
BS Service Request message. Upon receiving the A9-BS Service Response Message, the 31
PCF stops timer T
bsreq9
. 32
None. 34
35
TIA-2001.6-C
11 Section 2
2.2 A8/A9 Interface Clearing Procedures and Messages 1
2
2.2.1 A8/A9 Interface Clearing Procedures 3
Procedures for clearing the A8 connection are described in this section. A8 connection 4
clearing is initiated whenever the state of the packet data service changes from the active 5
state to the dormant/null state. Clearing the A8 connection does not necessarily 6
correspond to clearing of the traffic channel or the packet data service session. 7
2.2.1.1 Clearing Scenarios 8
A8 connection(s) clearing occurs: 9
When a packet data inactivity timer in the BS expires for a PDSI. If it is the only 10
active PDSI for the MS, the BS requests the MSC to clear the service, sends an A9- 11
Release-A8 message to the PCF and starts timer T
rel9
. Otherwise, if it is not the only 12
active PDSI, the BS sends an A9-Release-A8 message to the PCF and starts timer 13
T
rel9
. For either case, the PCF responds with an A9-Release-A8 Complete message 14
and the BS stops timer T
rel9
. The two scenarios are illustrated by The BS Initiated 15
PDSI Release to Dormant State when no other PDSI is active and The BS Initiated 16
PDSI Release to Dormant State when other PDSIs are active in [13]. 17
When the BS receives a Release Order requesting the transition to dormant of a 18
PDSI, the BS performs the same procedures as in the BS initiated scenarios. The 19
scenarios are illustrated by The MS Initiated PDSI Release to Dormant State when 20
no other PDSI is active and The MS Initiated PDSI Release to Dormant State 21
when other PDSIs are active in [13]. 22
When the MS releases the packet data session. When the BS receives a Release 23
Order, the BS requests the MSC to clear the service, sends an A9-Release-A8 24
message to the PCF with a cause value set to normal release if only one A8 25
connection is active and starts timer T
rel9
. If this is not the only active PDSI, the 26
cause value is set to packet data session release and sent for only one of the A8 27
connections. The PCF responds with an A9-Release-A8 Complete message. The BS 28
stops timer T
rel9
.

The MS Power Down and MS Initiated Call Release to Null 29
State scenarios are shown in [13]. 30
When the A10 connection is released by the PDSN. When the PCF detects that an 31
A10 connection is released, the PCF sends an A9-Disconnect-A8 message to the BS 32
and starts timer T
discon9
. The BS initiates release of the A8 connection by sending an 33
A9-Release-A8 message and starts timer T
rel9
. The PCF responds with an A9- 34
Release-A8 Complete message and stops timer T
discon9
. If this is the last PDSI, the 35
BS clears any terrestrial resources and releases the air resources. Otherwise if this is 36
not for the last PDSI, the BS renegotiates the traffic channel. The scenarios are 37
illustrated by The PDSN Initiated Release of an active PDSI - Packet data session 38
becomes dormant or inactive and The PDSN Initiated Release of an active PDSI - 39
Packet data session remains active in [13]. 40
2.2.2 A9-Release-A8 41
This A9 interface message is sent from the BS to the PCF to request the release of the 42
associated dedicated resource. 43
TIA-2001.6-C
Section 2 12
When the BS needs to release an A8 connection, it sends an A9-Release-A8 message to 2
the PCF. 3
When the BS releases an A8 connection for the case where the MS has powered down, 4
the BS sends an A9-Release-A8 message to the PCF with the cause value Packet Data 5
Session Release included. This message triggers the PCF to release all A10 connections 6
associated with the MS. 7
rel9
and waits for the A9-Release-A8 Complete message from the 8
PCF. 9
When the PCF receives the A9-Release-A8 message, it stops timer T
discon9,
T
aldak,
or

10
T
waitho9
if active and performs the appropriate procedure to release the associated 11
dedicated resources. 12
If an A9-Release-A8 Complete message is not received from the PCF before timer T
rel9
14
expires, the BS may resend the A9-Release-A8 message to the PCF and restart timer T
rel9
15
a configurable number of times. If the A9-Release-A8 Complete message is not received 16
from the PCF, the BS shall cease further supervision of this PDSI, release the dedicated 17
resources associated with this PDSI, and release the A8 connection. 18
2.2.3 A9-Release-A8 Complete 19
This A9 interface message is sent from the PCF to the BS to acknowledge completion of 20
the request to release the A8 connection or to indicate to the BS that an A8 connection 21
has not been established due to either PCF (or PDSN) resources being unavailable, during 22
dormant handoffs if the PDSN has no data to send, or during a CCPD Mode call setup. 23
Upon receipt of the A9-Release-A8 message from the BS, the PCF closes the A8 25
connection and sends an A9-Release-A8 Complete to notify the BS of the outcome. 26
Alternatively, if upon receipt of the A9-Setup-A8 message the PCF determines that the 27
A8 connection either does not need to be or cannot be set up, the PCF shall send an A9- 28
Release-A8 Complete message to the BS. Upon receipt of this message the BS stops 29
timer T
A8-setup
if the message was sent in response to an A9-Setup-A8 message. The BS 30
stops timer T
rel9
if the message was sent in response to an A9-Release-A8 message. 31
None. 33
2.2.4 A9-Disconnect-A8 34
This A9 interface message is sent from the PCF to the BS to request to release the 35
associated dedicated resource. 36
When the PCF needs to release an A8 connection, it sends an A9-Disconnect-A8 message 38
to the BS. The PCF starts timer T
discon9
. 39
TIA-2001.6-C
13 Section 2
If an A9-Release-A8 message is not received from the BS before timer T
discon9
expires, 2
the PCF may resend the A9-Disconnect-A8 message to the BS and restart timer T
discon9
a 3
configurable number of times. If the A9-Release-A8 message is not received from the 4
BS, the PCF shall cease further supervision of this A8 connection, send the A9-Release- 5
A8 Complete message, and release its the resources associated with the A8 connection. 6
2.3 A8/A9 Interface Handoff Procedures and Messages 7
This section contains the messages used during handoff procedures. 8
2.3.1 A9-Air Link (AL) Connected 9
This message is sent from the target BS to the PCF after the MS performs hard handoff. 10
This message notifies the PCF that the handoff is successfully completed (i.e. that the air 11
link has been established between the MS and the target BS) and that the PCF can send 12
packets on the established A8 connection. The message may also be sent from the source 13
BS to the PCF in the case of handoff with return on failure. In this situation, the message 14
notifies the PCF that the MS has re-established the air link with the source BS, and the 15
PCF can resume sending packets to the source BS. 16
After the MS performs hard handoff including the case of return on failure, the BS 18
managing the active air link sends the A9-AL Connected message to the PCF. In the 19
case of handoff with return on failure the PCF stops timer T
aldak
message. 21
Upon the receipt of the A9-AL Connected message, the PCF updates its routing table to 22
route packet data sent from the PDSN to the BS managing the active air link, stops the 23
timers T
waitho9
for all established A8 connections, and starts timer T
alc9
. The A9-AL 24
Connected message triggers the PCF to establish A10 connections for all established A8 25
connections if needed (inter-PCF handoff). If the PCF is unable to establish an A10 26
connection, it sends an A9-Disconnect-A8 message to the BS for the corresponding A8 27
connection. 28
If the PCF supports fast handoff, and the A10 connections have already been established 29
if needed for all A8 connections, when the PCF receives the A9-AL Connected message 30
it starts to forward the data from the PDSN to the BS on all A8 connections. 31
If timer T
alc9
expires, the message may be resent. If the A9-AL-Connected message is not 33
resent or resending of this message also results in failure, the BS shall initiate release of 34
the packet data session. 35
If timer T
waitho9
expires, the PCF shall send an A9-Disconnect-A8 message for the 36
associated A8 connection to the BS. The PCF shall start timer T
discon9
. 37
2.3.2 A9-Air Link (AL) Connected Ack 38
The A9-AL Connected Ack message is sent from the PCF to the BS to indicate the result 39
of processing the A9-AL Connected message. 40
TIA-2001.6-C
Section 2 14
Upon receipt of an A9-AL Connected message from the BS, the PCF shall transmit an 2
A9-AL Connected Ack message to the BS to indicate the outcome of processing the 3
received message. The target BS shall stop timer T
alc9
. 4
None. 6
2.3.3 A9-Air Link (AL) Disconnected 7
When the MS performs hard handoff, the A9-AL Disconnected message is sent from the 8
source BS to the source PCF. This message is sent to notify the source PCF that the air 9
link is temporarily disconnected. An A9-AL Disconnected Ack message is expected in 10
response. 11
When the source BS receives the Handoff Command message which instructs it to 13
perform hard handoff, the source BS shall send an A9-AL Disconnected message to the 14
PCF and start timer T
ald9
. 15
Upon receipt of an A9-AL Disconnected message from the source BS, the PCF shall stop 16
transmitting packet data to the BS for all packet data service instances and start buffering 17
packets from the PDSN. 18
If timer T
ald9
expires, the message may be resent. 20
2.3.4 A9-Air Link (AL) Disconnected Ack 21
The A9-AL Disconnected Ack message is sent from the PCF to the BS to indicate the 22
result of processing the A9-AL Disconnected message. 23
Upon receipt of an A9-AL Disconnected message from the BS, the PCF shall transmit an 25
A9-AL Disconnected Ack message to the BS to indicate the outcome of processing the 26
received message. The source BS shall stop timer T
ald9
upon receipt of the A9-AL 27
Disconnected Ack message. The PCF starts timer T
aldak.
28
If timer T
aldak
expires, the PCF may resend the A9-AL Disconnected Ack to the BS. 30
2.4 A8/A9 Interface Maintenance Procedures and Messages 31
This section describes the A9 version control messages. 32
2.4.1 A9-Version Info 33
This A9 interface message is sent from the PCF to the BS, or the BS to the PCF, when 34
the sending entity requires the software version information of the receiving entity. The 35
message may also be sent as a result of a BS or PCF reset. The sending entity includes its 36
TIA-2001.6-C
15 Section 2
software version information in the message and a cause value if the message is sent as 1
the result of a reset. 2
The sending entity starts timer T
vers9
after the message is sent. The receiving entity 4
responds with the A9-Version Info Ack message, and includes its software version 5
information in the message. 6
If the receiving entity fails to respond with an A9-Version Info Ack message prior to the 8
expiration of timer T
vers9
the sending entity may resend the message. 9
2.4.2 A9-Version Info Ack 10
This A9 interface message is sent from the PCF to the BS, or the BS to the PCF, in 11
response to the A9-Version Info message. The message includes the software version 12
information of the entity sending the message. 13
The BS or PCF that receives the A9-Version Info Ack message stops timer T
vers9
upon 15
reception of the message. 16
If a BS or PCF receives the A9-Version Info Ack message without initiating the 18
procedure with an A9-Version Info message, the message shall be ignored. 19
2.5 A9 Session Update Procedures 20
This section contains message procedures for passing update information over the A9 21
interface. The A8 connection may or may not be established prior to sending an update 22
on the A9 interface. 23
2.5.1 A9-Update-A8 24
The A9-Update-A8 message is sent from the PCF to the BS to update the BS with new or 25
updated parameters for a packet data service instance or packet data session. The packet 26
data session shall be active when this message is sent to the BS. 27
The A9-Update-A8 message is sent from the BS to the PCF to convey accounting 28
information to the PCF if the A8 connection is established before traffic channel 29
establishment (in which case the PCF resumes data transmission on the A8 connection 30
only after it receives the A9-Update-A8 message) or while a packet data service instance 31
is active following accounting parameter changes which need to be conveyed to the 32
PDSN indirectly via the PCF. 33
The BS sends the A9-Update-A8 message to the PCF to indicate a successful Short Data 34
Burst delivery to the MS. 35
The A9-Update-A8 message is also used to inform the PCF of an authentication failure at 36
the MSC following an access attempt by an MS undergoing dormant handoff. The BS 37
can also use this message to inform the PCF that a dormant MS has powered down. In 38
these two cases, the PCF initiates the release of all A10 connections associated with the 39
MS. 40
TIA-2001.6-C
Section 2 16
If the A9-Update_A8 message is sent from the PCF to the BS to update packet data 2
session parameters, the PCF includes the Cause element set to Session parameter update 3
upon reception of any new or updated session parameters from the PDSN. After sending 4
the message to the BS, the PCF starts timer T
upd9
and waits for an A9-Update-A8 Ack 5
message from the BS. 6
If the message is sent from the BS to the PCF to pass accounting or authentication 7
information, the BS shall set the Cause field to the appropriate value, start timer T
upd9
, 8
and wait for an A9-Update-A8 Ack message from the PCF. 9
When the message is sent from the PCF to the BS to update parameters for a packet data 11
service instance, if T
upd9
expires, the PCF may resend the A9-Update-A8 message to the 12
BS and restart timer T
upd9
a configurable number of times. If the A9-Update-A8-Ack 13
message is not received from the BS, the session update procedure is considered failed 14
and the PCF notifies the PDSN. In the event of a failure, if an A8 connection was active 15
prior to the session update procedure, it shall remain connected. 16
When the message is sent from the BS to the PCF to pass accounting or authentication 17
information, if an A9-Update-A8 Ack is not received from the PCF before timer T
upd9
18
expires, the BS may resend the A9-Update-A8 message and restart timer T
upd9
a 19
configurable number of times. If the Acknowledgment is not received from the PCF, the 20
BS ceases sending this message, and commences packet data service instance clearing. 21
2.5.2 A9-Update-A8 Ack 22
This A9 interface message is sent to indicate the result of processing the A9-Update-A8 23
message. 24
Upon receipt of an A9-Update-A8 message, the receiving entity shall transmit the A9- 26
Update-A8 Ack message to indicate the result of processing the received message. The 27
sending entity shall stop timer T
upd9
upon receipt of the A9-Update-A8 Ack message. 28
None. 30
31
2.6 A8/A9 Interface Data Delivery Procedures and Messages 32
33
2.6.1 A9-Short Data Delivery 34
This A9 interface message is sent from the BS to the PCF when it receives a short data 35
burst from the MS. It may also be sent from the PCF to the BS when there is a small 36
amount of packet data to be sent from the PDSN to an MS, and the PCF determines that a 37
short data burst should be used to transmit this data. This message is used when the MSs 38
packet data service instance is dormant. The data is encapsulated in the ADDS user part 39
element in SDB format as specified in [19]. 40
TIA-2001.6-C
17 Section 2
When used in the PCF to BS direction, the PCF retains a copy of the data sent in the 1
message. The message also contains a count of the number of additional bytes of data 2
remaining at the PCF for the packet data service instance. This information may be used 3
by the BS, for example in determining whether short data bursts could be used to deliver 4
the data to the MS. 5
The BS sends the A9-Short Data Delivery message to the PCF after receiving a short data 7
burst from the MS and after optionally authenticating the MS. Upon receipt of this 8
message by the PCF, the packet data is sent to the PDSN on the A10 connection 9
associated with service instance indicated in the A9-Short Data Delivery. 10
The PCF sends the A9-Short Data Delivery message to the BS when it determines that 11
there is a small amount of data to be sent to a dormant packet data service instance at the 12
MS or if the packet data service is operating in CCPD Mode. The PCF starts timer T
sdd9
13
and waits for an A9-Short Data Ack message from the BS. If the BS decides that the data 14
can be sent to the MS as a Short Data Burst, an A9-Short Data Ack message is sent to the 15
PCF with a successful cause value. The BS may also reject the PCFs request for a short 16
data burst delivery via the A9-Short Data Ack. 17
If timer T
sdd9
expires before the PCF receives an A9-Short Data Ack message from the 19
BS, the buffered data at the PCF is discarded. 20
2.6.2 A9-Short Data Ack 21
This message is sent from the BS to the PCF to acknowledge the receipt of the A9-Short 22
Data Delivery message from the PCF. It also indicates to the PCF whether the data 23
received is to be sent to the MS as a short data burst. 24
If the BS decides to send the data received from the PCF to the MS as a short data burst, 26
it shall indicate this to the PCF in the A9-Short Data Ack message. Upon receiving this 27
indication, the PCF stops timer T
sdd9
and discards its copy of the buffered data. Note that 28
acceptance of the data is independent of the mechanism the BS chooses to send the data 29
to the MS over the air interface. The BS may send this data directly to the MS via a short 30
data burst, or it may forward the data to the MSC using the BS Service Request/Response 31
procedure. If the BS is unsuccessful in delivering the data to the MS on its own, it may 32
choose to send the data to the MSC for delivery to the MS via the ADDS Page procedure. 33
If the BS decides against delivering the data to the MS as an SDB, it shall respond to the 34
PCF with an A9-Short Data Ack message with a reject indication. Upon reception of this 35
message, the PCF shall stop timer T
sdd9
and then initiate re-activation of the packet data 36
service instance from the dormant state by sending an A9-BS Service Request message to 37
the BS. Refer to [13] for more details. 38
None. 40
41
TIA-2001.6-C
Section 2 18
1
3
4
5
6
7
TIA-2001.6-C
19 Section 3
2
3.1 A9-Setup-A8 3
This message is sent from the BS to the PCF to request the establishment of an A8 4
connection. 5
Reference
A9 Message Type 4.2.13 BS -> PCF M
Call Connection Reference 4.2.10 BS -> PCF O R
Correlation ID 4.2.11 BS -> PCF O
a
C
Mobile Identity (IMSI) 4.2.2 BS -> PCF O R
Mobile Identity (ESN) 4.2.2 BS -> PCF O
b
C
CON_REF 4.2.14 BS -> PCF O R
Quality of Service Parameters 4.2.7 BS -> PCF O
c
C
A9 Cell Identifier 4.2.15 BS -> PCF O R
A8 Traffic ID 4.2.16 BS -> PCF O R
Service Option 4.2.8 BS -> PCF O R
A9 Indicators 4.2.17 BS -> PCF O R
User Zone ID 4.2.6 BS -> PCF O
d
C
IS-2000 Service Configuration Record 4.2.20 BS -> PCF O
e
C
Access Network Identifiers 4.2.19 BS -> PCF O
f
C
PDSN Address 4.2.5 BS -> PCF O
g
C
Anchor PDSN Address 4.2.22 BS -> PCF O
h
C
Anchor P-P Address 4.2.12 BS -> PCF O
i
C
SR_ID 4.2.4 BS -> PCF O
j
R
a. If this element is included in this message, its value shall be returned in the 6
corresponding element in the A9-Connect A8 message sent in response to this 7
message. 8
b. This second occurrence of the Mobile Identity element, if included, shall contain the 9
ESN of the MS. Use of the ESN in this message is a network operator decision. 10
c. This information element is included if QoS information is available at the BS. In 11
this version of this standard, this element is used to carry the current non-assured 12
mode priority of the packet data session. 13
d. The User Zone ID is included if received from the MS. 14
e. This information element may be omitted if the BS does not possess this information 15
at the time the message is created. 16
f. The Previous Access Network Identifiers are included if received from the MS or the 17
MSC. 18
g. This is the A11 interface IP address of the source PDSN. This element is only 19
present if the BS received this information from the source BS as part of a hard or 20
fast handoff request. 21
TIA-2001.6-C
Section 3 20
h. This is the A11 interface IP address of the anchor PDSN. This element is only 1
present if the BS received this information from the source BS as part of a fast 2
handoff request. 3
i. This is the P-P interface IP address of the anchor PDSN. This element is only present 4
if the BS received this information from the source BS as part of a fast handoff 5
request. 6
j. This element specifies the SR_ID of the service instance in the Service Option 7
element. 8
The following table shows the bitmap layout for the A9-Setup-A8 message. 9
3.1 A9-Setup-A8
7 6 5 4 3 2 1 0 Octet
! !! ! A9 Message Type = [01H] 1
! !! ! Call Connection Reference: A9 Element Identifier = [3FH] 1
Length = [08H] 2
(LSB) 4
(LSB) 6
8
9
(LSB) 10
! !! ! Correlation ID: A9 Element Identifier = [13H] 1
Length = [04H] 2
4
5
(LSB) 6
Indicator
= [1,0]
Type of Identity
= [110] (IMSI)
3

Length = [05H] 2
TIA-2001.6-C
21 Section 3
3.1 A9-Setup-A8
7 6 5 4 3 2 1 0 Octet
Indicator
= [0]
Type of Identity
= [101] (ESN)
3
5
6
(LSB) 7
! !! ! CON_REF: A9 Element Identifier = [01H] 1
Length = [01H] 2
IS-2000 CON_REF = [00H FFH] 3
Length = [01H] 2
1101]
3
! !! ! A9 Cell Identifier: A9 Element Identifier = [06H] 1
Length = [06H] 2
5
(LSB) 6
! !! ! A8 Traffic ID: A9 Element Identifier = [08H] 1
Length = [0CH] 2
A8 transport protocol stack = [01H] (GRE/IP) 3
(MSB) Protocol Type = [88 81H] (Unstructured byte stream) 4
(LSB) 5
(MSB) Key = <any value> 6
7
8
(LSB) 9
(MSB) IP Address = <any value> 11
12
13
(LSB) 14
TIA-2001.6-C
Section 3 22
3.1 A9-Setup-A8
7 6 5 4 3 2 1 0 Octet
= [00 21H (3G High Speed Packet Data),
00 3CH (Link Layer Assisted Header Removal)
00 3DH (Link Layer Assisted RObust Header Compression)]
(LSB) 3
! !! ! A9 Indicators: A9 Element Identifier = [05H] 1
Length = [01H] 2
Reserved = [0000] CCPD
Mode
= [0,1]
Reserved
= [0]
Data
Ready
Indicator
= [0,1]
Handoff
Indicator
= [0, 1]
3
Length = [02H] 2
(LSB) 4
Reserved
= [0000 0]
= [000 111]
3
(MSB) 4

Seventh
Fill Bit
if needed
= [0 (if
used as a
fill bit)]
Sixth
Fill Bit
if
needed
= [0 (if
used as
a fill
bit)]
Fifth
Fill Bit
if
needed
= [0 (if
used as
a fill
bit)]
Fourth
Fill Bit
if needed
= [0 (if
used as a
fill bit)]
Third Fill
Bit if
needed
= [0 (if
used as a
fill bit)]
Second
Fill Bit
if needed
= [0 (if
used as a
fill bit)]
First Fill
Bit if
needed
= [0 (if
used as a
fill bit)]
k
! !! ! Access Network Identifiers: A9 Element Identifier = [20H] 1
Length = [05H] 2
Reserved
= [0]
(LSB) 4
(LSB) 6
! !! ! PDSN Address: A9 Element Identifier = [14H] 1
Length = [04H] 2
(MSB) PDSN Address = <any value> 3
TIA-2001.6-C
23 Section 3
3.1 A9-Setup-A8
7 6 5 4 3 2 1 0 Octet
4
5
(LSB) 6
Length = [04H] 2
4
5
(LSB) 6
! !! ! Anchor P-P Address: A9 Element Identifier = [40H] 1
Length = [04H] 2
(MSB) Serving P-P IP Address = <any value> 3
4
5
(LSB) 6
! !! ! SR_ID: A9 Element Identifier = [0BH] 1
Length = [01H] 2
Reserved = [0000 0] IS-2000 SR_ID = [001 - 110] 3
1
TIA-2001.6-C
Section 3 24
3.2 A9-Connect-A8 1
This message is sent from the PCF to the BS to complete the setup of the A8 connection. 2
Reference
A9 Message Type 4.2.13 PCF -> BS M
Call Connection Reference 4.2.10 PCF -> BS O R
Correlation ID 4.2.11 PCF -> BS O
a
C
Mobile Identity (IMSI) 4.2.2 PCF -> BS O R
Mobile Identity (ESN) 4.2.2 PCF -> BS O
b
C
CON_REF 4.2.14 PCF -> BS O R
A8 Traffic ID 4.2.16 PCF -> BS O R
Cause 4.2.3 PCF -> BS O R
PDSN Address 4.2.5 PCF -> BS O
c
C
Anchor PDSN Address 4.2.22 PCF -> BS O
d
C
Anchor P-P Address 4.2.12 PCF -> BS O
e
C
SR_ID 4.2.4 PCF -> BS O
f
R
Service Instance Info 4.2.25 PCF -> BS O
g
C
a. This element shall only be included if it was also included in the A9-Setup-A8 3
message. This element shall be set to the value received in that message. 4
c. This is the A11 interface IP address of the target PDSN that terminates the A10 7
connection corresponding to the just-established A8 connection. If an A10 8
connection has been established, this element is included in this message and saved 9
by the BS, and included in the Handoff Required message in the event of a hard 10
handoff. 11
d. This is the A11 interface IP address of the anchor PDSN. This element shall be 12
included if the Anchor P-P Address is included. During a fast handoff, it shall 13
contain the same value as the Anchor PDSN Address received in the A9-Setup-A8 14
message; otherwise it shall be set to the same value as the PDSN Address. It is saved 15
by the BS and included in the Handoff Required message in the event of a fast 16
handoff. During a fast handoff, inclusion of this field indicates acceptance of the fast 17
handoff. 18
e. This is the IP address for establishing P-P connections to the serving PDSN . This 19
element shall be included if fast handoff is supported and if the value was received 20
from the PDSN. It is saved by the BS and included in the Handoff Required message 21
in the event of a fast handoff. During a fast handoff, inclusion of this field indicates 22
acceptance of the fast handoff. 23
f. This element specifies the SR_ID of the connected service instance. 24
g. This element identifies all service instances for which the PCF has an A10 25
connection, excluding the service instance identified by the SR_ID information 26
element. This element shall be included on transition of the packet data session to the 27
Active State, i.e., when the first A8 connection of a packet data session is being 28
TIA-2001.6-C
25 Section 3
established, but not during handoff (i.e., the Handoff Indicator in the A9-Setup-A8 1
message was set to 1). 2
3
The following table shows the bitmap layout for the A9-Connect-A8 message. 4
3.2 A9-Connect-A8
7 6 5 4 3 2 1 0 Octet
Length = [08H] 2
(LSB) 4
(LSB) 6
8
9
(LSB) 10
Length = [04H] 2
4
5
(LSB) 6
Indicator
= [1,0]
Type of Identity
= [110] (IMSI)
3

Length = [05H] 2
Indicator
= [0]
Type of Identity
= [101] (ESN)
3
5
TIA-2001.6-C
Section 3 26
3.2 A9-Connect-A8
7 6 5 4 3 2 1 0 Octet
6
(LSB) 7
Length = [01H] 2
Length = [0CH] 2
(LSB) 5
7
8
(LSB) 9
12
13
(LSB) 14
Length = [01H] 2
[13H (Successful operation),
32H (PCF (or PDSN) resources not available),
79H (PCF (or PDSN) resources are not available),
7AH (Data ready to send)]
3
Length = [04H] 2
4
5
(LSB) 6
Length = [04H] 2
TIA-2001.6-C
27 Section 3
3.2 A9-Connect-A8
7 6 5 4 3 2 1 0 Octet
4
5
(LSB) 6
Length = [04H] 2
4
5
(LSB) 6
Length = [01H] 2
Reserved = [0000 0] IS-2000 SR_ID = [001 - 011] 3
! !! ! Service Instance Info: A9 Element Identifier = [41H] 1
Length = [00-0FH] 2
Reserved SR_ID-6 SR_ID-5 SR_ID-4 SR_ID-3 SR_ID-2 SR_ID-1 3
(LSB) 5

(MSB) Service Option n 2n+2
(LSB) 2n+3
1
TIA-2001.6-C
Section 3 28
3.3 A9-Disconnect-A8 1
This message is sent from the PCF to the BS to request the release of an A8 connection. 2
Reference
a
C
b
C
CON_REF 4.2.14 PCF -> BS O R
A8 Traffic ID 4.2.16 PCF -> BS O R
Cause 4.2.3 PCF -> BS O R
A9 PDSN Code 4.2.23 PCF -> BS
O
c

C
d
R
corresponding element in the A9-Release-A8 message sent in response to this 4
message. 5
c. This information element may be present if a release code is received from the 8
PDSN. If this element is present, the Cause element shall be coded to PCF (or 9
PDSN) resources unavailable. 10
d. This element specifies the SR_ID of the service instance to be disconnected. 11
The following table shows the bitmap layout for the A9-Disconnect-A8 message. 12
3.3 A9-Disconnect-A8
7 6 5 4 3 2 1 0 Octet
Length = [08H] 2
(LSB) 4
(LSB) 6
8
9
(LSB) 10
TIA-2001.6-C
29 Section 3
7 6 5 4 3 2 1 0 Octet
Length = [04H] 2
4
5
(LSB) 6
Indicator
= [1,0]
Type of Identity
= [110] (IMSI)
3

Length = [05H] 2
Indicator
= [0]
Type of Identity
= [101] (ESN)
3
5
6
(LSB) 7
Length = [01H] 2
Length = [0CH] 2
(LSB) 5
7
8
(LSB) 9
TIA-2001.6-C
Section 3 30
7 6 5 4 3 2 1 0 Octet
12
13
(LSB) 14
Length = [01H] 2
[14H (Normal call release),
07H (OAM&P intervention)
79H (PCF (or PDSN) resources unavailable)]
3
! !! ! A9 PDSN Code: A9 Element Identifier = [0CH] 1
Length = [01H] 2
PDSN Code =
[C1H (Connection Release - reason unspecified),
C2H (Connection Release - PPP time-out ),
C3H (Connection Release - registration time-out),
C4H (Connection Release - PDSN error),
C5H (Connection Release - inter-PCF handoff),
C6H (Connection Release - inter-PDSN handoff),
C7H (Connection Release - PDSN OAM&P intervention),
C8H (Connection Release - accounting error )
CAH (Connection Release user (NAI) authentication failure)]

3
Length = [01H] 2
Reserved = [0000 0] IS-2000 SR_ID = [001 - 011] 3
1
TIA-2001.6-C
31 Section 3
3.4 A9-Release-A8 1
This message is sent from the BS to the PCF to release an A8 connection. 2
Reference
A9 Message Type 4.2.13 BS-> PCF M
Call Connection Reference 4.2.10 BS-> PCF O R
Correlation ID 4.2.11 BS-> PCF O
a
C
Mobile Identity (IMSI) 4.2.2 BS-> PCF O R
Mobile Identity (ESN) 4.2.2 BS-> PCF O
b
C
CON_REF 4.2.14 BS-> PCF O R
A8 Traffic ID 4.2.16 BS-> PCF O R
Cause 4.2.3 BS-> PCF O
c
R
Active Connection Time in Seconds 4.2.1 BS-> PCF O
d
R
e
R
a. This element shall be included if it was also included in the A9-Disconnect-A8 3
message. This element shall be set to the value received in that message. If this 4
element was not included in that message, it may be included in this message. 5
c. The cause value Normal Call Release indicates that the packet data service instance 8
has been released and therefore the A10 resources associated with this service 9
instance should be dropped. If the cause value indicates Packet Data Session 10
Release, all services have been released by the MS and therefore all A10 connections 11
associated with the MS shall be released. 12
d. This element shall be included to indicate the active connection time for a traffic 13
channel. 14
e. This element specifies the SR_ID of the service instance to be released. 15
The following table shows the bitmap layout for the A9-Release-A8 message. 16
3.4 A9-Release-A8
7 6 5 4 3 2 1 0 Octet
Length = [08H] 2
(LSB) 4
(LSB) 6
8
9
TIA-2001.6-C
Section 3 32
3.4 A9-Release-A8
7 6 5 4 3 2 1 0 Octet
(LSB) 10
Length = [04H] 2
4
5
(LSB) 6
Indicator
= [1,0]
Type of Identity
= [110] (IMSI)
3

Length = [05H] 2
Indicator
= [0]
Type of Identity
= [101] (ESN)
3
5
6
(LSB) 7
Length = [01H] 2
Length = [0CH] 2
(LSB) 5
7
8
TIA-2001.6-C
33 Section 3
3.4 A9-Release-A8
7 6 5 4 3 2 1 0 Octet
(LSB) 9
12
13
(LSB) 14
Length = [01H] 2
[0FH (Packet data session release)
14H (Normal call release),
0BH (Handoff successful),
1AH (Authentication failure)]
3
! !! ! Active Connection Time in Seconds: A9 Element Identifier = [0AH] 1
Length = [04H] 2
(MSB) Active Connection Time = [00 00 00 00H FF FF FF FFH] 3
4

5
(LSB) 6
Length = [01H] 2
Reserved = [0000 0] IS-2000 SR_ID = [001 - 011] 3
1
TIA-2001.6-C
Section 3 34
3.5 A9-Release-A8 Complete 1
This message is sent from the PCF to the BS either to acknowledge the release of an A8 2
connection or to indicate that an A8 does not need to be or cannot be set up. 3
Reference
a
C
Cause 4.2.3 PCF -> BS O
b
C
A9 PDSN Code 4.2.23 PCF -> BS O
c
C
d
R
a. This element shall only be included if it was also included in the A9-Release-A8 4
b. This information element is present in the case where an A8 connection is not 6
established during a setup request. The element contains a release cause. 7
c. This information element may be present if a code is received from the PDSN. If this 8
element is present the Cause element shall be coded to PCF (or PDSN) resources 9
unavailable or Packet call going dormant. 10
d. This element indicates the SR_ID of the service instance that was released. 11
The following table shows the bitmap layout for the A9-Release-A8 Complete message. 12
3.5 A9-Release-A8 Complete
7 6 5 4 3 2 1 0 Octet
Length = [08H] 2
(LSB) 4
(LSB) 6
8
9
(LSB) 10
Length = [04H] 2
4
5
TIA-2001.6-C
35 Section 3
3.5 A9-Release-A8 Complete
7 6 5 4 3 2 1 0 Octet
(LSB) 6
Length = [01H] 2
[79H (PDSN resource unavailable),
32H (PCF resource unavailable),
07H (OAM&P intervention)]
3
! !! ! A9 PDSN Code: A9 Element Identifier = [0CH] 1
Length = [01H] 2
PDSN Code =
[00H (Registration Accepted),
80H (Registration Denied reason unspecified)
81H (Registration Denied - administratively prohibited)
82H (Registration Denied insufficient resources)
83H (Registration Denied mobile node failed authentication)
85H (Registration Denied identification mismatch)
86H (Registration Denied poorly formed request)
88H (Registration Denied unknown PDSN address)
89H (Registration Denied requested reverse tunnel unavailable)
8AH (Registration Denied reverse tunnel is mandatory and T bit not set)
8DH (Registration Denied unsupported vendor ID or unable to interpret data in the CVSE)]
3
Length = [01H] 2
Reserved = [0000 0] IS-2000 SR_ID = [001 - 011] 3
1
TIA-2001.6-C
Section 3 36
3.6 A9-BS Service Request 1
This message is sent from the PCF to the BS to request re-activation of a dormant packet 2
Reference
a
C
b
C
Service Option 4.2.8 PCF -> BS O R
Data Count 4.2.18 PCF -> BS O
c
C
d
R
corresponding element in the A9-BS Service Response message sent in response to 5
this message. 6
c. This IE may be included by the PCF to indicate to the BS the amount of data 9
remaining at the PCF that is to be transmitted. 10
d. This element specifies the SR_ID of the service instance in the Service Option 11
element. 12
The following table shows the bitmap layout for the A9-BS Service Request message. 13
3.6 A9-BS Service Request
7 6 5 4 3 2 1 0 Octet
Length = [04H] 2
4
5
(LSB) 6
Indicator
= [1,0]
Type of Identity
= [110] (IMSI)
3

TIA-2001.6-C
37 Section 3
3.6 A9-BS Service Request
7 6 5 4 3 2 1 0 Octet
Length = [05H] 2
Indicator
= [0]
Type of Identity
= [101] (ESN)
3
5
6
(LSB) 7
= [00 21H (3G High Speed Packet Data)] (LSB) 3
! !! ! Data Count: A9 Element Identifier = [09H] 1
Length = [02H] 2
Count = <any value> 3

4
Length = [01H] 2
Reserved = [0000 0] IS-2000 SR_ID = [001 - 011] 3
1
2
TIA-2001.6-C
Section 3 38
3.7 A9-BS Service Response 1
This message is sent from the BS to the PCF to acknowledge the receipt and processing 2
of the A9-BS Service Request message. 3
Reference
a
C
Cause 4.2.3 BS -> PCF O
b
C
c
R
a. This element shall only be included if it was also included in the A9-BS Service 4
Request message. This element shall be set to the value received in that message. 5
b. This element shall only be included if the BS does not grant the A9-BS Service 6
Request. 7
c. This element indicates the SR_ID of the service instance that was set up. 8
The following table shows the bitmap layout for the A9-BS Service Response message. 9
3.7 A9-BS Service Response
7 6 5 4 3 2 1 0 Octet
Length = [04H] 2
4
5
(LSB) 6
Length = [01H] 2
[08H (MS busy),
11H (Service option not available)]
3
Length = [01H] 2
Reserved = [0000 0] IS-2000 SR_ID = [001 - 011] 3
10
TIA-2001.6-C
39 Section 3
3.8 A9-AL (Air Link) Connected 1
This message is sent from the BS to the PCF to indicate that a traffic channel has been 2
established to the MS during hard or fast handoff. 3
Reference
a
C
PDSN Address 4.2.5 BS -> PCF O
b,c
C
IS-2000 Service Configuration Record 4.2.20 BS -> PCF O R
Service Option 4.2.8 BS -> PCF O R
User Zone ID 4.2.6 BS -> PCF O R
Quality of Service Parameters 4.2.7 BS -> PCF O R
Access Network Identifiers 4.2.19 BS -> PCF O
c,d
C
corresponding element in the A9-AL Connected Ack message sent in response to 5
this message. 6
b. This is the IP address for the A11 interface of the source PDSN. 7
c. This element shall be omitted if this message is sent as part of a fast handoff because 8
the corresponding A10 connection has already been established. Otherwise, this 9
element shall be included. 10
d. The Access Network Identifiers are those of the source PCF communicated by the 11
source BS via the MSC (Handoff Required, Handoff Requested messages). 12
The following table shows the bitmap layout for the A9-AL Connected message. 13
3.8 A9-AL (Air Link) Connected
7 6 5 4 3 2 1 0 Octet
Length = [08H] 2
(LSB) 4
(LSB) 6
8
9
(LSB) 10
TIA-2001.6-C
Section 3 40
7 6 5 4 3 2 1 0 Octet
Length = [04H] 2
4
5
(LSB) 6
Length = [0CH] 2
(LSB) 5
7
8
(LSB) 9
12
13
(LSB) 14
Length = [04H] 2
4
5
(LSB) 6
= [00H to FFH]
2
Reserved
= [0000 0]
= [000 to 111]
3
(MSB) 4
= <any value>

TIA-2001.6-C
41 Section 3
7 6 5 4 3 2 1 0 Octet
Seventh
Fill Bit
if needed
= [0 (if
used as a
fill bit)]
Sixth Fill
Bit if
needed
= [0 (if
used as a
fill bit)]
Fifth Fill
Bit if
needed
= [0 (if
used as a
fill bit)]
Fourth
Fill Bit
if needed
= [0 (if
used as a
fill bit)]
Third
Fill Bit
if needed
= [0 (if
used as a
fill bit)]
Second
Fill Bit
if needed
= [0 (if
used as a
fill bit)]
First Fill
Bit if
needed
= [0 (if
used as a
fill bit)]
k
= [00 21H (3G High Speed Packet Data),
00 3CH (Link Layer Assisted Header Removal),
(LSB) 3
Length = [02H] 2
(LSB) 4
Length = [01H] 2
[0000 1101]
3
! !! !Access Network Identifiers: A9 Element Identifier = [20H] 1
Length = [05H] 2
Reserved
= [0]
(LSB) 4
(LSB) 6
1
TIA-2001.6-C
Section 3 42
3.9 A9-AL (Air Link) Connected Ack 1
This message is sent from the PCF to the BS to acknowledge reception of an A9-AL 2
Connected message. In the case of inter-PCF hard handoff without fast handoff, this 3
message is sent after establishment of the A10 connection. 4
Reference
a
C
PDSN Address 4.2.5 PCF -> BS O
b
C
Anchor PDSN Address 4.2.22 PCF -> BS O
c
C
Anchor P-P Address 4.2.12 PCF -> BS O
d
C
a. This element shall only be included if it was also included in the A9-AL Connected 5
b. This is the IP address of the A11 interface of the target PDSN. It shall be included in 7
this message unless the information was sent previously in an A9-Connect-A8 8
message. It is saved by the BS, and included in the Handoff Required message in the 9
event of a hard handoff. 10
c. This is the IP address for the A11 interface of the anchor PDSN. This element shall 11
be included if the Anchor P-P Address is included. If included, it shall be set to the 12
same value as the PDSN-Address. It is saved by the BS and included in the Handoff 13
Required message in the event of a fast handoff. 14
d. This is the IP address for establishing P-P connections to the anchor PDSN. This 15
element shall be included if fast handoff is supported and if the value was received 16
from the PDSN, unless the information was sent previously in an A9-Connect-A8 17
message. It is saved by the BS and included in the Handoff Required message in the 18
event of a fast handoff. 19
20
21
TIA-2001.6-C
43 Section 3
The following table shows the bitmap layout for the A9-AL Connected Ack message. 1
3.9 A9-AL (Air Link) Connected Ack
7 6 5 4 3 2 1 0 Octet
Length = [08H] 2
(LSB) 4
(LSB) 6
8
9
(LSB) 10
Length = [04H] 2
4
5
(LSB) 6
Length = [04H] 2
4
5
(LSB) 6
Length = [04H] 2
4
5
(LSB) 6
Length = [04H] 2
(MSB) Serving P-P IP Address = <any value> 3
4
5
TIA-2001.6-C
Section 3 44
3.9 A9-AL (Air Link) Connected Ack
7 6 5 4 3 2 1 0 Octet
(LSB) 6
1
TIA-2001.6-C
45 Section 3
3.10 A9-AL Disconnected 1
This message is sent from the BS to the PCF to indicate that the traffic channel has been 2
released following a hard handoff. 3
Reference
a
C
corresponding element in the A9-AL Disconnected Ack message sent in response to 5
this message. 6
The following table shows the bitmap layout for the A9-AL Disconnected message. 7
3.10 A9-AL Disconnected
7 6 5 4 3 2 1 0 Octet
! !! ! A9 Message Type = [0AH] 1
Length = [08H] 2
(LSB) 4
(LSB) 6
8
9
(LSB) 10
Length = [04H] 2
4
5
(LSB) 6
Length = [0CH] 2
(LSB) 5
TIA-2001.6-C
Section 3 46
3.10 A9-AL Disconnected
7 6 5 4 3 2 1 0 Octet
7
8
(LSB) 9
12
13
(LSB) 14
1
TIA-2001.6-C
47 Section 3
3.11 A9-AL Disconnected Ack 1
This message is sent from the PCF to the BS to acknowledge reception of the A9-AL 2
Disconnect message. 3
Reference
a
C
a. This element shall only be included if it was also included in the A9-AL 4
Disconnected message. This element shall be set to the value received in that 5
message. 6
The following table shows the bitmap layout for the A9-AL Disconnected Ack message. 7
3.11 A9-AL Disconnected Ack
7 6 5 4 3 2 1 0 Octet
! !! ! A9 Message Type = [0BH] 1
Length = [08H] 2
(LSB) 4
(LSB) 6
8
9
(LSB) 10
Length = [04H] 2
4
5
(LSB) 6
8
9
TIA-2001.6-C
Section 3 48
3.12 A9-Short Data Delivery 1
This message is sent from the BS to the PCF when a short data burst is received from an 2
MS. It may be sent from the PCF to the BS when a small amount of data is received for a 3
dormant packet data service instance. 4
Reference
A9 Message Type 4.2.13 PCF <-> BS M
a
C
Mobile Identity (IMSI) 4.2.2 PCF <-> BS O R
Mobile Identity (ESN) 4.2.2 PCF <-> BS O
b
C
SR_ID 4.2.4 PCF <-> BS O R
Data Count 4.2.18 PCF -> BS O
c
C
ADDS User Part 4.2.9 PCF <-> BS O
d
R
A9 Indicators 4.2.17 PCF -> BS O
e
C
a. If this element is included, its value shall be returned in the corresponding element in 5
the A9-Short Data Ack message from the BS. 6
c. This element is included in this message when sent from the PCF to the BS and 9
indicates the number of additional bytes of data queued at the PCF and waiting to be 10
sent to a specific MS. 11
d. Contains the packet data received from the PDSN or an MS in a SDB format as 12
e. This information element is included when the packet data service instance is 14
operating in CCPD Mode. 15
The following table shows the bitmap layout for the A9-Short Data Delivery message. 16
3.12 A9-Short Data Delivery
7 6 5 4 3 2 1 0 Octet
! !! ! A9 Message Type = [0CH] 1
Length = [04H] 2
4
5
(LSB) 6
Indicator
= [1,0]
Type of Identity
= [110] (IMSI)
3
TIA-2001.6-C
49 Section 3
3.12 A9-Short Data Delivery
7 6 5 4 3 2 1 0 Octet

Length = [05H] 2
Indicator
= [0]
Type of Identity
= [101] (ESN)
3
5
6
(LSB) 7
Length = [01H] 2
Reserved = [0000 0] IS-2000 SR_ID = [001 - 011] 3
! !! ! Data Count: A9 Element Identifier = [09H] 1
Length = [02H] 2
Count = <any value> 3

4
[06H (Short Data Burst)]
3

(LSB) n
! !! ! A9 Indicators: A9 Element Identifier = [05H] 1
Length = [01H] 2
Reserved = [0000] CCPD
Mode
= [0,1]
Reserved
= [0]
Data
Ready
Indicator
= [0,1]
(ignored)
Handoff
Indicator
= [0, 1]
(ignored)
3
TIA-2001.6-C
Section 3 50
3.13 A9-Short Data Ack 1
This message is sent from the BS to the PCF to acknowledge reception of the A9-Short 2
Data Delivery message and to indicate to the PCF whether the data was accepted for 3
delivery to the MS. 4
Reference
A9 Message Type 4.2.13 BS->PCF M
Correlation ID 4.2.11 BS->PCF O
a
C
Mobile Identity (IMSI) 4.2.2 BS->PCF O R
Mobile Identity (ESN) 4.2.2 BS->PCF O
b
C
Cause 4.2.3 BS->PCF O
c
R
a. If this element is included, its value shall be set to the value of the corresponding 5
element received in the A9-Short Data Delivery message from the PCF. 6
c. The cause value indicates to the PCF whether a short data burst is to be sent to the 9
MS. 10
The following table shows the bitmap layout for the A9-Short Data Ack message. 11
3.13 A9-Short Data Ack
7 6 5 4 3 2 1 0 Octet
! !! ! A9 Message Type = [0DH] 1
Length = [04H] 2
4
5
(LSB) 6
Indicator
= [1,0]
Type of Identity
= [110] (IMSI)
2

Length = [05H] 2
TIA-2001.6-C
51 Section 3
3.13 A9-Short Data Ack
7 6 5 4 3 2 1 0 Octet
Indicator
= [0]
Type of Identity
= [101] (ESN)
3
5
6
(LSB) 7
Length = [01H] 2
ext =
[0]
Cause Value =
16H (Initiate re-activation of packet data call)]
3
1
2
TIA-2001.6-C
Section 3 52
3.14 A9-Update-A8 1
This message is sent from the BS to the PCF to indicate a change to the session airlink 2
parameters. This message is also sent from the PCF to the BS to transfer new or updated 3
packet data session parameters to the BS. 4
Reference
A9 Message Type 4.2.13 BS <-> PCF M
Call Connection Reference 4.2.10 BS <-> PCF O R
Correlation ID 4.2.11 BS <-> PCF O
a
C
Mobile Identity (IMSI) 4.2.2 BS <-> PCF O R
Mobile Identity (ESN) 4.2.2 BS -> PCF O
b
C
IS-2000 Service Configuration Record 4.2.20 BS -> PCF O
c
C
Service Option 4.2.8 BS -> PCF O
c
C
User Zone ID 4.2.6 BS -> PCF O
c
C
Quality of Service Parameters 4.2.7 BS -> PCF O
c
C
Cause 4.2.3 BS <-> PCF O R
RN-PDIT 4.2.24 BS <- PCF O
d
C
SR_ID 4.2.4 BS< -> PCF O
e
R
corresponding element in the A9-Update-A8-Ack message sent in response to this 6
message. 7
c. These elements are required when the message is sent from the BS to the PCF unless 10
the message is used to indicate Dormant Power down or Authentication Failure. 11
d. This element is included in the message when the PDSN has sent the parameter to 12
the PCF. 13
e. This element specifies the SR_ID of the service instance in the Service Option 14
element. 15
The following table shows the bitmap layout for the A9-Update-A8 message. 16
3.14 A9-Update-A8
7 6 5 4 3 2 1 0 Octet
! !! ! A9 Message Type = [0EH] 1
Length = [08H] 2
(LSB) 4
(LSB) 6
TIA-2001.6-C
53 Section 3
3.14 A9-Update-A8
7 6 5 4 3 2 1 0 Octet
8
9
(LSB) 10
Length = [04H] 2
4
5
(LSB) 6
Indicator
= [1,0]
Type of Identity
= [110] (IMSI)
2

Length = [05H] 2
Indicator
= [0]
Type of Identity
= [101] (ESN)
3
5
6
(LSB) 7
Reserved
= [0000 0]
= [000 111]
3
(MSB) IS-2000 Service Configuration Record Content = <any value> 4

TIA-2001.6-C
Section 3 54
3.14 A9-Update-A8
7 6 5 4 3 2 1 0 Octet
Seventh
Fill Bit
if needed
= [0 (if
used as a
fill bit)]
Sixth Fill
Bit if
needed
= [0 (if
used as a
fill bit)]
Fifth Fill
Bit if
needed
= [0 (if
used as a
fill bit)]
Fourth
Fill Bit
if needed
= [0 (if
used as a
fill bit)]
Third
Fill Bit
if needed
= [0 (if
used as a
fill bit)]
Second
Fill Bit
if needed
= [0 (if
used as a
fill bit)]
First Fill
Bit if
needed
= [0 (if
used as a
fill bit)]
k
= [00 21H (3G High Speed Packet Data )
00 3CH (Link Layer Assisted Header Removal)
(LSB) 3
Length = [02H] 2
(LSB) 4
Length = [01H] 2
1101]
3
Length = [01H] 2
Ext=
[0]
Cause Value =
[19H (Power down from dormant state),
1CH (Update accounting: late traffic channel setup),
1EH (Update accounting: parameter change),
1AH (Authentication failure),
7BH (Session parameter update)]
3
! !! ! RN-PDIT: A9 Element Identifier = [0FH] 1
Length = [01H] 2
RN-PDIT = [01H-FFH] 3
Length = [01H] 2
Reserved = [0000 0] IS-2000 SR_ID = [001 - 011] 3
1
TIA-2001.6-C
55 Section 3
3.15 A9-Update-A8 Ack 1
This message is sent from the PCF to the BS to acknowledge a change to the session 2
airlink parameters. This message is also sent from the BS to the PCF to acknowledge the 3
processing of any new or updated session parameters. 4
Reference
A9 Message Type 4.2.13 BS<->PCF M
Call Connection Reference 4.2.10 BS<->PCF O R
Correlation ID 4.2.11 BS<->PCF O
a
C
Cause 4.2.3 BS -> PCF O
b
C
a. This element shall only be included if it was also included in the A9-Update-A8 5
b. The Cause element shall be included when the message is sent by the BS to the PCF 7
to indicate if the updated session parameter(s) was accepted by the BS. 8
The following table shows the bitmap layout for the A9-Update-A8 Ack message. 9
3.15 A9-Update-A8 Ack
7 6 5 4 3 2 1 0 Octet
! !! ! A9 Message Type = [0FH] 1
Length = [08H] 2
(LSB) 4
(LSB) 6
8
9
(LSB) 10
Length = [04H] 2
4
5
(LSB) 6
Length = [01H] 2
Ext=
[0]
Cause Value =
36H (Session parameter/option not supported at BS)]
3
10
TIA-2001.6-C
Section 3 56
3.16 A9-Version Info 1
This message is sent from the PCF to the BS, or the BS to the PCF, when the sending 2
entity requires software version information from the receiving entity. 3
Reference
a
C
Cause 4.2.3 BS<->PCF O
b
C
Software Version 4.2.21 BS<->PCF O R
corresponding element in the A9-Version Info Ack message sent in response to this 5
message. 6
b. This element shall be included if the message is being sent as the result of a reset at 7
the sending entity. 8
The following table shows the bitmap layout for the A9-Version Info message: 9
3.16 A9-Version Info
7 6 5 4 3 2 1 0 Octet
Length = [04H] 2
4
5
(LSB) 6
Length = [01H] 2
3

10
TIA-2001.6-C
57 Section 3
3.17 A9-Version Info Ack 1
This message is sent from the PCF to the BS, or BS to PCF, in response to the A9- 2
Version Info message. The message includes the software version information from the 3
receiving entity. 4
Reference
a
C
Software Version 4.2.21 BS<->PCF O R
a. This element is included in this message if it was sent in the A9-Version Info 5
message. Its value shall be set to the same value as in the A9-Version Info message. 6
The following table shows the bitmap layout for the A9-Version Info Ack message: 7
3.17 A9-Version Info Ack
7 6 5 4 3 2 1 0 Octet
Length = [04H] 2
4
5
(LSB) 6

8
9
TIA-2001.6-C
Section 3 58
1
3
4
5
6
7
TIA-2001.6-C
59 Section 4
9
bytes: 12
2, etc. 16
section 3.0. 20
The Information Element Identifier is included for all cases of signaling messages on the 21
A9 interface. 22
All reserved bits are set to 0, unless otherwise indicated. 23
For future expansion purposes, some information elements have fields that have been 24
reserved. 25
26
TIA-2001.6-C
Section 4 60
includes a reference to the section where the element coding can be found. 5
A listing of information elements, sorted by name, is included in Table 4.1.4-1, which 6
also specifies the messages in which each information element is used. 7
Table 4.1.2-1 A9 Information Element Identifiers Sorted by Identifier Value 8
Element Name Identifier Reference
CON_REF 01H 4.2.14
User Zone ID 02H 4.2.6
Service Option 03H 4.2.8
Cause 04H 4.2.3
A9 Indicators 05H 4.2.17
A9 Cell Identifier 06H 4.2.15
Quality of Service Parameters 07H 4.2.7
A8 Traffic ID 08H 4.2.16
Data Count 09H 4.2.18
Active Connection Time in Seconds 0AH 4.2.1
SR_ID 0BH 4.2.4
A9 PDSN Code 0CH 4.2.23
Mobile Identity 0DH 4.2.2
IS-2000 Service Configuration Record 0EH 4.2.20
RN-PDIT 0FH 4.2.24
Correlation ID 13H 4.2.11
PDSN Address 14H 4.2.5
Access Network Identifiers 20H 4.2.19
Anchor PDSN Address 30H 4.2.22
Software Version 31H 4.2.21
ADDS User Part 3DH 4.2.9
Call Connection Reference 3FH 4.2.10
Anchor P-P Address 40H 4.2.12
Service Instance Info 41H 4.2.25
9
10
TIA-2001.6-C
61 Section 4
Elements 2
occurrences on a specific IOS interface. Insofar as possible, the same Information 4
than one of the IOS interface. 6
Where the description of the information element in this standard contains reserved bits, 9
implementation, messages shall not be rejected simply because a reserved bit is set to 1. 11
a message may contain an information element, the content of which is zero length. This 13
shall be interpreted by the receiver as equivalent to that information element being 14
absent. 15
Some existing elements make use of an extension bit mechanism that allows the size of 16
the information element to be increased. This mechanism consists of the use of the high 17
order bit (bit 7) of an octet as an extension bit. When an octet within an information 18
element has bit 7 defined as an extension bit, then the value 0 in that bit position 19
indicates that the following octet is an extension of the current octet. When the value is 20
1, there is no extension. 21
22
TIA-2001.6-C
Section 4 62
4
Information Element Reference IEI Used in These Messages
A8 Traffic ID 4.2.16 08H A9-Setup-A8 3.1
A9-AL Connected 3.8
A9-AL Disconnected 3.10
A9-Connect-A8 3.2
A9-Disconnect-A8 3.3
A9-Release-A8 3.4
A9 Cell Identifier 4.2.15 06H A9-Setup-A8 3.1
A9 Indicators 4.2.17 05H A9-Setup-A8 3.1
A9-Short Data Delivery 3.12
A9 Message Type 4.2.13 None A9-Setup-A8 3.1
A9-AL Connected 3.8
A9-AL Connected Ack 3.9
A9-AL Disconnected Ack 3.11
A9-BS Service Request 3.6
A9-BS Service Response 3.7
A9-Connect-A8 3.2
A9-Release-A8 3.4
A9-Release-A8 Complete 3.5
A9-Short Data Delivery Ack 3.13
A9-Update-A8 3.14
A9-Update-A8 Ack 3.15
A9-Version Info 3.16
A9-Version Info Ack 3.17
A9 PDSN Code 4.2.23 0CH A9-Disconnect-A8 3.3
Access Network Identifier 4.2.19 20H A9-Setup-A8 3.1
A9-AL Connected 3.8
Active Connection Time in Seconds 4.2.1 0AH A9-Release-A8 3.4
ADDS User Part 4.2.9 3DH A9-Short Data Delivery 3.12
TIA-2001.6-C
63 Section 4
Anchor P-P Address 4.2.12 40H A9-Setup-A8 3.1
A9-Connect-A8 3.2
Anchor PDSN Address 4.2.22 30H A9-Setup-A8 3.1
A9-Connect-A8 3.2
Call Connection Reference 4.2.10 3FH A9-AL Connected 3.8
A9-AL Disconnected Ack 3.11
A9-Connect-A8 3.2
A9-Setup-A8 3.1
A9-Release-A8 3.4
A9-Update-A8 3.14
Cause 4.2.3 04H A9-Connect-A8 3.2
A9-Release-A8 3.4
A9-Short Data Ack 3.13
A9-Update-A8 3.14
A9-Version Info 3.16
CON_REF 4.2.14 01H A9-Setup-A8 3.1
A9-Connect-A8 3.2
A9-Release-A8 3.4
Correlation ID 4.2.11 13H A9-AL Disconnected Ack 3.11
A9-Setup-A8 3.1
A9-Connect-A8 3.2
A9-Release-A8 3.4
TIA-2001.6-C
Section 4 64
Data Count 4.2.18 09H A9-BS Service Request 3.6
IS-2000 Service Configuration
Record
4.2.20 0EH A9-Setup-A8 3.1
A9-AL Connected 3.8
A9-Update-A8 3.14
Mobile Identity 4.2.2 0DH A9-Setup A8 3.1
A9-Connect A8 3.2
A9-Release-A8 3.4
A9-Update-A8 3.14
PDSN Address 4.2.5 14H A9-Setup-A8 3.1
A9-Connect-A8 3.2
A9-AL Connected 3.8
Quality of Service Parameters 4.2.7 07H A9-Setup-A8 3.1
A9-AL Connected 3.8
A9-Update-A8 3.14
RN-PDIT 4.2.24 0FH A9-Update-A8 3.14
Service Instance Info 4.2.25 41H A9-Connect-A8 3.2
Service Option 4.2.8 03H A9-BS Service Request 3.6
A9-Setup-A8 3.1
A9-AL Connected 3.8
A9-Update-A8 3.14
Software Version 4.2.21 31H A9-Version Info 3.16
A9-Version Info Ack 3.17
SR_ID 4.2.4 0BH A9-Setup-A8 3.1
A9-Connect-A8 3.2
A9-Release-A8 3.4
TIA-2001.6-C
65 Section 4

A9-Update-A8 3.14
User Zone ID 4.2.6 02H A9-Setup-A8 3.1
A9-AL Connected 3.8
A9-Update-A8 3.14
1
TIA-2001.6-C
Section 4 66
2
4.2.1 Active Connection Time in Seconds 3
This element indicates the duration of traffic channel connection. It is coded as follows. 4
4.2.1 Active Connection Time in Seconds
7 6 5 4 3 2 1 0 Octet
Length 2
(MSB) Active Connection Time 3

4

5

(LSB) 6
Length: 5
Length field. This field shall be set to 04H. 7
Active Connection Time: 8
This field indicates the duration of time the traffic channel was 9
established in seconds. 10
11
TIA-2001.6-C
67 Section 4
Serial Number (ESN), the International Mobile Subscriber Identity (IMSI), or the 3
Broadcast Address. 4
Reserved field. 7
This element is coded as specified in [1]~[6]. 8
7 6 5 4 3 2 1 0 Octet
Length 2
Indicator
Type of Identity 3

The Type of Identity is defined as follows: 10
000 Reserved
010 Reserved
101 ESN
110 IMSI
The Odd/Even Indicator (octet 3; bit 3) field is set to 0 for an even number of digits and 12
to 1 for an odd number of identity digits. 13
The identity digits (octet 3 etc.) are coded as follows: 14
The International Mobile Subscriber Identifier fields are coded using BCD coding format. 15
If the number of identity digits is even then bits 4 to 7 of the last octet shall be filled with 16
an end mark coded as 1111. 17
The ESN is not separated into digits, and occupies octets 4-7 with the most significant bit 18
in octet 4 bit 7. Identity Digit 1 in octet 3 is unused and coded as 0000. 19
20
21
TIA-2001.6-C
Section 4 68
4.2.3 Cause 1
4.2.3 Cause
7 6 5 4 3 2 1 0 Octet
Length 2
0/1 Cause Value 3
Length: 4
Length field. 6
Cause Value: 7
This field is a single octet field if the extension bit (bit 7) is set to 0. If 8
bit 7 of octet 3 is set to 1 then the cause value is a two octet field. If 9
the value of the first octet of the cause field is 1XXX 0000 then the 10
second octet is reserved for national applications, where XXX 11
indicates the Cause Class as indicated in the table below. 12
Table 4.2.3-1 Cause Class 13
000 Normal event
001 Normal event
010 Resource unavailable
110 Protocol error
111 Interworking
14
15
TIA-2001.6-C
69 Section 4
Table 4.2.3-2 Cause Values 1
6 5 4 3 2 1 0 Hex
Value
Cause
0 0 0 1 0 0 0 08 MS busy
0 0 0 1 0 1 1 0B Handoff successful
0 0 0 1 1 1 1 0F Packet data session release
0 0 1 0 0 0 0 10 Packet call going dormant
0 0 1 0 0 1 1 13 Successful operation
0 0 1 0 1 0 0 14 Normal call release
0 0 1 0 1 1 0 16 Initiate re-activation of packet data call
0 0 1 1 0 0 1 19 Power down from dormant state
0 0 1 1 0 1 0 1A Authentication failure
0 0 1 1 1 0 0 1C Update Accounting: late traffic channel setup
0 0 1 1 1 1 0 1E Update Accounting: parameter change
0 1 1 0 0 1 0 32 PCF (or PDSN) resources not available
0 1 1 0 1 1 0 36 Session parameter/option not supported at BS
Protocol Error (110 xxxx)
Interworking (111 xxxx)
1 1 1 1 0 0 1 79 PCF (or PDSN) resources are not available
1 1 1 1 0 1 0 7A Data ready to send
1 1 1 1 0 1 1 7B Session parameter update
All other values

2
3
TIA-2001.6-C
Section 4 70
4.2.4 SR_ID 1
This information element identifies the service reference identifier for a particular service 2
instance. 3
4.2.4 SR_ID
7 6 5 4 3 2 1 0 Octet
Length 2
Reserved IS-2000 SR_ID 3
Length: 4
Length field. 6
IS-2000 SR_ID: 7
This field is used to uniquely identify a packet data service instance in 8
the MS. This field contains the Session Reference Identifier value 9
(sr_id) as defined in [3]. 10
11
TIA-2001.6-C
71 Section 4
4.2.5 PDSN Address 1
When sent from a PCF to a BS, this element contains an A11 interface IPv4 IP Address 2
for the PDSN that terminates the A10 connection corresponding to the just-established 3
A8 connection. 4
When sent from a target BS to a target PCF, this element contains an A11 interface IPv4 5
IP Address for the source PDSN during a hard or fast handoff. 6
4.2.5 PDSN Address
7 6 5 4 3 2 1 0 Octet
Length 2
(MSB) PDSN Address 3
4
5
(LSB) 6
Length: 7
Length field. 9
PDSN Address: 10
This field contains an A11 interface IPv4 address for the PDSN. 11
12
TIA-2001.6-C
Section 4 72
4.2.6 User Zone ID 1
This element uniquely identifies a particular User Zone. 2
4.2.6 User Zone ID
7 6 5 4 3 2 1 0 Octet
Length 2
(MSB) UZID 3
(LSB) 4
Length: 3
Length field. 5
UZID: 6
This field contains a User Zone ID value as sent by the MSC or MS. 7
The MSC is responsible for any mapping of this 16-bit value to the 24- 8
bit value defined in [9]. 9
10
TIA-2001.6-C
73 Section 4
This element identifies the Quality of Service for a given packet data service instance. In 2
this version of this standard the only information carried is non-assured mode packet 3
priority. 4
7 6 5 4 3 2 1 0 Octet
Length 2
information element is included in a message that is sent on the A1 or 7
A9 interface, the Element Identifier field is coded as 07H. When the 8
the Element Identifier field is coded as 0FH. 10
Length: 11
Length field. 13
Reserved: 14
20
TIA-2001.6-C
Section 4 74
4.2.8 Service Option 1
This element indicates the service option requested by the MS, or by the network. It is 2
coded as follows: 3
4.2.8 Service Option
7 6 5 4 3 2 1 0 Octet
(LSB) 3
4
The service options supported are given in Table 4.2.8-1. 5
Service Option
Value (hex)

Description
0021H 3G High Speed Packet Data
003CH Link Layer Assisted Header Removal
003DH Link-Layer Assisted Robust Header Compression (LLA-ROHC)
7
TIA-2001.6-C
75 Section 4
4.2.9 ADDS User Part 1
This element contains the application data message. 2
4.2.9 ADDS User Part
7 6 5 4 3 2 1 0 Octet
Length 2
Reserved Data Burst Type 3
Application Data Message 4-n
The Length field is defined as the number of octets following the Length field and has a 3
value greater than zero. 4
The Data Burst Type field is coded as follows: 5
For CDMA: the 6-bit Data Burst Type defined in [22] is contained in bits 5 6
through 0, with bits 6 and 7 set to zero. 7
The Application Data Message field has variable length and is encoded as follows: 8
For Short Data Burst, the Application Data Message is the SDB as specified in [19]. 9
10
TIA-2001.6-C
Section 4 76
4.2.10 Call Connection Reference 1
This information element contains a globally unique identification for a call connection. 2
4.2.10 Call Connection Reference
7 6 5 4 3 2 1 0 Octet
Length 2
(MSB) Market ID 3
Market ID (continued) (LSB) 4
(MSB) Generating Entity ID 5
Generating Entity ID (continued) (LSB) 6
(MSB) Call Connection Reference Value 7
8
9
(LSB) 10
Length: 3
Length field. 5
Market ID: 6
This field represents a unique market ID that is specified by the service 7
provider (refer to [21]). 8
Generating Entity ID: 9
This two octet field represents a unique code assigned by the operator 10
to the entity that generates this Call Connection Reference value. 11
Call Connection Reference Value: 12
This four octet field may contain any value. It is assigned by the 13
generating entity whose responsibility it is to guarantee its uniqueness. 14
15
TIA-2001.6-C
77 Section 4
4.2.11 Correlation ID 1
This information element is used to correlate request and response messages. 2
4.2.11 Correlation ID
7 6 5 4 3 2 1 0 Octet
Length 2
(MSB) Correlation Value 3
3
5
(LSB) 6
Length: 3
Length field and is set to a value of 4. 5
Correlation Value: 6
This field contains a value that allows the network entity to correlate a 7
request-response pair of messages. The value is a manufacturer 8
concern. In this revision of this standard, this value shall be exactly 4 9
octets in length. 10
11
TIA-2001.6-C
Section 4 78
4.2.12 Anchor P-P Address 1
This element contains the P-P interface IPv4 address for the of the anchor PDSN for fast 2
handoff. 3
4.2.12 Anchor P-P Address
7 6 5 4 3 2 1 0 Octet
Length 2
(MSB) Anchor P-P Address 3
4
5
(LSB) 6
Length: 4
Length field. 6
Anchor P-P Address: 7
This field contains a P-P interface IPv4 address for an anchor PDSN. 8
Refer to [8]. 9
10
11
TIA-2001.6-C
79 Section 4
4.2.13 A9 Message Type 1
The A9 Message Type element is used to indicate the type of a message on the A9 2
interface. 3
A9 Message Name A9 Message
Type
Section
Reference
A9-Setup-A8 01H 3.1
A9-Connect-A8 02H 3.2
A9-Disconnect-A8 03H 3.3
A9-Release-A8 04H 3.4
A9-Release-A8 Complete 05H 3.5
A9-BS Service Request 06H 3.6
A9-BS Service Response 07H 3.7
A9-AL Connected 08H 3.8
A9-AL Connected Ack 09H 3.9
A9-AL Disconnected 0AH 3.10
A9-AL Disconnected Ack 0BH 3.11
A9-Short Data Delivery 0CH 3.12
A9-Short Data Ack 0DH 3.13
A9-Update-A8 0EH 3.14
A9-Update-A8-Ack 0FH 3.15
A9-Version Info 10H 3.16
A9-Version Info Ack 11H 3.17
4
5
TIA-2001.6-C
Section 4 80
4.2.14 CON_REF 1
This information element identifies the connection instance between the MS and the 2
source BS. 3
4.2.14 CON_REF
7 6 5 4 3 2 1 0 Octet
Length 2
IS-2000 CON_REF 3
Length: 4
Length field. 6
IS-2000 CON_REF: 7
This field contains the connection reference value defined in [5]. 8
9
TIA-2001.6-C
81 Section 4
4.2.15 A9 Cell Identifier 1
This element uniquely identifies a particular cell: 2
3
4.2.15 A9 Cell Identifier
7 6 5 4 3 2 1 0 Octet
Length 2
Cell Identifier 4-8
Length: 4
Length field. 6
Cell Identifier: 9
referenced. The fields shall be coded as shown below: 11
Table 4.2.15-1 Cell Identifier 12
7 6 5 4 3 2 1 0 Octet
MSB MSCID 4
5
LSB 6
MSB Cell 7
Sector LSB 8
MSCID: 13
Cell/Sector: 20
each. 30
TIA-2001.6-C
Section 4 82
3
TIA-2001.6-C
83 Section 4
4.2.16 A8 Traffic ID 1
This information element identifies the connection used by the MS for packet data 2
service. 3
4.2.16 A8 Traffic ID
7 6 5 4 3 2 1 0 Octet
Length 2
A8 transport protocol stack 3
(LSB) 5
(MSB) Key 6
7
8
(LSB) 9
Address Type 10
(MSB) IP Address 11

(LSB) k
Length: 4
Length field. 6
A8 transport protocol stack: 7
This field is used to identify the A8 transport protocol stack to be used 8
for the A8 connection. 9
Table 4.2.16-1 A8 Traffic ID - A8 Transport Protocol Stack 10
Values Meaning
01H GRE/IP
All Others Reserved
Protocol Type: 11
This field is used to indicate the protocol type to be tunneled across the 12
A8 interface, and contains the same value that is used in the Protocol 13
Type field in the GRE header on the associated A8 connection. This 14
field is set to 0x88 81H (Unstructured Byte Stream). 15
Key: 16
This is a four octet field. This field is used to indicate the A8 17
connection identification, and contains the same value that is used in 18
the Key field in the GRE header on the associated A8 connection. 19
Address Type: 20
This field indicates the type and format of the IP Address that follows. 21
TIA-2001.6-C
Section 4 84
Table 4.2.16-2 A8 Traffic ID - Address Type 1
Value Address Type Length of IP Address
01H Internet Protocol IPv4 4 octets
02H Internet Protocol IPv6 variable
IP Address: 2
This field has a variable length that is dependent on the Type field. This 3
field is used to indicate the IP address of the A8 bearer port on the 4
sending entity. That is, when the BS sends the A9-Setup-A8 message 5
containing this element, this field contains the IP address at the BS 6
where the A8 user traffic connection terminates. 7
8
TIA-2001.6-C
85 Section 4
4.2.17 A9 Indicators 1
This information element indicates whether an A9-Setup-A8 message is being sent by the 2
source BS as a result of an initial connection, or by the target BS as a result of a handoff 3
operation. 4
4.2.17 A9 Indicators
7 6 5 4 3 2 1 0 Octet
Length 2
Reserved CCPD
Mode

Reserved
Data
Ready
Indicator
Handoff
Indicator
3
Length: 5
Length field. 7
Handoff Indicator: 8
This field indicates whether or not a handoff was performed. If this 9
field is set 0, the A9-Setup-A8 message indicates a normal call setup. 10
If this field is set 1, the A9-Setup-A8 message indicates a hard 11
handoff is to be performed and it is not necessary to establish the A10 12
connection immediately. This field is set to '0 for dormant handoff. 13
This field is set to 0 in the case of fast handoff because an A10 14
connection needs to be set up immediately. Refer to [13]. 15
Data Ready Indicator: 16
This field indicates whether there is data ready to be sent from the MS 17
to the network. It reflects the value of the DRS bit of the air interface. If 18
this field is set to 0, it indicates that data is not ready to be sent and 19
the A9-Setup-A8 message is reporting a mobility event. Otherwise (set 20
to 1) it indicates that data is ready to be sent. 21
22
CCPD Mode: This field indicates that an MS has requested CCPD Mode. The PCF is 23
not required to allocate an A8 connection when this bit is set. Any 24
signaling or data exchanged between the PCF and BS is sent over the 25
A9 signaling channel. 26
27
TIA-2001.6-C
Section 4 86
4.2.18 Data Count 1
This element contains a count the number of bytes to be transmitted. 2
4.2.18 Data Count
7 6 5 4 3 2 1 0 Octet
Length 2
Count - Octet 1 3
Count - Octet 2 4
Length: 3
Length field, and shall be set to 02H. 5
Count: 6
This element indicates the number of bytes remaining in the PCF. The 7
value FF FFH means that the number of bytes remaining is greater than 8
or equal to FF FFH bytes (65536 bytes). 9
10
TIA-2001.6-C
87 Section 4
4.2.19 Access Network Identifiers 1
The Access Network Identifiers information element identifies the PCF from which an 2
MS is handing off. 3
4.2.19 Access Network Identifiers
7 6 5 4 3 2 1 0 Octet
Length 2
Reserved (MSB) SID 3
(LSB) 4
(MSB) NID 5
(LSB) 6
PZID 7
Length: 4
Length field. 6
SID: 7
cellular or PCS system. 9
NID: 10
network within a cellular or PCS system. 12
PZID: 13
This one octet field is coded to the value that uniquely identifies the 14
PCF coverage area within a particular SID/NID area. The combined 15
SID/NID/PZID triplet is unique to a PCF. 16
17
TIA-2001.6-C
Section 4 88
This information element contains the service configuration record as defined in [5]. 2
4.2.20 IS-2000 Service Configuration Record
7 6 5 4 3 2 1 0 Octet
(MSB) 4

Seventh
Fill Bit
if needed
Sixth Fill
Bit if
needed
Fifth Fill
Bit if
needed
Fourth
Fill Bit
if needed
Third
Fill Bit
if needed
Second
Fill Bit
if needed
First Fill
Bit if
needed
k
[5]. The value begins in the high order bit position of octet 4 of this 19
element and extends into the last octet of this element. Bit positions in 20
the last octet that are not used, if any, are considered fill bits, are set to 21
0, and occupy the low order bit positions of the last octet. 22
23
TIA-2001.6-C
89 Section 4
message. Its definition is a BS and PCF manufacturer concern. 3
7 6 5 4 3 2 1 0 Octet
Length 2
Each version of this standard is published with a version number in the form X.Y.Z. 4
These three values shall be placed in octets 3, 4, and 5 respectively as binary values. 5
Each separate software load from a manufacturer shall have some software load identity. 6
In addition, the carrier may require the exchange of specific information between entities 7
in their network. This information shall be placed in octets 6-n in ASCII format as agreed 8
10
TIA-2001.6-C
Section 4 90
4.2.22 Anchor PDSN Address 1
This element contains the A11 interface IPv4 address of the anchor PDSN address and is 2
used for fast handoff. 3
4.2.22 Anchor PDSN Address
7 6 5 4 3 2 1 0 Octet
Length 2
(MSB) Anchor PDSN Address 3
4
5
(LSB) 6
Length: 4
Length field. 6
Anchor PDSN Address: 7
This field contains an A11 interface IPv4 address of the anchor PDSN. 8
9
TIA-2001.6-C
91 Section 4
4.2.23 A9 PDSN Code 1
This element contains the PDSN failure code sent from the PDSN to the PCF in the A11- 2
Registration Reply and A11-Registration Update messages. It is used to convey the 3
PDSN failure code from the PCF to the BS. 4
4.2.23 A9 PDSN Code
7 6 5 4 3 2 1 0 Octet
Length 2
PDSN Code 3
Length: 5
Length field. 7
PDSN Code: 8
This field contains the Code sent from the PDSN to the PCF. The 9
supported Code values are listed in Table 4.2.23-1. 10
Table 4.2.23-1 PDSN Code Values 11
Hex
Value
Decimal
Value
Code
00H 0 Registration Accepted
80H 128 Registration Denied reason unspecified
81H 129 Registration Denied administratively prohibited
82H 130 Registration Denied insufficient resources
83H 131 Registration Denied PCF failed authentication
85H 133 Registration Denied identification mismatch
86H 134 Registration Denied poorly formed request
88H 136 Registration Denied unknown PDSN address
89H 137 Registration Denied requested reverse tunnel unavailable
8AH 138 Registration Denied reverse tunnel is mandatory and T bit not set
8DH 141

Registration Denied unsupported Vendor ID or unable to interpret data
in the CVSE
C1H 193 Connection Release - Reason unspecified
C2H 194 Connection Release - PPP time-out
C3H 195 Connection Release - Registration time-out
C4H 196 Connection Release - PDSN error
C5H 197 Connection Release - Inter-PCF handoff
C6H 198 Connection Release - Inter-PDSN handoff
C7H 199 Connection Release - PDSN OAM&P intervention
C8H 200 Connection Release - Accounting error
CAH 202 Connection Release User (NAI) failed authentication
12
13
TIA-2001.6-C
Section 4 92
4.2.24 RN-PDIT 1
This element contains the Realm Configured Packet Data Session Dormancy Timer. 2
4.2.24 RN-PDIT
7 6 5 4 3 2 1 0 Octet
Length 2
RN-PDIT 3
Length: 3
Length field, and shall be set to 01H. 5
RN-PDIT: 6
This field contains the Realm Configured Packet Data Session 7
Dormancy Timer and has a range of 1-255 seconds (Refer to [15]). 8
9
10
TIA-2001.6-C
93 Section 4
4.2.25 Service Instance Info 1
This element indicates a list of the service option instances requested by the MS, or by 2
the network. It is coded as follows: 3
4.2.25 Service Instance Info
7 6 5 4 3 2 1 0 Octet
Length 2
Reserved SR-ID-6 SR-ID-5 SR-ID-4 SR-ID-3 SR-ID-2 SR-ID-1 3
(LSB) 5

(MSB) Service Option n 2n+2
(LSB) 2n+3
Length: 4
Length field. 6
SR_ID-n: 7
This field is set to 1 if the packet data session contains a service 8
instance with SR_ID=n. 9
Service Option n: 10
This field indicates the service option requested by the MS, or by the 11
network. Refer to section 4.2.8 for the encoding of this field. The first 12
service option is associated with the service instance with the smallest 13
SR_ID value and the last Service Option in the list is associated with 14
the service instance with the largest SR_ID. 15
16
TIA-2001.6-C
Section 4 94
1
3
4
5
6
7
TIA-2001.6-C
95 Section 5
2
5.1 Timer Values 3
Timer
Name
Default
Value
(seconds)
Range of
Values
(seconds)

Granularity
(seconds)
Section
Reference
T
A8-setup

4 0-99 1 5.2.1
T
alc9

0.5 0 1.0 0.1 5.2.4
T
ald9

0.5 0 1.0 0.1 5.2.7
T
aldak

1 0 5 0.1 5.2.10
T
bsreq9

1.5 0 5 0.1 5.2.6
T
discon9

1 0-5 0.1 5.2.2
T
rel9

1 0-5 0.1 5.2.3
T
sdd9

1.5 0-5 0.1 5.2.8
T
upd9

1 0-5 0.1 5.2.9
T
waitho9

Refer to section 5.2.5 5.2.5
T
ver9

1 0-5 0.1 5.2.11
7
5.2.1 T
A8-setup
8
This is a BS timer. The timer is started when an A9-Setup-A8 message is sent and 9
stopped when an A9-Connect-A8 or an A9-Release-A8 Complete message is received. 10
5.2.2 T
discon9
11
This is a PCF timer. The timer is started when an A9-Disconnect-A8 message is sent and 12
stopped when an A9-Release-A8 message is received. 13
5.2.3 T
rel9
14
This is a BS timer. The timer is started when an A9-Release-A8 message is sent and 15
stopped when an A9-Release-A8 Complete message is received. 16
5.2.4 T
alc9
17
This is a BS timer. The timer is started when an A9-AL Connected message is sent and 18
stopped when an A9-AL Connected Ack message is received. 19
TIA-2001.6-C
Section 5 96
5.2.5 T
waitho9
1
This is a PCF timer. The timer is started when an A9-Connect-A8 message is sent and 2
stopped when an A9-AL Connected or an A9-Release-A8 message is received. The value 3
of this timer shall be greater than that of the BS timer T
waitho
. Refer to [14]. 4
5.2.6 T
bsreq9
5
This is a PCF timer. The timer is started when an A9-BS Service Request message is sent 6
and stopped when an A9-BS Service Response message is received. 7
5.2.7 T
ald9
8
This is a BS timer. The timer is started when an A9-AL Disconnected message is sent 9
and stopped when an A9-AL Disconnected Ack message is received. 10
5.2.8 T
sdd9
11
This PCF timer is started after the A9-Short Data Delivery message is sent to the BS and 12
stopped when the A9-Short Data Ack message is received. 13
5.2.9 T
upd9
14
This is a BS and PCF timer. The timer is started after the A9-Update-A8 message is sent 15
and stopped when the A9-Update-A8 Ack message is received. 16
5.2.10 T
aldak
17
This is a PCF timer. The timer is started when an A9-AL Disconnected Ack message is 18
sent and stopped when an A9-Release-A8 message or A9-AL Connected message is 19
received. 20
5.2.11 T
vers9
21
This is a BS and PCF timer. The timer is started when an A9-Version Info message is 22
sent and stopped when an A9-Version Info Ack message is received. 23
TIA-2001.7-C
1
2
3
4
5
Interfaces) 7

TIA-2001.7-C

1
3

TIA-2001.7-C
i
Table of Contents 1
2
1.0 Introduction ........................................................................................................................................ 1 3
1.1 Overview........................................................................................................................................ 1 4
1.1.1 Purpose ................................................................................................................................... 1 5
1.1.2 Scope ...................................................................................................................................... 1 6
1.2 References ...................................................................................................................................... 1 7
1.2.1 TIA / EIA................................................................................................................................ 1 8
1.2.2 3GPP2..................................................................................................................................... 2 9
1.2.3 Other ....................................................................................................................................... 2 10
1.3 Terminology ................................................................................................................................... 3 11
1.3.1 Acronyms................................................................................................................................ 3 12
1.3.2 Definitions .............................................................................................................................. 4 13
1.7 Message Definition Guidelines ...................................................................................................... 7 17
1.8 Application of Mobile IP................................................................................................................ 8 18
1.9 PCF-PDSN Security Association ................................................................................................... 8 19
2.1 A10 Connection Establishment, Refresh and Release Procedures ............................................... 11 21
2.1.1 A11-Registration Request..................................................................................................... 11 22
2.1.1.1 Successful Establishment Operation................................................................................. 11 23
2.1.1.2 Successful Refresh Operation........................................................................................... 12 24
2.1.1.3 Successful Release Operation........................................................................................... 12 25
2.1.2 A11-Registration Reply........................................................................................................ 12 27
2.1.2.1 Successful Establishment Operation................................................................................. 12 28
2.1.2.2 Successful Refresh Operation........................................................................................... 13 29
2.1.2.3 Successful Release Operation........................................................................................... 13 30
2.1.3 A11-Registration Update ...................................................................................................... 13 32
2.1.4 A11-Registration Acknowledge ........................................................................................... 14 35
2.2 A10 Connection Update Procedures............................................................................................. 14 38
2.2.1 A11-Session Update ............................................................................................................. 14 39
2.2.2 A11-Session Update Acknowledge ...................................................................................... 15 42
2.3 A10 Packet Accounting Procedures ............................................................................................. 16 45
2.3.1 A10 Connection Setup Airlink Record................................................................................. 16 46
2.3.2 Active-Start Airlink Record.................................................................................................. 17 47
2.3.3 Active-Stop Airlink Record.................................................................................................. 17 48
2.3.4 SDB Airlink Record ............................................................................................................. 17 49
2.3.5 Accounting at Re-registration............................................................................................... 17 50
2.3.6 Airlink Sequence Numbers................................................................................................... 17 51
2.3.7 Accounting Update Due to Parameter Changes.................................................................... 18 52
3.0 Message Formats.............................................................................................................................. 19 53
3.1 A11-Registration Request ............................................................................................................ 19 54
3.2 A11-Registration Reply................................................................................................................ 23 55
TIA-2001.7-C
ii
3.3 A11-Registration Update.............................................................................................................. 27 1
3.4 A11-Registration Acknowledge ................................................................................................... 30 2
3.5 A11-Session Update ..................................................................................................................... 33 3
3.6 A11-Session Update Acknowledge .............................................................................................. 36 4
4.0 Information Element Definitions...................................................................................................... 39 5
4.1 Generic Information Element Encoding....................................................................................... 39 6
4.1.1 Conventions, Coding, and Interpretation Rules for Information Elements........................... 39 7
4.1.2 Information Element Identifiers............................................................................................ 39 8
4.1.3 Cross Reference of Information Elements With Messages................................................... 41 9
4.2 Information Elements ................................................................................................................... 43 10
4.2.1 A11 Message Type ............................................................................................................... 43 11
4.2.2 Flags ..................................................................................................................................... 44 12
4.2.3 Lifetime ................................................................................................................................ 45 13
4.2.4 Home Address ...................................................................................................................... 46 14
4.2.5 Home Agent.......................................................................................................................... 47 15
4.2.6 Care-of-Address.................................................................................................................... 48 16
4.2.7 Identification......................................................................................................................... 49 17
4.2.8 Code...................................................................................................................................... 50 18
4.2.9 Status .................................................................................................................................... 51 19
4.2.10 Mobile-Home Authentication Extension .............................................................................. 52 20
4.2.11 Registration Update Authentication Extension..................................................................... 53 21
4.2.12 Session Specific Extension ................................................................................................... 54 22
4.2.13 Critical Vendor/Organization Specific Extension (CVSE)................................................... 57 23
4.2.14 Normal Vendor/Organization Specific Extension (NVSE) .................................................. 65 24
5.0 Timer Definitions ............................................................................................................................. 71 25
5.1 Timer Values ................................................................................................................................ 71 26
5.2 Timer Definitions ......................................................................................................................... 71 27
5.2.1 T
regreq
..................................................................................................................................... 71 28
5.2.2 T
regupd
..................................................................................................................................... 71 29
5.2.3 T
rp
.......................................................................................................................................... 71 30
5.2.4 T
presetup
................................................................................................................................... 71 31
5.2.5 T
sesupd
..................................................................................................................................... 71 32
33
34
TIA-2001.7-C
iii
List of Tables 1
2
Table 2.4-1 Accounting Records Generated by the PCF ......................................................................... 16 4
Table 4.1.2-1 A11 Information Element Identifiers Sorted by Value ..................................................... 40 5
Table 4.1.3-1 Cross Reference of Information Elements with Messages ............................................... 41 6
Table 4.2.1-1 A11 Interface Message Types........................................................................................... 43 7
Table 4.2.2-1 Setting of A11-Registration Request Message Flags........................................................ 44 8
Table 4.2.4-1 Setting of Home Address Field......................................................................................... 46 9
Table 4.2.8-1 A11 Code Values.............................................................................................................. 50 10
Table 4.2.9-1 A11 Status Values............................................................................................................. 51 11
Table 4.2.12-1 A11 Protocol Type Values......................................................................................... 55 12
Table 4.2.12-2 Mobile Identity - Type of Identity Coding................................................................. 55 13
Table 4.2.13-1 Application Type and Sub Type ................................................................................ 58 14
Table 4.2.13-2 R-P Session Setup Airlink Record (Connection Setup) ............................................. 60 15
Table 4.2.13-3 Active Start Airlink Record ....................................................................................... 61 16
Table 4.2.13-4 Active Stop Airlink Record ....................................................................................... 61 17
Table 4.2.13-5 SDB Airlink Record................................................................................................... 62 18
Table 4.2.14-1 Application Sub Type ................................................................................................ 67 19
Table 4.2.14-2 PDSN Code Values.................................................................................................... 68 20
Table 4.2.14-3 Service Option Values ............................................................................................... 69 21
Table 5.1-1 Timer Values and Ranges Sorted by Name .......................................................................... 71 22
23
24
TIA-2001.7-C
iv
1
3
4
5
6
7
TIA-2001.7-C
1 Section 1
1.0 Introduction 1
2
1.1 Overview 3
1.1.1 Purpose 6
The purpose is to provide the standard for interfacing one or more PDSNs with one or 7
more PCFs. This document defines the functional capabilities, including services and 8
features, of the specified interfaces. These services and features are the defining 9
characteristics that are the basis for the overall system standard. 10
1.1.2 Scope 11
This standard provides the specification for the interface that coincides with the 12
Reference Point A
quater
Descriptions of the specified functional capabilities that provide packet data services 15
across the PCF-PDSN interface; 16
PCF and the PDSN without prescribing specific implementations. 18
1.2 References 19
20
1.2.1 TIA / EIA 21
[1] Reserved. 25
[2] Reserved. 26
[3] Reserved. 27
[4] Reserved. 28
[5] Reserved. 29
[6] Reserved. 30
[7] Reserved. 31
1
Wireless IP Network Standard, to be 32
published. 33
[9] Reserved. 34
[10] Reserved. 35

1
cdma2000

TIA-2001.7-C
Section 1 2
Access 1
[12] Reserved. 3
Access 4
[14] Reserved. 6
[15] Reserved. 7
Access 8
[17] Reserved. 10
1.2.2 3GPP2 12
provided here for information and cross-reference purposes. 14
[1] Reserved. 15
[2] Reserved. 16
[3] Reserved. 17
[4] Reserved. 18
[5] Reserved. 19
[6] Reserved. 20
[7] Reserved. 21
[9] Reserved. 23
[10] Reserved. 24
Access 25
[12] Reserved. 27
Access 28
[14] Reserved. 30
[15] Reserved. 31
Access 32
[17] Reserved. 34
Spread Spectrum 35
1.2.3 Other 37
[19] Internet Engineering Task Force, RFC 2002 IP Mobility Support, October 38
1996. 39
[20] Internet Engineering Task Force, RFC 2865 Remote Authentication Dial In 40
User Service (RADIUS), June 2000. 41
[21] Internet Engineering Task Force, RFC 2866 RADIUS Accounting, June 2000. 42
[22] Internet Engineering Task Force, RFC 3115 Mobile IP Vendor/Organization- 43
Specific Extensions, April 2001. 44
[23] Internet Engineering Task Force, RFC 2784 Generic Routing Encapsulation 45
(GRE), March 2000. 46
[24] Internet Engineering Task Force, RFC 2890 Key and Sequence Number 47
Extensions to GRE, September 2000. 48
[25] Internet Engineering Task Force, RFC 1321 MD5 Message Digest Algorithm, 49
April 1992. 50
TIA-2001.7-C
3 Section 1
1.3 Terminology 1
2
1.3.1 Acronyms 3
4
Acronym Meaning
3GPP2 3
rd
Generation Partnership Project 2
ANID Access Network Identifiers
BS Base Station
BSID Base Station ID
CANID Current Access Network Identifiers
CVSE Critical Vendor/Organization Specific Extension
DAI Data Available Indicator
IANA Internet Assigned Number Authority
IETF Internet Engineering Task Force
IMSI International Mobile Subscriber Identifier
IS Interim Standard
MSID Mobile Station IDentification
NVSE Normal Vendor/Organization Specific Extension
RADIUS Remote Authentication Dial In User Service
RC Radio Configuration, Radio Class
SPI Security Parameter Index
TIA-2001.7-C
Section 1 4
Acronym Meaning
TLV Type Length Value
1.3.2 Definitions 1
For each A11 interface message there are a number of information elements that are 4
individually defined in section 4.2. Each information element in a given message is 5
of being either required (R) or conditional (C) (refer to below). Some information 9
elements are reused in multiple messages. 10
PCF -> PDSN Element flows from the PCF to the PDSN
PDSN -> PCF Element flows from the PDSN to the PCF
An information element may be mandatory for some messages and optional for other 29
messages. 30
the information elements of section 4.2 and use the following conventions: 32
TIA-2001.7-C
5 Section 1
double lines. 2
element. 5
indicates: 10
<octet 1> 15
<octet m> 16
ssss ssss 22
ssss ssss 24
implemented to later revision levels, the following guidelines are defined for the 28
standard. 30
Unexpected signaling information may be received at an entity due to differing revision 31
levels of signaling protocol at different entities within a network: an entity using a more 32
enhanced version of the protocol may send information to an entity implemented at a 33
lower level of the protocol which is outside the protocol definition supported at that 34
receiving entity. 35
message processing guidelines are invoked to ensure predictable network behavior. 39
TIA-2001.7-C
Section 1 6
The sending entity shall send messages that are correctly formatted for the version of the 1
IOS declared to be implemented by the sending entity. To preserve the interoperability 2
between a PDSN and a PCF that have different IOS versions, the use of two element 3
types for the Vendor/Organization Specific Extension element is required, starting with 4
IOS version 4.1. The two types of Vendor/Organization Specific Extension elements i.e., 5
the Critical Vendor/Organization Specific Extension (CVSE) and the Normal 6
Vendor/Organization Specific Extension (NVSE) are defined in [22] where each 7
CVSE/NVSE has a 16 bit application type associated with it. This standard further 8
defines the 16-bit application type as an 8-bit application type and an 8-bit application 9
sub type. Also, the CVSEs/NVSEs introduced in this standard set the Vendor ID to the 10
Internet Assigned Number Authority (IANA) registered 3GPP2 vendor ID. 11
If a receiving entity receives a CVSE that contains an unrecognized application 12
type/application sub-type the receiving entity shall reject the message containing this 13
application type/application sub-type with an error code indicating that the message was 14
rejected due to the presence of an unknown CVSE. To support new features over the A11 15
signaling interface, new application types/application sub-types shall be included in an 16
NVSE element. If the receiving entity receives an NVSE with an unrecognized 17
application type/application sub-type, the receiving entity shall ignore the NVSE and 18
process the rest of the A11 signaling message. Within a CVSE or NVSE element 19
containing recognized application type and subtype, if any application data fields are not 20
recognized, those fields are ignored and the remainder of the element is processed to the 21
extent possible. 22
3.0. 28
Refer also to the message processing guidelines 9 and 10 below. This guideline does 40
not apply to the CVSE information element; refer to section 1.5 for more 41
information. 42
TIA-2001.7-C
7 Section 1
processed. 3
7. If a field within a received information element contains a value which is specified 7
as reserved or is otherwise not defined in the revision level implemented, this field 8
possible. In this situation, all other information elements shall be processed to the 10
extent possible. 11
entity. 14
be ignored. 18
received. 34
not change. 38
defined optional Information Elements other than the authentication extension 41
information elements (e.g. Mobile-Home Authentication Extension and Registration 42
Update Authentication Extension), which shall always be the last information 43
element in the message. 44
TIA-2001.7-C
Section 1 8
1.8 Application of Mobile IP 3
The A10/A11 interfaces are modeled after Mobile IP; refer to [19]. However, the two 4
protocols have been developed to meet different sets of requirements. With respect to the 5
model in this specification, the PDSN emulates the Home Agent (HA), and the PCF 6
emulates the Mobile node and the Foreign Agent. Note that this application of Mobile IP 7
is different from the application of Mobile IP as specified in [8], which occurs at a higher 8
layer and is transparent to the IOS. 9
By basing the A10/A11 interface on [19], the IOS may reference sections of [19] rather 10
than reproducing much of the text therein. For instance, message and information element 11
formats, extensions, security mechanisms, and codes are borrowed from [19]. Subsequent 12
sections provide explicit references to [19] when text from that document shall be 13
applied. 14
Note that this standard deviates from [19] in several respects. First, when registering, the 15
PCF uses a fictitious Home Address (= 0.0.0.0). The PDSN acting as an HA shall not 16
attempt to allocate a non-zero IP address, but instead return the Home IP address of 17
0.0.0.0 in its reply to the PCF. The PDSN uses information in the Session Specific 18
Extension (IMSI and SR_ID) as an identity of the Mobile Node. Second, this standard 19
specifies messages (Registration Update, Registration Acknowledge, Session Update, and 20
Session Update Acknowledge) not included in [19]. Third, the Registration Request and 21
Registration Reply messages are used not only for performing registrations, but also to 22
exchange other information (e.g., accounting) between the PCF and the PDSN. 23
1.9 PCF-PDSN Security Association 24
Security contexts are configurable between every PCF and PDSN pair on the packet data 25
network. Each security context indicates an authentication algorithm and mode, a secret 26
(a shared key, or appropriate public/private key pair), and a style of replay protection in 27
use. Refer to [19] for details. 28
An index identifying a security context between a pair of PCF and PDSN is called a 29
Security Parameter Index (SPI). SPI values 0 through 255 are reserved, hence not 30
used in any PCF-PDSN security association. 31
The Mobile-Home Authentication Extension and Registration Update Authentication 32
Extension provide a means for authenticating the registration messages on the A11 33
interface. The Authenticator value in the Mobile-Home Authentication Extension and 34
Registration Update Authentication Extension protects the following fields: 35
the UDP payload of registration messages, 36
all prior extensions in their entirety, and 37
the Type, Length and SPI fields of the extension. 38
The authentication algorithm uses the default keyed-MD5 ([25]) in the prefix-suffix 39
mode to compute a 128-bit message digest of the registration message. The 40
Authenticator value is a 128-bit value computed as the MD5 checksum over the 41
following stream of bytes: 42
TIA-2001.7-C
9 Section 1
the shared secret defined by the mobility security association between the PCF and 1
the PDSN and by the SPI value specified in the authentication extension, followed 2
by 3
the protected fields from the registration message, in the order specified above, 4
followed by 5
the shared secret again. 6
The Authenticator field itself and the UDP header are NOT included in the computation 7
of the Authenticator value. The receiver uses the SPI value within an authentication 8
extension to determine the security context, and to compute the Authenticator value. A 9
mismatch in the Authenticator values results in rejection of the registration message with 10
error code 131 (sending node failed authentication). Refer to [19] for implementation 11
details. 12
13
14
TIA-2001.7-C
Section 1 10
1
3
4
5
6
TIA-2001.7-C
11 Section 2
This section describes message procedures for the A10/A11 interface. 2
2.1 A10 Connection Establishment, Refresh and Release 3
Procedures 4
This section describes message procedures to establish, refresh or release an A10 5
connection. The release of an A10 connection is controlled by the PCF. For PDSN 6
initiated A10 connection release, the PDSN requests that the PCF release the connection. 7
2.1.1 A11-Registration Request 8
This message is sent from the PCF to the PDSN to initiate establishment, refresh or 9
release of an A10 connection. 10
2.1.1.1 Successful Establishment Operation 11
The PCF initiates setup of an A10 connection by sending an A11-Registration Request 12
message to the selected PDSN (refer to PDSN Selection Algorithm in [13]) with a non- 13
zero Lifetime value and starting timer T
regreq
. The A11-Registration Request message is 14
structured as specified in section 3.1. 15
If the connection setup request is acceptable, the PDSN updates its binding record for the 16
A10 connection by creating an association between the PDSN Session Identifier (PDSN 17
SID) and the IMSI, the MN Session Reference ID and PCF-Addresses. The PDSN SID 18
shall be identical to the PCF Session Identifier (PCF SID). If both the PCF and the PDSN 19
support a Session Identifier Version higher than 0, the PDSN may choose any PDSN 20
SID. In the case of multiple A10 connections for an MS, each A10 connection has its 21
own binding record and Lifetime timer. 22
The PCF and the PDSN shall use the PCF IP Address (sent in the A11-Registration 23
Request message) and the PDSN IP Address (returned in the A11-Registration Reply 24
message) as the A10 connection endpoints for the transport of user traffic. The PCF IP 25
Address and the PDSN IP Address form the unique link layer ID for each A10 26
connection. The PCF and the PDSN maintain an association of the MSs IMSI address 27
and MN Session Reference ID with the A10 connection. 28
When establishing a new A10 connection, the PCF shall always include the Current 29
Access Network Identifiers (CANID). If the PCF is able to determine that the setup of the 30
A10 connection is due to a dormant handoff or an inter-PCF hard handoff, the PCF shall 31
include a Mobility Event Indicator (MEI). If the PCF received the Access Network 32
Identifiers (ANID) from the BS, it shall also include it in the PANID field of the ANID 33
NVSE sent in the A11-Registration Request message. 34
If the PCF initiates the setup of the A10 connection due to hard handoff for which fast 35
handoff is indicated, the PCF shall set the flag bit S to 1, include the Anchor P-P 36
Address and set the Lifetime value to T
presetup
in the A11-Registration Request message. 37
In other cases the PCF shall set the Lifetime to T
rp.
38
TIA-2001.7-C
Section 2 12
2.1.1.2 Successful Refresh Operation 1
The PCF periodically refreshes the A10 connection with the PDSN by sending an A11- 2
Registration Request message with a non-zero Lifetime value before the A10 connection 3
registration Lifetime timer expires. After sending this message, the PCF starts timer 4
T
regreq
. 5
2.1.1.3 Successful Release Operation 6
The PCF may initiate release of the A10 connection by sending an A11-Registration 7
Request message to the PDSN with Lifetime field set to zero. The PCF includes 8
accounting related and other information in the A11-Registration Request message. For 9
successful operation, the PDSN removes the binding record for the A10 connection and 10
saves the accounting related and other information for further processing. 11
If the PCF does not receive an A11-Registration Reply message from the PDSN before 13
timer T
regreq
expires, the PCF may retransmit the A11-Registration Request message with 14
a new timestamp in the Identification information element. A connection establishment or 15
refresh is considered to have failed if no A11-Registration Reply message is received 16
after a configurable number of A11-Registration Request message retransmissions. For a 17
connection refresh or release, on failure to receive an A11-Registration Reply message in 18
response to a configurable number of A11-Registration Request message retransmissions, 19
the PCF removes the binding record for the A10 connection. 20
If the Lifetime timer for an A10 connection expires before the PDSN has received a valid 21
A11-Registration Request message from the PCF, then the PDSN shall delete the binding 22
record for the A10 connection. 23
2.1.2 A11-Registration Reply 24
The PDSN sends this message to the PCF to establish or refuse establishment of an A10 25
connection, acknowledge the refreshment of an A10 connection or to acknowledge the 26
teardown of an A10 connection. 27
2.1.2.1 Successful Establishment Operation 28
Upon receipt of an A11-Registration Request message with a nonzero Lifetime value, the 29
PDSN shall respond with an A11-Registration Reply message. If the PDSN accepts 30
establishment of the A10 connection, it shall send a Registration Accepted indication and 31
a non-zero Lifetime parameter value in the message. The value of the Lifetime parameter 32
in the A11-Registration Reply message shall be less or equal to the value of the Lifetime 33
parameter received in the A11-Registration Request message. The PCF stops timer 34
T
regreq
when it receives the A11-Registration Reply message and starts the Lifetime timer 35
initialized to the value of the returned Lifetime parameter. 36
If the PDSN has data to send to the PCF when it receives an A11-Registration Request 37
message, the PDSN shall include a Data Available Indication as a CVSE in the A11- 38
Registration Reply message. 39
If the PDSN supports fast handoff, the PDSN shall include the Anchor P-P Address in an 40
NVSE in the A11-Registration Reply message. 41
TIA-2001.7-C
13 Section 2
If the selected PDSN does not accept establishment of the A10 connection, it shall return 1
an A11-Registration Reply message with a reject result code. Upon receipt of this 2
message, the PCF stops timer T
regreq
. 3
The PDSN may return an A11-Registration Reply message with result code 88H 4
(Registration Denied unknown PDSN address). When code 88H is used, an alternate 5
PDSN address is included in the A11-Registration Reply message. The address of the 6
alternate proposed PDSN shall be returned in the Home Agent field of the A11- 7
Registration Reply message. Upon receipt of this message, the PCF stops timer T
regreq
. 8
On receipt of an A11-Registration Reply message with code 88H, the PCF shall either 9
initiate establishment of the A10 connection with the proposed PDSN by sending a new 10
A11-Registration Request message as indicated in this section, or it shall use internal 11
algorithms to select a new PDSN. 12
On receipt of an A11-Registration Reply message with another result code, depending on 13
the result code, the PCF may attempt to re-try setting up the A10 connection. 14
2.1.2.2 Successful Refresh Operation 15
Upon receipt of an A11-Registration Request message with a nonzero Lifetime value, the 16
PDSN shall respond with an A11-Registration Reply message with an accept indication, 17
including a Lifetime parameter value less or equal to the value of the received Lifetime 18
parameter. Upon receipt of this message, the PCF stops timer T
regreq
and starts the 19
Lifetime timer initialized to the value of the returned Lifetime parameter. 20
If authentication failed during re-registration, the A10 connection is released at the 21
expiration of the Lifetime timer. 22
If an identification mismatch is detected in the A11-Registration Reply message at re- 23
registration, the A10 connection is released upon expiration of the Lifetime timer. 24
2.1.2.3 Successful Release Operation 25
Upon receipt of an A11-Registration Request message with Lifetime field set to zero, the 26
PDSN shall respond with an A11-Registration Reply message with an accept indication. 27
Upon receipt of this message, the PCF removes the binding record for the A10 28
connection and stops timer T
regreq
. 29
None. 31
2.1.3 A11-Registration Update 32
The PDSN sends this message to the PCF to initiate release of an A10 connection. 33
The PDSN may initiate release of an A10 connection by sending an A11-Registration 35
Update message to the PCF. The Home Agent field in the A11-Registration Update 36
message is the PDSN-Address and the Home Address is set to zero. The PCF Session 37
TIA-2001.7-C
Section 2 14
Identifier and other session specific information are sent within the Session Specific 1
extension. After sending this message, the PDSN starts timer T
regupd
. 2
If the PDSN does not receive an A11-Registration Acknowledge message or an A11- 4
Registration Request message (with the Lifetime parameter set to 0 and accounting 5
related information included) before timer T
regupd
expires, the PDSN may retransmit the 6
A11-Registration Update message. 7
If the PDSN has not received an A11-Registration Acknowledge message or an A11- 8
Registration Request message (with Lifetime parameter set to 0 and accounting related 9
information included) after a configurable number of retransmissions, or upon receipt of 10
an A11-Registration Acknowledge message with an update denied status, the PDSN 11
shall remove the binding record for the A10 connection. 12
2.1.4 A11-Registration Acknowledge 13
The PCF sends this message to the PDSN to acknowledge receipt of an A11-Registration 14
Update message. 15
Upon receipt of an A11-Registration Update message, the PCF shall send an A11- 17
Registration Acknowledge message. If the PCF accepts the update, it shall send an 18
accept indication in the message. Otherwise, the PCF shall indicate an update denied 19
status. Upon receipt of this message, the PDSN stops timer T
regupd
. 20
For successful operation, the PCF includes accounting related and other information in a 21
CVSE in the A11-Registration Request message with the Lifetime parameter set to zero 22
(0). The PDSN responds with an A11-Registration Reply message with an accept 23
indication and saves the accounting related information and other information for further 24
processing. At this time, both the PCF and the PDSN remove the binding record for the 25
A10 connection. 26
None. 28
2.2 A10 Connection Update Procedures 29
The PDSN initiates the update of new or additional packet data session parameters on an 30
existing A10 connection with the messages described in this section. 31
2.2.1 A11-Session Update 32
The A11-Session Update message is sent from the PDSN to the PCF to add, change, or 33
update session parameters for an A10 connection. It is also sent to update the PCF with 34
the Anchor P-P Address. 35
TIA-2001.7-C
15 Section 2
The PDSN may update session parameters of an A10 connection or the Anchor P-P 2
Address by sending an A11-Session Update to the PCF. The Home Agent field in A11- 3
Session Update is the PDSN-Address and the Home Address is set to zero. The PCF 4
Session Identifier and other session specific information are sent within the Session 5
Specific Extension. 6
The A11-Session Update message includes the session parameter(s) or the Anchor P-P 7
Address in NVSE(s). For session parameter(s), the PCF either updates its session 8
parameters or relays the parameters to the BS. 9
After sending the A11-Session Update message, the PDSN starts timer T
sesupd
. 10
If the PDSN does not receive an A11-Session Update Acknowledge message before timer 12
T
sesupd
expires, the PDSN may retransmit the A11-Session Update message a 13
configurable number of times to the PCF. 14
If the PDSN has not received an A11-Session Update Acknowledge after a configurable 15
number of retransmissions, the PDSN shall consider the update failed and shall maintain 16
2.2.2 A11-Session Update Acknowledge 18
The A11-Session Update Acknowledge message is sent from PCF to PDSN to 19
acknowledge an A11-Session Update message. 20
When the PCF receives an A11-Session Update message with session parameter(s) in 22
NVSE(s), and the PCF accepts the update, the PCF shall send an A11-Session Update 23
Acknowledge message to the PDSN with an accept indication. If the PCF does not 24
accept the update it shall send a denied indication. When the PDSN receives this 25
sesupd
. 26
None. 28
29
TIA-2001.7-C
Section 2 16
2.3 A10 Packet Accounting Procedures 1
The PCF uses the A11-Registration Request message to send accounting related and 2
other information to the PDSN. The accounting related information is accumulated at the 3
PCF and sent to the PDSN on occurrence of pre-defined triggers, which are listed in 4
Table 2.4-1 below. The occurrence of these predefined triggers is fully specified in [8]. 5
The A10 connection binding record at the PDSN and the PCF may also be updated 6
appropriately depending on the setting of the Lifetime field. 7
Table 2.4-1 Accounting Records Generated by the PCF 8
Airlink
Record Type
(Y1)
Accounting Records Generated by the PCF
Y1=1 Connection Setup: Setup of A10 connection initiated
Y1=2 Active Start: A10 connection is associated with the traffic
channel(s) or new parameters are set.
Y1=3 Active Stop: A10 connection is disassociated from the
traffic channel(s) or parameter settings are no longer valid.
Y1=4 A forward or reverse short data burst (SDB) was exchanged
with the MS
If any airlink parameters for an active session change, the PCF generates an Active Stop 9
(Y1=3) accounting record followed by an Active Start (Y1=2) accounting record. For 10
successful operation, the PDSN saves the accounting related and other information for 11
further processing, and responds with an A11-Registration Reply message containing an 12
accept indication. 13
The Airlink Record information is transferred from the PCF to the PDSN, as RADIUS 14
protocol encoded attributes, in the Application Data field of a CVSE element. If the 15
PDSN receives an unexpected airlink record it may reject the A11-Registration Request 16
message and the A11-Registration Reply message shall contain the code 86H 17
(Registration Denied poorly formed request). If the PDSN does not receive an 18
accounting parameter that is expected, the PDSN may reject the A11-Registration 19
Request message, and the associated A11-Registration Reply message shall contain 20
either: 21
code 8DH (Registration Denied unsupported Vendor ID or unable to interpret 22
Application Type or Application Sub Type in the CVSE sent by the PCF to the 23
PDSN), or 24
code 86H (Registration Denied poorly formed request). 25
If the PDSN receives a RADIUS attribute that is not expected in a CVSE, the PDSN shall 26
ignore that attribute and process the remainder of the CVSE to the extent possible. Refer 27
to section 4.2.13 for further details. 28
2.3.1 A10 Connection Setup Airlink Record 29
The A10 Connection Setup Airlink record shall be included in the A11-Registration 30
Request message at the time of establishment of a new A10 connection. It is also 31
included in the A11-Registration Request message if an A10 connection is pre-setup 32
during fast handoff. 33
TIA-2001.7-C
17 Section 2
2.3.2 Active-Start Airlink Record 1
The Active-Start Airlink record shall be included in the A11-Registration Request 2
message under the following circumstances: 3
1. When a traffic channel is assigned to a packet data service instance: during initial 4
service instance setup when the service instance becomes associated with the air 5
interface, on transition from dormant to active state or during handoff. The Active- 6
Start Airlink record may follow the connection Setup Airlink record in the same 7
A11-Registration Request message (assuming that all the parameters required in the 8
Active-Start Airlink record are made available at the PCF at the time the message is 9
sent). 10
2. Following an Active-Stop Airlink record when any of the parameters (QoS, User 11
Zone, Forward/Reverse Mux Option) currently defined in the Active Start Airlink 12
Record are changed. The Active Start Airlink Record shall contain the new set of 13
parameters. 14
2.3.3 Active-Stop Airlink Record 15
The Active Stop Airlink Record shall be included in the A11-Registration Request 16
message under the following circumstances: 17
1. When the traffic channel is disassociated from the packet data service instance: 18
during service instance release, on transition from active state to dormant, or during 19
handoff. 20
2. When any of the parameters (QoS, User Zone, Forward/Reverse Mux Option) 21
currently defined in the Active Start Airlink Record are changed. 22
In the case of (2), the Active Stop Airlink Record shall be sent and followed by an Active 23
Start Airlink Record that shall contain the new set of parameters. 24
2.3.4 SDB Airlink Record 25
The SDB Airlink Record is used by the PCF to report to the PDSN the transfer of Short 26
Data Burst information to and from the user. 27
The PCF should be notified when a successful SDB is delivered to the MS or 28
successfully received by the BS. 29
2.3.5 Accounting at Re-registration 30
Reception by the PCF of new accounting information shall trigger an A11-Registration 31
Request message to transfer this accounting information to the PDSN. 32
2.3.6 Airlink Sequence Numbers 33
All the airlink records include a sequence number initialized to zero at A10 connection 34
setup for each identification triplet (PCF session ID, MSID, PCF ID). When transmitting 35
an airlink record to the PDSN, the PCF shall increment the sequence number (modulo 36
256) and insert it into the airlink record. If multiple airlink records are sent in the same 37
message their sequence numbers shall be in ascending order (modulo 256 arithmetic). 38
TIA-2001.7-C
Section 2 18
In the event of retransmission of the Air Link Record, the PCF shall retransmit with the 1
same sequence number. 2
2.3.7 Accounting Update Due to Parameter Changes 3
During an active connection, if any of the following parameters are changed: 4
User Zone 5
Airlink Priority 6
Forward/Reverse Mux Option 7
the PCF shall convey an Active Stop airlink record, and an Active Start airlink 8
record with a new set of parameters to the PDSN, via an A11-Registration Request 9
message. 10
TIA-2001.7-C
19 Section 3
2
3.1 A11-Registration Request 3
This A11 interface message is sent from the PCF to the PDSN for: 4
establishing an A10 connection (and identifying the associated service option value 5
and MN Session Reference ID); 6
periodic re-registration of an A10 connection; 7
clearing an A10 connection; 8
passing accounting related information; 9
indicating that all packet data service instances have gone dormant; 10
passing fast handoff related information. 11
12
Reference
A11 Message Type 4.2.1 PCF -> PDSN M
Flags 4.2.2 PCF -> PDSN O R
Lifetime 4.2.3 PCF -> PDSN O R
Home Address 4.2.4 PCF -> PDSN O R
Home Agent 4.2.5 PCF -> PDSN O R
Care-of-Address 4.2.6 PCF -> PDSN O R
Identification 4.2.7 PCF -> PDSN O R
Session Specific Extension 4.2.12 PCF -> PDSN O R
Critical Vendor/Organization Specific
Extension
4.2.13 PCF -> PDSN O
a,e
C
Normal Vendor/Organization Specific
Extension
4.2.14 PCF -> PDSN O
a,b,c,d,f
C
Mobile-Home Authentication Extension 4.2.10 PCF -> PDSN O R
a. One or more instances of this element may be included. 13
b During a fast handoff, this element is used to provide the Anchor P-P Address to the 14
target PDSN when the PCF supports fast handoff. 15
c. If this message contains the Active Stop Airlink Record for the last service instance 16
going dormant (i.e., all packet data service instances for the user are dormant) in the 17
CVSE, then an instance of this element containing the All Dormant Indicator shall be 18
included in this message. 19
d. This element shall be included when this message is sent for A10 connection setup 20
and the PCF is capable of supporting multiple service instances. It contains the 21
Service Option value for the packet data service instance received from the PCF. 22
e. During a handoff, this element is used to provide the MEI. 23
f. During a handoff, this element is used to provide the ANIDs. 24
25
TIA-2001.7-C
Section 3 20
The following table shows the bitmap layout for the A11-Registration Request message. 1
3.1 A11-Registration Request
0 1 2 3 4 5 6 7 Octet
! !! ! A11 Message Type = [01H] 1
! !! ! Flags = [0AH, 8AH] 1
(MSB) ! !! ! Lifetime = [00 00H to FF FEH] 1
(LSB) 2
(MSB) ! !! ! Home Address = [00 00 00 00H] 1
2
3
(LSB) 4
(MSB) ! !! ! Home Agent = <any value> 1
2
3
(LSB) 4
(MSB) ! !! ! Care-of-Address = <any value> 1
2
3
(LSB) 4
(MSB) ! !! ! Identification = <any value> 1
2
3
4
5
6
7
(LSB) 8
! !! ! Session Specific Extension: = [27H] 1
Length = [13H15H] 2
(MSB) Protocol Type = [88 0BH, 88 81H] 3
(LSB) 4
6
7
(LSB) 8
Reserved = [00H] 9
TIA-2001.7-C
21 Section 3
0 1 2 3 4 5 6 7 Octet
Session ID Ver =
[00 (Version 0),
01 (Version 1)]
10
(MSB) MN Session Reference Id = [00 01H 00 06H] 11
(LSB) 12
(MSB) MSID Type = [00 06H] (IMSI) 13
(LSB) 14
MSID Length = [06-08H] (10-15 digits) 15
Identity Digit 1 = [0H-9H] (BCD) Odd/Even Indicator = [0000, 0001] 16

If (Odd/Even Indicator = 0000 (even))
{Identity Digit N+1 = [FH] (BCD)}
Else If (Odd/Even Indicator = 0001 (odd))
{Identity Digit N+1 = [0H-9H] (BCD)}
Identity Digit N = [0H-9H] (BCD) k
! !! ! Critical Vendor/Organization Specific Extension: Type = [26H] 1
Reserved = [0000 0000] 2
(MSB) Length = <variable> 3
(LSB) 4
(MSB) 3GPP2 Vendor ID = 00 00 15 9FH 5
6
7
(LSB) 8
Application Type = [01H, 02H] 9
I F (Application Type =01H (Accounting) {1:
Application Sub Type = [01H] 10
(MSB) Application Data (contains accounting information) 11

(LSB) k
}Application Type =01H; ELSE I F (Application Type =02H (Mobility Event I ndicator)) {1:
Application Sub Type = [01H] m
}Application Type =02H
! !! ! Normal Vendor/Organization Specific Extension: Type = [86H] 1
(MSB) Reserved = [00 00H] 3
(LSB) 4
(MSB) 3GPP2 Vendor ID = [00 00 15 9FH] 5
TIA-2001.7-C
Section 3 22
0 1 2 3 4 5 6 7 Octet
6
7
(LSB) 8
Application Type = [04H-06H,09H] (Access Network Identifiers, PDSN Identifier,
Indicators)
9
I F (Application Type =04H (Access Network I dentifiers)) {1:
(MSB) Application Data = <any value> (contains PANID and CANID) 11

(LSB) 20
}Application Type =04H, ELSE I F (Application Type =05H (PDSN I dentifier)) {1:
Application Sub Type = [01H (Anchor P-P Address)] 10
(MSB) Application Data (contains an IPv4 address) 11
12
13
(LSB) 14
}Application Type =05H; ELSE I F (Application Type=06H (I ndicators)) {1
Application Sub Type = [01H (All Dormant Indicator)] 10
(MSB) Application Data = 00 00H 11
(LSB) 12
}Application Type =06H; ELSE I F (Application Type =09H (Service Option)) {1:
(MSB) Application Data (contains Service Option) 11
(LSB) 12
}Application Type =09H
! !! ! Mobile-Home Authentication Extension: Type = [20H] 1
Length = [14H] 2
(MSB) SPI = [00 00 01 00H to FF FF FF FFH] 3
4
5
(LSB) 6
(MSB) Authenticator = <any value > (keyed-MD-5 authentication) 7
8
9

(LSB) 22
1
TIA-2001.7-C
23 Section 3
3.2 A11-Registration Reply 1
This A11 interface message is sent from the PDSN to the PCF in response to an A11- 2
Registration Request message. 3
Reference
A11 Message Type 4.2.1 PDSN -> PCF M
Code 4.2.8 PDSN -> PCF M
Lifetime 4.2.3 PDSN -> PCF M
Home Address 4.2.4 PDSN -> PCF M
Home Agent 4.2.5 PDSN -> PCF M
a

Identification 4.2.7 PDSN -> PCF M
Session Specific Extension 4.2.12 PDSN -> PCF M
Critical Vendor/Organization Specific
Extension
4.2.13 PDSN -> PCF O
b
C
Extension
c,d,e,f,g
C
Mobile-Home Authentication Extension 4.2.10 PDSN -> PCF O R
a. This element can also be used to identify the IPv4 address of an alternative PDSN. 4
b. This element is included if the PDSN has data available. 5
c. This element is used by the anchor PDSN to provide an Anchor P-P Address when 6
the PDSN supports fast handoff. 7
d. One or more instances of this element may be included. 8
e. During a fast handoff, the target PDSN includes the Anchor P-P Address to indicate 9
that the fast handoff request was accepted. 10
f. This element is used to send a Radio Network Packet Data Inactivity Timer (RN- 11
PDIT) to the PCF when supported. 12
g. When an Always-on Indicator is present at the PDSN, the PDSN shall include the 13
NVSE with an Always-on indicator. 14
15
TIA-2001.7-C
Section 3 24
The following table shows the bitmap layout for the A11-Registration Reply message. 1
3.2 A11-Registration Reply
0 1 2 3 4 5 6 7 Octet
! !! ! A11 Message Type = [03H] 1
! !! ! Code =
[00H (Registration Accepted),
80H (Registration Denied reason unspecified),
81H (Registration Denied administratively prohibited),
82H (Registration Denied insufficient resources),
83H (Registration Denied PCF failed authentication),
85H (Registration Denied identification mismatch),
86H (Registration Denied poorly formed request),
88H (Registration Denied unknown PDSN address),
89H (Registration Denied requested reverse tunnel unavailable),
8AH (Registration Denied reverse tunnel is mandatory and T bit not set),
8DH (Registration Denied unsupported vendor ID or unable to interpret Application
Type or Application Sub Type in the CVSE sent by the PCF to the PDSN.)]
1
(MSB) ! !! ! Lifetime = [00 00H to FF FEH] 1
(LSB) 2
2
3
(LSB) 4
2
3
(LSB) 4
2
3
4
5
6
7
(LSB) 8
! !! ! Session Specific Extension: Type = [27H] 1
Length = [13H 15H] 2
TIA-2001.7-C
25 Section 3
0 1 2 3 4 5 6 7 Octet
(LSB) 4
6
7
(LSB) 8
Reserved = [00H] 9
Session ID Ver =
[00 (Version 0),
01 (Version 1)]
10
(LSB) 12
(LSB) 14
Identity Digit 1 = [0H - 9H] (BCD) Odd/Even Indicator = [0000, 0001] 16
Identity Digit 3 = [0H - 9H] (BCD) Identity Digit 2 = [0H - 9H] (BCD) 17

{Identity Digit N+1 = [0H - 9H] (BCD)}
Identity Digit N = [0H - 9H] (BCD) 21-23
! !! ! Critical Vendor/Organization Specific Extension: Type = [26H] 1
Reserved = [0000 0000] 2
(MSB) Length = [00 06H] 3
(LSB) 4
6
7
(LSB) 8
Application Type = [03H] (Data Availability Indicator) 9
Reserved = [00 00H] 3
4
6
TIA-2001.7-C
Section 3 26
0 1 2 3 4 5 6 7 Octet
7
(LSB) 8
Application Type = [05H (PDSN Identifier, 08H (Session Parameter)] 9
I F (Application Type =05H (PDSN I dentifier)){1
(MSB) Application Data (contains an IPv4 address)> 11
12
13
(LSB) 14
}Application Type =05H; ELSE I F (Application Type =08H (Session Parameter)){1
Application Sub Type = [01H (RN-PDIT), 02H (Always-on)] 10
I F (Application Sub Type =01H (RN-PDI T)) {1
(MSB) Application Data = [01FF] (LSB) 11
}Application Sub Type =01H, }Application Type =08H
! !! ! Mobile-Home Authentication Extension: Type = [20H] 1
Length = [14H] 2
4
5
(LSB) 6
8
9

(LSB) 22
1
TIA-2001.7-C
27 Section 3
3.3 A11-Registration Update 1
This A11 interface message is sent from the PDSN to the PCF to release an A10 2
connection. 3
Reference
Reserved <3 octets> None PDSN -> PCF M
a

Extension
b
C
Registration Update Authentication
Extension
4.2.11 PDSN -> PCF M
a. This field is set to zero by the PDSN and ignored by the PCF. 4
b. This element is used by the PDSN to provide a PDSN code to the PCF. 5
The following table shows the bitmap layout for the A11-Registration Update message. 6
3.3 A11-Registration Update
0 1 2 3 4 5 6 7 Octet
! !! ! Reserved = [00 00 00H] 1
2
3
2
3
(LSB) 4
2
3
(LSB) 4
2
3
4
5
TIA-2001.7-C
Section 3 28
0 1 2 3 4 5 6 7 Octet
6
7
(LSB) 8
(LSB) 4
6
7
(LSB) 8
Reserved = [00H] 9
Session ID Ver =
[00 (Version 0),
01 (Version 1)]
10
(LSB) 12
(LSB) 14

ELSE (If Odd/Even Indicator = 0001 (odd))
Length - <variable> 2
(LSB) 4
6
7
(LSB) 8
Application Type = [07H (PDSN CODE)] 9
TIA-2001.7-C
29 Section 3
0 1 2 3 4 5 6 7 Octet
Application Data = [C1H-C8H, CAH] 11
! !! ! Registration Update Authentication Extension: Type = [28H] 1
Length = [14H] 2
4
5
(LSB) 6
8
9

(LSB) 22
1
TIA-2001.7-C
Section 3 30
3.4 A11-Registration Acknowledge 1
This A11 interface message is sent from the PCF to the PDSN in response to an A11- 2
Registration Update message. 3
Reference
Reserved <2 octets> None PCF -> PDSN M
a

Status 4.2.9 PCF -> PDSN M
Home Address 4.2.4 PCF -> PDSN M
Care-of-Address 4.2.6 PCF -> PDSN M
Identification 4.2.7 PCF -> PDSN M
Session Specific Extension 4.2.12 PCF -> PDSN M
Extension
4.2.11 PCF -> PDSN M
a. This field is set to zero by the PCF and ignored by the PDSN. 4
The following table shows the bitmap layout for the A11-Registration Acknowledge 5
message. 6
3.4 A11-Registration Acknowledge
0 1 2 3 4 5 6 7 Octet
! !! ! Reserved = [00 00H] 1
2
! !! ! Status =
[00H (Update Accepted)
80H (Update Denied reason unspecified)
83H (Update Denied sending node failed authentication)
85H (Update Denied identification mismatch)
86H (Update Denied poorly formed registration update)]
1
2
3
(LSB) 4
2
3
(LSB) 4
2
TIA-2001.7-C
31 Section 3
0 1 2 3 4 5 6 7 Octet
3
4
5
6
7
(LSB) 8
(LSB) 4
6
7
(LSB) 8
Reserved = [00H] 9
Session ID Ver =
[00 (Version 0),
01 (Version 1)]
10
(LSB) 12
(LSB) 14

Length = [14H] 2
4
5
(LSB) 6
TIA-2001.7-C
Section 3 32
0 1 2 3 4 5 6 7 Octet
8
9

(LSB) 22
1
2
TIA-2001.7-C
33 Section 3
3.5 A11-Session Update 1
This A11 interface message is sent from the PDSN to the PCF to add new or update 2
parameters of an A10 connection. It is also sent to update the PCF with the Anchor P-P 3
Address. 4
Reference
Reserved <3 octets> None PDSN -> PCF M
a

Extension
4.2.14 PDSN ->PCF O
b,c
C
Extension
4.2.11 PDSN -> PCF M
a. This field is set to zero by the PDSN and ignored by the PCF. 5
b. This element is used by the PDSN to provide an RN-PDIT value to the PCF. 6
c. When an Always-on Indicator is present at the PDSN, the PDSN shall include the 7
NVSE with an Always-on indicator 8
The following table shows the bitmap layout for the A11-Session Update message. 9
3.5 A11-Session Update
0 1 2 3 4 5 6 7 Octet
(MSB) ! !! ! Reserved = [00 00 00H] 1
2
(LSB) 3
2
3
(LSB) 4
2
3
(LSB) 4
2
3
TIA-2001.7-C
Section 3 34
0 1 2 3 4 5 6 7 Octet
4
5
6
7
(LSB) 8
(MSB) Protocol Type = [88 81H] 3
(LSB) 4
6
7
(LSB) 8
Reserved = [00H] 9
Session ID Ver =
[00 (Version 0),
01 (Version 1)]
10
(MSB) MN Session Reference Id = <any value> 11
(LSB) 12
(LSB) 14

ELSE (If Odd/Even Indicator = 0001 (odd))
Length = <any value> 2
(LSB) 4
6
7
(LSB) 8
TIA-2001.7-C
35 Section 3
0 1 2 3 4 5 6 7 Octet
Application Type = [05H (PDSN Identifier), 08H (Session Parameter)] 9
I F (Application Type =05H (PDSN I dentifier)){1
(MSB) Application Data = (contains an IPv4 address) 11
12
13
(LSB) 14
}Application Type =05H; ELSE I F (Application Type =08H (Session Parameter)) {1
Application Sub Type = [01H (RN-PDIT), 02H (Always-on)]] 10
I F (Application Sub Type =01H (RN-PDI T)) {1
(MSB) Application Data = [01FFH] (LSB) 11
}Application Sub Type =01H, }Application Type =08H;
Length = [14H] 2
4
5
(LSB) 6
8
9

(LSB) 22
1
TIA-2001.7-C
Section 3 36
3.6 A11-Session Update Acknowledge 1
This A11 interface message is sent from the PCF to the PDSN in response to an A11- 2
Session Update message. 3
Reference
Reserved <2 octets> None PCF -> PDSN M
a

Status 4.2.9 PCF -> PDSN M
Home Address 4.2.4 PCF -> PDSN M
Care-of-Address 4.2.6 PCF -> PDSN M
Identification 4.2.7 PCF -> PDSN M
Session Specific Extension 4.2.12 PCF -> PDSN M
Extension
4.2.11 PCF -> PDSN M
a. This field is set to zero by the PCF and ignored by the PDSN. 4
The following table shows the bitmap layout for the A11-Session Update Acknowledge 5
message. 6
3.6 A11-Session Update Acknowledge
0 1 2 3 4 5 6 7 Octet
! !! ! Reserved = [00 00H] 1
2
! !! ! Status =
[00H (Update Accepted)
80H (Update Denied reason unspecified)
83H (Update Denied sending node failed authentication)
85H (Update Denied identification mismatch)
86H (Update Denied poorly formed registration update)
C9H (Update Denied session parameters not updated)]
1
2
3
(LSB) 4
2
3
(LSB) 4
TIA-2001.7-C
37 Section 3
0 1 2 3 4 5 6 7 Octet
2
3
4
5
6
7
(LSB) 8
(MSB) Protocol Type = [88 81H] 3
(LSB) 4
(MSB) 5
Key = <any value> 6
7
(LSB) 8
Reserved = [00H] 9
Session ID Ver =
[00 (Version 0),
01 (Version 1)]
10
(MSB) MN Session Reference Id = <any value> 11
(LSB) 12
(LSB) 14

Length = [14H] 2
4
5
(LSB) 6
TIA-2001.7-C
Section 3 38
0 1 2 3 4 5 6 7 Octet
8
9

(LSB) 22
1
2
TIA-2001.7-C
39 Section 4
9
4.1.1 Conventions, Coding, and Interpretation Rules for Information 10
Elements 11
bytes: 13
Each bit position is marked as 0 to 7. For the A10/A11 interface, bit 0 is the most 14
significant bit and is transmitted first. Note that for all other interfaces, bit 0 is the 15
least significant bit and is transmitted first. 16
2, etc. 18
occurrences on a specific A11 interface. Insofar as possible, the same Information 22
than one interface. 24
The order of appearance for each information element and the definition of whether an 25
information element is mandatory or optional is specified in section 3.0. 26
For future expansion purposes, some of these information elements have fields within 27
them that have been reserved. All reserved bits are set to 0, unless otherwise indicated. 28
To allow compatibility with future implementation, messages shall not be rejected simply 29
because a reserved bit is set to 1. The extensions for the A11 interface messages are 30
defined in the TLV (Type-Length-Value) format. The Type field indicates the type of the 31
extension. Length field indicates the length (in octets) of the extension, not including the 32
Type and Length fields. The value field contains the information specific to the Type of 33
the extension. 34
includes a reference to the section where the information element coding can be found. A 39
TIA-2001.7-C
Section 4 40
listing of information elements, sorted by name, is included in Table 4.1.3-1, which also 1
specifies the messages in which each information element is used. 2
A11 interface information elements, other than the extensions, are position specific, and 3
hence do not include the IEI. The A11 interface extensions are, however, identified by a 4
Type field, which distinguishes one extension from the others. 5
Table 4.1.2-1 A11 Information Element Identifiers Sorted by Value 6
Element Name Identifier Reference
A11 Message Type None 4.2.1
Care-of-Address None 4.2.6
Code None 4.2.8
Flags None 4.2.2
Home Address None 4.2.4
Home Agent None 4.2.5
Identification None 4.2.7
Lifetime None 4.2.3
Status None 4.2.9
Mobile-Home Authentication Extension 20H 4.2.10
Critical Vendor/Organization Specific Extension 26H 4.2.13
Session Specific Extension 27H 4.2.12
Registration Update Authentication Extension 28H 4.2.11
Normal Vendor/Organization Specific Extension 86H 4.2.14
7
8
TIA-2001.7-C
41 Section 4
A11 Message Type 4.2.1 None A11-Registration Request 3.1
A11-Registration Reply 3.2
A11-Registration Update 3.3
A11-Registration Acknowledge 3.4
A11-Session Update 3.5
A11-Session Update Acknowledge 3.6
Care-of-Address 4.2.6 None A11-Registration Request 3.1
Code 4.2.8 None A11-Registration Reply 3.2
4.2.13 26H A11-Registration Request 3.1 Critical Vendor/Organization
Specific Extension
Flags 4.2.2 None A11-Registration Request 3.1
Home Address 4.2.4 None A11-Registration Request 3.1
Home Agent 4.2.5 None A11-Registration Request 3.1
Identification 4.2.7 None A11-Registration Request 3.1
Lifetime 4.2.3 None A11-Registration Request 3.1
4.2.10 20H A11-Registration Request 3.1 Mobile-Home Authentication
Extension
TIA-2001.7-C
Section 4 42
4.2.14 86H A11-Registration Request 3.1 Normal Vendor/Organization
Specific Extension
4.2.11 28H A11-Registration Update 3.3 Registration Update
Authentication Extension
Session Specific Extension 4.2.12 27H A11-Registration Request 3.1
Status 4.2.9 None A11-Registration Acknowledge 3.4
1
TIA-2001.7-C
43 Section 4
4.2.1 A11 Message Type 2
This one octet element identifies the type of the A11 interface message. The structure of 3
the element conforms to [19], and is shown below. 4
4.2.1 A11 Message Type
0 1 2 3 4 5 6 7 Octet
A11 Message Type 1
The A11 interface message types are listed in Table 4.2.1-1. These values shall remain 5
coordinated with the values assigned by the IETF for the Mobile IP protocol. 6
Table 4.2.1-1 A11 Interface Message Types 7

A11 Interface Message Name
A11 Message
Type Value
Section
Reference
01H 3.1
03H 3.2
14H 3.3
15H 3.4
A11-Session Update
16H 3.5
A11-Session Update Acknowledge
17H 3.6
8
9
TIA-2001.7-C
Section 4 44
4.2.2 Flags 1
The structure of this element conforms to [19], and is shown below. The setting of the 2
Flags bits determines how an A11 interface message is interpreted by the receiving entity, 3
and also the characteristics of the A10 connection. 4
4.2.2 Flags
0 1 2 3 4 5 6 7 Octet
S B D M G V T Reserved 1
For the A11-Registration Request message, the Flag bits are set as specified in Table 5
4.2.2-1. The S bit is used for fast handoff. It is coded as specified in [8]. 6
Table 4.2.2-1 Setting of A11-Registration Request Message Flags 7
0 1 2 3 4 5 6 7 Bit Position
S B D M G V T
RES
Bit Identifier
0/1 Simultaneous Bindings
0 Broadcast Datagrams
0 Decapsulation by mobile node
0 Minimal Encapsulation
1 GRE Encapsulation
0 V.J. Compression
1 Reverse Tunneling
0 Reserved Bit
8
9
TIA-2001.7-C
45 Section 4
4.2.3 Lifetime 1
This two-octet element indicates the longest lifetime measured in seconds that the 2
sending entity is willing to accept before registration for an A10 connection is considered 3
expired. The structure of the element conforms to [19] and is shown below. 4
4.2.3 Lifetime
0 1 2 3 4 5 6 7 Octet
(MSB) Lifetime 1
(LSB) 2
5
6
TIA-2001.7-C
Section 4 46
4.2.4 Home Address 1
This information element does not carry valid information for this interface and is 2
ignored. However, it shall be included in all A11 messages and the information element 3
conforms to [19]. 4
4.2.4 Home Address
0 1 2 3 4 5 6 7 Octet
(MSB) Home Address 1
2
3
(LSB) 4
Table 4.2.4-1 shows the setting of the Home Address field for various A11 interface 5
messages. 6
Table 4.2.4-1 Setting of Home Address Field 7

A11 Interface Message

Home Address
00 00 00 00H
00 00 00 00H
00 00 00 00H
00 00 00 00H
A11-Session Update
00 00 00 00H
A11-Session Update Acknowledge
00 00 00 00H
8
9
TIA-2001.7-C
47 Section 4
4.2.5 Home Agent 1
This element identifies the IPv4 address of the PDSN that terminates the A10 connection. 2
The structure of the element conforms to [19] and is shown below. 3
4.2.5 Home Agent
0 1 2 3 4 5 6 7 Octet
(MSB) Home Agent 1
2
3
(LSB) 4
4
5
TIA-2001.7-C
Section 4 48
4.2.6 Care-of-Address 1
This element identifies the IPv4 address of the PCF that terminates the A10 connection. 2
The structure of the element conforms to [19] and is shown below. 3
4.2.6 Care-of-Address
0 1 2 3 4 5 6 7 Octet
(MSB) Care-of-Address 1
2
3
(LSB) 4
4
TIA-2001.7-C
49 Section 4
4.2.7 Identification 1
This element is used by the PCF and the PDSN for matching the A11-Registration 2
Request messages with A11-Registration Reply messages, A11-Registration Update 3
messages with A11-Registration Acknowledge messages, and A11-Session Update 4
messages with A11-Session Update Acknowledge messages. It also protects against 5
replay attacks using timestamps in the information element. The PCF and the PDSN 6
should have access to an accurate time-of-day clock. The margin of error should be a 7
configurable parameter. Refer to section 5.6, [19], for more details. The structure of the 8
element conforms to [19] and is shown below. 9
4.2.7 Identification
0 1 2 3 4 5 6 7 Octet
(MSB) Identification 1
2
3
4
5
6
7
(LSB) 8
10
11
TIA-2001.7-C
Section 4 50
4.2.8 Code 1
This element identifies the result of processing an A11-Registration Request message. 2
The element includes codes from [19] and is shown below. 3
4.2.8 Code
0 1 2 3 4 5 6 7 Octet
Code 1
The supported Code values are listed in Table 4.2.8-1. 4
Table 4.2.8-1 A11 Code Values 5
Hex
Value
Decimal
Value
Code
00H 0 Registration Accepted
09H 9 Reserved
80H 128 Registration Denied reason unspecified
81H 129 Registration Denied administratively prohibited
82H 130 Registration Denied insufficient resources
83H 131 Registration Denied PCF failed authentication
85H 133 Registration Denied identification mismatch
86H 134 Registration Denied poorly formed request
88H 136 Registration Denied unknown PDSN address
89H 137 Registration Denied requested reverse tunnel unavailable
8AH 138 Registration Denied reverse tunnel is mandatory and T bit not set
8DH 141

Registration Denied unsupported Vendor ID or unable to interpret
Application Type or Application Sub Type in the CVSE sent by the PCF
to the PDSN
6
TIA-2001.7-C
51 Section 4
4.2.9 Status 1
This element identifies the result of processing an A11-Registration Update message or 2
an A11-Session Update message. 3
4.2.9 Status
0 1 2 3 4 5 6 7 Octet
Status 1
The supported Status values are listed in Table 4.2.9-1. 4
Table 4.2.9-1 A11 Status Values 5
Hex
Value
Decimal
Value
A11 Status
0 0 Update Accepted
80H 128 Update Denied reason unspecified
83H 131 Update Denied sending node failed authentication
85H 133 Update Denied identification mismatch
86H 134 Update Denied poorly formed Registration Update
C9H 193 Update Denied Session parameters not updated
6
7
TIA-2001.7-C
Section 4 52
4.2.10 Mobile-Home Authentication Extension 1
This element is present in all A11-Registration Request and A11-Registration Reply 2
messages. This element marks the end of the authenticated data in these messages. The 3
structure of the extension conforms to [19] and is shown below. 4
4.2.10 Mobile-Home Authentication Extension
0 1 2 3 4 5 6 7 Octet
A11 Element Identifier (Type) 1
Length 2
(MSB) SPI 3
4
5
(LSB) 6
(MSB) Authenticator 7

(LSB) 22
Type: 5
20H. 6
Length: 7
Length field. This field is set to 4 plus the number of bytes in the 9
authenticator. 10
SPI: 11
This four octet field is set to the Security Parameter Index, as described 12
in section 1.6, in . 13
Authenticator: 14
For keyed-MD-5 authentication, the Authenticator field is set to the 15
128-bit message digest value obtained by applying the keyed-MD-5 16
algorithm in the prefix+suffix mode on the protected fields. Refer to 17
section 1.9 for details. The default authenticator algorithm shall also 18
protect the SPI value. 19
20
TIA-2001.7-C
53 Section 4
4.2.11 Registration Update Authentication Extension 1
This element is present in all A11-Registration Update, A11-Registration Acknowledge, 2
A11-Session Update and A11-Session Update Acknowledge messages. This element 3
marks the end of the authenticated data in these messages. 4
4.2.11 Registration Update Authentication Extension
0 1 2 3 4 5 6 7 Octet
Length 2
(MSB) 3
SPI 4
5
(LSB) 6
(MSB) 7
Authenticator

(LSB) 22
Type: 5
28H 6
Length: 7
Length field. This field is set to 4 plus the number of bytes in the 9
authenticator. 10
SPI: 11
This four octet field is set to the Security Parameter Index, as described 12
in section 1.6, in . 13
Authenticator: 14
For keyed-MD-5 authentication, the Authenticator field is set to the 15
128-bit message digest value obtained by applying the keyed-MD-5 16
algorithm in the prefix+suffix mode on the protected fields. Refer to 17
section 1.9 for details. The default authenticator algorithm shall also 18
protect the SPI value. 19
20
TIA-2001.7-C
Section 4 54
4.2.12 Session Specific Extension 1
This element is present in all A11-Registration Request, A11-Registration Reply, A11- 2
Registration Update, A11-Registration Acknowledge, A11-Session Update and A11- 3
Session Update Acknowledge messages. This element includes the mobile identity and 4
session specific information. 5
4.2.12 Session Specific Extension
0 1 2 3 4 5 6 7 Octet
Length 2
(LSB) 4
(MSB) 5
Key 6
7
(LSB) 8
Reserved 9
Reserved Session ID Ver 10
(MSB) MN Session Reference Id 11
(LSB) 12
(MSB) MSID Type 13
(LSB) 14
MSID Length 15
Identity Digit 1 Odd/Even Indicator 16

Identity Digit N+1 Identity Digit N Variable
Type: 6
27H 7
Length: 8
Protocol Type: 10
This two octet field identifies the type of the link layer 11
protocol/network layer protocol in use at the mobile node. The 12
supported Protocol Type values are listed below: 13
TIA-2001.7-C
55 Section 4
Table 4.2.12-1 A11 Protocol Type Values 1
Protocol Type Value
Unstructured Byte
Stream
88 81H
Key: 2
This field indicates to the receiver the value to use in the GRE header 3
Key field when sending traffic frames on the A10 connection. Refer to 4
[23] and [24]. 5
Reserved: 6
This field is not used at present. It is set to zero by the sending entity 7
and ignored by the receiving entity. 8
Session ID Ver: 9
This field is used to negotiate the Session Identifier Version to be used. 10
A one step negotiation is used where the initiating entity (the PCF) 11
indicates the highest version it supports, and the replying entity (the 12
PDSN) indicates the highest version it supports that is less than or 13
equal to the version received from the initiating entity. 14
If the negotiated Session Identifier Version is 0, the replying entity 15
shall send the same Key value received by the initiating entity. 16
If the negotiated Session Identifier Version is 1, the replying entity 17
may select a Key value different from the one received from the 18
initiating entity. 19
Values greater than 1 are reserved. 20
MN Session Reference ID: 21
This field is used to uniquely identify a packet data service instance in 22
the MS. The PCF shall set the MN Session Reference ID to the SR_ID 23
value received from the MS for a particular packet data service 24
instance. 25
MSID Type: 26
This field indicates the type of the address used by the mobile node. 27
The field is coded as shown in Table 4.2.12-2. Note only the least 28
significant bits are shown, all other bits are set to zero. 29
010 Reserved
101 Reserved
110 IMSI
MSID Length: 31
MSID Length field. 33
Odd/Even Indicator: 34
This field is set to 0000 for an even number of identity digits and to 35
0001 for an odd number of identity digits. 36
TIA-2001.7-C
Section 4 56
Identity Digits: 1
The identity digits are coded as follows: 2
The International Mobile Subscriber Identifier fields are coded using 3
BCD coding format. If the number of identity digits is even then bits 0 4
to 3 of the last octet shall be filled with an end mark coded as 1111. 5
6
TIA-2001.7-C
57 Section 4
4.2.13 Critical Vendor/Organization Specific Extension (CVSE) 1
This element may be present in the A11-Registration Request message to convey the 2
accounting information from the PCF to the PDSN. This element may also be present in 3
the A11-Registration Request message to convey the Mobility Event Indicator from the 4
PCF to the PDSN during dormant handoffs and active/hard handoffs. The coding format 5
of the CVSE defined herein conforms to [22]. 6
This element may be present in the A11-Registration Reply message to convey the Data 7
Available Indicator (DAI) from the PDSN to the PCF during handoff. 8
This element reflects Application Type and Application Sub-Types supported in IOS 9
v4.0. New Application Type or Application Sub-Types shall be added to the Normal 10
Vendor/Organization Specific Extension (NVSE) (refer to section 4.2.14). 11
When used to convey the accounting information, the accounting records are contained 12
within the Application Data field of this element. The accounting records conveyed from 13
the PCF to the PDSN conform to the specifications in [8]. Each application type 01H 14
(Accounting) CVSE contains one and only one airlink record. For transmission of 15
multiple airlink records in the same A11-Registration Request message, multiple 16
instances of accounting type CVSEs are used. 17
4.2.13 Critical Vendor/Organization Specific Extension (CVSE)
0 1 2 3 4 5 6 7 Octet
Reserved 2
(MSB) Length 3
(LSB) 4
(MSB) 3GPP2 Vendor ID 5
6
7
(LSB) 8
Application Type 9
Application Sub Type 10
(MSB) Application Data 11
12

(LSB) k
Note that the Application Type and the Application Sub Type together correspond to the 18
Vendor- CVSE-Type as defined in [22]. 19
Type: 20
26H 21
TIA-2001.7-C
Section 4 58
Length: 1
Length field. 3
3GPP2 Vendor ID: 4
00 00 15 9FH 5
Application Type: 6
This field indicates the type of application to which the extension 7
relates. The supported values are listed in Table 4.2.13-1. 8
Application Sub Type: 9
This one octet field indicates the Application sub-type within the 10
Application Type. The supported values are listed in Table 4.2.13-1. 11
Table 4.2.13-1 Application Type and Sub Type 12
Application Type Application Sub Type
Name Value Name Value
Used in Message Reference
RADIUS 01H A11-Registration Request 3.1
DIAMETER 02H Not used
Accounting 01H
Mobility 01H A11-Registration Request 3.1 Mobility Event Indicator 02H
Data Ready to Send 01H A11-Registration Reply 3.2 Data Available Indicator 03H
Application Data: 13
For Application Type 01H (Accounting), this field contains all the 14
accounting parameters contained in one airlink record conveyed from 15
the PCF to the PDSN as specified in [8]. In this version of this 16
standard, only Application Sub Type = RADIUS is used. Each of the 17
accounting parameters is structured in the format of RADIUS attributes 18
specified in [20] and [21], refer to the following text for more details. 19
For Application Type 02H (Mobility Event Indicator), this field is zero 20
bytes in length. 21
For Application Type 03H (Data Available Indicator), this field is zero 22
bytes in length. 23
24
25
TIA-2001.7-C
59 Section 4
For Application Type 01H (Accounting), all 3GPP2 specific Accounting Parameters are 1
coded using RADIUS Vendor-Specific-Attribute format as follows: 2
1 2 3 4 5 6 7 8 Octet
Type 1
Length 2
(MSB) 3GPP2 Vendor-Id 3
4
5
(LSB) 6
Vendor-Type 7
Vendor-Length 8
(MSB) Vendor-Value (variable number of octets) 9
10

(LSB) k
Type: 3
1AH 4
Length: 5
Type (1 octet) + Length (1 octet) + 3GPP2 Vendor Id (4 octets) + { 6
Vendor-Type (1 octet), Vendor-Length (1 octet), Vendor-Value 7
(variable octets) of the 3GPP2 specific parameter comprising the airlink 8
record being coded.} 9
Vendor ID: 10
00 00 15 9FH 11
Vendor Type: 12
Sub-Type value from the Airlink Record tables below. 13
Vendor-Length: 14
Vendor-Type (1 octet) + Vendor-Length (1 octet) + Payload Length (in 15
octets) from the Airlink Record tables below. 16
Vendor-Value: 17
Payload of the accounting parameter. 18
19
TIA-2001.7-C
Section 4 60
For Application Type 01H (Accounting) all RADIUS specific Airlink Record Parameters 1
are coded as follows: 2
3
1 2 3 4 5 6 7 8 Octet
Type 1
Length 2
(MSB) Value (variable number of octets) 3
4

(LSB) k
Type: 4
Type value from the Airlink Record tables below. 5
Length: 6
Type (1 octet) + Length (1 octet) + Payload Length (in octets) from the 7
Airlink Record tables below. 8
Value: 9
Payload of the accounting parameter. 10
Airlink Record Fields Tables: 11
Table 4.2.13-2 R-P Session Setup Airlink Record (Connection Setup) 12
Parameter Type Sub-
Type
Max. Payload
Length (octet)
Format
Airlink Record Type = 1 (Setup) 26 40 4 Integer
R-P Connection ID 26 41 4
Integer
2

Airlink Sequence number 26 42 4 Integer
MSID 31 N/A 15
String
3

Serving PCF 26 9 4 Ip-addr
BSID 26 10 12
String
4

ESN 26 52 15
String
5

2
This parameter shall be set to the same value as the Key field in the Session Specific
Extension information element sent in the A11-Registration Request message.
3
Each digit is encoded as an ASCII character.
4
A number formed from the concatenation of SID+NID+ Cell Identifier (Type 2),
where each item is encoded using four hexadecimal upper case ASCII characters.
5
The string consists of the 8-bit ASCII encoding of the upper case hexadecimal
representation of the ESN.
TIA-2001.7-C
61 Section 4
Table 4.2.13-3 Active Start Airlink Record 1
Parameter Type Sub-
Type
Max. Payload
Length (octet)
Format
Airlink record type = 2 (START) 26 40 4 Integer
R-P Connection ID 26 41 4 Integer
User Zone 26 11 4 Integer
Forward FCH Mux Option 26 12 4 Integer
Reverse FCH Mux Option 26 13 4 Integer
Service Option 26 16 4 Integer
Forward Traffic Type 26 17 4 Integer
Reverse Traffic Type 26 18 4 Integer
FCH Frame Size 26 19 4 Integer
Forward FCH RC 26 20 4 Integer
Reverse FCH RC 26 21 4 Integer
DCCH Frame Size (0/5/20 ms) 26 50 4 Integer
Forward DCCH Mux Option 26 84 4 Integer
Reverse DCCH Mux Option 26 85 4 Integer
Forward DCCH RC 26 86 4 Integer
Reverse DCCH RC 26 87 4 Integer
Airlink Priority 26 39 4 Integer
2
Table 4.2.13-4 Active Stop Airlink Record 3
Parameter Type Sub-
Type
Max. Payload
Length (octet)
Format
Airlink record type = 3 (STOP) 26 40 4 Integer
Active Connection Time in Seconds 26 49 4 Integer
4
5
TIA-2001.7-C
Section 4 62
Table 4.2.13-5 SDB Airlink Record 1
Parameter Type Sub-
Type
Max. Payload
Length (octet)
Format
Airlink record type = 4 (SDB) 26 40 4 Integer
Mobile Orig./Term. Indicator 26 45 4 Integer
SDB Octet Count 26 31/32
6
4 Integer
An example coding of the Active Stop Airlink Record within the CVSE element is 2
illustrated below: 3
0 1 2 3 4 5 6 7 Octet
A11 Element Identifier = 26H 1
Reserved 2
(MSB) Length = 36H 3
(LSB) 4
6
7
(LSB) 8
Application Type = 01H 9
Application Sub Type = 01H 10
Parameter Name: Airlink Record Type =3 (Active Stop)
Type = 1AH 11
Length = 0CH 12
(MSB) 3GPP2 Vendor-Id = 00 00 15 9FH 13
14
15
(LSB) 16
Vendor-Type = 28H 17
Vendor-Length = 06H 18
MSB Vendor-Value = 3 (Active Stop) 19
20
21
(LSB) 22

6
Subtype 31 is for terminating SDB octet count, subtype 32 is for originating SDB
octet count.
TIA-2001.7-C
63 Section 4
0 1 2 3 4 5 6 7 Octet
Parameter Name: R-P-Session I D
Type = 1AH 23
Length = 0CH 24
26
27
(LSB) 28
Vendor-Type = 29H 29
(MSB) Vendor-Value = PCF Session Identifier 31
32
33
(LSB) 34
Parameter Name: Airlink Sequence Number
Type = 1AH 35
Length = 0CH 36
38
39
(LSB) 40
Vendor-Type = 2AH 41
(MSB) Vendor-Value = Sequence Number 43
44
45
(LSB) 46
Parameter Name: Active Connection Time
Type = 1AH 47
Length = 0CH 48
50
51
(LSB) 52
Vendor Type = 31H 53
Length = 06H 54
(MSB) Value = Active Connection Time (in seconds) 55
TIA-2001.7-C
Section 4 64
0 1 2 3 4 5 6 7 Octet
56
57
(LSB) 58
1
TIA-2001.7-C
65 Section 4
4.2.14 Normal Vendor/Organization Specific Extension (NVSE) 1
This element may be included in the A11-Registration Request, A11-Registration Reply, 2
A11-Registration Update, and A11-Session Update messages to convey information 3
between the PCF and the PDSN. Any new Application Types or Application Sub-Types 4
supported after IOS v4.0 shall be added to this element. The coding format of the NVSE 5
defined herein conforms to [22]. 6
This element may be included in the A11-Registration Request message to convey the 7
Previous and Current Access Network Identifiers (PANID, CANID) and Anchor P-P 8
Address for fast handoff to the PDSN. 9
This element may be included in A11-Registration Reply or A11-Registration Request 10
messages when the PCF establishes the A10 connection with the selected PDSN. If the 11
receiver does not recognize the NVSE Vendor-ID or the NVSE Application Type or 12
Application Sub Type, it shall ignore the NVSE and process the remainder of the 13
message to the extent possible. 14
This element may be included in the A11-Registration Request message to send the All 15
Dormant Indicator for the case of an MS in fast handoff. The serving PCF shall send the 16
All Dormant Indicator to its supporting PDSN when all service instances for the MS 17
become dormant. The PCF shall send this indication in the same message as the Active 18
Stop Airlink Record for the last service instance that becomes dormant. 19
This element may be included in the A11-Registration Update message to indicate the 20
reason the PDSN initiated the release of the packet data session. 21
This element may be included in the A11 Registration Reply or A11-Session Update 22
messages to change the value of a session parameter. 23
This element may be included in the A11-Registration Request message to indicate the 24
service option of a service instance. 25
This element may be included in the A11-Session Update message to indicate a PDSN 26
Identifier. 27
4.2.14 Normal Vendor/Organization Specific Extension (NVSE)
0 1 2 3 4 5 6 7 Octet
Length 2
(MSB) Reserved 3
(LSB) 4
(MSB) 3GPP2 Vendor ID 5
6
7
(LSB) 8
Application Type 9
Application Sub Type 10
(MSB) Application Data 11
TIA-2001.7-C
Section 4 66
4.2.14 Normal Vendor/Organization Specific Extension (NVSE)
0 1 2 3 4 5 6 7 Octet
12

(LSB) k
Note that the Application Type and the Application Sub Type together correspond to the 1
Vendor- NVSE-Type as defined in [22]. 2
Type: 3
86H 4
Length: 5
Length field. 7
3GPP2 Vendor ID: 8
00 00 15 9FH. 9
Application Type: 10
This field indicates the type of application to which the extension 11
relates. The supported values are listed in Table 4.2.14-1. 12
13
TIA-2001.7-C
67 Section 4
Application Sub Type: 1
This one octet field indicates the Application sub-type within the 2
Application Type. The supported values are listed in Table 4.2.14-1. 3
Table 4.2.14-1 Application Sub Type 4
Application Type Application Sub Type
Name Value Name Value
Used in Message Reference
ANID 01H A11-Registration Request 3.1 Access Network
Identifiers (ANID)
04H
Anchor P-P Address 01H A11-Registration Request
3.1
3.2
PDSN Identifier 05H
All Dormant Indicator 01H A11-Registration Request 3.1 Indicators 06H
PDSN CODE 01H A11-Registration Update 3.3 PDSN Code 07H
RN-PDIT 01H A11-Registration Reply
A11-Session Update
3.2
3.5
Always-On 02H A11-Registration Reply
A11-Session Update
3.2
3.5
Session Parameter 08H
Service Option Value 01H A11-Registration Request 3.1 Service Option 09H
Application Data: 5
For Application Type 04H (Access Network Identifiers), this field 6
contains the PANID of the source PCF in the PANID field (octets 11- 7
15) and the ANID of the target PCF in the CANID field (octets 16-20). 8
The PANID and CANID fields are formatted as specified for the 9
Access Network Identifiers element (refer to [16]) from octet 3-7. If 10
PANID information is not available, it shall be coded as all zeros. The 11
CANID field shall be populated with the PCFs own ANID. 12
For Application Type 05H (PDSN Identifier), this field contains an 13
IPv4 address in octets 11-14. This is the Anchor P-P Address. The 14
Anchor P-P Address is the P-P interface address (refer to [8]) of the 15
anchor PDSN. 16
For Application Type 06H (Indicators), this field contains the All 17
Dormant Indicator in octets 11-12. A value of 00 00H indicates that 18
all MS packet data service instances are dormant. All other values are 19
reserved. 20
For Application Type 07H (PDSN CODE), the field contains a PDSN 21
Code indicating the reason the packet data connection is being released 22
TIA-2001.7-C
Section 4 68
by the PDSN. The PDSN Code values and their meanings are listed in 1
Table 4.2.14-2. 2
Table 4.2.14-2 PDSN Code Values 3
Hex
Value
Decimal
Value
PDSN Code
C1H 193 Connection Release - reason unspecified
C2H 194 Connection Release - PPP time-out
C3H 195 Connection Release - registration time-out
C4H 196 Connection Release - PDSN error
C5H 197 Connection Release - inter-PCF handoff
C6H 198 Connection Release - inter-PDSN handoff
C7H 199 Connection Release - PDSN OAM&P intervention
C8H 200 Connection Release - accounting error
CAH 202 Connection Release user (NAI) failed authentication
4
For Application Type 08H (Session Parameter) and Application Sub- 5
Type 01H, the Application Data field contains the Radio Network 6
Packet Data Inactivity Timer (RN-PDIT) value in seconds. This field is 7
one octet in length and has range 01HFFH, corresponding to timer 8
values 1255 seconds. For Application Sub Type 02H (Always-on 9
indicator), the Application Data is zero bytes in length. 10
For Application Type 09H (Service Option), this field contains the 11
Service Option value for the service instance associated with the A10 12
connection. 13
14
TIA-2001.7-C
69 Section 4
For Application Type 09H, the Application Data field is coded as follows: 1
0 1 2 3 4 5 6 7 Octet
(LSB) 2
2
Service Option: 3
Service Option
Value (hex)

Description
0021H 3G High Speed Packet Data
003CH Link Layer Assisted Header Removal
003DH Link Layer Assisted RObust Header Compression
5
6
TIA-2001.7-C
Section 4 70
1
3
4
5
6
7
TIA-2001.7-C
71 Section 5
5.1 Timer Values 2
Timer
Name
Default
Value
(seconds)
Range of
Values
(seconds)

Granularity
(seconds)
Section
Reference
T
presetup

10 0-255 1 5.2.4
T
regreq

1 1 5 1 5.2.1
T
regupd

1 1 5 1 5.2.2
T
rp

1800 60 65,534 1 5.2.3
T
sesupd

3 1-10 1 5.2.5
5.2.1 T
regreq
6
The PCF timer T
regreq
is started when the A11-Registration Request message is sent, and 7
stopped when the A11-Registration Reply message is received. 8
5.2.2 T
regupd
9
The PDSN timer T
regupd
is started when the A11-Registration Update message is sent, 10
and stopped when the A11-Registration Acknowledge message is received. 11
5.2.3 T
rp
12
This configurable parameter represents the longest lifetime that the PCF is willing to 13
accept before registration for an A10 connection is considered expired. It is used to set 14
the Lifetime parameter in the A11-Registration Request message. 15
5.2.4 T
presetup
16
This configurable parameter represents the longest lifetime that the PCF is willing to 17
accept before a fast handoff pre-registration for an A10 connection is considered expired. 18
It is used to set the Lifetime parameter in the A11-Registration Request message. 19
5.2.5 T
sesupd
20
The PDSN timer T
sesupd
is used when a packet data session update occurs. It is set when 21
the PDSN sends the A11-Session Update message with any new or updated packet data 22
session parameters, and stopped when an A11-Session Update Acknowledge message is 23
received from the PCF indicating the results of processing the new session parameters. 24
TIA-2001.7-C
Section 5 72
1
2

Tia 2001 C

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Tia 2001 C

Uploaded by

Copyright:

Available Formats

TIA

Access Network Interfaces............................................. 14 4

is a registered trademark of the Telecommunications Industry

Access Network Interfaces. 17

Access Network Interfaces. 24

Standards for Spread 33

Spread Spectrum Systems, May 2002. 40

Spread Spectrum Systems, May 2002. 42

Wireless IP Network Standard, to be published. 4

Standards for Spread Spectrum 27

Spread Spectrum Systems, May 2002. 34

) public cellular radio telecommunications 47

Access Network Interfaces 8

is a registered trademark of the Telecommunications Industry

Short Data Burst from an MS to the PDSN ......................................... 193 23

Short Data Burst from the PDSN to the MS ............................... 195 24

is a registered trademark of the Telecommunications Industry Association

Standards for Spread 17

Spread Spectrum Systems, May 2002. 24

Spread Spectrum Systems, May 2002. 26

Wireless IP Network Standard, to be published. 30

Standards for Spread Spectrum 46

Spread Spectrum Systems, May 2002. 2

Spread Spectrum Systems, May 2002. 4

). Intergeneration handoffs are described in section 2.19.5. 15

MS that supports CCPD Mode. A CCPD capable 21

. To use Flex Rate, the MS is required 3

1X) MS is re-directed from the cdma2000

system to another cdma2000

system during packet data services. In this 35

hard handoff to one or more cells in the 5

system to another cdma2000

system. In this scenario, the MS successfully 38

TCH establishment procedure may occur in parallel with the A8 connection 28

TCH establishment procedure has completed, the BS updates the 32

TCH establishment procedure is completed. The BS informs the 7

Short Data Burst from an MS to the PDSN 5

Short Data Burst to the network on a reverse common 6

Short Data Burst received by sending a Layer 8

Short Data Burst from the PDSN to the MS 2

hard handoff to one or more cells in the 11

hard handoff to one or more cells in the 13

hard handoff to one or more cells in the 10

MSs, the service option can be included in the General or 23

1X systems, there are three types of service redirection messages; SRM 12

Standards for Spread 31

is a registered trademark of the Telecommunications Industry

Spread Spectrum Systems, May 2002. 2

Spread Spectrum Systems, May 2002. 4

Spread Spectrum Systems, May 2002. 6

Standards for Spread Spectrum 47

Spread Spectrum Systems, May 2002. 4

Spread Spectrum Systems, May 2002. 6

Spread Spectrum Standards, Release C, January 2002. 35

paging channel slots monitored by the MS. 11

system. If this element is absent, then it is assumed that the MS is 9

systems, if this element is absent, then it is assumed 25

systems when the ESN is received from the 9

handoffs and shall 18

. It lists the cdma2000

channel(s) for each cell listed in the Cell 14

non-negotiable service configuration record to 22

3X. It lists the cdma2000