A03-20011105-004a A.S0007-0.2.0_IOS-for-HRPD-in-AN

November, 2001
A.S0007-0 version 2.0 (TIA-878)
HRPD IOS Publication Version
1
3GPP2 A.S0007-0 Version 2.0
Date: November, 2001
2
3
4
5
7
Inter-Operability Specification (IOS) for High Rate
Packet Data (HRPD) Access Network Interfaces
8
Revision 0
9
(Post SDO Ballot, Pre-SDO Publication Version)
6
10
11
12
13
14
15
16
17
18
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.
A.S0007-0 version 2.0 (TIA-878)
HRPD IOS Publication Version
November, 2001
1
Table of Contents
2
Foreword .......................................................................................................................................................v
3
1
Introduction ...................................................................................................................................1-1
4
1.1
Scope .............................................................................................................................................1-1
5
1.2
HRPD IOS Architecture Reference Model ...................................................................................1-1
6
1.3
HRPD Micro-Mobility and Macro-Mobility Concepts.................................................................1-2
7
1.4
References .....................................................................................................................................1-2
8
1.5
Terminology..................................................................................................................................1-3
9
1.5.1
Acronyms ..................................................................................................................................... 1-3
10
1.5.2
Definitions.................................................................................................................................... 1-3
11
1.6
Document Convention...................................................................................................................1-4
12
1.7
Compatibility with IS-2001 Standards..........................................................................................1-5
13
1.8
HRPD IOS Assumptions...............................................................................................................1-5
14
2
HRPD IOS Interfaces ....................................................................................................................2-1
15
2.1
A8-A9 (AN - PCF) Interface.........................................................................................................2-1
16
2.2
A10-A11 (PCF - PDSN) Interface ................................................................................................2-1
17
2.3
A12 (AN - AN AAA) Interface.....................................................................................................2-1
18
2.3.1
PPP Session.................................................................................................................................. 2-2
19
2.3.1.1
Establishment ..............................................................................................................2-2
20
2.3.1.2
Termination .................................................................................................................2-2
21
2.3.1.3
Access Authentication.................................................................................................2-2
22
2.3.2
AN-AAA Support ........................................................................................................................ 2-2
23
2.3.3
AN-AAA Requirements............................................................................................................... 2-3
24
2.4
A13 (AN - AN) Interface ..............................................................................................................2-4
25
2.4.1
A13 Interface Network/Transport Protocol Specification............................................................ 2-4
26
2.4.2
A13 Interface Procedures ............................................................................................................. 2-5
27
2.4.2.1
A13-Session Information Request...............................................................................2-5
28
2.4.2.1.1
Successful Operation ..................................................................................................2-5
29
2.4.2.1.2
Failure Operation ........................................................................................................2-5
30
2.4.2.2
A13-Session Information Response ............................................................................2-5
31
2.4.2.2.1
Successful Operation ..................................................................................................2-5
32
2.4.2.2.2
Failure Operation ........................................................................................................2-6
33
2.4.2.3
A13-Session Information Confirm..............................................................................2-6
34
2.4.2.3.1
Successful Operation ..................................................................................................2-6
35
2.4.2.3.2
Failure Operation ........................................................................................................2-6
36
2.4.2.4
A13-Session Information Reject .................................................................................2-6
i
A.S0007-0 version 2.0 (TIA-878)
HRPD IOS Publication Version
November, 2001
1
2.4.2.4.1
Successful Operation ..................................................................................................2-6
2
2.4.2.4.2
Failure Operation ........................................................................................................2-6
3
3
HRPD IOS Call Flows ..................................................................................................................3-1
4
3.1
AT Originates HRPD Session .......................................................................................................3-1
5
3.1.1
AT Originates HRPD Session - Successful Access Authentication............................................. 3-1
6
3.1.2
AT Originates HRPD Session - Unsuccessful Access Authentication ........................................ 3-3
7
3.2
Re-authentication ..........................................................................................................................3-4
8
3.2.1
Re-authentication of an AT in Dormant State.............................................................................. 3-4
9
3.2.2
Re-authentication of an AT in Active State ................................................................................. 3-5
10
3.3
Data Delivery ................................................................................................................................3-6
11
3.3.1
Network Initiated Call Re-activation from Dormant State........................................................... 3-6
12
3.3.2
AT Initiated Call Re-activation from Dormant State (Existing HRPD Session) ......................... 3-7
13
3.4
Connection Release.......................................................................................................................3-8
14
3.4.1
Connection Release on HRPD Network - Initiated by the AT..................................................... 3-8
15
3.4.2
Connection Release on HRPD Network - Initiated by the AN. ................................................... 3-9
16
3.5
Session Release ...........................................................................................................................3-10
17
3.5.1
HRPD Session Release - Initiated by the AT (A8 Connection Established).............................. 3-10
18
3.5.2
HRPD Session Release - Initiated by the AT (No Connection Established).............................. 3-11
19
3.5.3
HRPD Session Release - Initiated by the AN (A8 Connection Established) ............................. 3-12
20
3.5.4
HRPD Session Release - Initiated by the AN (No A8 Connection Established) ....................... 3-13
21
3.5.5
Packet Data Session Release - Initiated by the PDSN ............................................................... 3-14
22
3.6
Dormant Handoff of HRPD AT between ANs - Served by the Same PDSN .............................3-15
23
3.6.1
AN-AN Dormant Handoff with Successful Retrieval of HRPD Session Information............... 3-15
24
3.6.2
Dormant AN-AN Handoff with HRPD Session Information Transfer Failure.......................... 3-17
25
3.7
Active HRPD Session .................................................................................................................3-19
26
3.7.1
AN Detects a Loss of the Airlink During an Active HRPD Session.......................................... 3-19
27
4
HRPD and cdma2000 IOS Transition Call Flows.........................................................................4-1
28
4.1
Dormant Cross System Handoff - Served by the Same PDSN. ....................................................4-1
29
4.1.1
cdma2000 to HRPD Dormant Packet Data Session Handoff - Existing HRPD Session ............. 4-1
30
4.1.2
cdma2000 to HRPD Dormant Packet Data Session Handoff - New HRPD Session ................... 4-3
31
4.1.3
HRPD to cdma2000 Dormant Packet Data Session Handoff....................................................... 4-5
32
4.2
MS/AT Terminated Voice Call During Active HRPD Packet Data Session ................................4-7
33
4.2.1
MS/AT Terminated Voice Call During Active HRPD Data Packet (Intra-PDSN/Inter-PCF).... 4-7
34
4.2.2
AT Leaving During an Active 1xEV-DO Data Session............................................................... 4-9
35
4.2.3
MS/AT Terminated Voice Call During Active HRPD Packet Data Session (Intra-PCF).......... 4-11
36
4.3
cdma2000 to HRPD Active Packet Data Session Handoff .........................................................4-13
37
4.4
Status Management Supported by Feature Invocation................................................................4-14
ii
A.S0007-0 version 2.0 (TIA-878)
HRPD IOS Publication Version
November, 2001
1
5
Messages, Information Elements and Timer Definitions ..............................................................5-1
2
5.1
Message Definitions......................................................................................................................5-1
3
5.1.1
A13 Message Definitions ............................................................................................................. 5-1
4
5.1.1.1
A13-Session Information Request Message................................................................5-1
5
5.1.1.2
A13-Session Information Confirm Message...............................................................5-2
6
5.1.1.3
A13-Session Information Reject Message ..................................................................5-2
7
5.1.1.4
A13-Session Information Response Message .............................................................5-3
8
5.2
Information Element Definitions...................................................................................................5-5
9
5.2.1
A13 Information Element Definitions.......................................................................................... 5-5
10
5.2.1.1
Information Element Identifiers ..................................................................................5-5
11
5.2.1.2
A13 Message Type......................................................................................................5-5
12
5.2.1.3
Unicast Access Terminal Identifier (UATI 128).........................................................5-5
13
5.2.1.4
Security Layer Packet..................................................................................................5-6
14
5.2.1.5
SectorID ......................................................................................................................5-6
15
5.2.1.6
Cause ...........................................................................................................................5-6
16
5.2.1.7
Mobile Identity (MN ID).............................................................................................5-7
17
5.2.1.8
PDSN IP Address ........................................................................................................5-7
18
5.2.1.9
Access Network Identifiers .........................................................................................5-8
19
5.2.1.10
Session State Information Record ...............................................................................5-8
20
5.3
Timer Definitions ..........................................................................................................................5-9
21
5.3.1
Timer Descriptions....................................................................................................................... 5-9
22
5.3.1.1
Timer Tairdrop ................................................................................................................5-9
23
5.3.1.2
Timer TA13req ................................................................................................................5-9
24
5.3.1.3
Timer Tairdrop ................................................................................................................5-9
25
Annex A
Future Phases of HRPD IOS - Informative Annex.................................................................A-1
26
A.1
27
Annex B
A8-A9 (AN - PCF) Interface Change Text.............................................................................B-1
28
Annex C
A10-A11 (AN/PCF - PDSN) Interface Change Text .............................................................C-1
29
Annex D
A12 RADIUS Attributes ........................................................................................................D-1
30
Annex E
Revision History ..................................................................................................................... E-1
HRPD IOS Phase 2 Architecture Reference Model Working Assumptions................................A-1
31
32
iii
A.S0007-0 version 2.0 (TIA-878)
HRPD IOS Publication Version
November, 2001
Table of Figures
1
2
3
Figure 1.2-1
HRPD IOS Phase 1 Architecture Reference Model ...................................................... 1-1
4
Figure 1.3-1
Packet Data Mobility Architecture for HRPD............................................................... 1-2
5
Figure 2.3-1
RADIUS Protocol Reference Model ............................................................................. 2-2
6
Figure 3.1.1-1
Initial AT Origination with HRPD Session Establishment and Key Exchange ............ 3-1
7
Figure 3.1.2-1
Initial AT Origination - Unsuccessful Access Authentication ...................................... 3-3
8
Figure 3.2.1-1
Re-authentication of an AT in Dormant State ............................................................... 3-4
9
Figure 3.2.2-1
Re-authentication of an AT in Active State................................................................... 3-5
10
Figure 3.3.1-1
Network Initiated Call Re-activation from Dormant State............................................ 3-6
11
Figure 3.3.2-1
AT Initiated Call Re-activation from Dormant State (Existing HRPD Session)........... 3-7
12
Figure 3.4.1-1
AT Initiated Connection Release................................................................................... 3-8
13
Figure 3.4.2-1
AN Initiated Connection Release .................................................................................. 3-9
14
Figure 3.5.1-1
AT Initiated HRPD Session Release (A8 Connection Established) ............................ 3-10
15
Figure 3.5.2-1
AT Initiated HRPD Session Release (No A8 Connection Established) ...................... 3-11
16
Figure 3.5.3-1
AN Initiated HRPD Session Release (A8 Connection Established)............................ 3-12
17
Figure 3.5.4-1
AN Initiated HRPD Session Release (No A8 Connection Established)...................... 3-13
18
Figure 3.5.5-1
PDSN Initiated Packet Data Session Release.............................................................. 3-14
19
Figure 3.6.1-1
Inter-PCF/Intra-PDSN Dormant AN-AN HO - Successful Operation........................ 3-15
20
Figure 3.6.2-1
Inter-PCF/Intra-PDSN Dormant AN-AN HO - Transfer Failure ............................... 3-17
21
Figure 3.7.1-1
AN Detects Loss of Airlink During Active HRPD Session ........................................ 3-19
22
Figure 4.1.1-1
cdma2000 to HRPD Dormant Packet Data Session HO - Existing HRPD Session ...... 4-1
23
Figure 4.1.2-1
cdma2000 to HRPD Dormant Packet Data Session Handoff - New HRPD Session .... 4-3
24
Figure 4.1.3-1
HRPD to cdma2000 Dormant Packet Data Session Handoff ........................................ 4-5
25
Figure 4.2.1-1
Voice Call Termination During Active HRPD Packet Data Session (Inter-PCF)......... 4-7
26
Figure 4.2.2-1
AT Leaving During an Active 1xEV-DO Data Session................................................ 4-9
27
Figure 4.2.3-1
Voice Call Termination During Active HRPD Packet Data Session (Intra-PCF)....... 4-11
28
Figure 4.4-1
Terminal Based Status Management (Using Feature Invocation) ............................... 4-14
29
Figure A.1-1
HRPD IOS Phase 2 Architecture Reference Model Working Assumptions ................ A-1
30
Figure D-1
3GPP2 RADIUS Attribute Format ............................................................................... D-1
31
32
33
iv
A.S0007-0 version 2.0 (TIA-878)
HRPD IOS Publication Version
November, 2001
1
Foreword
6
While based on TIA/EIA/IS-2001-A, the interfaces defined in this document are compatible with a
TIA/EIA/IS-2001 or higher release. This document describes the protocol and some generic procedures
to support the following High Rate Packet Data (HRPD) IOS features. Conformance to the IOS may be
claimed on a feature-by-feature and/or interface-by-interface basis. If conformance on a given interface is
claimed for the HRPD IOS feature, it shall be supported as defined in this standard.
7
Features:
8
Access authentication
9
Data delivery
2
3
4
5
10
Session handoff between ANs
11
Status management
12
13
v
A.S0007-0 version 2.0 (TIA-878)
HRPD IOS Publication Version
1
November, 2001
No text.
2
vi
A.S0007-0 version 2.0 (TIA-878)
HRPD IOS Publication Version
November, 2001
1
1
Introduction
1.1
Scope
2
3
15
This specification provides the HRPD text and call flows for the following scenarios:
• AT originates a HRPD session (including access authentication)
• HRPD data delivery (both AT terminated and AT originated)
• Re-authentication of an AT
• HRPD connection release
• HRPD session release
• Dormant handoff of HRPD AT between ANs served by the same PDSN
• Dormant (voice or packet) cdma2000 handoff to/from HRPD, served by the same PDSN
• MS/AT terminated voice call during active HRPD data session
• cdma2000 to HRPD active packet data session handoff
• Loss of the airlink during an active HRPD session
• Status Management supported by feature invocation
16
and definitions for the following HRPD IOS interfaces:
4
5
6
7
8
9
10
11
12
13
14
Interface
A8-A9
A10-A11
A12
A13
(AN - PCF) Interface
(PCF - PDSN) Interface
(AN - AN AAA) Interface
(AN - AN) Interface
Description
TIA/EIA/IS-2001-A delta text (Annex B)
TIA/EIA/IS-2001-A delta text (Annex C)
New HRPD IOS defined text (Section 2.3)
New HRPD IOS defined text (Section 2.4)
17
18
19
20
21
1.2
HRPD IOS Architecture Reference Model
The HRPD IOS messaging and call flows are based on the Architecture Reference Model shown in Figure
1.2-1, HRPD IOS Phase 1. A working assumption for the HRPD IOS phase 2 Architecture Reference
Model is addressed in Annex A.
A8
Source Access
Network (AN)
Access
Terminal (AT)
Air Interface
A13
A12
A10
PCF
A9
PDSN
A11
AN AAA
Target Access
Network (AN)
22
23
Figure 1.2-1
HRPD IOS Phase 1 Architecture Reference Model
1-1
A.S0007-0 version 2.0 (TIA-878)
HRPD IOS Publication Version
November, 2001
1
1.3
HRPD Micro-Mobility and Macro-Mobility Concepts
2
The figure below provides a conceptual view of levels of HRPD packet data mobility.
Home Agent
Mobility between
PDSNs (Mobile IP)
PDSN
PDSN
PCF
PCF
Mobility between
PCFs (A10/A11
Interfaces)
PCF
Mobility between ANs
(A8/A9 Interfaces)
AN
AN
AN
AN
3
Figure 1.3-1
4
Packet Data Mobility Architecture for HRPD
5
•
The A8/A9 interfaces support mobility between ANs under the same PCF.
6
•
The A10/A11 interfaces support mobility between PCFs under the same PDSN.
7
•
Mobile IP supports mobility between PDSNs under the same Home Agent.
8
9
1.4
10
[1]
TIA/EIA/IS-2000-A-2, cdma2000 Standards for Spread Spectrum Systems Release A, March,
2000.
12
[02-06]
Reserved.
13
[7]
TIA/EIA-95-B, Mobile Station-Base Station Compatibility Standard for Wideband Spread
Spectrum Cellular Systems, March, 1999.
15
[8]
IS-707-A-2, Data Service Options for Spread Spectrum Systems, March, 2001.
16
[9]
TIA/EIA/IS-835-A, cdma2000 Wireless IP Network Standard, May, 2001.
17
[10]
TIA/EIA/IS-856, cdma2000 High Rate Packet Data Air Interface Specification, February,
2001.
[11]
TIA/EIA/IS-2001-A, Inter-Operability Specification (IOS) for CDMA 2000 Access Network
Interfaces, May, 2001.
21
[12-17]
Reserved.
22
[18]
RFC 1321, MD5 Message-Digest Algorithm, April 1992.
23
[19]
RFC 1661, Point-to-Point Protocol, July 1994.
24
[20]
RFC 1662, PPP in HDLC-Like Framing, July, 1994.
25
[21]
RFC 1750, Randomness Recommendations for Security, December, 1994.
26
[22]
RFC 1994, PPP Challenge Handshake Authentication Protocol (CHAP), August, 1996.
27
[23]
RFC 2002, IP Mobility Support, October, 1996.
28
[24]
RFC 2486, The Network Access Identifier, January, 1999.
29
[25]
RFC 2865, Remote Authentication Dial In User Service (RADIUS), June, 2000.
11
14
18
19
20
References
1-2
A.S0007-0 version 2.0 (TIA-878)
HRPD IOS Publication Version
November, 2001
1
1.5
Terminology
1.5.1
Acronyms
2
3
AAA
ACCM
AN
ANID
AT
BS
BSC
CANID
CHAP
CVSE
HRPD
IMSI
IOS
LCP
MAC
MEI
MN ID
MS
MSC
NAI
NID
PANID
PCF
PDSN
PPP
PZID
RADIUS
SID
SKey
UATI
Authentication, Authorization and Accounting
Async-Control-Character-Map
Access Network
Access Network Identifiers
Access Terminal
Base Station
Base Station Controller
Current Access Network Identifiers
Challenge Handshake Authentication Protocol
Critical Vendor/Organization Specific Extension
High Rate Packet Data
International Mobile Subscriber Identity
Inter-Operability Specification
Link Control Protocol
Medium Access Control
Mobility Event Indicator
Mobile Node Identification
Mobile Station
Mobile Switching Center
Network Access Identifier
Network Identification
Previous Access Network Identifiers
Packet Control Function
Packet Data Serving Node
Point-to-Point Protocol
Packet Zone Identification
Remote Authentication Dial-In User Service
System Identification
Session Key
Unicast Access Terminal Identifier
4
5
1.5.2
Definitions
7
Access Authentication A procedure in which the Access Terminal (AT) is authenticated by the ANAAA (Access Network Authentication, Authorization and Accounting entity).
8
Access Stream
6
9
The HRPD stream whose end-points are the access terminal and the Access Network (radio network). This stream is used for access authentication.
1-3
A.S0007-0 version 2.0 (TIA-878)
HRPD IOS Publication Version
November, 2001
Access Network
The network equipment providing data connectivity between a packet switched
data network (typically the Internet) and the access terminals. An access network
is equivalent to a base station in cdma2000 systems.
Access Terminal
A device providing data connectivity to a user. An access terminal may be
connected to a computing device such as a laptop personal computer or it may be
a self-contained data device such as a personal digital assistant. An access
terminal is equivalent to a mobile station in cdma2000 systems.
AN AAA
An entity that performs access authentication and authorization functions for the
Access Network.
Connection
A connection is a particular state of the air-link in which the access terminal is
assigned a Forward Traffic Channel, a Reverse Traffic Channel and associated
Medium Access Control (MAC) Channels. During a single HRPD session the
access terminal and the access network can open and can close a connection
multiple times.
15
Hybrid MS/AT
A device capable of operating on both cdma2000 and HRPD access networks.
16
Mobile Station
An entity in the (cdma2000) public cellular radio telecommunications service
intended to be used while in motion or during halts at unspecified points. Mobile
stations include portable units (e.g., hand-held personal units) and units installed
in vehicles.
Service Stream
The HRPD stream used when exchanging data between the access terminal and
the PDSN.
HRPD session
An HRPD session refers to a shared state between the access terminal and the
access network. This shared state stores the protocols and protocol configurations that were negotiated and are used for communications between the access
terminal and the access network. Other than to open a session, an access terminal
cannot communicate with an access network without having an open session.
Note that it is possible that the A10/A11 connection is not established even
though the HRPD session is established. Refer to [10], Section 1.9.
Packet Data Session
An instance of use of packet data service by a mobile user. A packet data session
begins when the user invokes packet data service. A packet data session ends
when the user or the network terminates packet data service. During a particular
packet data session, the user may change locations but the same IP address is
maintained. Refer to [11], Section 1.6.2.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
1.6
Document Convention
“Shall” and “shall not” identify requirements to be followed strictly to conform to the standard and from
which no deviation is permitted. “Should” and “should not” indicate that one of several possibilities is
recommended as particularly suitable, without mentioning or excluding others; that a certain course of
action is preferred but not necessarily required; or (in the negative form) that a certain possibility or
course of action is discouraged but not prohibited. “May” and “need not” indicate a course of action
permissible within the limits of the standard. “Can” and “cannot” are used for statements of possibility
and capability, whether material, physical, or causal.
43
44
1-4
A.S0007-0 version 2.0 (TIA-878)
HRPD IOS Publication Version
November, 2001
1
2
3
4
5
6
7
8
9
10
1.7
Compatibility with IS-2001 Standards
The HRPD IOS interface, as defined in this specification, is compatible with a TIA/EIA/IS-2001 or higher release, with the provision that the HRPD capabilities are the same as those supported by the interoperability specification, for the access network(s) in use. For example, when inter-operating with a
TIA/EIA/IS-2001 system, the portions of this specification related to concurrent services and support for
Previous/Current Access Node Identifies (PANID/CANID) are not applicable.
Note: When the procedures between TIA/EIA/IS-95-B or cdma2000 and HRPD systems differ, the
HRPD procedures are identified separately within this specification. When the TIA/EIA/IS-2001 text is
applied to the HRPD RAN specification, the procedures related to the MSC shall be ignored. Hard Handoff procedures, as defined in [11], are not applicable to HRPD.
11
12
1.8
13
The following assumptions are made regarding AN/AT behavior:
14
•
A packet data session maybe handed off from a serving cdma2000 system to a serving HRPD system
and from a serving HRPD system to a serving cdma2000 system.
•
A unique value, 59 (3B H), is used in the Service Option fields in accounting records transported on
the A9 and A11 interfaces to identify accounting records associated with HRPD Packet Data Service.
•
For the case of dormant inter-AN inter-PCF handoff, the target PCF may use the PDSN address
received from the source AN to send the A11-Registration Request message. Otherwise, the target
PCF shall use the PDSN selection algorithm (if supported) or internal algorithms to select a PDSN.
•
The AT may handoff a packet data session from a serving HRPD system to a serving cdma2000
system and back to a serving HRPD system. Therefore, following a dormant handoff, the target AN
shall use the PANID received from the AT. Otherwise if the AT does not send the PANID or the AN
chooses not to request this information from the AT, then the target AN may use the PANID received
in the A13-Session Information Accept message from the source AN.
•
For the instance of Packet Application terminated in the AN, the AT shall support Challenge
Handshake Authentication Protocol (CHAP) access authentication. In this case, the AT shall send a
Network Access Identifier (NAI) of the form specified in [24].
•
For the instance of Packet Application terminated in the AN (i.e., AN access authentication), the generation of the NAI and password are the responsibility of the service provider. The NAI and password should be chosen and managed using procedures that minimize the likelihood of compromise.
•
If the access authentication feature is used, the AN shall always propose CHAP as a PPP option in an
initial Link Control Protocol (LCP) Configure-Request during the PPP establishment.
•
35
The Mobile Node Identification (MN ID) that is used by the AN and the PCF on A8/A9 and A10/A11
messages is determined as follows:
36
!
If the HRPD AN uses the access authentication feature, the MN ID field shall be set to the MN ID
value returned by the AN-AAA (e.g., IMSI) following successful access authentication.
!
Otherwise, the AN/PCF shall set the MN ID field to a value that conforms to a valid MN ID
format (i.e., IMSI format). In this case, the MN ID is determined by other means.
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
HRPD IOS Assumptions
37
38
39
40
•
After the AT indicates it is ready to exchange data on the access stream, the AT and the AN initiate
PPP procedures according to [19].
•
The AT may support packet data service as specified in [9].
41
42
43
44
1-5
A.S0007-0 version 2.0 (TIA-878)
HRPD IOS Publication Version
1
November, 2001
No text.
2
1-6
A.S0007-0 version 2.0 (TIA-878)
HRPD IOS Publication Version
November, 2001
1
2
3
4
5
6
2
HRPD IOS Interfaces
This section describes the Radio Access Network interfaces associated with the HRPD IOS specification.
Where there are differences identified in the application of the IOS to cdma2000 as opposed to HRPD, the
terms in the right column of the following table are used explicitly. Otherwise, the terms in the left
column of the table shall be mapped to the corresponding terms in the right column when interpreting
Annex B and Annex C of this specification.
cdma2000 Term
BS
Base Station
BSC
Base Station Controller
MS
Mobile Station
HRPD Term
AN
Access Network
AN
Access Network
AT
Access Terminal
7
8
2.1
A8-A9 (AN - PCF) Interface
11
The specification for the A8-A9 interface is defined in [11]. While no new signaling information is defined for the interface between the AN and the PCF, updates to address HRPD (intended to incorporated
into a future revision of IS-2001) are included in Annex B.
12
2.2
9
10
A10-A11 (PCF - PDSN) Interface
15
The specification for the A10-A11 interface is defined in [11]. While no new signaling information is defined for the interface between the PCF and the PDSN, updates to address HRPD (intended to
incorporated into a future revision of IS-2001) are included in Annex C.
16
2.3
13
14
17
18
19
20
21
22
23
24
A12 (AN - AN AAA) Interface
The A12 interface between the AN and the AN-AAA entities is used for the following purposes:
1. to perform AN-level access authentication of the MS/AT device (by authenticating the results of a
CHAP challenge/response operation invoked by the AN).
2. to return the MN ID that is used on the A8/A9 and A10/A11 interfaces (following successful access
authentication of the MS/AT device). This identifier permits handoffs of PDSN packet data sessions
between ANs and between HRPD and cdma2000 systems.
If the MS/AT device access authentication feature is not used by an HRPD system, the MN ID that is
used by the AN on the A8/A9 and A10/A11 interfaces is determined by other means.
26
The A12 interface is based on the Remote Authentication Dial-In User Service (RADIUS) protocol as
defined in [18] and [25]. The interface is shown in Figure 1.2-1.
27
The A12 interface consists of the following messages:
25
28
29
30
31
32
33
34
35
•
•
•
A12 Access-Request
A12 Access-Accept
A12 Access-Reject
Note: In this document these message names are prefixed with “A12”, to conform to IOS notation convention.
The following figure shows the protocol reference model for the AN-AAA to the AN. The AN-AAA in
the visited access provider and home access provider IP networks communicate via AN-AAA proxy
servers and one or more AN-AAA brokers. Note: The use of AN-AAA brokers is optional.
2-1
A.S0007-0 version 2.0 (TIA-878)
HRPD IOS Publication Version
RADIUS
November, 2001
RADIUS RADIUS
RADIUS
UDP
UDP
UDP
UDP
UDP
UDP
IP
IP
IP
IP
IP
IP
Link
Layer
Link
Layer
Link
Layer
Link
Layer
Link
Layer
Link
Layer
PL
PL
PL
PL
PL
PL
AN
Broker
AN-AAA
Visited
AN-AAA
(optional)
1
Figure 2.3-1
2
RADIUS RADIUS
Home
AN-AAA
RADIUS Protocol Reference Model
3
4
2.3.1
5
2.3.1.1
PPP Session
Establishment
10
After the AT indicates it is ready to exchange data on the access stream, the AT and the AN initiate PPP
procedures according to [19]. PPP shall support transparency in accordance with section 4.2 of [20]. The
AN and AT shall attempt to negotiate a control character mapping, with the minimum number of escape
characters by proposing an Async-Control-Character-Map (ACCM) of 0x 00000000. Additionally, if no
PPP session is present, the AN may re-authenticate the MS/AT by reinitiating the PPP session.
11
2.3.1.2
6
7
8
9
Termination
14
The AN may release the PPP connection after the access authentication of the AT has been performed.
The AN may support a PPP inactivity timer for each PPP session. When the inactivity timer expires, the
AN shall terminate the PPP session.
15
2.3.1.3
12
13
Access Authentication
19
The AT shall support CHAP for the PPP instance on the access stream. If the AN supports access
authentication, the AN shall support CHAP for the PPP instance on the access stream. In this case, the
AN shall always propose CHAP as a PPP option in an initial LCP Configure-Request during the PPP
establishment.
20
2.3.2
16
17
18
21
22
23
24
25
26
27
28
AN-AAA Support
If the AN supports access authentication and the A12 interface, the AN shall support the RADIUS client
protocol in accordance with [25] and shall communicate user CHAP access authentication information to
the visited AN-AAA in an Access-Request message on the A12 interface. For an AN-AAA to recognize
that the transaction is related to access authentication, the Access-Request message may contain an additional 3GPP2 vendor specific attribute. Refer to Annex D, RADIUS Attributes. This attribute may also
be added by the proxy AN-AAA prior to forwarding the Access-Request message to the home AN-AAA.
On receipt of the MS/AT’s CHAP response, the AN shall send an Access-Request message, on the A12
interface, containing at a minimum:
2-2
A.S0007-0 version 2.0 (TIA-878)
HRPD IOS Publication Version
November, 2001
User-Name (1)1= NAI
CHAP-Password (3) = CHAP ID and CHAP-response
NAS-IP-Address (4) = IP address of AN
CHAP-Challenge (60)= challenge value issued by AN
1
2
3
4
HRPD Access Authentication (defined in Annex D) = Used to indicate that the Access Request
message in the context of access authentication.
5
6
Note: The CHAP access authentication password should be cryptographically strong. One
recommendation for password generation can be found in [21], Randomness Recommendations
for Security, Section 7.1.
7
8
9
10
11
12
Upon successful access authentication the visited AN-AAA shall send an Access-Accept message to the
AN on the A12 interface. The Access-Accept message shall contain at a minimum the RADIUS Callback-Id attribute (20) populated with the MN ID (e.g., IMSI) and the String field shall be set as follows:
7
6
5
4
3
Identity Digit 1 = [0H-9H] (BCD)
2
Odd/even
Indicator
= [1,0]
1
0
Type of Identity
= [110] (MN ID)
Octet
1
Identity Digit 3 = [0H-9H] (BCD)
Identity Digit 2 = [0H-9H] (BCD)
2
###
###
###
Identity Digit 2N-1 = [0H-9H] (BCD)
Identity Digit 2N-2 = [0H-9H] (BCD)
N
= [1111] (if even number of digits) or Identity Digit 2N+1 (if odd number of digits)
Identity Digit 2N = [0H-9H] (BCD)
N+1
14
The Odd/Even Indicator (octet 1; bit 3) field is set to ‘0’ for an even number of digits and to ‘1’
for an odd number of identity digits.
15
The identity digits (octet 2 etc.) are coded as follows:
13
The International Mobile Subscriber Identifier fields are coded using BCD coding format. If the
number of identity digits is even then bits 4 to 7 of the last octet shall be filled with an end mark
coded as ‘1111’.
16
17
18
19
2.3.3
20
The AN-AAA shall act as a RADIUS Server and shall follow the guidelines specified in [25].
21
22
23
24
25
26
27
28
29
AN-AAA Requirements
If the AN performs access authentication using CHAP, the AN-AAA receives a RADIUS Access-Request
message on the A12 interface from the AN with CHAP access authentication information. If the ANAAA does not have the authority to accept/deny the request, it forwards the request to the home network
or a peer (e.g., a broker), in accordance with [25]. In this case, the AN-AAA later receives an AccessAccept message from the home or broker network. The AN-AAA shall then send the Access-Accept
message to the AN, on the A12 interface.
Communications between AN-AAAs may optionally be protected with IP security. The establishment of
this security association is outside the scope of this standard. Refer also to [25] for additional RADIUS
security requirements.
30
31
1 The numbers in this list correspond to the RADIUS attribute type defined in [25].
2-3
A.S0007-0 version 2.0 (TIA-878)
HRPD IOS Publication Version
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
2.4
November, 2001
A13 (AN - AN) Interface
The information exchanged between the source and target AN is divided up into information in the target
to source direction, and source to target direction.
The information content in the target to source direction is as follows:
• Received Unicast Access Terminal Identifier (UATI). This is the previous UATI received by the
target AN from the AT, which allows the source AN to determine the session configuration parameters that are requested by the target.
• Security Layer Packet. This is the Security Layer packet, including protocol header and trailer, as
received from the AT.
• Sector ID. The target AN shall set this field to the 128-bit identifier of the sector on which the UATIRequest message is received.
The information content in the source to the target direction is as follows:
• MN ID used by the source AN over the A10 interface. This allows the target AN to use the same MN
Identifier from the previous A10 connection, once a new A10 connection has been setup.
• Session Configuration Parameters. These parameters including the Air interface protocols states,
allow the target AN to continue to use the air interface protocols already negotiated between the AT
and the source AN.
• PDSN address. This routable IP v4 address allows the target AN to reconnect (when possible) to the
same PDSN without executing a PDSN re-selection algorithm (if specified) or an internal PDSN
selection algorithm. For the case of dormant inter-AN inter-PCF handoff, the target PCF may use the
PDSN address received from the source AN to send the A11-Registration Request message.
Otherwise, the target PCF shall use the PDSN selection algorithm (if supported) or internal
algorithms to select a PDSN.
• PANID. This information allows the target AN to inform the PDSN of the PANID, in the case that it
is not provided by the AT over the air interface. The PANID, along with CANID information, allows
the PDSN to determine if there is a need to do an agent advertisement.
Note: The AT may handoff a packet data session from a serving HRPD system to a serving
cdma2000 system and back to a serving HRPD system. Therefore, following a dormant handoff, the
target AN shall use the PANID received from the AT. Otherwise, if the AT does not send the PANID
or the AN chooses not to request this information from the AT, then the target AN may use the
PANID received in the A13-Session Information Accept message from the source AN.
2.4.1
A13 Interface Network/Transport Protocol Specification
Signaling over the A13 interface require a reliable transport protocol and appropriate addressing and
routing mechanisms to deliver messages from target to source destination. The IOS application is independent of the underlying transport, which is left to the discretion of operators and manufacturers. The
signaling protocol stack available to operators and manufacturers for the A13 interface is:
IOS Application
TCP/UDP
IP
Link Layer
Physical Layer
A new TCP connection is established when a signaling message related to a call has to be exchanged over
an interface, and no such connection exists over the particular interface. Normal TCP connection
establishment procedures are used. An existing TCP connection over an interface is released when there
are no more signaling messages to be exchanged over the interface. Normal TCP connection release procedures are used. The following TCP and UDP port values are reserved for signaling on the A13 interface:
2-4
A.S0007-0 version 2.0 (TIA-878)
HRPD IOS Publication Version
November, 2001
1
•
2
3
4
5
•
A13 (AN-to-AN) 3125/tcp - This is the well-known TCP port number to be used for signaling
interconnection to another AN.
A13 (AN-to-AN) 3125/udp - This is the well-known UDP port number to be used for signaling
interconnection to another AN.
2.4.2
A13 Interface Procedures
12
This section describes the messages and procedures used between ANs on an A13 connection. The procedure for the A13 interface is a message flow to exchange AT and PDSN information between the ANs.
The information is exchanged via the following messages:
• A13-Session Information Request
• A13-Session Information Response
• A13-Session Information Confirm
• A13-Session Information Reject
13
The procedure(s) for how the target AN discovers the source AN is not specified.
14
2.4.2.1
6
7
8
9
10
11
A13-Session Information Request
16
The A13-Session Information Request message is sent by the target AN to request information about an
AT from a source AN when the target AN does not have this information.
17
2.4.2.1.1
15
18
19
20
21
22
Successful Operation
When the target AN receives a UATI Request from an AT for which the target AN has not assigned a
UATI, the target AN attempts to retrieve session related information from the source AN for the AT. The
target AN sends an A13-Session Information Request message to the source AN to indicate the information requested. The target AN shall include the received UATI, Security Layer Packet and Sector ID. The
target AN then starts timer TA13req.
24
Refer to section 5.1.1.1, A13-Session Information Request Message for the format and content of this
message.
25
2.4.2.1.2
23
Failure Operation
28
If timer TA13req expires, the target AN may choose to resend the A13-Session Information Request
message a second time. If timer TA13req expires a second time or if the target AN chooses not to resend
the A13-Request message, the target AN shall begin a new session establishment with the AT.
29
2.4.2.2
26
27
A13-Session Information Response
31
The A13-Session Information Response message is used by the source AN to respond to target AN about
a request to retrieve information about an AT.
32
2.4.2.2.1
30
Successful Operation
37
When the source AN receives an A13-Session Information Request message it checks if the session information for the requested AT exists and if it can authenticate the target AN request. After the source
AN has successfully authenticated the message contained in the A13-Session Information Request and
has the requested session state information, it sends an A13-Session Information Response message to the
target AN with the requested information.
38
Upon receipt of the A13-Session Information Response message, the target AN stops timer TA13req.
33
34
35
36
39
40
Refer to section 5.1.1.4, A13-Session Information Response Message for the format and content of this
message.
2-5
A.S0007-0 version 2.0 (TIA-878)
HRPD IOS Publication Version
1
2.4.2.2.2
2
None.
3
2.4.2.3
November, 2001
Failure Operation
A13-Session Information Confirm
5
The A13-Session Information Confirm message is used by the target AN to inform the source AN that the
target AN has successfully received the session information about an AT.
6
2.4.2.3.1
4
7
8
9
10
Successful Operation
When the target AN receives the A13-Session Information Response message from the source AN with
the requested AT information it shall send an A13-Session Information Confirm to the source AN. Upon
receipt of the A13-Session Information Confirm message, the source AN shall remove the stored session
information related to the AT in question.
12
Refer to section 5.1.1.2, A13-Session Information Confirm Message for the format and content of this
message.
13
2.4.2.3.2
14
None.
15
2.4.2.4
11
Failure Operation
A13-Session Information Reject
17
The A13-Session Information Reject message is used by the source AN to reject a request from the target
AN to retrieve session information from source AN.
18
2.4.2.4.1
16
19
20
21
22
23
24
Successful Operation
When the source AN receives an A13-Session Information Request message and it can not retrieve the
session information or can not authenticate the identity of the target AN, the source AN responds by
sending an A13-Session Information Reject message to the target AN.
Upon receipt of the A13-Session Information Reject message, the target AN stops timer TA13req. After
sending the A13-Session Information Reject message, if it exists, the source AN may retain the session
information.
26
Refer to section 5.1.1.3, A13-Session Information Reject Message for the format and content of this
message.
27
2.4.2.4.2
28
None.
25
Failure Operation
29
2-6
A.S0007-0 version 2.0 (TIA-878)
HRPD IOS Publication Version
November, 2001
1
3
HRPD IOS Call Flows
2
This section describes the call flows associated with a HRPD AT.
3
3.1
4
This section describes the call flows associated with an AT call origination in the AN.
5
3.1.1
6
This scenario describes the call flow for a successfully authenticated AT call origination in the AN.
AT Originates HRPD Session
AT Originates HRPD Session - Successful Access Authentication
AT
AN AAA
AN
PCF
PDSN
time
Session Establishment
a
AT Ready to Exchange
Data on Access Stream
b
PPP and LCP Negotiation
c
CHAP Challenge - Response
d
A12 Access-Request
e
A12 Access-Accept
f
CHAP - Authentication Success
g
Location Update Procedure
h
AT Ready to Exchange
Data on Service Stream
i
j
A9-Setup-A8
Tregreq
TA8-setup
A11-Registration Request (Lifetime, MEI)
k
A11-Registration Reply (Lifetime, accept)
l
m
A9-Connect-A8
Establishing PPP connection
n
Transmitting Packet Data
o
7
8
9
10
11
12
Figure 3.1.1-1 Initial AT Origination with HRPD Session Establishment and Key Exchange
a. The AT and the AN initiate HRPD session establishment. During this procedure, the AN does not
receive a UATI for an existing HRPD session. Since no session exists between the AT and AN, a
session is established where protocols and protocol configurations are negotiated, stored and used for
communications between the AT and the AN. Refer to [10], Section 5, Session Layer.
3-1
A.S0007-0 version 2.0 (TIA-878)
HRPD IOS Publication Version
1
2
3
4
5
6
7
8
9
10
b. The AT indicates that it is ready to exchange data on the access stream (e.g., the flow control protocol
for the default packet application bound to the AN is in the open state).
c. The AT and the AN initiate Point-to-Point Protocol (PPP) and LCP negotiations for access
authentication. Refer to [19].
d. The AN generates a random challenge and sends it to the AT in a CHAP Challenge message in
accordance with [22].
e. When the AN receives the CHAP response message from the AT, it sends an Access-Request
message on the A12 interface to the AN AAA which acts as a RADIUS server in accordance with
[25]).
f.
11
12
13
14
15
November, 2001
The AN-AAA looks up a password based on the User-name attribute in the Access-Request message
and if the access authentication passes (as specified in [22] and [25]), the AN AAA sends an AccessAccept message on the A12 interface in accordance to [25] (RADIUS). The Access-Accept message
contains a RADIUS attribute with Type set to 20 (Callback-Id), which is set to the MN ID of the AT.
Refer to Section 2.3.2, AN AAA Support.
g. The AN returns an indication of CHAP access authentication success, to the AT. Refer to [22].
18
h. If the AN supports the Location Update procedure, the AN updates the ANID in the AT using the
Location Update procedure. The AN may also retrieve the PANID from the AT if necessary. This
step may occur any time after step a.
19
i.
The AT indicates that it is ready to exchange data on the service stream (e.g., the flow control protocol for the default packet application bound to the packet data network is in the open state).
j.
The AN sends an A9-Setup-A8 message to the Packet Control Function (PCF) with Data Ready
Indicator (DRI) set to ‘1’ to establish the A8-Connection and starts timer TA8-setup. The A9-SetupA8 message shall not be sent before the AT indicates that it is ready to exchange data on the service
stream, as identified in step i.
16
17
20
21
22
23
24
28
k. The PCF recognizes that no A10 connection associated with the AT is available and selects a PDSN.
The PCF sends an A11-Registration Request message to the PDSN which includes the Mobility
Event Indicator (MEI) within the Critical Vendor/Organization Specific Extension (CVSE). The PCF
starts timer Tregreq.
29
l.
25
26
27
30
31
32
33
34
35
The A11-Registration Request message is validated and the PDSN accepts the connection by returning an A11-Registration Reply message with an accept indication and Lifetime set to the configured
Trp value. If the PDSN has data to send, it includes the Data Available Indicator within the CVSE.
The A10 connection binding information at the PDSN is updated to point to the PCF. The PCF stops
timer Tregreq.
m. The PCF sends the A9-Connect-A8 to the AN. When the AN receives the A9-Connect-A8 message it
stops timer TA8-setup.
37
n. PPP connection establishment procedure is performed between the AT and the PDSN, according to
[9]. Refer also to [19].
38
o. At this point the connection is established and packet data can flow between the AT and the PDSN.
36
39
40
3-2
A.S0007-0 version 2.0 (TIA-878)
HRPD IOS Publication Version
November, 2001
1
2
3
3.1.2
AT Originates HRPD Session - Unsuccessful Access Authentication
This scenario describes the call flow for an unsuccessful AT call origination in the AN, due to access
authentication failure.
AT
AN
AN AAA
PCF
PDSN
time
Session Establishment
a
AT Ready to Exchange
Data on Access Stream
b
PPP and LCP Negotiation
c
CHAP Challenge - Response
d
A12 Access-Request
e
A12 Access-Reject
f
CHAP - Authentication Failure
g
SessionClose
h
SessionClose
i
4
Figure 3.1.2-1 Initial AT Origination - Unsuccessful Access Authentication
5
6
7
8
9
a. The AT and the AN initiate HRPD session establishment. During this procedure, the AN does not
receive a UATI for an existing HRPD session. Since no session exists between the AT and AN, a
session is established where protocols and protocol configurations are negotiated, stored and used for
communications between the AT and the AN. Refer to [10], Section 5, Session Layer.
11
b. The AT indicates that it is ready to exchange data on the access stream (e.g., the flow control protocol
for the default packet application bound to the AN is in the open state).
12
c. The AT and the AN initiate PPP and LCP negotiations for access authentication. Refer to [19].
10
13
14
d. The AN generates a random challenge and sends it to the AT in a CHAP Challenge message, in
accordance with [22].
16
e. When the AN receives the CHAP response message from the AT, it sends an Access-Request message on the A12 interface to the AN AAA (which acts as a RADIUS server, in accordance with [25]).
17
f.
15
18
19
The AN-AAA looks up a password based on the User-name attribute in the Access-Request message
and if the access authentication fails (as specified in [22] and [25]), the AN AAA sends an AccessReject message on the A12 interface in accordance to [25] (RADIUS).
Note: For ANs that perform access authentication, the network requires that no use of a dedicated
resource, such as access to a PDSN, be allowed if authentication fails.
20
21
22
g. The AN returns an indication of CHAP access authentication failure, to the AT. Refer to [22].
23
h. The AN sends a SessionClose message to the AT, to close the HRPD session.
24
i.
The AT responds with a SessionClose message.
3-3
A.S0007-0 version 2.0 (TIA-878)
HRPD IOS Publication Version
November, 2001
1
3.2
2
This section describes the call flows associated with the re-authentication of an AT.
3
3.2.1
4
5
Re-authentication
Re-authentication of an AT in Dormant State
This scenario describes the call flow associated with re-authentication of a dormant AT. It is assumed that
the AT has already established an HRPD session.
AT
AN AAA
AN
time
Connection Establishment
a
AT Ready to Exchange
Data on Access Stream
b
PPP and LCP Negotiation
c
d
CHAP Challenge - Response
A12 Access-Request
e
A12 Access-Accept
f
CHAP - Authentication Success
g
Connection Tear-Down
(initiated by the AN)
h
6
Figure Error! Reference source not found.-1
7
8
9
10
11
12
13
14
15
Re-authentication of an AT in Dormant State
a. The AN determines that a re-authentication of an AT is required and initiates connection establishment procedures with the AT.
b. The AT indicates that it is ready to exchange data on the access stream (e.g., the flow control protocol
for the default packet application bound to the AN is in the open state).
c. The AT and the AN initiate PPP and LCP negotiations for access authentication. Refer to [19]. This
step is omitted when the AN and AT keep the PPP connection after initial access authentication.
d. The AN generates a random challenge and sends it to the AT in a CHAP Challenge message in
accordance with [22].
17
e. When the AN receives the CHAP response message from the AT, it send an Access-Request message
on the A12 Interface to the AN AAA which acts as a RADIUS server in accordance with [25].
18
f.
16
19
20
21
22
The AN-AAA looks up a password based on the User-name attribute in the Access-Request message
and if the access authentication passes (as specified in [22] and [25]), the AN AAA sends an AccessAccept message on the A12 interface in accordance to [25] (RADIUS). The Access-Accept message
contains a RADIUS attribute with Type set to 20 (Callback-Id), which is set to the MN ID of the AT.
Refer to Section 2.3.2, AN-AAA Support.
23
g. The AN returns an indication of CHAP access authentication success, to the AT. Refer to [22].
24
h. The AN initiates HRPD connection tear-down. Refer to [10], Section 6, Connection Layer.
25
26
3-4
A.S0007-0 version 2.0 (TIA-878)
HRPD IOS Publication Version
November, 2001
1
2
3
3.2.2
Re-authentication of an AT in Active State
This scenario describes the call flow associated with re-authentication of an active AT. It is assumed that
the AT has already established an HRPD session.
AT
AN
AN AAA
time
AN and AT Ready to Exchange
Data on Access Stream
a
PPP and LCP Negotiation
b
c
CHAP Challenge - Response
A12 Access-Request
d
A12 Access-Accept
e
CHAP - Authentication Success
f
AT Ready to Exchange
Data on Service Stream
g
4
Figure 3.2.2-1 Re-authentication of an AT in Active State
5
6
7
a. The AN determines that a re-Authentication of an AT is required and indicates to the AT that it wants
to open the access stream by sending the Data Ready indicator on the Access stream.
Note: The AT may turn off flow on the Service stream (e.g., the flow control protocol for the default
packet application bound to the PDSN is in the close state). The AT indicates that it is ready to
exchange data on the access stream (e.g., the flow control protocol for the default packet application
bound to the AN is in the open state).
8
9
10
11
12
13
14
15
16
17
18
b. The AT and the AN initiate PPP and LCP negotiations for access authentication. Refer to [19]. This
step is omitted when the AN and AT keep the PPP connection after initial access authentication.
c. The AN generates a random challenge and sends it to the AT in a CHAP Challenge message in
accordance with [22].
d. When the AN receives the CHAP response message from the AT, it send an Access-Request message
on the A12 Interface to the AN AAA which acts an a RADIUS server in accordance with [25]
(RADIUS).
23
e. The AN-AAA looks up a password based on the User-name attribute in the Access-Request message
and if the access authentication passes (as specified in [22] and [25]), the AN AAA sends an AccessAccept message on the A12 interface in accordance to [25] (RADIUS). The Access-Accept message
contains a RADIUS attribute with Type set to 20 (Callback-Id), which is set to the MN ID of the AT.
Refer to Section 2.3.2, AN-AAA Support.
24
f.
19
20
21
22
25
26
The AN returns an indication of CHAP access authentication success, to the AT. Refer to [22].
g. If necessary, the AT indicates that it is ready to exchange data on the service stream (e.g., the flow
control protocol for the default packet application bound to the PDSN is in the open state).
27
28
3-5
A.S0007-0 version 2.0 (TIA-878)
HRPD IOS Publication Version
November, 2001
1
3.3
2
This section describes the call flows associated with AT terminated and AT originated data delivery.
3
3.3.1
4
5
6
Data Delivery
Network Initiated Call Re-activation from Dormant State
In this scenario, it is assumed that the AT has already established a packet data session and also an HRPD
session, however it does not have an HRPD connection and there is no A8 connection between the AN
and the PCF.
AT
AN
PCF
PDSN
Transmitting Packet Data
A9-BS Service Request
time
a
b
Tbsreq9
A9-BS Service Response
Page Message
c
d
Tnet_conn
Connection Establishment
e
A9-Setup-A8
f
A9-Connect-A8
g
TA8-setup
Transmitting Packet Data
h
7
Figure 3.3.1-1 Network Initiated Call Re-activation from Dormant State
8
9
10
11
a. The PDSN sends packet data to the PCF.
b. The PCF sends an A9-BS Service Request message to the AN in order to request packet service, and
starts timer Tbsreq9.
13
c. The AN responds with an A9-BS Service Response. The PCF stops timer Tbsreq9 upon receipt of the
A9-BS Service Response message and starts timer Tnet_conn.
14
d. The AN sends a Page Message to the AT, on the control channel.
12
17
e. The AT initiates connection establishment procedures with the AN. The AN assigns a Forward
Traffic Channel, Reverse Power Control Channel and Reverse Traffic Channel. Refer to [10], Section 6.4.5.6, Connection Setup State.
18
f.
15
16
19
20
After the traffic channel is established, the AN sends an A9-Setup-A8 message to the PCF with Data
Ready Indicator set to ‘1’ to establish the A8-Connection and starts timer TA8-setup. When the PCF
receives the A9-Setup-A8 message, it stops timer Tnet_conn.
22
g. The PCF sends the A9-Connect-A8 to the AN. When the AN receives the A9-Connect-A8 message it
stops timer TA8-setup.
23
h. At this point the connection is established and packet data can flow between the AT and the PDSN.
21
24
25
3-6
A.S0007-0 version 2.0 (TIA-878)
HRPD IOS Publication Version
November, 2001
1
2
3
3.3.2
AT Initiated Call Re-activation from Dormant State (Existing HRPD Session)
This scenario describes the data origination from a dormant AT, i.e., the AT has already established a
packet data session. The AT has also established an HRPD session.
AT
AN
PCF
Connection Establishment
PDSN
time
a
A9-Setup-A8
b
TA8-setup
A9-Connect-A8
Transmitting Packet Data
c
d
4
5
6
7
8
9
10
Figure 3.3.2-1 AT Initiated Call Re-activation from Dormant State (Existing HRPD Session)
a. If the AT has data to send, the AT initiates connection establishment procedures with the AN. The
AN assigns a Forward Traffic Channel, Reverse Power Control Channel and Reverse Traffic
Channel. Refer to [10], Section 6.4.5.6, Connection Setup State.
b. After the traffic channel is established, the AN sends an A9-Setup-A8 message to the PCF with DRI
set to ‘1’ to establish the A8-Connection and starts timer TA8-setup.
13
c. The PCF sends the A9-Connect-A8 to the AN. When the AN receives the A9-Connect-A8 message it
stops timer TA8-setup. Refer to [11], Section 2.14.7.6, MS Initiated Call Re-activation from Dormant
State.
14
d. At this point the connection is established and packet data can flow between the AT and the PDSN.
11
12
15
16
3-7
A.S0007-0 version 2.0 (TIA-878)
HRPD IOS Publication Version
November, 2001
1
3.4
Connection Release
2
This section describes the call flows associated with a HRPD connection release.
3
3.4.1
4
This scenario describes the call flow associated with a connection release initiated by an AT.
Connection Release on HRPD Network - Initiated by the AT
AT
AN
PCF
PDSN
Connection Release
(Initiated by the AT)
time
a
A9-Release-A8
b
A9-Release-A8 Complete
c
Trel9
5
6
7
8
9
10
11
Figure 3.4.1-1 AT Initiated Connection Release
a. The AT initiates HRPD connection release. Refer to [10], Section 6, Connection Layer.
b. The AN sends an A9-Release-A8 message with a cause value set to “Packet call going dormant”, to
the PCF to request the PCF to release the A8 connection. The AN starts timer Trel9.
c. The PCF initiates procedures for releasing the A8 connection and sends an A9-Release-A8 Complete
message to the AN. The AN stops timer Trel9. At this time, A10 connection for this call is retained.
12
13
3-8
A.S0007-0 version 2.0 (TIA-878)
HRPD IOS Publication Version
November, 2001
1
3.4.2
Connection Release on HRPD Network - Initiated by the AN.
2
This scenario describes the call flow associated with a connection release initiated by the AN/PCF.
AT
AN
PCF
PDSN
time
A9-Release-A8
a
A9-Release-A8 Complete
b
TA8-setup
Connection Release
(Initiated by the AN)
c
3
4
5
6
7
8
9
10
11
Figure 3.4.2-1 AN Initiated Connection Release
a. The AN initiates release of the A8 connection by transmitting an A9-Release-A8 message to the PCF
with the cause value set to “Packet call going dormant”, to request the PCF to release the associated
dedicated resources. The AN starts timer Trel9.
b. The PCF acknowledges the A9-Release-A8 message by returning an A9-Release-A8 Complete
message. The AN stops timer Trel9.
c. The AN shall initiate HRPD connection release. This step may occur in parallel with steps a and b.
Refer to [10], Section 6, Connection Layer.
12
13
3-9
A.S0007-0 version 2.0 (TIA-878)
HRPD IOS Publication Version
November, 2001
1
3.5
2
This section describes the call flows associated with HRPD session and packet data session releases.
3
3.5.1
4
5
6
Session Release
HRPD Session Release - Initiated by the AT (A8 Connection Established)
This scenario describes the call flows associated with an HRPD session release initiated by an AT. This
subsequently leads to a packet data session release, if present. It is assumed that the A8 connection is already established.
AT
AN
PCF
PDSN
time
Session Release
(Initiated by the AT)
a
b
A9-Release-A8
A11-Registration Request (Lifetime=0, Acct data)
Trel9
c
Tregreq
A11-Registration Reply (Lifetime=0, Accept)
A9-Release-A8 Complete
d
e
7
8
9
10
11
12
13
14
15
Figure 3.5.1-1 AT Initiated HRPD Session Release (A8 Connection Established)
a. The AT initiates HRPD session release. Refer to [10], Section 5, Session Layer.
b. After the AN closes the HRPD session, the AN sends an A9-Release-A8 message with a cause value
set to “Normal call release”, to the PCF to request the PCF to release the associated dedicated
resource and the associated A10 connection. The AN starts timer Trel9.
c. The PCF sends an A11-Registration Request message to the PDSN with a Lifetime timer value of
zero to close the A10 connection. Accounting data is included in the message. The PCF starts timer
Tregreq. Refer to [11], Section 2.15.5.6, Packet Data Service Session Clearing - MS Initiated.
17
d. The PDSN stores the accounting data for further processing and responds with an A11-Registration
Reply message 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.
16
19
20
3-10
A.S0007-0 version 2.0 (TIA-878)
HRPD IOS Publication Version
November, 2001
1
2
3
4
3.5.2
HRPD Session Release - Initiated by the AT (No Connection Established)
This scenario describes the call flows associated with an HRPD session release initiated by an AT. This
subsequently leads to a packet data session release, if present. It is assumed that the A8 connection is not
established.
AT
AN
PCF
PDSN
time
Session Release
(Initiated by the AT)
a
A9-Update-A8
b
A11-Registration Request (Lifetime=0, Acct data)
c
Tregreq
Tupd9
A11-Registration Reply (Lifetime=0, Accept)
A9-Update-A8 Ack
d
e
5
6
7
8
9
10
11
12
13
Figure 3.5.2-1 AT Initiated HRPD Session Release (No A8 Connection Established)
a. The AT initiates HRPD session tear-down. Refer to [10], Section 5, Session Layer.
b. After the AN closes the HRPD session, the AN sends an A9-Update-A8 message with a cause value
set to “Power down from dormant state”, to the PCF to request the PCF to release the associated
dedicated resource and the associated A10 connection. The AN starts timer Tupd9.
c. The PCF sends an A11-Registration Request message to the PDSN with a Lifetime timer value of
zero to close the A10 connection. Accounting data is included in the message. The PCF starts timer
Tregreq. Refer to [11], Section 2.15.5.6, Packet Data Service Session Clearing - MS Initiated.
15
d. The PDSN stores the accounting data for further processing and responds with an A11-Registration
Reply to complete the release of the A10 connection. The PCF stops timer Tregreq.
16
e. The PCF sends an A9-Update-A8 Ack message to the AN. The AN stops timer Tupd9.
14
17
18
3-11
A.S0007-0 version 2.0 (TIA-878)
HRPD IOS Publication Version
1
2
3
4
3.5.3
November, 2001
HRPD Session Release - Initiated by the AN (A8 Connection Established)
This scenario describes the call flow associated with an HRPD session release initiated by the AN. This
subsequently leads to a packet data session release, if present. It is assumed that the A8 connection is already established.
AT
AN
PCF
PDSN
Session Release
(Initiated by the AN)
time
a
b
A9-Release-A8
A11-Registration Request (Lifetime=0)
c
A11-Registration Reply (Lifetime=0, accept)
d
Tregreq
Trel9
A9-Release-A8 Complete
e
5
6
7
8
9
10
11
12
Figure 3.5.3-1 AN Initiated HRPD Session Release (A8 Connection Established)
a. The AN initiates HRPD session release. Refer to [10], Section 5, Session Layer.
b. The AN sends an A9-Release-A8 message with a cause value set to “Normal call release”, to the PCF
to request the PCF to release the associated dedicated resource and the associated A10 connection.
The AN starts timer Trel9.
c. The PCF sends an A11-Registration Request message with Lifetime set to zero, to the PDSN. The
PCF starts timer Tregreq.
14
d. The PDSN sends an A11-Registration Reply message to the PCF. The PCF closes the A10 connection for the AT and stops timer Tregreq.
15
e. The PCF sends an A9-Release-A8 Complete message to the AN. The AN stops timer Trel9.
13
16
17
3-12
A.S0007-0 version 2.0 (TIA-878)
HRPD IOS Publication Version
November, 2001
1
2
3
4
3.5.4
HRPD Session Release - Initiated by the AN (No A8 Connection Established)
This scenario describes the call flows associated with an HRPD session release initiated by an AN. This
subsequently leads to a packet data session release, if present. It is assumed that the A8 connection is not
established.
AT
AN
PCF
PDSN
Session Release
(Initiated by the AN)
time
a
b
A9-Update-A8
A11-Registration Request (Lifetime=0)
c
A11-Registration Reply (Lifetime=0, accept)
d
Tregreq
Tupd9
A9-Update-A8 Ack
e
5
6
7
8
9
10
11
12
13
Figure 3.5.4-1 AN Initiated HRPD Session Release (No A8 Connection Established)
a. The AN initiates HRPD session tear-down. Refer to [10], Section 5, Session Layer.
b. After the AN closes the HRPD session, the AN sends an A9-Update-A8 message with a cause value
set to “Power down from dormant state”, to the PCF to request the PCF to release the associated
dedicated resource and the associated A10 connection. The AN starts timer Tupd9.
c. The PCF sends an A11-Registration Request message to the PDSN with a Lifetime timer value of
zero to close the A10 connection. Accounting data is included in the message. The PCF starts timer
Tregreq. Refer to [11], Section 2.15.5.6, Packet Data Service Session Clearing - MS Initiated.
15
d. The PDSN stores the accounting data for further processing and responds with an A11-Registration
Reply to complete the release of the A10 connection. The PCF stops timer Tregreq.
16
e. The PCF sends an A9-Update-A8 Ack message to the AN. The AN stops timer Tupd9.
14
17
18
3-13
A.S0007-0 version 2.0 (TIA-878)
HRPD IOS Publication Version
November, 2001
1
3.5.5
Packet Data Session Release - Initiated by the PDSN
2
This scenario describes the call flow associated with an A10 release initiated by the PDSN.
AT
AN
PCF
PDSN
A11-Registration Update
time
a
Tregupd
A11-Registration Acknowledgement
b
A11-Registration Request (Lifetime=0)
c
A11-Registration Reply (Lifetime=0, accept)
d
Tregreq
e
A9-Disconnect-A8
Tdiscon9
A9-Release-A8
f
A9-Release-A8 Complete
g
Trel9
Connection Release
h
3
Figure 3.5.5-1 PDSN Initiated Packet Data Session Release
4
6
a. The PDSN initiates closure of the A10 connection by sending an A11-Registration Update message to
the PCF. The PDSN starts timer Tregupd.
7
b. The PCF responds with an A11-Registration Acknowledge message. The PDSN stops timer Tregupd.
5
8
9
10
11
c. The PCF sends an A11-Registration Request message with Lifetime set to zero, to the PDSN. The
PCF starts timer Tregreq.
d. The PDSN sends an A11-Registration Reply message to the PCF. The PCF closes the A10 connection for the AT and stops timer Tregreq.
Note: If there is no existing A8 connection the remaining steps are omitted.
12
13
e. The PCF sends an A9-Disconnect-A8 message to the AN and starts timer Tdiscon9.
14
f.
15
16
The AN sends an A9-Release-A8 message with a cause value set to “Normal call release”, to the PCF
to request the PCF to release the associated dedicated resources. The AN starts timer Trel9. The PCF
stops timer Tdiscon9.
18
g. The PCF acknowledges the A9-Release-A8 message by returning an A9-Release-A8 Complete. The
AN stops timer Trel9.
19
h. The AN may initiate HRPD connection release. Refer to [10], Section 6, Connection Layer.
17
20
21
3-14
A.S0007-0 version 2.0 (TIA-878)
HRPD IOS Publication Version
November, 2001
1
3.6
2
This section describes the call flows associated with AT dormant handoff between ANs.
3
3.6.1
4
5
6
Dormant Handoff of HRPD AT between ANs - Served by the Same PDSN
AN-AN Dormant Handoff with Successful Retrieval of HRPD Session Information
This scenario describes the call flow associated with a dormant handoff between ANs when the HRPD
session information is successfully retrieved over the A13 interface. It is assumed that the AT has crossed
a mobility boundary.
Target
AN
AT
Target
PCF
Source
AN
Source
PCF
PDSN
time
a
Initiate Session
Establishment
A13-Session Information Request
b
A13-Session Information Response
c
TA13req
Complete Session
Establishment
d
Location Update
Procedures
e
A13-Session Information Confirm
f
A9-Setup-A8
g
A11-Registration Request (Lifetime, MEI)
h
A11-Registration Reply (Lifetime, accept)
i
A11-Registration Update
j
Tregreq
Tregupd
TA8-setup
Tregreq
A11-Registration Acknowledge
k
A11-Registration Request
(Lifetime=0)
l
A11-Registration Reply
(Lifetime=0, accept)
m
n
A9-Release-A8-Complete
7
8
9
10
11
12
13
14
15
Figure 3.6.1-1
Inter-PCF/Intra-PDSN Dormant AN-AN HO - Successful Operation
a. The AT and the target AN initiate HRPD session establishment. During this procedure, the target AN
receives the UATI of an existing HRPD session (if available). The UATI can be used as an identifier
for the existing HRPD session when the target AN attempts to retrieve the existing HRPD session
State Information from the Source AN.
b. The target AN sends an A13-Session Information Request message to the source AN to request the
HRPD session information for the AT. The A13-Session Information Request message shall include
the received UATI, the Security Layer Packet and Sector ID. The target AN starts timer TA13req.
3-15
A.S0007-0 version 2.0 (TIA-878)
HRPD IOS Publication Version
1
2
3
4
5
6
7
November, 2001
c. The source AN validates the A13-Session Information Request and sends the requested HRPD session information of the AT to the target AN in an A13-Session Information Response message. The
target AN stops timer TA13req.
d. The AT and the target AN complete the establishment of the HRPD session. Depending on the state
of the AT and the target AN, either an existing HRPD session may be re-established, or a new HRPD
session may be initiated if required. This step may be null if no further over-the-air signaling is
required.
11
e. If the target AN supports the Location Update procedure, the target AN updates the ANID in the AT
using the Location Update procedure. The target AN may also retrieve the PANID from the AT if
necessary (e.g., the Session Configuration retrieved in step c indicates that the Source AN does not
support the Location Update procedure).
12
f.
8
9
10
13
14
15
16
The target AN sends an A13-Session Information Confirm to the source AN to indicate that the target
AN has received the HRPD session information. Upon receipt of the A13-Session Information
Confirm message the source AN deletes the AT HRPD session information in question.
g. The target AN sends an A9-Setup-A8 message, with Data Ready Indicator set to ‘0’, to the target PCF
and starts timer TA8-setup. The handoff indicator of the A9 Indicators IE shall be set to ‘0’.
21
h. The target PCF selects the PDSN using the PDSN address provided in the A13-Session Information
Response message or using PDSN selection algorithms as specified in [11], and sends an A11Registration Request message to the PDSN. The A11-Registration Request message includes the
MEI within the CVSE. The target PCF starts timer Tregreq. Refer to [11], Section 2.15.5.8, Inter-PCF
Dormant Handoff - Mobile Continues to be Served by the Serving PDSN.
22
i.
The A11-Registration Request message is validated and the PDSN accepts the connection by
returning an A11-Registration Reply message with an accept indication and the Lifetime set to the
configured Trp value. If the PDSN has data to send, it includes the Data Available Indicator within
the CVSE. The A10 connection binding information at the PDSN is updated to point to the target
PCF. The target PCF stops timer Tregreq.
j.
The PDSN initiates closure of the A10 connection with the source PCF by sending an A11-Registration Update message. The PDSN starts timer Tregupd.
17
18
19
20
23
24
25
26
27
28
30
k. The source PCF responds with an A11-Registration Acknowledge message. The PDSN stops timer
Tregupd.
31
l.
29
32
33
34
35
36
37
The source PCF sends an A11-Registration Request message with Lifetime set to zero, to the PDSN.
The source AN/PCF starts timer Tregreq.
m. The PDSN sends an A11-Registration Reply message to the source PCF. The source PCF closes the
A10 connection for the AT and stops timer Tregreq.
n. Assuming the Data Availability Indicator was not present in step i, the target PCF responds to the
target AN with an A9-Release-A8-Complete message. The target AN stops timer TA8-setup. Note:
This step can occur any time after step i.
38
39
3-16
A.S0007-0 version 2.0 (TIA-878)
HRPD IOS Publication Version
November, 2001
1
2
3
3.6.2
Dormant AN-AN Handoff with HRPD Session Information Transfer Failure
This scenario describes the call flow associated with a dormant handoff between ANs when the HRPD
session information can not be retrieved successfully from the source AN.
Target
AN
AT
Target
PCF
Source
AN
Source
PCF
AAA-AN
PDSN
Initiate Session
Establishment
time
a
A13-Session Information Request
b
A13-Session Information Reject
c
TA13req
Complete Session
Establishment
d
Location Update
Procedures
e
Access Authentication
f
g
A9-Setup-A8
A11-Registration Request (Lifetime, MEI)
h
A11-Registration Reply (Lifetime, accept)
i
Tregreq
A11-Registration Update
j
Tregupd
TA8-setup
A11-Registration Acknowledge
Tregreq
A11-Registration Request
(Lifetime=0)
A11-Registration Reply
(Lifetime=0, accept)
A9-Release-A8-Complete
k
l
m
n
o
Connection Release
4
5
6
7
8
9
10
11
12
13
14
15
Figure 3.6.2-1
Inter-PCF/Intra-PDSN Dormant AN-AN HO - Transfer Failure
a. The AT and the target AN initiate HRPD session establishment. During this procedure, the target AN
receives the UATI of an existing HRPD session (if available). The UATI can be used as an identifier
for the existing HRPD session when the target AN attempts to retrieve the existing HRPD session
State Information from the Source AN.
b. The target AN sends an A13-Session Information Request message to the source AN to request the
HRPD session information for the AT. The A13-Session Information Request message shall include
the received UATI and the Security Layer Packet. The target AN starts timer TA13req.
c. The source AN cannot validate the A13-Session Information Request or does not have the requested
AT HRPD session information and sends an A13-Session Information Reject message to the target
AN. The target AN stops the timer TA13req.
3-17
A.S0007-0 version 2.0 (TIA-878)
HRPD IOS Publication Version
1
2
3
November, 2001
d. The AT and the target AN complete the establishment of the HRPD session. Depending on the state
of the AT and the target AN, either an existing session may be re-established, or a new HRPD session
may be initiated if required. This step may be null if no further over-the-air signaling is required.
6
e. If the target AN supports the Location Update procedure, the target AN updates the ANID in the AT
using the Location Update procedure. The target AN may also retrieve the PANID from the AT if
necessary.
7
f.
4
5
8
9
10
11
12
13
14
If access authentication is enabled/supported at the target AN, it shall initiate PPP on the access
stream. The AN initiates an access authentication of the AT using CHAP according to [22]. The AN
authenticates the results of the challenge with the AN_AAA, which acts as a RADIUS server
according to [25]. The AN shall use the MN ID received from the AN-AAA in the A12 AccessAccept message, in messages on the A9/A11 interfaces. Refer to Section 2.3, A12 (AN-AN AAA)
Interface.
g. The target AN transmits an A9-Setup-A8 message, with Data Ready Indicator set to ‘0’, to target PCF
and starts timer TA8-setup. The handoff indicator of the A9 Indicators IE shall be set to ‘0’.
19
h. The target PCF selects a PDSN for this call using PDSN selection algorithms as specified in [10].
The target PCF sends an A11-Registration Request message to the selected PDSN. The A11Registration Request message includes the MEI within the CVSE. The target PCF starts timer
Tregreq. Refer to [11], Section 2.15.5.8, Inter-PCF Dormant Handoff - Mobile Continues to be Served
by the Serving PDSN.
20
i.
The A11-Registration Request message is validated and the PDSN accepts the connection by
returning an A11-Registration Reply message with an accept indication and the Lifetime set to the
configured Trp value. If the PDSN has data to send, it includes the Data Available Indicator within
the CVSE. The A10 connection binding information at the PDSN is updated to point to the target
PCF. The target PCF stops timer Tregreq.
j.
The PDSN initiates closing of the A10 connection with the source PCF by sending an A11-Registration Update message. The PDSN starts timer Tregupd.
15
16
17
18
21
22
23
24
25
26
28
k. The source PCF responds with an A11-Registration Acknowledge message. The PDSN stops timer
Tregupd.
29
l.
27
30
31
32
The source PCF sends an A11-Registration Request message with Lifetime set to zero, to the PDSN.
The source AN/PCF starts timer Tregreq.
m. The PDSN sends an A11-Registration Reply message to the source PCF. The source PCF closes the
A10 connection for the AT and stops timer Tregreq.
35
n. Assuming the Data Availability Indicator was not present in step i, the target PCF responds to the
target AN with an A9-Release-A8 Complete message. The target AN stops timer TA8-setup. Note:
This step can occur any time after step i.
36
o. The AN may initiate HRPD connection release. Refer to [10], Section 6, Connection Layer.
33
34
37
38
3-18
A.S0007-0 version 2.0 (TIA-878)
HRPD IOS Publication Version
November, 2001
1
3.7
2
This section describes the call flows associated with an active HRPD session.
3
3.7.1
4
5
Active HRPD Session
AN Detects a Loss of the Airlink During an Active HRPD Session
This scenario describes the call flow associated with an AT detecting an airlink loss during an active
HRPD session.
AT
AN
PCF
PDSN
time
Active HRPD Session
AN loses the airlink to the AT
a
Tairdrop
A9-AL Disconnected
b
A9-AL Disconnected Ack
c
Tald9
AN detects the airlink to the AT
d
A9-Al Connected
e
A9-AL Connected Ack
f
Talc9
6
Figure 3.7.1-1
7
AN Detects Loss of Airlink During Active HRPD Session
8
a. The AN determines that it is not receiving any transmissions from the AT and starts timer Tairdrop.
9
b. The AN sends an A9-AL Disconnected message to the PCF to stop data flows and starts timer Tald9.
11
c. Upon receipt of the A9-AL Disconnected message, the PCF sends an A9-AL Disconnected Ack
message to the AN. The AN stops timer Tald9.
12
d. The AN detects an airlink from the AT. AN stops the timer Tairdrop.
13
e. The AN sends an A9-AL Connected message to PCF and starts timer Talc9.
14
f.
10
The PCF responds to the AN with an A9-AL Connected Ack-A8 message. The AN stops timer Talc9.
15
16
3-19
A.S0007-0 version 2.0 (TIA-878)
HRPD IOS Publication Version
1
November, 2001
No text.
2
3-20
A.S0007-0 version 2.0 (TIA-878)
HRPD IOS Publication Version
November, 2001
1
4
HRPD and cdma2000 IOS Transition Call Flows
4
This section describes the call flows associated with handoffs between HRPD and cdma2000 systems, for
hybrid MS/ATs. Where the AN and PCF or the BSC and PCF are combine into one entity in this section,
it is assumed that the messaging on A8/A9 is identical to the corresponding call flows in Section 3.
5
4.1
6
This section describes the call flows for dormant handoffs between HRPD and cdma2000 systems.
7
4.1.1
2
3
8
9
10
11
12
13
14
15
16
Dormant Cross System Handoff - Served by the Same PDSN.
cdma2000 to HRPD Dormant Packet Data Session Handoff - Existing HRPD Session
This scenario describes the call flow associated with an MS/AT dormant handoff from an cdma2000 to a
HRPD system, when the HRPD system supports unsolicited Location Notification messages. Refer to
[10]. Based on the MS/AT changing to a different ANID or for other reasons, a dormant handoff from
cdma2000 to HRPD is determined to be required. In this scenario, it is assumed that the MS/AT has
already established an HRPD session, however it does not have a connection established. In addition, the
MS/AT is configured to send unsolicited location notifications, upon return to the HRPD system. This
call flow assumes that no HRPD mobility boundary has been crossed since the MS/AT last reported a
mobility event to any HRPD system. If an HRPD mobility boundary has been crossed , the call flow is as
described in section 3.6.1, AN-AN Dormant Handoff with Successful Retrieval of Session Information.
Target
AN
MS/AT
Target
PCF
Source
BSC/PCF
PDSN
time
a
Location Update
Procedures
b
A9-Setup-A8
A11-Registration Request (Lifetime, MEI)
c
A11-Registration Reply (Lifetime, accept)
d
A11-Registration Update
e
Tregreq
Tregupd
TA8-setup
A11-Registration Acknowledge
f
A11-Registration Request (Lifetime=0)
g
Tregreq
A11-Registration Reply (Lifetime=0, accept)
A9-Release-A8
Complete
h
i
17
18
19
20
21
22
23
24
25
Figure 4.1.1-1 cdma2000 to HRPD Dormant Packet Data Session HO - Existing HRPD Session
a. The change of AN is indicated by the Location Update procedures as defined in [10].
b. The target AN sends an A9-Setup-A8 message, with Data Ready Indicator set to ‘0’, to the target PCF
and starts timer TA8-setup. The handoff indicator of the A9 Indicators IE shall be set to ‘0’.
c. If the PDSN address is not available to the target PCF by other means, the target PCF selects a PDSN
for this connection using the PDSN selection algorithm as specified in [10]. The target PCF sends an
A11-Registration Request message to the PDSN. The A11-Registration Request message includes
4-1
A.S0007-0 version 2.0 (TIA-878)
HRPD IOS Publication Version
the MEI, the PANID of the source PCF and the Current Access Network Identifiers (CANID) of the
target PCF, within the CVSE. The target PCF starts timer Tregreq.
1
2
3
4
5
6
7
8
9
10
d. The A11-Registration Request message is validated and the PDSN accepts the connection by
returning an A11-Registration Reply message with an accept indication and the Lifetime set to the
configured Trp value. If the PDSN has data to send, it includes the Data Available Indicator within
the CVSE. The A10 connection binding information at the PDSN is updated to point to the target
PCF. The target PCF stops timer Tregreq.
e. The PDSN initiates closure of the A10 connection with the source BSC/PCF by sending an A11-Registration Update message. The PDSN starts timer Tregupd.
f.
11
12
13
November, 2001
The source BSC/PCF responds with an A11-Registration Acknowledge message. The PDSN stops
timer Tregupd.
g. The source BSC/PCF sends an A11-Registration Request message with Lifetime set to zero, to the
PDSN. The source BSC/PCF starts timer Tregreq.
15
h. The PDSN sends an A11-Registration Reply message to the source BSC/PCF. The source BSC/PCF
closes the A10 connection for the MS/AT and stops timer Tregreq.
16
i.
14
17
The target PCF responds to the target AN with an A9-Release-A8 Complete message. The target AN
stops timer TA8-setup. Note: This step can occur any time after step d.
18
19
4-2
A.S0007-0 version 2.0 (TIA-878)
HRPD IOS Publication Version
November, 2001
1
2
3
4
5
4.1.2
cdma2000 to HRPD Dormant Packet Data Session Handoff - New HRPD Session
This scenario describes the call flow associated with an MS/AT dormant handoff from an cdma2000 to a
HRPD system. Based on an MS/AT report that it crossed a network specified threshold for signal
strength or for other reasons, a dormant handoff from cdma2000 to HRPD is determined to be required
when the dormant MS/AT transitions from cdma2000 to HRPD.
Target
AN/PCF
MS/AT
Source
BSC/PCF
Target
AN AAA
PDSN
time
Session Establishment
a
AT Ready to Exchange
Data on Access Stream
b
PPP and LCP Negotiation
c
CHAP Challenge - Response
d
A12 Access-Request
e
A12 Access-Accept
f
CHAP - Authentication Success
g
Location Update Procedures
h
AT Ready to Exchange
Data on Service Stream
i
A11-Registration Request (Lifetime, MEI)
j
A11-Registration Reply (Lifetime, accept)
k
Tregreq
l
A11-Registration Update
Tregupd
A11-Registration Acknowledge
m
A11-Registration Request (Lifetime=0)
n
Tregreq
A11-Registration Reply (Lifetime=0, accept)
o
6
7
8
9
10
11
12
13
14
15
16
17
18
Figure 4.1.2-1 cdma2000 to HRPD Dormant Packet Data Session Handoff - New HRPD Session
a. The AT and the AN initiate HRPD session establishment. During this procedure, the AN does not
receive a UATI for an existing HRPD session. Since no HRPD session exists between the MS/AT
and target AN/PCF, an HRPD session is established where protocols and protocol configurations are
negotiated, stored and used for communications between the MS/AT and the AN. Refer to [10],
Section 5, Session Layer.
b. The AT indicates that it is ready to exchange data on the access stream (e.g., the flow control protocol
for the default packet application bound to the AN is in the open state).
c. After HRPD session configuration the MS/AT initiates PPP and LCP negotiations for access authentication. Refer to [19].
d. The target AN/PCF generates a random challenge and sends it to the MS/AT in a CHAP Challenge
message in accordance with [22].
4-3
A.S0007-0 version 2.0 (TIA-878)
HRPD IOS Publication Version
November, 2001
3
e. When the target AN/PCF receives the CHAP response message from the MS/AT, it sends an AccessRequest message on the A12 interface to the AN AAA which acts as a RADIUS server in accordance
with [25].
4
f.
1
2
5
6
7
8
9
10
The target AN-AAA looks up a password based on the User-name attribute in the Access-Request
message and if the access authentication passes (as specified in [22] and [25]), the AN AAA sends an
Access-Accept message on the A12 interface in accordance to [25] (RADIUS). The Access-Accept
message contains a RADIUS attribute with Type set to 20 (Callback-Id), which is set to the MN ID of
the AT. Refer to Section 2.3.2, AN-AAA Support.
g. The target AN/PCF returns an indication of CHAP access authentication success, to the MS/AT.
Refer to [22].
13
h. If the target AN supports the Location Update procedure, the target AN updates the ANID in the AT
using the Location Update procedure. The target AN may also retrieve the PANID from the AT if
necessary. This step may occur any time after step a.
14
i.
The AT indicates that it is ready to exchange data on the service stream. (E.g., the flow control
protocol for the default packet application bound to the packet data network is in the open state).
j.
The target AN/PCF sends an A11-Registration Request message to the PDSN. The A11-Registration
Request message includes the MEI, the PANID of the source and the CANID of the target PCF,
within the CVSE. If PANID is not sent in step h, the AN/PCF sets all of the fields within the PANID
and the CANID to zero. The target AN/PCF starts timer Tregreq.
11
12
15
16
17
18
19
24
k. The A11-Registration Request message is validated and the PDSN accepts the connection by returning an A11-Registration Reply message with an accept indication and Lifetime set to the configured
Trp value. If the PDSN has data to send, it includes the Data Available Indicator within the CVSE.
The A10 connection binding information at the PDSN is updated to point to the target AN/PCF. The
target AN/PCF stops timer Tregreq.
25
l.
20
21
22
23
26
27
28
29
30
31
32
The PDSN initiates closure of the A10 connection with the source BSC/PCF by sending an A11-Registration Update message. The PDSN starts timer Tregupd.
m. The source BSC/PCF responds with an A11-Registration Acknowledge message. The PDSN stops
timer Tregupd.
n. The source BSC/PCF sends an A11-Registration Request message with Lifetime set to zero, to the
PDSN. The source BSC/PCF starts timer Tregreq.
o. The PDSN sends an A11-Registration Reply message to the source BSC/PCF. The source BSC/PCF
closes the A10 connection for the MS/AT and stops timer Tregreq.
33
34
4-4
A.S0007-0 version 2.0 (TIA-878)
HRPD IOS Publication Version
November, 2001
1
2
3
4
5
4.1.3
HRPD to cdma2000 Dormant Packet Data Session Handoff
This scenario describes the call flow associated with an MS/AT dormant handoff from a HRPD to an
cdma2000 system. Based on the MS/AT changing to a different ANID or for other reasons, a dormant
handoff from HRPD to cdma2000 is determined to be required. In this scenario, it is assumed that the
MS/AT has already established an HRPD session, however it does not have a connection established.
Target
BSC/PCF
MS/AT
Source
AN/PCF
PDSN
time
Origination (DRS='0')
a
BS Ack Order
b
A11-Registration Request (Lifetime, MEI)
c
A11-Registration Reply (Lifetime, accept)
d
A11-Registration Update
e
Tregreq
Tregupd
A11-Registration Acknowledge
f
A11-Registration Request (Lifetime=0)
g
Tregreq
A11-Registration Reply (Lifetime=0, accept)
h
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
Figure 4.1.3-1 HRPD to cdma2000 Dormant Packet Data Session Handoff
a. Upon transitioning to the cdma2000 system, the MS/AT transmits an Origination Message with DRS
set to ‘0’ and with layer 2 acknowledgment required, over the access channel of the air interface to
the target BSC/PCF to request service. This message may contain the SID, NID and PZID corresponding to the source PCF from which the MS/AT is coming, if this capability is supported by the air
interface. If available, these values are used to populate the PANID field of the A11-Registration
Request message that the target BSC/PCF sends to the PDSN.
b. The target BSC/PCF acknowledges receipt of the Origination Message with a Base Station Acknowledgment Order to the MS/AT.
c. The target BSC/PCF sends an A11-Registration Request message to the PDSN. The A11-Registration Request message includes the MEI, the PANID of the source PCF and the CANID of the target
PCF, within the CVSE. The target BSC/PCF starts timer Tregreq.
d. The A11-Registration Request message is validated and the PDSN accepts the connection by returning an A11-Registration Reply message with an accept indication and the Lifetime set to the configured Trp value. If the PDSN has data to send, it includes the Data Available Indicator within the CVSE.
The A10 connection binding information at the PDSN is updated to point to the target BSC/PCF. The
target BSC/ PCF stops timer Tregreq.
If the PDSN responds to the target BSC/PCF with the Data Available Indicator, the target BSC/PCF
establishes a traffic channel ([10] 2.15.5.4-1). In this case the remaining steps in this procedure are
omitted.
e. The PDSN initiates closure of the A10 connection with the source AN/PCF by sending an A11-Registration Update message. The PDSN starts timer Tregupd.
4-5
A.S0007-0 version 2.0 (TIA-878)
HRPD IOS Publication Version
1
2
3
4
5
6
f.
November, 2001
The source AN/PCF responds with an A11-Registration Acknowledge message. The PDSN stops
timer Tregupd.
g. The source AN/PCF sends an A11-Registration Request message with Lifetime set to zero, to the
PDSN. The source AN/PCF starts timer Tregreq.
h. The PDSN sends an A11-Registration Reply message to the source AN/PCF. The source AN/PCF
closes the A10 connection for the MS/AT and stops timer Tregreq.
7
8
4-6
A.S0007-0 version 2.0 (TIA-878)
HRPD IOS Publication Version
November, 2001
1
4.2
MS/AT Terminated Voice Call During Active HRPD Packet Data Session
3
This section describes the call flows associated with an MS/AT terminated voice call during active HRPD
packet data session.
4
4.2.1
2
5
6
7
MS/AT Terminated Voice Call During Active HRPD Data Packet (Intra-PDSN/Inter-PCF)
This scenario describes the call flow associated with an MS/AT terminated voice call while the MS/AT
has an active HRPD packet data session. The HRPD packet data session is handed off to the cdma2000
system as a concurrent call service if the MS/AT has and selects this capability.
MS/AT
BS
cdma2000
PCF1
HRPD
AN
PCF2
PDSN
time
HRPD Active Data Session
a
Page
x
MS/AT stops transmitting to the AN
b
A9-AL Disconnected
c
A9-AL Disconnected Ack
d
Tald9
Page Response
e
TCH Setup
f
Alert with Info
g
Origination for
Concurrent Service
h
A9-Setup-A8
TA8-Setup
i
Tairdrop
Tregreq
A11-Registration Request (Lifetime, MEI)
j
A11-Registration Reply (Lifetime, accept)
k
A9-Connect-A8
l
m
IS-2000 Active Data Session
n
Connect Order
A11-Registration Update
Tregupd
A11-Registration Acknowledge
o
p
A11-Registration Request (Lifetime=0)
Tregreq
q
A11-Registration Reply (Lifetime=0, Accept)
r
A9-Release-A8
x
s
Trel9
A9-Release-A8 Complete
t
8
9
Figure 4.2.1-1 Voice Call Termination During Active HRPD Packet Data Session (Inter-PCF)
4-7
A.S0007-0 version 2.0 (TIA-878)
HRPD IOS Publication Version
1
2
3
November, 2001
a. The BS sends a Page Message containing the MS/AT address over the paging channel. The MS/AT
may ignore this Page Message to continue the HRPD session. If the MS/AT ignores the message,
following steps are not performed.
5
b. The AN determines that it is not receiving any transmissions from the MS/AT and starts timer
Tairdrop.
6
c. The AN sends an A9-AL Disconnected message to PCF2 to stop data flow and starts timer Tald9.
4
8
d. Upon receipt of the A9-AL Disconnected message, PCF2 sends an A9-AL Disconnected Ack to the
AN. The AN stops timer Tald9.
9
e. The MS/AT sends a Page Response message to the BS. This step can occur any time after step c.
7
10
f.
The BS establishes a traffic channel.
11
g. The BS sends an Alert with Info message to indicate the MS/AT to ring.
15
h. The MS/AT and the cdma2000 system set up the data session for handoff from HRPD as a concurrent
call service if the MS/AT supports the concurrent call service capability and selects to handoff the
data session from the HRPD to the cdma2000 system. Refer to [11], Section 2.17.2.1 steps (a) to step
(g).
16
i.
The BS sends an A9-Setup-A8 message to PCF1 to establish A8 connection and starts timer TA8setup. If the MS/AT has indicated the presence of data ready to send, the BS shall set the Data Ready
Indicator to 1; otherwise, the BS shall set the Ready Indicator to 0.
j.
PCF1 sends an A11-Registration Request message to the PDSN to establish the A10 connection to
handoff from the HRPD system to the cdma2000 system. PCF1 starts timer Tregreq.
12
13
14
17
18
19
20
22
k. The A11-Registration Request message is validated and the PDSN accepts the connection by returning an A11-Registration Reply message with an accept indication. PCF1 stops timer Tregreq.
23
l.
21
24
PCF1 sends an A9-Connect-A8 message after the completion of the A10 connection handoff. The BS
stops timer TA8-setup.
25
m. At this point, the data session is successfully handed off from the HRPD to the cdma2000 system.
26
n. The MS/AT sends a Connect Order message when the call is answered at the MS/AT.
28
o. PDSN Initiates closure of the A10 connection with PCF2 by sending an A11-Registartion Update
message. PDSN starts timer Tregupd. This step may occur direct after step j.
29
p. PCF2 responds with an A11-Registartion Acknowledge message. The PDSN stops timer Tregupd.
27
31
q. PCF2 sends an A11-Registration Request message with Lifetime set to zero, to the PDSN. PCF2
starts timer Tregreq.
32
r.
30
33
The PDSN sends an A11-Registration Reply message to PCF2. PCF2 closes the A10 connection for
the MS/AT and stops timer Tregreq.
36
s. Upon not having received any transmissions from the MS/AT prior to timer Tairdrop expiration, the
AN sends an A9-Release-A8 message to PCF2 and starts timer Trel9. This step can occur any time
after step b.
37
t.
34
35
PCF2 responds to the AN with an A9-Release-A8 Complete message. The AN stops timer Trel9.
38
39
4-8
A.S0007-0 version 2.0 (TIA-878)
HRPD IOS Publication Version
November, 2001
1
2
3
4
5
4.2.2
AT Leaving During an Active 1xEV-DO Data Session
This section describes the call flow associated with an MS/AT leaving the 1xEV-DO session due to a
terminated voice call or other reasons, while the MS/AT has an active packet data session. The scenario
assumes that the AT does not initiate concurrent services prior to the detection of the loss of the HRPD
radio link.
MS/AT
BS
cdma2000
PCF1
AN
HRPD
PCF2
PDSN
time
HRPD Active Data Session
Page
a
MS/AT stops transmitting to the AN
b
x
A9-AL Disconnected
c
A9-AL Disconnected Ack-A8
d
Tald9
e
Page Response
TCH Setup
f
TAirdrop
Alert with Info
g
Connect Order
h
i
A9-Release-A8
A11-Registration Request (Lifetime=0)
Tregreq
Trel9
A11-Registration Reply (Lifetime=0, Accept)
A9-Release-A8 Complete
j
k
l
6
Figure 4.2.2-1 AT Leaving During an Active 1xEV-DO Data Session
7
8
9
10
a. The BS sends a Page Message containing the AT address over the paging channel. The MS/AT may
ignore this Page Message to continue the HRPD session. If the MS/AT ignores the message, following steps are not performed.
12
b. The AN determines that it is not receiving any transmissions from the MS/AT and starts timer
Tairdrop.
13
c. The AN sends an A9-AL Disconnected message to PCF2 to stop data flow and starts timer Tald9.
11
15
d. Upon receipt of the A9-AL Disconnected message, PCF2 sends an A9-AL Disconnected Ack
message to the AN. The AN stops timer Tald9.
16
e. The MS/AT sends a Page Response message to the BS. This step can occur any time after step c.
17
f.
18
g. The BS sends an Alert with Info message to indicate the MS/AT to ring.
19
h. The MS/AT sends a Connect Order message when the call is answered at the MS/AT.
14
The BS establishes a traffic channel upon receipt of the Assignment Request message.
4-9
A.S0007-0 version 2.0 (TIA-878)
HRPD IOS Publication Version
1
i.
When the timer Tairdrop expires, the AN initiates the release of the A8 connection by sending an A9Release-A8 message to PCF2 and starts timer Trel9.
j.
PCF2 sends an A11-Registration Request message with Lifetime set to zero, to the PDSN. PCF2
starts timer Tregreq.
2
3
November, 2001
4
6
k. The PDSN sends an A11-Registration Reply message to PCF2. PCF2 closes the A10 connection for
the MS/AT and stops timer Tregreq.
7
l.
5
PCF2 responds to the AN with an A9-Release-A8 Complete message. The AN stops timer Trel9.
8
9
4-10
A.S0007-0 version 2.0 (TIA-878)
HRPD IOS Publication Version
November, 2001
1
2
3
4
4.2.3
MS/AT Terminated Voice Call During Active HRPD Packet Data Session (Intra-PCF)
This scenario describes the call flow associated with an MS/AT terminated voice call while the MS/AT
has an active HRPD packet data session. The HRPD packet data session is handed off to the cdma2000
system as a concurrent call service if the MS/AT has and selects this capability.
MS/AT
BS
cdma2000
AN
HRPD
PCF
PDSN
time
HRPD Active Data Session
a
Page
MS/AT stops transmitting to the AN
x
b
A9-AL Disconnected
c
A9-AL Disconnected Ack
d
Tald9
e
Page Response
TCH Setup
f
g
Alert with Info
Tairdrop
Origination for
Concurrent Service
h
A9-Setup-A8
i
A9-Connect-A8
j
TA8-setup
k
IS-2000 Active Data Session
l
Connect Order
x
A9-Release-A8
m
A9-Release-A8 Complete
n
Trel9
5
Figure 4.2.3-1 Voice Call Termination During Active HRPD Packet Data Session (Intra-PCF)
6
7
8
9
a. The BS sends a Page Message containing the MS/AT address over the paging channel. The MS/AT
may ignore this Page Message to continue the HRPD session. If the MS/AT ignores the message,
following steps are not performed.
11
b. The AN determines that it is not receiving any transmissions from the MS/AT and starts timer
Tairdrop.
12
c. The AN sends an A9-AL Disconnected message to the PCF to stop data flow and starts timer Tald9.
10
14
d. Upon receipt of the A9-AL Disconnected message, the PCF sends an A9-AL Disconnected Ack to the
AN. The AN stops timer Tald9.
15
e. The MS/AT sends a Page Response message to the BS. This step can occur any time after step c.
16
f.
17
g. The BS sends an Alert with Info message to indicate the MS/AT to ring.
13
The BS establishes a traffic channel.
4-11
A.S0007-0 version 2.0 (TIA-878)
HRPD IOS Publication Version
November, 2001
4
h. The MS/AT and cdma2000 system set up the data session for handoff from HRPD as a concurrent
call service if the MS/AT supports the concurrent call service capability and selects to handoff the
data session from the HRPD to the cdma2000 system. Refer to [11], Section 2.17.2.1 steps (a) to step
(g).
5
i.
The BS sends an A9-Setup-A8 message to the PCF to establish A8 connection and starts timer TA8setup. If the MS/AT has indicated the presence of data ready to send, the BS shall set the Data Ready
Indicator to 1; otherwise, the BS shall set the Ready Indicator to 0.
j.
The PCF sends an A9-Connect-A8 message to the BS. The BS stops timer TA8-setup.
1
2
3
6
7
8
10
k. At this point, the data session is successfully handed off from the HRPD system to the cdma2000
system.
11
l.
9
12
13
14
15
The MS/AT sends a Connect Order message when the call is answered at the MS/AT.
m. Upon not having received any transmissions from the MS/AT prior to timer Tairdrop expiration, the
AN sends an A9-Release-A8 message to the PCF and starts timer Trel9.
n. Upon receipt of the A9-Release-A8 message, the PCF sends an A9-Release-A8 Complete message to
the AN. The AN stops timer Trel9.
16
17
4-12
A.S0007-0 version 2.0 (TIA-878)
HRPD IOS Publication Version
November, 2001
1
2
3
4
5
6
7
8
9
10
11
4.3
cdma2000 to HRPD Active Packet Data Session Handoff
This section describes the call flow associated with an MS/AT AN change from an cdma2000 to a HRPD
system. The MS/AT determines that an AN change from cdma2000 to HRPD is required. In this
scenario, it is assumed that the MS/AT has already established an HRPD session, however it does not
have a connection established.
Handoff of the active cdma2000 packet data session occurs via the dormant state. The transition from
cdma2000 active to dormant occurs according to [10] 2.14.7.3, MS Initiated Call Release to Dormant
State. The dormant handoff from cdma2000 to HRPD occurs according to section 4.1.1 or 4.1.2
(cdma2000 to HRPD Dormant Packet Data Session Handoff - Existing or New HRPD Session) as
appropriate. Finally, the MS/AT transitions from dormant to active on HRPD according to section 3.3.2,
AT Initiated Call Re-activation from Dormant State (Existing HRPD Session).
12
13
4-13
A.S0007-0 version 2.0 (TIA-878)
HRPD IOS Publication Version
1
2
4.4
November, 2001
Status Management Supported by Feature Invocation
This scenario describes the call flow associated with status management using feature invocation.
MS/AT
BS
cdma2000
MSC
Origination
(Feature Code)
HRPD
AN
time
a
Mobile Originating Call Setup
b
MSC Initiated Call Clearing
c
Mobile Initiated HRPD Connection Setup
d
Mobile Initiated HRPD Connection Release
e
Origination
(Feature Code)
f
Mobile Originating Call Setup
g
MSC Initiated Call Clearing
h
3
Figure 4.4-1
4
5
6
7
8
9
10
11
12
Terminal Based Status Management (Using Feature Invocation)
a. The MS/AT sends an Origination Message, including the feature code as the called number, to the BS
when the MS/AT starts the HRPD communication. This feature code indicates that the MSC should
activate a feature (e.g., do not disturb).
b. The BS and the MSC setup the call. From the feature code, the MSC knows not to page the MS/AT
for a voice call. Refer to [11], Section 2.2.2.1, Mobile Origination.
c. The BS and the MSC clear the call. Refer to [11], Section 2.3.5.3, Call Clear Initiated by MSC.
d. The MS/AT starts communication on the HRPD session. Refer to Section 3.3.2, AT Initiated Call
Re-activation from Dormant State (Existing HRPD Session).
15
e. The MS/AT terminates communication on the HRPD session when the HRPD session goes dormant
or inactive. Refer to Section 3.5.2, HRPD Session Release - Initiated by the AT (No Connection
Established).
16
f.
13
14
17
18
The MS/AT sends an Origination Message, including the feature code as the calling number, to the
BS when the MS/AT ends the HRPD communication. This feature code indicates that the MSC
should deactivate the feature activated in step a.
20
g. The BS and the MSC setup the call. From the feature code, the MSC know it may page the MS/AT
for a voice call. Refer to [11], Section 2.2.2.1, Mobile Origination.
21
h. The BS and the MSC clear the call. Refer to [11], Section 2.3.5.3, Call Clear Initiated by MSC.
19
22
4-14
A.S0007-0 version 2.0 (TIA-878)
HRPD IOS Publication Version
November, 2001
1
5
Messages, Information Elements and Timer Definitions
2
5.1
Message Definitions
3
5.1.1
A13 Message Definitions
4
5.1.1.1
5
6
A13-Session Information Request Message
This message is sent from the target AN to the source AN to request session control information for a
particular AT.
Information Element
Section Reference
Element Direction
Type
A13 Message Type
5.2.1.2
Target → Source
UATI 128
5.2.1.3
Target → Source
O
R
Security Layer Packet
5.2.1.4
Target → Source
O
R
Sector ID (target)
5.2.1.5
Target → Source
O
R
M
7
8
The following table shows the bitmap layout for the A13-Session Information Request Message.
7
6
5
⇒
⇒
(MSB)
4
3
2
1
0
Octet
A13 Message Type = [01H]
1
UATI 128: A13 Element Identifier = [01H]
1
Length = [10H]
2
UATI
3
4
###
###
(LSB)
⇒
1
Security Layer Packet: A13 Element Identifier = [02H]
(MSB)
N
Length = [variable]
2
Security Layer Packet
3
4
###
###
(LSB)
⇒
(MSB)
N
1
Sector ID: A13 Element Identifier = [03H]
Length = [10H]
2
Sector ID
3
4
###
###
(LSB)
9
10
5-1
N
A.S0007-0 version 2.0 (TIA-878)
HRPD IOS Publication Version
1
2
3
5.1.1.2
November, 2001
A13-Session Information Confirm Message
This message is sent from the target AN to the source AN to indicate that the target AN has successful
received the session control information for the requested AT.
Information Element
Section Reference
Element Direction
A13 Message Type
5.2.1.2
Target → Source
UATI 128
5.2.1.3
Target → Source
Type
M
O
R
4
5
The following table shows the bitmap layout for the A13-Session Information Confirm Message.
7
6
5
⇒
⇒
4
3
2
1
0
Octet
A13 Message Type = [02H]
1
UATI 128: A13 Element Identifier = [01H]
1
Length = [10H]
2
UATI
3
(MSB)
4
###
###
(LSB)
N
6
7
8
9
5.1.1.3
A13-Session Information Reject Message
This message is sent from the source AN to the target AN to indicate that the request for session control
information has been denied.
Information Element
Section Reference
Element Direction
Type
A13 Message Type
5.2.1.2
Source → Target
UATI 128
5.2.1.3
Source → Target
O
R
Cause
5.2.1.6
Source → Target
O
R
M
10
11
The following table shows the bitmap layout for the A13-Session Information Reject Message.
7
6
5
⇒
⇒
(MSB)
4
3
2
1
0
Octet
A13 Message Type = [03H]
1
UATI 128: A13 Element Identifier = [01H]
1
Length = [10H]
2
UATI
3
4
###
###
(LSB)
-- Continued on next page -12
5-2
N
A.S0007-0 version 2.0 (TIA-878)
HRPD IOS Publication Version
November, 2001
1
-- Continued from previous page -⇒
1
Cause: A13 Element Identifier [04H]
Length = [03H]
2
Cause Value = [ 01H (Protocol Subtype Not Recognized),
02H (Protocol Subtype Attribute(s) Not Recognized)
03H (Protocol Subtype Attribute(s) Missing)
04H (Requested Session Not Found)
05H (Requested Session Not Authentic)]
3
2
3
4
5
5.1.1.4
A13-Session Information Response Message
This message is sent from the source AN to the target AN and includes the requested session control
information.
Information Element
Section Reference
Element Direction
Type
A13 Message Type
5.2.1.2
Source → Target
UATI 128
5.2.1.3
Source → Target
O
R
Mobile Identity (MN ID)
5.2.1.7
Source → Target
O
R
PDSN Address
5.2.1.8
Source → Target
O
R
Access Network Identifiers
5.2.1.9
Source → Target
O
R
Session State Information Record
5.2.1.10
Source → Target
O
R
M
6
7
The following table shows the bitmap layout for the A13-Session Information Response Message.
7
6
5
⇒
⇒
(MSB)
4
3
2
1
0
Octet
A13 Message Type = [04H]
1
UATI 128: A13 Element Identifier = [01H]
1
Length = [10H]
2
UATI
3
4
###
###
(LSB)
-- Continued on next page -8
5-3
N
A.S0007-0 version 2.0 (TIA-878)
HRPD IOS Publication Version
November, 2001
1
-- Continued from previous page -⇒
1
Mobile Identity (MN ID): A13 Element Identifier = [05H]
Length = 14-15 digits
Identity Digit 1 = [0H-9H] (BCD)
Odd/even
Indicator
= [1,0]
2
Type of Identity
= [110] (MN ID)
3
Identity Digit 3 = [0H-9H] (BCD)
Identity Digit 2 = [0H-9H] (BCD)
4
###
###
###
Identity Digit N+1 = [0H-9H] (BCD)
Identity Digit N = [0H-9H] (BCD)
N
= [1111] (if even number of digits)
⇒
(MSB)
Identity Digit N+2 = [0H-9H] (BCD)
n+1
1
PDSN IP Address: A13 Element Identifier [06H]
Length = [04H]
2
PDSN IP Address
3
4
5
(LSB)
⇒
Reserved
(MSB)
Access Network Identifiers: A13 Element Identifier [07H]
2
Length = [05H]
3
SID
4
NID
PZID
(MSB)
5
6
(LSB)
⇒
1
Type = 01H
(LSB)
(MSB)
6
7
8
Session State Information Record: A13 Element Identifier [08H]
1
Length = [variable]
2
Session State Information Record
3
###
###
(LSB)
2
3
5-4
N
A.S0007-0 version 2.0 (TIA-878)
HRPD IOS Publication Version
November, 2001
1
5.2
Information Element Definitions
2
5.2.1
A13 Information Element Definitions
3
5.2.1.1
4
5
6
Information Element Identifiers
The following table lists all the elements that make up the messages defined in Section 5.1. The table
includes the Information Element Identifier (IEI) coding which distinguishes one element from another.
The table also includes a section reference indicating where the element coding can be found.
Element Name
UATI 128
Security Layer Packet
SectorID
Cause
Mobile Identity (MN ID)
PDSN IP Address
Access Network Identifiers
Session State Information Record
Identifier (Hex)
01H
02H
03H
04H
05H
06H
07H
08H
Identifier (Binary)
0000 0001
0000 0010
0000 0011
0000 0100
0000 0101
0000 0110
0000 0111
0000 1000
Reference
5.2.1.3
5.2.1.4
5.2.1.5
5.2.1.6
5.2.1.7
5.2.1.8
5.2.1.9
5.2.1.10
7
5.2.1.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
A13-Session Information Request Message
A13-Session Information Confirm Message
A13-Session Information Reject Message
A13-Session Information Response Message
9
10
5.2.1.3
Section Reference
01H
02H
03H
04H
5.1.1.1
5.1.1.2
5.1.1.3
5.1.1.4
Unicast Access Terminal Identifier (UATI 128).
This element is set to the terminal identifier associated with the AT.
7
(MSB)
6
5
4
3
2
1
0
Octet
A13 Element Identifier = [01H]
1
Length
2
UATI
3
4
###
###
(LSB)
11
Length
This field contains the number of octets in this element following this field as a binary
number.
UATI
This is set to the terminal identifier associated with the AT.
12
13
N
5-5
A.S0007-0 version 2.0 (TIA-878)
HRPD IOS Publication Version
November, 2001
1
5.2.1.4
2
This element is set to the security layer packet received from the AT.
7
Security Layer Packet
6
5
(MSB)
4
3
2
1
0
Octet
A13 Element Identifier = [02H]
1
Length
2
Security Layer Packet
3
4
###
###
(LSB)
3
Length
This field contains the number of octets in this element following this field as a
binary number.
4
5
N
Security Layer Packet This is set to the security layer packet received from the AT.
6
7
5.2.1.5
8
The AN shall set this field to the address of this sector.
7
SectorID
6
5
(MSB)
4
3
2
1
0
Octet
A13 Element Identifier = [03H]
1
Length
2
Sector ID
3
4
###
###
(LSB)
9
10
N
Length
This field shall be set to the length of this element in octets following the Length Field.
Sector ID
This is set to the 128-bit address of the sector.
11
12
5.2.1.6
13
This element is used to indicate the reason for occurrence of a particular event and is coded as follows.
7
(MSB)
14
15
Length
Cause
6
5
4
3
2
1
0
Octet
A13 Element Identifier = [04H]
1
Length
2
Cause Value
(LSB)
3
This field contains the number of octets in this element following this field as a binary
number.
16
17
5-6
A.S0007-0 version 2.0 (TIA-878)
HRPD IOS Publication Version
November, 2001
1
Cause Value
This field is set to the range of values as follows:
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
2
3
5.2.1.7
4
This element is used to provide the access terminal’s Mobile Node Identification (MN ID).
7
Mobile Identity (MN ID)
6
5
4
2
1
0
Octet
A13 Element Identifier = [05H]
1
Length = 14-15 digits
2
Identity Digit 1 = [0H-9H] (BCD)
5
3
Odd/even
Indicator
= [1,0]
Type of Identity
= [110] (MN ID)
3
Identity Digit 3 = [0H-9H] (BCD)
Identity Digit 2 = [0H-9H] (BCD)
4
###
###
###
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
Length
This field contains the number of octets in this element following this field as a binary
number.
6
7
8
5.2.1.8
9
This element is used to provide the PDSN address.
7
PDSN IP Address
6
(MSB)
5
4
3
2
1
0
Octet
A1 Element Identifier = [06H]
1
Length
2
PDSN IP Address
3
4
5
(LSB)
10
Length
This field contains the number of octets in this element following this field as a
binary number.
PDSN IP Address
This field is set to the IPv4 address of a PDSN.
11
12
6
13
5-7
A.S0007-0 version 2.0 (TIA-878)
HRPD IOS Publication Version
1
2
3
4
5.2.1.9
November, 2001
Access Network Identifiers
This element uniquely identifies the PCF an is used by the PDSN to determine if it owns the connection.
If so the PDSN does not need to send agent advertisements. If not, then the PDSN needs to trigger an
MIP Registration Request so that the Foreign Agent/Home Agent tunnel is set up properly.
7
Reserved
6
5
4
3
2
1
0
Octet
A13 Element Identifier = [07H]
1
Type = 01H
2
Length
3
SID
4
(MSB)
(LSB)
(MSB)
NID
5
6
(LSB)
PZID
7
8
5
Type
This field identifies the ANID Sub Type (01H).
6
Length
This field contains the number of octets in this element following this field as a binary
number.
SID
This two octet field is coded to the vale that uniquely identifies the cellular or PCS
system.
NID
This two octet field is coded to the vale that uniquely identifies the network within a
cellular or PCS system.
PZID
This one octet field is coded to the vale that uniquely identifies the Packet Control
Function (PCF) coverage Area within a particular SID/NID area. The combined
SID/NID/PZID triplet is unique to a PCF.
7
8
9
10
11
12
13
14
15
16
5.2.1.10
17
This element is used to send HRPD Session Information as specified in [10].
7
(MSB)
Session State Information Record
6
5
4
3
2
1
0
A13 Element Identifier = [08H]
1
Length
2
Session State Information Record
3
###
###
(LSB)
18
21
N
Length
This field contains the number of octets in this element following
this field as a binary number.
Session State Information Record
This field contains the air interface protocol attributes and associated public data. The format is as specified in [10].
19
20
Octet
22
23
24
5-8
A.S0007-0 version 2.0 (TIA-878)
HRPD IOS Publication Version
November, 2001
1
5.3
Timer Definitions
2
This section describes the timers associated with the HRPD IOS specification.
Timer
Name
Default
Value
(seconds)
Range of
Values
(seconds)
Granularity
(seconds)
Section
Reference
Classification
Tairdrop
TA13req
5
1
0.1 – 60.0
0.1 - 60.0
0.1
0.1
5.3.1.1
5.3.1.2
Call Processing
A13 interface
Tnet conn
5
0.1 - 60.0
0.1
5.3.1.3
A9 interface
3
4
5.3.1
5
5.3.1.1
6
7
8
Timer Descriptions
Timer Tairdrop
This AN timer indicates when a HRPD connection has been lost. The timer is started by the AN when it
determines that it is not receiving any transmissions from the MS/AT and stopped when the AN resumes
receiving transmissions from the MS/AT or upon receipt of the A9-Disconnect-A8 message.
9
10
11
12
13
5.3.1.2
Timer TA13req
This AN timer is started when the target AN sends an A13-Session Information Request message to the
source AN and is stopped when the A13-Session Information Response message or A13-Session Information Reject message is received.
14
15
16
17
5.3.1.3
Timer Tairdrop
This PCF timer is started when the PCF receives the A9-BS Service Response message from the AN and
is stopped when the A9-Setup-A8 message is received from the AN.
18
19
5-9
A.S0007-0 version 2.0 (TIA-878)
HRPD IOS Publication Version
1
November, 2001
No text.
2
5-10
A.S0007-0 version 2.0 (TIA-878)
HRPD IOS Publication Version
November, 2001
1
Annex A
2
A.1
3
4
5
6
7
8
9
Future Phases of HRPD IOS - Informative Annex
HRPD IOS Phase 2 Architecture Reference Model Working Assumptions
TSG-A consensus was reached that the desired AN/PCF restructuring cannot be completed on the agreed
schedule for the Phase 1 IOS. Refer to Section 1.2 for the Phase 1 Architecture Reference Model. The
requested restructuring is shown in Figure A.1-1. Note that a portion of the AN functionality (e.g.,
session control and mobility) is to evolve from the AN into a new PCF entity (which also includes the
current PCF functionality). Some proposals also suggest further restructuring of the AN and PCF
functions, but no consensus was reached, and these are to be discussed after the Phase 1 IOS development
is completed.
Phase 2
A8'
Access Terminal
(AT)
A10
Access Network
(AN')
PCF'
A9'
PDSN
A11
Session
Control
A12
Aa'
Ab'
A13'
Proxy
AN AAA
A8'
Access Terminal
(AT)
AN AAA
A10
Access Network
(AN')
PCF'
A9'
PDSN
A11
Session
Control
A12
Proxy
AN AAA
AN AAA
10
Figure A.1-1
11
HRPD IOS Phase 2 Architecture Reference Model Working Assumptions
12
13
Items identified for future study include:
14
•
Determination of the architectural entity in which the location of session control exists.
15
•
Enhancements to status management, using the network.
16
17
A-1
A.S0007-0 version 2.0 (TIA-878)
HRPD IOS Publication Version
1
November, 2001
No text.
2
A-2
A.S0007-0 version 2.0 (TIA-878)
HRPD IOS Publication Version
November, 2001
1
Annex B
2
2.14
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
A8-A9 (AN - PCF) Interface Change Text
Packet Data Calls
Data services are grouped into two categories: circuit-oriented (includes Asynchronous Data and Group-3
Fax services) and packet. Procedures applicable to packet data calls are described in this section. See
Section 6.2.2.66 for valid service options. Note some service options are only valid for Intergeneration
Handoff (handoff between systems supporting packet data services based on ANSI/TIA/EIA/IS-95-B and
systems supporting packet data service based on TIA/EIA/IS-2000). Intergeneration Handoffs are described in Annex D.
Note: When the procedures between TIA/EIA/IS-95-B or cdma2000 and HRPD systems differ, the
HRPD procedures are identified separately within this specification. When the IOS text is applied to the
HRPD RAN specification, the procedures related to the MSC shall be ignored. Hard Handoff procedures
are not applicable to HRPD.
For all calls supporting packet data services, a Packet Data Serving Node (PDSN) exists that interfaces
between the transmission of the data in the fixed network and the transmission of the data over the air
interface. The PDSN interfaces to the BS through a Packet Control Function (PCF), which may or may
not be co-located with the BS.
For purposes of the protocol of this standard, there are three packet data service states: Active/Connected,
Dormant, and Null/Inactive. In the Active/Connected State, a physical traffic channel exists between the
mobile station and the base station, and either side may send data. In the Dormant State, no physical
traffic channel exists between the mobile station and the base station, but the PPP link between the mobile
station and the PDSN is maintained. In the Null/Inactive State, there is no traffic channel between the
mobile station and the base station and no PPP link between the mobile station and the PDSN.
Active /
Connected
State
Dormant State
Null / Inactive
State
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
Figure 2.14-1 - Packet Data Service State Transitions
In cdma2000 systems, A1 and A8 connections are maintained during the Active / Connected State and released during transition to Dormant or Null/Inactive State. The A10 connection is maintained during the
Active/Connected and the Dormant State.
In HRPD systems, the A8 connection is maintained during the Active/Connected State and released during transition to Dormant or Null/Inactive State. The A10 connection is maintained during the Active/
Connected and the Dormant State.
As part of the support for the Dormant State, the TIA/EIA/IS-2000 air interface supports a Data Ready to
Send indicator that is used on Origination. When a mobile terminal sends an origination request with a
packet data service option specified, it will include the Data Ready to Send (DRS) bit. This indicator will
be set to 1 on initial call setup and when the terminal wishes to transition from Dormant to Active because
it has data to send and is requesting the establishment of a traffic channel. The DRS bit will be set to 0 to
indicate that the terminal has transitioned a Packet Zone boundary while dormant, and is sending the
origination request to update the network as to its current location.
B-1
A.S0007-0 version 2.0 (TIA-878)
HRPD IOS Publication Version
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
November, 2001
In HRPD systems when data is ready to be sent, connection establishment procedures are used on initial
call setup to transition from Dormant to Active for the purposes of requesting the establishment of a
traffic channel. UATI assignment procedures are employed when the terminal detects a change of subnet
while dormant, to update the network as to its current location.
On receipt of an origination with the DRS bit set to 1 or for connection establishment procedures in an
HRPD system, the BS will initiate the call setup procedure as shown in Section 2.14.7.1, which will
normally result in the establishment of a traffic channel and in the A8 and A10 bearer connections being
established.
When the BS receives an origination with the DRS bit set to 0 or when UATI assignment procedures are
employed in an HRPD system, the BS will delay the establishment of a traffic channel until after the A8
and A10 bearer connection establishment procedures are complete. During the A8 bearer connection
establishment procedure, the BS will indicate to the PCF that a DRS=0 has been received (or there is no
indication of data ready to be exchanged, for HRPD systems) through the use of the Data Ready Indicator
element in the A9-Setup-A8 message. If the PCF has data from the network to deliver to the terminal, it
will indicate this by setting the Cause element in the A9-Connect-A8 message to the Data Ready to Send
value. The BS will then establish a traffic channel to the terminal and complete a normal call setup procedure as in Section 2.14.7.1. For HRPD systems, the AN initiates connection establishment procedures
to setup a traffic channel with the AT.
23
If the PCF does not have data, it indicates that the A8 is not being established by sending the A9-ReleaseA8 Complete message to the BS. The BS will then return an Assignment Failure message to the MSC
with the cause value set to Packet call going dormant. Upon receipt of the Assignment Failure message,
the MSC returns a Clear Command to the BS with the Cause value set to Do Not Notify Mobile. The BS
sends a Clear Complete message to the MSC upon receipt of the Clear Command message.
24
2.14.1 Packet Data Assumptions
25
No changes from TIA/EIA/IS-2001-A text.
26
2.14.2 Previous and Current Access Network Identifiers (PANID/CANID)
19
20
21
22
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
The selected PDSN needs to know whether a mobile is being handed off by a PCF that was not previously
using this PDSN for the connection, in order to determine if PPP reconfiguration and Mobile IP
registration are required. The information used to make this determination consists of the PZID, SID or
NID (PZID), System ID (SID) and Network ID (NID) values, which are also referred to as the Access
Network Identifiers. The PCF is uniquely identified by the Current Access Network Identifiers (CANID)
and every PCF knows its CANID value. Anytime a mobile crosses into a new region, where the region is
defined by the Access Network Identifiers, it must re-register with that Access Network.
On detection of a new PZID, SID or NID, the Mobile Station sends an Origination Message or Enhanced
Origination message to the target BS. In an HRPD system the change of AN is indicated by the Location
Update procedures as defined in TIA/EIA/IS-856. The target BS forwards the received PZID, SID and
NID information to the PCF as the Previous Access Network Identifiers (PANID). The AN may also
retrieve the PZID, SID and NID from the AT in an HRPD system by using the Location Update Procedures in TIA/EIA/IS-856 when the AN detects a Dormant handoff between ANs. In the case of hard
handoff, the source BS includes the Previous Access Network Identifiers (PANID) in the Handoff
Required message to the MSC. The MSC forwards this information to the target BS in the Handoff
Request message, which in turn sends the received PANID to the PCF. The PCF includes the PANID
received from the target BS, along with the its own Current Access Node Identifiers (CANID) to the
PDSN as part of the A11-Registration Request message. The PDSN maintains the CANID which is
serving each connection and compares this against the PANID, received in the A11 Registration Request,
to determine if it currently owns the call. If the PDSN owns the call, it does not need to initiate or send
agent advertisements. If the PDSN does not own the call, then the PDSN needs to trigger PPP renegotiation followed by the sending of agent advertisement messages so that a new Foreign Agent / Home
Agent (HA) tunnel to the mobile can be setup properly. Upon a successful A11 registration, the PDSN
B-2
A.S0007-0 version 2.0 (TIA-878)
HRPD IOS Publication Version
November, 2001
1
2
updates its stored CANID with the input CANID value received in the A11-Registration Request message
(so it is up-to-date with the currently active PCF).
5
For first time originations the Mobile Station does not send the PANID and the PCF sends only its
CANID. If the PDSN does not receive the PANID, it performs an agent advertisement and forces the
mobile to re-register with the Home Agent.
6
2.14.3
7
No changes from TIA/EIA/IS-2001-A text.
8
2.14.4 A8/A9 Interface Procedures
9
No changes from TIA/EIA/IS-2001-A text.
3
4
PDSN Selection Algorithm
10
2.14.4.1
11
No changes from TIA/EIA/IS-2001-A text.
12
2.14.4.1.1
13
No changes from TIA/EIA/IS-2001-A text.
14
2.14.4.1.1.1
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
A8/A9 Interface Setup Procedures And Messages
A9-Setup-A8
Successful Operation
When the BSC receives an Assignment Request from the MSC, as a result of sending a CM Service
Request (in response to an Origination message from the mobile with a Service Option that requests
packet data service and with the DRS bit set to 1), or as a result of sending a Page Response, or when
connection establishment procedures are employed in an HRPD system, it initiates the procedure for
establishing radio traffic channels. After establishing traffic channels, the BSC determines the
characteristics for an A8 connection such as QoS and generates an A9-Setup-A8 message indicating the
normal call setup (i.e., the handoff indicator field of the A9-Setup-A8 message is set to ‘0’). The BSC
sends the message to the PCF on the A9 interface and starts timer TA8-setup. Upon receiving the message,
the PCF initiates the procedure for establishing an A10 connection. In an HRPD system, the PCF stops
timer Tnet_conn.
After establishing an A10 connection, the PCF sends an A9-Connect-A8 message to the BSC. For the
case where the DRS bit received from the mobile is set to 0 or a request for a traffic channel is not
received in the HRPD system, the BSC will await the response from the PCF to determine if a traffic
channel needs to be established.
When the mobile station performs a hard handoff during packet services, the target BSC sends the A9Setup-A8 message upon receipt of the Handoff Request message from the MSC and starts timer TA8-setup.
In this case, the BSC sets the Handoff Indicator field of the A9-Setup-A8 message to ‘1’ and Data Ready
Indicator is set to ‘1’.
In the case of dormant handoff the BSC sends the A9-Setup-A8 message to the PCF upon receipt of the
Assignment Request message from the MSC or upon completion of the UATI assignment procedures in
HRPD systems. For this case, it will set both the Data Ready Indicator and the Handoff Indicator to 0.
Please refer to section 6.1.10.1, “A9-Setup-A8,” for the format and content of this message.
Alternatively, if upon receipt of the A9-Setup-A8 message, if the PDSN has no data to send to the MS (in
the case of a dormant handoff) or if the PCF could not setup the A8 connection due to PDSN resources
being unavailable, the PCF will send the A9-Release-A8 Complete message. Upon receipt of this
message, the BSC stops timer TA8-setup.
If the A9-Setup-A8 message contains a DRI set to '0' and the PCF does not have data to send, the PCF rejects the attempt to setup the A8 connection by sending an A9-Release-A8 Complete message to the BSC.
B-3
A.S0007-0 version 2.0 (TIA-878)
HRPD IOS Publication Version
1
2.14.4.1.1.2
November, 2001
Failure Operation
8
If the BSC fails to receive an A9-Connect-A8, that is to say, the timer TA8-setup has expired before receiving an A9-Connect-A8 or A9-Release-A8 Complete message, the BSC sends an Assignment Failure
message or a Handoff Failure message, as appropriate, to the MSC. If the A10/A11 connection establishment procedure is required but fails, the PCF should send an A9-Release-A8 Complete message with
cause value set to “PDSN resources not available (0x79)". In an HRPD system, if the AN fails to receive
an A9-Connect-A8 message or an A9-Release-A8 message, the AN may re-send the A9-Setup-A8
message or release the traffic channel if it exists.
9
2.14.4.1.2
2
3
4
5
6
7
A9-Connect-A8
10
No changes from TIA/EIA/IS-2001-A text.
11
2.14.4.1.2.1
12
No changes from TIA/EIA/IS-2001-A text.
13
2.14.4.1.2.2
14
No changes from TIA/EIA/IS-2001-A text.
15
2.14.4.1.3
16
No changes from TIA/EIA/IS-2001-A text.
17
2.14.4.1.3.1
18
No changes from TIA/EIA/IS-2001-A text.
19
2.14.4.1.3.2
20
No changes from TIA/EIA/IS-2001-A text.
21
2.14.4.1.4
22
No changes from TIA/EIA/IS-2001-A text.
23
2.14.4.1.4.1
24
25
Successful Operation
Failure Operation
A9-BS Service Request
Successful Operation
Failure Operation
A9-BS Service Response
Successful Operation
The BSC shall send an A9-BS Service Response message to the PCF originating the A9-BS Service Request message. Upon receiving the A9-BS Service Response Message, the PCF stops timer Tbsreq9.
28
In an HRPD system, the PCF also starts timer Tnet_conn and waits for an A9-Setup-A8 message. If timer
Tnet_conn expires prior to receiving the A9-Setup-A8 message, the PCF may resend the A9-BS Service
Request message.
29
Please refer to section 6.1.10.7, “A9-BS Service Response,” for the format and content of this message.
30
2.14.4.1.4.2
31
No changes from TIA/EIA/IS-2001-A text.
32
2.14.5 A8/A9 Interface Clearing Procedures and Messages
33
No changes from TIA/EIA/IS-2001-A text.
34
2.14.5.1
35
An A8 connection clearing occurs:
26
27
Failure Operation
Successful Clearing Scenarios
B-4
A.S0007-0 version 2.0 (TIA-878)
HRPD IOS Publication Version
November, 2001
1
•
when a packet data inactivity timer in the BSC expires. The BSC, after sending the Clear Request
message, sets timer T300 and waits for a Clear Command message from the MSC. To release all
allocated resources, the MSC shall send a Clear Command message to the BSC, start timer T315, and
wait for the Clear Complete message from the BSC. After stopping timer T300 and releasing the air
resources, the BSC sends an A9-Release-A8 message to the PCF and starts timer Trel9. The PCF
responds with an A9-Release-A8 Complete message. Then the BSC sends a Clear Complete message
and stops timer Trel9. The cdma2000 system call flow scenario is illustrated in section 2.14.7.2, BS
Initiated Call Release to Dormant State. The HRPD system call flow scenario is illustrated in TIA878 section 3.4.2, Connection Release on HRPD Network - Initiated by the AN.
•
when the packet data inactivity timer in the MS expires. When the BS receives a Release Order or
connection release procedures for HRPD systems, requesting the transition to dormant, the BSC shall
send a Clear Request message to the MSC. The rest of the procedure is same as the BSC initiated
scenario. The cdma2000 system call flow scenario is illustrated in section 2.14.7.3, MS Initiated Call
Release to Dormant State. The HRPD system call flow scenario is illustrated in TIA-878 section
3.4.1, Connection Release on HRPD Network - Initiated by the AT.
•
when the MS releases the call or to indicate to the BSC that an A8 connection will not be established
due to either PDSN resources being unavailable or during dormant handoff if the PDSN has no data
to send. When the BSC receives a Release Order or connection release procedures for HRPD
systems, the BSC shall send a Clear Request message to the MSC and start timer T300. To release all
allocated resources, the MSC shall send a Clear Command message to the BSC, start timer T315, and
wait for the Clear Complete message from the BSC. After stopping timer T300 and releasing the air
resources with the Release Order or connection release procedures for HRPD systems, the BSC sends
an A9-Release-A8 message to the PCF and starts timer Trel9. The PCF responds with an A9-ReleaseA8 Complete message. Then the BSC sends a Clear Complete message and stops timer Trel9. The
cdma2000 system call flow scenario is illustrated in section 2.14.7.4, MS Power Down. The HRPD
system call flow scenario is illustrated in TIA-878 section 3.4.1, Connection Release on HRPD
Network - Initiated by the AT.
•
when the A10/A11 connection is released by the PDSN. When the PCF detects that the A10/A11
connection is released, the PCF sends an A9-Disconnect-A8 message to the BSC and starts timer
Tdiscon9. Then the BSC initiates the release of the A8 connection by sending an A9-Release-A8
message and starts timer Trel9. The PCF responds with an A9-Release-A8 Complete message and
stops timer Tdiscon9. The BSC, after sending the Clear Request message and stopping timer Trel9, sets
timer T300 and waits for a Clear Command message from the MSC. To release all allocated
resources, the MSC shall send a Clear Command message to the BSC, start timer T315, and wait for
the Clear Complete message from the BSC. Then the BSC stops timer T300, releases the air
resources, and responds with a Clear Complete message. The cdma2000 system call flow scenario is
illustrated in section 2.14.7.5, PDSN Initiated Service Release. The HRPD system call flow scenario
is illustrated in TIA-878 section 3.5.5, Packet Data Session Release - Initiated by the PDSN.
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
2.14.5.2
Unsuccessful A8 Interface Clearing Procedures
40
No changes from TIA/EIA/IS-2001-A text.
41
2.14.5.3
42
No changes from TIA/EIA/IS-2001-A text.
43
2.14.5.3.1
44
No changes from TIA/EIA/IS-2001-A text.
45
2.14.5.3.2
A9-Release-A8
Successful Operation
Failure Operation
B-5
A.S0007-0 version 2.0 (TIA-878)
HRPD IOS Publication Version
1
No changes from TIA/EIA/IS-2001-A text.
2
2.14.5.4
3
No changes from TIA/EIA/IS-2001-A text.
4
2.14.5.4.1
5
No changes from TIA/EIA/IS-2001-A text.
6
2.14.5.4.2
7
No changes from TIA/EIA/IS-2001-A text.
8
2.14.5.5
9
No changes from TIA/EIA/IS-2001-A text.
10
2.14.5.5.1
November, 2001
A9-Release-A8 Complete
Successful Operation
Failure Operation
A9-Disconnect-A8
Successful Operation
12
When the PCF needs to release an A8 connection, it sends an A9-Disconnect-A8 message to the BSC.
The PCF starts timer Tdiscon9. In the HRPD system, timer Tairdrop is stopped, if it has been started.
13
Please refer to section 6.1.10.3, “A9-Disconnect-A8,” for the format and content of this message.
14
2.14.5.5.2
15
No changes from TIA/EIA/IS-2001-A text.
16
2.14.5.6
11
17
18
19
20
21
Failure Operation
A9-Update-A8
This A9 interface message is sent from the BSC to the PCF and is used in several cases. First, it is used
to convey accounting information to the PCF if the A8 connection is established before traffic channel
establishment (in which case the PCF will resume data transmission on the A8 connection only after it
receives the A9-update-A8 message) or during an active session following accounting parameters changes
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 access authentication failure at the
MSC or at the AN-AAA for HRPD systems, following an access attempt by a mobile undergoing
dormant handoff. The BSC can also use this message to inform the PCF that a dormant mobile has
powered down. In these two cases, the PCF initiates the release of the A10 connection associated with
the mobile. This A9 message may also be used to indicate to the PCF a successful Short Data Burst
delivery.
28
2.14.5.6.1
29
No changes from TIA/EIA/IS-2001-A text.
30
2.14.5.6.2
31
No changes from TIA/EIA/IS-2001-A text.
32
2.14.5.7
33
No changes from TIA/EIA/IS-2001-A text.
34
2.14.5.7.1
35
No changes from TIA/EIA/IS-2001-A text.
36
2.14.5.7.2
22
23
24
25
26
Successful operation
Failure operation
A9-Update-A8 Ack
Successful operation
Failure operation
B-6
A.S0007-0 version 2.0 (TIA-878)
HRPD IOS Publication Version
November, 2001
1
No changes from TIA/EIA/IS-2001-A text.
2
2.14.6
3
No changes from TIA/EIA/IS-2001-A text.
4
2.14.6.1
5
6
7
8
9
10
11
A8/A9 Interface Handoff Procedures and Messages
A9-Air Link (AL) Connected
In cdma2000 systems, Aafter the mobile station performs (inter-BS) hard handoff, the A9-AL Connected
message is sent from the target BS managing the active air link to the target PCF. This message is
employed in order to notify the target PCF that handoff is successfully completed and that the air link has
been established and that the PCF can send packets on the new A8 connection. An A9-AL Connected Ack
message is expected in response in a successful situation. If the target PCF was not able to establish an
A10 connection with a selected PDSN, it will send back an A9-disconnect-A8 to the BSC to release the
A8 connection.
16
In HRPD systems, the A9-AL Connected message is sent from the AN managing the active air link to the
PCF when it detects the establishment of an air link for the MS/AT for which it sent an A9-AL
Disconnected message and for which timer Tairdrop has not expired . This message is employed in order
to notify the PCF that it can send packets on the A8 connection. An A9-AL Connected Ack message is
expected in response to this message.
17
2.14.6.1.1
12
13
14
15
18
19
20
21
22
23
24
25
Successful Operation
In cdma2000 systems, Aafter the mobile station performs (inter-BS) hard handoff including the case of
return on failure, the (target) BSC managing the active air link sends the A9-AL Connected message to
the (target) PCF and starts timer Talc9.
Upon the receipt of the A9-AL Connected message, the PCF updates its routing table to route packet data
sent from the PDSN to the (target) BSC managing the active air link. The PCF performs A10/A11
connection establishment if the A10/A11 connection has not been established yet. If the PCF is unable to
establish the new A10/A11 connection, it will send an A9-Disconnect-A8 message to the BSC. Upon
receipt of this message, the BSC will begin call tear-down.
30
In HRPD systems, after the AN detects the establishment of an air link for the MS/AT for which it sent an
A9-AL Disconnected message and for which timer Tairdrop has not expired, it sends the A9-AL
Connected message to the PCF and starts timer Talc9. Upon the receipt of the A9-AL Connected message,
the PCF updates its routing table to route packet data sent from the PDSN to the AN managing the active
air link.
31
Please refer to section 6.1.10.8, “A9-AL Connected”, for the format and content of this message.
32
2.14.6.1.2
33
No changes from TIA/EIA/IS-2001-A text.
34
2.14.6.2
35
No changes from TIA/EIA/IS-2001-A text.
36
2.14.6.2.1
37
No changes from TIA/EIA/IS-2001-A text.
38
2.14.6.2.2
39
No changes from TIA/EIA/IS-2001-A text.
40
2.14.6.3
26
27
28
29
Failure Operation
A9-Air Link (AL) Connected Ack
Successful Operation
Failure Operation
A9-Air Link (AL) Disconnected
B-7
A.S0007-0 version 2.0 (TIA-878)
HRPD IOS Publication Version
November, 2001
4
When the mobile station performs hard handoff or the AN detects a loss of the air link in an HRPD
system, the A9-AL Disconnected message is sent from the source BSC to the source PCF. This message
is employed in order to notify the source PCF that the air link is temporarily disconnected. An A9-AL
Disconnected Ack message is expected in response.
5
2.14.6.3.1
1
2
3
6
7
8
9
10
11
Successful Operation
When the source BSC receives the Handoff Command message which instructs it to perform hard handoff
or when the AN detects a loss of the air link in the HRPD system, the source BSC shall send an A9-AL
Disconnected message to the PCF and start timer Tald9. Additionally, in an HRPD system the AN also
starts timer Tairdrop.
If timer Tairdrop expires in an HRPD system, an A9-Release-A8 shall be sent from the AN to the PCF to
release the A8 connection.
13
Upon receipt of an A9-AL Disconnected message from the source BSC, the PCF shall 1stop transmitting
packet data and start buffering packets from the PDSN.
14
Please refer to section 6.1.10.10, “A9-AL Disconnected,” for the format and content of this message.
15
2.14.6.3.2
12
Failure Operation
17
If timer Tald9 expires, the message may be resent. If timer Tairdrop expires in an HRPD system, an A9Release-A8 shall be sent from the AN to the PCF to release the A8 connection.
18
2.14.6.4
19
No changes from TIA/EIA/IS-2001-A text.
20
2.14.6.4.1
21
No changes from TIA/EIA/IS-2001-A text.
22
2.14.6.4.2
23
No changes from TIA/EIA/IS-2001-A text.
16
A9-Air Link (AL) Disconnected Ack
Successful Operation
Failure Operation
24
25
26
B-8
A.S0007-0 version 2.0 (TIA-878)
HRPD IOS Publication Version
November, 2001
1
6.1.10
A9 Interface Message Formats
2
6.1.10.1
A9-Setup-A8
3
4
This A9 interface message is sent from the BS to the PCF to request the establishment of an A8
connection.
Information Element
5
6
7
8
Section
Reference
Element Direction
Type
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
a. If this element is included in this message, its value shall be returned in the corresponding element in
the A9-Connect A8 message sent in response to this message.
b. This second occurrence of the Mobile Identity element, if included, shall contain the ESN of the MS.
Use of the ESN in this message is a network operator decision.
11
c. This information element is included if information is available at the BS. In this version of this
standard, this element is used to carry the current non-assured mode priority of the packet data
session. This information element shall not be included in HRPD messages.
12
d. The Access Node Identifiers (PANID) are included if received from the MS.
9
10
14
e. This information element may be omitted if the BS does not possess this information at the time the
message if created. This information element shall not be included in HRPD messages.
15
f.
13
16
17
The User Zone ID is included if received from the MS.
g. This information element shall be set to the MN ID, associated with the A10 connection, in HRPD
messages.
19
h. The IS-2000 CON_REF field of this information element shall be set to 00H for padding, in HRPD
messages.
20
i.
18
This information element shall not be included in HRPD messages.
21
22
B-9
A.S0007-0 version 2.0 (TIA-878)
HRPD IOS Publication Version
1
November, 2001
The following table shows the bitmap layout for the A9-Setup-A8 message:
7
6
5
4
⇒
⇒
3
2
1
0
1
A9 Message Type = [01H]
Call Connection Reference:
1
A1 Element Identifier = [3FH]
Length = [08H]
(MSB)
2
Market ID = <any value>
3
(LSB)
(MSB)
Octet
Generating Entity ID = <any value>
4
5
(LSB)
(MSB)
6
7
Call Connection Reference = <any value>
8
9
(LSB)
⇒
10
1
Correlation ID: A3/A7 Element Identifier = [13H]
Length = [04H]
2
(MSB)
3
Correlation Value = <any value>
4
5
(LSB)
⇒
1
Mobile Identity (IMSI): A1 Element Identifier = [0DH]
Length = [06H-08H] (10-15 digits)
Identity Digit 1 = [0H-9H] (BCD)
Odd/even
Indicator
= [1,0]
Identity Digit 3 = [0H-9H] (BCD)
6
2
Type of Identity
= [110] (IMSI)
3
Identity Digit 2 = [0H-9H] (BCD)
###
4
###
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
⇒
1
Mobile Identity (ESN): A1 Element Identifier = [0DH]
Length = [05H]
Identity Digit 1 = [0000]
Odd/even
Indicator
= [0]
2
Type of Identity
= [101] (ESN)
3
(MSB)
4
ESN = <any value>
5
6
(LSB)
-- Continued on next page -2
B-10
7
A.S0007-0 version 2.0 (TIA-878)
HRPD IOS Publication Version
November, 2001
1
-- Continued from previous page -⇒
⇒
CON_REF:
1
A9 Element Identifier = [01H]
Length = [01H]
2
IS-2000 CON_REF = [00H – FFH]
3
Quality of Service Parameters:
1
A9 Element Identifier = [07H]
Length = [01H]
Reserved = [0000]
⇒
2
Non-Assured Mode Packet Priority =
[0000 – 1101]
A9 BSC_ID:
1
A9 Element Identifier = [06H]
Length = [01H – 06H]
(MSB)
2
BSC Identifier = <any value>
3
###
###
(LSB)
⇒
(MSB)
A8 Traffic ID:
3
m
1
A9 Element Identifier = [08H]
Length = [0CH]
2
A8 transport protocol stack = [01H] (GRE/IP)
3
Protocol Type = [88 81H] (Unstructured byte stream)
4
(LSB)
(MSB)
5
6
Key = <any value>
7
8
(LSB)
Address Type = [01H] (IPv4)
9
10
(MSB)
11
IP Address = <any value>
12
13
(LSB)
⇒
(MSB)
1
Service Option: A1 Element Identifier = [03H]
Service Option
2
= [ 00 21H 3B H (3G High Speed Packet Data)
(High Rate Packet Data) ]
⇒
(LSB)
Length = [01H]
2
Data
Ready
Indicator
= [0,1]
-- Continued on next page -2
B-11
3
1
A9 Indicators: A9 Element Identifier = [05H]
Reserved = [0000 000]
14
Handoff
indicator
= [0, 1]
3
A.S0007-0 version 2.0 (TIA-878)
HRPD IOS Publication Version
November, 2001
1
-- Continued from previous page -⇒
User Zone ID:
1
A1 Element Identifier = [02H]
Length = [02H]
(MSB)
2
UZID = <any value>
3
(LSB)
⇒
IS-2000 Service Configuration Record:
A1 Element Identifier = [0EH]
Bit-Exact Length – Octet Count = <variable>
Reserved
= [ 0000 0 ]
Bit-Exact Length – Fill Bits
= [ 000 – 111 ]
3
4
IS-2000 Service Configuration Record Content = <any value>
Seventh
Fill Bit –
if needed
= [0 (if
used as a
fill bit)]
⇒
Sixth Fill
Bit – if
needed
= [0 (if
used as a
fill bit)]
Fifth Fill
Bit – if
needed
= [0 (if
used as a
fill bit)]
Access Network Identifiers:
Fourth
Fill Bit –
if needed
= [0 (if
used as a
fill bit)]
Third
Fill Bit –
if needed
= [0 (if
used as a
fill bit)]
Second
Fill Bit –
if needed
= [0 (if
used as a
fill bit)]
. . .
First Fill
Bit – if
needed
= [0 (if
used as a
fill bit)]
(MSB)
k
1
A1 Element Identifier = [20H]
Length = [05H]
2
SID = <any value>
3
(LSB)
(MSB)
1
2
(MSB)
Reserve
d = [0]
4
NID = <any value>
5
(LSB)
PZID = <any value>
2
3
B-12
4
6
7
A.S0007-0 version 2.0 (TIA-878)
HRPD IOS Publication Version
November, 2001
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.
Information Element
3
4
5
6
7
8
9
10
11
12
13
14
Section
Reference
Element Direction
Type
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
a. This element shall only be included if it was also included in the A9-Setup-A8 message. This
element shall be set to the value received in that message.
b. This second occurrence of the Mobile Identity element, if included, shall contain the ESN of the MS.
Use of the ESN in this message is a network operator decision. This information element shall not be
included in HRPD messages.
c. Allowable cause values are: “PCF resources not available”; “Equipment failure”; “Successful operation”, “PDSN resources are not available”, “Data ready to send”.
d.The PCF transmits its Access Network Identifiers (CANID) to the Base Station.
d. This information element shall be set to the MN ID, associated with the A10 connection, in HRPD
messages.
e. The IS-2000 CON_REF field of this information element shall be set to 00H for padding, in HRPD
messages.
15
16
B-13
A.S0007-0 version 2.0 (TIA-878)
HRPD IOS Publication Version
1
November, 2001
The following table shows the bitmap layout for the A9-Connect-A8 message:
7
6
5
4
⇒
⇒
3
2
1
0
1
A9 Message Type = [02H]
Call Connection Reference:
1
A1 Element Identifier = [3FH]
Length = [08H]
(MSB)
2
Market ID = <any value>
3
(LSB)
(MSB)
Octet
Generating Entity ID = <any value>
4
5
(LSB)
(MSB)
6
7
Call Connection Reference = <any value>
8
9
(LSB)
⇒
10
1
Correlation ID: A3/A7 Element Identifier = [13H]
Length = [04H]
2
(MSB)
3
Correlation Value = <any value>
4
5
(LSB)
⇒
1
Mobile Identity (IMSI): A1 Element Identifier = [0DH]
Length = [06H-08H] (10-15 digits)
Identity Digit 1 = [0H-9H] (BCD)
Odd/even
Indicator
= [1,0]
Identity Digit 3 = [0H-9H] (BCD)
6
2
Type of Identity
= [110] (IMSI)
3
Identity Digit 2 = [0H-9H] (BCD)
###
4
###
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
⇒
1
Mobile Identity (ESN): A1 Element Identifier = [0DH]
Length = [05H]
Identity Digit 1 = [0000]
Odd/even
Indicator
= [0]
2
Type of Identity
= [101] (ESN)
3
(MSB)
4
ESN = <any value>
5
6
(LSB)
-- Continued on next page -2
B-14
7
A.S0007-0 version 2.0 (TIA-878)
HRPD IOS Publication Version
November, 2001
1
-- Continued from previous page -⇒
⇒
(MSB)
CON_REF:
1
A9 Element Identifier = [01H]
Length = [01H]
2
IS-2000 CON_REF = [00H – FFH]
3
A8 Traffic ID:
1
A9 Element Identifier = [08H]
Length = [0CH]
2
A8 transport protocol stack = [01H] (GRE/IP)
3
Protocol Type = [88 81H] (Unstructured byte stream)
4
(LSB)
(MSB)
5
6
Key = <any value>
7
8
(LSB)
Address Type = [01H] (IPv4)
9
10
(MSB)
11
IP Address = <any value>
12
13
(LSB)
⇒
1
Cause: A9 Element Identifier = [04H]
Length = [01H]
ext = [0]
2
3
Cause Value =
[13H (Successful operation),
20H (Equipment failure),
32H (PCF resources not available),
79H (PDSN resources are not available),
7AH (Data Ready to Send) ]
⇒
14
1
PDSN IP Address: A1 Element Identifier = [14H]
Length = [04H]
2
(MSB)
3
PDSN IP Address = <any value>
4
5
(LSB)
2
3
B-15
6
A.S0007-0 version 2.0 (TIA-878)
HRPD IOS Publication Version
November, 2001
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.
Information Element
3
4
Section
Reference
Element Direction
Type
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
a. If this element is included in this message, its value shall be returned in the corresponding element in
the A9-Release-A8 message sent in response to this message.
6
b. This second occurrence of the Mobile Identity element, if included, shall contain the ESN of the MS.
Use of the ESN in this message is a network operator decision.
7
c. Allowable cause values are: “Packet call going dormant”; “Equipment failure”; “Normal call release”.
5
8
9
10
11
d. This information element shall be set to the MN ID, associated with the A10 connection, in HRPD
messages.
e. The IS-2000 CON_REF field of this information element shall be set to 00H for padding, in HRPD
messages.
12
13
B-16
A.S0007-0 version 2.0 (TIA-878)
HRPD IOS Publication Version
November, 2001
1
The following table shows the bitmap layout for the A9-Disconnect-A8 message:
7
6
5
4
⇒
⇒
3
2
1
0
1
A9 Message Type = [03H]
Call Connection Reference:
1
A1 Element Identifier = [3FH]
Length = [08H]
(MSB)
2
Market ID = <any value>
3
(LSB)
(MSB)
Octet
Generating Entity ID = <any value>
4
5
(LSB)
(MSB)
6
7
Call Connection Reference = <any value>
8
9
(LSB)
⇒
10
1
Correlation ID: A3/A7 Element Identifier = [13H]
Length = [04H]
2
(MSB)
3
Correlation Value = <any value>
4
5
(LSB)
⇒
1
Mobile Identity (IMSI): A1 Element Identifier = [0DH]
Length = [06H-08H] (10-15 digits)
Identity Digit 1 = [0H-9H] (BCD)
Odd/even
Indicator
= [1,0]
Identity Digit 3 = [0H-9H] (BCD)
6
2
Type of Identity
= [110] (IMSI)
3
Identity Digit 2 = [0H-9H] (BCD)
###
4
###
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
⇒
1
Mobile Identity (ESN): A1 Element Identifier = [0DH]
Length = [05H]
Identity Digit 1 = [0000]
Odd/even
Indicator
= [0]
2
Type of Identity
= [101] (ESN)
3
(MSB)
4
ESN = <any value>
5
6
(LSB)
-- Continued on next page -2
B-17
7
A.S0007-0 version 2.0 (TIA-878)
HRPD IOS Publication Version
November, 2001
1
-- Continued from previous page -⇒
⇒
(MSB)
CON_REF:
1
A9 Element Identifier = [01H]
Length = [01H]
2
IS-2000 CON_REF = [00H – FFH]
3
A8 Traffic ID:
1
A9 Element Identifier = [08H]
Length = [0CH]
2
A8 transport protocol stack = [01H] (GRE/IP)
3
Protocol Type = [88 81H] (Unstructured byte stream)
4
(LSB)
(MSB)
5
6
Key = <any value>
7
8
(LSB)
Address Type = [01H] (IPv4)
9
10
(MSB)
11
IP Address = <any value>
12
13
(LSB)
⇒
ext = [0]
Cause: A9 Element Identifier = [04H]
14
1
Length = [01H]
2
Cause Value =
[10H (Packet call going dormant),
14H (Normal call release),
20H (Equipment failure) ]
3
2
3
B-18
A.S0007-0 version 2.0 (TIA-878)
HRPD IOS Publication Version
November, 2001
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.
Information Element
3
4
5
6
7
Section
Reference
Element Direction
Type
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
a. This element shall be included if it was also included in the A9-Disconnect-A8 message. This
element shall be set to the value received in that message. If this element was not included in that
message, it may be included in this message.
b. This second occurrence of the Mobile Identity element, if included, shall contain the ESN of the MS.
Use of the ESN in this message is a network operator decision.
10
c. Allowable cause values are: “Packet call going dormant”; “Equipment failure”; “Normal call release”; "Handoff Successful"; “Authentication Failure”. Note that Normal Call Release indicates that
the service has been released and therefore the A10 resources should be dropped.
11
d. This element shall be included to indicate the active connection time for a traffic channel.
8
9
13
e. This information element shall be set to the MN ID, associated with the A10 connection, in HRPD
messages.
14
f.
12
15
The IS-2000 CON_REF field of this information element shall be set to 00H for padding, in HRPD
messages.
16
17
B-19
A.S0007-0 version 2.0 (TIA-878)
HRPD IOS Publication Version
1
November, 2001
The following table shows the bitmap layout for the A9-Release-A8 message:
7
6
5
4
⇒
⇒
3
2
1
0
1
A9 Message Type = [04H]
Call Connection Reference:
1
A1 Element Identifier = [3FH]
Length = [08H]
(MSB)
2
Market ID = <any value>
3
(LSB)
(MSB)
Octet
Generating Entity ID = <any value>
4
5
(LSB)
(MSB)
6
7
Call Connection Reference = <any value>
8
9
(LSB)
⇒
10
1
Correlation ID: A3/A7 Element Identifier = [13H]
Length = [04H]
2
(MSB)
3
Correlation Value = <any value>
4
5
(LSB)
⇒
1
Mobile Identity (IMSI): A1 Element Identifier = [0DH]
Length = [06H-08H] (10-15 digits)
Identity Digit 1 = [0H-9H] (BCD)
Odd/even
Indicator
= [1,0]
Identity Digit 3 = [0H-9H] (BCD)
6
2
Type of Identity
= [110] (IMSI)
3
Identity Digit 2 = [0H-9H] (BCD)
###
4
###
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
⇒
1
Mobile Identity (ESN): A1 Element Identifier = [0DH]
Length = [05H]
Identity Digit 1 = [0000]
Odd/even
Indicator
= [0]
2
Type of Identity
= [101] (ESN)
3
(MSB)
4
ESN = <any value>
5
6
(LSB)
⇒
CON_REF:
A9 Element Identifier = [01H]
7
1
Length = [01H]
2
IS-2000 CON_REF = [00H – FFH]
3
-- Continued on next page -2
B-20
A.S0007-0 version 2.0 (TIA-878)
HRPD IOS Publication Version
November, 2001
1
-- Continued from previous page -⇒
(MSB)
A8 Traffic ID:
1
A9 Element Identifier = [08H]
Length = [0CH]
2
A8 transport protocol stack = [01H] (GRE/IP)
3
Protocol Type = [88 81H] (Unstructured byte stream)
4
(LSB)
(MSB)
5
6
Key = <any value>
7
8
(LSB)
Address Type = [01H] (IPv4)
9
10
(MSB)
11
IP Address = <any value>
12
13
(LSB)
⇒
ext = [0]
⇒
14
1
Cause: A9 Element Identifier = [04H]
Length = [01H]
2
Cause Value =
[10H (Packet call going dormant),
14H (Normal call release),
0BH (Handoff Successful),
20H (Equipment failure),
1AH (Authentication Failure) ]
3
Active Connection Time in Seconds:
A9 Element Identifier = [0AH]
Length = [04H]
1
2
(MSB)
3
Active Connection Time = [00 00 00 00H – FF FF FF FFH]
4
###
5
(LSB)
2
3
4
B-21
6
A.S0007-0 version 2.0 (TIA-878)
HRPD IOS Publication Version
1
6.1.10.5
2
No changes from TIA/EIA/IS-2001-A text.
3
6.1.10.6
4
5
A9-Release-A8 Complete
A9-BS Service Request
This A9 interface message is sent from the PCF to the BS to request re-activation of a packet data service
in Dormant state.
Information Element
6
7
8
9
10
11
12
13
November, 2001
Section
Reference
Element Direction
Type
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
Od
R
Mobile Identity (ESN)
6.2.2.16
PCF -> BS
Ob
C
Service Option
6.2.2.66
PCF -> BS
O
R
Data Count
6.2.2.179
PCF -> BS
Oc
C
a. If this element is included in this message, its value shall be returned in the corresponding element in
the A9-BS Service Response message sent in response to this message.
b. This second occurrence of the Mobile Identity element, if included, shall contain the ESN of the MS.
Use of the ESN in this message is a network operator decision.
c. This IE may be included by the PCF to indicate to the BS the amount of data remaining at the PCF
that is to be transmitted.
d. This information element shall be is set to the MN ID, associated with the A10 connection, in HRPD
messages.
14
15
B-22
A.S0007-0 version 2.0 (TIA-878)
HRPD IOS Publication Version
November, 2001
1
The following table shows the bitmap layout for the A9-BS Service Request message:
7
6
5
4
⇒
⇒
3
2
1
0
Octet
A9 Message Type = [06H]
1
Correlation ID: A3/A7 Element Identifier = [13H]
1
Length = [04H]
2
(MSB)
3
Correlation Value = <any value>
4
5
(LSB)
⇒
1
Mobile Identity (IMSI): A9 Element Identifier = [0DH]
Length = [06H-08H] (10-15 digits)
Identity Digit 1 = [0H-9H] (BCD)
Odd/even
Indicator
= [1,0]
Identity Digit 3 = [0H-9H] (BCD)
6
2
Type of Identity
= [110] (IMSI)
3
Identity Digit 2 = [0H-9H] (BCD)
###
4
###
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
⇒
1
Mobile Identity (ESN): A1 Element Identifier = [0DH]
Length = [05H]
Identity Digit 1 = [0000]
Odd/even
Indicator
= [0]
2
Type of Identity
= [101] (ESN)
3
(MSB)
4
ESN = <any value>
5
6
(LSB)
⇒
1
Service Option: A1 Element Identifier = [03H]
(MSB)
Service Option
= [00 3B H (High Rate Packet Data)]
⇒
Data Count:
A9 Element Identifier = [09H]
7
2
(LSB)
3
1
Length = [02H]
2
Count = <any value>
3
###
4
2
B-23
A.S0007-0 version 2.0 (TIA-878)
HRPD IOS Publication Version
1
6.1.10.7
2
No changes from TIA/EIA/IS-2001-A text.
3
6.1.10.8
4
5
6
A9-BS Service Response
A9-AL Connected
This A9 interface message is sent from the BS to the PCF to notify that the traffic channel is established
when the MS performed Hard Handoff or in HRPD systems when the AN starts to receive transmissions
from the MS/AT for which it has started timer Tairdrop and such that this timer has not expired.
Information Element
7
8
9
10
November, 2001
Section
Reference
Element Direction
Type
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
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
a. If this element is included in this message, its value shall be returned in the corresponding element in
the A9-AL Connected Ack message sent in response to this message.
b. The Access Network Identifiers are those of the source PCF communicated by the source BSC via the
MSC (handoff required, handoff requested messages), in cdma2000 systems.
12
c. The Bit-Exact Length – Octet Count field and the Bit-Exact Length – Fill Bits field of this information element shall set to ‘0’, in HRPD messages.
13
d. The UZID field of this information element shall be set to 00H for padding, in HRPD messages.
11
14
15
e. The Non-Assured Mode Packet Priority field of this information element shall set to 0H for padding,
in HRPD messages.
16
17
B-24
A.S0007-0 version 2.0 (TIA-878)
HRPD IOS Publication Version
November, 2001
1
The following table shows the bitmap layout for the A9-AL Connected message:
7
6
5
4
⇒
⇒
3
2
1
0
1
A9 Message Type = [08H]
Call Connection Reference:
1
A1 Element Identifier = [3FH]
Length = [08H]
(MSB)
2
Market ID = <any value>
3
(LSB)
(MSB)
Octet
Generating Entity ID = <any value>
4
5
(LSB)
(MSB)
6
7
Call Connection Reference = <any value>
8
9
(LSB)
⇒
10
1
Correlation ID: A3/A7 Element Identifier = [13H]
Length = [04H]
2
(MSB)
3
Correlation Value = <any value>
4
5
(LSB)
⇒
(MSB)
A8 Traffic ID:
6
1
A9 Element Identifier = [08H]
Length = [0CH]
2
A8 transport protocol stack = [01H] (GRE/IP)
3
Protocol Type = [88 81H] (Unstructured byte stream)
4
(LSB)
(MSB)
5
6
Key = <any value>
7
8
(LSB)
Address Type = [01H] (IPv4)
9
10
(MSB)
11
IP Address = <any value>
12
13
(LSB)
⇒
14
1
PDSN IP Address: A1 Element Identifier = [14H]
Length = [04H]
2
(MSB)
3
PDSN IP Address = <any value>
4
5
(LSB)
-- Continued on next page -2
B-25
6
A.S0007-0 version 2.0 (TIA-878)
HRPD IOS Publication Version
November, 2001
1
-- Continued from previous page -⇒
IS-2000 Service Configuration Record:
A1 Element Identifier = [0EH]
Bit-Exact Length – Octet Count
= [00H to FFH]
Reserved
= [0000 0]
2
Bit-Exact Length – Fill Bits
= [000 to 111]
(MSB)
Seventh
Fill Bit –
if needed
= [0 (if
used as a
fill bit)]
⇒
Sixth Fill
Bit – if
needed
= [0 (if
used as a
fill bit)]
Fifth Fill
Bit – if
needed
= [0 (if
used as a
fill bit)]
Fourth
Fill Bit –
if needed
= [0 (if
used as a
fill bit)]
Third
Fill Bit –
if needed
= [0 (if
used as a
fill bit)]
. . .
Second
Fill Bit –
if needed
= [0 (if
used as a
fill bit)]
First Fill
Bit – if
needed
= [0 (if
used as a
fill bit)]
Service Option
= [ 00 3B H (High Rate Packet Data) ]
⇒
User Zone ID:
2
(LSB)
2
UZID = <any value>
3
(LSB)
⇒
Quality of Service Parameters:
2
Non-Assured Mode Packet Priority =
[0000 – 1101]
⇒ACCESS NETWORK IDENTIFIERS: A1 ELEMENT IDENTIFIER = [20H]
Length = [05H]
(MSB)
2
3
(LSB)
NID = <any value>
B-26
4
5
(LSB)
2
3
1
SID = <any value>
PZID = <any value>
4
1
A1 Element Identifier = [07H]
Length = [01H]
Reserved = [0000]
3
1
A1 Element Identifier = [02H]
Length = [02H]
(MSB)
k
1
Service Option: A1 Element Identifier = [03H]
(MSB)
(MSB)
3
4
IS-2000 Service Configuration Record Content
= <any value>
Reserve
d = [0]
1
6
7
A.S0007-0 version 2.0 (TIA-878)
HRPD IOS Publication Version
November, 2001
1
2
3
6.1.10.9
A9-AL Connected Ack
This A9 interface message is sent from the PCF to the BS to acknowledge completion of the Al
connection request or the A9-AL Connected message for HRPD systems.
Information Element
4
5
Section
Reference
Element Direction
Type
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
PDSN IP Address
6.2.2.30
PCF -> BS
Ob
C
a. This element shall only be included if it was also included in the A9-AL Connected message. This
element shall be set to the value received in that message.
7
b. This IE may be included if the target PCF could not connect to the PDSN designated in the A9-AL
Connected message.
8
The following table shows the bitmap layout for the A9-AL Connected Ack message:
6
7
6
5
4
⇒
⇒
3
2
1
0
1
A9 Message Type = [09H]
Call Connection Reference:
1
A1 Element Identifier = [3FH]
Length = [08H]
(MSB)
2
Market ID = <any value>
3
(LSB)
(MSB)
Octet
Generating Entity ID = <any value>
4
5
(LSB)
(MSB)
6
7
Call Connection Reference = <any value>
8
9
(LSB)
⇒
10
1
Correlation ID: A3/A7 Element Identifier = [13H]
Length = [04H]
2
(MSB)
3
Correlation Value = <any value>
4
5
(LSB)
⇒
6
1
PDSN IP Address: A1 Element Identifier = [14H]
Length = [04H]
2
(MSB)
3
PDSN IP Address = <any value>
4
5
(LSB)
9
B-27
6
A.S0007-0 version 2.0 (TIA-878)
HRPD IOS Publication Version
November, 2001
1
6.1.10.10
2
No changes from TIA/EIA/IS-2001-A text.
3
6.1.10.11
4
5
6
A9-AL Disconnected
A9-AL Disconnected Ack
For cdma2000 systems, this This A9 interface message is sent from the PCF to the BS to acknowledge
completion of the Al disconnected request. For HRPD systems, the A9-AL Disconnected Ack message is
only used to acknowledge the A9-AL Disconnected message.
Information Element
Section
Reference
Element Direction
Type
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
8
a. This element shall only be included if it was also included in the A9-AL Disconnected message. This
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
7
6
5
4
⇒
⇒
3
2
1
0
1
A9 Message Type = [0BH]
Call Connection Reference:
1
A1 Element Identifier = [3FH]
Length = [08H]
(MSB)
2
Market ID = <any value>
3
(LSB)
(MSB)
Octet
Generating Entity ID = <any value>
4
5
(LSB)
(MSB)
6
7
Call Connection Reference = <any value>
8
9
(LSB)
⇒
10
1
Correlation ID: A3/A7 Element Identifier = [13H]
Length = [04H]
2
(MSB)
3
Correlation Value = <any value>
4
5
(LSB)
10
11
12
B-28
6
A.S0007-0 version 2.0 (TIA-878)
HRPD IOS Publication Version
November, 2001
1
2
3
4
6.1.10.12
A9-Short Data Delivery
This message is sent from the BS to the PCF when a short data burst is received from a mobile. It is sent
from the PCF to the BS when a small amount of data is received for a mobile when it’s packet data
service instance is dormant. This section is not applicable to HRPD systems.
5
Information Element
6
7
8
9
10
11
12
13
Section
Reference
Element Direction
Type
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
a. If this element is included, its value shall be returned in the corresponding element in the A9-Short
Data Ack message from the BS.
b. This second occurrence of the Mobile Identity element, if included, shall contain the ESN of the MS.
Use of the ESN in this message is a network operator decision.
c. This element is included in this message when sent from the PCF to the BS and indicates the number
of additional bytes of data queued at the PCF and waiting to be sent to a specific mobile.
d. Contains the packet data received from the PDSN or an MS in a SDB format as specified in IS-707A-2.
14
15
B-29
A.S0007-0 version 2.0 (TIA-878)
HRPD IOS Publication Version
1
November, 2001
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
Correlation ID: A8/A9 Element Identifier = [13H]
1
Length = [04H]
2
(MSB)
3
Correlation Value = <any value>
4
5
(LSB)
⇒
1
Mobile Identity (IMSI): A9 Element Identifier = [0DH]
Length = [06H-08H] (10-15 digits)
Identity Digit 1 = [0H-9H] (BCD)
Odd/even
Indicator
= [1,0]
Identity Digit 3 = [0H-9H] (BCD)
6
2
Type of Identity
= [110] (IMSI)
3
Identity Digit 2 = [0H-9H] (BCD)
###
4
###
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
⇒
1
Mobile Identity (ESN): A1 Element Identifier = [0DH]
Length = [05H]
Identity Digit 1 = [0000]
Odd/even
Indicator
= [0]
2
Type of Identity
= [101] (ESN)
3
(MSB)
4
ESN = <any value>
5
6
(LSB)
⇒
1
SR_ID: A9 Element Identifier = [0BH]
Length = [01H]
Reserved = [0000 0]
⇒
⇒
2
IS-2000 SR_ID = [001 - 011]
Data Count:
(MSB)
Length = [02H]
2
Count = <any value>
3
…
4
ADDS User Part:
1
A1 Element Identifier = [3DH]
2
Data Burst Type =
[ 06H (Short Data Burst) ]
3
Application Data Message = <any value>
4
###
###
(LSB)
2
3
3
1
A9 Element Identifier = [09H]
Length = <variable>
Reserved = [00]
7
B-30
n
A.S0007-0 version 2.0 (TIA-878)
HRPD IOS Publication Version
November, 2001
1
2
3
4
6.1.10.13
A9-Short Data Ack
This A9 interface message is sent from the BS to the PCF to acknowledge reception of the A9-Short Data
Delivery message and to indicate to the PCF whether the data was accepted for delivery to the mobile.
This section is not applicable to HRPD systems.
5
Information Element
6
7
8
9
10
Section
Reference
Element Direction
Type
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
a. If this element is included, its value shall be set to the value of the corresponding element in the A9Short Data Delivery message from the PCF.
b. This second occurrence of the Mobile Identity element, if included, shall contain the ESN of the MS.
Use of the ESN in this message is a network operator decision.
c. The cause value indicates to the PCF whether a short data burst be sent to the mobile.
11
12
B-31
A.S0007-0 version 2.0 (TIA-878)
HRPD IOS Publication Version
1
November, 2001
The following table shows the bitmap layout for the A9-Short Data Ack message.
7
6
5
4
⇒
⇒
3
2
1
0
Octet
A9 Message Type = [0DH]
1
Correlation ID: A8/A9 Element Identifier = [13H]
1
Length = [04H]
2
(MSB)
3
Correlation Value = <any value>
4
5
(LSB)
⇒
1
Mobile Identity (IMSI): A9 Element Identifier = [0DH]
Length = [06H-08H] (10-15 digits)
Identity Digit 1 = [0H-9H] (BCD)
Odd/ev
en
Indicat
or
= [1,0]
Identity Digit 3 = [0H-9H] (BCD)
6
2
Type of Identity
= [110] (IMSI)
2
Identity Digit 2 = [0H-9H] (BCD)
###
3
###
Identity Digit N+1 = [0H-9H] (BCD)
Identity Digit N = [0H-9H] (BCD)
n
= [1111] (if even number of digits)
Identity Digit N+2 = [0H-9H] (BCD)
n+1
⇒
1
Mobile Identity (ESN): A1 Element Identifier = [0DH]
Length = [05H]
Identity Digit 1 = [0000]
Odd/ev
en
Indicat
or
= [0]
2
Type of Identity
= [101] (ESN)
3
(MSB)
4
ESN = <any value>
5
6
(LSB)
⇒
SR_ID: A9 Element Identifier = [0BH]
Length = [01H]
Reserved = [0000 0]
⇒
IS-2000 SR_ID = [001 - 011]
Cause: A1 Element Identifier = [04H]
Cause Value =
[13H (Successful Operation),
16H (Initiate Re-activation of Packet Data call)
2
3
B-32
1
2
Length = [01H]
ext =
[0]
7
3
1
2
3
A.S0007-0 version 2.0 (TIA-878)
HRPD IOS Publication Version
November, 2001
1
2
3
6.1.10.14
A9-Update-A8
This A9 interface message is sent from the BS to the PCF to indicate a change to the session airlink parameters.
Information Element
4
5
6
7
8
9
Section
Reference
Element Direction
Type
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
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
a. If this element is included in this message, its value shall be returned in the corresponding element in
the A9-Update-A8-Ack message sent in response to this message.
b. This second occurrence of the Mobile Identity element, if included, shall contain the ESN of the MS.
Use of the ESN in this message is a network operator decision.
c. These elements are required unless the message is used to indicate Dormant Power down or
Authentication Failure.
10
d. This information element shall be set to the MN ID, retrieved from AN-AAA, in HRPD messages.
11
e. This information element shall not be included in HRPD messages.
12
13
B-33
A.S0007-0 version 2.0 (TIA-878)
HRPD IOS Publication Version
1
November, 2001
The following table shows the bitmap layout for the A9-Update-A8 message:
7
6
5
4
⇒
⇒
3
2
1
0
1
A9 Message Type = [03H]
Call Connection Reference:
1
A1 Element Identifier = [3FH]
Length = [08H]
(MSB)
2
Market ID = <any value>
3
(LSB)
(MSB)
Octet
Generating Entity ID = <any value>
4
5
(LSB)
(MSB)
6
7
Call Connection Reference = <any value>
8
9
(LSB)
⇒
10
1
Correlation ID: A3/A7 Element Identifier = [13H]
Length = [04H]
2
(MSB)
3
Correlation Value = <any value>
4
5
(LSB)
⇒
1
Mobile Identity (IMSI): A9 Element Identifier = [0DH]
Length = [06H-08H] (10-15 digits)
Identity Digit 1 = [0H-9H] (BCD)
Odd/even
Indicator
= [1,0]
Identity Digit 3 = [0H-9H] (BCD)
6
2
Type of Identity
= [110] (IMSI)
2
Identity Digit 2 = [0H-9H] (BCD)
###
3
###
Identity Digit N+1 = [0H-9H] (BCD)
Identity Digit N = [0H-9H] (BCD)
n
= [1111] (if even number of digits)
Identity Digit N+2 = [0H-9H] (BCD)
n+1
⇒
1
Mobile Identity (ESN): A1 Element Identifier = [0DH]
Length = [05H]
Identity Digit 1 = [0000]
Odd/even
Indicator
= [0]
2
Type of Identity
= [101] (ESN)
3
(MSB)
4
ESN = <any value>
5
6
(LSB)
-- Continued on next page -2
B-34
7
A.S0007-0 version 2.0 (TIA-878)
HRPD IOS Publication Version
November, 2001
1
-- Continued from previous page -⇒
IS-2000 Service Configuration Record:
A1 Element Identifier = [0EH]
Bit-Exact Length – Octet Count = <variable>
Reserved
= [ 0000 0 ]
2
Bit-Exact Length – Fill Bits
= [ 000 – 111 ]
(MSB)
3
4
IS-2000 Service Configuration Record Content = <any value>
Seventh
Fill Bit –
if needed
= [0 (if
used as a
fill bit)]
⇒
Sixth Fill
Bit – if
needed
= [0 (if
used as a
fill bit)]
Fourth
Fill Bit –
if needed
= [0 (if
used as a
fill bit)]
Fifth Fill
Bit – if
needed
= [0 (if
used as a
fill bit)]
Third
Fill Bit –
if needed
= [0 (if
used as a
fill bit)]
Second
Fill Bit –
if needed
= [0 (if
used as a
fill bit)]
. . .
First Fill
Bit – if
needed
= [0 (if
used as a
fill bit)]
Service Option
= [ 00 3B H (High Rate Packet Data ) ]
⇒
User Zone ID:
2
(LSB)
2
UZID = <any value>
3
(LSB)
⇒
Quality of Service Parameters:
A1 Element Identifier = [07H]
Length = [01H]
Reserved = [0000]
⇒
Non-Assured Mode Packet Priority = [0000 –
1101]
Cause: A1 Element Identifier = [04H]
Length = [01H]
Cause Value =
[19H (Power down from dormant state),
1CH (update accounting: late traffic channel setup),
1EH (update accounting: parameter change),
1AH (Authentication Failure)]
2
3
4
6.1.10.15
A9-Update-A8-Ack
5
No changes from TIA/EIA/IS-2001-A text.
6
B-35
3
1
A1 Element Identifier = [02H]
Length = [02H]
(MSB)
k
1
Service Option: A1 Element Identifier = [03H]
(MSB)
Ext=
[0]
1
4
1
2
3
1
2
3
A.S0007-0 version 2.0 (TIA-878)
HRPD IOS Publication Version
1
November, 2001
No text.
2
B-36
A.S0007-0 version 2.0 (TIA-878)
HRPD IOS Publication Version
November, 2001
1
Annex C
2
2.15
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
46
A10/A11 Interface Procedures
A10/A11 interface uses Mobile IP messages for managing the A10 connections. The following sections
describe the messages and procedures for the A10/A11 interfaces. The sections are as follows:
•
•
•
•
•
A10 Connection Setup Procedures,
A10 Connection Re-Registration Procedures,
A10 Connection Release Procedures,
A10 Connection Accounting Procedures, and
A10/A11 Interface Call Flows for cdma2000 mobiles.
When originating in a cdma2000 system, The mobile subscriber initiates a packet data call is initiated by
sending an IS-2000 Origination Message. Normal voice service authentication procedures are followed
for the subscriber, and then a traffic channel is established with the mobile. After connection of a packet
data service option, RLP synchronization between the mobile station and the BS proceeds. When
originating in an HRPD system, a packet data session is initiated as specified in TIA/EIA/IS-856. Access
authentication of the AT may be performed via the AN AAA server. After establishment of a packet data
session in the AN and allocation of radio resources, the The BS/PCF initiates setup of an A10 connection
with the PDSN by sending an A11-Registration Request message on the A11 interface. The PDSN may
accept or reject the connection setup request. If the connection setup request is acceptable, the PDSN
returns an A11-Registration Reply message with an accept indication, and the packet data call is
connected through the just established A10 connection.
With the A10 connection in place, link layer/network layer frames pass over this connection in both
directions via Generic Routing Extension Encapsulation (GRE) framing. The PDSN accepts these
frames, strips the GRE, and processes them as normal incoming frames for the appropriate interface and
protocol. The other direction behaves analogously, with the PDSN encapsulating the link layer/network
layer frames in GRE, and the PCF stripping the GRE before passing the frames over to the upper layer.
At this point, there is a point-to-point link layer/network layer connection between the MS/AT mobile
user and the PDSN.
In order to setup an A10 connection, the PCF assigns a PCF Session Identifier (PSI) to the packet data
bearer. The Mobile PCF Session Identifier (PSI) is unique only within the PCF entity. The PCF also use
the MN Session Reference ID (MN-SRID) which is passed from the mobile on each cdma2000
origination and which, together with the Mobile Identifier, can be used to identify a packet data service
session for a specific mobile across PCFs and PDSNs. In the case of HRPD, the MN-SRID is not
received from the AT during origination and the AN/PCF shall set this to the default value of 1. In the
A11-Registration Request message, the PCF sets the Home Address field to zeros. The IP source address
(IP header) and the Care-of-Address field of the A11-Registration Request message are set to the IP
address of the PCF. The IP destination address in the IP header and the Home Agent field in the A11Registration Request message are set to the address of the PDSN designated for the call. The PCF
Session Identifier (PSI), link layer/network layer protocol type identifier, MN Session Reference ID and
IMSI address of the mobile subscriber are set in the Session Specific Extension of the A11-Registration
Request message.
When the A10/A11 interface is used between an HRPD AN/PCF and a PDSN, the MN ID that is used by
the AN and the PCF on A8/A9 and A10/A11 messages is determined as follows:
•
If the HRPD AN uses the access authentication feature, the MN ID field shall be set to the MN ID
value returned by the AN-AAA (e.g., IMSI) following successful access authentication.
•
Otherwise, the AN/PCF shall set the MN ID field to a value that conforms to a valid MN ID
format (e.g., IMSI format). In this case, the MN ID is determined by other means.
44
45
A10-A11 (AN/PCF - PDSN) Interface Change Text
C-1
A.S0007-0 version 2.0 (TIA-878)
HRPD IOS Publication Version
1
2
3
4
5
6
November, 2001
The A10 bearer connection is used for the transport of user data for a packet data session. Link layer /
network layer frames are carried between the PCF and the PDSN encapsulated in GRE packets, which in
turn are carried over IP. The PCF-Address and the PDSN-Address are used in the source address and
destination address fields of the IP header used with the GRE packet. The key field in the GRE header
contains the PCF Session Identifier (PSI), and indicates which packet data bearer connection a particular
payload packet belongs to.
10
The A11-Registration Request and A11-Registration Reply messages are defined by RFC 2002 with
extension elements defined in Section 6.1.11 of this standard. The A11-Registration Update and A11Registration Acknowledge messages are also defined in Section 6.1.11 of this standard. The procedures
for the use of these messages are defined in Section 2.15.1 of this standard.
11
2.15.1 A10 Interface Setup Procedures
12
No changes from TIA/EIA/IS-2001-A text.
13
2.15.1.1
14
No changes from TIA/EIA/IS-2001-A text.
15
2.15.1.1.1
7
8
9
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
A10 Connection Establishment
Successful Operation
When the cdma2000 BS receives an Assignment Request with a Service Option that requests packet data
service from the MSC, it initiates the procedure for establishing radio traffic channels. After traffic
channels are established, the BS/PCF initiates procedures for establishing an A10 connection. For the
HRPD system, after the AN and the mobile have established an HRPD session, the AN/PCF initiates
procedures for establishing an A10 connection.
The PCF initiates setup of an A10 connection by sending an A11-Registration Request message to the
PDSN and starts timer Tregreq. The A11-Registration Request message is structured as specified in RFC
2002 and contains the extensions specified in this standard. The A11-Registration Request message may
be retransmitted a configurable number of times as specified in RFC 2002. If the connection setup
request is acceptable, the PDSN updates its binding record for the A10 connection by creating an
association between the MN ID IMSI address and the PCF Session Identifier, PCF-Address and PDSNAddress information. It then returns an A11-Registration Reply message with an accept indication, including the configured Lifetime (Trp) for the A10 connection. The packet data call is connected through
the just established A10 connection.
The PCF and the PDSN use the PCF-IP-Address and the PDSN-IP-Address returned in the A11Registration Reply message as the A10 connection for the transport of user traffic. The PCF-IP-Address
and the PDSN-IP-Address form the unique link layer ID for each A10 connection. The PCF and the
PDSN maintain an association of the mobile’s MN ID IMSI address with the A10 connection.
The PCF and the PDSN use the PCF-Address and the PDSN-Address returned in the A11-Registration
Reply message as the A10 connection for the transport of user traffic. The PSI, PCF-Address and the
PDSN-Address form the unique link layer ID for each A10 connection. The PCF and the PDSN maintain
an association of the mobile’s IMSI address with link layer ID over the A10 connection.
39
Please refer to RFC 2002 and section 6.1.11.1 “A11-Registration Request” for the format and content of
the A11-Registration Request message.
40
2.15.1.1.2
38
41
42
43
44
45
Failure Operation
The PCF initiates setup of an A10 connection by sending an A11-Registration Request message to a
selected PDSN. If the selected PDSN does not accept the connection, it returns an A11-Registration
Reply message with a reject result code.
The PDSN may return an A11-Registration Reply message with result code ‘88H’ (Registration Denied unknown PDSN address). When code ‘88H’ is used, an alternate PDSN address is included in the A11C-2
A.S0007-0 version 2.0 (TIA-878)
HRPD IOS Publication Version
November, 2001
1
2
3
4
5
6
7
8
9
Registration Reply message. The address of the alternate proposed PDSN shall be returned in the Home
Agent field of the A11-Registration Reply message.
On receipt of an A11-Registration Reply message with code ‘88H’, the PCF shall either initiate
establishment of the A10 connection with the proposed PDSN by sending a new A11-Registration
Request message as indicated in this section, or shall use internal algorithms to select a new PDSN.
On receipt of an A11-Registration Reply message with another result code, depending on the result code,
the PCF may attempt to re-try setting up the A10 connection. If the A10 connection can not be
established, the PCF indicates this to the AN which releases the call or to the BSC, which returns a failure
indication to the MSC, which in-turn releases the call.
14
Reliable message delivery mechanisms are used for setting up the A10 connection between the PCF and
the PDSN. As specified in RFC 2002, the A11-Registration Request message may be retransmitted if no
A11-Registration Reply message is received within a configurable time. A call is considered to have
failed if no A11-Registration Reply message is received after a configurable number of A11-Registration
Request retransmissions.
15
2.15.2 A10 Interface Operational Procedures
16
No changes from TIA/EIA/IS-2001-A text.
17
2.15.2.1
18
No changes from TIA/EIA/IS-2001-A text.
19
2.15.2.1.1
20
No changes from TIA/EIA/IS-2001-A text.
21
2.15.2.1.2
22
No changes from TIA/EIA/IS-2001-A text.
23
2.15.3 A10 Interface Release Procedures
10
11
12
13
A10 Connection – Periodic Re-registration
Successful Operation
Failure Operation
26
The release of an A10 connection is controlled by the PCF. For PDSN initiated A10 connection release,
the PDSN requests that the PCF release the connection. The BSC or AN then would releases the traffic
channel(s) accordingly.
27
2.15.3.1
28
No changes from TIA/EIA/IS-2001-A text.
29
2.15.3.1.1
30
No changes from TIA/EIA/IS-2001-A text.
31
2.15.3.1.2
32
No changes from TIA/EIA/IS-2001-A text.
33
2.15.3.2
24
25
34
35
A10 Connection Release – PCF Requested
Successful Operation
Failure Operation
A10 Connection Release – PDSN Initiated
The PDSN may initiate release of an A10 connection by sending an A11-Registration Update message to
the PCF.
38
In the case of a PDSN initiated release of the A10 connection, the PCF indicates this to the AN which
releases the traffic resources accordingly or to the BSC, in this release, which returns an indication to the
MSC .
39
Please refer to Section 6.1.11.3, “A11-Registration Update”, for the format and content of this message.
36
37
C-3
A.S0007-0 version 2.0 (TIA-878)
HRPD IOS Publication Version
1
2.15.3.2.1
2
No changes from TIA/EIA/IS-2001-A text.
3
2.15.3.2.2
4
5
6
7
8
9
10
11
12
November, 2001
Successful Operation
Failure Operation
On failure to receive an A11-Registration Acknowledge or an A11-Registration Request message (with
accounting related information and Lifetime set to zero) in response to a configurable number of A11Registration Update retransmissions or on receiving an A11-Registration Acknowledge with an update
denied status, the PDSN removes the binding information for the A10 connection.
When PCF returns Registration denied, the PDSN may send a new registration update at a configurable
number of time.
On the release of the A10 connection, the PCF indicates this to the AN which releases the resources
associated with the connection or to the BSC, which returns an indication to the MSC (if required), which
in-turn initiates release of the call.
14
Please refer to Section 6.1.11.4, “A11-Registration Acknowledge”, for the format and content of this
message.
15
2.15.4 A10 Interface Packet Accounting Procedures
13
16
17
18
19
20
The PCF uses the A11-Registration Request message to send accounting related and other information to
the PDSN. The accounting related information is accumulated at the PCF and sent to the PDSN on
occurrence of pre-defined triggers, which are listed in Table 2.15.4-1 below. The occurrence of these
predefined triggers is fully specified in TIA/EIA/IS-835. The A10 connection binding information at the
PDSN and the PCF may also be updated appropriately depending on the setting of the Lifetime field.
Table 2.15.4-1 - Accounting Records Generated By The PCF
Airlink Record Type (Y1)
Accounting Records Generated By The PCF
21
22
23
24
25
26
27
28
29
30
31
32
33
34
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
If some airlink parameters for an active session change, the PCF generates an “Active Stop (Y1=3)”
accounting record followed by an “Active Start (Y1=2)” accounting record. For successful operation, the
PDSN saves the accounting related and other information for further processing, and responds with A11Registration Reply message with an accept indication.
See section 6.2.2.166 Vendor/Organization Specific Extension for detailed information on all the airlink
record types and the accounting parameters required for each airlink record type. If the accounting
parameter specified for an airlink record type is not received at the PDSN, the PDSN shall return an A11Registration Reply message with result code ‘8DH’ (Registration Denied - unsupported Vendor ID or
unable to interpret data in the CVSE’.
The following is a description of the accounting events and indicates which airlink record type shall be
used for each event. If a specified airlink record type is not received at the PDSN or on receipt of an
unspecified airlink record type, the PDSN shall return an A11-Registration Reply message with result
code ‘8DH’ (Registration Denied – unsupported Vendor ID or unable to interpret data in the CVSE’.
1
Y1=4 Airlink record is only applicable to cdma2000 systems
C-4
A.S0007-0 version 2.0 (TIA-878)
HRPD IOS Publication Version
November, 2001
1
2.15.4.1
2
No changes from TIA/EIA/IS-2001-A text.
3
2.15.4.2
4
5
6
7
8
9
10
11
A10 Connection Setup Airlink Record
Active-Start Airlink Record
An Active-Start Airlink record shall be included in the A11 Registration Request to the PDSN for any of
the following event:
1. For a cdma2000 system wWhen a traffic channel is assigned to a packet data session: during initial
call setup, on transition from dormant to active state or during handoff or for an HRPD IOS system
when the air interface is in an appropriate state such that bearer data is ready to be exchanged. The
Active-Start Airlink record may follow the connection Setup Airlink record in the same A11Registration Request message (assuming that all the parameters required in the Active-Start Airlink
record are made available at the PCF at that time.
14
2. Following an Active-Stop Airlink record (for cdma2000 systems), when any of the parameters (QoS,
User Zone, Forward/Reverse Mux Option’) currently defined in Active Start are changed. The Active
Start will contain the new set of parameters.
15
2.15.4.3
16
No changes from TIA/EIA/IS-2001-A text.
17
2.15.4.4
18
No changes from TIA/EIA/IS-2001-A text.
19
2.15.4.5
20
No changes from TIA/EIA/IS-2001-A text.
21
2.15.4.6
22
No changes from TIA/EIA/IS-2001-A text.
23
2.15.4.7
24
No changes from TIA/EIA/IS-2001-A text.
12
13
Active-Stop Airlink Record
SDB Airlink Record
Accounting at Re-registration
Sequence Numbers
Accounting update due to parameter changes
25
26
6.1.11
A11 Interface Message Formats
27
No changes from TIA/EIA/IS-2001-A text.
28
6.1.11.1
29
No changes from TIA/EIA/IS-2001-A text.
30
6.1.11.2
31
No changes from TIA/EIA/IS-2001-A text.
32
6.1.11.3
33
No changes from TIA/EIA/IS-2001-A text.
34
6.1.11.4
35
No changes from TIA/EIA/IS-2001-A text.
A11-Registration Request
A11-Registration Reply
A11-Registration Update
A11-Registration Acknowledge
C-5
A.S0007-0 version 2.0 (TIA-878)
HRPD IOS Publication Version
November, 2001
1
2
6.2.2.154
A11 Message Type
3
No changes from TIA/EIA/IS-2001-A text.
4
6.2.2.155
5
No changes from TIA/EIA/IS-2001-A text.
6
6.2.2.156
7
No changes from TIA/EIA/IS-2001-A text.
8
6.2.2.157
9
No changes from TIA/EIA/IS-2001-A text.
Flags
Lifetime
Home Address
10
6.2.2.158
11
No changes from TIA/EIA/IS-2001-A text.
12
6.2.2.159
13
No changes from TIA/EIA/IS-2001-A text.
14
6.2.2.160
15
No changes from TIA/EIA/IS-2001-A text.
16
6.2.2.161
17
No changes from TIA/EIA/IS-2001-A text.
18
6.2.2.162
19
No changes from TIA/EIA/IS-2001-A text.
20
6.2.2.163
21
No changes from TIA/EIA/IS-2001-A text.
22
6.2.2.164
23
No changes from TIA/EIA/IS-2001-A text.
24
6.2.2.165
25
No changes from TIA/EIA/IS-2001-A text.
26
6.2.2.166
27
28
29
30
31
32
33
Home Agent
Care-of-Address
Identification
Code
Status
Mobile-Home Authentication Extension
Registration Update Authentication Extension
Session Specific Extension
Vendor/Organization Specific Extension
This element may be present in the A11-Registration Request message to convey the accounting information from the PCF to the PDSN. This element may also be present in the A11-Registration Request
message to convey the Mobility Event Indicator from the PCF to the PDSN during dormant handoffs and
active/hard handoffs. For alternative coding formats see RFC 2138. This element may also be present in
the A11-Registration Request message to convey the Access Network Identifiers (PANID & CANID).
This element may be present in the A11-Registration Reply message to convey the Data Available
Indicator (DAI) from the PDSN to the PCF during handoff.
C-6
A.S0007-0 version 2.0 (TIA-878)
HRPD IOS Publication Version
November, 2001
1
2
3
4
5
When used to convey the accounting information, the accounting records are contained within the Application Data field of this element. The accounting records conveyed from the PCF to the PDSN conform
to the specifications in TIA/EIA/IS-835 (Wireless IP Network Standard). Each application type 01H
(Accounting) VSE contains one and only one airlink record. For transmission of multiple airlink records
in the same A11-Registration Request message, multiple instances of accounting type VSEs are used.
0
1
2
3
4
5
6
7
Octet
A11 Element Identifier (Type)
1
Reserved
2
3
(MSB)
Length
(LSB)
(MSB)
4
5
3GPP2 Vendor ID
6
7
(LSB)
8
Application Type
9
Application Sub Type
10
(MSB)
11
12
Application Data
…
…
(LSB)
k
6
7
Type:
26H
8
Length:
This field indicates the number of octets in this element following this
field.
10
3GPP2 Vendor ID:
00 00 15 9FH
11
Application Type:
This field indicates the type of the application, that the extension relates
to. The supported values are:
9
12
13
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.
14
15
16
Application Sub Type: This one octet field indicates the Application sub-type within the
Application Type. The supported values are listed in Table 6.2.2.166-2.
17
18
C-7
A.S0007-0 version 2.0 (TIA-878)
HRPD IOS Publication Version
November, 2001
Table 6.2.2.166-2 - Application Sub Type
1
Application Type
Application Sub Type
Application Type
Name
HEX Value
Application Sub
Type Name
HEX Value
Accounting
01 H
RADIUS
01H
DIAMETER
02H
All other values are reserved
Mobility Event
Indicator
02H
Mobility
01H
All other values are reserved
Data Available
Indicator
03H
Data Ready to
Send
01H
All other values are reserved
Access Network
Identifiers
04 H
ANID
01H
All other values are reserved
All other values are reserved
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
Application Data:
For Application Type 01H (Accounting), this field contains the accounting parameters conveyed from the PCF to the PDSN as specified in
TIA/EIA/IS-835 (Wireless IP Network Standard). Each of the accounting parameters are structured in the format of RADIUS attributes specified in RFC 2138 and RFC 2139. This field is used in messages sent from
the PCF to the PDSN.
For Application Type 02H (Mobility Event Indicator), this field is zero
bytes in length. This field is used in messages sent from the PCF to the
PDSN.
For Application Type 03H (Data Available Indicator), this field is zero
bytes in length. This field is used in messages sent from the PDSN to the
PCF.
For Application Type 04H (Access Network Identifiers), this field contains the PANID of the source PCF in octets 11-15 and CANID of the
target PCF in octets 16-20. The PANID and CANID are formatted as
specified for the Access Network Identifiers element (see section
6.2.2.189) from octet 3-7. If PANID or CANID information is not available, it shall be coded as all zeros. The PANID and CANID information
is included only in the first A11 Registration Request message following
a handoff.
For Application Type 01 H (Accounting) all 3GPP2 specific Airlink
Record Parameters are coded as follows:
25
C-8
A.S0007-0 version 2.0 (TIA-878)
HRPD IOS Publication Version
November, 2001
1
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
2
3
Type:
1A H
4
Length:
Type (1 octet ) + Length (1 octet ) + 3GPP2 Vendor Id (4 octets) + {
Vendor-Type (1 octet), Vendor-Length (1 octet), Vendor-Value (variable
octets) of the 3GPP2 specific parameter comprising the airlink record
being coded.}
8
Vendor ID:
00 00 15 9F H
9
Vendor Type:
Sub-Type value from the Airlink Record table below.
Vendor-Length:
Vendor-Type (1 octet) + Vendor-Length (1 octet) + Payload Length (in
octets) from the Airlink Record table below.
5
6
7
10
11
12
13
14
For Application Type 01 H (Accounting) all RADIUS specific Airlink Record Parameters are coded as
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
17
Length:
Type (1 octet) + Length (1 octet) + Payload Length (in octets) from the
Airlink Record table below.
18
C-9
A.S0007-0 version 2.0 (TIA-878)
HRPD IOS Publication Version
November, 2001
1
Airlink Record Fields Tables:
2
1. R-P Session Setup Airlink Record (Connection Setup).
3
Parameter
Type
SubType
Max. Payload
Length (octet)
Format
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
Parameter
Type
SubType
Max. Payload
Length (octet)
Format
Airlink record type = 2 (START)
26
40
4
Integer
R-P Session ID
26
41
4
Integer
Airlink Sequence number
26
42
4
Integer
User Zone
26
11
4
Integer
Forward Mux Option3
26
12
4
Integer
2. Active Start Airlink Record.
Reverse Mux Option3
26
13
4
Integer
3
26
14
4
Integer
3
26
15
4
Integer
26
16
4
Integer
26
17
4
Integer
26
18
4
Integer
26
19
4
Integer
26
20
4
Integer
26
21
4
Integer
26
39
4
Integer
Parameter
Type
SubType
Max. Payload
Length (octet)
Format
Airlink record type = 3 (STOP)
26
40
4
Integer
R-P Session ID
26
41
4
Integer
Airlink Sequence number
26
42
4
Integer
Active Connection Time in Seconds
46
N/A
4
Integer
Forward Fundamental Rate
Reverse Fundamental Rate
Service Option
3
Forward Traffic Type
3
Reverse Traffic Type
Fundamental Frame Size
3
3
Forward Fundamental RC
3
Reverse Fundamental RC
Airlink Quality of Service (QoS)
4
3
3. Active Stop Airlink Record.
5
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-10
A.S0007-0 version 2.0 (TIA-878)
HRPD IOS Publication Version
November, 2001
1
4. SDB Airlink Record.
Parameter
Type
SubType
Max. Payload
Length (octet)
Format
Airlink record type = 4 (SDB)
26
40
4
Integer
R-P Session ID
26
41
4
Integer
Airlink Sequence number
26
42
4
Integer
Mobile Orig./Term. Indicator
26
45
4
Integer
SDB Octet Count
26
31/324
4
Integer
2
3
4
An example coding of the Active Stop Airlink Record within the Vendor/Organization Specific Extension
element is illustrated below:
0
1
2
3
4
5
6
7
Octet
A11 Element Identifier = 26H
1
Reserved
2
3
(MSB)
Length = 30 H
(LSB)
(MSB)
4
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
5
4
Subtype 31 is for terminating SDB octet count, subtype 32 is for originating SDB octet count.
C-11
A.S0007-0 version 2.0 (TIA-878)
HRPD IOS Publication Version
November, 2001
1
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
Vendor-Length = 06 H
30
(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
Vendor-Length = 06 H
42
(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)
2
C-12
52
A.S0007-0 version 2.0 (TIA-878)
HRPD IOS Publication Version
November, 2001
1
2
3
Annex D
A12 RADIUS Attributes
This is the general Vendor Specific Format for all 3GPP2 RADIUS attributes. The type and vendor ID
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
Figure D-1
5
6
Type:
26
7
Length:
greater than 9
8
3GPP2 Vendor ID: 5535
3GPP2 RADIUS Attribute Format
9
10
11
12
13
14
HRPD Access Authentication: Indicates whether the Access Request is in the context of access
authentication. This optionally appears in an A12 Access-Request message.
Vendor-Type = 60
Vendor-Length = 6
Vendor-Value = 1 (HRPD Access Authentication)
15
16
D-1
A.S0007-0 version 2.0 (TIA-878)
HRPD IOS Publication Version
1
November, 2001
No text.
2
D-2
A.S0007-0 version 2.0 (TIA-878)
HRPD IOS Publication Version
November, 2001
1
Annex E
Revision History
2
June 14, 2001
TIA-878 Ballot text.
October 15, 2001
TIA-878 Publication text.
3
4
5
E-1
A.S0007-0 version 2.0 (TIA-878)
HRPD IOS Publication Version
November, 2001
1
No text.
2
E-2