A.S0007-0 v1.0

SP-3-0009 (TIA/EIA/IS-878)
June 14, 2001 1xEV-DO IOS Ballot Version
3GPP2 A.S0007
Ballot Version
Date: June 14, 2001
2 1xEV-DO Inter-Operability Specification (IOS) for

3 CDMA 2000 Access Network Interfaces
4 Release 0
5 (Ballot Version)
6
COPYRIGHT © 2001, 3GPP2

3GPP2 and its Organizational Partners claim copyright in this document and individual Organizational
Partners may copyright and issue documents or standards publications in individual Organizational
Partner's name based on this document. Requests for reproduction of this document should be directed to
the 3GPP2 Secretariat at secretariat@3gpp2.org. Requests to reproduce individual Organizational
Partner's documents should be directed to that Organizational Partner. See www.3gpp2.org for more
information.
SP-3-0009 (TIA/EIA/IS-878)
2 1xEV-DO Inter-Operability Specification (IOS) for CDMA

3 2000 Access Network Interfaces
4 SP-3-0009
5 Ballot Version: June, 2001
SP-3-0009 (TIA/EIA/IS-878)
1 Table of Contents
2 Foreword........................................................................................................................................................v
3 1 Introduction .................................................................................................................................. 1-1
4 1.1 Scope ............................................................................................................................................ 1-1
5 1.2 1xEV-DO IOS Architecture Reference Model............................................................................. 1-1
6 1.3 References .................................................................................................................................... 1-2
7 1.4 Terminology ................................................................................................................................. 1-2
8 1.4.1 Acronyms ..................................................................................................................................... 1-2
9 1.4.2 Definitions .................................................................................................................................... 1-3
10 1.5 Document Convention.................................................................................................................. 1-4
11 1.6 Compatibility with IS-2001 Standards ......................................................................................... 1-4
12 1.7 1xEV-DO IOS Assumptions ........................................................................................................ 1-4
13 2 1xEV-DO IOS Call Flows............................................................................................................ 2-1
14 2.1 AT Originates 1xEV-DO Session................................................................................................. 2-1
15 2.1.1 AT Originates 1xEV-DO Session -Successful Authentication..................................................... 2-1
16 2.1.2 AT Originates 1xEV-DO Session - Unsuccessful Authentication ............................................... 2-3
17 2.1.3 AT Originates with a Pre-existing 1xEV-DO Session.................................................................. 2-5
18 2.2 Data Delivery................................................................................................................................ 2-6
19 2.2.1 Data Delivery - AT Terminated.................................................................................................... 2-6
20 2.2.2 Data Delivery - AT Originated..................................................................................................... 2-7
21 2.3 Connection Tear-Down ................................................................................................................ 2-7
22 2.3.1 Connection Tear-Down on 1xEV-DO Network - Initiated by the AT. ........................................ 2-7
23 2.3.2 Connection Tear-Down on 1xEV-DO Network - Initiated by the AN/PCF................................. 2-8
24 2.4 Session Tear-Down....................................................................................................................... 2-9
25 2.4.1 Session Tear-Down - Initiated by the AT.................................................................................... 2-9
26 2.4.2 A10 Tear-Down - Initiated by the PDSN ................................................................................... 2-10
27 2.4.3 Radio Session Tear-Down - Initiated by the AN........................................................................ 2-11
28 2.5 Dormant Handoff of 1xEV-DO AT between ANs - Served by the Same PDSN....................... 2-12
29 2.5.1 AN-AN Dormant Handoff with Successful Retrieval of Session Information........................... 2-12
30 2.5.2 Dormant AN-AN Handoff with Session Information Transfer Failure...................................... 2-14
31 3 1xEV-DO and IS-2000 IOS Transition Call Flows...................................................................... 3-1
32 3.1 Dormant/Idle (Voice or Packet) Cross System Handoff - Served by the Same PDSN. ............... 3-1
33 3.1.1 Dormant/Idle IS-2000 Handoff to Idle 1xEV-DO - Existing Session .......................................... 3-1
34 3.1.2 Dormant/Idle IS-2000 Handoff to Idle 1xEV-DO - New Session................................................ 3-3
35 3.1.3 Idle 1xEV-DO Handoff to Dormant/Idle IS-2000........................................................................ 3-5
36 3.2 AT Terminated Voice Call During Active 1xEV-DO Data Session ............................................ 3-7
i
SP-3-0009 (TIA/EIA/IS-878)
1xEV-DO IOS Ballot Version June 14, 2001
1 3.2.1 AT Terminated Voice Call During Active 1xEV-DO Data Session (Intra-PDSN/Inter-PCF)..... 3-7
2 3.2.2 MS/AT Terminated Voice Call During Active 1xEV-DO Data Session (Intra-PCF).................. 3-9
3 3.3 AN Change, Active IS-2000 (Packet) to Active 1xEV-DO (Cross System - DO)..................... 3-11
4 3.4 Status Management Supported by Feature Invocation ............................................................... 3-13
5 4 1xEV-DO IOS Interfaces.............................................................................................................. 4-1
6 4.1 A8-A9 (AN - PCF) Interface ........................................................................................................ 4-1
7 4.2 A10-A11 (PCF - PDSN) Interface................................................................................................ 4-1
8 4.3 A12 (AN - AN AAA) Interface.................................................................................................... 4-1
9 4.3.1 PPP Session .................................................................................................................................. 4-2
10 4.3.1.1 Establishment.............................................................................................................. 4-2
11 4.3.1.2 Termination ................................................................................................................ 4-2
12 4.3.1.3 Authentication ............................................................................................................ 4-2
13 4.3.2 RADIUS Support.......................................................................................................................... 4-2
14 4.3.3 Radius Server Requirements ........................................................................................................ 4-3
15 4.4 A13 (AN - AN) Interface.............................................................................................................. 4-4
16 4.4.1 A13 Interface Network/Transport Protocol Specification ............................................................ 4-4
17 4.4.2 A13 Interface Procedures ............................................................................................................. 4-5
18 4.4.2.1 A13-Session Information Request.............................................................................. 4-5
19 4.4.2.1.1 Successful Operation.................................................................................................. 4-5
20 4.4.2.1.2 Failure Operation........................................................................................................ 4-5
21 4.4.2.2 A13-Session Information Response ........................................................................... 4-5
24 4.4.2.3 A13-Session Information Confirm ............................................................................. 4-6
27 4.4.2.4 A13-Session Information Reject................................................................................. 4-6
30 4.4.3 A13 Message Definitions ............................................................................................................. 4-7
31 4.4.3.1 A13-Session Information Request Message ............................................................... 4-7
32 4.4.3.2 A13-Session Information Confirm Message .............................................................. 4-8
33 4.4.3.3 A13-Session Information Reject Message.................................................................. 4-8
34 4.4.3.4 A13-Session Information Response Message............................................................. 4-9
35 4.4.4 A13 Information Element Definitions ........................................................................................ 4-11
36 4.4.4.1 Information Element Identifiers ............................................................................... 4-11
37 4.4.4.2 A13 Message Type ................................................................................................... 4-11
ii
SP-3-0009 (TIA/EIA/IS-878)
1 4.4.4.3 Unicast Access Terminal Identifier (UATI). ............................................................ 4-11

2 4.4.4.4 Security Layer Packet ............................................................................................... 4-12
3 4.4.4.5 SectorID.................................................................................................................... 4-12
4 4.4.4.6 Cause ........................................................................................................................ 4-13
5 4.4.4.7 Mobile Identity (MN ID) .......................................................................................... 4-13
6 4.4.4.8 PDSN IP Address ..................................................................................................... 4-14
7 4.4.4.9 Access Network Identifiers....................................................................................... 4-14
8 4.4.4.10 AN State Information Record................................................................................... 4-15
9 5 1xEV-DO IOS Timer Definitions................................................................................................. 5-1
10 5.1 Timer Tairdrop .................................................................................................................................. 5-1
11 Annex A Informative 1xEV-DO IOS Phase 1+ Annex......................................................................... A-1
12 A.1 1xEV-DO IOS Phase 1+ Architecture Reference Model ............................................................ A-1
13 Annex B A8-A9 (AN - PCF) Interface Change Text .............................................................................B-1
14 Annex C A10-A11 (AN/PCF - PDSN) Interface Change Text..............................................................C-1
15 Annex D A12 RADIUS Attributes........................................................................................................ D-1
16 Annex E Revision History......................................................................................................................E-1
17
18
iii
SP-3-0009 (TIA/EIA/IS-878)
1 Table of Figures
2 Figure 1.2-1 1xEV-DO IOS Phase 1 Architecture Reference Model ............................................... 1-1
3 Figure 2.1.1-1 Initial AT Origination (with Session Establishment and Key Exchange) .................... 2-1
4 Figure 2.1.2-1 Initial AT Origination (with Session Establishment and Key Exchange) .................... 2-3
5 Figure 2.1.3-1 AT Origination (Session is Already Established) ........................................................ 2-5
6 Figure 2.2.1-1 AT Terminated Data Delivery...................................................................................... 2-6
7 Figure 2.3.1-1 AT Initiated Connection Tear-Down ........................................................................... 2-7
8 Figure 2.3.2-1 AN/PCF Initiated Connection Tear-Down................................................................... 2-8
9 Figure 2.4.1-1 AT Initiated Session Tear-Down.................................................................................. 2-9
10 Figure 2.4.2-1 PDSN Initiated A10 Tear-Down ................................................................................ 2-10
11 Figure 2.4.3-1 AN Initiated Radio Session Tear-Down..................................................................... 2-11
12 Figure 2.5.1-1 Inter-PCF/Intra-PDSN Dormant AN-AN HO - Successful Operation....................... 2-12
13 Figure 2.5.2-1 Inter-PCF/Intra PDSN Dormant AN-AN HO - Session Info Transfer Failure .......... 2-14
14 Figure 3.1.1-1 MS/AT Idle Handoff from IS-2000 to 1xEV-DO - Existing Session .......................... 3-1
15 Figure 3.1.2-1 MS/AT Idle Handoff from IS-2000 to 1xEV-DO - New Session ................................ 3-3
16 Figure 3.1.3-1 MS/AT Idle Handoff from a 1xEV-DO to an IS-2000 System.................................... 3-5
17 Figure 3.2.1-1 Voice Call Termination During Active 1xEV-DO Data Session (Inter-PCF) ............. 3-7
18 Figure 3.2.2-1 Voice Call Termination During Active 1xEV-DO Data Session (Intra-PCF) ............. 3-9
19 Figure 3.3-1 MS/AT Active AN Change from an IS-2000 to a 1xEV-DO System........................ 3-11
20 Figure 3.4-1 Terminal Based Status Management (Using Feature Invocation).............................. 3-13
21 Figure 4.3-1 RADIUS Protocol Reference Model............................................................................ 4-1
22 Figure A.1-1 1xEV-DO IOS Phase 1+ Architecture Reference Model ............................................ A-1
23 Figure D-1 3GPP2 RADIUS Attribute Format.............................................................................. D-1
24
25
26
iv
SP-3-0009 (TIA/EIA/IS-878)
1 Foreword
2 This 1xEV-DO Inter-Operability Specification (IOS) document is based on TIA/EIA/IS-2001-A, the
3 “Inter-Operability Specification (IOS) for CDMA 2000 Access Network Interfaces”. This document
4 describes the protocol and some generic procedures to support the following 1xEV-DO IOS features.
5 Conformance to the IOS may be claimed on a feature-by-feature and/or interface-by-interface basis. If
6 conformance on a given interface is claimed for the 1xEV-DO IOS feature, it shall be supported as
7 defined in this standard.
8 Features:
9 Authentication
10 Data delivery
11 Session handoff between ANs.
12
13
v
SP-3-0009 (TIA/EIA/IS-878)
1 No text.
2
vi
SP-3-0009 (TIA/EIA/IS-878)
1 1 Introduction
2
3 1.1 Scope
4 This specification provides the 1xEV-DO text and call flows for the following scenarios:
5 N AT originates a 1xEV-DO session (including authentication)
6 N 1xEV-DO data delivery (both AT terminated and AT originated)
7 N 1xEV-DO session tear-down on
8 N Idle handoff of 1xEV-DO AT between ANs
9 N Dormant/Idle (voice or packet) IS-2000 handoff to/from Idle 1xEV-DO (cross system)
10 N Active IS-2000 call (packet), AN change to active call on 1xEV-DO system (cross system, data only)
11 This may happen via a dormant handoff
12 N AT terminated voice call during active 1xEV-DO data session
13 N Status Management
14 and definitions for the following 1xEV-DO IOS interfaces:

Interface Description
A8-A9 (AN - PCF) Interface TIA/EIA/IS-2001-A delta text (Annex B)
A10-A11 (PCF - PDSN) Interface TIA/EIA/IS-2001-A delta text (Annex B)
A12 (AN - AN AAA) Interface New 1xEV-DO IOS defined text (Section 4.3)
A13 (AN - AN) Interface New 1xEV-DO IOS defined text (Section 4.4)
15
16 1.2 1xEV-DO IOS Architecture Reference Model

17 The 1xEV-DO IOS messaging and call flows are based on the Architecture Reference Model shown in
18 Figure 1.2-1, 1xEV-DO IOS Phase 1. The 1xEV-DO IOS Phase 1+ Architecture Reference Model is
19 addressed in Annex A.
A8 A10
Source Access
PCF PDSN
Network (AN) A9 A11
Access Air Interface A13 A12 AN AAA

Terminal (AT)
Target Access
Network (AN)
20
21 Figure 1.2-1 1xEV-DO IOS Phase 1 Architecture Reference Model
22
1-1
SP-3-0009 (TIA/EIA/IS-878)
1 1.3 References
2 RFC 1321, MD5 Message-Digest Algorithm, April 1992.
3 RFC 1332, The PPP Internet Protocol Control Protocol (IPCP), May, 1992.
4 RFC 1661, Point-to-Point Protocol, July 1994.
5 RFC 1662, PPP in HDLC-Like Framing, July, 1994.
6 RFC 1750, Randomness Recommendations for Security, December, 1994.
7 RFC 1994, PPP Challenge Handshake Authentication Protocol (CHAP), August, 1996.
8 RFC 2486, The Network Access Identifier, January, 1999.
9 RFC 2784, Generic Routing Encapsulation (GRE), March, 2000.
10 RFC 2865, Remote Authentication Dial In User Service (RADIUS), June, 2000.
11 RFC 2866, RADIUS Accounting, June, 2000.
12 TIA/EIA/IS-856, cdma2000 High Rate Packet Data Air Interface Specification, February, 2001.
13 TIA/EIA/IS-2001, Inter-Operability Specification (IOS) for CDMA 2000 Access Network Interfaces,
14 December, 2000.
15 TIA/EIA/IS-2001-A, Inter-Operability Specification (IOS) for CDMA 2000 Access Network Interfaces,
16 May, 2001.
17
18 1.4 Terminology
19
20 1.4.1 Acronyms
1xEV-DO 1x Evolution - Data Only

AAA Authentication, Authorization and Accounting
AN Access Network
AT Access Terminal
BS Base Station
BSC Base Station Controller
CANID Current Access Network Identifiers
CHAP Challenge Handshake Authentication Protocol
IMSI International Mobile Subscriber Identity
IOS Inter-Operability Specification
IPCP Internet Protocol Control Protocol
LCP Link Control Protocol
MAC Medium Access Control
MEI Mobility Event Indicator
MN ID Mobile Node Identification
MS Mobile Station
MSC Mobile Switching Center
NAI Network Access Identifier
1-2
SP-3-0009 (TIA/EIA/IS-878)
NID Network Identification

PANID Previous Access Network Identifiers
PCF Packet Control Function
PDSN Packet Data Serving Node
PPP Point-to-Point Protocol
PZID Packet Zone Identification
RADIUS Remote Authentication Dial-In User Service
SID System Identification
SKey Session Key
UATI Unicast Access Terminal Identifier
2 1.4.2 Definitions
3 Access Stream The IS-856 stream whose end-points are the Access Terminal and the Access Net-
4 work (radio network). This stream is used for access authentication.
5 Access Network The network equipment providing data connectivity between a packet switched data
6 network (typically the Internet) and the access terminals. An access network is equiv-
7 alent to a base station in an IS-2000 systems.
8 Access Terminal A device providing data connectivity to a user. An access terminal may be connected
9 to a computing device such as a laptop personal computer or it may be a self-contain-
10 ed data device such as a personal digital assistant. An access terminal is equivalent to
11 a mobile station in an IS-2000 systems.
12 AN AAA An entity that performs authentication and authorization functions for the Access
13 Network.
14 Connection A connection is a particular state of the air-link in which the access terminal is
15 assigned a Forward Traffic Channel, a Reverse Traffic Channel and associated
16 Medium Access Control (MAC) Channels. During a single session the access
17 terminal and the access network can open and can close a connection multiple times.
18 Hybrid MS/AT A device capable of operating on both IS-2000 and 1xEV-DO access networks.
19 Mobile Station An entity in the (IS-2000) public cellular radio telecommunications service intended
20 to be used while in motion or during halts at unspecified points. Mobile stations
21 include portable units (e.g., hand-held personal units) and units installed in vehicles.
22 Service Stream The IS-856 stream whose end-points are the Access Terminal and the PDSN. This
23 stream is used for packet data exchange.
24 Session A session refers to a shared state between the access terminal and the access network.
25 This shared state stores the protocols and protocol configurations that were
26 negotiated and are used for communications between the access terminal and the
27 access network. Other than to open a session, an access terminal cannot communicate
28 with an access network without having an open session. The 1xEV-DO session and
29 the A10/A11 connection are not associated with each other. The A10/ A11
30 connection may not be established even if the 1xEV-DO session is established. The
31 1xEV-DO session may not be released even if the A10/A11 connection is released.
32
1-3
SP-3-0009 (TIA/EIA/IS-878)
1 1.5 Document Convention

2 “Shall” and “shall not” identify requirements to be followed strictly to conform to the standard and from
3 which no deviation is permitted. “Should” and “should not” indicate that one of several possibilities is
4 recommended as particularly suitable, without mentioning or excluding others; that a certain course of
5 action is preferred but not necessarily required; or (in the negative form) that a certain possibility or
6 course of action is discouraged but not prohibited. “May” and “need not” indicate a course of action
7 permissible within the limits of the standard. “Can” and “cannot” are used for statements of possibility
8 and capability, whether material, physical, or causal.
9
10 1.6 Compatibility with IS-2001 Standards

11 The 1xEV-DO IOS interface, as defined in this specification, is compatible with a TIA/EIA/IS-2001 or
12 higher release, with the provision that the 1xEV-DO capabilities are the same as those supported by the
13 interoperability specification, for the access network(s) in use. For example, when inter-operating with a
14 TIA/EIA/IS-2001 system, the portions of this specification related to concurrent services and support for
15 Previous/Current Access Node Identifies (PANID/CANID) are not applicable.
16 Note: When the procedures between TIA/EIA/IS-95-B / IS-2000 and 1xEV-DO systems differ, the
17 1xEV-DO procedures are identified separately within this specification. When the TIA/EIA/IS-2001 text
18 is applied to the 1xEV-DO RAN specification, the procedures related to the MSC shall be ignored. Hard
19 Handoff procedures are not applicable to 1xEV-DO.
20 When interpreting TIA/EIA/IS-2001 in the context of TIA/EIA/IS-856, the following TIA/EIA/IS-2001
21 terms should be mapped as follows.
22
TIA/EIA/IS-2001 term TIA/EIA/IS-856 term

BS AN
Base Station Access Network
BSC AN
Base Station Controller Access Network
Call Connection
MS AT
Mobile Station Access Terminal
23
24
25 1.7 1xEV-DO IOS Assumptions

26 The following assumptions are made regarding AN/AT behavior:
27 N A unique value (TBD) is used in the Service Option fields in accounting records transported on the
28 A9 and A11 interfaces to identify accounting records associated with 1xEV-DO Packet Data Service.
29 N For the case of idle inter-AN inter-PCF handoff, the target PCF may use the PDSN address received
30 from the source AN to send the A11-Registration Request. Otherwise, the target PCF shall use the
31 PDSN selection algorithm (if supported) or internal algorithms to select a PDSN.
32 N For the case of idle inter-AN handoff, the target AN shall use the PANID received from the AT. If the
33 AT does not send the PANID or the AN chooses not to request this information from the AT, then the
34 target AN may use the PANID received from the source AN.
1-4
SP-3-0009 (TIA/EIA/IS-878)
1 Note: Since the AT may have visited an IS-2000 system and established a data session between the
2 time it made an idle handoff from the source AN to target AN, the target AN shall use the PANID
3 given to it by the AT (if any) over the PANID received in the A13-Session Information Accept
4 message from the source AN.
5 N For the instance of Packet Application terminated in the AN, the AT shall support CHAP
6 authentication. In this case, the AT shall send a Network Access Identifier (NAI) of the form
7 specified in RFC 2486.
8 N For the instance of Packet Application terminated in the AN (i.e. AN authentication), the generation
9 of the NAI and password are the responsibility of the service provider. The NAI and password should
10 be chosen and managed using procedures that minimize the likelihood of compromise.
11 N If the AT device authentication feature is used, the AN shall always propose CHAP as a PPP option
12 in an initial Link Control Protocol (LCP) Configure-Request during the PPP establishment.
13 N The MN ID that is used by the AN and the PCF on A8/A9 and A10/A11 messages is determined as
14 follows:
15 S If the 1xEV-DO AN uses the AT device authentication feature, the MN ID field shall be set to the
16 MN ID value returned by the AN-AAA (e.g., IMSI) following successful access authentication.
17 S Otherwise, the AN/PCF shall set the MN ID field to a value that conforms to a valid MN ID
18 format (e.g., IMSI format). In this case, the MN ID is determined by other means.
19 N After the AT indicates it is ready to exchange data on the access stream, the AT and the AN initiate
20 PPP procedures according to RFC 1661.
21 N The AT may support Mobile IP.
22
23
1-5
SP-3-0009 (TIA/EIA/IS-878)
1 No text.
2
1-6
SP-3-0009 (TIA/EIA/IS-878)
1 2 1xEV-DO IOS Call Flows

2 This section describes the call flows associated with a 1xEV-DO Access Terminal (AT).
3 2.1 AT Originates 1xEV-DO Session

4 This section describes the call flows associated with an AT call origination in the Access Network (AN).
5 2.1.1 AT Originates 1xEV-DO Session -Successful Authentication

6 This section describes the call flow for a successfully authenticated AT call origination in the AN.
AT AN AN AAA PCF PDSN time
UATI-Request a
UATI-Assignment b
UATI-Complete c
Session Establishment d
AT Ready to Exchange e
Data on Access Stream
PPP and LCP Negotiation f
CHAP Challenge - Response g
A12 Access-Request h
A12 Access-Accept i
CHAP - Authentication Success j
AT Ready to Exchange k
Data on Packet Data Stream
A9-Setup-A8 l
A11-Registration Request (Lifetime, MEI) m

TA8-setup Tregreq
A11-Registration Reply (Lifetime, accept) n
A9-Connect-A8 o
Establishing PPP connection p
Transmitting Packet Data q
7
8
9 Figure 2.1.1-1 Initial AT Origination (with Session Establishment and Key Exchange)
2-1
SP-3-0009 (TIA/EIA/IS-878)
1 a. The AT sends a UATI-Request message to request that a Unicast Access Terminal Identifier (UATI)
2 be assigned to it by the AN.
3 b. The AN sends a UATI-Assignment message to assign a UATI to the AT.
4 c. The AT sends a UATI-Complete message to notify the AN that it has received the UATI-Assignment
5 message.
6 d. If no session exists between the AT and AN, a session is established where protocols and protocol
7 configurations are negotiated, stored and used for communications between the AT and the AN. Refer
8 to TIA/EIA/IS-856, Section 5, Session Layer.
9 e. The AT indicates that it is ready to exchange data on the access stream (e.g., the flow control protocol
10 for the default packet application bound to the AN is in the open state).
11 f. The AT and the AN initiate Point-to-Point Protocol (PPP) and Link Control Protocol (LCP) negotiat-
12 ions for access authentication. Refer to RFC 1661.
13 g. The AN generates a random challenge and sends it to the AT in a Challenge Handshake Authenticat-
14 ion Protocol (CHAP) Challenge packet in accordance with RFC 1994.
15 h. When the AN receives the CHAP response packet from the AT, it sends a RADIUS Access-Request
16 message packet on the A12 interface to the AN Authentication, Authorization and Accounting (AAA)
17 entity (which acts as a RADIUS server) in accordance with RFC-2865.
18 i. The AN-AAA looks up a password based on the User-name attribute in the A12 Access-Request and
19 if the authentication passes (as specified in RFC-1994 and RFC-2865), the AN AAA sends an
20 Access-Accept packet on the A12 interface. The A12 Access-Accept contains a RADIUS attribute
21 with Type set to 20 (Callback-Id). Refer to Section 4.3.2, RADIUS Support.
22 j. The AN returns an indication of CHAP authentication success, to the AT. Refer to RFC 1994.
23 k. The AT indicates that it is ready to exchange data on the packet data stream. (E.g., the flow control
24 protocol for the default packet application bound to the packet data network is in the open state).
25 l. The AN sends an A9-Setup-A8 message to the Packet Control Function (PCF) and starts timer TA8-
26 setup, to establish the A8-Connection. The A9-Setup-A8 message shall not be sent before the AT indi-
27 cates that it is ready to exchange data on the access stream, as identified in step e.
28 m. The PCF recognizes that no A10 connection associated with the AT is available and selects a PDSN.
29 The PCF sends an A11-Registration Request message to the PDSN which includes the Mobility
30 Event Indicator (MEI) within the Vendor/Organization Specific Extension. The PCF starts timer
31 Tregreq.
32 n. The A11-Registration Request is validated and the PDSN accepts the connection by returning an
33 A11-Registration Reply with an accept indication and Lifetime set to the configured Trp. Both the
34 PDSN and the PCF create a binding record for the A10 connection. The PCF stops timer Tregreq.
35 o. When the AN receives the A9-Connect-A8 message it stops timer TA8-setup.
36 p. PPP connection establishment procedure and optional Mobile IP Registration on the PPP connection
37 are performed between the AT and the PDSN. Refer to RFC 1661.
38 q. At this point the connection is established and packet data can flow between the AT and the PDSN.
39
40
2-2
SP-3-0009 (TIA/EIA/IS-878)
1 2.1.2 AT Originates 1xEV-DO Session - Unsuccessful Authentication

2 This section describes the call flow for an unsuccessful AT call origination in the AN, due to authenticat-
3 ion failure.
AT AN AN AAA PCF PDSN time
UATI-Request a
UATI-Assignment b
UATI-Complete c
AT Ready to Exchange
e
A12 Access-Reject i
CHAP - Authentication Failure j
SessionClose k
SessionClose l
5 Figure 2.1.2-1 Initial AT Origination (with Session Establishment and Key Exchange)
6 a. The AT sends a UATI-Request message to request that a UATI be assigned to it by the AN.
7 b. The AN sends a UATI-Assignment message to assign a UATI to the AT.
8 c. The AT sends a UATI-Complete message to notify the AN that it has received the UATI-Assignment
9 message.
10 d. If no session exists between the AT and AN, a session is established where protocols and protocol
11 configurations are negotiated, stored and used for communications between the AT and the AN. Refer
12 to TIA/EIA/IS-856, Section 5, Session Layer.
15 f. The AT and the AN initiate PPP and LCP negotiations for access authentication. Refer to RFC 1661.
16 g. The AN generates a random challenge and sends it to the AT in a CHAP Challenge packet in accord-
17 ance with RFC 1994.
18 h. When the AN receives the CHAP response packet from the AT, it sends a RADIUS Access-Request
19 message packet on the A12 interface to the AN AAA (which acts as a RADIUS server) in accordance
20 with RFC-2865.
2-3
SP-3-0009 (TIA/EIA/IS-878)
1 i. The AN-AAA looks up a password based on the User-name attribute in the A12 Access-Request and
2 if the authentication fails (as specified in RFC-1994 and RFC-2865), the AN AAA sends an Access-
3 Reject packet on the A12 interface.
4 Note: For ANs that perform access authentication, the network requires that no use of a dedicated
5 resource, such as access to a PDSN, be allowed if authentication fails.
6 j. The AN returns an indication of CHAP authentication failure, to the AT. Refer to RFC 1994.
7 k. The AN sends a SessionClose message to the AT, to close the session.
8 l. The AT responds with a SessionClose message.
9
10
2-4
SP-3-0009 (TIA/EIA/IS-878)
1 2.1.3 AT Originates with a Pre-existing 1xEV-DO Session

2 This section describes the origination call flow for when the AT has already established a session.
AT AN PCF PDSN time
Connection Establishment
a
A9-Setup-A8 b
TA8-setup
A9-Connect-A8 c
Transmitting Packet Data d
4 Figure 2.1.3-1 AT Origination (Session is Already Established)

5 a. If the AT has data to send, the AT initiates connection establishment procedures with the AN. The
6 AN assigns a Forward Traffic Channel, Reverse Power Control Channel and Reverse Traffic
7 Channel. Refer to TIA/EIA/IS-856, Section 6.4.5.6, Connection Setup State.
8 b. After the traffic channel is established, the AN sends an A9-Setup-A8 message to the PCF and starts
9 timer TA8-setup, to establish the A8-Connection.
10 c. When the AN receives the A9-Connect-A8 message it stops timer TA8-setup. Refer to TIA/EIA/IS-
11 2001-A, Section 2.14.7.6, Network Initiated Call Re-Activation from Dormant State.
12 d. At this point the connection is established and packet data can flow between the AT and the PDSN.
13
14
2-5
SP-3-0009 (TIA/EIA/IS-878)
1 2.2 Data Delivery

2 This section describes the call flows associated with AT terminated and AT originated data delivery.
3 2.2.1 Data Delivery - AT Terminated

4 This section describes the call flow associated with AT terminated data delivery. In this scenario, it is
5 assumed that the AT has already established a session, however it does not have a connection established.
AT AN PCF PDSN time
Transmitting Packet Data a
A9-BS Service Request b

Tbsreq9
A9-BS Service Response c
Page Message d
Connection Establishment e
A9-Setup-A8 f
TA8-setup
A9-Connect-A8 g
Transmitting Packet Data h
7 Figure 2.2.1-1 AT Terminated Data Delivery

8 a. The PCF determines that packet data is available for delivery to the AT.
9 b. The PCF sends an A9-BS Service Request message to the AN in order to request packet service, and
10 starts timer Tbsreq9.
11 c. The AN responds with an A9-BS Service Response. The PCF stops timer Tbsreq9 upon receipt of the
12 A9-BS Service Response message.
13 d. The AN sends a Page Message to the AT, on the control channel.
14 e. If the AT has data to send, the AT initiates connection establishment procedures with the AN. The
15 AN assigns a Forward Traffic Channel, Reverse Power Control Channel and Reverse Traffic
16 Channel. Refer to TIA/EIA/IS-856, Section 6.4.5.6, Connection Setup State.
17 f. After the traffic channel is established, the AN sends an A9-Setup-A8 to the PCF and starts timer TA8-
18 setup, to establish the A8-Connection.
19 g. When the AN receives the A9-Connect-A8 message it stops timer TA8-setup.

20 h. At this point the connection is established and packet data can flow between the AT and the PDSN.
21
22
2-6
SP-3-0009 (TIA/EIA/IS-878)
1 2.2.2 Data Delivery - AT Originated

2 AT originated data delivery is described in AT call originations. Refer to section 2.1.3, AT Originates
3 with a Pre-existing 1xEV-DO Session.
4
5 2.3 Connection Tear-Down

6 This section describes the call flows associated with a 1xEV-DO connection release.
7 2.3.1 Connection Tear-Down on 1xEV-DO Network - Initiated by the AT.

8 This section describes the call flow associated with a connection release initiated by an AT.
time
AT AN PCF PDSN
Connection Tear-Down a
(Initiated by the AT)
b
A9-Release-A8
Trel9
c
A9-Release-A8 Complete
10 Figure 2.3.1-1 AT Initiated Connection Tear-Down

11 a. The AT initiates 1xEV-DO connection tear-down. Refer to TIA/EIA/IS-856, Section 6, Connection
12 Layer.
13 b. The AN sends an A9-Release-A8 message with a Cause value set to “Packet call going dormant”, to
14 the PCF to instruct the PCF to release the A8 connection. The AN starts timer Trel9.
15 c. The PCF initiates procedures for releasing the A8 connection and sends an A9-Release-A8 Complete
16 message to the AN. The AN stops timer Trel9. At this time, A10 connection for this call is retained.
17
18
2-7
SP-3-0009 (TIA/EIA/IS-878)
1 2.3.2 Connection Tear-Down on 1xEV-DO Network - Initiated by the AN/PCF.

2 This section describes the call flow associated with a connection release initiated by the AN/PCF.
time
AT AN PCF PDSN
A9-Disconnect-A8
a
Tdiscon9
A9-Release-A8 b
Trel9
c
A9-Release-A8 Complete
Connection Tear-Down
d
(Initiated by the AN)
4 Figure 2.3.2-1 AN/PCF Initiated Connection Tear-Down

5 a. When the PCF decides to release the connection, the PCF sends an A9-Disconnect-A8 message to the
6 AN and starts timer Tdiscon9. In the case where the AN initiates connection release, this step is omitted.
7 b. The AN initiates release of the A8 connection by transmitting an A9-Release-A8 message and starts
8 timer Trel9. The PCF stops timer Tdiscon9 if it is running.
9 c. The PCF acknowledges the A9-Release-A8 message by returning an A9-Release-A8 Complete
10 message. The AN stops timer Trel9.
11 d. The AN may initiate 1xEV-DO connection tear-down. Refer to TIA/EIA/IS-856, Section 6, Connect-
12 ion Layer.
13
14
2-8
SP-3-0009 (TIA/EIA/IS-878)
1 2.4 Session Tear-Down

2 This section describes the call flows associated with a 1xEV-DO session release.
3 2.4.1 Session Tear-Down - Initiated by the AT

4 This section describes the call flows associated with a session release initiated by an AT. It is assumed
5 that the A8 connection is already established.
AT AN PCF PDSN
time
Session Tear-Down
a
(Initiated by the AT)
A9-Release-A8 b
A11-Registration Request (Lifetime=0, Acct data) c

Trel9 Tregreq
A11-Registration Reply (Lifetime=0, Accept) d
A9-Release-A8 Complete e
7 Figure 2.4.1-1 AT Initiated Session Tear-Down

8 a. The AT initiates 1xEV-DO session tear-down. Refer to TIA/EIA/IS-856, Section 5, Session Layer.
9 b. After the AN closes the 1xEV-DO session, the AN sends an A9-Release-A8 message with a Cause
10 value set to “Normal Call Release”, to the PCF to instruct the PCF to release the associated dedicated
11 resource and releases the associated A10 connection. The AN starts timer Trel9.
12 c. The PCF sends an A11-Registration Request message to the PDSN with a Lifetime timer value of
13 zero to close the A10 connection. Accounting data is included in the message. The PCF starts timer
14 Tregreq. Refer to TIA/EIA/IS-2001-A, Section 2.15.5.6, Packet Data Service Session Clearing - MS
15 Initiated.
16 d. The PDSN stores the accounting data for further processing and responds with an A11-Registration
17 Reply to complete the release of the A10 connection. The PCF stops timer Tregreq.
18 e. The PCF sends an A9-Release-A8 Complete message to the AN. The AN stops timer Trel9.
19
20
2-9
SP-3-0009 (TIA/EIA/IS-878)
1 2.4.2 A10 Tear-Down - Initiated by the PDSN

2 This section describes the call flow associated with an A10 release initiated by the PDSN.
AT AN PCF PDSN time
A11-Registration Update a
Tregupd
A11-Registration Acknowledgement b
A11-Registration Request (Lifetime=0) c

Tregreq
A11-Registration Reply (Lifetime=0, accept) d
A9-Disconnect-A8 e
Tdiscon9
A9-Release-A8 f
Trel9
A9-Release-A8 Complete g
4 Figure 2.4.2-1 PDSN Initiated A10 Tear-Down

5 a. The PDSN initiates closure of the A10 connection by sending an A11-Registration Update message to
6 the PCF. The PDSN starts timer Tregupd.
7 b. The PCF responds with an A11-Registration Acknowledge message. The PDSN stops timer Tregupd.
8 c. The PCF sends an A11-Registration Request message with Lifetime set to zero, to the PDSN. The
9 PCF starts timer Tregreq.
10 d. The PDSN sends an A11-Registration Reply message to the PCF. The PCF closes the A10 connection
11 for the AT and stops timer Tregreq.
12 e. The PCF sends an A9-Disconnect-A8 message to the AN and starts timer Tdiscon9.
13 f. The AN initiates release of the A8 connection by transmitting an A9-Release-A8 message and starts
14 timer Trel9. The PCF stops timer Tdiscon9.
15 g. The PCF acknowledges the A9-Release-A8 message by returning an A9-Release-A8 Complete. The
16 AN stops timer Trel9.
17
18
2-10
SP-3-0009 (TIA/EIA/IS-878)
1 2.4.3 Radio Session Tear-Down - Initiated by the AN.

2 This section describes the call flow associated with a session release initiated by the AN.
AT AN PCF PDSN time
Session Tear-Down
(Initiated by the AN) a
A9-Release-A8 b
A11-Registration Request (Lifetime=0) c
Trel9 Tregreq
A11-Registration Reply (Lifetime=0, accept) d
A9-Release-A8 Complete e
4 Figure 2.4.3-1 AN Initiated Radio Session Tear-Down

5 a. The AN initiates 1xEV-DO session tear-down. Refer to TIA/EIA/IS-856, Section 5, Session Layer.
6 b. The AN sends an A9-Release-A8 message with a Cause value set to “Normal Call Release”, to the
7 PCF to instruct the PCF to release the associated dedicated resource and releases the associated A10
8 connection. The AN starts timer Trel9.
9 c. The PCF sends an A11-Registration Request message with Lifetime set to zero, to the PDSN. The
10 PCF starts timer Tregreq.
11 d. The PDSN sends an A11-Registration Reply message to the PCF. The PCF closes the A10 connection
12 for the AT and stops timer Tregreq.
13 e. The PCF sends an A9-Release-A8 Complete message to the AN. The AN stops timer Trel9.
14
15
2-11
SP-3-0009 (TIA/EIA/IS-878)
1 2.5 Dormant Handoff of 1xEV-DO AT between ANs - Served by the Same PDSN
2 This section describes the call flows associated with AT dormant handoff between ANs.
3 2.5.1 AN-AN Dormant Handoff with Successful Retrieval of Session Information

4 This section describes the call flow associated with a dormant handoff between ANs when the session in-
5 formation is successfully retrieved over the A13 interface.
Target Target Source Source
AT PDSN time
AN PCF AN PCF
UATI-Request a
A13-Session Information Request b
TA13req
A13-Session Information Response c
UATI-Assignment
d
UATI-Complete
Location Update
e
Procedures
A13-Session Information Confirm f
A9-Setup-A8 g
A11-Registration Request (Lifetime, MEI) h
Tregreq
A11-Registration Reply (Lifetime, accept) i
A11-Registration Update j
TA8-setup Tregupd
A11-Registration Acknowledge k
A11-Registration Request l
(Lifetime=0)
Tregreq
A11-Registration Reply
m
(Lifetime=0, accept)
A9-Release-A8-Complete n
7 Figure 2.5.1-1 Inter-PCF/Intra-PDSN Dormant AN-AN HO - Successful Operation

8 a. The target AN receives a UATI-Request from the AT.
9 b. The target AN sends an A13-Session Information Request message to the source AN to request the
10 session information for the AT. The A13-Session Information Request message shall include the
11 received UATI, the Security Layer Packet and Sector ID. The target AN starts timer TA13req.
12 c. The source AN validates the A13-Session Information Request and sends the requested session in-
13 formation of the AT to the target AN in an A13-Session Information Response message.
14 d. The AN sends a UATI-Assignment to the AT. The AT confirms the receipt of the UATI with a
15 UATI-Complete. The UATI-Assignment may contain a new UATI or use the UATI received in the
16 UATI-Request message. This step can occur anytime after receipt of the UATI-Request message.
2-12
SP-3-0009 (TIA/EIA/IS-878)
1 e. The Location Update procedures may be used to retrieve the PANID information for sending to the
2 PCF / PDSN.
3 f. The target AN sends an A13-Session Information Confirm to the source AN to indicate that the target
4 AN has received the session information. The target AN stops timer TA13req. Upon receipt of the A13-
5 Session Information Confirm message the source AN deletes the AT session information in question.
6 g. The target AN sends an A9-Setup-A8 message, with Data Ready Indicator set to 0, to the target PCF
7 and starts timer TA8-setup.
8 h. The target PCF selects the PDSN to connect to using the PDSN address provided in the A13-Session
9 Information Response message or using PDSN selection algorithms as specified in TIA/EIA/IS-2001,
10 and sends an A11-Registration Request message to the PDSN. The A11-Registration Request
11 message includes the Mobility Event Indicator (MEI) within the Vendor/Organization Specific Ex-
12 tension. The target PCF starts timer Tregreq. Refer to TIA/EIA/IS-2001-A, Section 2.15.5.8, Inter-PCF
13 Dormant Handoff - Mobile Continues to be Served by the Serving PDSN.
14 i. The A11-Registration Request is validated and the PDSN accepts the connection by returning an
15 A11-Registration Reply with an accept indication and the Lifetime set to the configured Trp value. If
16 the PDSN has data to send, it includes the Data Available Indicator within the Vendor/Organization
17 Specific Extension. The A10 connection binding information at the PDSN is updated to point to the
18 target PCF. The target PCF stops timer Tregreq.
19 j. The PDSN initiates closure of the A10 connection with the source PCF by sending an A11-Registrat-
20 ion Update message. The PDSN starts timer Tregupd.
21 k. The source PCF responds with an A11-Registration Acknowledge message. The PDSN stops timer
22 Tregupd.
23 l. The source PCF sends an A11-Registration Request message with Lifetime set to zero, to the PDSN.
24 The source AN/PCF starts timer Tregreq.
25 m. The PDSN sends an A11-Registration Reply message to the source PCF. The source PCF closes the
26 A10 connection for the AT and stops timer Tregreq.
27 n. The target PCF responds to the target AN with an A9-Release-A8-complete message. The AN stops
28 timer TA8-setup.
29
30
2-13
SP-3-0009 (TIA/EIA/IS-878)
1 2.5.2 Dormant AN-AN Handoff with Session Information Transfer Failure

2 This section describes the call flow associated with a dormant handoff between ANs when the session in-
3 formation can not be retrieved successfully from the source AN.
Target Target Source Source
AT AAA-AN PDSN time
AN PCF AN PCF
UATI-Request a
A13-Session Information Request b

TA13req
A13-Session Information Reject c
UATI-Assignment
d
UATI-Complete
Location Update
Procedures e
Access Authentication f
A9-Setup-A8 g
A11-Registration Request (Lifetime, MEI) h

Tregreq
A11-Registration Reply (Lifetime, accept) i
Tregupd
TA8-setup k
A11-Registration Acknowledge
A11-Registration Request
l
(Lifetime=0)
Tregreq
A11-Registration Reply
m
(Lifetime=0, accept)
A9-Release-A8-Complete n
5 Figure 2.5.2-1 Inter-PCF/Intra PDSN Dormant AN-AN HO - Session Info Transfer Failure
6 a. The target AN receives a UATI-Request from the AT.
7 b. The target AN sends an A13-Session Information Request message to the source AN to request the
8 session information for the AT. The A13-Session Information Request message shall include the
9 received UATI and the Security Layer Packet. The target AN starts timer TA13req.
10 c. The source AN cannot validate the A13-Session Information Request or does not have the requested
11 AT session information and sends an A13-Session Information Reject message to the target AN. The
12 target AN stops the timer TA13req.
13 d. The target AN sends a UATI-Assignment to the AT with a new UATI. The AT confirms that it has
14 received the UATI with a UATI-Complete message. This step can occur anytime after receipt of the
15 UATI-Request message.
16 e. The Location Update procedures may be used to retrieve the PANID information for sending to the
17 PCF / PDSN.
2-14
SP-3-0009 (TIA/EIA/IS-878)
1 f. Since no session exist between the AN and AT, a new session is established. The AT opens an access
2 stream for access authentication. If access authentication is enabled/supported at the target AN, it
3 shall initiate a PPP on the access stream. The AT performs an access authentication via CHAP /
4 RADIUS towards the AN-AAA. The AN shall use the MN ID received from the AN-AAA in the A12
5 Access-Accept, in messages on the A9/A11 interfaces. Refer to Section 4.3, A12 (AN-AN AAA)
6 Interface.
7 g. The target AN transmits an A9-Setup-A8 message to target PCF with Data Ready Indicator set to 0 to
8 establish an A8 connection and starts timer TA8-setup.
9 h. The target PCF selects a PDSN for this call using PDSN selection algorithms as specified in IS-2001.
10 The target PCF sends an A11-Registration Request message to the selected PDSN. The A11-
11 Registration Request includes the Mobility Event Indicator (MEI) within the Vendor/Organization
12 Specific Extension. The PCF starts timer Tregreq. Refer to TIA/EIA/IS-2001-A, Section 2.15.5.8, Inter-
13 PCF Dormant Handoff - Mobile Continues to be Served by the Serving PDSN.
14 i. The A11-Registration Request is validated and the PDSN accepts the connection by returning an
17 Specific Extension . The A10 connection binding information at the PDSN is updated to point to the
19 j. The PDSN initiates closure of the A10 connection with the source PCF by sending an A11-Registrat-
20 ion Update message. The PDSN starts timer Tregupd.
21 k. The source PCF responds with an A11-Registration Acknowledge message. The PDSN stops timer
22 Tregupd.
23 l. The source PCF sends an A11-Registration Request message with Lifetime set to zero, to the PDSN.
24 The source AN/PCF starts timer Tregreq.
25 m. The PDSN sends an A11-Registration Reply message to the source PCF. The source PCF closes the
26 A10 connection for the AT and stops timer Tregreq.
27 n. The target PCF responds to the target AN with an A9-Release-A8 Complete message. The AN stops
28 timer TA8-setup.
29
30
2-15
SP-3-0009 (TIA/EIA/IS-878)
1 No text.
2
2-16
SP-3-0009 (TIA/EIA/IS-878)
1 3 1xEV-DO and IS-2000 IOS Transition Call Flows

2 This section describes the call flows associated with handoffs between 1xEV-DO and TIA/EIA/IS-2000
3 systems, for hybrid MS/ATs.
4 3.1 Dormant/Idle (Voice or Packet) Cross System Handoff - Served by the Same PDSN.
5 This section describes the call flows for dormant/idle handoffs between 1xEV-DO and TIA/EIA/IS-2000
6 systems.
7 3.1.1 Dormant/Idle IS-2000 Handoff to Idle 1xEV-DO - Existing Session

8 This section describes the call flow associated with an MS/AT idle handoff from an IS-2000 to a 1xEV-
9 DO system, when the 1xEV-DO system supports unsolicited Location Notification messages. Refer to
10 TIA/EIA/IS-856. Based on the MS/AT changing to a different ANID or for other reasons, a dormant
11 handoff from IS-2000 to idle 1xEV-DO is determined to be required. In this scenario, it is assumed that
12 the MS/AT has already established a session, however it does not have a connection established. In
13 addition, the MS/AT is configured to send unsolicited location notifications, upon return to the 1xEV-DO
14 system.
Target Target Source
MS/AT PDSN time
AN PCF BSC/PCF
Location Update a
Procedures
b
A9-Setup-A8
A11-Registration Request (Lifetime, MEI) c
Tregreq
A11-Registration Reply (Lifetime, accept) d
A11-Registration Update e
TA8-setup Tregupd
A11-Registration Acknowledge f
A11-Registration Request (Lifetime=0) g
Tregreq
A11-Registration Reply (Lifetime=0, accept) h
A9-Release-A8 i
Complete
15
16
17 Figure 3.1.1-1 MS/AT Idle Handoff from IS-2000 to 1xEV-DO - Existing Session
18 a. The change of AN is indicated by the Location Update procedures as defined in TIA/EIA/IS-856.
19 b. The target AN sends an A9-Setup-A8 message to the target PCF and starts timer TA8-setup.
20 c. The target PCF sends an A11-Registration Request message to the PDSN. The A11-Registration Re-
21 quest message includes the MEI, the PANID of the source PCF and the Current Access Network
22 Identifiers (CANID) of the target PCF, within the Vendor/Organization Specific Extension. The
23 target PCF starts timer Tregreq.
24 d. The A11-Registration Request is validated and the PDSN accepts the connection by returning an
3-1
SP-3-0009 (TIA/EIA/IS-878)
4 e. The PDSN initiates closure of the A10 connection with the source BSC/PCF by sending an A11-Reg-
5 istration Update message. The PDSN starts timer Tregupd.
6 f. The source BSC/PCF responds with an A11-Registration Acknowledge message. The PDSN stops
7 timer Tregupd.
8 g. The source BSC/PCF sends an A11-Registration Request message with Lifetime set to zero, to the
9 PDSN. The source BSC/PCF starts timer Tregreq.
10 h. The PDSN sends an A11-Registration Reply message to the source BSC/PCF. The source BSC/PCF
11 closes the A10 connection for the MS/AT and stops timer Tregreq.
12 i. The target PCF sends an A9-Release-A8 Complete message to the target AN. The target AN stops
13 timer TA8-setup.
14
15
3-2
SP-3-0009 (TIA/EIA/IS-878)
1 3.1.2 Dormant/Idle IS-2000 Handoff to Idle 1xEV-DO - New Session

2 This section describes the call flow associated with an MS/AT idle handoff from an IS-2000 to a 1xEV-
3 DO system. Based on an MS/AT report that it crossed a network specified threshold for signal strength or
4 for other reasons, a dormant handoff from IS-2000 to idle 1xEV-DO is determined to be required and the
5 idle MS/AT tunes from IS-2000 to 1xEV-DO.
Target Source Target

MS/AT PDSN time
AN/PCF BSC/PCF AN AAA
UATI-Request a
b
UATI-Assignment
UATI-Complete c
AT Ready to Exchange e
A12 Access-Accept i
CHAP - Authentication Success j
Location Update Procedures k
AT Ready to Exchange
l
Data on Packet Data Stream
A11-Registration Request (Lifetime, MEI) m

Tregreq
A11-Registration Reply (Lifetime, accept) n
A11-Registration Update o
Tregupd
A11-Registration Acknowledge p
A11-Registration Request (Lifetime=0) q

Tregreq
A11-Registration Reply (Lifetime=0, accept) r
PPP Traffic s
7 Figure 3.1.2-1 MS/AT Idle Handoff from IS-2000 to 1xEV-DO - New Session
8 a. The MS/AT sends a UATI-Request message to request that a UATI be assigned to it by the target
9 AN/PCF.
10 b. The target AN/PCF sends a UATI-Assignment message to assign a UATI to the MS/AT.
11 c. The MS/AT sends a UATI-Complete message to notify the target AN/PCF that it has received the
12 UATI-Assignment message.
3-3
SP-3-0009 (TIA/EIA/IS-878)
1 d. Since no session exists between the MS/AT and target AN/PCF, a session is established where
2 protocols and protocol configurations are negotiated, stored and used for communications between
3 the MS/AT and the AN. Refer to TIA/EIA/IS-856, Section 5, Session Layer.
6 f. After session configuration the MS/AT initiates PPP and LCP negotiations for access authentication.
7 Refer to RFC 1661.
8 g. The target AN/PCF generates a random challenge and sends it to the MS/AT in a CHAP Challenge
9 packet in accordance with RFC 1994.
10 h. When the target AN/PCF receives the CHAP response packet from the MS/AT, it sends a RADIUS
11 Access-Request message packet on the A12 interface to the AN AAA (which acts as a RADIUS
12 server) in accordance with RFC-2865.
13 i. The target AN-AAA looks up a password based on the User-name attribute in the A12 Access-
14 Request and if the authentication passes (as specified in RFC-1994 and RFC-2865), the AN AAA
15 sends an Access-Accept packet on the A12 interface. The A12 Access-Accept contains a RADIUS
16 attribute with Type set to 20 (Callback-Id). Refer to Section 4.3.2, RADIUS Support.
17 j. The target AN/PCF returns an indication of CHAP authentication success, to the MS/AT. Refer to
18 RFC 1994.
19 k. The change of AN is indicated by the Location Update procedures as defined in TIA/EIA/IS-856.
20 l. The AT indicates that it is ready to exchange data on the packet data stream. (E.g., the flow control
21 protocol for the default packet application bound to the packet data network is in the open state).
22 m. The target AN/PCF sends an A11-Registration Request message to the PDSN. The A11-Registration
23 Request message includes the MEI, the PANID of the source and the CANID of the target PCF,
24 within the Vendor/Organization Specific Extension. If PANID is not sent in step l, the AN/PCF sets
25 all of the fields within the PANID and the CANID to zero. The target AN/PCF starts timer Tregreq.
26 n. The A11-Registration Request is validated and the PDSN accepts the connection by returning an
30 target AN/PCF. The target AN/PCF stops timer Tregreq.
31 o. The PDSN initiates closure of the A10 connection with the source BSC/PCF by sending an A11-Reg-
33 p. The source BSC/PCF responds with an A11-Registration Acknowledge message. The PDSN stops
34 timer Tregupd.
35 q. The source BSC/PCF sends an A11-Registration Request message with Lifetime set to zero, to the
37 r. The PDSN sends an A11-Registration Reply message to the source BSC/PCF. The source BSC/PCF
39 s. PPP traffic flows.
40
41
3-4
SP-3-0009 (TIA/EIA/IS-878)
1 3.1.3 Idle 1xEV-DO Handoff to Dormant/Idle IS-2000

2 This section describes the call flow associated with an MS/AT idle handoff from a 1xEV-DO to an IS-
3 2000 system. Based on the MS/AT changing to a different ANID or for other reasons, an idle handoff
4 from 1xEV-DO to dormant IS-2000 is determined to be required. In this scenario, it is assumed that the
5 MS/AT has already established a session, however it does not have a connection established.
Target Source
MS/AT MSC PDSN time
BSC/PCF AN/PCF
Origination (DRS='0') a
BS Ack Order b
Complete L3 Info CM Service Request c
T303
Assignment Request d
A11-Registration Request (Lifetime, MEI) e

Tregreq T10
A11-Registration Reply (Lifetime, accept) f
Assignment Failure g
Clear Command h
T20
Clear Complete i
Tregupd
A11-Registration Acknowledge k
A11-Registration Request (Lifetime=0) l

Tregreq
A11-Registration Reply (Lifetime=0, accept) m
7 Figure 3.1.3-1 MS/AT Idle Handoff from a 1xEV-DO to an IS-2000 System

8 a. Upon tuning to the IS-2000 system, the MS/AT transmits an Origination Message, with layer 2 ac-
9 knowledgment required, over the access channel of the air interface to the target BSC/PCF to request
10 service. This message may contain the SID, NID and PZID corresponding to the source PCF from
11 which the MS/AT is coming, if this capability is supported by the air interface. If available, these
12 values are used to populate the PANID field of the A11-Registration Request message that the target
13 BSC/PCF sends to the PDSN.
14 b. The target BSC/PCF acknowledges receipt of the Origination Message with a Base Station Acknow-
15 ledgment Order to the MS/AT.
16 c. The target BSC/PCF constructs a CM Service Request message, places it in the Complete Layer 3
17 Information message, sends the message to the MSC and starts timer T303.
18 d. The MSC sends an Assignment Request message to the target BSC/PCF requesting assignment of
19 radio resources and starts timer T10. The BSC/PCF stops timer T303.
3-5
SP-3-0009 (TIA/EIA/IS-878)
1 e. The target BSC/PCF sends an A11-Registration Request message to the PDSN. The A11-Registrat-
2 ion Request message includes the MEI, the PANID of the source PCF and the CANID of the target
3 PCF, within the Vendor/Organization Specific Extension. The target BSC/PCF starts timer Tregreq.
4 f. The A11-Registration Request is validated and the PDSN accepts the connection by returning an
8 target BSC/PCF. The target BSC/ PCF stops timer Tregreq.
9 If the PDSN responds to the target BSC/PCF with the Data Available Indicator, the target BSC/PCF
10 establishes a traffic channel (IS-2001-A 2.15.5.4-1). In this case the remaining steps in this procedure
11 are omitted.
12 g. The target BSC/PCF sends an Assignment Failure message to the MSC with the cause value indicat-
13 ing Packet Call Going Dormant and starts timer T20. The MSC stops timer T10.
14 h. The MSC sends a Clear Command message to the target with a Cause value Do Not Notify Mobile
15 and starts timer T315. The BSC/PCF stops timer T20 upon receipt of the Clear Command message.
16 i. The target BSC/PCF sends a Clear Complete message to the MSC. The MSC stops timer T315.
17 j. The PDSN initiates closure of the A10 connection with the source AN/PCF by sending an A11-Reg-
19 k. The source AN/PCF responds with an A11-Registration Acknowledge message. The PDSN stops
20 timer Tregupd.
21 l. The source AN/PCF sends an A11-Registration Request message with Lifetime set to zero, to the
22 PDSN. The source AN/PCF starts timer Tregreq.
23 m. The PDSN sends an A11-Registration Reply message to the source AN/PCF. The source AN/PCF
25
26
3-6
SP-3-0009 (TIA/EIA/IS-878)
1 3.2 AT Terminated Voice Call During Active 1xEV-DO Data Session

2 This section describes the call flows associated with AT Terminated Voice Call During Active 1xEV-DO
3 Data Session.
4 3.2.1 AT Terminated Voice Call During Active 1xEV-DO Data Session (Intra-PDSN/Inter-PCF)
5 This section describes the call flow associated with an MS/AT terminated voice call while the MS/AT has
6 an active 1xEV-DO data session. The 1xEV-DO data session is handed off to the IS-2000 system as a
7 concurrent call service if the MS/AT has and selects this capability.
MS/AT BS IS-2000 PCF1 MSC AN 1xEV-DO PCF2 PDSN time
1xEV-DO Active Data Session
Paging Request a
Page b
MS/AT stops transmitting to the AN x c

T3113 A9-AL Disconnected d
Tald9
A9-AL Disconnected Ack-A8 e
Page Response f
Paging Response g
Assignment Request h
TCH Setup T10 i
Assignment Complete j
Alert with Info k
Origination for Concurrent Service Tairdrop l
A9-Setup-A8 m
T10
A11-Registration Request (Lifetime, MEI) n
TA8-Setup Tregreq
A11-Registration Reply (Lifetime, accept) o
A9-Connect-A8 p
Assignment Complete q
IS-2000 Active Data Session r
Connect Order s
Connect t
x A9-Release-A8 u
A11-Registration Request (Lifetime=0) v

Trel9 Tregreq
A11-Registration Reply (Lifetime=0, Accept)
w
A9-Release-A8 Complete x
9 Figure 3.2.1-1 Voice Call Termination During Active 1xEV-DO Data Session (Inter-PCF)
3-7
SP-3-0009 (TIA/EIA/IS-878)
1 a. The MSC determines that an incoming call terminates to an MS/AT within its serving region and
2 sends a Paging Request message to the BS to initiate an MS/AT terminated call setup scenario. The
3 MSC starts timer T3113.
4 b. The BS sends a Page Message containing the AT address over the paging channel. The MS/AT may
5 ignore this Page Message to continue the 1xEV-DO session. If the MS/AT ignores the message,
6 following steps are not performed.
7 c. The AN determines that it is not receiving any transmissions from the MS/AT and starts timer Tairdrop.
8 d. The AN sends an A9-AL Disconnected message to PCF2 to stop data flow and starts timer Tald9.
9 e. Upon receipt of the A9-AL Disconnected message, the PCF2 sends an A9-AL Disconnected Ack to
10 the AN. The AN stops timer Tald9.
11 f. The MS/AT sends a Page Response message to the BS. This step can occur any time after step c.
12 g. The BS sends a Paging Response message to the MSC. The MSC stops timer T3113.
13 h. The MSC sends an Assignment Request message to the BS and starts timer T10.
14 i. The BS establishes a traffic channel upon receipt of the Assignment Request message. Refer to
15 TIA/EIA/IS-856, Section 8.4 (8.5), Default Forward (Reverse) Traffic Channel MAC Procedures.
16 j. After the traffic channel setup is complete, the BS sends an Assignment Complete message to the
17 MSC. The MSC stops timer T10.
18 k. The BS sends an Alert with Info message to indicate the MS/AT to ring.
19 l. The MS/AT and the IS-2000 system set up the data session for handoff from 1xEV-DO as a
20 concurrent call service if the MS/AT has concurrent call service capability and selects to handoff the
21 data session from the 1xEV-DO to the IS-2000 system. Refer to TIA/EIA/IS-2001-A, Section
22 2.17.2.1 steps (a) to step (g).
23 m. The BS sends an A9-Setup-A8 message to the PCF1 to establish A8 connection and starts timer TA8-
24 setup.
25 n. PCF1 sends an A11-Registration Request message to the PDSN to establish the A10 connection to
26 handoff from the 1xEV-DO system to the IS-2000 system. PCF1 starts timer Tregreq.
27 o. The A11-Registration Request is validated and the PDSN accepts the connection by returning an
28 A11-Registration Reply with an accept indication. The target PCF1 stops timer Tregreq.
29 p. PCF1 sends an A9-Connect-A8 message after the completion of the A10 connection handoff. The BS
30 stops timer TA8-setup.
31 q. The BS sends an Assignment Complete message to the MSC and stops timer T10 (started during the
32 origination for concurrent service, in step l).
33 r. At this point, the data session is successfully handed off from the 1xEV-DO to the IS-2000 system.
34 s. The MS/AT sends a Connect Order message when the call is answered at the MS/AT.
35 t. The BS sends a Connect message to the MSC.
36 u. Upon not having received any transmissions from the MS/AT prior to timer Tairdrop expiration, the AN
37 sends an A9-Release-A8 message to PCF2 and starts timer Trel9.
38 v. PCF2 sends an A11-Registration Request message with Lifetime set to zero, to the PDSN. PCF2
39 starts timer Tregreq.
40 w. The PDSN sends an A11-Registration Reply message to PCF2. The PCF2 closes the A10 connection
41 for the MS/AT and stops timer Tregreq.
42 x. PCF2 responds to the AN with an A9-Release-A8 Complete message. The AN stops timer Trel9.
43
3-8
SP-3-0009 (TIA/EIA/IS-878)
1 3.2.2 MS/AT Terminated Voice Call During Active 1xEV-DO Data Session (Intra-PCF)
2 This section describes the call flow associated with an MS/AT terminated voice call while the MS/AT has
3 an active 1xEV-DO data session. The 1xEV-DO data session is handed off to the IS-2000 system as a
4 concurrent call service if the MS/AT has and selects this capability.
MS/AT BS IS-2000 MSC AN 1xEV-DO PCF PDSN time
1xEV-DO Active Data Session
Paging Request a
Page b
MS/AT stops transmitting to the AN x c
A9-AL Disconnected d
T3113
Tald9
A9-AL Disconnected Ack-A8 e
Page Response f
Paging Response g
Assignment Request h
TCH Setup T10 i
Assignment Complete j
Alert with Info k
Tairdrop
Origination for Concurrent Service l
A9-Setup-A8 m
A9-Connect-A8 n
Assignment Complete o
IS-2000 Active Data Session p
Connect Order q
Connect r
x A9-Release-A8 s
A9-Release-A8 Complete t
5
6 Figure 3.2.2-1 Voice Call Termination During Active 1xEV-DO Data Session (Intra-PCF)
7 a. The MSC determines that an incoming call terminates to an MS/AT within its serving region and
8 sends a Paging Request message to the BS to initiate an MS/AT terminated call setup scenario. The
9 MSC starts timer T3113.
10 b. The BS sends a Page Message containing the MS/AT address over the paging channel. The MS/AT
11 may ignore this Page Message to continue the 1xEV-DO session. If the MS/AT ignores the message,
12 following steps are not performed.
13 c. The AN determines that it is not receiving any transmissions from the MS/AT and starts timer Tairdrop.
14 d. The AN sends an A9-AL Disconnected message to the PCF to stop data flow and starts timer Tald9.
15 e. Upon receipt of the A9-AL Disconnected message, the PCF sends an A9-AL Disconnected Ack to the
16 AN. The AN stops timer Tald9.
17 f. The MS/AT sends a Page Response message to the BS. This step can occur any time after step c.
3-9
SP-3-0009 (TIA/EIA/IS-878)
1 g. The BS sends a Paging Response message to the MSC. The MSC stops timer T3113.
2 h. The MSC sends an Assignment Request message to the BS and starts timer T10.
3 i. The BS establishes a traffic channel upon receipt of the Assignment Request message.
4 j. After the traffic channel setup is complete, the BS sends an Assignment Complete message to the
5 MSC. The MSC stops timer T10. Refer to TIA/EIA/IS-856, Section 8.4 (and 8.5), Default Forward
6 (and Reverse) Traffic Channel MAC Procedures.
7 k. The BS sends an Alert with Info message to indicate the MS/AT to ring.
8 l. The MS/AT and IS-2000 system set up the data session for handoff from 1xEV-DO as a concurrent
9 call service if the MS/AT has concurrent call service capability and selects to handoff the data session
10 from the 1xEV-DO to the IS-2000 system. Refer to TIA/EIA/IS-2001-A, Section 2.17.2.1 steps (a) to
11 step (g).
12 m. The BS sends an A9-Setup-A8 message to the PCF to establish A8 connection and starts timer TA8-
13 setup.
14 n. The PCF sends an A9-Connect-A8 message to the BS. The BS stops timer TA8-setup.
15 o. The BS sends an Assignment Complete message to the MSC and stops timer T10 (started during the
16 origination for concurrent service), in step l.
17 p. At this point, the data session is successfully handed off from the 1xEV-DO system to the IS-2000
18 system.
19 q. The MS/AT sends a Connect Order message when the call is answered at the MS/AT..
20 r. The BS sends a Connect message to the MSC.
21 s. Upon not having received any transmissions from the MS/AT prior to timer Tairdrop expiration, the AN
22 sends an A9-Release-A8 message to the PCF and starts timer Trel9.
23 t. Upon receipt of the A9-Release-A8 message, the PCF sends an A9-Release-A8 Complete message to
24 the AN. The AN stops timer Trel9.
25
26
3-10
SP-3-0009 (TIA/EIA/IS-878)
1 3.3 AN Change, Active IS-2000 (Packet) to Active 1xEV-DO (Cross System - DO)
2 This section describes the call flow associated with an MS/AT AN change from an IS-2000 to a 1xEV-
3 DO system. The MS/AT determines that an AN change from IS-2000 to 1xEV-DO is required. In this
4 scenario, it is assumed that the MS/AT has already established a session, however it does not have a
5 connection established.
Target Source
MS/AT AN/PCF BSC/PCF MSC PDSN time
Release Order a
Release Order b
Clear Request c
T300
Clear Command d
Location Update Procedures e
A11-Registration Request (Lifetime, MEI) f

Tregreq
A11-Registration Reply (Lifetime, accept) g
A11-Registration Update h
T315 Tregupd
A11-Registration Acknowledge i
A11-Registration Request (Lifetime=0) j

Tregreq
A11-Registration Reply (Lifetime=0, accept) k
Clear Complete l
Packet Data Exchange m
7 Figure 3.3-1 MS/AT Active AN Change from an IS-2000 to a 1xEV-DO System

8 a. The MS/AT sends a Release Order to the source BSC/PCF.
9 b. The source BSC/PCF releases any associated dedicated resources and acknowledges the MS/AT by
10 sending a Release Order.
11 c. The BSC/PCF sends a Clear Request to the MSC and starts timer T300. Refer to TIA/EIA/IS-2001-A,
12 Section 2.15.5.6, Packet Data Service Session Clearing - MS Initiated.
13 d. The MSC responds with a Clear Command and starts timer T315. The BSC/PCF stops timer T300.
14 e. The change of AN is indicated by the Location Update procedures as defined in TIA/EIA/IS-856.
15 f. The target AN/PCF sends an A11-Registration Request message to the PDSN. The A11-Registration
16 Request message includes the MEI, the PANID of the source PCF and the CANID of the target PCF,
17 within the Vendor/Organization Specific Extension. If PANID is not sent in step e, the target AN/
18 PCF sets all of the fields within the PANID and the CANID to zero. The target AN/PCF starts timer
19 Tregreq.
20 If the AT has indicated to the AN that it is not ready to exchange data packets (e.g., the Flow Control
21 Protocol of the Default Packet Application that is bound to the service network is in the Closed state),
22 then the AN may delay sending the A11-Registration Request message to the PDSN until after the
3-11
SP-3-0009 (TIA/EIA/IS-878)
1 AT is ready to exchange data packets. In this case, the AN may take the appropriate action to notify
2 the AT that data packets are available (e.g., by requesting that the Flow Control Protocol transition to
3 the Open state).
4 g. The A11-Registration Request is validated and the PDSN accepts the connection by returning an
8 target AN/PCF. The target AN/PCF stops timer Tregreq.
9 h. The PDSN initiates closure of the A10 connection with the source BSC/PCF by sending an A11-Reg-
11 i. The source BSC/PCF responds with an A11-Registration Acknowledge message. The PDSN stops
12 timer Tregupd.
13 j. The source BSC/PCF sends an A11-Registration Request message with Lifetime set to zero, to the
15 k. The PDSN sends an A11-Registration Reply message to the source BSC/PCF. The source BSC/PCF
17 l. The target BSC/PCF sends a Clear Complete message to the MSC. The MSC stops timer T315.
18 m. Packet data exchange continues between the MS/AT and the PDSN.
19
20
3-12
SP-3-0009 (TIA/EIA/IS-878)
1 3.4 Status Management Supported by Feature Invocation

2 This section describes the call flow associated with status management using feature invocation.
MS/AT BS IS-2000 MSC 1xEV-DO AN time
Origination a
(Feature Code)
Mobile Originating Call Setup b
c
MSC Initiated Call Clearing
Mobile Initiated 1xEV-DO Connection Setup d
Mobile Initiated 1xEV-DO Connection Release e
Origination f
(Feature Code)
Mobile Originating Call Setup g
MSC Initiated Call Clearing h
4 Figure 3.4-1 Terminal Based Status Management (Using Feature Invocation)

5 a. The MS/AT sends an Origination Message, including the feature code as the called number, to the BS
6 when the MS/AT starts the 1xEV-DO communication. This feature code indicates that the MSC
7 should activate a feature (e.g., do not disturb).
8 b. The BS and the MSC setup the call. From the feature code, the MSC knows not to page the MS/AT
9 for a voice call. Refer to TIA/EIA/IS-2001-A Section 2.2.2.1, Mobile Origination.
10 c. The BS and the MSC clear the call. Refer to TIA/EIA/IS-2001-A Section 2.3.5.3, Call Clear Initiated
11 by MSC.
12 d. The MS/AT starts communication on the 1xEV-DO session. Refer to Section 2.1.3, AT Originates
13 with a Pre-existing 1xEV-DO Session.
14 e. The MS/AT terminates communication on the 1xEV-DO session when the 1xEV-DO session goes
15 dormant or inactive. Refer to Section 2.4.1, Session Tear-Down, Initiated by the AT.
16 f. The MS/AT sends an Origination Message, including the feature code as the calling number, to the
17 BS when the MS/AT ends the 1xEV-DO communication. This feature code indicates that the MSC
18 should deactivate the feature activated in step a.
19 g. The BS and the MSC setup the call. From the feature code, the MSC know it may page the MS/AT
20 for a voice call. Refer to TIA/EIA/IS-2001-A Section 2.2.2.1, Mobile Origination.
21 h. The BS and the MSC clear the call. Refer to TIA/EIA/IS-2001-A Section 2.3.5.3, Call Clear Initiated
22 by MSC.
23
24
3-13
SP-3-0009 (TIA/EIA/IS-878)
1 No text.
2
3-14
SP-3-0009 (TIA/EIA/IS-878)
1 4 1xEV-DO IOS Interfaces

2 This section describes the interfaces associated with the 1xEV-DO IOS specification.
3 4.1 A8-A9 (AN - PCF) Interface

4 The specification for the A8-A9 interface is defined in the IS-2001 specification. While no new signaling
5 information is defined for the interface between the AN and the PCF, updates to address 1xEV-DO
6 (intended to incorporated into a future revision of IS-2001) are included in Annex B.
7 4.2 A10-A11 (PCF - PDSN) Interface

8 The specification for the A10-A11 interface is defined in the IS-2001 specification. While no new signal-
9 ing information is defined for the interface between the PCF and the PDSN, updates to address 1xEV-DO
10 (intended to incorporated into a future revision of IS-2001) are included in Annex C.
11 4.3 A12 (AN - AN AAA) Interface

12 The A12 interface between the AN and the AN-AAA entities is used for the following purposes:
13 1. to perform AN-level authentication of the MS/AT device (by authenticating the results of a CHAP
14 challenge/response operation invoked by the AN).
15 2. to return the MN ID that is used on the A8/A9 and A10/A11 interfaces (following successful authent-
16 ication of the MS/AT device). This identifier permits handoffs of PDSN packet data sessions
17 between ANs and between 1xEV-DO and IS-2000 systems.
18 If the MS/AT device authentication feature is not used by a 1xEV-DO system, the MN ID that is used by
19 the AN on the A8/A9 and A10/A11 interfaces is determined by other means.
20 The A12 interface is based on the RADIUS protocol as defined in RFC 2865 and RFC 1321. The inter-
21 face is defined as shown in the simplified network architecture of Figure 1.2-1.
22 The A12 interface consists of the following messages:
23 A12 Access-Request
24 A12 Access-Accept
25 A12 Access-Reject
26 The following figure shows the protocol reference model for the RADIUS server to the AN. The
27 RADIUS servers in the visited access provider and home access provider IP networks communicate via
28 RADIUS proxy servers and one or more RADIUS brokers. Note: the use of RADIUS brokers is optional.
RADIUS RADIUS RADIUS RADIUS RADIUS RADIUS
UDP UDP UDP UDP UDP UDP
IP IP IP IP IP IP
Link Link Link Link Link Link

Layer Layer Layer Layer Layer Layer
PL PL PL PL PL PL
RADIUS RADIUS RADIUS

AN Broker
Visited Home
29
(optional)
30 Figure 4.3-1 RADIUS Protocol Reference Model
4-1
SP-3-0009 (TIA/EIA/IS-878)
1 4.3.1 PPP Session
2 4.3.1.1 Establishment
3 After the AT indicates it is ready to exchange data on the access stream, the AT and the AN initiate PPP
4 procedures according to RFC 1661.. PPP shall support transparency in accordance with section 4.2 of
5 RFC 1662. The AN and AT shall attempt to negotiate a control character mapping, with the minimum
6 number of escaped characters by proposing an ACCM of 0x00000000. Additionally, if no PPP session is
7 present, the AN may re-authenticate the MS/AT by reinitiating the PPP session.
8 4.3.1.2 Termination
9 The AN may release the PPP connection after the authentication of the AT has been performed. The AN
10 may support a PPP inactivity timer for each PPP session. When the inactivity timer expires, the AN shall
11 terminate the PPP session.
12 4.3.1.3 Authentication
13 The AT and the AN shall support the authentication mechanism CHAP. The AN shall always propose
14 CHAP as a PPP option in an initial LCP Configure-Request during the PPP establishment.
15 4.3.2 RADIUS Support

16 The AN shall act as a RADIUS client in accordance with RFC 2865 and shall communicate user CHAP
17 authentication information to the local RADIUS server in a RADIUS Access-Request on the A12 inter-
18 face. For a RADIUS Server to recognize that the transaction is related to terminal authentication, the A12
19 Access-Request may contain an additional 3GPP2 vendor specific attribute. Refer to Annex D, RADIUS
20 Attributes. This attribute may also be added by the proxy AAA server prior to forwarding the Access-
21 Request to the home AAA server.
22 On receipt of the MS/AT’s CHAP response, the AN shall create an A12 Access-Request containing at a
23 minimum:
24 User-Name (1)1= NAI
25 CHAP-Password (3) = CHAP ID and CHAP-response
26 NAS-IP-Address (4) = IP address of AN
27 CHAP-Challenge (60)= challenge value issued by AN
28 1xEV-DO Terminal Authentication (defined in Annex D) = Used to indicate that the Access
29 Request message in the context of terminal authentication.
30 Note: The CHAP authentication password should be cryptographically strong. One recommendat-
31 ion for password generation can be found in RFC 1750, Randomness Recommendations for
32 Security, Section 7.1.
33 Upon successful authentication the local RADIUS server shall send a RADIUS Access-Accept message
34 to the AN on the A12 interface. The Access-Accept shall contain at a minimum the 3GPP2 vendor spec-
35 ific attribute:
36
1 The numbers in this list correspond to the RADIUS attribute type defined in RFC 2865.
4-2
SP-3-0009 (TIA/EIA/IS-878)
1 Callback-Id (20) is populated with the MN ID (i.e., IMSI) and the String field shall be set as
2 follows:
7 6 5 4 3 2 1 0 Octet
Identity Digit 1 = [0H-9H] (BCD) Odd/even Type of Identity 1
Indicator = [110] (MN ID)
= [1,0]
Identity Digit 3 = [0H-9H] (BCD) Identity Digit 2 = [0H-9H] (BCD) 2

OOO OOO OOO
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
3 The Odd/Even Indicator (octet 3; bit 3) field is set to ‘0’ for an even number of digits and to ‘1’
4 for an odd number of identity digits.
5 The identity digits (octet 3 etc.) are coded as follows:
6 The International Mobile Subscriber Identifier fields are coded using BCD coding format. If the
7 number of identity digits is even then bits 4 to 7 of the last octet shall be filled with an end mark
8 coded as ‘1111’.
9
10 4.3.3 Radius Server Requirements

11 RADIUS Server shall follow the guidelines specified in RFC 2865.
12 If the MS/AT uses CHAP, the RADIUS server receives a RADIUS Access-Request on the A12 interface
13 from the AN with CHAP authentication information. If the RADIUS server does not have the authority
14 to accept/deny the request, it forwards the request to the home network or a peer (e.g., a broker), in
15 accordance with RFC 2865. In this case, the RADIUS server later receives a RADIUS A12 Access-
16 Accept message from the home or broker network. The RADIUS server shall then send the RADIUS
17 Access-Accept to the AN, on the A12 interface.
18 Communications security between RADIUS servers may optionally be protected with IP security. The
19 establishment of this security association is outside the scope of this standard. Also see RFC 2865 for
20 additional RADIUS security requirements.
21
22
4-3
SP-3-0009 (TIA/EIA/IS-878)
1 4.4 A13 (AN - AN) Interface

2 The information exchanged between the source and target AN is divided up into information in the target
3 to source direction, and source to target direction.
4 The information content in the target to source direction is as follows:
5 Received UATI. This is the previous UATI received by the target AN from the MS/AT, which allows
6 the source AN to determine the session configuration parameters that are requested by the target.
7 Security Layer Packet. This is the Security Layer packet, including protocol header and trailer, as
8 received from the MS/AT.
9 Sector ID. The target AN shall set this field to the 128-bit identifier of the sector on which the UATI-
10 Request message is received.
11 The information content in the source to the target direction is as follows:
12 MN ID used by the source AN over the A10 interface. This allows the target AN to use the same MN
13 Identifier once the new A10 connection has been setup. By using the same MN identifier as used in
14 the previous A10 connection, the PDSN (using current TSG-P procedures) can use this identifier to
15 use the same PPP instance.
16 The Session Configuration Parameters. The Session Configuration parameters include the Session
17 Key (Skey) and Air interface protocols states, and allow the target AN to verify that the received
18 access messages belong to the owner of the session. Additionally, this information also allows the
19 target AN to continue to use the air interface protocols already negotiated between the MS/AT and
20 the source AN.
21 PDSN address. This routable IP v4 address allows the target AN to reconnect (when possible) to the
22 same PDSN without executing a PDSN re-selection algorithm (if specified) or an internal PDSN
23 selection algorithm.). For the case of idle inter-AN inter-PCF handoff, the target PCF may use the
24 PDSN address received from the source AN to send the A11-Registration Request. Otherwise, the
25 target PCF shall use the PDSN selection algorithm (if supported) or internal algorithms to select a
26 PDSN.
27 PANID. This information allows the target AN to inform the PDSN of the PANID, in the case that it
28 is not provided by the MS/AT over the air interface. The PANID, along with CANID information,
29 allows the PDSN to determine if there is a need to do an agent advertisement. For the case of idle
30 inter-AN handoff, the target AN shall use the PANID received from the AT. If the AT does not send
31 the PANID or the AN chooses not to request this information from the AT, then the target AN may
32 use the PANID received from the source AN.
33 Note: Since the AT may have visited an IS-2000 system and established a data session between the
34 time it made an idle handoff from the source AN to target AN, the target AN shall use the PANID
35 given to it by the AT (if any) over the PANID received in the A13-Session Information Accept
36 message from the source AN.
37 4.4.1 A13 Interface Network/Transport Protocol Specification

38 Signaling over the A13 interface require a reliable transport protocol and appropriate addressing and
39 routing mechanisms to deliver messages from target to source destination. The IOS application is inde-
40 pendent of the underlying transport, which is left to the discretion of operators and manufacturers. The
41 signaling protocol stack available to operators and manufacturers for the A13 interface is:
42 IOS Application
43 TCP/UDP
44 IP
45 Link Layer
46 Physical Layer
47 A new TCP connection is established when a signaling message related to a call has to be exchanged over
48 an interface, and no such connection exists over the particular interface. Normal TCP connection
4-4
SP-3-0009 (TIA/EIA/IS-878)
1 establishment procedures are used. An existing TCP connection over an interface is released when there
2 are no more signaling messages to be exchanged over the interface. Normal TCP connection release pro-
3 cedures are used. The following TCP and UDP port values are reserved for signaling on the A13 inter-
4 face:
5 A13 (AN-to-AN) 3125/tcp - This is the well-known TCP port number to be used for signaling
6 interconnection to another AN.
7 A13 (AN-to-AN) 3125/udp - This is the well-known UDP port number to be used for signaling
8 interconnection to another AN.
9 4.4.2 A13 Interface Procedures

10 This section describes the messages and procedures used between ANs on an A13 connection. The pro-
11 cedure for the A13 interface is a message flow to exchange MS/AT and PDSN information between the
12 ANs. The information is exchanged via the following messages:
13 A13-Session Information Request
14 A13-Session Information Response
15 A13-Session Information Confirm
16 A13-Session Information Reject
17 The procedure(s) for how the target AN discovers the source AN is left as a vendor implementation.
18 4.4.2.1 A13-Session Information Request

19 The A13-Session Information Request message is sent by the target AN to request information about an
20 MS/AT from a source AN when the target AN does not have this information.
21 4.4.2.1.1 Successful Operation

22 When the target AN receives a UATI Request from an MS/AT for which the target AN has not assigned a
23 UATI, the target AN attempts to retrieve session related information from the source AN for the MS/AT.
24 The target AN sends an A13-Session Information Request message to the source AN to indicate the in-
25 formation requested. The target AN shall include the received UATI, Security Layer Packet and Sector
26 ID. The target AN then starts timer TA13req.
27 Refer to section 4.4.3.1, “A13-Session Information Request“ for the format and content of this message.
28 4.4.2.1.2 Failure Operation

29 If timer TA13req expires, the target AN may choose to resend the A13-Session Information Request
30 message a second time, If TA13req expires a second time or if the target AN chooses not to resend the A13-
31 Request message, the target AN shall begin new session establishment with the MS/AT.
32 4.4.2.2 A13-Session Information Response

33 The A13-Session Information Response message is used by the source AN to respond to target AN about
34 a request to retrieve information about an MS/AT.

36 When the source AN receives an A13-Session Information Request message it checks if the session in-
37 formation for the requested MS/AT exists and if it can authenticate the target AN request. After the
38 source AN has successfully authenticated the message contained in the A13-Session Information Request
39 and has the requested session state information, it sends an A13-Session Information Response message
40 to the target AN with the requested information.
41 Upon receipt of the A13-Session Information Response message, the target AN stops timer TA13req.
42 Refer to section 4.4.3.4, “A13-Session Information Response “ for the format and content of this message.
4-5
SP-3-0009 (TIA/EIA/IS-878)

2 None.
3 4.4.2.3 A13-Session Information Confirm

4 The A13-Session Information Confirm message is used by the target AN to inform the source AN that the
5 target AN has successfully received the session information about an MS/AT.

7 When the target AN receives the A13-Session Information Response message from the source AN with
8 the requested MS/AT information it shall send an A13-Session Information Confirm to the source AN.
9 Upon receipt of the A13-Session Information Confirm message, the source AN shall remove the stored
10 session information related to the MS/AT in question.
11 Refer to section 4.4.3.2, “A13-Session Information Confirm“ for the format and content of this message.

13 None.
14 4.4.2.4 A13-Session Information Reject

15 The A13-Session Information Reject message is used by the source AN to reject a request from the target
16 AN to retrieve session information from source AN.

18 When the source AN receives an A13-Session Information Request message and it can not retrieve the
19 session information or can not authenticate the target AN, the source AN responds by sending an A13-
20 Session Information Reject message to the target AN.
21 Upon receipt of the A13-Session Information Reject message, the target AN stops timer TA13req. After
22 sending the A13-Session Information Reject message, if it exists, the source AN may retain the session
23 information.
24 Refer to section 4.4.3.3, “A13-Session Information Reject“ for the format and content of this message.

26 None.
27
28
4-6
SP-3-0009 (TIA/EIA/IS-878)
1 4.4.3 A13 Message Definitions
2 4.4.3.1 A13-Session Information Request Message

3 This message is sent from the target AN to the source AN to request session control information for a
4 particular MS/AT.
Information Element Section Reference Element Direction Type
A13 Message Type 4.4.4.1 Target Source M
UATI 4.4.4.2 Target Source O R
Security Layer Packet 4.4.4.3 Target Source O R
Sector ID 4.4.4.4 Target Source O R
6 The following table shows the bitmap layout for the A13-Session Information Request Message
7 6 5 4 3 2 1 0 Octet
A13 Message Type = [01H] 1
UATI: A13 Element Identifier = [01H] 1
Length = [0FH] 2
UATI Type = [01] 3
(MSB) UATI 4
5
OOO OOO
(LSB) N
Security Layer Packet: A13 Element Identifier = [02H] 1
Length = [variable] 2
(MSB) Security Layer Packet 3
4
OOO OOO
(LSB) N
Sector ID: A13 Element Identifier = [03H] 1
Length = [0FH] 2
(MSB) Sector ID 3
4
OOO OOO
(LSB) N
4-7
SP-3-0009 (TIA/EIA/IS-878)
1 4.4.3.2 A13-Session Information Confirm Message

2 This message is sent from the target AN to the source AN to indicate that the target AN has successful
3 received the session control information for the requested MS/AT.
A13 Message Type 4.4.4.1 Target Source M
UATI 4.4.4.2 Target Source O R
5 The following table shows the bitmap layout for the A13-Session Information Confirm Message
7 6 5 4 3 2 1 0 Octet
Length = [0FH] 2
UATI Type = [01H] 3
(MSB) UATI 4
5
OOO OOO
(LSB) N
7 4.4.3.3 A13-Session Information Reject Message

8 This message is sent from the source AN to the target AN to indicate that the request for session control
9 information has been denied.
A13 Message Type 4.4.4.1 Source Target M
UATI 4.4.4.2 Source Target O R
Cause 4.4.4.5 Source Target O C
10
11 The following table shows the bitmap layout for the A13-Session Information Reject Message
7 6 5 4 3 2 1 0 Octet
Length = [0FH] 2
UATI Type = [01H] 3
(MSB) UATI 4
5
OOO OOO
(LSB) N
-- Continued on next page --
12
4-8
SP-3-0009 (TIA/EIA/IS-878)
-- Continued from previous page --

Cause: A13 Element Identifier [04H] 1
Length = [03H] 2
Cause Value = [ 01H (Protocol Subtype Not Recognized), 3
02H (Protocol Subtype Attribute(s) Not Recognized)
03H (Protocol Subtype Attribute(s) Missing)
04H (Requested Session Not Found)
05H (Requested Session Not Authentic)]
3 4.4.3.4 A13-Session Information Response Message

4 This message is sent from the source AN to the target AN and includes the requested session control
5 information.
A13 Message Type 4.4.4.1 Source Target M
UATI 4.4.4.2 Source Target O R
Mobile Identity (MN ID) 4.4.4.6 Source Target O R
PDSN Address 4.4.4.7 Source Target O R
Access Network Identifiers 4.4.4.8 Source Target O R
AN State Information Record 4.4.4.9 Source Target O R
7 The following table shows the bitmap layout for the A13-Session Information Response Message
7 6 5 4 3 2 1 0 Octet
Length = [0FH] 2
UATI Type = [01H] 3
(MSB) UATI 4
5
OOO OOO
(LSB) N
8
4-9
SP-3-0009 (TIA/EIA/IS-878)

Mobile Identity (MN ID): A13 Element Identifier = [05H] 1
Length = 14-15 digits 2
= [1,0]
OOO OOO OOO
Identity Digit N+1 = [0H-9H] (BCD) Identity Digit N = [0H-9H] (BCD)
N
PDSN IP Address: A13 Element Identifier [06H] 1
Length = [06H] 2
(MSB) PDSN IP Address 3
4
5
(LSB) 6
Access Network Identifiers: A13 Element Identifier [07H] 1
Type = 01H 2
Length = [07H] 3
Reserved (MSB) SID 4
(LSB) 5
(MSB) NID 6
(LSB) 7
PZID 8
AN State Information Record: A13 Element Identifier [08H] 1
Length = [variable] 2
(MSB) AN State Information Record 3
OOO OOO
(LSB) N
4-10
SP-3-0009 (TIA/EIA/IS-878)
1 4.4.4 A13 Information Element Definitions
2 4.4.4.1 Information Element Identifiers

3 The following table lists all the elements that make up the messages defined in Section 4.4.3. The table
4 includes the Information Element Identifier (IEI) coding which distinguishes one element from another.
5 The table also includes a section and page reference where the element coding can be found.
6 Table 4.4.5.1 A13 Information Element Identifiers
Element Name Identifier (Hex) Identifier (Binary) Reference

UATI 01H 0000 0001 4.4.4.3
Security Layer Packet 02H 0000 0010 4.4.4.4
SectorID 03H 0000 0011 4.4.4.5
Cause 04H 0000 0100 4.4.4.6
Mobile Identity (MN ID) 05H 0000 0101 4.4.4.7
PDSN IP Address 06H 0000 0110 4.4.4.8
Access Network Identifiers 07H 0000 0111 4.4.4.9
AN State Information Record 08H 0000 1000 4.4.4.10
7 4.4.4.2 A13 Message Type

8 The A13 Message Type element is used to indicate the type of message on the A13 interface.
A13 Message Name A13 Message Type Section Reference

A13-Session Information Request Message 01H 4.4.3.1
A13-Session Information Confirm Message 02H 4.4.3.2
A13-Session Information Reject Message 03H 4.4.3.3
A13-Session Information Response Message 04H 4.4.3.4
9 4.4.4.3 Unicast Access Terminal Identifier (UATI).

10 This element is set to the terminal identifier associated with the MS/AT.
7 6 5 4 3 2 1 0 Octet
A13 Element Identifier 1
Length 2
UATI Type = [01H] 3
(MSB) UATI 4
5
OOO OOO
(LSB) N
11 Length This field contains the number of octets in this element following this field as a
12 binary number.
13 UATI Type This field indicates the type of the UATI. The supported values are listed as
14 follows.
4-11
SP-3-0009 (TIA/EIA/IS-878)
UATI Type Length Description

01H 11H UATI128
02H 05H UATI32 (UATI Color Code + UATI024)
All other values are reserved
1 UATI This is set to the terminal identifier associated with the MS/AT.
2
3 4.4.4.4 Security Layer Packet

4 This element is set to the security layer packet received from the MS/AT.
7 6 5 4 3 2 1 0 Octet
Length 2
(MSB) Security Layer Packet 3
4
OOO OOO
(LSB) N
6 binary number.
7 Security Layer Packet This is set to the security layer packet received from the MS/AT.
8
9 4.4.4.5 SectorID
10 The AN shall set this field to the 128-bit address of this sector.
7 6 5 4 3 2 1 0 Octet
Length 2
(MSB) Sector ID 3
4
OOO OOO
(LSB) N
11 Length This field shall be set to the length of this element in octets following the Length
12 Field.
13 Sector ID This is set to the address of the sector.
14
4-12
SP-3-0009 (TIA/EIA/IS-878)
1 4.4.4.6 Cause
2 This element is used to indicate the reason for occurrence of a particular event and is coded as shown
3 below.
7 6 5 4 3 2 1 0 Octet
Length 2
(MSB) Cause Value (LSB) 3
5 binary number.
6 Cause Value This field is set to the range of values below:
7
Hex Values Meaning

01 Protocol Subtype Not Recognized
02 Protocol Subtype Attribute(s) Not Recognized
03 Protocol Subtype Attribute(s) Missing
04 Requested Session Not Found
05 Requested Session Not Authentic
8
9 4.4.4.7 Mobile Identity (MN ID)

10 This element is used to provide the Access Terminal’s Mobile Node Identification (MN ID).
7 6 5 4 3 2 1 0 Octet
Length = 14-15 digits 2
= [1,0]
OOO OOO OOO
Identity Digit N+1 = [0H-9H] (BCD) Identity Digit N = [0H-9H] (BCD) N
12 binary number.
13
14
4-13
SP-3-0009 (TIA/EIA/IS-878)
1 4.4.4.8 PDSN IP Address

2 This element is used to provide the PDSN address.
7 6 5 4 3 2 1 0 Octet
A1 Element Identifier = [13H] 1
Length 2
(MSB) PDSN IP Address 3
4
5
(LSB) 6
3 Length This field contains the number of octets in this element following this
4 field as a binary number.
5 PDSN IP Address This field is set to the IPv4 address of a PDSN.
6
7 4.4.4.9 Access Network Identifiers

8 This element uniquely identifies the PCF an is used by the PDSN to determine if it owns the connection.
9 If so the PDSN does not need to send agent advertisements. If not, then the PDSN needs to trigger an MIP
10 Registration Request so that the Foreign Agent/Home Agent tunnel is set up properly.
7 6 5 4 3 2 1 0 Octet
Type = 01H 2
Length 3
Reserved (MSB) SID 4
(LSB) 5
(MSB) NID 6
(LSB) 7
PZID 8
11 Type This field identifies the ANID Sub Type (01H).

13 binary number.
14 SID This two octet field is coded to the vale that uniquely identifies the cellular or
15 PCS system.
16 NID This two octet field is coded to the vale that uniquely identifies the network
17 within a cellular or PCS system.
18 PZID This one octet field is coded to the vale that uniquely identifies the Packet
19 Control Function (PCF) coverage Area within a particular SID/NID area. The
20 combined SID/NID/PZID triplet is unique to a PCF.
21
4-14
SP-3-0009 (TIA/EIA/IS-878)
1 4.4.4.10 AN State Information Record

2 This element is used to send 1xEV-DO Session Information as specified in TIA/EIA/IS-856.
7 6 5 4 3 2 1 0 Octet
Length 2
(MSB) AN State Information Record 3
OOO OOO
(LSB) N
3 Length This field contains the number of octets in this element following
4 this field as a binary number.
5 AN State Information Record This field contains the air interface protocol attributes and
6 associated public data. - The format is as specified in
7 TIA/EIA/IS-856.
8
10
4-15
SP-3-0009 (TIA/EIA/IS-878)
1 No text.
2
4-16
SP-3-0009 (TIA/EIA/IS-878)
1 5 1xEV-DO IOS Timer Definitions

2 This section describes the timers associated with the 1xEV-DO IOS specification.
Timer Default Range of Section

Name Value Values Granularity Reference Classification
(seconds) (seconds) (seconds)
Tairdrop 5 0.1 – 60.0 0.1 5.1 Call Processing
3
4 5.1 Timer Tairdrop

5 This AN timer indicates when a 1xEV-DO connection has been lost.
6
5-1
SP-3-0009 (TIA/EIA/IS-878)
1 No text.
2
5-2
SP-3-0009 (TIA/EIA/IS-878)
1 Annex A Informative 1xEV-DO IOS Phase 1+ Annex

2 A.1 1xEV-DO IOS Phase 1+ Architecture Reference Model
3 TSG-A consensus was reached that the desired AN/PCF restructuring cannot be completed on the agreed
4 schedule for the Phase 1 IOS. The requested restructuring is shown in Figure A.1-1. Note that a portion
5 of the AN functionality (e.g., session control and mobility) is to evolve from the AN into a new PCF
6 entity (which also includes the current PCF functionality). Some proposals also suggest further restruct-
7 uring of the AN and PCF functions, but no consensus was reached, and these are to be discussed after the
8 Phase 1 IOS development is completed.
Phase 1
A8 A10
Access
Access Terminal
Network PCF PDSN
(AT)
(AN) A9 A11
Session
Control
A12
A13 Proxy
AN AAA
AN AAA
Session
Control
A8 A10
Access
Access Terminal
Network PCF PDSN
(AT)
(AN) A9 A11
A12
Proxy
AN AAA
AN AAA
Future
A8' A10
Access Terminal Access Network
PCF' PDSN
(AT) (AN')
A9' Session
A11
Control
A12
Aa' Ab' A13' Proxy

AN AAA
AN AAA
A8' A10
Access Terminal Access Network
PCF' PDSN
(AT) (AN')
A9' Session
A11
Control
A12
Proxy
AN AAA
AN AAA
10 Figure A.1-1 1xEV-DO IOS Phase 1+ Architecture Reference Model

11
A-1
SP-3-0009 (TIA/EIA/IS-878)
1 Items identified for future study include:

2 N Determination of the architectural entity in which the location of session control exists.
3 N Enhancements to status management, using the network.
4
A-2
SP-3-0009 (TIA/EIA/IS-878)
1 Annex B A8-A9 (AN - PCF) Interface Change Text

2 2.14 Packet Data Calls
3 Data services are grouped into two categories: circuit-oriented (includes Asynchronous Data and Group-3
4 Fax services) and packet. Procedures applicable to packet data calls are described in this section. See
5 Section 6.2.2.66 for valid service options. Note some service options are only valid for Intergeneration
6 Handoff (handoff between systems supporting packet data services based on ANSI/TIA/EIA/IS-95-B and
7 systems supporting packet data service based on TIA/EIA/IS-2000). Intergeneration Handoffs are
8 described in Annex D.
9 Note: When the procedures between TIA/EIA/IS-95-B / IS-2000 and 1xEV-DO systems differ, the 1xEV-
10 DO procedures are identified separately within this specification. When the IOS text is applied to the
11 1xEV-DO RAN specification, the procedures related to the MSC shall be ignored. Hard Handoff proced-
12 ures are not applicable to 1xEV-DO.
13 For all calls supporting packet data services, a Packet Data Serving Node (PDSN) exists that interfaces
14 between the transmission of the data in the fixed network and the transmission of the data over the air
15 interface. The PDSN interfaces to the BS through a Packet Control Function (PCF), which may or may
16 not be co-located with the BS.
17 For purposes of the protocol of this standard, there are three packet data service states: Active/Connected,
18 Dormant, and Null/Inactive. In the Active/Connected State, a physical traffic channel exists between the
19 mobile station and the base station, and either side may send data. In the Dormant State, no physical
20 traffic channel exists between the mobile station and the base station, but the PPP link between the mobile
21 station and the PDSN is maintained. In the Null/Inactive State, there is no traffic channel between the
22 mobile station and the base station and no PPP link between the mobile station and the PDSN.
23
Active / Dormant
Connected State
State
Null/Inactive
State
24
25 Figure 2.14-1 - Packet Data Service State Transitions

26 In TIA/EIA/IS-2000 systems, A1 and A8 connections are maintained during the Active / Connected State
27 and released during transition to Dormant or Null/Inactive State. The A10 connection is maintained
28 during the Active/Connected and the Dormant State.
29 In 1xEV-DO systems, the A8 connection is maintained during the Active / Connected State and released
30 during transition to Dormant or Null/Inactive State. The A10 connection is maintained during the Active /
31 Connected and the Dormant State.
32 As part of the support for the Dormant State, the TIA/EIA/IS-2000 air interface supports a Data Ready to
33 Send indicator that is used on Origination. When a mobile terminal station sends an origination request
34 with a packet data service option specified, it will includes the Data Ready to Send (DRS) bit. This
35 indicator is will be set to 1 on initial call setup and when the terminal wishes to transitions from Dormant
36 to Active because it has data to send and is requesting the establishment of a traffic channel. The DRS bit
37 is will be set to 0 to indicate that the terminal has transitioned crossed a Packet Zone boundary while
38 dormant, and is sending the origination request to update the network as to its current location.
B-1
SP-3-0009 (TIA/EIA/IS-878)
1 In 1xEV-DO systems when data is ready to be sent, a ConnectionRequest message is sent on initial call
2 setup to transition from Dormant to Active for the purposes of requesting the establishment of a traffic
3 channel. A UATI assignment is requested when the terminal has detected change of subnet while
4 dormant, to update the network as to its current location.
5 On receipt of an origination with the DRS bit set to 1 or a ConnectionRequest message in a 1xEV-DO
6 system, the BS will initiates the call setup procedure as shown in Section 2.14.7.1, which will normally
7 results in the establishment of a traffic channel and in the A8 and A10 bearer connections being establish-
8 ed.
9 When the BS receives an origination with the DRS bit set to 0 or a request for UATI assignment in a
10 1xEV-DO system, the BS will delays the establishment of a traffic channel until after the A8 and A10
11 bearer connection establishment procedures are complete. During the A8 bearer connection establishment
12 procedure, the BS will indicates to the PCF that a DRS=0 has been received (or there is no indication of
13 data ready to be exchanged, for 1xEV-DO systems) through the use of the Data Ready Indicator element
14 in the A9-Setup-A8 message. If the PCF has data from the network to deliver to the terminal, it will
15 indicates this by setting the Cause element in the A9-Connect-A8 message to the Data Ready to Send
16 value. The BS will then establishes a traffic channel to the terminal and complete a normal call setup
17 procedure as in Section 2.14.7.1.
18 If the PCF does not have data, it indicates that the A8 is not being established by sending the A9-Release-
19 A8 Complete message to the BS. The BS will then returns an Assignment Failure message to the MSC
20 with the Cause value set to Packet Call Going Dormant. Upon receipt of the Assignment Failure message,
21 the MSC returns a Clear Command to the BS with the Cause value set to Do Not Notify Mobile. The BS
22 sends a Clear Complete message to the MSC upon receipt of the Clear Command message.
23 2.14.1 Packet Data Assumptions

24 No changes from TIA/EIA/IS-2001-A text.
25 2.14.2 Previous and Current Access Network Identifiers (PANID/CANID)

27 2.14.3 PDSN Selection Algorithm

29 2.14.4 A8/A9 Interface Procedures

31 2.14.4.1 A8/A9 Interface Setup Procedures And Messages

33 2.14.4.1.1 A9-Setup-A8
35 2.14.4.1.1.1 Successful Operation

36 When the BSC receives an Assignment Request from the MSC, as a result of sending a CM Service
37 Request (in response to an Origination Mmessage from the mobile with a Service Option that requests
38 packet data service and with the DRS bit set to 1), or as a result of sending a Page Response, or upon
39 receipt of a traffic channel request (i.e. ConnectionRequest message) in a 1xEV-DO system, it initiates
40 the procedure for establishing radio traffic channels. After establishing traffic channels, the BSC
41 determines the characteristics for an A8 connection such as QoS and generates an A9-Setup-A8 message
42 indicating the normal call setup (i.e., the handoff indicator field of the A9-Setup-A8 message is set to ‘0’).
B-2
SP-3-0009 (TIA/EIA/IS-878)
1 The BSC sends the message to the PCF on the A9 interface and starts timer TA8-Ssetup. Upon receiving the
2 message, the PCF initiates the procedure for establishing an A10 connection.
3 After establishing an A10 connection, the PCF sends an A9-Connect-A8 message to the BSC. For the
4 case where the DRS bit received from the mobile is set to 0 or a request for a traffic channel is not
5 received in the 1xEV-DO system, the BSC will awaits the response from the PCF to determine if a traffic
6 channel needs to be established.
7 When the mobile station performs a hard handoff during packet services, the target BSC sends the A9-
8 Setup-A8 message upon receipt of the Handoff Request message from the MSC and starts timer TA8-sSetup.
9 In this case, the BSC sets the Handoff Indicator field of the A9-Setup-A8 message to ‘1’ and Data Ready
10 Indicator is set to ‘1’.
11 In the case of dormant handoff the BSC sends the A9-Setup-A8 message to the PCF upon receipt of the
12 Assignment Request message from the MSC or upon completion of the UATI assignment in 1xEV-DO
13 systems. For this case, it will sets both the Data Ready Indicator and the Handoff Indicator to 0. Please
14 refer to section 6.1.10.1, “A9-Setup-A8,” for the format and content of this message. Alternatively, if
15 upon receipt of the A9-Setup-A8 message, if the PDSN has no data to send to the MS (in the case of a
16 dormant handoff) or if the PCF could not setup the A8 connection due to PDSN resources being
17 unavailable, the PCF will sends the A9-Release-A8 Complete message. Upon receipt of this message, the
18 BSC stops timer TA8-Ssetup.
19 If the A9-Setup-A8 message contains a DRS IndicatorDRI set to '0' and the PCF does not have data to
20 send, the PCF rejects the attempt to setup the A8 connection by sending an A9-Release- A8-Complete
21 message to the BSC.
22 2.14.4.1.1.2 Failure Operation

23 If the BSC fails to receive an A9-Connect-A8, that is to say, the timer TA8-setup has expired before receiv-
24 ing an A9-Connect-A8 or A9-Release-A8 Complete message, the BSC sends an Assignment Failure
25 message or a Handoff Failure message, as appropriate, to the MSC. If the A10/A11 connection establish-
26 ment procedure is required but fails, the PCF should send an A9-Release-A8 Complete message with
27 Cause value set to “PDSN resources not available (0x79)". In a 1xEV-DO system, the BSC may re-send
28 the A9-Setup-A8 message or release the traffic channel if it exists.
29 2.14.4.1.2 A9-Connect-A8


35 2.14.4.1.3 A9-BS Service Request



41 2.14.4.1.4 A9-BS Service Response
B-3
SP-3-0009 (TIA/EIA/IS-878)


6 2.14.5 A8/A9 Interface Clearing Procedures and Messages

8 2.14.5.1 Successful Clearing Scenarios

9 An A8 connection clearing occurs:
10 N when a packet data inactivity timer in the BSC expires. The BSC, after sending the Clear Request
11 message, sets timer T300 and waits for a Clear Command message from the MSC. To release all
12 allocated resources, the MSC shall send a Clear Command message to the BSC, start timer T315, and
13 wait for the Clear Complete message from the BSC. After stopping timer T300 and releasing the air
14 resources, the BSC sends an A9-Release-A8 message to the PCF and starts timer Trel9. The PCF
15 responds with an A9-Release-A8 Complete message. Then the BSC sends a Clear Complete message
16 and stops timer Trel9. The IS-2000 system call flow scenario is illustrated in section 2.14.7.2 "BS
17 Initiated Call Release to Dormant State." The 1xEV-DO system call flow scenario is illustrated in
18 section 2.4.3, “Radio Session Tear-Down - Initiated by the AN”.
19 N when the packet data inactivity timer in the MS expires. When the BS receives a Release Order or
20 ConnectionClose for 1xEV-DO systems, requesting the transition to dormant, the BSC shall send a
21 Clear Request message to the MSC. The rest of the procedure is same as the BSC initiated scenario.
22 The IS-2000 system call flow scenario is illustrated in section 2.14.7.3 "MS Initiated Call Release to
23 Dormant State." The 1xEV-DO system call flow scenario is illustrated in section 2.4.1, “Session
24 Tear-Down - Initiated by the AT”.
25 N when the MS releases the call or to indicate to the BSC that an A8 connection can will not be
26 established due to either PDSN resources being unavailable or during dormant handoff if the PDSN
27 has no data to send. When the BSC receives a Release Order or ConnectionClose for 1xEV-DO
28 systems, the BSC shall send a Clear Request message to the MSC and start timer T300. To release all
29 allocated resources, the MSC shall send a Clear Command message to the BSC, start timer T315, and
30 wait for the Clear Complete message from the BSC. After stopping timer T300 and releasing the air
31 resources with the Release Order or ConnectionClose for 1xEV-DO systems, the BSC sends an A9-
32 Release-A8 message to the PCF and starts timer Trel9. The PCF responds with an A9-Release-A8
33 Complete message. Then the BSC sends a Clear Complete message and stops timer Trel9. The IS-2000
34 system call flow scenario is illustrated in section 2.14.7.4 "MS Power Down." There is no 1xEV-DO
35 scenario for “AT Power Down”.
36 N when the A10/A11 connection is released by the PDSN. When the PCF detects that the A10/A11
37 connection is released, the PCF sends an A9-Disconnect-A8 message to the BSC and starts timer
38 Tdiscon9. Then the BSC initiates the release of the A8 connection by sending an A9-Release-A8
39 message and starts timer Trel9. The PCF responds with an A9-Release-A8 Complete message and
40 stops timer Tdiscon9. The BSC, after sending the Clear Request message and stopping timer Trel9, sets
41 timer T300 and waits for a Clear Command message from the MSC. To release all allocated resources,
42 the MSC shall send a Clear Command message to the BSC, start timer T315, and wait for the Clear
43 Complete message from the BSC. Then the BSC stops timer T300, releases the air resources, and
44 responds with a Clear Complete message. The IS-2000 system call flow scenario is illustrated in sect-
45 ion 2.14.7.5 “PDSN Initiated Service Release." The 1xEV-DO system call flow scenario is illustrated
46 in section 2.4.2, “A10 Tear-Down - Initiated by the PDSN”.
B-4
SP-3-0009 (TIA/EIA/IS-878)
1 2.14.5.2 Unsuccessful A8 Interface Clearing Procedures

3 2.14.5.3 A9-Release-A8


9 2.14.5.4 A9-Release-A8 Complete



15 2.14.5.5 A9-Disconnect-A8


21 2.14.5.6 A9-Update-A8
22 This A9 interface message is sent from the BSC to the PCF and is used in several cases. First, it is used to
23 convey accounting information to the PCF if the A8 connection is established before traffic channel
24 establishment (in which case the PCF will resumes data transmission on the A8 connection only after it
25 receives the A9-update-A8 message) or during an active session following accounting parameters changes
26 which need to be conveyed to the PDSN indirectly via the PCF.
27 This A9 interface message can also be used to inform the PCF of an authentication failure at the MSC or
28 AN-AAA for 1xEV-DO systems, following an access attempt by a mobile undergoing dormant handoff.
29 The BSC can also use this message to inform the PCF that a dormant mobile has powered down. In these
30 two cases, the PCF initiates the release of the A10 connection associated with the mobile. This A9
31 message may also be used to indicate to the PCF a successful Short Data Burst delivery.
32 2.14.5.6.1 Successful operation

34 2.14.5.6.2 Failure operation

B-5
SP-3-0009 (TIA/EIA/IS-878)
1 2.14.5.7 A9-Update-A8 Ack

3 2.14.5.7.1 Successful operation

5 2.14.5.7.2 Failure operation

7 2.14.6 A8/A9 Interface Handoff Procedures and Messages

9 2.14.6.1 A9-Air Link (AL) Connected



15 2.14.6.2 A9-Air Link (AL) Connected Ack



21 2.14.6.3 A9-Air Link (AL) Disconnected



27 2.14.6.4 A9-Air Link (AL) Disconnected Ack



B-6
SP-3-0009 (TIA/EIA/IS-878)
1 OOO
2 6.1.10 A9 Interface Message Formats
3 6.1.10.1 A9-Setup-A8
4 This A9 interface message is sent from the BS to the PCF to request the establishment of an A8
5 connection.
Information Element Section Element Direction Type
Reference
A9 Message Type 6.2.2.167 BS -> PCF M
Call Connection Reference 6.2.2.98 BS -> PCF O R
Correlation ID 6.2.2.108 BS -> PCF Oa C
Mobile Identity (IMSI) 6.2.2.16 BS -> PCF Og R
Mobile Identity (ESN) 6.2.2.16 BS -> PCF Ob C
CON_REF 6.2.2.168 BS -> PCF Oh R
Quality of Service Parameters 6.2.2.54 BS -> PCF Oc C
A9 BSC_ID 6.2.2.169 BS -> PCF O R
A8_Traffic_ID 6.2.2.170 BS -> PCF O R
Service Option 6.2.2.66 BS -> PCF Of R
A9 Indicators 6.2.2.171 BS -> PCF O R
User Zone ID 6.2.2.32 BS -> PCF Oi C
IS-2000 Service configuration record 6.2.2.68 BS -> PCF Oe C
Access Network Identifiers 6.2.2.189 BS -> PCF Od C
6 a. If this element is included in this message, its value shall be returned in the corresponding element in
7 the A9-Connect A8 message sent in response to this message.
8 b. This second occurrence of the Mobile Identity element, if included, shall contain the ESN of the MS.
9 Use of the ESN in this message is a network operator decision. This information element shall not be
10 included in 1xEV-DO messages.
11 c. This information element is included if information is available at the BS. In this version of this
12 standard, this element is used to carry the current non-assured mode priority of the packet data
13 session. This information element shall not be included in 1xEV-DO messages.
14 d. The Access Node Identifiers (PANID) are included if received from the MS..
15 e. This information element may be omitted if the BS does not possess this information at the time the
16 message if created. This information element shall not be included in 1xEV-DO messages.
17 f. The User Zone ID is included if received from the MS.
18 g. This information element shall be set to the MN ID, associated with the A10 connection, for 1xEV-
19 DO messages.
20 h. The IS-2000 CON_REF field of this information element shall be set to 00H for padding, for 1xEV-
21 DO messages.
22 i. The UZID field of this information element shall be set to 00H for padding, for 1xEV-DO messages.
23
24 The following table shows the bitmap layout for the A9-Setup-A8 message:
B-7
SP-3-0009 (TIA/EIA/IS-878)
7 6 5 4 3 2 1 0 Octet
Call Connection Reference: A1 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) 7
Call Connection Reference = <any value> 8
9
(LSB) 10
Correlation ID: A3/A7 Element Identifier = [13H] 1
Length = [04H] 2
(MSB) 3
Correlation Value = <any value> 4
5
(LSB) 6
Mobile Identity (IMSI): A1 Element Identifier = [0DH] 1
Length = [06H-08H] (10-15 digits) 2
Indicator = [110] (IMSI)
= [1,0]
OOO OOO
Identity Digit N+1 = [0H-9H] (BCD) Identity Digit N = [0H-9H] (BCD) n
Mobile Identity (ESN): A1 Element Identifier = [0DH] 1
Length = [05H] 2
Identity Digit 1 = [0000] Odd/even Type of Identity 3
Indicator = [101] (ESN)
= [0]
(MSB) 4
ESN = <any value> 5
6
(LSB) 7
1
B-8
SP-3-0009 (TIA/EIA/IS-878)

CON_REF: A9 Element Identifier = [01H] 1
Length = [01H] 2
IS-2000 CON_REF = [00H – FFH] 3
Quality of Service Parameters: A9 Element Identifier = [07H] 1
Length = [01H] 2
Reserved = [0000] Non-Assured Mode Packet Priority = 3
[0000 – 1101]
A9 BSC_ID: A9 Element Identifier = [06H] 1
Length = [01H – 06H] 2
(MSB) BSC Identifier = <any value> 3
OOO OOO
(LSB) m
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) 6
Key = <any value> 7
8
(LSB) 9
Address Type = [01H] (IPv4) 10
(MSB) 11
IP Address = <any value> 12
13
(LSB) 14
Service Option: A1 Element Identifier = [03H] 1
(MSB) Service Option 2
= [ 00 21H TBD H (3G High Speed Packet Data) (LSB) 3
(1xEV-DO Packet Data) ]
A9 Indicators: A9 Element Identifier = [05H] 1
Length = [01H] 2
Reserved = [0000 000] Data Handoff 3
Ready indicator
Indicator = [0, 1]
= [0,1]
2
B-9
SP-3-0009 (TIA/EIA/IS-878)

User Zone ID: A1 Element Identifier = [02H] 1
Length = [02H] 2
(MSB) UZID = <any value> 3
(LSB) 4
IS-2000 Service Configuration Record: A1 Element Identifier = [0EH] 1
Bit-Exact Length – Octet Count = <variable> 2
Reserved Bit-Exact Length – Fill Bits 3
= [ 0000 0 ] = [ 000 – 111 ]
(MSB) 4
IS-2000 Service Configuration Record Content = <any value> ...
Seventh Sixth Fill Fifth Fill Fourth Third Second First Fill k
Fill Bit – Bit – if Bit – if Fill Bit – Fill Bit – Fill Bit – Bit – if
if needed needed needed if needed if needed if needed needed
= [0 (if = [0 (if = [0 (if = [0 (if = [0 (if = [0 (if = [0 (if
used as a used as a used as a used as a used as a used as a used as a
fill bit)] fill bit)] fill bit)] fill bit)] fill bit)] fill bit)] fill bit)]
Access Network Identifiers: A1 Element Identifier = [20H] 1
Length = [05H] 2
Reserve (MSB) SID = <any value> 3
d = [0]
(LSB) 4
(MSB) NID = <any value> 5
(LSB) 6
PZID = <any value> 7
B-10
SP-3-0009 (TIA/EIA/IS-878)
1 6.1.10.2 A9-Connect-A8
2 This A9 interface message is sent from the PCF to the BS to complete the setup of the A8 connection.
Reference
A9 Message Type 6.2.2.167 PCF -> BS M
Call Connection Reference 6.2.2.98 PCF -> BS O R
Correlation ID 6.2.2.108 PCF -> BS Oa C
Mobile Identity (IMSI) 6.2.2.16 PCF -> BS Od R
Mobile Identity (ESN) 6.2.2.16 PCF -> BS Ob C
CON_REF 6.2.2.168 PCF -> BS Oe R
A8_Traffic_ID 6.2.2.170 PCF -> BS O R
Cause 6.2.2.19 PCF -> BS Oc R
PDSN IP Address 6.2.2.30 PCF -> BS O R
3 a. This element shall only be included if it was also included in the A9-Setup-A8 message. This element
4 shall be set to the value received in that message.
7 included on 1xEV-DO messages.
8 c. Allowable cause values are: “PCF resources not available”; “Equipment failure”; “Successful
9 operation”, “PDSN resources are not available”, “Data ready to send”.
10 d.The PCF transmits its Access Network Identifiers (CANID) to the Base Station.
11 d. This information element shall be set to the MN ID, associated with the A10 connection, for 1xEV-
12 DO messages.
13 e. The IS-2000 CON_REF field of this information element shall be set to 00H for padding, for 1xEV-
14 DO messages.
15
16
B-11
SP-3-0009 (TIA/EIA/IS-878)
1 The following table shows the bitmap layout for the A9-Connect-A8 message:
7 6 5 4 3 2 1 0 Octet
Length = [08H] 2
(LSB) 4
(LSB) 6
(MSB) 7
9
(LSB) 10
Length = [04H] 2
(MSB) 3
5
(LSB) 6
= [1,0]
OOO OOO
Length = [05H] 2
= [0]
(MSB) 4
ESN = <any value> 5
6
(LSB) 7
2
B-12
SP-3-0009 (TIA/EIA/IS-878)

Length = [01H] 2
IS-2000 CON_REF = [00H – FFH] 3
Length = [0CH] 2
(LSB) 5
(MSB) 6
Key = <any value> 7
8
(LSB) 9
(MSB) 11
13
(LSB) 14
Cause: A9 Element Identifier = [04H] 1
Length = [01H] 2
ext = [0] Cause Value = 3
[13H (Successful operation),
20H (Equipment failure),
32H (PCF resources not available),
79H (PDSN resources are not available),
7AH (Data Ready to Send) ]
PDSN IP Address: A1 Element Identifier = [14H] 1
Length = [04H] 2
(MSB) 3
PDSN IP Address = <any value> 4
5
(LSB) 6
B-13
SP-3-0009 (TIA/EIA/IS-878)
1 6.1.10.3 A9-Disconnect-A8
2 This A9 interface message is sent from the PCF to the BS to release the associated dedicated resource.
Reference
CON_REF 6.2.2.168 PCF -> BS Oe R
A8_Traffic_ID 6.2.2.170 PCF -> BS O R
Cause 6.2.2.19 PCF -> BS Oc R
4 the A9-Release-A8 message sent in response to this message.
8 c. Allowable cause values are: “Packet call going dormant”; “Equipment failure”; “Normal call release”.
9 d. This information element shall be set to the MN ID, associated with the A10 connection, for 1xEV-
10 DO messages.
11 e. The IS-2000 CON_REF field of this information element shall be set to 00H for padding, for 1xEV-
12 DO messages.
13
14
B-14
SP-3-0009 (TIA/EIA/IS-878)
1 The following table shows the bitmap layout for the A9-Disconnect-A8 message:
7 6 5 4 3 2 1 0 Octet
Length = [08H] 2
(LSB) 4
(LSB) 6
(MSB) 7
9
(LSB) 10
Length = [04H] 2
(MSB) 3
5
(LSB) 6
= [1,0]
OOO OOO
Length = [05H] 2
= [0]
(MSB) 4
ESN = <any value> 5
6
(LSB) 7
2
B-15
SP-3-0009 (TIA/EIA/IS-878)

Length = [01H] 2
IS-2000 CON_REF = [00H – FFH] 3
Length = [0CH] 2
(LSB) 5
(MSB) 6
Key = <any value> 7
8
(LSB) 9
(MSB) 11
13
(LSB) 14
Length = [01H] 2
[10H (Packet call going dormant),
14H (Normal call release),
20H (Equipment failure) ]
B-16
SP-3-0009 (TIA/EIA/IS-878)
1 6.1.10.4 A9-Release-A8
2 This A9 interface message is sent from the BS to the PCF to release the associated dedicated resource.
Reference
A9 Message Type 6.2.2.167 BS-> PCF M
Call Connection Reference 6.2.2.98 BS-> PCF O R
Correlation ID 6.2.2.108 BS-> PCF Oa C
Mobile Identity (IMSI) 6.2.2.16 BS-> PCF Oe R
Mobile Identity (ESN) 6.2.2.16 BS-> PCF Ob C
CON_REF 6.2.2.168 BS-> PCF Of R
A8_Traffic_ID 6.2.2.170 BS-> PCF O R
Cause 6.2.2.19 BS-> PCF Oc R
Active Connection Time in Seconds 6.2.2.11 BS-> PCF Od R
4 a. This element shall be included if it was also included in the A9-Disconnect-A8 message. This
5 element shall be set to the value received in that message. If this element was not included in that
6 message, it may be included in this message.
10 c. Allowable cause values are: “Packet call going dormant”; “Equipment failure”; “Normal call
11 release”; "Handoff Successful"; “Authentication Failure”. Note that Normal Call Release indicates
12 that the service has been released and therefore the A10 resources should be dropped.
13 d. This element shall be included to indicate the active connection time for a traffic channel.
14 e. This information element shall be set to the MN ID, associated with the A10 connection, for 1xEV-
15 DO RAN messages.
16 f. The IS-2000 CON_REF field of this information element shall be set to 00H for padding, for 1xEV-
17 DO messages.
18
19
B-17
SP-3-0009 (TIA/EIA/IS-878)
1 The following table shows the bitmap layout for the A9-Release-A8 message:
7 6 5 4 3 2 1 0 Octet
Length = [08H] 2
(LSB) 4
(LSB) 6
(MSB) 7
9
(LSB) 10
Length = [04H] 2
(MSB) 3
5
(LSB) 6
= [1,0]
OOO OOO
Length = [05H] 2
= [0]
(MSB) 4
ESN = <any value> 5
6
(LSB) 7
Length = [01H] 2
IS-2000 CON_REF = [00H – FFH] 3
2
B-18
SP-3-0009 (TIA/EIA/IS-878)

Length = [0CH] 2
(LSB) 5
(MSB) 6
Key = <any value> 7
8
(LSB) 9
(MSB) 11
13
(LSB) 14
Length = [01H] 2
[10H (Packet call going dormant),
14H (Normal call release),
0BH (Handoff Successful),
20H (Equipment failure),
1AH (Authentication Failure) ]
Active Connection Time in Seconds: A9 Element Identifier = [0AH] 1
Length = [04H] 2
(MSB) 3
Active Connection Time = [00 00 00 00H – FF FF FF FFH] 4
… 5
(LSB) 6
B-19
SP-3-0009 (TIA/EIA/IS-878)
1 6.1.10.5 A9-Release-A8 Complete

3 6.1.10.6 A9-BS Service Request

4 This A9 interface message is sent from the PCF to the BS to request re-activation of a packet data service
5 in Dormant state.
Reference
Service Option 6.2.2.66 PCF -> BS O R
Data Count 6.2.2.179 PCF -> BS Oc C
7 the A9-BS Service Response message sent in response to this message.
11 c. This IE may be included by the PCF to indicate to the BS the amount of data remaining at the PCF
12 that is to be transmitted. This information element shall not be included in 1xEV-DO messages.
13 d. This information element shall be is set to the MN ID, associated with the A10 connection, for 1xEV-
14 DO RAN messages.
15
B-20
SP-3-0009 (TIA/EIA/IS-878)
1 The following table shows the bitmap layout for the A9-BS Service Request message:
7 6 5 4 3 2 1 0 Octet
Length = [04H] 2
(MSB) 3
5
(LSB) 6
= [1,0]
OOO OOO
Length = [05H] 2
= [0]
(MSB) 4
ESN = <any value> 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
2
B-21
SP-3-0009 (TIA/EIA/IS-878)
1 6.1.10.7 A9-BS Service Response

3 6.1.10.8 A9-AL Connected

4 This A9 interface message is sent from the BS to the PCF to notify that the traffic channel is established
5 when the MS performed Hard Handoff.
Reference
A8_Traffic_ID 6.2.2.170 BS -> PCF O R
PDSN IP Address 6.2.2.30 BS -> PCF O R
IS-2000 Service Configuration Record 6.2.2.68 BS -> PCF Oc R
Service option 6.2.2.66 BS -> PCF O R
User Zone ID 6.2.2.32 BS -> PCF Od R
Quality of Service Parameters 6.2.2.54 BS -> PCF Oe R
Access Network Identifiers 6.2.2.189 BS -> PCF Ob R
7 the A9-AL Connected Ack message sent in response to this message.
8 b. The Access Network Identifiers are those of the source PCF communicated by the source BSC via the
9 MSC (handoff required, handoff requested messages), in TIA/EIA/IS-2000 systems.
10 c. The Bit-Exact Length – Octet Count field and the Bit-Exact Length – Fill Bits field of this informat-
11 ion element shall set to ‘0’, for 1xEV-DO messages.
12 d. The UZID field of this information element shall be set to 00H for padding, for 1xEV-DO messages.
13 e. The Non-Assured Mode Packet Priority field of this information element shall set to 0H for padding,
14 for 1xEV-DO messages.
15
16
B-22
SP-3-0009 (TIA/EIA/IS-878)
1 The following table shows the bitmap layout for the A9-AL Connected message:
7 6 5 4 3 2 1 0 Octet
Length = [08H] 2
(LSB) 4
(LSB) 6
(MSB) 7
9
(LSB) 10
Length = [04H] 2
(MSB) 3
5
(LSB) 6
Length = [0CH] 2
(LSB) 5
(MSB) 6
Key = <any value> 7
8
(LSB) 9
(MSB) 11
13
(LSB) 14
Length = [04H] 2
(MSB) 3
5
(LSB) 6
2
B-23
SP-3-0009 (TIA/EIA/IS-878)

Bit-Exact Length – Octet Count 2
= [00H to FFH]
= [0000 0] = [000 to 111]
(MSB) 4
IS-2000 Service Configuration Record Content ...
= <any value>
= [0 (if = [0 (if = [0 (if = [0 (if = [0 (if = [0 (if = [0 (if
= [ 00 21H (3G High Speed Packet Data) ] (LSB) 3
Length = [02H] 2
(LSB) 4
Length = [01H] 2
Reserved = [0000] Non-Assured Mode Packet Priority = 3
[0000 – 1101]
ACCESS NETWORK IDENTIFIERS: A1 ELEMENT IDENTIFIER = [20H] 1

Length = [05H] 2
Reserve (MSB) SID = <any value> 3
d = [0]
(LSB) 4
(MSB) NID = <any value> 5
(LSB) 6
PZID = <any value> 7
2
B-24
SP-3-0009 (TIA/EIA/IS-878)
1 6.1.10.9 A9-AL Connected Ack

2 This A9 interface message is sent from the PCF to the BS to acknowledge completion of the Al
3 connection request or the A9-AL Connected message for 1xEV-DO systems.
Reference
PDSN IP Address 6.2.2.30 PCF -> BS Ob C
4 a. This element shall only be included if it was also included in the A9-AL Connected message. This
5 element shall be set to the value received in that message.
6 b. This IE may be included if the target PCF could not connect to the PDSN designated in the A9-AL
7 Connected message.
8 The following table shows the bitmap layout for the A9-AL Connected Ack message:
7 6 5 4 3 2 1 0 Octet
Length = [08H] 2
(LSB) 4
(LSB) 6
(MSB) 7
9
(LSB) 10
Length = [04H] 2
(MSB) 3
5
(LSB) 6
Length = [04H] 2
(MSB) 3
5
(LSB) 6
9
B-25
SP-3-0009 (TIA/EIA/IS-878)
1 6.1.10.10 A9-AL Disconnected

3 6.1.10.11 A9-AL Disconnected Ack

4 For IS-2000 systems, this This A9 interface message is sent from the PCF to the BS to acknowledge
5 completion of the Al disconnected request. For 1xEV-DO systems, the A9-AL Disconnected Ack
6 message is only used to acknowledge the A9-AL Disconnected message.
Reference
7 a. This element shall only be included if it was also included in the A9-AL Disconnected message. This
8 element shall be set to the value received in that message.
9 The following table shows the bitmap layout for the A9-AL Disconnected Ack message:
7 6 5 4 3 2 1 0 Octet
A9 Message Type = [0BH] 1
Length = [08H] 2
(LSB) 4
(LSB) 6
(MSB) 7
9
(LSB) 10
Length = [04H] 2
(MSB) 3
5
(LSB) 6
10
11
12
B-26
SP-3-0009 (TIA/EIA/IS-878)
1 6.1.10.12 A9-Short Data Delivery

2 This message is sent from the BS to the PCF when a short data burst is received from a mobile. It is sent
3 from the PCF to the BS when a small amount of data is received for a mobile when it’s packet data
4 service instance is dormant. This section is not applicable to 1xEV-DO systems.
5

Reference
A9 Message Type 6.2.2.167 PCF <-> BS M
Correlation ID 6.2.2.108 PCF->BS Oa C
Mobile Identity (IMSI) 6.2.2.16 PCF <-> BS O R
Mobile Identity (ESN) 6.2.2.16 BS <-> PCF Ob C
SR_ID 6.2.2.26 BS<->PCF O R
Data Count 6.2.2.179 PCF->BS Oc C
ADDS User Part 6.2.2.67 PCF <-> BS Od R
7 a. If this element is included, it’s value shall be returned in the corresponding element in the A9-Short
8 Data Ack message from the BS.
10 Use of the ESN in this message is a network operator decision.
11 c. This element is included in this message when sent from the PCF to the BS and indicates the number
12 of additional bytes of data queued at the PCF and waiting to be sent to a specific mobile.
13 d. Contains the packet data received from the PDSN or an MS in a SDB format as specified in
14 TIA/EIA/IS-707-A-2.
15
16
B-27
SP-3-0009 (TIA/EIA/IS-878)
1 The following table shows the bitmap layout for the A9-Short Data Delivery message.
7 6 5 4 3 2 1 0 Octet
A9 Message Type = [0CH] 1
Length = [04H] 2
(MSB) 3
5
(LSB) 6
= [1,0]
OOO OOO
Length = [05H] 2
= [0]
(MSB) 4
ESN = <any value> 5
6
(LSB) 7
SR_ID: A9 Element Identifier = [0BH] 1
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
ADDS User Part: A1 Element Identifier = [3DH] 1
Length = <variable> 2
Reserved = [00] Data Burst Type = 3
[ 06H (Short Data Burst) ]
(MSB) Application Data Message = <any value> 4
OOO OOO
(LSB) n
3
B-28
SP-3-0009 (TIA/EIA/IS-878)
1 6.1.10.13 A9-Short Data Ack

2 This A9 interface message is sent from the BS to the PCF to acknowledge reception of the A9-Short Data
3 Delivery message and to indicate to the PCF whether the data was accepted for delivery to the mobile.
4 This section is not applicable to 1xEV-DO systems.
5

Reference
A9 Message Type 6.2.2.167 BS->PCF M
Correlation ID 6.2.2.108 BS->PCF Oa C
Mobile Identity (IMSI) 6.2.2.16 BS->PCF O R
Mobile Identity (ESN) 6.2.2.16 BS->PCF Ob C
SR_ID 6.2.2.26 BS->PCF O R
Cause 6.2.2.19 BS->PCF Oc R
7 a. If this element is included, it’s value shall be set to the value of the corresponding element in the A9-
8 Short Data Delivery message from the PCF.
10 Use of the ESN in this message is a network operator decision.
11 c. The cause value indicates to the PCF whether a short data burst is to will be sent to the mobile.
12
13
B-29
SP-3-0009 (TIA/EIA/IS-878)
1 The following table shows the bitmap layout for the A9-Short Data Ack message.
2
7 6 5 4 3 2 1 0 Octet
A9 Message Type = [0DH] 1
Length = [04H] 2
(MSB) 3
5
(LSB) 6
Identity Digit 1 = [0H-9H] (BCD) Odd/ev Type of Identity 2
en = [110] (IMSI)
Indicat
or
= [1,0]
OOO OOO
Length = [05H] 2
Identity Digit 1 = [0000] Odd/ev Type of Identity 3
en = [101] (ESN)
Indicat
or
= [0]
(MSB) 4
ESN = <any value> 5
6
(LSB) 7
SR_ID: A9 Element Identifier = [0BH] 1
Length = [01H] 2
Reserved = [0000 0] IS-2000 SR_ID = [001 - 011] 3
Length = [01H] 2
ext = Cause Value = 3
[0] [13H (Successful Operation),
16H (Initiate Re-activation of Packet Data call)
B-30
SP-3-0009 (TIA/EIA/IS-878)
1 6.1.10.14 A9-Update-A8
2 This A9 interface message is sent from the BS to the PCF to indicate a change to the session airlink para-
3 meters.
4

Reference
Mobile Identity (IMSI) 6.2.2.16 BS -> PCF Od R
Mobile Identity (ESN) 6.2.2.16 BS -> PCF Ob,c C
IS-2000 Service Configuration Record 6.2.2.68 BS -> PCF Oc,e C
Service Option 6.2.2.66 BS -> PCF Oc C
User Zone ID 6.2.2.32 BS -> PCF Oc C
Quality of Service Parameters 6.2.2.54 BS -> PCF Oc,e C
Cause 6.2.2.19 BS -> PCF O R
6 the A9-Update-A8-Ack message sent in response to this message.
10 c. These elements are required unless the message is used to indicate Dormant Power down or
11 Authentication Failure.
12 d. This information element shall be set to the MN ID, retrieved from AN-AAA, for 1xEV-DO
13 messages.
14 e. This information element shall not be included in 1xEV-DO messages.
15
16
B-31
SP-3-0009 (TIA/EIA/IS-878)
1 The following table shows the bitmap layout for the A9-Update-A8 message:
7 6 5 4 3 2 1 0 Octet
Length = [08H] 2
(LSB) 4
(LSB) 6
(MSB) 7
9
(LSB) 10
Length = [04H] 2
(MSB) 3
5
(LSB) 6
= [1,0]
OOO OOO
Length = [05H] 2
= [0]
(MSB) 4
ESN = <any value> 5
6
(LSB) 7
2
B-32
SP-3-0009 (TIA/EIA/IS-878)

Bit-Exact Length – Octet Count = <variable> 2
= [ 0000 0 ] = [ 000 – 111 ]
(MSB) 4
IS-2000 Service Configuration Record Content = <any value> ...
= [0 (if = [0 (if = [0 (if = [0 (if = [0 (if = [0 (if = [0 (if
= [ 00 21H (3G High Speed Packet Data ) ] (LSB) 3
Length = [02H] 2
(LSB) 4
Length = [01H] 2
Reserved = [0000] Non-Assured Mode Packet Priority = [0000 – 3
1101]
Length = [01H] 2
Ext= Cause value = 3
[0] [19H (Power down from dormant state),
1CH (update accounting: late traffic channel setup),
1EH (update accounting: parameter change),
1AH (Authentication Failure)]
B-33
SP-3-0009 (TIA/EIA/IS-878)
1 6.1.10.15 A9-Update-A8-Ack
3
B-34
SP-3-0009 (TIA/EIA/IS-878)
1 Annex C A10-A11 (AN/PCF - PDSN) Interface Change Text

2 2.15 A10/A11 Interface Procedures
3 A10/A11 interface uses Mobile IP messages for managing the A10 connections. The following sections
4 describe the messages and procedures for the A10/A11 interfaces. The sections are as follows:
5 N A10 Connection Setup Procedures,
6 N A10 Connection Re-Registration Procedures,
7 N A10 Connection Release Procedures,
8 N A10 Connection Accounting Procedures, and
9 N A10/A11 Interface Call Flows for TIA/EIA/IS-2000 mobiles.
10 When originating in a TIA/EIA/IS-2000 system, The mobile subscriber initiates a packet data call is
11 initiated by sending an IS-2000 Origination Message. Normal voice service authentication procedures are
12 followed for the subscriber, and then a traffic channel is established with the mobile. After connection of
13 a packet data service option, RLP synchronization between the mobile station and the BS proceeds. When
14 originating in a 1xEV-DO system, a packet data session is initiated as specified in TIA/EIA/IS-856.
15 Access authentication of the AT may be performed via the AN AAA server. After establishment of a
16 packet data session in the AN and allocation of radio resources, the The BS/PCF initiates setup of an A10
17 connection with the PDSN by sending an A11-Registration Request message on the A11 interface. The
18 PDSN may accept or reject the connection setup request. If the connection setup request is acceptable, the
19 PDSN returns an A11-Registration Reply message with an accept indication, and the packet data call is
20 connected through the just established A10 connection.
21 With the A10 connection in place, link layer/network layer frames pass over this connection in both
22 directions via Generic Routing Extension Encapsulation (GRE) framing. Refer to RFC 2784. The PDSN
23 accepts these frames, strips the GRE, and processes them as normal incoming frames for the appropriate
24 interface and protocol. The other direction behaves analogously, with the PDSN encapsulating the link
25 layer/network layer frames in GRE, and the PCF stripping the GRE before passing the frames over to the
26 upper layer. At this point, there is a point-to-point link layer/network layer connection between the
27 MS/AT mobile user and the PDSN.
28 In order to setup an A10 connection, the PCF assigns a PCF Session Identifier (PSI) to the packet data
29 bearer. The Mobile PCF Session Identifier (PSI) is unique only within the PCF entity. The PCF will also
30 uses the MN Session Reference ID (MN-SRID) which is passed from the mobile on each TIA/EIA/IS-
31 2000 origination and which, together with the Mobile Identifier, can be used to identify a packet data
32 service session for a specific mobile across PCFs and PDSNs. In the case of 1xEV-DO, the MN-SRID is
33 not received from the AT during origination and the AN/PCF shall set this to the default value of 1. In the
34 A11-Registration Request message, the PCF sets the Home Address field to zeros. The IP source address
35 (IP header) and the Care-of-Address field of the A11-Registration Request message are set to the IP
36 address of the PCF. The IP destination address in the IP header and the Home Agent field in the A11-
37 Registration Request are set to the address of the PDSN designated for the call. The PCF Session
38 Identifier (PSI), link layer/network layer protocol type identifier, MN Session Reference ID and IMSI
39 address of the mobile subscriber are set in the Session Specific Extension of the A11-Registration
40 Request message.
41 When the A10/A11 interface is used between a 1xEV-DO AN/PCF and a PDSN, the MN ID that is used
42 by the AN and the PCF on A8/A9 and A10/A11 messages is determined as follows:
43 N If the 1xEV-DO AN uses the AT device authentication feature, the MN ID field shall be set to the
44 MN ID value returned by the AN-AAA (e.g., IMSI) following successful access authentication.
45 N Otherwise, the AN/PCF shall set the MN ID field to a value that conforms to a valid MN ID
46 format (e.g., IMSI format). In this case, the MN ID is determined by other means.
C-1
SP-3-0009 (TIA/EIA/IS-878)
1 The A10 bearer connection is used for the transport of user data for a packet data session. Link layer /
2 network layer frames are carried between the PCF and the PDSN encapsulated in GRE packets, which in
3 turn are carried over IP. The PCF-Address and the PDSN-Address are used in the source address and
4 destination address fields of the IP header used with the GRE packet. The key field in the GRE header
5 contains the PCF Session Identifier (PSI), and indicates to which packet data bearer connection a partic-
6 ular payload packet belongs to.
7 The A11 A11-Registration Request and A11-Registration Reply messages are defined by RFC 2002 with
8 extension elements defined in Section 6.1.11 of this standard. The A11-Registration Update and A11-
9 Registration Acknowledge messages are also defined in Section 6.1.11 of this standard. The procedures
10 for the use of these messages are defined in Section 2.15.1 of this standard.
11 2.15.1 A10 Interface Setup Procedures

13 2.15.1.1 A10 Connection Establishment


16 When the TIA/EIA/IS-2000 BS receives an Assignment Request with a Service Option that requests
17 packet data service from the MSC, it initiates the procedure for establishing radio traffic channels. After
18 traffic channels are established, the BS/PCF initiates procedures for establishing an A10 connection. For
19 the 1xEV-DO system, after the AN and the mobile have established a packet data session, the AN/PCF
20 initiates procedures for establishing an A10 connection.
21 The PCF initiates setup of an A10 connection by sending an A11-Registration Request message to the
22 PDSN and starts timer Tregreq. The A11-Registration Request message is structured as specified in RFC
23 2002 and contains the extensions specified in this standard. The A11-Registration Request message may
24 be retransmitted a configurable number of times as specified in RFC 2002. If the connection setup request
25 is acceptable, the PDSN updates its binding record for the A10 connection by creating an association
26 between the MN ID IMSI address and the PCF Session Identifier, PCF-Address and PDSN-Address
27 information. It then returns an A11-Registration Reply with an accept indication, including the configured
28 Lifetime (Trp) for the A10 connection. The packet data call is connected through the just established A10
29 connection.
30 The PCF and the PDSN use the PCF-IP-Address and the PDSN-IP-Address returned in the A11-
31 Registration Reply message as the A10 connection for the transport of user traffic. The PCF-IP-Address
32 and the PDSN-IP-Address form the unique link layer ID for each A10 connection. The PCF and the
33 PDSN maintain an association of the mobile’s MN ID IMSI address with the A10 connection.
34 The PCF and the PDSN use the PCF-Address and the PDSN-Address returned in the A11-Registration
35 Reply message as the A10 connection for the transport of user traffic. The PSI, PCF-Address and the
36 PDSN-Address form the unique link layer ID for each A10 connection. The PCF and the PDSN maintain
37 an association of the mobile’s IMSI address with link layer ID over the A10 connection.
38 Please refer to RFC 2002 and section 6.1.11.1 “A11-Registration Request” for the format and content of
39 the A11-Registration Request message.

41 The PCF initiates setup of an A10 connection by sending an A11-Registration Request message to a
42 selected PDSN. If the selected PDSN does not accept the connection, it returns an A11-Registration
43 Reply with a reject result code.
44 The PDSN may return an A11-Registration Reply message with result code ‘88H’ (Registration Denied -
45 unknown PDSN address). When code ‘88H’ is used, an alternate PDSN address is included in the A11-
C-2
SP-3-0009 (TIA/EIA/IS-878)
1 Registration Reply message. The address of the alternate proposed PDSN shall be returned in the Home
2 Agent field of the A11-Registration Reply message.
3 On receipt of an A11-Registration Reply with code ‘88H’, the PCF shall either initiate establishment of
4 the A10 connection with the proposed PDSN by sending a new A11-Registration Request message as
5 indicated in this section, or shall use internal algorithms to select a new PDSN.
6 On receipt of an A11-Registration Reply with another result code, depending on the result code, the PCF
7 may attempt to re-try setting up the A10 connection. If the A10 connection can not be established, the
8 PCF indicates this to the AN which releases the call or to the BSC, which returns a failure indication to
9 the MSC, which in-turn releases the call.
10 Reliable message delivery mechanisms are used for setting up the A10 connection between the PCF and
11 the PDSN. As specified in RFC 2002, the A11-Registration Request message may be retransmitted if no
12 A11-Registration Reply is received within a configurable time. A call is considered to have failed if no
13 A11-Registration Reply is received after a configurable number of A11-Registration Request retrans-
14 missions.
15 2.15.2 A10 Interface Operational Procedures

17 2.15.2.1 A10 Connection – Periodic Re-registration



23 2.15.3 A10 Interface Release Procedures

24 The release of an A10 connection is controlled by the PCF. For PDSN initiated A10 connection release,
25 the PDSN requests that the PCF release the connection. The BSC or AN then would releases the traffic
26 channel(s) accordingly.
27 2.15.3.1 A10 Connection Release – PCF Requested



33 2.15.3.2 A10 Connection Release – PDSN Initiated

34 The PDSN may initiate release of an A10 connection by sending an A11-Registration Update message to
35 the PCF.
36 In the case of a PDSN initiated release of the A10 connection, the PCF indicates this to the AN which
37 releases the traffic resources accordingly or to the BSC, in this release, which returns an indication to the
38 MSC .
39 Please refer to Section 6.1.11.3, “A11-Registration Update”, for the format and content of this message.
C-3
SP-3-0009 (TIA/EIA/IS-878)


4 On failure to receive an A11-Registration Acknowledge or an A11-Registration Request (with accounting
5 related information and Lifetime set to zero) in response to a configurable number of A11-Registration
6 Update retransmissions or on receiving an A11-Registration Acknowledge with an update denied status,
7 the PDSN removes the binding information for the A10 connection.
8 When PCF returns Registration denied, the PDSN may send a new registration update at a configurable
9 number of time.
10 On the release of the A10 connection, the PCF indicates this to the AN which releases the resources
11 associated with the connection or to the BSC, which returns an indication to the MSC (if required), which
12 in-turn initiates release of the call.
13 Please refer to Section 6.1.11.4, “A11-Registration Acknowledge”, for the format and content of this
14 message.
15 2.15.4 A10 Interface Packet Accounting Procedures

16 The PCF uses the A11-Registration Request message to send accounting related and other information to
17 the PDSN. The accounting related information is accumulated at the PCF and sent to the PDSN on
18 occurrence of pre-defined triggers, which are listed in Table 2.15.4-1 below. The occurrence of these
19 predefined triggers is fully specified in TIA/EIA/IS-835. The A10 connection binding information at the
20 PDSN and the PCF may also be updated appropriately depending on the setting of the Lifetime field.
21 Table 2.15.4-1 - Accounting Records Generated By The PCF
Airlink Record Type (Y1) Accounting Records Generated By The PCF
Y1=1 Connection Setup: Setup of A10 connection initiated
Y1=2 Active Start: Mobile comes on the traffic channel(s).
Y1=3 Active Stop: Mobile has stopped use of traffic channel(s).
Y1=41 A forward or reverse short data burst (SDB) was exchanged with the
mobile
22 If some airlink parameters for an active session change, the PCF generates an “Active Stop (Y1=3)”
23 accounting record followed by an “Active Start (Y1=2)” accounting record. For successful operation, the
24 PDSN saves the accounting related and other information for further processing, and responds with A11-
25 Registration Reply with an accept indication.
26 See section 6.2.2.166 Vendor/Organization Specific Extension for detailed information on all the airlink
27 record types and the accounting parameters required for each airlink record type. If the accounting
28 parameter specified for an airlink record type is not received at the PDSN, the PDSN shall return an A11-
29 Registration Reply with result code ‘8DH’ (Registration Denied - unsupported Vendor ID or unable to
30 interpret data in the CVSE’.
31 The following is a description of the accounting events and indicates which airlink record type shall be
32 used for each event. If a specified airlink record type is not received at the PDSN or on receipt of an
33 unspecified airlink record type, the PDSN shall return an A11-Registration Reply with result code ‘8DH’
34 (Registration Denied – unsupported Vendor ID or unable to interpret data in the CVSE’.
1 Y1=4 Airlink record is only applicable to TIA/EIA/IS-2000 systems
C-4
SP-3-0009 (TIA/EIA/IS-878)
1 2.15.4.1 A10 Connection Setup Airlink Record

3 2.15.4.2 Active-Start Airlink Record

4 An Active-Start Airlink record shall be included in the A11 Registration Request to the PDSN for any of
5 the following event:
6 1. For an IS-2000 system wWhen a traffic channel is assigned to a packet data session: during initial call
7 setup, on transition from dormant to active state or during handoff or for a 1xEV-DO IOS system
8 when there is an indication that data is ready to be exchanged. The Active-Start Airlink record may
9 follow the connection Setup Airlink record in the same A11- Registration Request message (assuming
10 that all the parameters required in the Active-Start Airlink record are made available at the PCF at
11 that time.
12 2. Following an Active-Stop Airlink record (for TIA/EIA/IS-2000 systems), when any of the parameters
13 (QoS, User Zone, Forward/Reverse Mux Option’) currently defined in Active Start are changed. The
14 Active Start will contains the new set of parameters.
15 2.15.4.3 Active-Stop Airlink Record

16 An Active Stop Airlink record shall be included in A11-Registration Request to the PDSN at any of the
17 following event:
18 1. When the traffic channel assigned to the packet data session is released.
19 2. For TIA/EIA/IS-2000 systems, wWhen any of the parameters (QoS, User Zone, Forward/Reverse
20 Mux Option’) currently defined in Active Start are changed. The Active Stop is will be sent and
21 followed by an Active Start that will contain the new set of parameters.
22 2.15.4.4 SDB Airlink Record

24 2.15.4.5 Accounting at Re-registration

26 2.15.4.6 Sequence Numbers

27 All the airlink records include a sequence number initialized to i=zero at A10 connection setup for each
28 identification triplet (PCF session ID, MN SID, PCF ID). The PCF shall increment the sequence number
29 and insert it’s modulo 256 in the subsequent airlink record transmitted during the lifetime of the PCF
30 session ID. If the sequence number is equal to 255, and the PCF needs to send a subsequent airlink record
31 on the same PCF session, the PCF should set the sequence number to i+1 modulo 256 in the next airlink
32 record.
33 In the event of retransmission of the Air Link Record, the PCF shall retransmit with the same sequence
34 number.
35 2.15.4.7 Accounting update due to parameter changes

36 For TIA/EIA/IS-2000 systems, dDuring an active connection, if any of the following parameters are
37 changed:
38 - User Zone
39 - Quality of Service
40 - Forward/Reverse Mux Option’
C-5
SP-3-0009 (TIA/EIA/IS-878)
1 The PCF shall notify the PDSN using A11-Registration Request message containing an “Active Stop”
2 and an “Active Start” with the new set of parameters.
MS BSC/PCF MSC PDSN time
Active PPP session a
Parameter Parameter
b
change change
notification/ notification/
A11-Registration Request (Accounting Data)

c
A11-Registration Reply (Accept)

d
4 Figure 2.15.4.7-1 – Accounting update due to parameter change

5 a. An active PPP session exists and data is transferred over the connection
6 b. An event had occurred where parameters are changed/negotiated between the BSC/MSC and the MS.
7 c. The PCF notifies the PDSN by using A11-Registration Request message when any of the following
8 parameters have changed User-Zone, Quality of Service, Forward/Reverse Mux Option (see
9 TIA/EIA/IS-2000-5). The message will contains airlink records “Active-Stop” followed by an “Act-
10 ive Start” with the new set of parameters.
11 d. The PDSN updates the accounting data and returns an A11-Registration-Reply back to PCF.
12 OOO
13 6.1.11 A11 Interface Message Formats

15 6.1.11.1 A11-Registration Request

17 6.1.11.2 A11-Registration Reply

19 6.1.11.3 A11-Registration Update

21 6.1.11.4 A11-Registration Acknowledge

C-6
SP-3-0009 (TIA/EIA/IS-878)
1 OOO
2 6.2.2.155 Flags
4 6.2.2.156 Lifetime
6 6.2.2.157 Home Address

8 6.2.2.158 Home Agent

10 6.2.2.159 Care-of-Address
12 6.2.2.160 Identification
14 6.2.2.161 Code
16 6.2.2.162 Status
18 6.2.2.163 Mobile-Home Authentication Extension

20 6.2.2.164 Registration Update Authentication Extension

22 6.2.2.165 Session Specific Extension

24 6.2.2.166 Vendor/Organization Specific Extension

25 This element may be present in the A11-Registration Request message to convey the accounting inform-
26 ation from the PCF to the PDSN. This element may also be present in the A11-Registration Request
27 message to convey the Mobility Event Indicator from the PCF to the PDSN during dormant handoffs and
28 active/hard handoffs. For alternative coding formats see RFC 2138. This element may also be present in
29 the A11-Registration Request message to convey the Access Network Identifiers (PANID & CANID).
30 This element may be present in the A11-Registration Reply message to convey the Data Available
31 Indicator (DAI) from the PDSN to the PCF during handoff.
32 When used to convey the accounting information, the accounting records are contained within the Appli-
33 cation Data field of this element. The accounting records conveyed from the PCF to the PDSN conform to
34 the specifications in TIA/EIA/IS-835 (Wireless IP Network Standard). Each application type 01H
35 (Accounting) VSE contains one and only one airlink record. For transmission of multiple airlink records
36 in the same A11-Registration Request message, multiple instances of accounting type VSEs are used.
C-7
SP-3-0009 (TIA/EIA/IS-878)
0 1 2 3 4 5 6 7 Octet
A11 Element Identifier (Type) 1
Reserved 2
(MSB) 3
Length (LSB) 4
(MSB) 5
3GPP2 Vendor ID 6
7
(LSB) 8
Application Type 9
Application Sub Type 10
(MSB) 11
12
Application Data …
…
(LSB) k
3 Type: 26H
4 Length: This field indicates the number of octets in this element following this
5 field.
6 3GPP2 Vendor ID: 00 00 15 9FH
7 Application Type: This field indicates the type of the application, that the extension relates
8 to. The supported values are:
9 Table 6.2.2.166-1 - Vendor/Organization Specific Extension - Application Type
Hex Value Description
01H Accounting
02H Mobility Event Indicator
03H Data Available Indicator
04H Access Network Identifiers
All other values reserved.
10
11 Application Sub Type: This one octet field indicates the Application sub-type within the
12 Application Type. The supported values are listed in Table 6.2.2.166-2.
13
14
C-8
SP-3-0009 (TIA/EIA/IS-878)
1 Table 6.2.2.166-2 - Application Sub Type

Application Type Application Sub Type
Application Type HEX Value Application Sub HEX Value
Name Type Name
Accounting 01 H RADIUS 01H
DIAMETER 02H
Mobility Event 02H Mobility 01H
Indicator
Data Available 03H Data Ready to 01H

Indicator Send
Access Network 04 H ANID 01H
Identifiers
3 Application Data: For Application Type 01H (Accounting), this field contains the account-
4 ing parameters conveyed from the PCF to the PDSN as specified in
5 TIA/EIA/IS-835 (Wireless IP Network Standard). Each of the accounting
6 parameters are structured in the format of RADIUS attributes specified in
7 RFC 2138 2865 and RFC 21392866. This field is used in messages sent
8 from the PCF to the PDSN.
9 For Application Type 02H (Mobility Event Indicator), this field is zero
10 bytes in length. This field is used in messages sent from the PCF to the
11 PDSN.
12 For Application Type 03H (Data Available Indicator), this field is zero
13 bytes in length. This field is used in messages sent from the PDSN to the
14 PCF.
15 For Application Type 04H (Access Network Identifiers), this field con-
16 tains the PANID of the source PCF in octets 11-15 and CANID of the
17 target PCF in octets 16-20. The PANID and CANID are formatted as
18 specified for the Access Network Identifiers element (see section
19 6.2.2.189) from octet 3-7. If PANID or CANID information is not avail-
20 able, it shall be coded as all zeros. The PANID and CANID information
21 is included only in the first A11 Registration Request message following
22 a handoff.
23 For Application Type 01 H (Accounting) all 3GPP2 specific Airlink
24 Record Parameters are coded as follows:
25
C-9
SP-3-0009 (TIA/EIA/IS-878)
1 2 3 4 5 6 7 8 Octet
Type 1
Length 2
(MSB) 3
4
3GPP2 Vendor-Id 5
(LSB) 6
Vendor-Type 7
Vendor-Length 8
MSB 9
10
Vendor-Value (variable number of octets) ...

(LSB) k
3 Type: 1A H
4 Length: Type (1 octet ) + Length (1 octet ) + 3GPP2 Vendor Id (4 octets) + {
5 Vendor-Type (1 octet), Vendor-Length (1 octet), Vendor-Value (variable
6 octets) of the 3GPP2 specific parameter comprising the airlink record
7 being coded.}
8 Vendor ID: 00 00 15 9F H
9 Vendor Type: Sub-Type value from the Airlink Record table below.
10 Vendor-Length: Vendor-Type (1 octet) + Vendor-Length (1 octet) + Payload Length (in
11 octets) from the Airlink Record table below.
12
13 For Application Type 01 H (Accounting) all RADIUS specific Airlink Record Parameters are coded as
14 follows:
1 2 3 4 5 6 7 8 Octet
Type 1
Length 2
MSB 3
4
Value (variable number of octets) …

(LSB) k
15
16 Length: Type (1 octet) + Length (1 octet) + Payload Length (in octets) from the
17 Airlink Record table below.
18
C-10
SP-3-0009 (TIA/EIA/IS-878)
1 Airlink Record Fields Tables:

2 1. R-P Session Setup Airlink Record (Connection Setup).
Parameter Type Sub- Max. Payload Format
Type Length (octet)
Airlink Record Type = 1 (Setup) 26 40 4 Integer
R-P Session ID 26 41 4 Integer
Airlink Sequence number 26 42 4 Integer
MSID 31 N/A 15 String
Serving PCF 26 9 4 ip-addr
BSID 26 10 12 string2
3 2. Active Start Airlink Record.

Type Length (octet)
Airlink record type = 2 (START) 26 40 4 Integer
User Zone 26 11 4 Integer
Forward Mux Option3 26 12 4 Integer
Reverse Mux Option3 26 13 4 Integer
3
Forward Fundamental Rate 26 14 4 Integer
3
Reverse Fundamental Rate 26 15 4 Integer
Service Option 26 16 4 Integer
3
Forward Traffic Type 26 17 4 Integer
3
Reverse Traffic Type 26 18 4 Integer
3
Fundamental Frame Size 26 19 4 Integer
3
Forward Fundamental RC 26 20 4 Integer
3
Reverse Fundamental RC 26 21 4 Integer
3
Airlink Quality of Service (QoS) 26 39 4 Integer
4 3. Active Stop Airlink Record.

Type Length (octet)
Airlink record type = 3 (STOP) 26 40 4 Integer
Active Connection Time in Seconds 46 N/A 4 Integer
2 A number formed from the concatenation of SID+NID+BSC ID, where each item is encoded using four
hexadecimal upper case ASCII characters.
3 If the PCF has not received this information from the AN, the PCF shall set this field to a default value of 0.
C-11
SP-3-0009 (TIA/EIA/IS-878)
2 4. SDB Airlink Record.

Type Length (octet)
Airlink record type = 4 (SDB) 26 40 4 Integer
Mobile Orig./Term. Indicator 26 45 4 Integer
SDB Octet Count 26 31/324 4 Integer
4 An example coding of the Active Stop Airlink Record within the Vendor/Organization Specific Extension
5 element is illustrated below:
0 1 2 3 4 5 6 7 Octet
A11 Element Identifier = 26H 1
Reserved 2
(MSB) 3
Length = 30 H (LSB) 4
(MSB) 5
3GPP2 Vendor ID = 00 00 15 9F H 6
7
(LSB) 8
Application Type = 01 H 9
Application Sub Type = 01 H 10
Parameter Name: Airlink Record Type = 3 (Active Stop)
Type = 1A H 11
Length = 0C H 12
(MSB) 13
14
3GPP2 Vendor-Id = 00 00 15 9F H 15
(LSB) 16
Vendor-Type = 28 H 17
Vendor-Length = 06 H 18
MSB 19
20
Vendor-Value = 3 (Active Stop) 21

(LSB) 22
Continued on next page

6
4 Subtype 31 is for terminating SDB octet count, subtype 32 is for originating SDB octet count.
C-12
SP-3-0009 (TIA/EIA/IS-878)
Continued from previous page
Parameter Name: R-P-Session ID

Type = 1A H 23
Length = 0C H 24
(MSB) 25
26
3GPP2 Vendor-Id = 00 00 15 9F H 27
(LSB) 28
Vendor-Type = 29 H 29
(MSB) 31
32
Vendor-Value = PCF Session Identifier 33

(LSB) 34
Parameter Name: Airlink Sequence Number

Type = 1A H 35
Length = 0C H 36
(MSB) 37
38
3GPP2 Vendor-Id = 00 00 15 9F H 39
(LSB) 40
Vendor-Type = 2A H 41
(MSB) 43
44
Vendor-Value = Sequence Number 45

(LSB) 46
Parameter Name: Active Connection Time

Type = 3A H 47
Length = 06 H 48
(MSB) 49
50
Value = Active Connection Time (in seconds) 51

(LSB) 52
C-13
SP-3-0009 (TIA/EIA/IS-878)
1 No text.
2
C-14
SP-3-0009 (TIA/EIA/IS-878)
1 Annex D A12 RADIUS Attributes

2 This is the general Vendor Specific Format for all 3GPP2 RADIUS attributes. The type and vendor ID
3 are the same for every attribute. The vendor type, vendor length, and value are specified as follows.
1 2 3
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Vendor-Id
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor-Id (cont) | Vendor-type |Vendor-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type = cdma specific

Length >= 9
4
5 Figure D-1 3GPP2 RADIUS Attribute Format

6 Type: 26
7 Length: greater than 9
8 3GPP2 Vendor ID: 5535
9
10 1xEV-DO Terminal Authentication: Indicates whether the Access Request is in the context of terminal
11 authentication. This optionally appears in an A12 Access-Request.
12 Vendor-Type = TBD [Editor’s note: TBD requires resolution]
13 Vendor-Length = 6
14 Vendor-Value = 1 (1xEV-DO Terminal Authentication)
15
16
17
18
D-1
SP-3-0009 (TIA/EIA/IS-878)
1 No text.
2
D-2
SP-3-0009 (TIA/EIA/IS-878)
1 Annex E Revision History

2
June 14, 2001 Ballot text.
E-1
SP-3-0009 (TIA/EIA/IS-878)
1 No text.
2
E-2

A.S0007-0 v1.0

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

A.S0007-0 v1.0

Hochgeladen von

Copyright:

Verfügbare Formate

SP-3-0009 (TIA/EIA/IS-878)

June 14, 2001 1xEV-DO IOS Ballot Version

2 1xEV-DO Inter-Operability Specification (IOS) for

COPYRIGHT © 2001, 3GPP2

2 1xEV-DO Inter-Operability Specification (IOS) for CDMA

1 4.4.4.3 Unicast Access Terminal Identifier (UATI). ............................................................ 4-11

14 and definitions for the following 1xEV-DO IOS interfaces:

16 1.2 1xEV-DO IOS Architecture Reference Model

Access Air Interface A13 A12 AN AAA

21 Figure 1.2-1 1xEV-DO IOS Phase 1 Architecture Reference Model

1xEV-DO 1x Evolution - Data Only

NID Network Identification

1 1.5 Document Convention

10 1.6 Compatibility with IS-2001 Standards

TIA/EIA/IS-2001 term TIA/EIA/IS-856 term

25 1.7 1xEV-DO IOS Assumptions

1 2 1xEV-DO IOS Call Flows

3 2.1 AT Originates 1xEV-DO Session

5 2.1.1 AT Originates 1xEV-DO Session -Successful Authentication

AT AN AN AAA PCF PDSN time

PPP and LCP Negotiation f

CHAP Challenge - Response g

CHAP - Authentication Success j

A11-Registration Request (Lifetime, MEI) m

Establishing PPP connection p

Transmitting Packet Data q

1 2.1.2 AT Originates 1xEV-DO Session - Unsuccessful Authentication

AT AN AN AAA PCF PDSN time

PPP and LCP Negotiation f

CHAP Challenge - Response g

CHAP - Authentication Failure j

1 2.1.3 AT Originates with a Pre-existing 1xEV-DO Session

AT AN PCF PDSN time

Transmitting Packet Data d

4 Figure 2.1.3-1 AT Origination (Session is Already Established)

1 2.2 Data Delivery

3 2.2.1 Data Delivery - AT Terminated

AT AN PCF PDSN time

Transmitting Packet Data a

A9-BS Service Request b

Transmitting Packet Data h

7 Figure 2.2.1-1 AT Terminated Data Delivery

19 g. When the AN receives the A9-Connect-A8 message it stops timer TA8-setup.

1 2.2.2 Data Delivery - AT Originated

5 2.3 Connection Tear-Down

7 2.3.1 Connection Tear-Down on 1xEV-DO Network - Initiated by the AT.

10 Figure 2.3.1-1 AT Initiated Connection Tear-Down

1 2.3.2 Connection Tear-Down on 1xEV-DO Network - Initiated by the AN/PCF.

4 Figure 2.3.2-1 AN/PCF Initiated Connection Tear-Down

1 2.4 Session Tear-Down

3 2.4.1 Session Tear-Down - Initiated by the AT

A11-Registration Request (Lifetime=0, Acct data) c

7 Figure 2.4.1-1 AT Initiated Session Tear-Down

1 2.4.2 A10 Tear-Down - Initiated by the PDSN

AT AN PCF PDSN time

A11-Registration Request (Lifetime=0) c

4 Figure 2.4.2-1 PDSN Initiated A10 Tear-Down

1 2.4.3 Radio Session Tear-Down - Initiated by the AN.

AT AN PCF PDSN time

A11-Registration Request (Lifetime=0) c

4 Figure 2.4.3-1 AN Initiated Radio Session Tear-Down

3 2.5.1 AN-AN Dormant Handoff with Successful Retrieval of Session Information