A.S0008-C v2.0 090106

3GPP2 A.S0008-C v2.
0 Date: January 2009
1 2 3
Interoperability Specification (IOS) for High Rate Packet Data (HRPD) Radio Access Network Interfaces with Session Control in the Access Network 3GPP2 Publication Version
4 5 6
COPYRIGHT 2009, 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.
3GPP2 A.S0008-C v2.0

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
Table of Contents
Foreword ................................................................................................................................................... xxv 1 1.1 1.1.1 1.1.2 1.1.3 1.2 1.2.1 1.2.2 1.3 1.3.1 1.3.2 1.4 1.5 1.6 1.7 1.8 1.9 1.10 1.11 Introduction...................................................................................................................................1-1 Overview.......................................................................................................................................1-1 Purpose..........................................................................................................................................1-2 Scope.............................................................................................................................................1-2 Document Convention ..................................................................................................................1-2 References.....................................................................................................................................1-2 Normative References...................................................................................................................1-2 Informative References.................................................................................................................1-4 Terminology..................................................................................................................................1-4 Acronyms......................................................................................................................................1-4 Definitions ....................................................................................................................................1-6 HRPD IOS Architecture Reference Model (SC/MM in the AN) ...............................................1-10 HRPD Micro-Mobility and Macro-Mobility Concepts ..............................................................1-12 Compatibility with IOS Standards ..............................................................................................1-12 Message Body, Coding, Ordering, and Interpretation of Elements ............................................1-13 Forward Compatibility Guidelines .............................................................................................1-14 Message Processing Guidelines ..................................................................................................1-15 Message Definition Guidelines...................................................................................................1-16 HRPD IOS Assumptions.............................................................................................................1-16
1.11.1 IOS Assumptions ........................................................................................................................1-16 1.11.2 QoS Assumptions .......................................................................................................................1-17 1.12 State Definition ...........................................................................................................................1-18 1.12.1 Packet Data Session State ...........................................................................................................1-18 1.12.2 IP Flow State...............................................................................................................................1-18 1.13 Feature Descriptions ...................................................................................................................1-19 1.13.1.1 1.13.1.2 1.13.1.3 1.13.1.4 1.13.1.5 1.13.1.6 1.13.1.7 1.13.1.8 1.13.1.9 AT Originates an HRPD Session (including Access Authentication).................1-19 Re-authentication of an AT .................................................................................1-19 HRPD Data Delivery (both AT Terminated and AT Originated) .......................1-19 HRPD Connection Release..................................................................................1-19 HRPD Session Release........................................................................................1-19 HRPD Packet Data Session Release....................................................................1-19 Dormant Handoff of HRPD AT Between ANs Served by the Same PDSN .......1-19 Dormant Packet Data Session Handoff Between 1x and HRPD Served by the Same PDSN ..............................................................................................1-19 Voice Call Delivery During Active HRPD Data Session....................................1-19 i 1.13.1 Explicitly Supported Features.....................................................................................................1-19
3GPP2 A.S0008-C v2.0

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
1.13.1.10 1.13.1.11 1.13.1.12 1.13.1.13 1.13.1.14 1.13.1.15 1.13.1.16 1.13.1.16.1 1.13.1.16.2 1.13.1.17 1.13.1.18 1.13.1.19 1.13.1.20 1.13.1.21 1.13.1.22 1.13.1.23 1.13.1.24 1.13.1.25 1.13.1.26 1.13.1.27 1.13.1.28 1.13.1.29 1.13.2.1 2 2.1 2.2 2.3 2.4 2.4.1
Status Management Supported by Feature Invocation ........................................1-20 HRPD-1x cdma2000 Circuit Services Notification Application.........................1-20 Multiple Personalities in the Session Configuration Protocol.............................1-20 Packet Application Supporting Multiple Link Flows and Quality of Service.....1-20 Data Over Signaling (DoS) .................................................................................1-20 GRE Segmentation ..............................................................................................1-20 RObust Header Compression (ROHC) on SO67 ................................................1-20 AN-Based ROHC ................................................................................................1-20 PDSN-Based ROHC............................................................................................1-20 HRPD Inter-AN Connected State Session Transfer (hard handoff)....................1-21 HRPD Inter-AN Cross-connectivity....................................................................1-21 HRPD Inter-AN Session transfer with cross-connectivity (including make-before-break) .............................................................................................1-21 1x Calling Party Number Presentation ................................................................1-21 Reservation Label in HRPD Service Option When Paging on 1x.......................1-21 Hard Handoff of a VoIP Call from HRPD to 1x Circuit Voice Call...................1-21 Prior Session Release ..........................................................................................1-21 QoS Update by the PDSN Feature Description...................................................1-21 CSNA over A21 ..................................................................................................1-22 PDSN Initiated IP Flow Release .........................................................................1-22 Inter-AN paging when the AT is in idle state......................................................1-22 Keep alive over A13 interface.............................................................................1-22 HRPD Emergency Indicator................................................................................1-22 ROHC over PPP ..................................................................................................1-23
1.13.2 Transparently Supported Features ..............................................................................................1-23 HRPD IOS Interfaces....................................................................................................................2-1 A1/A1p Interface (HRPD AN - MSC)..........................................................................................2-1 A8-A9 (AN - PCF) Interface ........................................................................................................2-2 A10-A11 (PCF - PDSN) Interface ................................................................................................2-2 A12 (AN - AN-AAA) Interface ....................................................................................................2-2 PPP Session...................................................................................................................................2-3 2.4.1.1 2.4.1.2 2.4.1.3 2.4.2 2.4.2.1 2.4.2.2 2.4.3 Establishment ........................................................................................................2-3 Termination ...........................................................................................................2-4 Access Authentication ...........................................................................................2-4 Access Authentication Establishment ...................................................................2-4 Access Authentication Revocation........................................................................2-5
AN-AAA Support .........................................................................................................................2-4
AN-AAA Requirements................................................................................................................2-5 ii
3GPP2 A.S0008-C v2.0

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
2.5 2.5.1 2.5.2
A13 (AN - AN) Interface ..............................................................................................................2-5 A13 Interface Network/Transport Protocol Specification ............................................................2-6 A13 Interface Message Procedures...............................................................................................2-7 2.5.2.1 2.5.2.1.1 2.5.2.1.2 2.5.2.2 2.5.2.2.1 2.5.2.2.2 2.5.2.3 2.5.2.3.1 2.5.2.3.2 2.5.2.4 2.5.2.4.1 2.5.2.4.2 2.5.2.5 2.5.2.5.1 2.5.2.5.2 2.5.2.6 2.5.2.6.1 2.5.2.6.2 2.5.2.7 2.5.2.7.1 2.5.2.7.2 2.5.2.8 2.5.2.8.1 2.5.2.8.2 2.5.2.9 2.5.2.9.1 2.5.2.9.2 2.5.2.10 2.5.2.10.1 2.5.2.10.2 2.5.2.11 2.5.2.11.1 2.5.2.11.2 2.5.2.12 2.5.2.12.1 A13-Session Information Request.........................................................................2-7 Successful Operation .............................................................................................2-7 Failure Operation...................................................................................................2-8 A13-Session Information Response ......................................................................2-8 Successful Operation .............................................................................................2-8 Failure Operation...................................................................................................2-9 A13-Session Information Confirm ........................................................................2-9 Successful Operation .............................................................................................2-9 Failure Operation...................................................................................................2-9 A13-Session Information Reject ...........................................................................2-9 Successful Operation .............................................................................................2-9 Failure Operation...................................................................................................2-9 A13-Resource Release Request.............................................................................2-9 Successful Operation ...........................................................................................2-10 Failure Operation.................................................................................................2-10 A13-Resource Release Response ........................................................................2-10 Successful Operation ...........................................................................................2-10 Failure Operation.................................................................................................2-10 A13-Paging Request............................................................................................2-10 Successful Operation ...........................................................................................2-10 Failure Operation.................................................................................................2-11 A13-Paging Request Ack ....................................................................................2-11 Successful Operation ...........................................................................................2-11 Failure Operation.................................................................................................2-11 A13-Paging Delivered .........................................................................................2-11 Successful Operation ...........................................................................................2-11 Failure Operation.................................................................................................2-11 A13-Paging Delivered Ack .................................................................................2-11 Successful Operation ...........................................................................................2-11 Failure Operation.................................................................................................2-12 A13-Keep Alive Request.....................................................................................2-12 Successful Operation ...........................................................................................2-12 Failure Operation.................................................................................................2-12 A13-Keep Alive Response ..................................................................................2-12 Successful Operation ...........................................................................................2-12 iii
3GPP2 A.S0008-C v2.0

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
2.5.2.12.2 2.5.2.13 2.5.2.13.1 2.5.2.13.2 2.5.2.14 2.5.2.14.1 2.5.2.14.2 2.6 2.6.1 2.6.2
Failure Operation.................................................................................................2-12 A13-1x Air Interface Signaling ...........................................................................2-12 Successful Operation ...........................................................................................2-12 Failure Operation.................................................................................................2-12 A13-1x Air Interface Signaling Ack ...................................................................2-12 Successful Operation ...........................................................................................2-13 Failure Operation.................................................................................................2-13
A16 Interface ..............................................................................................................................2-13 A16 Interface Network/Transport Protocol Specification ..........................................................2-13 A16 Interface Message Procedures.............................................................................................2-14 2.6.2.1 2.6.2.1.1 2.6.2.1.2 2.6.2.2 2.6.2.2.1 2.6.2.2.2 2.6.2.3 2.6.2.3.1 2.6.2.3.2 2.6.2.4 2.6.2.4.1 2.6.2.4.2 2.6.2.5 2.6.2.5.1 2.6.2.5.2 2.6.2.6 2.6.2.6.1 2.6.2.6.2 2.6.2.7 2.6.2.7.1 2.6.2.7.2 2.6.2.8 2.6.2.8.1 2.6.2.8.2 2.6.2.9 2.6.2.9.1 2.6.2.9.2 2.6.2.10 A16-Session Transfer Request ............................................................................2-14 Successful Operation ...........................................................................................2-14 Failure Operation.................................................................................................2-15 A16-Session Transfer Response..........................................................................2-15 Successful Operation ...........................................................................................2-15 Failure Operation.................................................................................................2-15 A16-Session Transfer Complete..........................................................................2-15 Successful Operation ...........................................................................................2-15 Failure Operation.................................................................................................2-15 A16-Session Release Indication ..........................................................................2-16 Successful Operation ...........................................................................................2-16 Failure Operation.................................................................................................2-16 A16-Session Release Indication Ack ..................................................................2-16 Successful Operation ...........................................................................................2-16 Failure Operation.................................................................................................2-16 A16-Session Transfer Abort................................................................................2-16 Successful Operation ...........................................................................................2-16 Failure Operation.................................................................................................2-17 A16-Session Transfer Abort Ack ........................................................................2-17 Successful Operation ...........................................................................................2-17 Failure Operation.................................................................................................2-17 A16-Session Transfer Reject...............................................................................2-17 Successful Operation ...........................................................................................2-17 Failure Operation.................................................................................................2-17 A16-FL Signal Tunnel.........................................................................................2-17 Successful Operation ...........................................................................................2-17 Failure Operation.................................................................................................2-17 A16-FL Signal Tunnel Ack .................................................................................2-18 iv
3GPP2 A.S0008-C v2.0

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
2.6.2.10.1 2.6.2.10.2 2.6.2.11 2.6.2.11.1 2.6.2.11.2 2.6.2.12 2.6.2.12.1 2.6.2.12.2 2.6.2.13 2.6.2.13.1 2.6.2.13.2 2.6.2.14 2.6.2.14.1 2.6.2.14.2 2.7 2.7.1 2.7.2
Successful Operation ...........................................................................................2-18 Failure Operation.................................................................................................2-18 A16-RL Signal Tunnel ........................................................................................2-18 Successful Operation ...........................................................................................2-18 Failure Operation.................................................................................................2-18 A16-RL Signal Tunnel Ack.................................................................................2-18 Successful Operation ...........................................................................................2-18 Failure Operation.................................................................................................2-18 A16-Attributes Update ........................................................................................2-19 Successful Operation ...........................................................................................2-19 Failure Operation.................................................................................................2-19 A16-Attributes Update Ack.................................................................................2-19 Successful Operation ...........................................................................................2-19 Failure Operation.................................................................................................2-19
A17, A18, and A19 Interface......................................................................................................2-20 A17, A18, and A19 Interface Network/Transport Protocol Specification..................................2-20 A17 Message Procedures............................................................................................................2-21 2.7.2.1 2.7.2.1.1 2.7.2.1.2 2.7.2.2 2.7.2.2.1 2.7.2.2.2 2.7.2.3 2.7.2.3.1 2.7.2.3.2 2.7.2.4 2.7.2.4.1 2.7.2.4.2 2.7.2.5 2.7.2.5.1 2.7.2.5.2 2.7.2.6 2.7.2.6.1 2.7.2.6.2 2.7.2.7 2.7.2.7.1 2.7.2.7.2 A17-Allocate Request .........................................................................................2-22 Successful Operation ...........................................................................................2-22 Failure Operation.................................................................................................2-22 A17-Allocate Response .......................................................................................2-22 Successful Operation ...........................................................................................2-22 Failure Operation.................................................................................................2-23 A17-Set Attributes...............................................................................................2-23 Successful Operation ...........................................................................................2-23 Failure Operation.................................................................................................2-24 A17-Set Attributes Ack .......................................................................................2-24 Successful Operation ...........................................................................................2-24 Failure Operation.................................................................................................2-24 A17-Modify Request ...........................................................................................2-25 Successful Operation ...........................................................................................2-25 Failure Operation.................................................................................................2-25 A17-Modify Response ........................................................................................2-25 Successful Operation ...........................................................................................2-25 Failure Operation.................................................................................................2-25 A17-Target Modify Request................................................................................2-25 Successful Operation ...........................................................................................2-26 Failure Operation.................................................................................................2-26 v
3GPP2 A.S0008-C v2.0

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
2.7.2.8 2.7.2.8.1 2.7.2.8.2 2.7.2.9 2.7.2.9.1 2.7.2.9.2 2.7.2.10 2.7.2.10.1 2.7.2.10.2 2.7.2.11 2.7.2.11.1 2.7.2.11.2 2.7.2.12 2.7.2.12.1 2.7.2.12.2 2.7.2.13 2.7.2.13.1 2.7.2.13.2 2.7.2.14 2.7.2.14.1 2.7.2.14.2 2.7.2.15 2.7.2.15.1 2.7.2.15.2 2.7.2.16 2.7.2.16.1 2.7.2.16.2 2.7.2.17 2.7.2.17.1 2.7.2.17.2 2.7.2.18 2.7.2.18.1 2.7.2.18.2 2.7.2.19 2.7.2.19.1 2.7.2.19.2 2.7.2.20 2.7.2.20.1
A17-Target Modify Response .............................................................................2-26 Successful Operation ...........................................................................................2-26 Failure Operation.................................................................................................2-26 A17-Deallocate Request......................................................................................2-26 Successful Operation ...........................................................................................2-26 Failure Operation.................................................................................................2-27 A17-Deallocate Ack ............................................................................................2-27 Successful Operation ...........................................................................................2-27 Failure Operation.................................................................................................2-27 A17-Target Deallocate Request ..........................................................................2-27 Successful Operation ...........................................................................................2-27 Failure Operation.................................................................................................2-27 A17-Target Deallocate Ack.................................................................................2-27 Successful Operation ...........................................................................................2-28 Failure Operation.................................................................................................2-28 A17-CC Packet....................................................................................................2-28 Successful Operation ...........................................................................................2-28 Failure Operation.................................................................................................2-28 A17-Neighbor Information Request....................................................................2-28 Successful Operation ...........................................................................................2-28 Failure Operation.................................................................................................2-29 A17-Neighbor Information Notification .............................................................2-29 Successful Operation ...........................................................................................2-29 Failure Operation.................................................................................................2-29 A17-Neighbor Information Notification Ack......................................................2-29 Successful Operation ...........................................................................................2-29 Failure Operation.................................................................................................2-30 A17-Slave Attach Request ..................................................................................2-30 Successful Operation ...........................................................................................2-30 Failure Operation.................................................................................................2-30 A17-Slave Attach Response ................................................................................2-30 Successful Operation ...........................................................................................2-30 Failure Operation.................................................................................................2-30 A17-Slave Detach Request..................................................................................2-30 Successful Operation ...........................................................................................2-31 Failure Operation.................................................................................................2-31 A17-Slave Detach Ack ........................................................................................2-31 Successful Operation ...........................................................................................2-31 vi
3GPP2 A.S0008-C v2.0

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
2.7.2.20.2 2.7.3 2.7.3.1 2.7.3.1.1 2.7.3.1.2 2.7.3.2 2.7.3.2.1 2.7.3.2.2 2.7.4 2.7.4.1 2.7.4.1.1 2.7.4.1.2 2.7.4.1.3 2.7.4.2 2.7.4.2.1 2.7.4.2.2 2.7.4.3 2.7.4.3.1 2.7.4.3.2 2.7.4.4 2.7.4.4.1 2.7.4.4.2 2.7.4.5 2.7.4.5.1 2.7.4.5.2 2.7.4.6 2.7.4.6.1 2.7.4.6.2 2.7.4.7 2.7.4.7.1 2.7.4.7.2 2.7.4.8 2.7.4.8.1 2.7.4.8.2 2.7.4.9 2.7.4.9.1 2.7.4.9.2 2.7.4.10
Failure Operation.................................................................................................2-31 A18-FTCH Packet ...............................................................................................2-31 Successful Operation ...........................................................................................2-32 Failure Operation.................................................................................................2-32 A18-RTCH Packet ..............................................................................................2-32 Successful Operation ...........................................................................................2-32 Failure Operation.................................................................................................2-33 Serving RT Switching Procedure ........................................................................2-33 Candidate Serving Set .........................................................................................2-34 Recommended Multicasting Procedure...............................................................2-34 Data Transmission Group and its Attributes .......................................................2-35 A19-Acquisition Status .......................................................................................2-36 Successful Operation ...........................................................................................2-36 Failure Operation.................................................................................................2-36 A19-Acquisition Status Ack................................................................................2-36 Successful Operation ...........................................................................................2-36 Failure Operation.................................................................................................2-36 A19-Serving RT Changed ...................................................................................2-36 Successful Operation ...........................................................................................2-37 Failure Operation.................................................................................................2-37 A19-Serving RT Changed Ack ...........................................................................2-37 Successful Operation ...........................................................................................2-37 Failure Operation.................................................................................................2-37 A19-Forward Desired..........................................................................................2-37 Successful Operation ...........................................................................................2-37 Failure Operation.................................................................................................2-37 A19-Forward Desired Ack ..................................................................................2-38 Successful Operation ...........................................................................................2-38 Failure Operation.................................................................................................2-38 A19-Forward Stopped .........................................................................................2-38 Successful Operation ...........................................................................................2-38 Failure Operation.................................................................................................2-38 A19-Forward Stopped Ack..................................................................................2-38 Successful Operation ...........................................................................................2-38 Failure Operation.................................................................................................2-39 A19-Flush............................................................................................................2-39 vii
A18 Message Procedures............................................................................................................2-31
A19 Message Procedures............................................................................................................2-33
3GPP2 A.S0008-C v2.0

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
2.7.4.10.1 2.7.4.10.2 2.7.4.11 2.7.4.11.1 2.7.4.11.2 2.7.4.12 2.7.4.12.1 2.7.4.12.2 2.7.4.13 2.7.4.13.1 2.7.4.13.2 2.8 2.8.1 2.8.2
Successful Operation ...........................................................................................2-39 Failure Operation.................................................................................................2-39 A19-Flush Ack ....................................................................................................2-39 Successful Operation ...........................................................................................2-39 Failure Operation.................................................................................................2-39 A19-Purge ...........................................................................................................2-39 Successful Operation ...........................................................................................2-39 Failure Operation.................................................................................................2-40 A19-Purge Ack....................................................................................................2-40 Successful Operation ...........................................................................................2-40 Failure Operation.................................................................................................2-40
A21 (AN IWS) Interface..........................................................................................................2-40 A21 Interface Network/Transport Protocol Specification ..........................................................2-40 A21 Interface Message Procedures.............................................................................................2-41 2.8.2.1 2.8.2.1.1 2.8.2.1.2 2.8.2.2 2.8.2.2.1 2.8.2.2.2 2.8.2.3 2.8.2.3.1 2.8.2.3.2 2.8.2.4 2.8.2.4.1 2.8.2.4.2 2.8.2.5 2.8.2.5.1 2.8.2.5.2 2.8.2.6 2.8.2.6.1 2.8.2.6.2 2.8.2.7 2.8.2.7.1 2.8.2.7.2 2.8.2.8 2.8.2.8.1 2.8.2.8.2 A21-1x Air Interface Signaling ...........................................................................2-42 Successful Operation ...........................................................................................2-42 Failure Operation.................................................................................................2-42 A21-Ack ..............................................................................................................2-42 Successful Operation ...........................................................................................2-42 Failure Operation.................................................................................................2-43 A21-1x Parameters ..............................................................................................2-43 Successful Operation ...........................................................................................2-43 Failure Operation.................................................................................................2-43 A21-Event Notification .......................................................................................2-43 Successful Operation ...........................................................................................2-43 Failure Operation.................................................................................................2-43 A21-1x Parameters Request ................................................................................2-43 Successful Operation ...........................................................................................2-44 Failure Operation.................................................................................................2-44 A21-Service Request ...........................................................................................2-44 Successful Operation ...........................................................................................2-44 Failure Operation.................................................................................................2-44 A21-Service Response ........................................................................................2-44 Successful Operation ...........................................................................................2-44 Failure Operation.................................................................................................2-44 A21-Radio Update Request.................................................................................2-44 Successful Operation ...........................................................................................2-44 Failure Operation.................................................................................................2-45 viii
3GPP2 A.S0008-C v2.0

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
2.8.2.9 2.8.2.9.1 2.8.2.9.2 2.9 3 3.1 3.1.1 3.1.2 3.2 3.2.1 3.2.2 3.3 3.3.1 3.3.2 3.3.3 3.4 3.4.1 3.4.2 3.5 3.5.1 3.5.2 3.5.3 3.5.4 3.6 3.7 3.7.1 3.7.2 3.8 3.8.1 3.9 3.9.1 3.9.2
A21-Radio Update Response ..............................................................................2-45 Successful Operation ...........................................................................................2-45 Failure Operation.................................................................................................2-45
A24 AN-AN (IP Tunneling) Interface ........................................................................................2-45 HRPD IOS Call Flows ..................................................................................................................3-1 AT Originates HRPD Session.......................................................................................................3-1 AT Originates HRPD Session - Successful Access Authentication .............................................3-1 AT Originates HRPD Session - Unsuccessful Access Authentication .........................................3-3 Re-authentication ..........................................................................................................................3-4 Re-authentication of an AT in Dormant State ..............................................................................3-4 Re-authentication of an AT in Active State ..................................................................................3-5 Data Delivery ................................................................................................................................3-6 Network Initiated Call Re-activation from Dormant State ...........................................................3-6 AT Initiated Call Re-activation from Dormant State (Existing HRPD Session) ..........................3-7 AT Initiated Packet Data Session Establishment from an Established HRPD Session ................3-7 Connection Release.......................................................................................................................3-9 Connection Release on HRPD Network - Initiated by the AT .....................................................3-9 Connection Release on HRPD Network - Initiated by the AN. ....................................................3-9 HRPD Session Release ...............................................................................................................3-11 HRPD Session Release - Initiated by the AT or AN (A8 Connections Exist)............................3-11 HRPD Session Release - Initiated by the AT or AN (A8 Connections do not Exist).................3-11 HRPD Session Release - Re-authentication of AT Failure (A8 Connections Exist) ..................3-12 HRPD Session Release - Re-authentication of AT Failure (A8 Connections do not Exist).......3-14 Packet Data Session Release - Initiated by the PDSN ................................................................3-16 Dormant Handoff of HRPD AT between ANs - Served by the Same PDSN.............................3-17 AN-AN Dormant Handoff with Successful Retrieval of HRPD Session Information ...............3-17 AN-AN Dormant Handoff with HRPD Session Information Transfer Failure ..........................3-19 Miscellaneous Active HRPD Session Call Flows.......................................................................3-21 Deactivation/Activation of Data Flow During an Active HRPD Packet Data Session ..............3-21 Multiple Connection Procedures.................................................................................................3-22 Initial HRPD Call Setup (Default IP Flows Establishment) .......................................................3-22 IP Flow Mapping Update with Service Connection Establishment............................................3-22 3.9.2.1 3.9.2.2 3.9.2.3 IP Flow Mapping Update with Service Connection Establishment All New Connections Establishment .................................................................................3-22 IP Flow Mapping Update with Service Connection Establishment - All New Connections Rejected by PCF/PDSN with Existing Connections Sustained ......3-23 IP Flow Mapping Update with Service Connection Establishment - Partial New Connections Establishment.........................................................................3-24 ix
3GPP2 A.S0008-C v2.0

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
3.9.2.4 3.9.3 3.9.4 3.9.5 3.9.6 3.9.7 3.10
IP Flow Mapping Update with Service Connection Establishment - Main Connection Rejected by PCF/PDSN ...................................................................3-26
IP Flow Mapping Update with Service Connection Release ......................................................3-27 IP Flow to A8/A10 Connection Mapping Update ......................................................................3-28 Subscriber QoS Profile Delivery ................................................................................................3-28 QoS Update by the PDSN...........................................................................................................3-29 PDSN Initiated IP Flow Release.................................................................................................3-30 Support for Data Over Signaling Protocol..................................................................................3-31 3.10.1.1 3.10.1.2 3.10.2.1 3.10.2.2 3.10.2.3 DoS Delivery from the AT to the PDSN without A13 Procedure.......................3-31 DoS Delivery from the AT to the PDSN with A13 Procedure............................3-31 DoS Delivery from the PDSN to the AT.............................................................3-33 DoS Request from the PDSN AN Refuses Request .........................................3-34 DoS Delivery from the PDSN to the AT with A13 Procedure............................3-34
3.10.1 AT Originated DoS .....................................................................................................................3-31
3.10.2 AT Terminated DoS....................................................................................................................3-33
3.11
Mobility Management.................................................................................................................3-35
3.11.1 Prior Session Retrieval Procedure ..............................................................................................3-35 3.11.2 Prior Session Removal Procedure...............................................................................................3-36 3.11.3 Inter-AN Paging when the AT is in Idle State ............................................................................3-37 3.12 Connected State HRPD Session Transfer Call Flows.................................................................3-42 3.12.1 Intra-PDSN Connected State HRPD Hard Handoff - Successful Operation ..............................3-42 3.12.2 Connected State HRPD Hard Handoff - Failure Scenario (Refusal by Target AN) ...................3-46 3.12.3 Connected State HRPD Hard Handoff - Traffic Channel Assignment (TCA) Retry Scenario ..3-48 3.12.4 Connected State HRPD Hard Handoff - Failure Scenario (AT Lost).........................................3-50 3.12.5 Intra-PDSN Connected State HRPD Session Transfer with Cross-Connectivity Support Successful Operation..................................................................................................3-52 3.12.5.1 3.12.5.2 3.12.5.3 3.12.5.4 3.12.5.5 3.12.5.6 3.12.5.7 Slave AN attaches to sectors in another AN during Connected State HRPD Session Transfer with Cross-Connectivity Support.................................3-57 Slave AN detaches from sectors in another AN during Connected State HRPD Session Transfer with Cross-Connectivity Support.................................3-58 Master AN adds new sectors to Active Set during Session Transfer with Cross-Connectivity Support ................................................................................3-58 Master AN removes sectors from the Active Set during Connected State HRPD Session Transfer with Cross-Connectivity Support.................................3-61 Master AN updates Slave AN with the updated session during Connected State Session Transfer with Cross-Connectivity Support....................................3-63 Slave AN tunnels signaling messages to AT through Master AN during Make-before-break Session Transfer ..................................................................3-63 Tunneling of signaling messages from the AT to Slave AN during Make-before-break Session Transfer ..................................................................3-64 x
3.12.6 Data Flow during Make-before-break Session Transfer.............................................................3-64
3GPP2 A.S0008-C v2.0

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
3.13
Hard Handoff Negotiation Procedures with Example of Air-interface Signaling ......................3-66
3.13.1 HRPD Hard Handoff without SLP States Transfer ....................................................................3-66 3.13.2 HRPD Hard Handoff with Personality Switch ...........................................................................3-67 3.14 HRPD IOS Cross-Connectivity Call Flows ................................................................................3-69 3.14.1 AT Connection Setup..................................................................................................................3-69 3.14.2 Add Pilot Belonging to Target AN to ATs Active Set ..............................................................3-73 3.14.3 Drop Pilot Belonging to Target AN from ATs Active Set ........................................................3-74 3.14.4 AT Connection Close..................................................................................................................3-76 3.14.4.1 3.14.4.2 3.14.4.3 Graceful Connection Close..................................................................................3-76 Non-Graceful Connection Close: Scenario 1 ......................................................3-77 Non-Graceful Connection Close: Scenario 2 ......................................................3-78
3.14.5 Source AN Requests Resource Modification at Target AN........................................................3-79 3.14.6 Target AN Requests Resource Modification at Target AN ........................................................3-80 3.14.7 Serving RT Switching.................................................................................................................3-81 3.14.7.1 3.14.7.2 3.14.7.3 3.14.7.4 3.14.7.5 4 4.1 4.1.1 4.1.2 4.1.3 4.2 4.2.1 4.2.2 4.3 4.4 4.5 4.5.1 Serving RT Change: Serving RT Moves to Target AN.......................................3-82 Serving RT Change: Serving RT Moves to Source AN ......................................3-83 Serving RT Change: Serving RT Remains in Target AN (Different Endpoint ID).......................................................................................3-84 Serving RT Change: Serving RT Remains in Same Target AN (Same Endpoint ID).............................................................................................3-86 Serving RT Change: Serving RT Remains in Same Target AN (Different Endpoint ID), and No Early Detection ...............................................3-86
HRPD and 1x IOS Transition Call Flows.....................................................................................4-1 Dormant Cross System Handoff - AT Served by the Same PDSN...............................................4-1 1x to HRPD Dormant Packet Data Session Handoff - Existing HRPD Session...........................4-1 1x to HRPD Dormant Packet Data Session Handoff - New HRPD Session ................................4-2 HRPD to 1x Dormant Packet Data Session Handoff....................................................................4-4 MS/AT Terminated Voice Call During Active HRPD Packet Data Session................................4-6 MS/AT Terminated Voice Call During Active HRPD Packet Data Session (Intra-PDSN/Inter-PCF)................................................................................................................4-6 MS/AT Terminated Voice Call During Active HRPD Packet Data Session (Intra-PCF) ............4-7 1x to HRPD Active Packet Data Session Handoff .....................................................................4-10 Status Management Supported by Feature Invocation................................................................4-11 CSNA in the HRPD System .......................................................................................................4-12 SMS Mobile Originated Point-to-Point (ADDS Transfer) ......................................................4-12 4.5.1.1 4.5.1.2 SMS Mobile Originated Point-to-Point (ADDS Transfer) IWS-AN ............4-12 SMS Mobile Originated Point-to-Point (ADDS Transfer) IWS-1xBS .........4-13
4.5.2
SMS Mobile Terminated Point-to-Point (ADDS Page / ADDS Page Ack) ............................4-13
xi
3GPP2 A.S0008-C v2.0

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
4.5.2.1 4.5.2.2 4.5.2.3 4.5.2.4 4.5.3
SMS Mobile Terminated Point-to-Point (ADDS Page / ADDS Page Ack) without A13 Procedure IWS-AN .....................................................................4-13 SMS Mobile Terminated Point-to-Point (ADDS Page / ADDS Page Ack) without A13 Procedure IWS-1xBS ..................................................................4-14 SMS Mobile Terminated Point-to-Point (ADDS Page / ADDS Page Ack) with A13 Procedure IWS-AN ..........................................................................4-15 SMS Mobile Terminated Point-to-Point (ADDS Page / ADDS Page Ack) with A13 Procedure IWS-1xBS .......................................................................4-16 1x Page Delivery to the MS/AT in an HRPD System (Paging Request) without A13 Procedure IWS-AN Successful Operation ...............................4-18 1x Page Delivery to the MS/AT in an HRPD System (Paging Request) without A13 Procedure IWS-1xBS Successful Operation ............................4-19 1x Page Delivery to the MS/AT in an HRPD System (Paging Request) from Multiple IWS-1xBSs Successful Operation ............................................4-20 1x Page Delivery to the MS/AT in an HRPD System (Paging Request) with A13 Procedure IWS-AN Successful Operation ....................................4-22 1x Page Delivery to the MS/AT in an HRPD System (Paging Request) with A13 Procedure IWS-1xBS Successful Operation .................................4-24 Refusal of a 1x Page Delivery to the MS/AT in an HRPD System (Paging Request) without A13 Procedure IWS-AN.........................................4-25 MS/AT Rejects 1x Page in HRPD System without A13 Procedure IWS-1xBS ...........................................................................................................4-26 Refusal of a 1x Page Delivery to the MS/AT in an HRPD System (Paging Request) with A13 Procedure IWS-AN..............................................4-28 MS/AT Rejects 1x Page in HRPD System with A13 Procedure IWS-1xBS ...........................................................................................................4-29 HRPD Page Delivery in a 1x System - MS/AT Idle IWS-AN .........................4-30 HRPD Page Delivery in a 1x System - MS/AT Idle IWS-1xBS......................4-32 HRPD Page Delivery in a 1x System - MS/AT Idle MS/AT Rejects HRPD Page IWS-AN ..........................................................................................4-33 HRPD Page Delivery in a 1x System - MS/AT Idle MS/AT Rejects HRPD Page IWS-1xBS .......................................................................................4-34 HRPD Page Delivery in a 1x System - MS/AT on a Traffic Channel IWS-AN...............................................................................................................4-35 HRPD Page Delivery in a 1x System - MS/AT on a Traffic Channel IWS-1xBS ...........................................................................................................4-36 HRPD Page Delivery in a 1x System - MS/AT on a Traffic Channel MS/AT Rejects HRPD IWS-AN ...................................................................................4-38 HRPD Page Delivery in a 1x System - MS/AT on a Traffic Channel MS/AT Rejects HRPD Page IWS-1xBS .......................................................................4-39 xii
1x Page Delivery to the MS/AT in an HRPD System (Paging Request)....................................4-18 4.5.3.1 4.5.3.2 4.5.3.3 4.5.3.4 4.5.3.5
4.5.4
Refusal of a 1x Page Delivery to the MS/AT in an HRPD System ............................................4-25 4.5.4.1 4.5.4.2 4.5.4.3 4.5.4.4
4.5.5
HRPD Page Delivery in a 1x System - MS/AT Idle...................................................................4-30 4.5.5.1 4.5.5.2 4.5.5.3 4.5.5.4
4.5.6
HRPD Page Delivery in a 1x System - MS/AT on a Traffic Channel (TCH) ............................4-35 4.5.6.1 4.5.6.2 4.5.6.3 4.5.6.4
3GPP2 A.S0008-C v2.0

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
4.6 4.6.1
Mobility Management for CSNA in the HRPD System .............................................................4-41 1x Registration Over HRPD .......................................................................................................4-41 4.6.1.1 4.6.1.2 1x Registration Over HRPD IWS-AN .............................................................4-41 1x Registration Over HRPD IWS-1xBS ..........................................................4-42
4.6.2 4.6.3 4.7 4.7.1 4.7.2 5 5.1 5.1.1
Event Notification From HRPD AN to IWS-1xBS ....................................................................4-43 Event Notification From IWS-1xBS to HRPD AN ....................................................................4-44 Hard Handoff Between HRPD and 1x........................................................................................4-45 Hard Handoff of a Voice Call from HRPD VoIP to 1x Circuit Service - IWS-1xBS ................4-45 Hard Handoff of a Voice Call From HRPD VoIP to 1x Circuit Service, IWS-AN....................4-48 Messages, Information Elements and Timer Definitions..............................................................5-1 Message Definitions......................................................................................................................5-1 A13 Message Definitions..............................................................................................................5-1 5.1.1.1 5.1.1.2 5.1.1.3 5.1.1.4 5.1.1.5 5.1.1.6 5.1.1.7 5.1.1.8 5.1.1.9 5.1.1.10 5.1.1.11 5.1.1.12 5.1.1.13 5.1.1.14 A13-Session Information Request.........................................................................5-1 A13-Session Information Response ......................................................................5-2 A13-Session Information Confirm ........................................................................5-7 A13-Session Information Reject ...........................................................................5-7 A13-Resource Release Request.............................................................................5-8 A13-Resource Release Response ..........................................................................5-9 A13-Paging Request............................................................................................5-10 A13-Paging Request Ack ....................................................................................5-13 A13-Paging Delivered .........................................................................................5-15 A13-Paging Delivered Ack .................................................................................5-16 A13-Keep Alive Request.....................................................................................5-17 A13-Keep Alive Response ..................................................................................5-18 A13-1x Air Interface Signaling ...........................................................................5-19 A13-1x Air Interface Signaling Ack ...................................................................5-20 A16-Session Transfer Request ............................................................................5-21 A16-Session Transfer Response..........................................................................5-28 A16-Session Transfer Complete..........................................................................5-30 A16-Session Release Indication ..........................................................................5-34 A16-Session Release Indication Ack ..................................................................5-35 A16-Session Transfer Abort................................................................................5-36 A16-Session Transfer Abort Ack ........................................................................5-37 A16-Session Transfer Reject...............................................................................5-38 A16-FL Signal Tunnel.........................................................................................5-39 A16-FL Signal Tunnel Ack .................................................................................5-40 A16-RL Signal Tunnel ........................................................................................5-41 xiii
5.1.2
A16 Message Definitions............................................................................................................5-21 5.1.2.1 5.1.2.2 5.1.2.3 5.1.2.4 5.1.2.5 5.1.2.6 5.1.2.7 5.1.2.8 5.1.2.9 5.1.2.10 5.1.2.11
3GPP2 A.S0008-C v2.0

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
5.1.2.12 5.1.2.13 5.1.2.14 5.1.3 5.1.3.1 5.1.3.2 5.1.3.3 5.1.3.4 5.1.3.5 5.1.3.6 5.1.3.7 5.1.3.8 5.1.3.9 5.1.3.10 5.1.3.11 5.1.3.12 5.1.3.13 5.1.3.14 5.1.3.15 5.1.3.16 5.1.3.17 5.1.3.18 5.1.3.19 5.1.3.20 5.1.4 5.1.4.1 5.1.4.2 5.1.5 5.1.5.1 5.1.5.2 5.1.5.3 5.1.5.4 5.1.5.5 5.1.5.6 5.1.5.7 5.1.5.8 5.1.5.9 5.1.5.10
A16-RL Signal Tunnel Ack.................................................................................5-42 A16-Attributes Update ........................................................................................5-42 A16-Attributes Update Ack.................................................................................5-45 A17-Allocate Request .........................................................................................5-46 A17-Allocate Response .......................................................................................5-49 A17-Set Attributes...............................................................................................5-51 A17-Set Attributes Ack .......................................................................................5-54 A17-Modify Request ...........................................................................................5-55 A17-Modify Response ........................................................................................5-56 A17-Target Modify Request................................................................................5-58 A17 Target Modify Response .............................................................................5-59 A17-Deallocate Request......................................................................................5-60 A17-Deallocate Ack ............................................................................................5-62 A17-Target Deallocate Request ..........................................................................5-62 A17-Target Deallocate Ack.................................................................................5-64 A17-CC Packet....................................................................................................5-64 A17-Neighbor Information Request....................................................................5-66 A17-Neighbor Information Notification .............................................................5-68 A17-Neighbor Information Notification Ack......................................................5-70 A17-Slave Attach Request ..................................................................................5-70 A17-Slave Attach Response ................................................................................5-73 A17-Slave Detach Request..................................................................................5-74 A17-Slave Detach Ack ........................................................................................5-76 A18-FTCH Packet ...............................................................................................5-76 A18-RTCH Packet ..............................................................................................5-79 A19-Acquisition Status .......................................................................................5-81 A19-Acquisition Status Ack................................................................................5-82 A19-Serving RT Changed ...................................................................................5-83 A19-Serving RT Changed Ack ...........................................................................5-85 A19-Forward Desired..........................................................................................5-86 A19-Forward Desired Ack ..................................................................................5-87 A19-Forward Stopped .........................................................................................5-88 A19-Forward Stopped Ack..................................................................................5-89 A19-Flush............................................................................................................5-90 A19-Flush Ack ....................................................................................................5-91 xiv
A17 Message Definitions............................................................................................................5-46
3GPP2 A.S0008-C v2.0

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
5.1.5.11 5.1.5.12 5.1.6 5.1.6.1 5.1.6.2 5.1.6.3 5.1.6.4 5.1.6.5 5.1.6.6 5.1.6.7 5.1.6.8 5.1.6.9 5.2 5.2.1
A19-Purge ...........................................................................................................5-92 A19-Purge Ack....................................................................................................5-94 A21-1x Air Interface Signaling ...........................................................................5-95 A21-Ack ..............................................................................................................5-99 A21-1x Parameters ............................................................................................5-100 A21-Event Notification .....................................................................................5-101 A21-1x Parameters Request ..............................................................................5-103 A21-Service Request .........................................................................................5-104 A21-Service Response ......................................................................................5-105 A21-Radio Update Request...............................................................................5-106 A21-Radio Update Response ............................................................................5-108
Information Element Definitions ..............................................................................................5-111 A13 Information Element Definitions ......................................................................................5-111 5.2.1.1 5.2.1.2 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 5.2.1.11 5.2.1.12 5.2.1.13 5.2.1.14 5.2.1.15 5.2.1.16 5.2.1.17 5.2.1.18 5.2.1.19 5.2.1.20 5.2.1.21 5.2.1.22 5.2.1.23 5.2.1.24 A13 Information Element Identifiers ................................................................5-111 A13 Cross Reference of IEs with Messages......................................................5-111 A13 Message Type............................................................................................5-114 Unicast Access Terminal Identifier (UATI 128)...............................................5-114 Security Layer Packet........................................................................................5-115 Sector ID............................................................................................................5-115 Cause .................................................................................................................5-115 Mobile Identity (MN ID)...................................................................................5-116 PDSN IP Address ..............................................................................................5-117 Access Network Identifiers ...............................................................................5-117 Session State Information Record .....................................................................5-118 Extended Session State Information Record .....................................................5-118 Forward QoS Information .................................................................................5-119 Reverse QoS Information ..................................................................................5-120 Subscriber QoS Profile ......................................................................................5-121 Forward QoS Update Information.....................................................................5-121 Reverse QoS Update Information .....................................................................5-122 Hardware ID ......................................................................................................5-123 AT-ID ................................................................................................................5-123 Correlation ID....................................................................................................5-124 Paging Control Information...............................................................................5-124 Paging Cause .....................................................................................................5-126 AT Designated Frequency.................................................................................5-127 A13 Vendor-Specific Information.....................................................................5-127 xv
3GPP2 A.S0008-C v2.0

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
5.2.1.25 5.2.1.26 5.2.1.27 5.2.1.28 5.2.2 5.2.2.1 5.2.2.2 5.2.2.3 5.2.2.4 5.2.2.5 5.2.2.6 5.2.2.7 5.2.2.8 5.2.2.9 5.2.2.10 5.2.2.11 5.2.2.12 5.2.2.13 5.2.2.14 5.2.2.15 5.2.2.16 5.2.2.17 5.2.2.18 5.2.2.19 5.2.2.20 5.2.2.21 5.2.2.22 5.2.2.23 5.2.2.24 5.2.2.25 5.2.2.26 5.2.2.27 5.2.2.28 5.2.2.29 5.2.2.30 5.2.2.31 5.2.2.32 5.2.2.33
ADDS User Part ................................................................................................5-128 A13 1x LAC Encapsulated PDU.......................................................................5-128 A13 1x Message Transmission Control ............................................................5-129 Data Transfer.....................................................................................................5-129 A16 Information Element Identifiers ................................................................5-131 A16 Cross Reference of IEs with Messages......................................................5-132 A16 Message Type............................................................................................5-135 Mobile Identity (MN ID)...................................................................................5-135 Access Network Identifiers ...............................................................................5-136 Encapsulated Message.......................................................................................5-136 Source PDSN Address.......................................................................................5-137 Session Transfer Information ............................................................................5-137 Session Transfer Abort Cause ...........................................................................5-138 Session State Information Record .....................................................................5-138 Proposed Session State Information Record .....................................................5-139 Extended Session State Information Record .....................................................5-139 AT-ID ................................................................................................................5-140 ConfirmedUATI ................................................................................................5-141 AssignedUATI...................................................................................................5-141 LCM_UATI.......................................................................................................5-141 SLP-D Parameters .............................................................................................5-142 SLP-F Parameters..............................................................................................5-143 Forward QoS Information .................................................................................5-144 Reverse QoS Information ..................................................................................5-145 Subscriber QoS Profile ......................................................................................5-146 Forward QoS Update Information.....................................................................5-146 Reverse QoS Update Information .....................................................................5-147 Session Transfer Reject Cause ..........................................................................5-148 Correlation ID....................................................................................................5-148 Session Transfer Complete Parameters .............................................................5-149 Sequence Number..............................................................................................5-149 Fixed Rate Mode ...............................................................................................5-150 Serving Sector Information ...............................................................................5-150 FL Signal Tunnel Parameter..............................................................................5-151 Sector Endpoint Information .............................................................................5-151 SLP Reset Message SEQ Info ...........................................................................5-152 Assigning SC IP Address ..................................................................................5-152 xvi
A16 Information Element Definitions ......................................................................................5-131
3GPP2 A.S0008-C v2.0

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
5.2.2.34 5.2.2.35 5.2.2.36 5.2.2.37 5.2.3 5.2.3.1 5.2.3.2 5.2.3.3 5.2.3.4 5.2.3.5 5.2.3.6 5.2.3.7 5.2.3.8 5.2.3.9 5.2.3.10 5.2.3.11 5.2.3.12 5.2.3.13 5.2.3.14 5.2.3.15 5.2.3.16 5.2.3.17 5.2.3.18 5.2.3.19 5.2.3.20 5.2.3.21 5.2.3.22 5.2.3.23 5.2.3.24 5.2.3.25 5.2.3.26 5.2.3.27 5.2.3.28 5.2.3.29 5.2.3.30 5.2.3.31 5.2.3.32 5.2.4
Timers................................................................................................................5-153 RTD Information...............................................................................................5-154 Serving Sector ID ..............................................................................................5-154 Target Sector ID ................................................................................................5-155 A17, A18 and A19 Information Element Identifiers.........................................5-156 A17, A18, and A19 Cross Reference of IEs with Messages .............................5-157 Message Type III...............................................................................................5-161 AT-ID ................................................................................................................5-162 Current Session State Information Record ........................................................5-163 Proposed Session State Information Record .....................................................5-164 Alternative Session State Information Record ..................................................5-164 Sector Information.............................................................................................5-165 Correlation ID....................................................................................................5-165 AT Acquired Flag..............................................................................................5-166 RTCH Power Control Setpoint..........................................................................5-166 Deallocation Timer............................................................................................5-167 Power Ramp-Up Bias ........................................................................................5-167 Queue ID Information .......................................................................................5-168 FTCH Packet Served Status ..............................................................................5-169 AT Acquisition Status .......................................................................................5-169 CC Packet Control Information.........................................................................5-170 Air-Interface Signaling Header .........................................................................5-170 RL Application Layer Packet ............................................................................5-171 FL Application Layer Packet.............................................................................5-171 RTCH Packet Control Information ...................................................................5-174 Last Packet ID Served .......................................................................................5-176 Rapid Commit ...................................................................................................5-177 CRC Pass Fail....................................................................................................5-177 AN A17 IPv4 Address.......................................................................................5-177 Neighbor Information........................................................................................5-178 Leg Number.......................................................................................................5-181 AN Leg Information ..........................................................................................5-181 Leg-Sector Association .....................................................................................5-183 RT Leg Information...........................................................................................5-185 Requested Sector Information ...........................................................................5-187 A17 Cause .........................................................................................................5-189 xvii
A17, A18, and A19 Information Element Definitions..............................................................5-156
A21 Information Element Definitions ......................................................................................5-190
3GPP2 A.S0008-C v2.0

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
5.2.4.1 5.2.4.2 5.2.4.3 5.2.4.4 5.2.4.5 5.2.4.6 5.2.4.7 5.2.4.8 5.2.4.9 5.2.4.10 5.2.4.11 5.2.4.12 5.2.4.13 5.2.4.14 5.3 5.3.1
A21 Information Element Identifiers ................................................................5-190 A21 Cross Reference of IEs with Messages......................................................5-190 A21 Message Type............................................................................................5-191 1x LAC Encapsulated PDU...............................................................................5-192 A21 1x Parameters ............................................................................................5-192 Pilot List ............................................................................................................5-192 Correlation ID....................................................................................................5-195 Mobile Identity (MN ID)...................................................................................5-195 Authentication Challenge Parameter (RAND) ..................................................5-196 A21 1x Message Transmission Control ............................................................5-197 A21 Cause .........................................................................................................5-198 A21 Event..........................................................................................................5-198 Service Option...................................................................................................5-201 A21 Mobile Subscription Information ..............................................................5-201
Timer Definitions......................................................................................................................5-204 Timer Descriptions....................................................................................................................5-205 5.3.1.1 5.3.1.2 5.3.1.3 5.3.1.4 5.3.1.5 5.3.1.6 5.3.1.7 5.3.1.8 5.3.1.9 5.3.1.10 5.3.1.11 5.3.1.12 5.3.1.13 5.3.1.14 5.3.1.15 5.3.1.16 5.3.1.17 5.3.1.18 5.3.1.19 Timer TA13req ..................................................................................................5-205 Timer TA13res ..................................................................................................5-205 Timer Tnet_conn ...............................................................................................5-205 Timer TA13rel ...................................................................................................5-205 Timer Tpreq-13 .................................................................................................5-205 Timer TSClose-13 .............................................................................................5-205 Timer TKeepAlive-13 .......................................................................................5-205 Timer Tstreq-16 .................................................................................................5-205 Timer Tstcomp-16 .............................................................................................5-205 Timer Tstack-16 ................................................................................................5-206 Timer Tstrel-16..................................................................................................5-206 Timer Tstabrt-16................................................................................................5-206 Timer Tsigtunnel-16 ..........................................................................................5-206 Timer Tattribupd-16 ..........................................................................................5-206 Timer Tneighbor-17 ..........................................................................................5-206 Timer Tallocreq-17............................................................................................5-206 Timer Tsetattrib-17............................................................................................5-206 Timer Tdeallocreq-17 ........................................................................................5-206 Timer Ttgtdeallocreq-17....................................................................................5-207 xviii
3GPP2 A.S0008-C v2.0

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
5.3.1.20 5.3.1.21 5.3.1.22 5.3.1.23 5.3.1.24 5.3.1.25 5.3.1.26 5.3.1.27 5.3.1.28 5.3.1.29 5.3.1.30 Annex A Annex B Annex C Annex D Annex E
Timer Tmodreq-17 ............................................................................................5-207 Timer Ttgtmodreq-17 ........................................................................................5-207 Timer Twaitacq-17 ............................................................................................5-207 Timer Tacqstatus-19 ..........................................................................................5-207 Timer Tservrtch-19............................................................................................5-207 Timer Tflush-19 ................................................................................................5-207 Timer Tpurge-19 ...............................................................................................5-207 Timer Tack-21 ...................................................................................................5-207 Timer Tparamreq-21 .........................................................................................5-208 Timer Tpage-21 .................................................................................................5-208 Timer Tradioreq-21 ...........................................................................................5-208 Transport Change Text (Normative) .................................................................... A-1 A1/A1p Interface (BS - MSC) Interface Change Text (Normative) .................... B-1 A8-A9 (AN - PCF) Interface Change Text (Normative)...................................... C-1 A10-A11 (AN/PCF - PDSN) Interface Change Text (Normative) ...................... D-1 A12 RADIUS Attributes (Normative).................................................................. E-1
xix
3GPP2 A.S0008-C v2.0

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
Table of Figures
Figure 1.4-1 Figure 1.5-1 HRPD IOS Architecture Reference Model (SC/MM in the AN) ..................................1-12 Packet Data Mobility Architecture for HRPD ...............................................................1-12
Figure 1.12.1-1 Packet Data Session State Transitions ...........................................................................1-18 Figure 1.12.2-1 IP Flow State Transitions...............................................................................................1-19 Figure 2.4-1 RADIUS Protocol Reference Model ...............................................................................2-3 Example Usage of the DTG Tag.......................................................................2-36 Figure 2.7.4.1.3-1
Figure 3.1.1-1 Initial AT Origination with HRPD Session Establishment and Key Exchange...............3-1 Figure 3.1.2-1 Initial AT Origination - Unsuccessful Access Authentication.........................................3-3 Figure 3.2.1-1 Re-authentication of an AT in Dormant State .................................................................3-4 Figure 3.2.2-1 Re-authentication of an AT in Active State .....................................................................3-5 Figure 3.3.1-1 Network Initiated Call Re-activation from Dormant State ..............................................3-6 Figure 3.3.2-1 AT Initiated Call Re-activation from Dormant State (Existing HRPD Session) .............3-7 Figure 3.3.3-1 AT Initiated Packet Data Session Establishment from Established HRPD Session ........3-8 Figure 3.4.1-1 AT Initiated Connection Release .....................................................................................3-9 Figure 3.4.2-1 AN Initiated Connection Release.....................................................................................3-9 Figure 3.5.1-1 AT or AN Initiated HRPD Session Release (A8 Connections Exist)............................3-11 Figure 3.5.2-1 AT or AN Initiated HRPD Session Release (A8 Connections do not Exist).................3-12 Figure 3.5.3-1 HRPD Session Release - Re-authentication of AT Failure (A8 Connections Exist) .....3-13 Figure 3.5.4-1 HRPD Session Release - Re-authentication of AT Failure (A8 Connections do not Exist).................................................................................................................3-14 Figure 3.6-1 PDSN Initiated Packet Data Session Release ................................................................3-16 Figure 3.7.1-1 Inter-PCF/Intra-PDSN Dormant AN-AN HO - Successful Operation ..........................3-17 Figure 3.7.2-1 Inter-PCF/Intra-PDSN Dormant AN-AN HO - Transfer Failure ..................................3-19 Figure 3.8.1-1 Activation /De-activation of Data Flow During Active HRPD Packet Data Session....3-21 Figure 3.9.2.1-1 IP Flow Mapping Update with Service Connection Establishment All New Connections Establishment .......................................................................................................3-22 Figure 3.9.2.2-1 IP Flow Mapping Update with Service Connection Establishment All New Connections Rejected by PCF/PDSN with Existing Connections Sustained............................3-23 Figure 3.9.2.3-1 IP Flow Mapping Update with Service Connection Establishment Partial New Connections Establishment ..................................................................................................3-25 Figure 3.9.2.4-1 IP Flow Mapping Update with Service Connection Establishment Main Connection Rejected by PCF/PDSN ..............................................................................................3-26 Figure 3.9.3-1 IP Flow Mapping Update with Service Connection Release .........................................3-27 Figure 3.9.4-1 IP Flow Mapping Update...............................................................................................3-28 Figure 3.9.5-1 Subscriber QoS Profile Transfer....................................................................................3-29 Figure 3.9.6-1 QoS Update by the PDSN..............................................................................................3-30 Figure 3.10.1.1-1 HRPD DoS from an AT to the PDSN without A13 Procedure ........................3-31 xx
3GPP2 A.S0008-C v2.0

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
Figure 3.10.1.2-1 Figure 3.10.2.1-1 Figure 3.10.2.2-1
HRPD DoS from an AT to the PDSN with A13 Procedure..............................3-32 HRPD DoS from the PDSN to the AT.............................................................3-33 DoS from the PDSN to the AT AN Refuses DoS Request............................3-34
Figure 3.11.1-1 Prior Session Retrieval using Prior Session Attribute ..................................................3-35 Figure 3.11.2-1 Prior Session Removal Procedure.................................................................................3-36 Figure 3.11.3-1 Inter-AN Paging when the AT is in Idle State Successful Scenario ...........................3-38 Figure 3.12.1-1 Intra-PDSN Connected State HRPD Hard Handoff -- Successful Operation................3-43 Figure 3.12.2-1 Connected State HRPD Session Hard Handoff Failure Scenario (Refusal by Target AN) 3-47 Figure 3.12.3-1 Connected State HRPD Hard Handoff TCA Retry Scenario......................................3-49 Figure 3.12.4-1 Connected State HRPD Hard Handoff Failure Scenario (AT Lost) ...........................3-51 Figure 3.12.5-1 Intra-PDSN Connected State HRPD Session Transfer with Cross-Connectivity Support -- Successful Operation ..............................................................................................................3-54 Figure 3.12.5.1-1 Slave AN attaches to sectors in another AN during Connected State HRPD Session Transfer with Cross-Connectivity Support -- Successful Operation...............................3-57 Figure 3.12.5.2-1 Slave AN detaches from a sector in another AN during Connected State HRPD Session Transfer with Cross-Connectivity Support -- Successful Operation...............................3-58 Figure 3.12.5.3-1 Master AN adds new sectors to Active Set during Connected State HRPD Session Transfer with Cross-Connectivity Support -- Successful Operation ..........................................3-59 Figure 3.12.5.4-1 Master AN removes sectors from the Active Set during Connected State HRPD Session Transfer with Cross-Connectivity Support -- Successful Operation...............................3-61 Figure 3.12.5.5-1 Master AN updates Slave AN with the updated Session State Information Records or Serving Sector during Connected-State Session Transfer with Cross-Connectivity Support.....................................................................................................................3-63 Figure 3.12.5.6-1 Slave AN tunnels signaling messages to AT through Master AN during Make-before-break Session Transfer............................................................................................3-63 Figure 3.12.5.7-1 Tunneling of signaling messages from the AT to Slave AN during Make-before-break Session Transfer .......................................................................................................3-64 Figure 3.12.6-1 Data Flow before Make-before-break Session Transfer starts.......................................3-65 Figure 3.12.6-2 Data Flow during Make-before-break Session Transfer................................................3-65 Figure 3.12.6-3 Data Flow after Make-before-break Session Transfer finishes......................................3-65 Figure 3.13.1-1 HRPD Hard Handoff without SLP States Transfer .......................................................3-66 Figure 3.13.2-1 HRPD Hard Handoff with Personality Switch ..............................................................3-67 Figure 3.14.1-1 AT Connection Setup.....................................................................................................3-70 Figure 3.14.2-1 Add Pilot Belonging to Target AN to ATs Active Set .................................................3-73 Figure 3.14.3-1 Drop Pilot Belonging to Target AN from ATs Active Set ...........................................3-75 Figure 3.14.4.1-1 Figure 3.14.4.2-1 Figure 3.14.4.3-1 Graceful Connection Close...............................................................................3-76 Non-Graceful Connection Close: Scenario 1....................................................3-77 Non-Graceful Connection Close: Scenario 2....................................................3-78
Figure 3.14.5-1 Modify Resources at Sector Belonging to Target AN per Source ANs Request..........3-79 Figure 3.14.6-1 Modify Resources at Sector Belonging to Target AN per Target ANs Request ..........3-81 xxi
3GPP2 A.S0008-C v2.0

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
Figure 3.14.7.1-1 Figure 3.14.7.2-1
Serving RT Change: Serving RT Moves to Target AN ....................................3-82 Serving RT Change: Serving RT Moves to Source AN ...................................3-83
Figure 3.14.7.3-1 Serving RT Change: Serving RT Remains in Same Target AN (Different Endpoint ID).....................................................................................................................3-85 Figure 3.14.7.4-1 Serving RT Change: Serving RT Remains in Same Target AN (Same Endpoint ID) .........................................................................................................................3-86 Figure 3.14.7.5-1 Serving RT Change: Serving RT Remains in Same Target AN (Different Endpoint ID), and No Early Detection....................................................................................3-87 Figure 4.1.1-1 1x to HRPD Dormant Packet Data Session HO - Existing HRPD Session .....................4-1 Figure 4.1.2-1 1x to HRPD Dormant Packet Data Session Handoff - New HRPD Session ...................4-3 Figure 4.1.3-1 HRPD to 1x Dormant Packet Data Session Handoff.......................................................4-5 Figure 4.2.1-1 Voice Call Termination During Active HRPD Packet Data Session (Inter-PCF) ...........4-6 Figure 4.2.2-1 Voice Call Termination During Active HRPD Packet Data Session (Intra-PCF) ...........4-8 Figure 4.4-1 Terminal Based Status Management (Using Feature Invocation) .................................4-11 Figure 4.5.1.1-1 Mobile Originated Point-to-Point SMS in an HRPD System IWS-AN......................4-12 Figure 4.5.1.2-1 Mobile Originated Point-to-Point SMS in an HRPD System IWS-1xBS...................4-13 Figure 4.5.2.1-1 Mobile Terminated Point-to-Point SMS without A13 Procedure in an HRPD System IWS-AN........................................................................................................................4-14 Figure 4.5.2.2-1 Mobile Terminated Point-to-Point SMS without A13 Procedure in an HRPD System IWS-1xBS.....................................................................................................................4-14 Figure 4.5.2.3-1 Mobile Terminated Point-to-Point SMS with A13 Procedure in an HRPD System IWS-AN........................................................................................................................4-15 Figure 4.5.2.4-1 Mobile Terminated Point-to-Point SMS with A13 Procedure in an HRPD System IWS-1xBS.....................................................................................................................4-17 Figure 4.5.3.1-1 1x Page Delivery to the MS/AT in an HRPD System without A13 Procedure IWS-AN .......................................................................................................................4-18 Figure 4.5.3.2-1 1x Page Delivery to the MS/AT in an HRPD System without A13 Procedure IWS-1xBS ....................................................................................................................4-19 Figure 4.5.3.3-1 1x Page Delivery to the MS/AT in an HRPD System (Paging Request) from Multiple IWS-1xBSs .......................................................................................................................4-21 Figure 4.5.3.4-1 1x Page Delivery to the MS/AT in an HRPD System with A13 Procedure IWS-AN .......................................................................................................................4-23 Figure 4.5.3.5-1 1x Page Delivery to the MS/AT in an HRPD System with A13 Procedure IWS-1x BS ...................................................................................................................4-24 Figure 4.5.4.1-1 Refusal of a 1x Page Delivery to the MS/AT in an HRPD System without A13 Procedure-IWS-AN.............................................................................................................4-26 Figure 4.5.4.2-1 MS/AT Rejects 1x Page in HRPD System without A13 Procedure IWS-1xBS.........4-27 Figure 4.5.4.3-1 Refusal of a 1x Page Delivery to the MS/AT in an HRPD System with A13 Procedure - IWS-AN........................................................................................................................4-28 Figure 4.5.4.4-1 MS/AT Rejects 1x Page in HRPD System with A13 procedure IWS-1xBS ..............4-29 Figure 4.5.5.1-1 HRPD Page Delivery in a 1x System - MS/AT Idle IWS-AN ...................................4-31 Figure 4.5.5.2-1 HRPD Page Delivery in a 1x System - MS/AT Idle......................................................4-32 xxii
3GPP2 A.S0008-C v2.0

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
Figure 4.5.5.3-1 HRPD Page Delivery in a 1x System - MS/AT Idle MS/AT Rejects HRPD Page IWS-AN ..................................................................................................................4-33 Figure 4.5.5.4-1 HRPD Page Delivery in a 1x System - MS/AT Idle MS/AT Rejects HRPD Page IWS-1xBS............................................................................................................4-34 Figure 4.5.6.1-1 HRPD Page Delivery in a 1x System - MS/AT on TCH - IWS-AN .............................4-35 Figure 4.5.6.2-1 HRPD Page Delivery in a 1x System - MS/AT on TCH IWS-1xBS..........................4-37 Figure 4.5.6.3-1 HRPD Page Delivery in a 1x System - MS/AT on a Traffic Channel MS/AT Rejects HRPD IWS-AN...........................................................................................................4-38 Figure 4.5.6.4-1 HRPD Page Delivery in a 1x System - MS/AT on a Traffic Channel MS/AT Rejects HRPD Page IWS-1xBS...............................................................................................4-39 Figure 4.6.1.1-1 1x Registration Over HRPD IWS-AN ........................................................................4-41 Figure 4.6.1.2-1 1x Registration Over HRPD IWS-1xBS........................................................................4-42 Figure 4.6.2-1 Event Notification From HRPD AN to IWS-1xBS .......................................................4-44 Figure 4.6.3-1 Event Notification From IWS-1xBS to HRPD AN .......................................................4-44 Figure 4.7.1-1 Hard Handoff of a Voice Call From HRPD VoIP to 1x Circuit Service - IWS-1xBS ..4-46 Figure 4.7.2-1 Hard Handoff of a Voice Call From HRPD VoIP to 1x Circuit Service, IWS-AN.......4-49 Figure Annex E-1 Figure Annex E-2 3GPP2 RADIUS Attribute Format .................................................................... E-1 AT Hardware Identifier ..................................................................................... E-1
xxiii
3GPP2 A.S0008-C v2.0

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
Table of Tables
Table 1.7-1 Table 2-1 Table 2.1-1 Element Flow DIRECTION Indication .........................................................................1-13 Terminology Cross Reference between 1x and HRPD....................................................2-1 A1 and A1p Messages Implemented in this Document...................................................2-1
Table 5.2.1.2-1 Cross Reference of IEs with Messages ........................................................................5-112 Table 5.2.1.8-1 Mobile Identity - Type of Identity Coding ..................................................................5-116 Table 5.2.1.28-1 Table 5.2.1.28-2 Data Transfer Types........................................................................................5-130 Target IP Address Type ..................................................................................5-130
Table 5.2.2.2-1 A16 Cross Reference of IEs with Messages ................................................................5-132 Table 5.2.2.4-1 Mobile Identity - Type of Identity Coding ..................................................................5-136 Table 5.2.3.2-1 A17, A18, and A19 Cross Reference of IEs with Messages........................................5-157 Table 5.2.4.2-1 A21 Cross Reference of IEs with Messages ................................................................5-190 Table 5.2.4.8-1 Mobile Identity - Type of Identity Coding ..................................................................5-196 Table 5.2.4.9-1 Authentication Challenge Parameter - Random Number Type ...................................5-197 Table 5.2.4.12-1 Table 5.2.4.12-2 Table 5.2.4.13-1 Table 5.2.4.14-1 Table 5.2.4.14-2 Event Values ...................................................................................................5-199 Additional Event Info Values .........................................................................5-200 Service Option Values ....................................................................................5-201 Record Identifier Values .................................................................................5-202 Band Class/Band Subclass Record (Record Identifier = 00H) .......................5-202
xxiv
3GPP2 A.S0008-C v2.0
1 2 3 4 5 6 7 8 9
Foreword
The foreword is informational. While based on [11]~[17], the interface specifications defined in this document are compatible with an Interoperability Specification (IOS) v4.0 or higher release (refer to [11]). This document describes the interface protocols and procedures to support the High Rate Packet Data (HRPD) IOS features listed in section 1.1. Refer to section 1.6 for clarification of this specifications reuse of 1x IOS transport requirements and interface definitions in relation to the revision marks contained in Annex A through Annex D. Revision History Date July 2007 January 2009 Publication Description
A.S0008-C v1.0 For features and enhancements supported, refer to section 1.1. A.S0008-C v2.0 Bug fix/additions including: Disconnect-Request, AltPPP support, CM Service Request Type (to differentiate 1x access vs. transfer from HRPD to 1x), A8 release reason indication, A21 enhancements (radio update handling, new event/cause values), partial connection establishment, inclusion of RTD information and Serving and Target Sector ID in the A16-Session Transfer Request message, HRPD Emergency Indicator and general message/parameter clean.
10 11
xxv
3GPP2 A.S0008-C v2.0

1 2 3 4 5
(This page intentionally left blank)
xxvi
3GPP2 A.S0008-C v2.0
1 2
1 Introduction
1.1 Overview
3 4 5 6 7
This document includes a description of the interface protocols and procedures to support the following features and functions. Conformance to this standard may be claimed on a feature by feature and/or interface by interface basis. If conformance on a given interface is claimed for a feature, it shall be supported as defined in this standard. New features and enhancements supported in this release: Circuit Services Notification Application (CSNA) over A21 Packet Data Serving Node (PDSN) initiated IP flow release Inter-Access Network (AN) paging when the Access Terminal (AT) is in idle state Long Code Mask Unicast Access Terminal Identifier (LCM_UATI) keep alive over A13 interface High Rate Packet Data (HRPD) Inter-AN Session transfer with cross-connectivity (including makebefore-break) AltPPP HRPD Emergency Indicator Emergency call Features and functions explicitly supported in this standard: AT (Access Terminal) originates an HRPD session (including access authentication) Re-authentication of an AT HRPD data delivery (both AT terminated and AT originated) HRPD connection release HRPD session release Dormant handoff of HRPD AT between ANs served by the same Packet Data Serving Node (PDSN) Dormant 1x handoff to/from HRPD, served by the same PDSN Voice call delivery during active HRPD data session 1x to HRPD packet data session handoff Loss of the airlink during an active HRPD session Status Management supported by feature invocation HRPD-1x cdma2000 1 Circuit Services Notification Application Multiple personalities in the session configuration protocol Packet Application supporting multiple link flows and Quality of Service Data Over Signaling (DoS) GRE Segmentation QoS update by the PDSN RObust Header Compression (ROHC) on SO67 HRPD Inter-AN connected state session transfer (hard handoff)
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
cdma2000 is the trademark for the technical nomenclature for certain specifications and standards of the Organizational Partners (OPs) of 3GPP2. Geographically (and as of the date of publication), cdma2000 is a registered trademark of the Telecommunications Industry Association (TIA-USA) in the United States.
1-1
3GPP2 A.S0008-C v2.0

1 2 3 4 5 6 7 8 9 10 11 12 13
HRPD Inter-AN cross-connectivity 1x calling party number presentation Reservation label in HRPD service option when paging on 1x Hard handoff of a VoIP call from HRPD to 1x circuit voice call Prior session release CSNA over A21 PDSN initiated IP flow release Inter-AN paging when the AT is in idle state LCM_UATI keep alive over A13 interface HRPD Inter-AN Session transfer with cross-connectivity (including make-before-break) AltPPP HRPD Emergency Indicator Emergency call
14 15 16 17
Features and functions transparently supported in this standard: ROHC over PPP Note: Fast Handoff is not supported in this version of the standard. 1.1.1 Purpose
18 19 20
The purpose of this document is to provide a standard and call flows for the IOS HRPD interfaces within the Radio Access Network (RAN). 1.1.2 Scope
21
22 23 24 25
This document provides an interoperability specification for a RAN that supports HRPD. The RAN architecture in this document logically locates the Session Control and Mobility Management (SC/MM) function in the Access Network (AN). This document contains message procedures and formats necessary to obtain this interoperability. 1.1.3 Document Convention
26 27 28 29 30 31 32 33 34 35
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. In the Annexes that show deltas relative to the base documents [11]~[17], underscore indicates additions, strikeout indicates deletions, and an ellipsis () indicates that the base document is unchanged.
36 37
1.2
References
38 39 40
1.2.1
Normative References
For consistency between RAN specifications, the most commonly referenced documents [1~17] are maintained or left as Reserved if not used in this specification.
1-2
3GPP2 A.S0008-C v2.0

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
[1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20] [21] [22] [23] [24]
3GPP2: C.S0001-D v2.0, Introduction to cdma2000 Standards for Spread Spectrum Systems, September 2005. 3GPP2: C.S0002-D v2.0, Physical Layer Standard for cdma2000 Spread Spectrum Systems, September 2005. 3GPP2: C.S0003-D v2.0, Medium Access Control (MAC) Standard for cdma2000 Spread Spectrum Systems, September 2005. 3GPP2: C.S0004-D v2.0, Signaling Link Access Control (LAC) Standard for cdma2000 Spread Spectrum Systems, September 2005. 3GPP2: C.S0005-D v2.0, Upper Layer (Layer 3) Signaling Standard for cdma2000 Spread Spectrum Systems, September 2005. 3GPP2: C.S0006-D v2.0, Analog Signaling Standard for cdma2000 Spread Spectrum Systems, September 2005. Reserved. 3GPP2: X.S0011-D v1.0, Wireless IP Network Standard, March 2006. 3GPP2: C.S0082-0 v1.0, Circuit Services Notification Application Specification for cdma2000 High Rate Packet Data, August 2006. 3GPP2: C.S0024-B v2.0, cdma2000 High Rate Packet Data Air Interface Specification, March 2007. 3GPP2: A.S0011-C v2.0, Interoperability Specification (IOS) for cdma2000 Access Network Interfaces Part 1 Overview, December 2005. 3GPP2: A.S0012-C v2.0, Interoperability Specification (IOS) for cdma2000 Access Network Interfaces Part 2 Transport, December 2005. 3GPP2: A.S0013-C v2.0, Interoperability Specification (IOS) for cdma2000 Access Network Interfaces Part 3 Features, December 2005. 3GPP2: A.S0014-C v2.0, Interoperability Specification (IOS) for cdma2000 Access Network Interfaces Part 4 (A1, A1p, A2, and A5 Interfaces), December 2005. 3GPP2: A.S0015-C v2.0, Interoperability Specification (IOS) for cdma2000 Access Network Interfaces Part 5 (A3 and A7 Interfaces), December 2005. 3GPP2: A.S0016-C v2.0, Interoperability Specification (IOS) for cdma2000 Access Network Interfaces Part 6 (A8 and A9 Interfaces), December 2005. 3GPP2: A.S0017-C v2.0, Interoperability Specification (IOS) for cdma2000 Access Network Interfaces Part 7 (A10 and A11 Interfaces), December 2005. 3GPP2: C.R1001-E v1.0, Administration of Parameter Value Assignments for cdma2000 Spread Spectrum Standards, September 2005. 3GPP2: C.S0075-0 v1.0, Interworking Specification for cdma2000 1x and High Rate Packet Data Systems, February 2006. 3GPP2: C.S0063-A v1.0, cdma2000 High Rate Packet Data Supplemental Services, April 2006. 3GPP2: C.S0057-B v1.0, Band Class Specification for cdma2000 Spread Spectrum Systems, August 2006. 3GPP2: C.S0017-A v1.0, Data Service Options for Spread Spectrum Systems, July 2004. 3GPP2: X.S0049-0 v1.0, All-IP Network Emergency Call Support, February 2008. IETF: RFC 768, User Datagram Protocol, August 1980. 1-3
43
3GPP2 A.S0008-C v2.0

1 2 3 4 5 6 7 8 9 10 11 12
[25] [26] [27] [28] [29] [30] [31] [32] [33]
IETF: RFC 793, Transmission Control Protocol, September 1981. IETF: RFC 1661, Point-to-Point Protocol, July 1994. IETF: RFC 1662, PPP in HDLC-Like Framing, July 1994. IETF: RFC 1750, Randomness Recommendations for Security, December 1994. IETF: RFC 1994, PPP Challenge Handshake Authentication Protocol (CHAP), August 1996. IETF: RFC 2486, The Network Access Identifier, January 1999. IETF: RFC 2865, Remote Authentication Dial In User Service (RADIUS), June 2000. IETF: RFC 3095, RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed, July 2001. IETF: RFC 3115, Mobile IP Vendor/Organization-Specific Extensions, April 2001.
13 14 15 16 17 18
1.2.2 [34] [35] [36]
Informative References IETF: RFC 2002, IP Mobility Support, October 1996. IETF: RFC 3241, Robust Header Compression (ROHC) over PPP, April 2002. IETF: RFC 3759, RObust Header Compression (ROHC): Terminology and Channel Mapping Examples, April 2004.
19 20
1.3
Terminology
21
1.3.1 3GPP2 AAA ACCM ADDS AltPPP AN ANID AT BLOB BS CANID CC CHAP CID CSNA CVSE DoS DRI
Acronyms 3rd Generation Partnership Project 2 Authentication, Authorization and Accounting Async-Control-Character-Map Application Data Delivery Service Alternative PPP Access Network Access Network Identifiers Access Terminal BLock Of Bits Base Station Current Access Network Identifiers Common Control Challenge Handshake Authentication Protocol Context IDentifier Circuit Services Notification Application Critical Vendor/Organization Specific Extension Data Over Signaling Data Ready Indicator 1-4
3GPP2 A.S0008-C v2.0 DTG ESSIR FN GPM GRE HRPD IE IMSI IOS IP IWS IWS-1xBS IWS-AN LCM LCP MAC MEI MEID MN ID MRRU MS MSC MSCe NAI NID NVSE PANID PCF PDSI PDSN PPP PZID QoS RADIUS RAN RLP ROHC RT SC/MM SDB SID SLP SMS SSIR Data Transmission Group Extended Session State Information Record Feature Notification General Page Message Generic Routing Encapsulation High Rate Packet Data Information Element International Mobile Subscriber Identity Interoperability Specification Internet Protocol Interworking Solution IWS collocated in the 1x BS IWS collocated in the HRPD AN Long Code Mask Link Control Protocol Medium Access Control Mobility Event Indicator Mobile Equipment Identity Mobile Node Identification Maximum Reconstructed Reception Unit Mobile Station Mobile Switching Center Mobile Switching Center Emulation Network Access Identifier Network Identification Normal Vendor Specific Extension Previous Access Network Identifiers Packet Control Function Packet Data Service Instance Packet Data Serving Node Point-to-Point Protocol Packet Zone Identification Quality of Service Remote Authentication Dial-In User Service Radio Access Network Radio Link Protocol RObust Header Compression Radio Transceiver Session Control / Mobility Management Short Data Burst System Identification Signaling Link Protocol Short Message Service Session State Information Record 1-5
3GPP2 A.S0008-C v2.0 TCA TCH UATI VoIP VPI VSA

1
Traffic Channel Assignment Traffic Channel Unicast Access Terminal Identifier Voice over Internet Protocol Virtual Page Indicator Vendor Specific Attribute
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
1.3.2 1x
Definitions Refer to cdma2000 1x. A procedure in which the Access Terminal (AT) is authenticated by the ANAAA (Access Network Authentication, Authorization and Accounting entity). A stream to which a packet application bound to an access network is attached. Access stream is used for access authentication. A logical entity in the Radio Access Network (RAN) used for radio communications with the AT. An AN contains one or more RTs and is equivalent to a base station (BS) in 1x systems. In addition, the AN for this specification logically contains the SC/MM function. Refer to the definition of SC/MM function. A device providing data connectivity to a user. An AT 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 AT is equivalent to a mobile station in 1x systems. An entity that performs access authentication functions for the RAN. ROHC where compression and decompression are performed in the AN. ROHC channels for AN-Based ROHC terminate in the AT and AN. The version of cdma2000 defined by [1]~[6] and also supported by [11]~[17]. The MSC provides signaling capability via an SS7-based connection to the AN on the A1 interface. The A2 interface may be used to connect with the IWS function. Connected State Session Transfer is the process of transferring the session of an AT from one AN to another AN. Connected State Session Transfer can either be without cross-connectivity support (i.e., hard handoff) or with cross-connectivity support.
Access Authentication
Access Stream Access Network
Access Terminal
AN-AAA AN-Based ROHC cdma2000 1x Circuit-Switched MSC
Connected State Session Transfer
Connection
A connection, in this specification, refers to either an air interface connection or a signaling or user traffic connection in the RAN. An air interface 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 AT and the AN can open and can close a connection multiple times. A signaling or user traffic connection is a particular state shared between two nodes in the RAN or between a node in the RAN and a network entity outside the RAN. Examples of a connection in the RAN are A8 and A10 connections, which are used for user traffic. 1-6
3GPP2 A.S0008-C v2.0

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 48 49
Flow ID Flow Profile ID Forward ROHC Channel
An identifier which, combined with a direction, uniquely identifies an IP flow for an AT. An identifier of the service needs for an application flow. Refer to [18]. A unidirectional compressor/decompressor pair (refer to [32]) that sends ROHC packets from PDSN or AN to AT. The compressor transforms original packets into ROHC packets. The QoS Sub BLOB (Block of Bits) containing the QoS granted for a given IP flow. Refer to [8] and [10]. A handoff characterized by a temporary disconnection of the Traffic Channel. Hard handoffs occur when the AT is transferred between disjoint Active Sets, or when the Frequency Assignment changes. Area that is serviced by one HRPD PCF. An HRPD session refers to a shared state between the AT and the AN. This shared state stores the protocols and protocol configurations that were negotiated and are used for communications between the AT and the AN. Other than to open a session, an AT cannot communicate with an AN 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 section 1.12 and [10]. A unidirectional bearer traffic flow identified by a particular pair of source and destination IP addresses and port numbers. An IP flow is identified by the Flow ID and direction. Interworking Solution (IWS) Function is logically collocated at the 1x BS or the AN, or as a standalone entity. In this standard the term IWS is used without regard to the location of the IWS. When it is necessary to make a distinction with regard to the location of the IWS, that is explicitly stated. IWS provides the following functions: Message Translation: This function translates between IOS A1/A1p messages received from/sent to a Mobile Switching Center (MSC) and 1x air interface signaling messages sent/received over the HRPD air interface. 1x Parameters Storage: This function stores 1x radio parameters required for CSNA support. 1x PN Offset and BTS Cell ID Mapping: This function enables to map a pair of 1x PN pilot information and HRPD sector information into BTS Cell ID. RAND Generation: This optional function provides the RAND used for 1x authentication. This function may be in the HRPD AN. When several nodes in the RAN have this function, the RAND value provided by the IWS is used. If the AT is in Connected State, LCM_UATI is the UATI that the Reverse Traffic Channel Long Code Mask (refer to [10]) is built upon. This term is also used in this document to mean the last confirmed UATI which the AT has accessed the AN, if the AT is in Idle State. A value representing one or more sectors in the active set belonging to the same RT. Unidirectional data flow over the air interface. Refer to RLP (Radio Link Protocol) Flow. Refer to [20] or [10]. 1-7
Granted QoS Sub BLOB Hard Handoff
HRPD Packet Zone HRPD session
IP Flow
IWS Function
LCM_UATI
Leg Number Link Flow
Make-before-break Session Transfer
3GPP2 A.S0008-C v2.0

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 48 49
Make-before-break session transfer procedure allows data to flow throughout the Connected State Session Transfer process by adding a separate application-layer data (such as RLP) route through the target AN before tearing down the original route in the source AN. At any given time, only a single AN may control the session of the AT and process signaling messages. Cross-connectivity support and packet application that supports multiple application-layer data routes are required for make-before-break session transfer. Master AN The master AN is an operational state of the AN during Connected State Session Transfer with cross-connectivity support. When an AN becomes a master AN, it controls the session and also holds the state associated with airinterface signaling protocols. The MSC switches MS/AT-originated or MS/AT-terminated traffic. An MSC connects to one or more ANs . It may connect to other public networks (PSTN, ISDN, etc.), other MSCs in the same network, or MSCs in different networks. (It has been referred to as Mobile Telephone Switching Office, MTSO.) It provides the interface for user traffic between the wireless network and other public switched networks, or other MSCs. In this document, for signaling, the term MSC refers to either a circuitswitched MSC or a Mobile Switching Center Emulation (MSCe). In situations where a statement applies to either the circuit-switched or packetbased MSC exclusively, the type of MSC will be specifically identified (i.e. circuit-switched MSC or MSCe). MSC Emulation (MSCe) The MSCe provides processing and control for calls and services. The MSCe provides signaling capabilities equivalent to a circuit-switched MSC on the A1p interface. The MSCe connects to an AN via IP based protocols. A hybrid device capable of operating on both 1x and HRPD systems. The values of the ROHC configuration parameters negotiated by the AN for a particular ROHC Channel for PDSN-based ROHC. The negotiated ROHC parameter values are sent to the PDSN upon establishment of the ROHC channel. Packet Control Function An entity in the radio access network that manages the relay of packets between the AN and the PDSN.
Mobile Switching Center
MS/AT
Negotiated ROHC Parameter Values
Packet Data Serving Node An entity that routes AT originated or AT terminated packet data traffic. A PDSN establishes, maintains and terminates link layer sessions to ATs. 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 also to [11] definitions. ROHC where compression and decompression are performed in the PDSN. ROHC channels for PDSN-Based ROHC terminate in the AT and PDSN. An object formatted as specified in [8] containing QoS attribute sets or QoS Profile IDs. The network entities providing data connectivity between the packet switched data network (typically the Internet) and the AT. The RAN may be divided into the following logical entities: ANs, AN-AAAs, and PCFs. The interfaces between these entities, the interfaces between the PCF and the 1-8
PDSN-Based ROHC QoS Sub BLOB Radio Access Network
3GPP2 A.S0008-C v2.0

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
Packet Data Serving Node (PDSN), and the interfaces between the AN and the Mobile Switching Center (MSC) are considered parts of the RAN. Refer to section 1.4. Requested QoS Sub BLOB The QoS Sub BLOB containing the QoS requested by an MS/AT for a given IP flow. Refer to [8] and [10]. Reservation Reservation Label Reverse ROHC Channel Air interface resources needed to carry an IP flow. Refer to [10] or [20]. An identifier, which combined with a direction, uniquely identifies a reservation for an AT. Reservation labels are also used as Flow IDs. A unidirectional compressor/decompressor pair (refer to [32]) that sends ROHC packets from AT to PDSN or AN. The compressor transforms original packets into ROHC packets. Unidirectional data flow over the air interface. This specification refers to this as Link flow. Refer to [10]. A protocol defined by IETF (refer to [32], [35]). Unless otherwise specified, ROHC in this document refers to ROHC on SO67. For example, negotiated ROHC parameter values do not apply to ROHC over PPP (refer to [32]). A unidirectional compressor/decompressor pair (refer to [32]). In this document, a ROHC Channel may be a Forward ROHC Channel or a Reverse ROHC Channel. One A8/A10 connection, which is bidirectional, may carry one Forward ROHC Channel, or one Reverse ROHC Channel, or one Forward and one Reverse ROHC Channel. Mandatory parameters that have the same values at both compressor and decompressor of a ROHC channel. In this document, this term refers to the MAX_CID, LARGE_CIDS, PROFILES, and MRRU. The parameter FEEDBACK_FOR is not used in this document. Refer to [32]. ROHC on SO67 ROHC over PPP RT The capability to associate ROHC channels with A8/A10 connections having service option 67. The capability to associate ROHC channels with A8/A10 connections having service option 59 or 64. A Radio Transceiver (RT) is a component of an AN comprising a collection of sectors that transmit the same power control command to an AT. An RT is also referred to as a cell on the air interface (refer to [10]). SC/MM (Session Control and Mobility Management) is logically located in the AN and includes the following functions: Storage of HRPD session related information: This function keeps HRPD session related information (e.g., Keep Alive timer, MNID, mapping between MNID and UATI, etc.) for dormant ATs. Assignment of UATI (Unicast AT identifier): This function assigns a new UATI to an AT. Access Authentication: This function performs the access authentication procedure. This function judges whether an AT should be authenticated or not when the AT is accessing the HRPD RAN. The SC/MM performs Point-to-Point Protocol (PPP) procedures for access authentication. Mobility Management: This function manages the location of an AT. 1-9
RLP Flow ROHC
ROHC Channel
ROHC Configuration Parameters
SC/MM function:
3GPP2 A.S0008-C v2.0

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
Service Connection
A bidirectional logical connection between the AT and PDSN that may persist for the life of the PPP session. A service connection is identified by the SR_ID 2 and has an associated service option value. A service connection may be mapped to a unique forward air interface link flow, reverse air interface link flow, A8 connection and A10 connection associated with the AT at any given time. PPP signaling is carried over the main service connection, which is associated with the main A8/A10 connection. Auxiliary service connections may be established as needed. Every IP flow is associated with a service connection. The HRPD stream used when exchanging data between the AT and the PDSN. Refer to [10]. The RT that contains the serving sector. Refer to [10]. Session Transfer with cross-connectivity support is a Connected State Session Transfer process where both the source AN and the target AN can cross-connect to the current Active Set. Make-before-break Session Transfer is Session Transfer with cross-connectivity support which utilizes two routes.
Service Stream Serving RT
Session Transfer with cross-connectivity support
Slave AN
The slave AN is an operational state of the AN during Connected State Session Transfer with cross-connectivity support. When an AN is involved in Connected State Session Transfer with a master AN, it becomes a slave AN. Identifier of a service connection. SR_ID 1 identifies the main service connection. The set of sectors that advertise the same subnet mask and for which the AND operation performed on the Sector ID and the subnet mask results in the same value. A subnet is intended to allow the network to define the boundary at which an idle AT is required to access the system. Refer to [10]. The set of QoS-related information sent from the PDSN that the RAN uses to authorize QoS requests for a given subscriber. Refer to [8].
SR_ID Subnet
Subscriber QoS Profile
30 31 32 33 34 35 36 37 38 39 40 41 42 43
1.4
A1
HRPD IOS Architecture Reference Model (SC/MM in the AN)

The A1 interface carries signaling information between the call control and mobility management functions of the circuit-switched MSC and the IWS function. For A1 descriptions, refer to section 2.1. A1 interface changes required for HRPD are specified in Annex B. The A1p interface carries signaling information between the call control and mobility management functions of the MSCe and the IWS function. It is recommended that the A1p interface, instead of the A1 interface, be applied for interworking between the 1x and HRPD systems. For A1p descriptions, refer to section 2.1. A1p interface changes required for HRPD are specified in Annex B. The A8 interface carries user traffic between the Access Network (AN) and the Packet Control Function (PCF). For A8 descriptions, refer to section 2.2. A8 interface changes required for HRPD are specified in Annex C.
The interfaces defined in this specification are described as follows.
A1p
A8
There are some situations where the SR_ID of the service connection may change; e.g., upon a failed inter-PCF session transfer.
1-10
3GPP2 A.S0008-C v2.0

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
A9
The A9 interface carries signaling information between the AN and the PCF. For A9 descriptions, refer to section 2.2. A9 interface changes required for HRPD are specified in Annex C. The A10 interface carries user traffic between the PCF and the PDSN. For A10 descriptions, refer to section 2.3. A10 interface changes required for HRPD are specified in Annex D. The A11 interface carries signaling information between the PCF and the PDSN. For A11 descriptions, refer to section 2.3. A11 interface changes required for HRPD are specified in Annex D. The A12 interface carries signaling information related to access authentication between the SC/MM function in the AN and the AN-AAA (Authentication, Authorization and Accounting entity). For a description of the A12 interface, refer to section 2.4. The A13 interface carries signaling information between the SC/MM function in the source AN and the SC/MM function in the target AN for dormant state session transfer and inter-AN paging when the AT is in idle state. For a description of the A13 interface, refer to section 2.5. The A16 interface carries signaling information between the source AN and the target AN for HRPD Inter-AN Connected State Session Transfer (hard handoff or with crossconnectivity support). For a description of the A16 interface, refer to section 2.6. The A17 interface carries signaling information between a source AN and a target AN to manage resources in support of inter-AN cross-connectivity (soft/softer handoff). The A17 interface establishes dedicated endpoints for the A18 and A19 interfaces. Additionally, the A17 interface tunnels air interface forward control channel signaling messages from the source AN to a target AN that has sectors in the ATs Active Set to be transmitted to the AT. For a description of the A17 interface, refer to section 2.7. The A18 interface transports user traffic (i.e., air interface traffic channel data) for an AT between the source AN and a target RT during cross-connectivity. The A18 interface endpoints are set up using the A17 interface. For a description of the A18 interface, refer to section 2.7. The A19 interface carries RT-specific bearer-related cross-connectivity control messages for an AT between the source AN and a target RT. The A19 interface endpoints are set up using the A17 interface. For a description of the A19 interface, refer to section 2.7. The A21 interface carries signaling information between the HRPD AN and the IWS. For a description of the A21 interface, refer to section 2.8. The A24 interface carries buffered user data from the source AN to the target AN for an AT, during A13 session transfer. The target AN interface endpoint is transmitted to the source AN in the A13-Session Information Request message. Refer to section 2.9.
A10
A11
A12
A13
A16
A17
A18
A19
A21 A24
The HRPD IOS messaging and call flows are based on the Architecture Reference Model shown in Figure 1.4-1. In Figure 1.4-1, solid lines indicate signaling and bearer and dashed lines indicate only signaling.
1-11
3GPP2 A.S0008-C v2.0

IW S F un ction 1x B S
A 1 /A 1 p
A 1/A 1p
IW S F unction
A 21
A 21
M S C /M S C e
A 1 /A 1 p
IW S F un ction S ource A N S C /M M F unction

A8 A9 A12 A10
PCF
PDSN
A 11
A ir Interface
AT
A 1 3 A 16 A 1 7
A 18 A 1 9
A24
AN AAA
S C /M M F un ction T arget A N
1 2
RT
Figure 1.4-1
HRPD IOS Architecture Reference Model (SC/MM in the AN)
3 4 5 6 7 8 9
Note: The IWS Function may be collocated at either the 1x BS or at the HRPD AN, or may be a standalone entity. When the IWS function is collocated at the 1x BS, the A21 interface is supported between the 1x BS and the HRPD AN, and the A1/A1p interface is supported between the MSC and the 1x BS. When the IWS function is part of the HRPD AN, the A1/A1p interface between the MSC and the HRPD AN exists, and the A21 interface is internal to the HRPD AN. When the IWS is a standalone entity, the A1/A1p interface is supported between the MSC and the IWS, and the A21 interface is supported between the IWS and the HRPD AN.
10 11
1.5
HRPD Micro-Mobility and Macro-Mobility Concepts
The figure below provides a conceptual view of levels of HRPD packet data mobility.
Home Agent Mobility between PDSNs (Mobile IP) PDSN PDSN Mobility between PCFs (A10/A11 Interfaces) PCF Mobility between ANs (A8/A9 Interfaces) AN AN
PCF
PCF
AN
12 13
AN
Figure 1.5-1
Packet Data Mobility Architecture for HRPD
14 15 16
The A8/A9 interfaces support mobility between ANs under the same PCF. The A10/A11 interfaces support mobility between PCFs under the same PDSN. Mobile IP supports mobility between PDSNs under the same Home Agent, as specified in [34].
17 18 19
1.6
Compatibility with IOS Standards
The HRPD IOS architecture reference model in section 1.4 includes the following interfaces that also exist in the 1x architecture reference model (refer to [11]): A1/A1p, A8/A9, and A10/A11. To the extent 1-12
3GPP2 A.S0008-C v2.0

1 2 3 4 5 6
possible, this specification reuses the 1x IOS transport requirements and interface definitions for these interfaces. Some changes are required for these interfaces to work when used in HRPD systems. For example, HRPD service option values are different from 1x service option values. The 1x IOS version specified in [11]~[17] are used as the base documents for this specification. The [12], [14], [16] and [17] changes required for HRPD are shown in Annex A through Annex D as delta (i.e., revision marked) text relative to the 1x IOS version of the base documents
7 8 9 10 11 12 13 14 15 16 17 18 19
1.7
Message Body, Coding, Ordering, and Interpretation of Elements
For interfaces common to 1x, the guidelines in the base 1x text apply. Refer to Annexes for more information. For each HRPD IOS-unique interfaces message, there are a number of information elements that are individually defined in section 5.2. In section 5.1, each information element in a given message is tagged with a reference, a direction indication (i.e., some elements within a message are bi-directional and others are not), and a mandatory/optional type (M/O) indicator. Information elements that are marked as optional carry an additional indication of being either required (R) or conditional (C) (refer to below). Some information elements are reused in multiple messages. The DIRECTION indication associated with each information element pertains to the use of that particular information element when used with the particular message (i.e., use of the information element may be different in other messages). The format of the DIRECTION indication is as follows: Table 1.7-1 Source -> Target Target -> Source Element Flow DIRECTION Indication Element flows from the Source to the Target Element flows from the Target to the Source
20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43
The inclusion of information elements in each message is specified as follows: M Information elements which are mandatory for the message. O Information elements which are optional for the message. R Required in the message whenever the message is sent. C Conditionally required. The conditions for inclusion of this element are defined in the operation(s) where the message is used and in footnotes associated with the table defining the order of information elements in the message. Information elements which are mandatory for a given message shall be present, and appear in the order shown in the message definitions in this chapter. Information elements which are optional for a given message are included as needed for specific conditions. When included, they shall appear in the order shown in the message definition given in this chapter. An information element may be mandatory for some messages and optional for other messages. The following conventions are assumed for the sequence of transmission of bits and bytes: Each bit position is marked as 0 to 7. For HRPD IOS-unique interfaces, bit 0 is the least significant bit and is transmitted first. In a message, octets are identified by number. Octet 1 is transmitted first, then octet 2, etc. For variable length elements, a length indicator is included. This indicates the number of octets following in the element. Information elements shall always use the same Information Element Identifier for all occurrences on a specific HRPD interface. Insofar as possible, the same Information Element Identifier shall be used for a given information element when it is used on more than one interface. 1-13
3GPP2 A.S0008-C v2.0

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
For future expansion purposes, some of these information elements have fields within them that have been reserved. All reserved bits are set to 0, unless otherwise indicated. To allow compatibility with future implementation, messages shall not be rejected simply because a reserved bit is set to 1. The bitmap tables in the message subsections of section 5.1 are patterned after the format for the information elements of section 5.2 and use the following conventions: Element Name{<# instances>: = Name of information element. Different elements within a message are separated by double lines. Fields within elements are separated by single lines. Octets are renumbered at the beginning of every element. [<values>] = Set of allowed values. The number of instances of an element is 1 by default. If the Element Name{<# instances }Element Name notation is used, the <# instances> notation indicates: n = exactly n occurrences of the element n+ 1..n label {<# instances>: <octet 1> <octet m> } label = Number of instances of the bracketed set of fields where <# instances> notation indicates: n = exactly n occurrences of the field n+ 1..n ssss ssss ssss ssss = Variable length field. = n or more occurrences of the field = 1 to n inclusive occurrences of the field = n or more occurrences of the element = 1 to n inclusive occurrences of the element } Element Name
31 32 33 34 35 36 37 38 39 40 41
1.8
Forward Compatibility Guidelines
This standard is intended to evolve to accommodate new features and capabilities. To ensure that equipment implemented to one revision level interoperates with equipment implemented to later revision levels, the following guidelines are defined for the processing of messages and for the development of messages in future revisions of this standard. Unexpected signaling information may be received at an entity due to differing revision levels of signaling protocol at different entities within a network: an entity using a more enhanced version of the protocol may send information to an entity implemented at a lower level of the protocol which is outside the protocol definition supported at that receiving entity. It may happen that an entity receives unrecognized signaling information, i.e., messages, element types or element values. This can typically be caused by the upgrading of the protocol version used by other 1-14
3GPP2 A.S0008-C v2.0

1 2 3 4 5 6 7 8 9 10 11 12
entities in the network. In these cases the following message processing guidelines are invoked to ensure predictable network behavior. The sending entity shall send messages that are correctly formatted for the version of the IOS implemented by the sending entity. For the A11 interface, to preserve the interoperability between a PDSN and a PCF that have different IOS versions, the use of two element types for the Vendor/Organization Specific Extension element is required, starting with IOS version 4.1. The two types of Vendor/Organization Specific Extension elements i.e., the Critical Vendor/Organization Specific Extension (CVSE) and the Normal Vendor/Organization Specific Extension (NVSE) are defined in [33] where each CVSE/NVSE has a 16 bit application type associated with it. This standard further defines the 16-bit application type as an 8-bit application type and an 8-bit application sub type. Also, the CVSEs/NVSEs introduced in this standard set the Vendor ID to the Internet Assigned Number Authority (IANA) registered 3GPP2 vendor ID.
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
1.9
Message Processing Guidelines
The following message processing guidelines apply to HRPD IOS-unique interfaces unless overridden by explicit processing directions in other places within this standard. In the guidelines in this section, optional includes both optional conditional and optional required information elements as indicated in the message tables in section 5.1. 1. If a message is received containing a Message Type value which is not defined for the revision level implemented then the message shall be discarded and ignored. There shall be no change in state or in timers due to receipt of an unknown message. 2. If a message is received without an expected mandatory information element for the revision level implemented then the message shall be discarded and ignored. There shall be no change in state or in timers due to receipt of the message. 3. If a message is received that contains an information element which is defined for the revision level implemented but contains invalid values in some fields, these fields shall be ignored and the remainder of the information element processed to the extent possible. The message and all other information elements shall be processed to the extent possible. Failure handling may be initiated if call processing cannot continue. Also refer to message processing guidelines 9 and 10. 4. If a message is received that contains an Information Element Identifier which is not defined for the revision level implemented then that element shall be discarded and ignored. The message shall be processed to the extent possible. Failure handling may be initiated if call processing cannot continue. 5. If a known but unexpected optional information element is received, that information element shall be ignored. The message and all other information elements shall be processed. 6. If a message is received without an expected optional information element the message shall be processed to the extent possible. Failure handling may be initiated if call processing cannot continue. 7. If a field within a received information element contains a value which is specified as reserved or is otherwise not defined in the revision level implemented, this field shall be ignored and the remainder of the information element processed to the extent possible. In this situation, all other information elements shall be processed to the extent possible. 8. Octets and bits designated as Reserved or which are undefined for the revision implemented shall be set to zero by a sending entity and ignored by a receiving entity even if the value is nonzero. 9. If an element is received containing a field that is larger than expected, i.e., is indicated as having more bits/octets than expected, then the expected bits/octets of that field shall be processed to the extent possible and the additional bits/octets shall be ignored. 10. If an element is received containing a field that is smaller than expected, i.e., is indicated as having fewer bits/octets than expected, then the length field or other indicator shall be considered correct and
1-15
3GPP2 A.S0008-C v2.0

1 2 3 4 5 6 7 8 9 10
the bits/octets actually present in the element shall be processed to the extent possible. Failure handling may be initiated if call processing cannot continue. 11. For the A11 interface, if a receiving entity receives a CVSE that contains an unrecognized application type/application sub-type the receiving entity shall reject the message containing this application type/application sub-type with an error code indicating that the message was rejected due to the presence of an unknown CVSE. If the receiving entity receives an NVSE with an unrecognized application type/application sub-type, the receiving entity shall ignore the NVSE and process the rest of the A11 signaling message. Within a CVSE or NVSE element containing recognized application type and subtype, if any application data fields are not recognized, those fields are ignored and the remainder of the element is processed to the extent possible.
11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32
1.10
Message Definition Guidelines
1. New messages shall have a Message Type that has never been previously used on that interface. 2. Information Element Identifiers shall not be reused in future revisions. 3. Defined valid values of Information Elements may be changed in future revisions. The new version shall define the error handling when previously valid values are received. 4. Octets and bits which are undefined or which are defined as reserved may be used in future revisions. 5. The Mandatory/Optional designation of Information Elements within a message shall not change. 6. Mandatory Information elements shall be sent in the order specified in section 5.1. 7. New optional Information Elements in a message shall be defined after all previously defined optional Information Elements. 8. All new Information Elements shall be defined with a length field. Note that most existing Information Elements have 1 octet length fields but some existing Information Elements have 2 octet length fields. Information Element Identifier values in the range A0H-BFH inclusive shall be defined to have a 2 octet length field. All other new Information Element Identifier values shall be defined to have a 1 octet length field. 9. New information may be added to the end of an existing Information Element, provided that the Information Element is defined with a length field. Care should be taken to avoid introducing ambiguity. For example, a length parameter that spans two fields of variable length or spans iterative loops with variable length fields could be ambiguous. 10. New application types/application sub-types shall be defined for support of new features on the A11 interface.
33 34
1.11
HRPD IOS Assumptions
This section describes assumptions in this standard. 1.11.1 IOS Assumptions The following assumptions are made regarding AN/AT behavior: 1. A packet data session may transition from a serving 1x system to a serving HRPD system and from a serving HRPD system to a serving 1x system. 2. Service option values 59 (3BH), 64 (40H), 67 (43H) and 71 (47H) are 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. 3. Subnets do not span more than one HRPD packet zone. There may be more than one subnet within an HRPD packet zone and intra-PCF handoffs may occur. 1-16
35 36 37 38 39 40 41 42 43
3GPP2 A.S0008-C v2.0

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
4. For the case of dormant 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 and if the International Mobile Subscriber Identity, IMSI, is available) or internal algorithms to select a PDSN. 5. Following a dormant handoff, the target AN sends the ANID to the target PCF. If the AT sends the SID, NID, and PZID, then the ANID consists of a triplet containing the received values. If the AT does not send the triplet, or the AN chooses not to request this information from the AT, then the target AN may send the ANID received in the A13-Session Information Response message from the source AN. If the target PCF supports ANIDs, then it sets the PANID to the ANID received from the target AN, and the CANID to its own ANID in the A11 messages. 6. 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 [30]. 7. 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. 8. 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. 9. The Mobile Node Identification (MN ID) that is used by the AN and the PCF in A9 and A11 messages is unique within the operators network, and is determined as follows: o 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. o 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. 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 [26]. 11. The AT may support packet data service as specified in [8]. 12. If the access authentication feature is used, the AN may acquire the AT hardware identifier via airinterface signaling, based on the network operator policies. 13. The AN and AT do not pass default attributes and attributes of hardlinked protocols over the air interface. Refer to [10].
33 34 35 36 37 38 39 40 41 42 43 44 45
1.11.2 QoS Assumptions The following assumptions are made regarding the QoS architecture: 1. The IP flows identified as Flow ID = {FFH, Forward} and {FFH, Reverse} are always associated with the main A8 and A10 connections. 2. A8 and A10 connections are bi-directional. 3. HRPD service option values are sent over the A9 and A11 interface but not over the HRPD air interface.
4. An IP flow is identified by a Flow ID and a direction. For HRPD, the Flow ID is set to the value of the air interface Reservation Label. 5. There is an M:1 mapping of IP flows to A8/A10 connection in the forward direction. That is, one A8/A10 connection may carry multiple forward IP flows. 6. There is an N:1 mapping of IP flows to A8/A10 connection in the reverse direction. That is, one A8/A10 connection may carry multiple reverse IP flows. 1-17
3GPP2 A.S0008-C v2.0

1 2 3 4 5 6 7 8 9 10 11 12
7. There is a 1:1 coupling of A8 and A10 connections. All IP flows mapped to a given A10 connection are mapped to the A8 connection corresponding to that A10 connection. 8. Each A8/A10 connection is associated with zero or one forward link flow. Subject to the network operators policy (e.g., accounting), this does not prohibit an IP flow from using a default link flow when its associated forward link flow is unavailable or when it (the IP flow) is in the deactivated state. 9. Each A8/A10 connection is associated with zero or one reverse link flow. 10. An AN is able to detect when a forward IP flow transitions to the active state, and to identify the activated forward IP flow (e.g., using Flow ID in the GRE extension). 11. The A8 and A10 connections with SR_ID 1 are defined to be the main A8 and A10 connection, respectively.
13 14
1.12
State Definition
This section describes state definitions for the HRPD system. 1.12.1 Packet Data Session State For purposes of the protocol of this standard, there are three packet data session states: Active/Connected, Dormant, and Null/Inactive. In the Active/Connected State, a physical traffic channel exists between the AT and the AN over which data may be sent. When transitioning to this state, all A8 connections for the packet data session are established and, if transitioning from the Null/Inactive State, all A10 connections for the packet data session are established. In the Dormant State, no physical traffic channel exists between the AT and the AN and no A8 connections exist between the AN and the PCF, however the PPP link between the AT and the PDSN is maintained. When transitioning to this state, all A8 connections for the packet data session are released. In the Null/Inactive State, there is no traffic channel between the AT and the AN and no PPP link between the AT and the PDSN. When transitioning to this state all A10 connections for the packet data session are released and, if transitioning from the Active/Connected State, all A8 connections for the packet data session are released. Figure 1.12.1-1 shows the possible transitions between the states of a packet data session.
Active / Connected State Dormant State
15 16 17 18 19 20 21 22 23 24 25 26 27
Null / Inactive State

28 29
Figure 1.12.1-1 Packet Data Session State Transitions 1.12.2 IP Flow State There are two IP flow states: Activated and Deactivated. In the Activated State, the IP flow is in service. The Activated State corresponds to the Multi-Flow Packet Application Reservation Open state specified in [10] and the Enhanced Multi-Flow Packet Application Reservation Open state specified in [20]. In the Deactivated State, the IP flow is temporarily out of service. Information on the IP flow is kept in the RAN so that the IP flow may be reactivated. The Deactivated State corresponds to the Multi-Flow Packet Application Reservation Close state specified in [10] and the Enhanced Multi-Flow Packet Application 1-18
30 31 32 33 34 35 36
3GPP2 A.S0008-C v2.0

1 2
Reservation Close state specified in [20]. Figure 1.12.2-1 shows the possible transitions between the states of an IP flow.
Initial state of IP flow other than FFH Initial state of IP flow FFH
Deactivated State
3 4
Activated State
Figure 1.12.2-1 IP Flow State Transitions
1.13
Feature Descriptions
1.13.1 Explicitly Supported Features 1.13.1.1 AT Originates an HRPD Session (including Access Authentication)
8 9
This feature supports the ability to originate an HRPD session. 1.13.1.2 Re-authentication of an AT
10 11
This feature supports the ability to re-authenticate an AT in dormant state or active state. 1.13.1.3 HRPD Data Delivery (both AT Terminated and AT Originated)
12 13
This feature supports the ability of the AT to terminate and originate data delivery. 1.13.1.4 HRPD Connection Release
14 15
This feature supports the ability of the AT or AN to release an HRPD connection. 1.13.1.5 HRPD Session Release
16 17
This feature supports the ability of the AT or AN to release an HRPD session. 1.13.1.6 HRPD Packet Data Session Release
18 19
This feature supports the ability of the PDSN to release the packet data session. 1.13.1.7 Dormant Handoff of HRPD AT Between ANs Served by the Same PDSN
20 21 22
This feature supports the ability of the AT to move to different ANs serviced by a common PDSN. During the mobility event, the packet data session is in a dormant state. 1.13.1.8 Dormant Packet Data Session Handoff Between 1x and HRPD Served by the Same PDSN
23 24 25 26
This feature supports the ability of an MS/AT with a dormant packet data session to move between a 1x BS and an HRPD AN served by a common PDSN. 1.13.1.9 Voice Call Delivery During Active HRPD Data Session
27 28 29
This feature supports the ability to deliver a voice call to an MS/AT during an active HPRD packet data session. 1-19
3GPP2 A.S0008-C v2.0

1 2
1.13.1.10
Status Management Supported by Feature Invocation
This feature supports the ability to invoke a service from a 1x MSC. 1.13.1.11 HRPD-1x cdma2000 Circuit Services Notification Application
3 4 5
This feature provides the ability to communicate 1x signaling information between the IWS and the HRPD AN to support the CSNA HRPD application. 1.13.1.12 Multiple Personalities in the Session Configuration Protocol
6 7
This feature supports multiple personalities in the HRPD session. 1.13.1.13 Packet Application Supporting Multiple Link Flows and Quality of Service
8 9
This feature supports different packet applications as supported in [10] [20] and quality of service. 1.13.1.14 Data Over Signaling (DoS)
10 11
This feature supports AT originated and AT terminated DoS. 1.13.1.15 GRE Segmentation
12 13 14
This feature supports GRE segmentation in both the forward and reverse directions between the PDSN and the AN. 1.13.1.16 RObust Header Compression (ROHC) on SO67
15 16 17 18 19 20 21 22 23
This feature supports the capability to associate ROHC channels with A8/A10 connections having service option 67. The location of ROHC is assumed to be the same across an operators network. The support of PDSN-based ROHC is mandatory, and the support of AN-based ROHC is optional. However, ROHC parameters negotiation shall always be carried between the AT and the AN. Each ROHC channel transfers ROHC packets without PPP encapsulation and without octet-based HDLClike framing (refer to [20] and [32]). For AN-based ROHC, these ROHC packets are exchanged between the AT and AN. For PDSN-based ROHC, these ROHC packets are exchanged between the AT and PDSN. 1.13.1.16.1 AN-Based ROHC For AN-based ROHC, the AN simply informs the PDSN that the A8/A10 connection has service option 67. The ROHC channels are transparent to the PCF and PDSN, so no A9/A11 signaling is required to support ROHC parameter exchange. 1.13.1.16.2 PDSN-Based ROHC For PDSN-based ROHC, each auxiliary A8/A10 connection may carry one forward ROHC channel, one reverse ROHC channel, or one forward and one reverse ROHC channel. Decisions about creating a new ROHC channel and its configuration parameter values are performed by the AN. The PDSN sends its ROHC parameter values via the PCF to the AN. The AN stores these values and takes them into account when determining the negotiated configuration parameter values each time the AN creates a new ROHC channel. The AN establishes any associated forward and/or reverse ROHC channels at the time an auxiliary A8/A10 connection with service option 67 is established. If forward and/or reverse ROHC channels are established, then the AN also includes the negotiated configuration parameter values for the new ROHC channel(s). If a service such as PDSN-based ROHC on SO67 requires a feedback loop, the PCF/AN shall assign the services feedback loop to the same A8/A10 connection (i.e., same SR_ID value in each direction) as the forward flow to which it refers. 1-20
24 25 26 27
28 29 30 31 32 33 34 35 36 37 38 39 40 41
3GPP2 A.S0008-C v2.0

1 2
1.13.1.17
HRPD Inter-AN Connected State Session Transfer (hard handoff)
This feature supports Connected State session transfer (also known as hard handoff) between ANs. 1.13.1.18 HRPD Inter-AN Cross-connectivity
3 4 5
This feature supports the ability of a source AN to use the radio resources of a target AN to support an active session. 1.13.1.19 HRPD Inter-AN Session transfer with cross-connectivity (including make-before-break)
6 7
This feature supports connected state session transfer with cross-connectivity between ANs. 1.13.1.20 1x Calling Party Number Presentation
8 9 10
This feature supports the ability to provide the calling party information for a 1x paging request that is sent to the MS/AT over the HRPD radio interface. 1.13.1.21 Reservation Label in HRPD Service Option When Paging on 1x
11 12
This feature supports the signaling of a reservation label in HRPD while paging on the 1x system. 1.13.1.22 Hard Handoff of a VoIP Call from HRPD to 1x Circuit Voice Call
13 14 15
This feature supports the ability of the network to handoff a VoIP call over HRPD to a circuit voice call over 1x. 1.13.1.23 Prior Session Release
16 17
This feature supports the ability to recover resources via release of a prior session. 1.13.1.24 QoS Update by the PDSN Feature Description
18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39
This feature enables the PDSN to update the QoS for one or more IP flows. The PDSN may send a QoS Update for any IP flow requested by the AT, even if the AN did not grant (but did not reject 3) the IP flow. The trigger for QoS update by the PDSN is operator configurable and is outside the scope of this document. The QoS update for an IP flow includes a list of one or more Flow Profile IDs. A Flow Profile ID value of 0x0000 indicates that the AN shall inform the AT that requested QoS_SUB_BLOB has been added but is invalid for this AN and the AT should not activate the corresponding IP flow. If the RAN does not have sufficient resources available to comply with the updated QoS for all of the specified flows, then the PCF may reject the A11-Session Update message by setting the Status IE to Update Denied insufficient resources in the A11-Session Update Acknowledge message. If the RAN only has resources available to comply with the updated QoS for some of the specified flows, the PCF may respond to the A11-Session Update message by setting the Status IE set to Partial QoS updated in the A11-Session Update Acknowledge message. The PCF informs the PDSN of which QoS updates were accepted and which were rejected using the IP flow mapping update procedure. After receiving the Updated QoS information, if the AN accepted the update then the AN initiates IP Flow Update procedure(s) if needed (refer to section 3.9.2 - 3.9.4). For each IP Flow updated by the PDSN, the AN shall change the granted QoS to the corresponding QoS_ATTRIBUTE_SET_ID in the R_QoS_SUB_BLOB that matches the first acceptable Flow Profile ID in the U_QoS_SUB_BLOB, irrespective of the contents of the Subscriber QoS Profile. A Flow Profile ID shall be considered acceptable if it is supported by the AN, if it matches one of the Flow Profile IDs requested by the AT, and if the call is not in inter-PCF handoff.
3
A reservation that is rejected via the attribute update reject message will be deleted; hence it cannot be upgraded later.
1-21
3GPP2 A.S0008-C v2.0

1 2 3 4 5 6 7 8 9
The AN shall store the QoS update together with the personality index in use at the time the QoS update was received from the PDSN. Whenever the specified personality index is in use, the AN shall use the stored QoS update to grant the QoS irrespective of the contents of the subscriber QoS Profile. All updated QoS information stored in the AN for a given IP flow is cleared when the corresponding IP flow is set to null (refer to [10]), regardless of the personality in use 4. During dormant and active handoff, stored QoS updates are transferred to the target AN via A13 and A16, respectively. Updated QoS information received from the PDSN (via the PCF) supersedes stored updated QoS information previously received from the PDSN or from another AN (via A13 or A16). 1.13.1.25 CSNA over A21
10 11 12 13 14
The CSNA over A21 feature uses the A21 interface to tunnel certain 1x messages between the HRPD AN and an IWS-1xBS or standalone IWS. The CSNA over A21 feature is also used to send signaling messages between the HRPD AN and the IWS-1xBS or standalone IWS. 1.13.1.26 PDSN Initiated IP Flow Release
15 16 17
This feature supports the PDSN initiated release of one or more IP flows. The PDSN should not use this procedure for flow ID FFH 5 and FEH. 1.13.1.27 Inter-AN paging when the AT is in idle state
18 19 20
This feature supports the ability for an AN to be able to page the AT that is in the service area of another AN. 1.13.1.28 Keep alive over A13 interface
21 22
This feature supports the ability to keep the LCM_UATI alive over the A13 interface. 1.13.1.29 HRPD Emergency Indicator
23 24 25 26 27 28 29 30 31 32 33 34
When emergency call setup is requested over the air and there is no existing packet data session on the HRPD system (e.g., the Emergency Indicator is set to 1 in the ConnectionRequest message), access authentication is performed per section 2.4.2. After authentication or for an AT with an existing packet data session that is requesting a new service connection for emergency services (e.g., the Emergency Indicator is set to 1 in the ReservationOnRequest message), the HRPD Emergency Indicator is sent from the AN to the PDSN in the A9-Setup-A8 and A11-Registration Request messages. For an AT with an existing packet data session that is requesting update of an existing service connection for emergency services, the HRPD Emergency Indicator is sent from the AN to the PDSN in the A9-Update-A8 and A11-Registration Request messages. Refer also to [23]. The PDSN may use the indication to prioritize RAN resource allocation.
4 5
i.e., ProfileType = NULL in ReservationKKQoSRequestFwd or ReservationKKQoSRequestRev. Presumably if the PDSN no longer needs flow FFH then the PDSN is closing the PPP session, in which case the PDSN would release the A10 connections (refer to section 3.6).
1-22
3GPP2 A.S0008-C v2.0

1
1.13.2 Transparently Supported Features 1.13.2.1 ROHC over PPP
2 3 4 5
ROHC over PPP channels (refer to [35]) are negotiated over PPP. ROHC packets may be carried over any combination of one A8/A10 connection using SO59 and zero or more A8/A10 connections using SO64. Refer to [8].
1-23
3GPP2 A.S0008-C v2.0

1 2 3 4 5
1-24
3GPP2 A.S0008-C v2.0
1 2 3 4 5 6 7 8 9 10
2 HRPD IOS Interfaces

This section describes the RAN interfaces associated with this specification. Where there are differences identified in the application of the IOS to 1x as opposed to HRPD, the terms in the right column of Table 2-1 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 A through Annex D of this specification. Note: Annex A through Annex D contain specific A1, A1p, A8, A9, A10 and A11 messaging text from [12], [14], [16] and [17] with all HRPD related changes identified through the use of underscores (additions) and strikeouts (deletions). Table 2-1 1x Term BS Base Station MS Mobile Station Terminology Cross Reference between 1x and HRPD HRPD Term AN Access Network AT Access Terminal
11
12 13 14 15 16 17
2.1
A1/A1p Interface (HRPD AN - MSC)
Note: In this specification A1 messages are used by both the A1 and A1p interfaces and the term MSC refers to either a circuit-switched MSC or an MSCe. The specification for the A1/A1p interfaces is defined in [14]. Updates to address HRPD are included in Annex B. The A1/A1p messages contained in Table 2.1-1 may be supported in HRPD systems. Table 2.1-1 A1 and A1p Messages Implemented in this Document
A1 and A1p Messages Call Processing Messages: CM Service Request 6 Assignment Request7 Assignment Complete7 Clear Request7 Clear Command7 Clear Complete7 Paging Request BS Service Request BS Service Response Mobility Management Messages: Location Updating Request Location Updating Accept Location Updating Reject
These messages should be implemented at the standalone IWS or the IWS-AN that support Hard Handoff of a Voice Call from HRPD VoIP to 1x Circuit Service.
2-1
3GPP2 A.S0008-C v2.0

Event Notification Event Notification Ack Handoff Messages: Handoff Required7 Handoff Command7 Handoff Commenced7 Handoff Required Reject7 Application Data Delivery Service (ADDS) Messages: ADDS Page ADDS Page Ack ADDS Transfer Facility Management Messages: Reset Circuit7 Reset Circuit Acknowledge7 Reset7 Reset Acknowledge7
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
The A1/A1p interface between the HRPD AN and the MSC is used to support CSNA (refer to [9]) and HRPD reactivation via the cdma2000 1x network. The CSNA functionality is included to address operation of an MS/AT that otherwise would have to periodically check the 1x system for pages while it is monitoring the HRPD system. For example, CSNA allows the MS/AT to receive a 1x notification over HRPD while receiving a service such as Broadcast Multicast Service (BCMCS) over HRPD. A corresponding enhancement is for an MS/AT to receive notification of data pending delivery in the HRPD system while it is monitoring the 1x system. HRPD AN - MSC assumptions: 1. The operation described in this document is achieved in part by reusing a subset of the messages defined on the A1/A1p interface between the 1x BS and the MSC. 2. The MSC keeps track of which RAN (1x or HRPD) from which a 1x registration was most recently received. 3. If the same PDSN is shared between the 1x PCF and HRPD PCF, the A10 can only be connected to either the 1x PCF or the HRPD PCF for a given MS/AT. The MS/AT cannot have both a 1x packet data service option and an HRPD service option active at the same time.
17 18 19
2.2
A8-A9 (AN - PCF) Interface
The specification for the A8-A9 interface is defined in [16]. Updates to address HRPD are included in Annex C.
20 21 22
2.3
A10-A11 (PCF - PDSN) Interface
The specification for the A10-A11 interface is defined in [17]. Updates to address HRPD are included in Annex D.
23 24 25
2.4
A12 (AN - AN-AAA) Interface
Support for the A12 interface and access authentication is optional in an HRPD radio access network. The requirements and provisions in this section apply insofar as the A12 interface is supported. 2-2
3GPP2 A.S0008-C v2.0

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
The A12 interface between the AN and the AN-AAA entities is used for the following purposes: 1. to transmit data used to perform AN-level access authentication of the 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 A1/A1p, A9 and A11 interfaces (following successful access authentication of the AT device). This identifier permits packet data session handoffs between ANs, between HRPD and 1x systems, and is also used in support of CSNA. If the AT device access authentication feature is not used by an HRPD system, the MN ID that is used by the AN on the A1/A1p, A9 and A11 interfaces is determined by other means. The A12 interface is based on the Remote Authentication Dial-In User Service (RADIUS) protocol as defined in [31]. The interface is shown in Figure 1.4-1. The A12 interface consists of the following messages: A12 Access-Request A12 Access-Accept A12 Access-Reject Note: In the call flows of this document these message names are prefixed with A12, to conform to IOS notation convention. Figure 2.4-1 shows the protocol reference model for the A12 interface. 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 that the use of AN-AAA brokers is optional.
RADIUS RADIUS RADIUS RADIUS RADIUS RADIUS
UDP IP Link Layer PL
AN
20 21
Visited AN-AAA
Broker AN-AAA
(optional)
Home AN-AAA
Figure 2.4-1
RADIUS Protocol Reference Model
22
23
2.4.1 2.4.1.1
PPP Session Establishment
24 25 26 27 28 29 30
If the AN supports access authentication and the A12 interface, after the AT indicates it is ready to exchange data on the access stream, the AN shall initiate PPP procedures according to [26] by sending an LCP Configure-Request. PPP shall support transparency in accordance with [27]. 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 AT by reinitiating the PPP session.
2-3
3GPP2 A.S0008-C v2.0

1 2 3 4
2.4.1.2
Termination
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. 2.4.1.3 Access Authentication
5 6 7 8 9
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. 2.4.2 AN-AAA Support
10 11 12 13 14 15 16 17 18 19 20 21 22
If the AN supports access authentication and the A12 interface, the AN shall support the RADIUS client protocol in accordance with [31] 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 rd additional 3 Generation Partnership Project 2 (3GPP2) Vendor Specific Attribute (VSA). Refer to Annex E, RADIUS Attributes. If the Access-Request message on the A12 interface contains a 3GPP2 VSA, the proxy AN-AAA shall include the attribute in the Access-Request message forwarded to the home AN-AAA on the A12 interface. The AN may acquire the AT hardware identity information as specified in [10]. This acquisition procedure is independent of any provisioning procedures that are performed locally on the AT, and the acquired AT hardware identity information represents the hardware identity of the AT obtained via air-interface signaling. 2.4.2.1 Access Authentication Establishment
23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42
On receipt of the ATs CHAP response, the AN shall send an Access-Request message, on the A12 interface, containing at a minimum: User-Name (1) 7 = 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 Note: For an emergency call, if the AT fails the access attempt, it may reattempt to access using the emergency NAI, emergency@a12.emergency.com as defined in [23]. In addition, the Access-Request message may contain: HRPD Access Authentication VSA (defined in Annex E), which is used to indicate that the AccessRequest message is sent in the context of access authentication. HRPD AT Hardware Identifier VSA (defined in Annex E), which contains the AT hardware identifier value and type obtained via air-interface signaling. Note: The CHAP access authentication password should be cryptographically strong. One recommendation for password generation can be found in [28], Randomness Recommendations for Security. Note: Based on network operators policy, the AN-AAA may use the AT hardware identifier in the AT Hardware Identifier VSA for verification purposes. If the policy of the home operator requires the usage of the AT hardware identifier and the AT Hardware Identifier VSA is absent from the Access-Request message, then the AN-AAA responds with an Access-Reject message.
The numbers in this list correspond to the RADIUS attribute type defined in [31].
2-4
3GPP2 A.S0008-C v2.0

1 2 3 4 5
Note: In HRPD systems, access authentication on the A12 interface should be performed prior to establishing the main A10 connection. 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 CallbackId attribute (Type=20) populated with the MN ID (e.g., IMSI) and the String field shall be set as follows: 0 1 2 3 4 5 6 7 Octet 1 2
ASCII encoded MN ID Type [30H denotes IMSI] ASCII encoded most significant Identity Digit = [30-39H]
ASCII encoded least significant Identity Digit = [30-39H]

6 7 8 9 10 11
2.4.2.2
Access Authentication Revocation
If the operator allows an IMSI to be copied to a new AT before removing it from the old AT, or the operator employs Removable User Identity Modules (R-UIMs) in their network, then the operator should prevent a users session from being applied to the wrong AT. This may be accomplished by requiring the Home AAA to send a Disconnect-Request to the PDSN to remove any existing PPP session and A10 connections (refer to [8]) and provisioning the new AT with a different CHAP password. 2.4.3 AN-AAA Requirements
12 13 14 15 16 17 18 19 20 21 22 23 24 25
The AN-AAA shall act as a RADIUS server and shall follow the guidelines specified in [31]. 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 [31]. 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 [31] for additional RADIUS security requirements. If the policy of the home operator requires the usage of the AT hardware identifier information, then the AN-AAA uses the AT hardware identifier information in the Access-Request message. The AN-AAA stores and returns the MN_ID that is used on the A9 and A11 interfaces.
26 27 28
2.5
A13 (AN - AN) Interface
The A13 interface carries HRPD session related information between the SC/MM function of the source AN and the SC/MM function of the target AN.
2-5
3GPP2 A.S0008-C v2.0

1 2 3 4 5
2.5.1
A13 Interface Network/Transport Protocol Specification
The IOS application is independent of the underlying physical transport medium, 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 UDP IP Link Layer Physical Layer
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
The following UDP [24] port value is reserved for signaling on the A13 interface: A13 (AN-to-AN) 3125/udp - This is the registered UDP port number to be used for signaling interconnection to another AN. The destination port number in the UDP packet that carries an A13-Session Information Request, A13Resource Release Request, A13-Paging Request, A13-Paging Delivered, and A13-1x Air Interface Signaling message shall be set to 3125. The receiver of the A13-Session Information Request message shall set the <source port, source IP address> and <destination port, destination IP address> of the UDP packet that carries the corresponding A13-Session Information Response/Reject message to the <destination port, destination IP address> and <source port, source IP address> of the UDP packet that carried the A13-Session Information Request message, respectively. The receiver of the A13-Session Information Response message shall set the <source port, source IP address> and <destination port, destination IP address> of the UDP packet that carries the corresponding A13-Session Information Confirm message to the <destination port, destination IP address> and <source port, source IP address> of the UDP packet that carried the A13-Session Information Response message, respectively. The receiver of the A13-Resource Release Request message shall set the <source port, source IP address> and <destination port, destination IP address> of the UDP packet that carries the corresponding A13Resource Release Response message to the <destination port, destination IP address> and <source port, source IP address> of the UDP packet that carried the A13-Resource Release Request message, respectively. The receiver of the A13-Paging Request message shall set the <source port, source IP address> and <destination port, destination IP address> of the UDP packet that carries the corresponding A13-Paging Request Ack message to the <destination port, destination IP address> and <source port, source IP address> of the UDP packet that carried the A13-Paging Request message, respectively. The receiver of the A13-Keep Alive Request message shall set the <source port, source IP address> and <destination port, destination IP address> of the UDP packet that carries the corresponding A13-Keep Alive Response message to the <destination port, destination IP address> and <source port, source IP address> of the UDP packet that carried the A13-Keep Alive Request message, respectively. The receiver of the A13-Paging Delivered message shall set the <source port, source IP address> and <destination port, destination IP address> of the UDP packet that carries the corresponding A13-Paging Delivered Ack message to the <destination port, destination IP address> and <source port, source IP address> of the UDP packet that carried the A13-Paging Delivered message, respectively. The receiver of the A13-1x Air Interface Signaling message shall set the <source port, source IP address> and <destination port, destination IP address> of the UDP packet that carries the corresponding A13-1x Air Interface Signaling Ack message to the <destination port, destination IP address> and <source port, source IP address> of the UDP packet that carried the A13-1x Air Interface Signaling, respectively. 2-6
3GPP2 A.S0008-C v2.0

1 2 3
The standard UDP protocol, as described in [24], shall be used. Note: Care should be taken in addressing ANs designed per 3GPP2 A.S0008-0, where this port usage specification was not made. 2.5.2 A13 Interface Message Procedures
4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
This section describes the message procedures used between ANs on the A13 interface. The interface consists of the following messages: A13-Session Information Request A13-Session Information Response A13-Session Information Confirm A13-Session Information Reject A13-Resource Release Request A13-Resource Release Response A13-Paging Request A13-Paging Request Ack A13-Paging Delivered A13-Paging Delivered Ack A13-Keep Alive Request A13-Keep Alive Response A13-1x Air Interface Signaling A13-1x Air Interface Signaling Ack The procedures for how the target AN discovers the source AN and determines the UATI are not specified. 2.5.2.1 A13-Session Information Request
24 25 26
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. 2.5.2.1.1 Successful Operation
27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44
When the target AN receives a packet from an AT that contains a UATI that is not in a subnet that is associated with the target AN, 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 determined UATI, Security Layer Packet and Sector ID. The target AN then starts timer TA13req. The information content in the A13-Session Information Request message includes: Unicast Access Terminal Identifier (UATI). This is the UATI received by the target AN using the UATI Color Code and UATI024 received from the AT, which allows the source AN to determine the session configuration parameters that are requested by the target. Note that some parts of the UATI determined by the target may not be meaningful. However, it is assumed that the source AN has enough information to identify the corresponding HRPD session. 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. Data Transfer. If the target AN is capable of receiving buffered data from the source AN, it may include the A24 Connection ID to be used for the tunneling of this data for the AT. The A24
2-7
3GPP2 A.S0008-C v2.0

1 2 3
Connection ID is used as the upper 24 bits of the GRE key for A24 data transfer for all A24 GRE connections for the AT. Refer to section 5.1.1.1, A13-Session Information Request, for the format and content of this message. 2.5.2.1.2 Failure Operation
4 5 6 7 8
If timer TA13req expires, the target AN may resend the A13-Session Information Request message to the source AN and restart timer TA13req a configurable number of times. If the A13-Session Information Response message is not received from the source AN, the target AN may begin a new session establishment with the AT. 2.5.2.2 A13-Session Information Response
9 10 11
The A13-Session Information Response message is used by the source AN to respond to the target ANs request to retrieve information about an AT. 2.5.2.2.1 Successful Operation
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
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 information contained in the A13-Session Information Request message and if it has the requested session state information, it sends an A13-Session Information Response message to the target AN with the requested information and starts timer TA13res. The source AN includes Session State Information Records (SSIR) for the main personality and Extended Session State Information Records (ESSIR) for all personalities other than the main personality in the A13-Session Information Response message. The target AN determines the current personality from the SessionConfigurationToken attribute of the main personality. For detailed information, refer to [10]. Upon receipt of the A13-Session Information Response message, the target AN stops timer TA13req. The information content in the A13-Session Information Response message includes: MN ID used by the source AN over the A11 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 previously negotiated between the AT and the source AN. PDSN address. This IPv4 address allows the target AN/PCF 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-PCF handoff, the target PCF may use the PDSN address received from the source AN via the target 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 transition a packet data session from a serving HRPD system to a serving 1x system and back to a serving HRPD system. Therefore, following a dormant handoff, the target AN shall send the PANID received from the AT to the target PCF. 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 Response message from the source AN. Data Transfer. If the target AN indicated in the A13-Session Information Request message that it is capable of receiving buffered data from the source AN and the source AN will have data to send, the source AN may include this IE. This IE provides a list of RLP_IDs for A24 data transfer. Upon receiving an A13-Session Information Response message with the Data Transfer IE included, the target AN may wait an implementation specific time after receiving the message before it stops expecting 2-8
3GPP2 A.S0008-C v2.0

1 2 3 4 5 6 7
data, in the event that a buffer indicator is not received from the source AN in the Buffered Data Information GRE attribute. The target AN shall assume that A24 data transfer is for all RLP IDs listed in the Data Transfer IE in the A13-Session Information Response message. The target AN shall use GRE keys that consists of A24 Connection ID sent in the A13-Session Information Request message as upper 24 bits of GRE key and RLP_ID as lower 8 bits of GRE key, to receive data from the source AN over A24 interface. Refer to section 5.1.1.2, A13-Session Information Response, for the format and content of this message. 2.5.2.2.2 Failure Operation
8 9
If timer TA13res expires, the source AN may re-send this message a configurable number of times. 2.5.2.3 A13-Session Information Confirm
10 11 12
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. 2.5.2.3.1 Successful Operation
13 14 15 16 17 18 19 20 21
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 and stop timer TA13res. If the source AN indicated in the A13Session Information Response message that it will have buffered data to send to the target AN, then the source AN should wait until the A8 connection release prior to removing the stored session information related to the AT. Refer to section 5.1.1.3, A13-Session Information Confirm, for the format and content of this message. 2.5.2.3.2 None. 2.5.2.4 A13-Session Information Reject Failure Operation
22 23
24 25 26
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. 2.5.2.4.1 Successful Operation
27 28 29 30 31 32 33 34
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 AT, 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, the source AN may retain the session information, if it exists. Refer to section 5.1.1.4, A13-Session Information Reject, for the format and content of this message. 2.5.2.4.2 None. 2.5.2.5 A13-Resource Release Request Failure Operation
35 36
37 38 39
The A13-Resource Release Request message is used by the target AN to request the source AN to release a UATI after active handoff or to release prior session information.
2-9
3GPP2 A.S0008-C v2.0

1 2 3 4 5 6 7 8 9 10
2.5.2.5.1
Successful Operation
For active handoff procedure, when the target AN receives an HRPD session in Connected State through the A16 interface and the connection is subsequently closed, the target AN sends an A13-Resource Release Request message to the AN determined from the LCM_UATI IE received in the A16-Session Transfer Complete message. The target AN includes UATI 128, determined from the LCM_UATI IE, in the A13-Resource Release Request message. The target AN starts timer TA13rel. For prior session information release procedure, when the target AN receives information about a prior session from the AT, the target AN may send an A13-Resource Release Request message to the source AN to release prior session information for the AT. The target AN starts timer TA13rel. Refer to section 5.1.1.5, A13-Resource Release Request, for the format and content of this message. 2.5.2.5.2 Failure Operation
11 12 13
If timer TA13rel expires, the target AN may resend the A13-Resource Release Request message a configurable number of times. 2.5.2.6 A13-Resource Release Response
14 15 16
The A13-Resource Release Response message is sent by the source AN to respond to the A13-Resource Release Request message. 2.5.2.6.1 Successful Operation
17 18 19 20 21 22 23 24 25 26
When the source AN receives an A13-Resource Release Request message which contains only UATI 128, the source AN releases the UATI if the policy in the source AN allows the session to be released without receiving authenticating credentials such as the Security Layer Packet. Otherwise, it checks if the session information for the requested AT exists and if it can authenticate the target ANs request. After the source AN has successfully authenticated the information contained in the A13-Resource Release Request message, the source AN releases the existing prior session information and sends the A13-Resource Release Response message to the target AN. Upon receipt of the A13-Resource Release Response message, the target AN stops timer TA13rel. Refer to section 5.1.1.6, A13-Resource Release Response, for the format and content of this message. 2.5.2.6.2 None. 2.5.2.7 A13-Paging Request Failure Operation
27 28
29 30 31
The A13-Paging Request message is used by the source AN to request the target AN to transmit a page message for an AT. 2.5.2.7.1 Successful Operation
32 33 34 35 36 37 38 39
When the source AN needs to send a page message to the AT on the target AN control channel, the source AN sends an A13-Paging Request message to the target AN. The message includes the AT-ID of the AT. The source AN may include timing information of when the message is to be transmitted on the source AN control channel. In case that distance-based registration is used at the AT, the source AN shall include the location information of the sector where the AT last registers. The source AN starts timer Tpreq-13. Refer to section 5.1.1.7, A13-Paging Request, for the format and content of this message.
2-10
3GPP2 A.S0008-C v2.0

1 2 3
2.5.2.7.2
Failure Operation
If timer Tpreq-13 expires, the source AN may resend the A13-Paging Request message a configurable number of times. 2.5.2.8 A13-Paging Request Ack
4 5 6
The A13-Paging Request Ack message is sent by the target AN to respond to the source AN to acknowledge the receipt of the A13-Paging Request message. 2.5.2.8.1 Successful Operation
7 8 9 10 11 12 13 14 15 16 17 18 19
When the target AN receives an A13-Paging Request message, it shall send the A13-Paging Request Ack message to the source AN and attempt to send a page message on its control channel on the paging cycle of the AT. The target AN may send the message in the timeslot indicated by the source AN in the A13Paging Request message. If the AT supports secondary colorcode, the target AN may send the message on all of its RTs that advertise the colorcode found in UATI32. If distance-based registration is used, the target AN may send the message on all of its RTs that are within the RouteUpdate radius (as specified in [10]) received in the A13-Paging Request message from the location information contained in the A13Paging Request message. The target AN shall use the Paging Cause IE in the A13-Paging Request Ack message to indicate the action to be taken. Upon receipt of the A13-Paging Request Ack message, the source AN stops timer Tpreq-13. Refer to section 5.1.1.8, A13-Paging Request Ack, for the format and content of this message. 2.5.2.8.2 None. 2.5.2.9 A13-Paging Delivered Failure Operation
20 21
22 23 24
The A13-Paging Delivered message is sent by the target AN to the source AN to indicated that a previous page has been delivered to an AT. 2.5.2.9.1 Successful Operation
25 26 27 28 29
When the target AN receives an HRPD ack message from the AT indicating the AT has received the HRPD data burst message associated with the A13-Paging Request and Request Ack messaging, the target AN sends the A13-Paging Delivered message to the source AN and starts timer Tpreq-13. Refer to section 5.1.1.9, A13-Paging Delivered, for the format and content of this message. 2.5.2.9.2 Failure Operation
30 31 32
If timer Tpreq-13 expires, the target AN may resend the A13-Paging Delivered message and restart timer Tpreq-13 a configurable number of times. 2.5.2.10 A13-Paging Delivered Ack
33 34 35
The A13-Paging Delivered Ack message is sent by the source AN to the target AN to acknowledge receipt of the previous A13 Paging Delivered message. 2.5.2.10.1 Successful Operation When the source AN receives the A13-Paging Delivered message, the source AN sends the A13-Paging Delivered Ack message to the target AN. When the target AN receives an A13-Paging Delivered Ack message, the target AN stops timer Tpreq-13. Refer to section 5.1.1.10, A13-Paging Delivered Ack, for the format and content of this message. 2-11
36 37 38 39 40
3GPP2 A.S0008-C v2.0

1 2
2.5.2.10.2 Failure Operation None. 2.5.2.11 A13-Keep Alive Request
3 4 5
The A13-Keep Alive Request message is sent from the serving AN to the AN that assigned LCM_UATI to inform it that the LCM_UATI is still in use. 2.5.2.11.1 Successful Operation The serving AN may send an A13-Keep Alive Request message to the AN that assigned LCM_UATI to restart timer TSClose-13 running in the AN that assigned LCM_UATI. When the serving AN sends the A13-Keep Alive Request message, the serving AN starts timer TKeepAlive-13. The AN receiving this message shall restart timer TSClose-13 if it is running. Refer to section 5.1.1.11 A13-Keep Alive Request, for the format and content of this message. 2.5.2.11.2 Failure Operation If timer TKAreq-13 expires, the serving AN may resend the A13-Keep Alive Request message and restart timer TKeepAlive-13 a configurable number of times. 2.5.2.12 A13-Keep Alive Response
6 7 8 9 10 11
12 13 14
15 16 17
The A13-Keep Alive Response message is sent by the AN that assigned LCM_UATI to the serving AN to respond to the A13-Keep Alive Request message. 2.5.2.12.1 Successful Operation When the AN receives an A13-Keep Alive Request message, the AN sends an A13-Keep Alive Response message to the serving AN. The serving AN stops timer TKeepAlive-13. Refer to section 5.1.1.12, A13-Keep Alive Response, for the format and content of this message. 2.5.2.12.2 Failure Operation None. 2.5.2.13 A13-1x Air Interface Signaling
18 19 20 21
22 23
24 25 26
The A13-1x Air Interface Signaling message is sent by the target AN to the source AN to indicated a 1x air interface message received by the target AN from the MS/AT using the CSNA protocol. 2.5.2.13.1 Successful Operation When the target AN receives a 1x air interface message from the MS/AT that is to be sent to an IWS, the target AN encapsulates the 1x air interface message in a A13-1x Air Interface Signaling message and sends it to the source AN, which forwards it to the IWS via A21 interface. The HRPD target AN then starts timer Tpreq-13. Refer to section 5.1.1.13, A13-1x Air Interface Signaling, for the format and content of this message. 2.5.2.13.2 Failure Operation If timer Tpreq-13 expires, the target AN may resend the A13-1x Air Interface Signaling message and restart timer Tpreq-13 a configurable number of times. 2.5.2.14 A13-1x Air Interface Signaling Ack
27 28 29 30 31 32
33 34 35
36 37 38
The A13-1x Air Interface Signaling Ack message is sent by the source AN to the target AN to acknowledge receipt of the previous A13-1x Air Interface Signaling message. 2-12
3GPP2 A.S0008-C v2.0

1 2 3 4 5
2.5.2.14.1 Successful Operation When the source AN receives the A13-1x Air Interface Signaling message, the source AN sends the A131x Air Interface Signaling Ack message to the target AN. When the target AN receives an A13-1x Air Interface Signaling Ack message, the target AN stops timer Tpreq-13. Refer to section 5.1.1.14, A13-1x Air Interface Signaling Ack, for the format and content of this message. 2.5.2.14.2 Failure Operation None.
6 7
8 9
2.6
A16 Interface
10 11 12
2.6.1
A16 Interface Network/Transport Protocol Specification
The signaling protocol stack available to operators and manufacturers for the A16 interface is: IOS Application UDP IP Link Layer Physical Layer
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
The following UDP port values are reserved for signaling on the A16 interface. A16 (AN-to-AN) 4598/udp - This is the registered UDP port number to be used for signaling interconnection to another AN. The destination port number in the UDP packet that carries an A16-Session Transfer Request message shall be set to 4598. When the source AN sends an A16-Session Transfer Abort message before it receives the corresponding A16-Session Transfer Response message, the destination port number in the UDP packet that carries an A16-Session Transfer Abort message shall be set to 4598. The receiver of the A16-Session Transfer Request message shall set the <source port, source IP address> and <destination port, destination IP address> of the UDP packet that carries all subsequent A16 messages related to session transfer of the AT to the <destination port, destination IP address> and <source port, source IP address> of the UDP packet that carried the A16-Session Transfer Request message, respectively. If the receiver needs to send another A16-Session Transfer Request for the same AT, the destination port of the A16-Session Transfer Request shall be reset to 4598 with the provisioned IP address of the target AN. The receiver of the A16-Session Transfer Response message shall set the <source port, source IP address> and <destination port, destination IP address> of the UDP packet that carries all A16 messages other than A16-Session Transfer Request to the <destination port, destination IP address> and <source port, source IP address> of the UDP packet that carried the A16-Session Transfer Response message, respectively. If the source AN is the master AN, it shall set the <source port, source IP address> and the <destination port, destination IP address> of the A16-Attributes Update to the <source port, source IP address> and the <destination port, destination IP address> it used to send the last A16-Session Transfer Request message for this AT. If the source AN is the slave AN, it shall set the <source port, source IP address> and the <destination port, destination IP address> of the A16-FL Signal Tunnel or A16-RL Signal Tunnel messages to the <source port, source IP address> and the <destination port, destination IP address> it used to send the last A16-Session Transfer Request message for this AT. 2-13
3GPP2 A.S0008-C v2.0

1 2 3 4 5 6 7 8 9 10 11 12 13
If the target AN is the master AN, it shall set the <source port, source IP address> and the <destination port, destination IP address> of the A16-Attributes Update to the <source port, source IP address> and the <destination port, destination IP address> it used to send the last A16-Session Transfer Response message for this AT. If the target AN is the slave AN, it shall set the <source port, source IP address> and the <destination port, destination IP address> of the A16-FL Signal Tunnel or A16-RL Signal Tunnel messages to the <destination port, destination IP address> and <source port, source IP address> of the UDP packet of the last received A16-Session Transfer Request message, respectively. The receiver of the A16-FL Signal Tunnel, A16-RL Signal Tunnel, or A16-Attributes Update message shall set the <source port, source IP address> and <destination port, destination IP address> of the UDP packet that carries the corresponding acknowledgement of these messages to the <destination port, destination IP address> and <source port, source IP address> of the UDP packet that carried the message that it acknowledges. The standard UDP protocol, as described in [24], shall be used. 2.6.2 A16 Interface Message Procedures
14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
This section describes the message procedures used between ANs on the A16 interface. The A16 interface consists of the following messages: A16-Session Transfer Request A16-Session Transfer Response A16-Session Transfer Complete A16-Session Release Indication A16-Session Release Indication Ack A16-Session Transfer Abort A16-Session Transfer Abort Ack A16-Session Transfer Reject A16-FL Signal Tunnel A16-FL Signal Tunnel Ack A16-RL Signal Tunnel A16-RL Signal Tunnel Ack A16-Attributes Update A16-Attributes Update Ack The destination IP address of the A16 interface at the target AN is provisioned in the source AN. 2.6.2.1 A16-Session Transfer Request
32 33 34
The A16-Session Transfer Request message is sent by the source AN to the target AN to request a Connected State Session Transfer (hard handoff or with cross-connectivity support) for an AT. 2.6.2.1.1 Successful Operation
35 36 37 38 39 40 41 42 43 44 45
When the source AN decides that it is necessary to perform a Connected State Session Transfer for an AT to a target AN, it sends an A16-Session Transfer Request to the target AN and starts timer Tstreq-16 to await the arrival of the A16-Session Transfer Response message. If the source AN requests a Hard Handoff to the target AN, the source AN shall include an Encapsulated Message IE and may include the Serving Sector ID, Target Sector ID and RTD Information IEs in this message. Otherwise, the Encapsulated Message IE shall not be included. If the source AN requests a make-before-break session transfer, then Serving Sector Information IE shall be included. During Connected State Session Transfer with cross-connectivity support, the source AN shall become the master AN upon transmission of the A16-Session Transfer Request message. Refer to section 5.1.2.1, A16-Session Transfer Request, for the format and content of this message. 2-14
3GPP2 A.S0008-C v2.0

1 2 3 4 5 6
2.6.2.1.2
Failure Operation
If timer Tstreq-16 expires, the source AN may resend the A16-Session Transfer Request message to the target AN and restart timer Tstreq-16 a configurable number of times. If the A16-Session Transfer Response message is not received from the target AN, the source AN may choose other actions with respect to the AT, for example, the source AN may perform a Connected State Session Transfer with another AN. 2.6.2.2 A16-Session Transfer Response
7 8 9
The A16-Session Transfer Response message is sent by the target AN to the source AN to accept a Connected State Session Transfer for an AT. 2.6.2.2.1 Successful Operation
10 11 12 13 14 15 16 17 18 19
When the target AN receives an A16-Session Transfer Request message, it determines whether it has sufficient resources to accept the Connected State Session Transfer request and whether it can support the embedded session in the message. During Connected State Session Transfer with cross-connectivity support, the target AN shall become the slave AN upon receipt of the A16-Session Transfer Request message. When the target AN decides that it can accept the session, it responds to the source AN by sending an A16-Session Transfer Response and starts timer Tstcomp-16 to await the arrival of the A16Session Transfer Complete message. Upon receipt of the A16-Session Transfer Response message, the source AN stops timer Tstreq-16. Refer to section 5.1.2.2, A16-Session Transfer Response, for the format and content of this message. 2.6.2.2.2 Failure Operation
20 21 22 23 24
If timer Tstcomp-16 expires, the target AN may resend the A16-Session Transfer Response message to the source AN and restart timer Tstcomp-16 a configurable number of times. If the A16-Session Transfer Complete message is not received from the source AN, the target AN shall send an A16-Session Transfer Abort message to the source AN. 2.6.2.3 A16-Session Transfer Complete
25 26 27
The A16-Session Transfer Complete message is sent by the source AN to the target AN to notify the target AN to take control of the ATs session. 2.6.2.3.1 Successful Operation
28 29 30 31 32 33 34 35 36 37 38
When the source AN receives an A16-Session Transfer Response from the target AN, it stops timer Tstreq-16. During hard handoff, the source AN also instructs the AT to move to the Active Set of the target AN. The source AN then sends an A16-Session Transfer Complete message to the target AN and starts timer Tstack-16 to await the arrival of the A16-Session Release Indication message. During Connected State Session Transfer with cross-connectivity support, the source AN shall become the slave AN upon transmission of the A16-Session Transfer Complete message. Upon receipt of the A16-Session Transfer Complete message, the target AN stops timer Tstcomp-16. During Connected State Session Transfer with cross-connectivity support, the target AN shall become the master AN upon receipt of the A16-Session Transfer Complete message. Refer to section 5.1.2.3, A16-Session Transfer Complete, for the format and content of this message. 2.6.2.3.2 Failure Operation
39 40 41 42 43
If timer Tstack-16 expires, the source AN may resend the A16-Session Transfer Complete message to the target AN and restart timer Tstack-16 a configurable number of times. If the A16-Session Release Indication message is not received from the target AN, the source AN may release resources related to the AT. 2-15
3GPP2 A.S0008-C v2.0

1 2 3 4
During hard handoff, if the target AN receives the A16-Session Transfer Complete message but fails to acquire the AT after expiration of an implementation dependent timer, the target AN may resend the A16Session Transfer Response message to the source AN and restart timer Tstcomp-16. The target AN then awaits the arrival of another A16-Session Transfer Complete message. 2.6.2.4 A16-Session Release Indication
5 6 7 8
The A16-Session Release Indication message is sent by the target AN to the source AN to notify the source AN that the AT is now under the control of the target AN and the source AN may purge the session associated with the AT. 2.6.2.4.1 Successful Operation
9 10 11 12 13 14
When the target AN receives an A16-Session Transfer Complete message from the source AN, it stops timer Tstcomp-16. Once the AT is under the control of the target AN, the target AN sends an A16-Session Release Indication message to the source AN and starts timer Tstrel-16 to await the arrival of the A16Session Release Indication Ack message. Refer to section 5.1.2.4, A16-Session Release Indication, for the format and content of this message. 2.6.2.4.2 Failure Operation
15 16 17
If timer Tstrel-16 expires, the target AN may resend the A16-Session Release Indication message to the source AN and restart timer Tstrel-16 a configurable number of times. 2.6.2.5 A16-Session Release Indication Ack
18 19 20
The A16-Session Release Indication Ack message is sent by the source AN to the target AN to acknowledge the release of the session for the AT. 2.6.2.5.1 Successful Operation
21 22 23 24 25
When source AN receives an A16-Session Release Indication from the target AN, the source AN responds with an A16-Session Release Indication Ack message and stops timer Tstack-16. Upon receipt of the A16-Session Release Indication Ack message, the target AN stops timer Tstrel-16. Refer to section 5.1.2.5, A16-Session Release Indication Ack, for the format and content of this message. 2.6.2.5.2 None. 2.6.2.6 A16-Session Transfer Abort Failure Operation
26 27
28 29 30
The A16-Session Transfer Abort message is sent by either the source AN or the target AN to the other AN to indicate a Connected State Session Transfer failure. 2.6.2.6.1 Successful Operation
31 32 33 34 35 36 37 38 39 40 41
Upon transmission or receipt of an A16-Session Transfer Abort message, the source AN during hard handoff or the master AN during session transfer with cross-connectivity support attempts to maintain control of the AT and may re-attempt the Connected State Session Transfer. Upon transmission or receipt of an A16-Session Transfer Abort message, the target AN during hard handoff or the slave AN during session transfer with cross-connectivity support shall cease to attempt to take control of the AT and should release resources related to the session transfer of the AT. This message may be sent in response to an unexpected session transfer message or when the AN has detected that the connection to the AT is lost. The sending AN starts timer Tstabrt-16. Upon receipt of the A16-Session Transfer Abort message, the receiving AN stops timer Tstack-16, Tstreq-16, or Tstcomp-16, if running. Refer to section 5.1.2.6, A16-Session Transfer Abort, for the format and content of this message. 2-16
3GPP2 A.S0008-C v2.0

1 2 3 4 5
2.6.2.6.2
Failure Operation
If timer Tstabrt-16 expires, the sending AN may resend the A16-Session Transfer Abort message to the other AN and restart timer Tstabrt-16 a configurable number of times. If the A16-Session Transfer Abort Ack message is not received from the other AN, the sending AN may release resources related to Session Transfer of the AT. 2.6.2.7 A16-Session Transfer Abort Ack
6 7 8
The A16-Session Transfer Abort Ack message is sent by an AN to another AN to acknowledge the cancellation of a Connected State Session Transfer attempt for the AT. 2.6.2.7.1 Successful Operation
9 10 11 12 13
When an AN receives an A16-Session Transfer Abort message from another AN, it stops the outstanding A16 timer and responds with an A16-Session Transfer Abort Ack message. Upon receipt of the A16Session Transfer Abort Ack message the receiving AN stops timer Tstabrt-16. Refer to section 5.1.2.7, A16-Session Transfer Abort Ack, for the format and content of this message. 2.6.2.7.2 None. 2.6.2.8 A16-Session Transfer Reject Failure Operation
14 15
16 17 18
The A16-Session Transfer Reject message is sent by the target AN to the source AN to reject a Connected State Session Transfer request for an AT. 2.6.2.8.1 Successful Operation
19 20 21 22 23 24 25
When the target AN receives an A16-Session Transfer Request message, it determines whether it has sufficient resources to accept the Connected State Session Transfer and whether it can support the embedded session in the message. When the target AN decides that it cannot accept the Connected State Session Transfer, it responds to the source AN by sending an A16-Session Transfer Reject message. Upon receipt of the A16-Session Transfer Reject message, the source AN stops timer Tstreq-16. Refer to section 5.1.2.8, A16-Session Transfer Reject, for the format and content of this message. 2.6.2.8.2 None. 2.6.2.9 A16-FL Signal Tunnel Failure Operation
26 27
28 29 30
The A16-FL Signal Tunnel message is sent by the slave AN to the master AN to tunnel air-interface signaling messages from the slave AN to the AT. 2.6.2.9.1 Successful Operation
31 32 33 34 35 36
When the slave AN determines that it needs to tunnel a signaling message (including DoS [10], [20]) to the AT, it sends an A16-FL Signal Tunnel message which encapsulates the air-interface signaling message needed to be transmitted to the AT. Refer to section 5.1.2.9, A16-FL Signal Tunnel, for the format and content of this message. The slave AN then starts timer Tsigtunnel-16. 2.6.2.9.2 Failure Operation
37 38 39
If timer Tsigtunnel-16 expires, the slave AN may resend the A16-FL Signal Tunnel message to the master AN and restart timer Tsigtunnel-16 a configurable number of times. If the A16-FL Signal Tunnel Ack 2-17
3GPP2 A.S0008-C v2.0

1 2
message is not received from the master AN, the slave AN may release resources related to session transfer of the AT. 2.6.2.10 A16-FL Signal Tunnel Ack
3 4 5
The A16-FL Signal Tunnel Ack message is sent by the master AN to the slave AN to acknowledge the receipt of the A16-FL Signal Tunnel message. 2.6.2.10.1 Successful Operation When the master AN receives the A16-FL Signal Tunnel message, it sends the encapsulated signaling message to the AT and also sends an A16-FL Signal Tunnel Ack message to the slave AN. When the slave AN receives an A16-FL Signal Tunnel Ack message from the master AN, it stops timer Tsigtunnel16. Refer to section 5.1.2.10, A16-FL Signal Tunnel Ack, for the format and content of this message. 2.6.2.10.2 Failure Operation None. 2.6.2.11 A16-RL Signal Tunnel
6 7 8 9 10 11
12 13
14 15 16
The A16-RL Signal Tunnel message is sent by the master AN to the slave AN to tunnel signaling messages related to the slave AN from the AT to the slave AN through the master AN. 2.6.2.11.1 Successful Operation When the master AN receives an air-interface signaling message related to the slave AN, e.g., a signaling message (including DoS [10], [20]) related to the application-layer route that belongs to the slave AN, the master AN encapsulates the air-interface signaling message in an A16-RL Signal Tunnel message and then sends the message to the slave AN. Refer to section 5.1.2.11, A16-RL Signal Tunnel, for the format and content of this message. The master AN then starts timer Tsigtunnel-16. 2.6.2.11.2 Failure Operation If timer Tsigtunnel-16 expires, the master AN may resend the A16-RL Signal Tunnel message to the slave AN and restart timer Tsigtunnel-16 a configurable number of times. If the A16-RL Signal Tunnel Ack message is not received from the slave AN, the master AN may release resources related to session transfer of the AT. 2.6.2.12 A16-RL Signal Tunnel Ack
17 18 19 20 21 22 23
24 25 26 27 28
29 30 31
The A16-RL Signal Tunnel Ack message is sent by the slave AN to the master AN to acknowledge the receipt of the A16-RL Signal Tunnel message. 2.6.2.12.1 Successful Operation Upon receipt of the A16-RL Signal Tunnel message, the slave AN sends an A16-RL Signal Tunnel Ack message to the master AN. When the master AN receives the A16-RL Signal Tunnel Ack message from the slave AN, it stops timer Tsigtunnel-16. Refer to section 5.1.2.12, A16-RL Signal Tunnel Ack, for the format and content of this message. 2.6.2.12.2 Failure Operation None.
32 33 34 35 36
37 38
2-18
3GPP2 A.S0008-C v2.0

1 2 3 4
2.6.2.13
A16-Attributes Update
The A16-Attributes Update message is sent by the master AN to the slave AN to update the Session State Information Records, Serving Sector Information and/or Sector Endpoint Information of the sectors in the current active set of the AT at the slave AN. 2.6.2.13.1 Successful Operation When there is a change in the Session State Information Records, Serving Sector Information and/or Sector Endpoint Information of the sectors in the current active set of the AT during Connected State Session Transfer with Cross-Connectivity support, the master AN sends an A16-Attributes Update message to the slave AN. The message contains the updated Session State Information Records, Serving Sector Information and Sector Endpoint Information that have changed from the Session State Information Records, Serving Sector Information and Sector Endpoint Information that were last acknowledged by the slave AN, i.e., the Session State Information Records, Serving Sector Information and Sector Endpoint Information sent in A16-Attributes Update message with the largest sequence number that was acknowledged or the Session State Information Records, Serving Sector Information and/or Sector Endpoint Information in A16-Session Transfer Request message if no A16-Attributes Update message was sent. Refer to section 5.1.2.13, A16-Attributes Update, for the format and content of this message. The master AN then starts timer Tattribupd-16. 2.6.2.13.2 Failure Operation If timer Tattribupd-16 expires, the master AN may resend the A16-Attributes Update message to the slave AN and restart timer Tattribupd-16 a configurable number of times. If the A16-Attributes Update Ack message is not received from the slave AN, the master AN may release resources related to session transfer of the AT. 2.6.2.14 A16-Attributes Update Ack
5 6 7 8 9 10 11 12 13 14 15 16 17 18
19 20 21 22 23
24 25 26
The A16-Attributes Update Ack message is sent by the slave AN to the master AN to acknowledge the receipt of the A16-Attributes Update message. 2.6.2.14.1 Successful Operation Upon receipt of the A16-Attributes Update message from the master AN, the slave AN updates the session information and serving sector as specified in the A16-Attributes Update message, according to Sector Endpoint Information in the A16-Attributes Update message. If the slave AN determines that sectors are newly added in the Active Set, then the slave AN may send an A17-Slave Attach Request message to the IP address and UDP port during connected-state session transfer with cross-connectivity support to attach to the newly added sectors. If the slave AN determines that sectors are newly dropped (e.g. the sectors are no longer included), the slave AN may send an A17-Slave Detach Request message to release cross-connectivity connection between the slave AN and the newly dropped sectors. The slave AN then sends an A16-Attributes Update Ack message back to the master AN. When the master AN receives the A16-Attributes Update Ack message from the slave AN, it stops timer Tattribupd-16. Refer to section 5.1.2.14, A16-Attributes Update Ack, for the format and content of this message. 2.6.2.14.2 Failure Operation None.
27 28 29 30 31 32 33 34 35 36 37 38
39 40 41
2-19
3GPP2 A.S0008-C v2.0

1
2.7
2.7.1
A17, A18, and A19 Interface

A17, A18, and A19 Interface Network/Transport Protocol Specification
2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
The A17 interface carries signaling information between the source AN and target AN to manage resources in support of cross-connectivity. The A17 interface establishes dedicated endpoints for the A18 and A19 interfaces. Additionally, for cross connectivity support, the A17 interface is responsible for carrying air-interface signaling messages sent by a source AN to a target AN to be transmitted to an AT on the forward control channel by a sector belonging to the target AN. The A18 interface transports user traffic (i.e., air interface traffic channel data) between the source AN and a target RT that has sectors in the ATs active set. The user traffic is transmitted to the AT on the forward traffic channel or received from the AT on the reverse traffic channel. The A19 interface carries sector-specific bearer-related cross-connectivity signaling messages between the source AN and a target RT. The A17, A18 and A19 interfaces are used together to support cross-connectivity between the source AN and the target AN. The AT_ID IE in A17, A18 and A19 messages includes LCM_UATI. The signaling protocol stack available to operators and manufacturers for the A17, A18, and A19 interfaces is: IOS Application UDP IP Link Layer Physical Layer
19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41
The following UDP port values are reserved for signaling on the A17 interface. A17 (AN-to-AN) 4599/udp - This is the registered UDP port number to be used for signaling interconnection to another AN. Reference: http://www.iana.org/assignments/port-numbers. The UDP port numbers used for the A18 and A19 interfaces are carried in A17 signaling. The destination IP address used by the source AN in an IP packet that carries an A17-Allocate Request, A17-Set Attributes, A17-Modify Request, A17-Deallocate Request, or A17-CC Packet message on the A17 interface is provisioned in the source AN. The destination IP address used by the source AN in an IP packet that carries an A17-Neighbor Information Request message on the A17 interface is also provisioned in the source AN. The destination IP address used by the target AN in an IP packet that carries an A17-Target Modify Request or A17-Target Deallocate Request message on the A17 interface shall be set to the source IP address used by the source AN in an IP packet that carried the associated A17-Allocate Request message for a specific AT. The destination IP address used by the target AN in an IP packet that carries a solicited A17-Neighbor Information Notification message on the A17 interface shall be set to the source IP address used by the source AN in an IP packet that carried the corresponding A17-Neighbor Information Request message. The destination IP address used by the target AN in an IP packet that carries an unsolicited A17-Neighbor Information Notification message on the A17 interface may be provisioned in the case where no previous A17-Neighbor Information Request message has been received. In the case where a prior A17-Neighbor Information Request message has been received, the IP address used for an unsolicited A17-Neighbor Information Notification message shall be the same address as that used in the previous A17-Neighbor Information Notification message.
2-20
3GPP2 A.S0008-C v2.0

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
The destination UDP port number used by the source AN in a UDP packet that carries an A17-Allocate Request, A17-Set Attributes, A17-Modify Request, A17-Deallocate Request, A17-CC Packet, or A17Neighbor Information Request message on the A17 interface shall be set to 4599 (refer to section 2.7.1). The destination UDP port number used by the target AN in a UDP packet that carries an A17-Target Modify Request or A17-Target Deallocate Request message on the A17 interface shall be set to the source UDP port number used by the source AN in a UDP packet that carried the associated A17-Allocate Request message for a specific AT. The destination UDP port number used by the target AN in a UDP packet that carries a solicited A17Neighbor Information Notification message on the A17 interface shall be set to the source UDP port number used by the source AN in a UDP packet that carried the corresponding A17-Neighbor Information Request message. The destination UDP port number used by the target AN in a UDP packet that carries an unsolicited A17-Neighbor Information Notification message on the A17 interface shall be set to 4599 in the case where no previous A17-Neighbor Information Request message has been received. In the case where a prior A17-Neighbor Information Request message has been received, the UDP port number used for an unsolicited A17-Neighbor Information Notification message shall be the same UDP port number as that used in the previous A17-Neighbor Information Notification message. The receiver of an A17 interface message shall set the <source UDP port, source IP address> and <destination UDP port, destination IP address> of the UDP/IP packet that carries the corresponding response or acknowledgement message to the <destination UDP port, destination IP address> and <source UDP port, source IP address> of the UDP/IP packet that carries the A17 interface message to which the receiver is responding or acknowledging. 2.7.2 A17 Message Procedures
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
This section contains message procedures used between ANs on the A17 interface. The main procedures for the A17 interface are message flows to allocate, modify, or deallocate resources at RTs belonging to the target AN in support of cross-connectivity for a specific AT. Additional procedures tunnel airinterface forward control channel signaling messages to be transmitted to the AT and obtain neighbor information from the target AN. The A17 interface consists of the following messages: A17-Allocate Request A17-Allocate Response A17-Set Attributes A17-Set Attributes Ack A17-Modify Request A17-Modify Response A17-Target Modify Request A17-Target Modify Response A17-Deallocate Request A17-Deallocate Ack A17-Target Deallocate Request A17-Target Deallocate Ack A17-CC Packet A17-Neighbor Information Request A17-Neighbor Information Notification A17-Neighbor Information Notification Ack A17-Slave Attach Request A17-Slave Attach Response A17-Slave Detach Request 2-21
3GPP2 A.S0008-C v2.0

1
A17-Slave Detach Ack A17-Allocate Request
2 3 4 5
2.7.2.1
The A17-Allocate Request message is sent by the source AN to the target AN to request the target AN to allocate resources at RTs belonging to the target AN so that the sectors belonging to those RTs can be added to an ATs Active Set. 2.7.2.1.1 Successful Operation
6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22
When the source AN decides to allocate resources at RTs belonging to the target AN so that they can be added to an ATs Active Set, it sends an A17-Allocate Request message to the target AN. The source AN then starts timer Tallocreq-17 and awaits the arrival of the A17-Allocate Response message. The A17Allocate Request message contains, among other things, Session State Information Records for the AT. The A17-Allocate Request message also contains a Proposed Session State Information Record with fields that need to be filled in by the target AN for each RT that it adds to the ATs Active Set 8. The A17Allocate Request message also contains the AN A19 Control Endpoint ID and AN A18 Data Endpoint ID of the source AN. When the source AN attaches sectors to the existing leg and/or detaches sectors from the existing leg, it shall send an A17-Allocate Request message to the target AN. The A17-Allocate Request message includes information on all sector information for the call, both those already attached, and those to be attached. Sectors to be released are not included in the A17-Allocate Request message. The source AN shall only include sectors belonging to the same RT into the same leg in the A17-Allocate Request message. The information on which sectors belong to which RT may be obtained by an A17Neighbor Information Request or by provisioning. Refer to section 5.1.3.1, A17-Allocate Request, for the format and content of this message. 2.7.2.1.2 Failure Operation
23 24 25 26
If timer Tallocreq-17 expires, the source AN may resend the A17-Allocate Request message to the target AN and restart timer Tallocreq-17 a configurable number of times. If the A17-Allocate Response message is not received from the target AN, the source AN may choose other actions with respect to the AT. 2.7.2.2 A17-Allocate Response
27 28 29 30
The A17-Allocate Response message is sent by the target AN to the source AN to accept or reject a request for the target AN to allocate resources at RTs belonging to the target AN so that they can be added to an ATs Active Set. 2.7.2.2.1 Successful Operation
31 32 33 34 35 36 37 38 39 40
When the target AN receives an A17-Allocate Request message requesting it to allocate resources at RTs belonging to the target AN so that they can be added to an ATs Active Set, the target AN determines whether it supports the necessary protocol configurations and has sufficient resources to do this. If the target AN decides that it can add the RTs to an ATs Active Set, it responds to the source AN by sending an A17-Allocate Response message to the source AN. The A17-Allocate Response message contains, among other things, the Proposed Session State Information Record included in the A17Allocate Request message with fields filled in by the target AN for each RT that the target AN adds to the ATs Active Set. The A17-Allocate Response message also contains the RT A19 Control Endpoint ID and RT A18 Data Endpoint ID for each RT that the target AN adds to the ATs Active Set.
If Default RouteUpdate protocol is in use, the Proposed Session State Information Record contains the RouteUpdate Parameter Record [10] and the target AN shall fill out values for either MACIndex or MACIndexLSB and MACIndexMSB [10] as appropriate in the A17-Allocate Response message.
2-22
3GPP2 A.S0008-C v2.0

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
If the target AN decides that it cannot add the RTs to an ATs Active Set, it responds to the source AN by sending an A17-Allocate Response message to the source AN without filling in fields of the Proposed Session State Information Record for those RTs and without including an RT A19 Control Endpoint ID and RT A18 Data Endpoint ID for those sectors. When the target AN receives the A17-Allocate Request message attaching sectors to the existing leg and/or detaching sectors from the existing leg, it shall send an A17-Allocate Response message to the source AN. The A17-Allocate Response message includes information on all sector information for the call, both those already attached, and those to be attached. Sectors to be released are not included in the A17-Allocate Response message. The target AN shall not modify the mapping between legs and sectors when it sends an A17-Allocate Response message. The source AN stops timer Tallocreq-17 upon receipt of the A17-Allocate Response message. The target AN starts timer Twaitacq-17 when it sends the A17-Allocate Response message when a new leg is established between the source AN and the target AN during HRPD connection setup. Note that the target AN shall determine that the A17-Allocation Request message is sent because of HRPD connection setup by the content of SSIR. The timer Twaitacq-17 is not used for a leg addition when the AT is in Connected State. Refer to section 5.1.3.2, A17-Allocate Response, for the format and content of this message. 2.7.2.2.2 Failure Operation
18 19 20
If the timer Twaitacq-17 expires, the target AN may discontinue the procedure and start the release procedure. Refer to section 2.7.2.11 for the procedure of A17-Target Deallocate Request message. 2.7.2.3 A17-Set Attributes
21 22 23 24 25 26 27 28 29
The A17-Set Attributes message is sent by the source AN to the target AN to: Update resources at sectors belonging to the target AN that are part of an ATs Active Set. Send RTCH power control information to the target AN for sectors belonging to the target AN that are part of an ATs Active Set. Send an indication during connection setup to a target AN with sectors in the ATs Active Set that the ATs reverse traffic channel has been acquired. Send power ramp-up bias information to the target AN for sectors belonging to the target AN that are part of an ATs Active Set. 2.7.2.3.1 Successful Operation
30 31 32 33 34 35 36 37 38 39 40 41
When the source AN decides to update resources at sectors belonging to the target AN that are part of an ATs Active Set, it sends an A17-Set Attributes message to the target AN. The source AN then starts timer Tsetattrib-17 and awaits the arrival of the A17-Set Attributes Ack message. The source AN may send the A17-Set Attributes message to the target AN for this purpose after having received an A17-Allocate Response message, A17-Modify Response message, or A17-Deallocate Ack message from the target AN. The A17-Set Attributes message contains, among other things, Session State Information Records or Alternative Session State Information Records. The Session State Information Records are included when the A17-Set Attributes message serves as a four-way handshake (use of A17-Modify Request, A17Modify Response, A17-Set Attribute and A17-Set Attribute Ack) for the resource allocation procedure or the resource modification procedure. The Alternative Session State Information Records (comprising old and new Session State Information Records) are included when the target AN does not know
2-23
3GPP2 A.S0008-C v2.0

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
exactly when the value of some parameters take effect until the ATs traffic channels are updated 9, e.g., TrafficChannelAssignment message [10] is received at the AT. When the source AN decides to send RTCH power control information 10 to the target AN for sectors belonging to it that are part of an ATs Active Set, it sends an A17-Set Attributes message to the target AN. The source AN may send the A17-Set Attributes message to the target AN for this purpose periodically. When an RT in the ATs active set acquires the ATs reverse traffic channel during connection setup, the source AN is notified via an A19-Acquisition Status message from the corresponding target AN (or the equivalent for sectors belonging to the source AN). The source AN then sends the A17-Set Attributes message including the AT Acquired Flag IE to the other target ANs that have sectors in the ATs Active Set to notify them that the ATs reverse traffic channel has been acquired. When the source AN decides to send power ramp-up bias information 11 to the target AN for sectors belonging to the target AN that are part of an ATs Active Set, it sends an A17-Set Attributes message to the target AN. The source AN may send the A17-Set Attributes message to the target AN for this purpose during connection setup after having received an A17-Allocate Response message from the target AN. Upon sending the A17-Set Attributes message, the source AN starts timer Tsetattrib-17 and awaits the arrival of the A17-Set Attributes Ack message. The target AN stops timer Twaitacq-17 if it is running, upon receipt of the A17-Set Attributes message including AT Acquired Flag. Refer to section 5.1.3.3, A17-Set Attributes, for the format and content of this message. 2.7.2.3.2 Failure Operation
21 22 23 24
If timer Tsetattrib-17 expires, the source AN may resend the A17-Set Attributes message to the target AN and restart timer Tsetattrib-17 a configurable number of times. If the A17-Set Attributes Ack message is not received from the target AN, the source AN may choose other actions with respect to the AT. 2.7.2.4 A17-Set Attributes Ack
25 26 27
The A17-Set Attributes Ack message is sent by the target AN to the source AN to acknowledge the receipt of the A17-Set Attributes message from the source AN. 2.7.2.4.1 Successful Operation
28 29 30 31
When the source AN receives an A17-Set Attributes Ack message from the target AN, it stops timer Tsetattrib-17. Refer to section 5.1.3.4, A17-Set Attributes Ack, for the format and content of this message. 2.7.2.4.2 None. Failure Operation
32 33
9 10 11
In Default RouteUpdate protocol [10], the DRCLength parameter [10] being used by the AT is not known until the traffic channels are updated. For example, the sectors will attempt to power control the AT via power control decisions sent on the forward link so that the received pilot Eo/Nt matches the supplied value [10]. For example, this helps the sectors achieve a certain power ramp-up bias during connection setup by having them send power up and down commands pseudo-randomly with a bias towards the up command, where the power up and down commands are sent on the Reverse Power Control Channel (RPC) as defined in [10].
2-24
3GPP2 A.S0008-C v2.0

1 2 3 4 5 6
2.7.2.5
A17-Modify Request
The A17-Modify Request message is sent by the source AN to the target AN to request modification of resources at target sectors that are in the ATs Active Set. If the source AN knows that the target AN will accept the resource modification request, then the source AN may skip sending A17-Modify Request and simply send an A17-Set Attributes message instructing the target AN to update its resources. One use of this message is to request adding or deleting Link Flows. 2.7.2.5.1 Successful Operation
7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22
When the source AN wants to modify resources at target sectors in the ATs Active Set, and it does not know whether the target AN will accept, the source AN sends an A17-Modify Request message to the target AN that includes the proposed changes in one or more Proposed Session State Information Records. If there are sectors belonging to more than one target AN that are part of the ATs Active Set that the source AN sends an A17-Modify Request message to, the source AN shall indicate to the target AN (using the Rapid Commit IE) that the target AN shall wait until receiving an A17-Set Attributes message from the source AN containing Session State Information Records before modifying resources. The A17-Modify Request message includes the Rapid Commit IE, which specifies whether the target AN shall wait for the actual changes to be sent in an A17-Set Attributes message before modifying resources. For example, the source AN may specify to wait for an A17-Set Attributes message if there are multiple ANs with sectors in the ATs Active Set. The source AN uses the A17-Modify Response messages from each target AN to determine what resource modifications can be done by all of the target ANs and then notifies the target ANs using the A17-Set Attributes message. The source AN starts timer Tmodreq-17 upon sending the A17-Modify Request message. Refer to section 5.1.3.5, A17-Modify Request, for the format and content of this message. 2.7.2.5.2 Failure Operation
23 24 25 26
If timer Tmodreq-17 expires, the source AN may resend the A17-Modify Request message to the target AN and restart timer Tmodreq-17 a configurable number of times. If the A17-Modify Response message is not received from the target AN, the source AN may choose other actions with respect to the AT. 2.7.2.6 A17-Modify Response
27 28 29
The A17-Modify Response message is sent by the target AN to accept, modify, or reject a request from the source AN to modify resources at the target sectors that are in the ATs Active Set. 2.7.2.6.1 Successful Operation
30 31 32 33 34 35
Upon receipt of an A17-Modify Request message requesting modification of resources at sectors in the ATs Active Set, the target AN determines whether it has sufficient resources to accept the request. The target AN responds by sending the A17-Modify Response message to the source AN. The source AN stops timer Tmodreq-17 upon receipt of the A17-Modify Response message. Refer to section 5.1.3.6, A17-Modify Response, for the format and content of this message. 2.7.2.6.2 None. 2.7.2.7 A17-Target Modify Request Failure Operation
36 37
38 39 40
The A17-Target Modify Request message is sent by the target AN to the source AN to request modification of resources at its own sectors that are in the ATs Active Set.
2-25
3GPP2 A.S0008-C v2.0

1 2 3 4 5 6 7
2.7.2.7.1
When the target AN wants to modify resources at its own sectors that are in the ATs Active Set, it sends an A17-Target Modify Request message to the source AN that includes the proposed changes in one or more Proposed Session State Information Records. The target AN starts timer Ttgtmodreq-17 upon sending the A17-Target Modify Request message and awaits the arrival of the A17-Target Modify Response message. Refer to section 5.1.3.7, A17-Target Modify Request, for the format and content of this message. 2.7.2.7.2 Failure Operation
8 9 10 11 12
If timer Ttgtmodreq-17 expires, the target AN may resend the A17-Target Modify Request message to the source AN and restart timer Ttgtmodreq-17 a configurable number of times. If the A17-Target Modify Response message is not received from the source AN, the target AN may choose other actions with respect to the AT. 2.7.2.8 A17-Target Modify Response
13 14 15 16 17
The A17-Target Modify Response message is sent by the source AN to the target AN to accept, modify, or reject a request from the target AN to modify resources at the targets own sectors that are in the ATs Active Set. To determine the response, the source AN must first consider whether the requested changes are acceptable to all other ANs (including itself) that have sectors in the ATs active set. 2.7.2.8.1 Successful Operation
18 19 20 21 22 23 24 25 26
Upon receiving an A17-Target Modify Request message, the source AN must first consider whether all other ANs (including itself) with sectors in the ATs active set have sufficient resources for the requested changes. The source AN may send an A17-Modify Request message to any other target ANs that have sectors in the ATs active set to determine this. Refer to section 2.7.2.5. The source AN then responds to the A17-Target Modify Request message by sending an A17-Target Modify Response message to the target AN. The source AN stops timer Ttgtmodreq-17 upon receipt of the A17-Target Modify Response message. Refer to section 5.1.3.8, A17-Target Modify Response, for the format and content of this message. 2.7.2.8.2 None. 2.7.2.9 A17-Deallocate Request Failure Operation
27 28
29 30 31
The A17-Deallocate Request message is sent by the source AN to the target AN to deallocate resources at RTs belonging to the target AN that are part of an ATs Active Set. 2.7.2.9.1 Successful Operation
32 33 34 35 36 37 38
When the source AN decides to deallocate resources at RTs belonging to the target AN that are part of an ATs Active Set, it sends an A17-Deallocate Request message to the target AN. The source AN then starts timer Tdeallocreq-17 and awaits the arrival of the A17-Deallocate Ack message. The A17-Deallocate Request message contains, among other things, sector information comprising the leg numbers of sectors whose resources are to be deallocated and a Deallocation Timer IE 12 to indicate when the resources at the sectors can be deallocated.
12
For example, if the value of this element is non-zero, then each sector that the source AN is requesting resource deallocation for shall immediately indicate to the AT that the air-interface resources allocated to it at that sector have been deallocated (footnote continued on next page)
2-26
3GPP2 A.S0008-C v2.0

1
Refer to section 5.1.3.9, A17-Deallocate Request, for the format and content of this message. 2.7.2.9.2 Failure Operation
2 3 4 5 6
If timer Tdeallocreq-17 expires, the source AN may resend the A17-Deallocate Request message to the target AN and restart timer Tdeallocreq-17 a configurable number of times. If the A17-Deallocate Ack message is not received from the target AN, the source AN may choose other actions with respect to the AT. 2.7.2.10 A17-Deallocate Ack
7 8 9
The A17-Deallocate Ack message is sent by the target AN to the source AN to acknowledge the receipt of the A17-Deallocate Request message from the source AN. 2.7.2.10.1 Successful Operation When the source AN receives an A17-Deallocate Ack message from the target AN, it stops timer Tdeallocreq-17. Refer to section 5.1.3.10, A17-Deallocate Ack, for the format and content of this message. 2.7.2.10.2 Failure Operation None. 2.7.2.11 A17-Target Deallocate Request
10 11 12 13
14 15
16 17 18
The A17-Target Deallocate Request message is sent by the target AN to the source AN to deallocate resources at RTs belonging to the target AN that are part of an ATs Active Set. 2.7.2.11.1 Successful Operation When the target AN decides to deallocate resources at RTs belonging to the target AN that are part of an ATs Active Set, it sends an A17-Target Deallocate Request message to the source AN. The target AN then starts timer Ttgtdeallocreq-17 and awaits the arrival of the A17-Target Deallocate Ack message. The A17-Target Deallocate Request message contains, among other things, sector information comprising the leg numbers of sectors whose resources are to be deallocated. Refer to section 5.1.3.11, A17-Target Deallocate Request, for the format and content of this message. 2.7.2.11.2 Failure Operation If timer Ttgtdeallocreq-17 expires, the target AN may resend the A17-Target Deallocate Request message to the source AN and restart timer Ttgtdeallocreq-17 a configurable number of times. If the A17-Target Deallocate Ack message is not received from the source AN, the target AN may choose other actions with respect to the AT. 2.7.2.12 A17-Target Deallocate Ack
19 20 21 22 23 24 25
26 27 28 29 30
31 32 33
The A17-Target Deallocate Ack message is sent by the source AN to the target AN to acknowledge the receipt of the A17-Deallocate Request message from the target AN.
and subsequently deallocate resources after Deallocation Timer milliseconds have elapsed. Each sector indicates to the AT that the air-interface resources have been deallocated by setting the ForwardTrafficValid field associated with the ATs MACIndex to zero for x milliseconds via the QuickConfig message as defined in [10]. Otherwise, each sector shall immediately deallocate resources upon receiving the A17-Deallocate Request message.
2-27
3GPP2 A.S0008-C v2.0

1 2 3 4
2.7.2.12.1 Successful Operation When the target AN receives an A17-Target Deallocate Ack message from the source AN, it stops timer Ttgtdeallocreq-17. Refer to section 5.1.3.12, A17-Target Deallocate Ack, for the format and content of this message. 2.7.2.12.2 Failure Operation None. 2.7.2.13 A17-CC Packet
5 6
7 8 9 10
The A17-CC Packet message is sent by the source AN to the target AN to request that a specific sector(s) belonging to the target AN transmit signaling information to a specific AT on the forward control channel. 2.7.2.13.1 Successful Operation When the source AN has signaling information to send to an AT via specific sectors belonging to the target AN on the forward control channel, it sends an A17-CC Packet message to the target AN. The A17CC Packet message contains, among other things, sector information comprising the leg numbers of the sectors that are being requested to transmit the signaling information to a specific AT. The A17-CC Packet message also contains air-interface signaling header information 13, the type of forward control channel capsule to be used to transmit the signaling information to the AT, and the actual signaling information 14. Refer to section 5.1.3.13, A17-CC Packet, for the format and content of this message. 2.7.2.13.2 Failure Operation None. 2.7.2.14 A17-Neighbor Information Request
11 12 13 14 15 16 17 18 19
20 21
22 23 24 25 26
The A17-Neighbor Information Request message is sent by the source AN to the target AN to request neighbor information for sectors belonging to the target AN. The A17-Neighbor Information Request message may be sent simultaneously with an initial A17-Allocate Request message that is sent to the target AN (i.e., during the activation of an initial cross-connectivity session with the target AN). 2.7.2.14.1 Successful Operation When the source AN requests neighbor information for sectors belonging to the target AN, it sends an A17-Neighbor Information Request message to the target AN. The source AN then starts timer Tneighbor17 and awaits the arrival of the A17-Neighbor Information Notification message. The A17-Neighbor Information Request message contains, among other things, sector information comprising the Pilot PN and Channel of the sectors for which neighbor information is being requested. The A17-Neighbor Information Request also contains the IPv4 address of the source AN to which the target AN is to send unsolicited A17-Neighbor Information Notification messages. Refer to section 5.1.3.14, A17-Neighbor Information Request, for the format and content of this message.
27 28 29 30 31 32 33 34 35
13 For example, the Air-Interface Signaling Header field contains SLP-D header information as defined in [10] that is used by an RT to construct the header of the SLP-D packet. 14 For example, the Application Layer Payload field contains the upper layer signaling information that an RT will encapsulate in an SLP-D packet as defined in [10].
2-28
3GPP2 A.S0008-C v2.0

1 2 3 4 5
2.7.2.14.2 Failure Operation If timer Tneighbor-17 expires, the source AN may resend the A17-Neighbor Information Request message to the target AN and restart timer Tneighbor-17 a configurable number of times. If the A17-Neighbor Information Notification message is not received from the target AN, the source AN may choose other actions. 2.7.2.15 A17-Neighbor Information Notification
6 7 8 9 10
The A17-Neighbor Information Notification message is sent by the target AN to the source AN in response to an A17-Neighbor Information Request message from the source AN. This message is also sent from the target AN to the source AN when the target AN wants to send unsolicited neighbor information to the source AN for sectors belonging to the target AN. 2.7.2.15.1 Successful Operation When the target AN receives an A17-Neighbor Information Request message requesting it to provide neighbor information to the source AN for sectors belonging to the target AN, the target AN responds to the source AN by sending an A17-Neighbor Information Notification message to the source AN. The target AN then starts timer Tneighbor-17 and awaits the arrival of the A17-Neighbor Information Notification Ack message. Upon receiving the A17-Neighbor Information Notification message, the source AN stops timer Tneighbor-17. The target AN shall send an unsolicited A17-Neighbor Information Notification message to the source AN in the event that the neighbor information for sectors belonging to the target AN has changed. The target AN shall send an unsolicited A17-Neighbor Information Notification message to the source AN as long as the source AN has active cross-connectivity sessions with the target AN. The target AN then starts timer Tneighbor-17 and awaits the arrival of the A17-Neighbor Information Notification Ack message. The source AN may store the neighbor information received in the A17-Neighbor Information Notification message for later use. However, the source AN shall not expect to receive unsolicited A17Neighbor Information Notification messages if there are no active cross-connectivity sessions between the source AN and the target AN. In both cases, the A17-Neighbor Information Notification message contains, among other things, sector information comprising the Pilot PN and Channel of the sectors for which neighbor information is included in addition to the neighbor information itself. The neighbor information in turn comprises sector information (i.e., Pilot PN and Channel) for the neighbor sectors along with the IPv4 addresses for each neighbor sector to be used by the source AN as the destination IP address of the A17 interface and A16 interface at the target AN. Refer to section 5.1.3.15, A17-Neighbor Information Notification, for the format and content of this message. 2.7.2.15.2 Failure Operation If timer Tneighbor-17 expires, the target AN may resend the A17-Neighbor Information Notification message to the source AN and restart timer Tneighbor-17 a configurable number of times. If the A17Neighbor Information Notification Ack message is not received from the source AN, the target AN may choose other actions. 2.7.2.16 A17-Neighbor Information Notification Ack
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
The A17-Neighbor Information Notification Ack message is sent by the source AN to the target AN to acknowledge the receipt of the A17-Neighbor Information Notification message from the target AN. 2.7.2.16.1 Successful Operation When the target AN receives an A17-Neighbor Information Notification Ack message from the source AN, it stops timer Tneighbor-17. 2-29
43 44 45
3GPP2 A.S0008-C v2.0

1 2
Refer to section 5.1.3.16, A17-Neighbor Information Notification Ack, for the format and content of this message. 2.7.2.16.2 Failure Operation None. 2.7.2.17 A17-Slave Attach Request
3 4
5 6 7 8
The A17-Slave Attach Request message is sent from the slave AN to the master AN or another target AN to request connection to the existing A17-A19 resources at sectors belonging to the master AN or another target AN that have already been allocated for a specific AT. 2.7.2.17.1 Successful Operation When a target AN becomes the slave AN, it sends the A17-Slave Attach Request message to establish connections to all sectors in the active set. These connections will be used for cross-connectivity upon session transfer, when the target AN becomes the master AN. The slave AN then starts timer Tallocreq-17 and awaits the arrival of the A17-Slave Attach Response message. The A17-Slave Attach Request message contains, among other things, the AN Control Endpoint ID and AN Data Endpoint ID of the slave AN. Refer to section 5.1.3.17, A17-Slave Attach Request, for the format and content of this message. 2.7.2.17.2 Failure Operation If timer Tallocreq-17 expires, the slave AN may resend the A17-Slave Attach Request message to the master AN or another target AN and restart timer Tallocreq-17 a configurable number of times. If the A17Slave Attach Response message is not received from the master AN or another target AN, the slave AN may choose other actions with respect to the AT. 2.7.2.18 A17-Slave Attach Response
9 10 11 12 13 14 15 16
17 18 19 20 21
22 23 24
The A17-Slave Attach Response message is sent by the master AN or another target AN to the slave AN in response to an A17-Slave Attach Request message from the slave AN. 2.7.2.18.1 Successful Operation When the master AN or another target AN receives an A17-Slave Attach Request message requesting connection to existing resources at sectors belonging to the master AN or another target AN that have already been allocated for a specific AT, the master AN or another target AN sends an A17-Slave Attach Response message to the slave AN. The A17-Slave Attach Response message contains, among other things, the RT Control Endpoint ID and RT Data Endpoint ID for each sector that the master AN or another target AN has already allocated resources for a specific AT. When the slave AN receives the A17-Slave Attach Response message, it stops timer Tallocreq-17. Refer to section 5.1.3.18, A17-Slave Attach Response, for the format and content of this message. 2.7.2.18.2 Failure Operation None. 2.7.2.19 A17-Slave Detach Request
25 26 27 28 29 30 31 32 33
34 35
36 37 38
The A17-Slave Detach Request message is sent from the slave AN to the master AN or another target AN to release cross-connectivity connections between the slave AN and the master AN or another target AN.
2-30
3GPP2 A.S0008-C v2.0

1 2 3 4 5
2.7.2.19.1 Successful Operation When the slave AN needs to release the resources on the A17-A19 interfaces with the master AN and/or another ANs, the slave AN sends an A17-Slave Detach Request message to those ANs, starts timer Tdeallocreq-17 and awaits the arrival of the A17-Slave Detach Ack message. Refer to section 5.1.3.19, A17-Slave Detach Request, for the format and content of this message. 2.7.2.19.2 Failure Operation If timer Tdeallocreq-17 expires, the slave AN may resend the A17-Slave Detach Request message to the master AN or another target AN and restart timer Tdeallocreq-17 a configurable number of times. If the A17-Slave Detach Ack message is not received from the master AN or another target AN, the slave AN may release resources related to the AT. 2.7.2.20 A17-Slave Detach Ack
6 7 8 9 10
11 12 13
The A17-Slave Detach Ack message is sent by the master AN or another target AN to the slave AN to acknowledge the receipt of an A17-Slave Detach Request message from the slave AN. 2.7.2.20.1 Successful Operation When the master AN or another target AN receives an A17-Slave Detach Request message, it releases the cross-connectivity connections requested in the message. The master AN or another target AN also sends an A17-Slave Detach Ack message to the slave AN. When the slave AN receives the A17-Slave Detach Ack message, it stops timer Tdeallocreq-17. Refer to section 5.1.3.20, A17-Slave Detach Ack, for the format and content of this message. 2.7.2.20.2 Failure Operation None.
14 15 16 17 18 19
20 21 22
23 24 25 26 27 28 29 30 31 32 33 34 35
2.7.3
A18 Message Procedures
This section describes message procedures used on the A18 interface. The A18 interface transports user traffic between the source AN and a target RT that is to be transmitted to the AT on the forward traffic channel or that has been received from the AT on the reverse traffic channel. The A18 interface consists of the following messages: A18-FTCH Packet A18-RTCH Packet The destination IP address and UDP port number used by the source AN in an IP packet that carries an A18-FTCH Packet message on the A18 interface is obtained by the source AN in the A17-Allocate Response message (specifically, the RT A18 Data Endpoint ID). The destination IP address and UDP port number used by the target AN in an IP packet that carries an A18-RTCH Packet message on the A18 interface is obtained by the target AN in the A17-Allocate Request message (specifically, the AN A18 Data Endpoint ID). 2.7.3.1 A18-FTCH Packet
36 37 38 39 40
The A18-FTCH Packet message is sent by the source AN to the target AN to request an RT belonging to the target AN that is part of an ATs Active Set to transmit signaling or data information to the AT on the forward traffic channel. The A18-FTCH Packet message contains the signaling or data information that needs to be transmitted to the AT on the forward traffic channel.
2-31
3GPP2 A.S0008-C v2.0

1 2 3 4 5 6 7 8 9 10 11
2.7.3.1.1
When the source AN has signaling or data information to send to an AT via a specific sector belonging to the target AN, it sends an A18-FTCH Packet message to the target RT. The A18-FTCH Packet message contains, among other things, queue information. The A18-FTCH Packet message also contains either airinterface signaling header information 15 or air-interface application header information 16 and either the actual signaling information 17 or the actual data information 18. Additionally, the A18-FTCH Packet message contains control information to be used by the target RT during both unicast and multicast transmission from the source AN. The Packet ID in the FTCH Packet Control Information IE shall be incremented by one every time per unique application type when the source AN sends an A18-FTCH Packet message. Refer to section 5.1.4.1, A18-FTCH Packet, for the format and content of this message 2.7.3.1.2 None. 2.7.3.2 A18-RTCH Packet Failure Operation
12 13
14 15 16 17 18
The A18-RTCH Packet message is sent by the target AN to the source AN after an RT belonging to the target AN that is part of an ATs Active Set has received signaling or data information from the AT on the reverse traffic channel. The A18-RTCH Packet message contains the decoded signaling or data information that has been received from the AT on the reverse traffic channel. 2.7.3.2.1 Successful Operation
19 20 21 22 23 24 25 26 27 28 29
When the target AN has decoded signaling or data information from an AT to send to the source AN, it sends an A18-RTCH Packet message to the source AN. The A18-RTCH Packet message contains, among other things, control information to be used by the source AN to discard duplicate reverse traffic channel packets received from different sectors when the AT is in soft handoff and to provide an estimation of round trip delay that allows the source AN to assist new sectors that belong to the target AN with the acquisition of the AT. For Subtype 2 Physical Layer protocol [10], the A18-RTCH Packet message also contains the sub-packet number and interlace number for the packet decoded and the status of packets being decoded on the other two interlaces 19. Additionally, the A18-RTCH Packet message contains the actual data information 20. Refer to section 5.1.4.2, A18-RTCH Packet, for the format and content of this message.
15 For example, the Air-Interface Signaling Header field contains SLP-D header information as defined in [10] that is used by the sector to construct the header of the SLP-D packet. This information is included if the stream number is 00. 16 For example, the Air-Interface Application Header field contains RLP header information as defined in [20], [10] that is used by the sector to construct the header of the RLP packet. This information is included if the stream number is 01, 10, or 11. 17 18 19 For example, if the stream number is 00, the Application Layer Payload field contains the upper layer signaling information that an RT will encapsulate in an SLP-D packet as defined in [10]. For example, if the stream number is 01, 10, or 11, the Application Layer Payload field contains the upper layer data information that an RT will encapsulate in an RLP packet as defined in [20], [10]. For example, for an ATs RLP flow that is configured to send NAKs [20], [10] the source AN may use the information to determine how long to delay sending an RLP NAK upon detecting a hole in the RLP sequence space. Conversely, an RLP flow configured not to send NAKs may use the information to determine how long to delay sending data to the upper layer protocols upon detecting a hole in the RLP sequence space. For example, the Application Layer Payload field contains the MAC Layer packet as defined in [10].
20
2-32
3GPP2 A.S0008-C v2.0

1 2
2.7.3.2.2 None. 2.7.4
Failure Operation
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
A19 Message Procedures
This section describes message procedures used on the A19 interface. The A19 interface carries bearerrelated cross-connectivity signaling messages between the source AN and a target RT such as serving RT switching and notification of when an RT has acquired or lost the ATs reverse traffic channel. The A19 interface consists of the following messages: A19-Acquisition Status A19-Acquisition Status Ack A19-Serving RT Changed A19-Serving RT Changed Ack A19-Forward Desired A19-Forward Desired Ack A19-Forward Stopped A19-Forward Stopped Ack A19-Flush A19-Flush Ack A19-Purge A19-Purge Ack The destination IP address and UDP port number used by the source AN in an IP packet that carries an A19-Flush message on the A19 interface is obtained by the source AN in the A17-Allocate Response message (specifically, the RT A19 Control Endpoint ID). The destination IP address and UDP port number used by the target AN in an IP packet that carries an A19-Acquisition Status, A19-Serving RT Changed, A19-Forward Desired, A19-Forward Stopped, or A19-Purge message on the A19 interface is obtained by the target AN in the A17-Allocate Request message (specifically, the AN A19 Control Endpoint ID). The receiver of the A19-Flush message shall set the <source port, source IP address> and <destination port, destination IP address> of the UDP packet that carries the corresponding A19-Flush Ack message to the <destination port, destination IP address> and <source port, source IP address> of the UDP packet that carried the A19-Flush message, respectively. The receiver of the A19-Acquisition Status, A19-Serving RT Changed, A19-Forward Desired, A19Forward Stopped, or A19-Purge message shall set the <source port, source IP address> and <destination port, destination IP address> of the UDP packet that carries the corresponding A19 Ack messages to the <destination port, destination IP address> and <source port, source IP address> of the UDP packet that carried the A19-Acquisition Status, A19-Serving RT Changed, A19-Forward Desired, A19-Forward Stopped, or A19-Purge message, respectively. 2.7.4.1 Serving RT Switching Procedure
37 38 39 40 41 42 43 44 45 46
When the serving RT changes, the source AN stops sending data packets to the current serving RT and it starts sending packets to the new serving RT. It is desirable to minimize the interruption when serving the data packets to the AT due to such a change in the serving RT. Such interruption can be minimized by having the source AN start to send packets to the new serving RT prior to having it stop sending packets to the current serving RT. The air-interface specification [10] allows the AT to send an early indication to the source AN as to which RT is about to become the serving RT. This standard mandates the messages and parameters that a target AN shall send to the source AN and their corresponding triggers to support the functionality mentioned above. The actions taken by the source AN upon reception of such triggers from a target AN are left to the source AN and are not mandated by 2-33
3GPP2 A.S0008-C v2.0

1 2 3 4 5 6 7 8 9
this specification. This standard, however, specifies recommended procedures for the source AN to follow to minimize the interruption due to a change in the serving RT. In the following procedures, we refer to the source AN receiving messages from an RT. It should be noted that if the sector belongs to the source AN, then such messages are exchanged between the source AN and its RT and are part of the source AN-source RT interface and, hence, are beyond the scope of this standard (i.e., the source AN can choose its own proprietary messages to communicate with its RTs). Similarly, in the following procedures, we refer to the source AN sending messages to the RTs. When the RT belongs to the source AN, then such messages are exchanged between the source AN and its RT and are part of the source AN-source RT interface and, hence, are beyond the scope of this standard. 2.7.4.1.1 Candidate Serving Set
10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25
If the source AN chooses not to perform multicasting, it does not need to maintain the Candidate Serving Set. A Candidate Serving Set is defined to be a subset of the ATs Active Set whose members are added to and deleted from the Candidate Serving Set according to the following rules. The Candidate Serving Set is maintained only by the source AN. The number of members of this set is used by the source AN to determine whether or not it should start the multicast as described in section 2.7.4.1.2 An RT that is in the ATs Active Set is added to the Candidate serving Set if it indicates to the source AN that it has successfully determined that the AT has chosen it as the serving RT. A target RT indicates this event to the source AN by sending an A19-Forward Desired message. A source RT indicates this event to the source AN using a source AN-source RT interface that is beyond the scope of this standard 21. An RT is deleted from the Candidate serving Set when the RT has determined that the AT has chosen another RT as the serving RT. A target RT indicates this event to the source AN by sending an A19Forward Stopped message to the source AN. A source RT indicates this event to the source AN using a source AN-source RT interface that is beyond the scope of this standard. Recommended Multicasting Procedure
26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43
2.7.4.1.2
This section specifies the recommended set of rules for the source AN for starting and stopping the multicast to the RTs in the ATs Active Set if the source AN chooses to perform multicasting (e.g., for the delay-sensitive flows). Note that multicasting here refers to sending unicast A18-FTCH Packet messages to the target ANs that own an RT in the ATs Active Set and does not refer to IP multicasting. The source AN starts multicasting the packets destined to the AT (if not multicasting already) to the RTs in the ATs Active Set (through their respective target ANs or directly using the A18 interface) once any of the following is satisfied: If the serving RT indicates that it is either unable to determine which RT the AT has chosen as the serving RT, or if the serving RT indicates that the AT may have chosen another RT as the serving RT. A target RT indicates this event to the source AN by sending an A19-Serving RT Changed message to the source AN. A source RT indicates this event to the AN using a source AN-source RT interface that is beyond the scope of this standard. If the serving RT indicates that AT has chosen another RT as the serving RT and after reception of such indication the Candidate Serving Set is empty. A target RT indicates this event (i.e., the AT choosing another RT as the serving RT) to the source AN by sending an A19-Forward Stopped message to the source AN. A source RT indicates this event to the AN using a source AN-source RT interface that is beyond the scope of this standard.
21 While it is not mandated in this specification, the A19-Serving RT Changed, A19-Forward Desired, A19-Forward Stopped, etc. messages can be used for the source AN-source RT interface.
2-34
3GPP2 A.S0008-C v2.0

1 2 3 4 5 6 7 8
The source AN starts multicasting from the octet that the last serving RT has served to the AT. The serving RT indicates the last octet that it has served to the AT in one of the indications specified above. The source AN stops multicasting to the sectors in the ATs Active Set when there is exactly one RT in the Candidate Serving Set and that RT has not sent an A19-Serving RT Changed message since the last time that it had sent an A19-Forward Desired message to the source AN. The source AN sends an A19-Flush message to all the RTs in the ATs Active Set that are not in the Candidate Serving Set upon stopping the multicast to the RTs. The A19-Flush message specifies the forward link flow to which it applies. 2.7.4.1.3 Data Transmission Group and its Attributes
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
The Data Transmission Group (DTG) is a concept introduced to define the behavior of the target RTs with respect to the processing forward link packets (i.e., A18-FTCH Packet messages). A DTG is per forward link flow and per an RT and is defined to be a collection of forward link packets associated with the forward link flow that the source AN sends to the RT such that they satisfy either of the following conditions: Forward link packets associated with the flow that the source AN sends to the RT between the time that the source AN determines that a flow has been allocated in that RT and the time that the source AN sends the first A19-Flush message (after allocation) to the RT. Forward link packets associated with the flow that the source AN sends to the RT between two consecutive A19-Flush messages to the RT for the forward link flow. There are two attributes associated with a DTG: DTG First Packet ID: This is the Packet ID associated with the first packet in a DTG. The source AN includes this parameter in the A18-FTCH Packet message so that a target AN can determine any potential missing packets in the DTG. The target AN may choose to delay the delivery of packets in a DTG if it determines that there are missing packets in a DTG. Note that an A18-FTCH Packet message may be erased or delivered out-of-order to a target AN and a target AN cannot detect such events without the DTG First Packet ID parameter. DTG Tag: o The source AN shall initialize this parameter to zero for the first DTG associated with an RT and its flow. o The source AN then shall increment the value of this parameter when the DTG ends. o The target AN shall consider a forward link packet that it has received in an A18-FTCH Packet message a duplicate if it receives a forward link packet associated with the DTG with the same <DTG Tag, PacketID> tuple. o The target AN shall discard forward link packets that it receives in an A18-FTCH Packet message if the value of the DTG Tag field in the message is smaller 22 than the last value of the DTG Tag parameter associated with the DTG. o The target RT shall update the last DTG Tag value only for the packets that it does not discard. The DTG Tag allows the target AN to determine which packets are duplicates and which packets belong to a previous DTG. Figure 2.7.4.1.3-1 shows an example in which the DTG Tag helps the target AN to determine if certain packets belong to a previous DTG and, hence, should be discarded.
22
The comparison shall be carried out in unsigned modulo 2n, where n is the length of the DTG Tag parameter in the A18FTCH Packet message. For DTG Tag equal to N, the numbers in the range [N+1, N+2n-1-1] shall be considered greater than N and the numbers in the range [N-2n-1, N-1] shall be considered smaller than N.
2-35
3GPP2 A.S0008-C v2.0

Packet ID rolls over DTG Tag=5, Packet ID=313 Transmitted by the source AN DTG Tag=5, Packet ID=413 DTG Tag=6, Packet ID=300 DTG Tag=6, Packet ID=400 time
Delayed packets Received by the Target AN time
1 2
Figure 2.7.4.1.3-1
Example Usage of the DTG Tag
4 5 6 7
2.7.4.2
A19-Acquisition Status
The A19-Acquisition Status message is sent by the target AN to the source AN when an RT belonging to the target AN indicates that it has either acquired an ATs reverse traffic channel or lost an ATs reverse traffic channel. 2.7.4.2.1 Successful Operation
8 9 10 11 12 13
When an RT belonging to the target AN either acquires an ATs reverse traffic channel or loses an ATs reverse traffic channel, the target AN sends an A19-Acquisition Status message to the source AN indicating this event. The target AN starts timer Tacqstatus-19 and awaits the arrival of the A19-Acquisition Status Ack message. Refer to section 5.1.5.1, A19-Acquisition Status, for the format and content of this message. 2.7.4.2.2 Failure Operation
14 15 16 17 18
If timer Tacqstatus-19 expires, the target AN may resend the A19-Acquisition Status message to the source AN and restart timer Tacqstatus-19 a configurable number of times. If the A19-Acquisition Status Ack message is not received from the source AN, the target AN may choose other actions with respect to the AT. 2.7.4.3 A19-Acquisition Status Ack
19 20 21
The A19-Acquisition Status Ack message is sent by the source AN to the target AN to acknowledge the receipt of the A19-Acquisition Status message from the target AN. 2.7.4.3.1 Successful Operation
22 23 24 25
When the target AN receives an A19-Acquisition Status Ack message from the source AN, it stops timer Tacqstatus-19. Refer to section 5.1.5.2, A19-Acquisition Status Ack, for the format and content of this message. 2.7.4.3.2 None. 2.7.4.4 A19-Serving RT Changed Failure Operation
26 27
28 29 30 31 32
The A19-Serving RT Changed message is sent by the target AN to the source AN when an RT belonging to the target AN provides an early indication that it either determines or is unable to determine which sector an AT has chosen as the serving RT. This is done as part of the serving RT switching procedure. Only an RT that belongs to the Candidate Serving Set sends this message. The sector may send the A192-36
3GPP2 A.S0008-C v2.0

1 2
Serving RT Changed message before it sends the A19-Forward Stopped message so that the source AN can prepare for switching the serving RT (e.g., by starting to multicast). 2.7.4.4.1 Successful Operation
3 4 5 6 7 8 9 10 11
When an RT belonging to the target AN provides an early indication that it either determines or is unable to determine which sector an AT has chosen as the serving RT, the target AN sends an A19Serving RT Changed message to the source AN indicating this event. The source AN starts timer Tservrtch-19 and awaits the arrival of the A19-Serving RT Changed Ack message. The A19-Serving RT Changed message contains, among other things, queue information. The A19-Serving RT Changed message also contains status information informing the source AN what the last forward link packet was that the sector has already transmitted to the AT for a specific flow. Refer to section 5.1.5.3, A19-Serving RT Changed, for the format and content of this message. 2.7.4.4.2 Failure Operation
12 13 14 15 16
If timer Tservrtch-19 expires, the target AN may resend the A19-Serving RT Changed message to the source AN and restart timer Tservrtch-19 a configurable number of times. If the A19-Serving RT Changed Ack message is not received from the source AN, the target AN may choose other actions with respect to the AT. 2.7.4.5 A19-Serving RT Changed Ack
17 18 19
The A19-Serving RT Changed Ack message is sent by the source AN to the target AN to acknowledge the receipt of the A19-Serving RT Changed message from the target AN. 2.7.4.5.1 Successful Operation
20 21 22 23
When the target AN receives an A19-Serving RT Changed Ack message from the source AN, it stops timer Tservrtch-19. Refer to section 5.1.5.4, A19-Serving RT Changed Ack, for the format and content of this message. 2.7.4.5.2 None. 2.7.4.6 A19-Forward Desired Failure Operation
24 25
26 27 28 29
The A19-Forward Desired message is sent by the target RT to the source AN when the target RT is not the serving RT and a sector belonging to the target RT indicates that it has detected that the AT has chosen it as the serving sector. The message is sent as part of the serving RT switching procedure. 2.7.4.6.1 Successful Operation
30 31 32 33 34 35
When an RT belonging to the target AN detects that the AT has chosen it as the serving RT and the target RT is not the serving RT, the target RT sends an A19-Forward Desired message to the source AN indicating this event. The source AN starts timer Tservrtch-19 and awaits the arrival of the A19-Forward Desired Ack message. Refer to section 5.1.5.5, A19-Forward Desired, for the format and content of this message. 2.7.4.6.2 Failure Operation
36 37 38 39 40
If timer Tservrtch-19 expires, the target RT may resend the A19-Forward Desired message to the source AN and restart timer Tservrtch-19 a configurable number of times. If the A19-Forward Desired Ack message is not received from the source AN, the target RT may choose other actions with respect to the AT.
2-37
3GPP2 A.S0008-C v2.0

1 2 3
2.7.4.7
A19-Forward Desired Ack
The A19-Forward Desired Ack message is sent by the source AN to the target AN to acknowledge the receipt of the A19-Forward Desired message from the target AN. 2.7.4.7.1 Successful Operation
4 5 6 7
When the target AN receives an A19-Forward Desired Ack message from the source AN, it stops timer Tservrtch-19. Refer to section 5.1.5.6, A19-Forward Desired Ack, for the format and content of this message. 2.7.4.7.2 None. 2.7.4.8 A19-Forward Stopped Failure Operation
8 9
10 11 12 13 14 15 16 17 18 19
The A19-Forward Stopped message is sent by the RT of the target AN to the source AN when an RT belonging to the target AN indicates that an AT has chosen another sector belonging to another RT as the serving RT. This is done as part of the serving RT switching procedure. Only an RT that belongs to the Candidate Serving Set sends this message. The sector may send the A19-Serving RT Changed message before it sends the A19-Forward Stopped message so that the source AN can prepare for switching the serving RT (e.g., by starting to multicast). The A19-Forward Stopped message should be sent when the sector has observed for a longer period of time the signals from the AT that indicate a change in the serving RT compared to the event that triggers the A19-Serving RT Changed message transmission (hence, the greater level of confidence). 2.7.4.8.1 Successful Operation
20 21 22 23 24 25 26 27 28
When an RT belonging to the target AN detects that an AT has chosen another sector belonging to another RT as the serving RT, the target AN sends an A19-Forward Stopped message to the source AN indicating this event. The source AN starts timer Tservrtch-19 and awaits the arrival of the A19-Forward Stopped Ack message. The A19-Forward Stopped message contains, among other things, queue information. The A19-Forward Stopped message also contains status information informing the source AN what the last forward link packet was that the sector has already transmitted to the AT for a specific flow. Refer to section 5.1.5.7, A19-Forward Stopped, for the format and content of this message. 2.7.4.8.2 Failure Operation
29 30 31 32 33
If timer Tservrtch-19 expires, the target AN may resend the A19-Forward Stopped message to the source AN and restart timer Tservrtch-19 a configurable number of times. If the A19-Forward Stopped Ack message is not received from the source AN, the target AN may choose other actions with respect to the AT. 2.7.4.9 A19-Forward Stopped Ack
34 35 36
The A19-Forward Stopped Ack message is sent by the source AN to the target AN to acknowledge the receipt of the A19-Forward Stopped message from the target AN. 2.7.4.9.1 Successful Operation
37 38 39 40
When the target AN receives an A19-Forward Stopped Ack message from the source AN, it stops timer Tservrtch-19. Refer to section 5.1.5.8, A19-Forward Stopped Ack, for the format and content of this message.
2-38
3GPP2 A.S0008-C v2.0

1 2
2.7.4.9.2 None. 2.7.4.10
Failure Operation
3 4 5 6
A19-Flush
The A19-Flush message is sent by the source AN to the target AN to clear the contents of a specific scheduling queue at an RT belonging to the target AN during RLP reset as defined in [20], [10] or during serving RT switching. 2.7.4.10.1 Successful Operation When the source AN wants to clear the contents of a specific scheduling queue at an RT belonging to the target AN, it sends an A19-Flush message to the target AN. The source AN starts timer Tflush-19 and awaits the arrival of the A19-Flush Ack message. The A19-Flush message contains, among other things, queue information indicating to the sector which queues are to have their contents cleared. Upon receiving the A19-Flush message from the source AN, the sector is to perform the following: Purge all packets associated with the forward link flow specified in the A19-Flush message that it has currently buffered. Discard any subsequent packets (associated with the forward link flow specified in the A19-Flush message) that it receives if it has a DTG Tag that is smaller or equal to the last value of the DTG Tag received for the forward link flow.
7 8 9 10 11 12 13 14 15 16 17 18
Refer to section 5.1.5.9, A19-Flush, for the format and content of this message. 2.7.4.10.2 Failure Operation If timer Tflush-19 expires, the source AN may resend the A19-Flush message to the target AN and restart timer Tflush-19 a configurable number of times. If the A19-Flush Ack message is not received from the target AN, the source AN may choose other actions with respect to the AT. 2.7.4.11 A19-Flush Ack
19 20 21 22
23 24 25
The A19-Flush Ack message is sent by the target AN to the source AN to acknowledge the receipt of the A17-Flush message from the source AN. 2.7.4.11.1 Successful Operation When the source AN receives an A19-Flush Ack message from the target AN, it stops timer Tflush-19. Refer to section 5.1.5.10, A19-Flush Ack, for the format and content of this message. 2.7.4.11.2 Failure Operation None. 2.7.4.12 A19-Purge
26 27 28
29 30
31 32 33 34
The A19-Purge message is sent by the target AN to the source AN when an RT belonging to the target AN indicates that it has served forward traffic channel packets up to a specific point for an AT so that the source AN can clear the contents of a buffer for a specific queue. 2.7.4.12.1 Successful Operation When the target AN wants to indicate to the source AN that it can clear the contents of a buffer for a specific queue because the target AN has served forward traffic channel packets up to a specific point for an AT, it sends an A19-Purge message to the source AN. The target AN starts timer Tpurge-19 and awaits the arrival of the A19-Purge Ack message. The A19-Purge message contains, among other things, queue information indicating to the source AN which queues are to have the contents of their buffer cleared. The 2-39
35 36 37 38 39 40
3GPP2 A.S0008-C v2.0

1 2 3
A19-Purge message also contains status information informing the source AN what the last forward link packet was that the sector has already transmitted to the AT for a specific flow. Refer to section 5.1.5.11, A19-Purge, for the format and content of this message. 2.7.4.12.2 Failure Operation If timer Tpurge-19 expires, the target AN may resend the A19-Purge message to the source AN and restart timer Tpurge-19 a configurable number of times. If the A19-Purge Ack message is not received from the source AN, the target AN may choose other actions with respect to the AT. 2.7.4.13 A19-Purge Ack
4 5 6 7
8 9 10
The A19-Purge Ack message is sent by the source AN to the target AN to acknowledge the receipt of the A19-Purge message from the target AN. 2.7.4.13.1 Successful Operation When the target AN receives an A19-Purge Ack message from the source AN, it stops timer Tpurge-19. Refer to section 5.1.5.12, A19-Purge Ack, for the format and content of this message. 2.7.4.13.2 Failure Operation None.
11 12 13
14 15
16 17 18
2.8
A21 (AN IWS) Interface
The A21 interface is used to pass 1x air interface signaling messages between the HRPD AN and the standalone IWS or the IWS-1xBS. 2.8.1 A21 Interface Network/Transport Protocol Specification
19 20 21 22 23
The IOS application is independent of the underlying physical transport medium, which is left to the discretion of operators and manufacturers. The signaling protocol stack available to operators and manufacturers for the A21 interface is: IOS Application UDP IP Link Layer Physical Layer
24 25 26 27 28 29 30 31 32 33 34 35 36
The following UDP port value is reserved for signaling on the A21 interface: A21 (AN-to-IWS) 4597/udp - This is the registered UDP port number to be used for signaling interconnection between an HRPD AN and an IWS. The destination port number in the UDP packet that carries an A21-1x Air Interface Signaling message, an A21-Event Notification message, an A21-1x Parameters Request message, or an unsolicited A21-1x Parameters message shall be set to 4597. The receiver of an A21-1x Air Interface Signaling message, an A21-1x Parameters message, or an A21Event Notification message shall set the <source port, source IP address> and <destination port, destination IP address> of the UDP packet that carries the corresponding A21-Ack message to the <destination port, destination IP address> and <source port, source IP address> of the UDP packet that carried the A21-1x Air Interface Signaling message, the A21-1x Parameters message, or the A21-Event Notification message respectively. 2-40
3GPP2 A.S0008-C v2.0

1 2 3 4 5 6 7 8
The receiver of an A21-1x Parameters Request message shall set the <source port, source IP address> and <destination port, destination IP address> of the UDP packet that carries the corresponding the A21-1x Parameters message to the <destination port, destination IP address> and <source port, source IP address> of the UDP packet that carried the A21-1x Parameters Request message. The receiver of an A21-Service Request message shall set the <source port, source IP address> and <destination port, destination IP address> of the UDP packet that carries the corresponding the A21Service Response message to the <destination port, destination IP address> and <source port, source IP address> of the UDP packet that carried the A21-Service Request message. 2.8.2 A21 Interface Message Procedures
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
This section describes the message procedures supported between an HRPD AN and an IWS on the A21 interface. The A21 interface consists of the following messages: A21-1x Air Interface Signaling A21-Ack A21-1x Parameters A21-Event Notification A21-1x Parameters Request A21-Service Request A21-Service Response A21-Radio Update Request A21-Radio Update Response The procedures for how the HRPD AN discovers the A21 endpoint in the IWS are not defined. The A21 interface is used to support MS/ATs that do not transmit and receive on both the HRPD and 1x radio interfaces simultaneously. In particular, the A21 interface provides the ability to transfer a voice call from voice over IP (VoIP) on HRPD to a 1x circuit voice call. Refer to section 4.7 for a message flow describing this capability. The HRPD AN and IWS communicate across the A21 interface to provide the 1x information to the MS/AT that it requires to originate a 1x circuit voice call when it has an active connection on HRPD. They also communicate to provide the radio information to the 1x BS that it requires to properly assign the MS/AT to a 1x traffic channel and prepare to receive the MS/AT when it accesses that traffic channel. The MS/AT requires the 1x overhead channel parameters to originate a 1x circuit voice call that it may not be able to acquire on its own. The 1x BS provides those values to the HRPD AN for distribution to the MS/ATs that require them. The 1x BS requires the radio information, e.g., estimated one way delays, handoff target cell identifiers, and pilot strength measurements, for 1x cells to which the MS/AT may be assigned. The HRPD AN can provide this information in several ways. a. If the MS/AT can provide actual 1x pilot measurements, then the HRPD AN simply forwards this information to the IWS. b. If the MS/AT can provide only HRPD pilot measurements, then the HRPD AN needs to estimate the corresponding 1x pilot measurements for known 1x pilots. These estimations can be grouped in two categories: 1. Collocated HRPD and 1x cells: For this configuration, the HRPD and 1x cells are transmitting from the same antenna mast. The 1x values can be estimated to be very close to the HRPD values. 2. Non-collocated HRPD and 1x cells: For this configuration, the HRPD AN may have information about relative distances between HRPD and 1x cells, e.g., via provisioning. Techniques similar to those used for 1x inter-frequency hard handoff can be used. The HRPD 2-41
3GPP2 A.S0008-C v2.0

1 2 3 4 5
AN may also have knowledge of traffic patterns in its area and be able to estimate which 1x cells may be appropriate handoff targets. Finally, the HRPD AN provides identification of the 1x pilot that is being reported/estimated. It is through a vendor defined method, e.g., provisioning, that the HRPD AN determines which 1x BS to send the Origination Message to, as well as which set of overhead parameters to send to the MS/AT. 2.8.2.1 A21-1x Air Interface Signaling
6 7 8 9 10
The A21-1x Air Interface Signaling message is sent in either direction on the A21 interface. When sent by the IWS, this message includes a 1x air interface message to be sent to the MS/AT by the HRPD AN using the CSNA protocol. When sent by the HRPD AN, this message includes a 1x air interface message received by the HRPD AN from the MS/AT using the CSNA protocol. 2.8.2.1.1 Successful Operation
11 12 13 14 15 16 17 18
In the IWS to HRPD AN direction, this message contains a 1x air interface message, which the HRPD AN forwards to the MS/AT using the CSNA protocol (refer to [9]). The IWS starts timer Tack-21. In the HRPD AN to IWS direction, when the HRPD AN receives a 1x air interface message from the MS/AT that is to be sent to an IWS, the HRPD AN encapsulates the 1x air interface message in an A211x Air Interface Signaling message and sends it to the IWS via the A21 interface. The HRPD AN then starts timer Tack-21. Refer to section 5.1.6.1, A21-1x Air Interface Signaling, for the format and content of this message. 2.8.2.1.2 Failure Operation
19 20 21
When timer Tack-21 expires, the sender may resend the A21-1x Air Interface Signaling message to the receiver and restart timer Tack-21 a configurable number of times. 2.8.2.2 A21-Ack
22 23 24
The A21-Ack message is sent by the HRPD AN to the IWS or by the IWS to the HRPD AN on the A21 interface to acknowledge receipt of some A21 messages. 2.8.2.2.1 Successful Operation
25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43
When the HRPD AN receives an A21-1x Air Interface Signaling message, it sends the 1x air interface message via the HRPD CSNA procedures to the MS/AT. If the AckRequired field of the A21 1x Message Transmission Control IE is set to 1, the HRPD AN shall delay sending this A21-Ack message until it receives an acknowledgement from the MS/AT; otherwise, the HRPD AN shall send this A21-Ack message as soon as it has successfully received the A21-1x Air Interface Signaling message. If the HRPD AN does not receive an air interface acknowledgement from the MS/AT, the HRPD AN shall send an A21-Ack message with an appropriate cause value, prior to expiration of timer Tack-21. When the HRPD AN receives an A21-1x Parameters message from the IWS, it sends an A21-Ack message to the IWS to acknowledge receipt. When the IWS receives an A21-1x Air Interface Signaling message, it sends an A21-Ack message to the HRPD AN to acknowledge receipt. Upon receipt of the A21-Ack message, the HRPD AN stops timer Tack-21. When the HRPD AN or IWS receives an A21 interface message that cannot be acted upon as expected, e.g., an A21-1x Air Interface Signaling message that contains an MEID value unknown to the HRPD AN, the HRPD AN or IWS shall set the cause value of the A21-Ack message appropriately to indicate the exception. When the HRPD AN or IWS receives an A21-Event Notification, it notes the event information and sends an A21-Ack message to the sender. 2-42
3GPP2 A.S0008-C v2.0

1 2
Upon receipt of the A21-Ack message, the receiver stops the corresponding timer Tack-21. Refer to section 5.1.6.2, A21-Ack, for the format and content of this message. 2.8.2.2.2 None. 2.8.2.3 A21-1x Parameters Failure Operation
3 4
5 6 7 8 9
The A21-1x Parameters message is sent by the IWS to the HRPD AN on the A21 interface to provide the HRPD AN with the 1x overhead parameter values to be transmitted in the CSNA 3G1XParameters message (refer to [9]). This message also can contain the RAND value when the IWS has been configured to provide the RAND value to the HRPD AN. 2.8.2.3.1 Successful Operation
10 11 12 13 14 15 16 17 18
When one or more of the 1x overhead parameter values or the RAND value (when the IWS has been configured to provide the RAND value to the HRPD AN) change, IWS encodes those values in the A211x Parameters message and sends this message to the HRPD AN. When the IWS receives an A21-1x Parameters Request message, it encodes the 1x overhead parameter values and the RAND value (when applicable) in the A21-1x Parameters message and sends this message to the HRPD AN. The HRPD AN will provide them to the MS/AT via the CSNA protocol. The IWS then starts timer Tack-21. The HRPD AN stops timer Tparamreq-21, if it is running. Refer to section 5.1.6.3, A21-1x Parameters, for the format and content of this message. 2.8.2.3.2 Failure Operation
19 20 21
When timer Tack-21 expires, IWS may resend the A21-1x Parameters message to the HRPD AN and restart timer Tack-21 a configurable number of times. 2.8.2.4 A21-Event Notification
22 23 24
The A21-Event Notification message is sent by the entity at either end of the A21 interface to provide notification of some event that may be of interest to the entity at the other end of the A21 interface. 2.8.2.4.1 Successful Operation
25 26 27 28 29 30 31 32 33
When some event occurs that may be of interest to the entity at the other end of the A21 interface, an A21-Event Notification message is sent to inform that entity of the event. The sender then starts timer Tack-21. In particular, when an inter-AN handoff occurs and the ATs target configuration includes the CSNA protocol to send and receive 1x messages to the 1x IWS, the target AN shall send an A21-Event Notification message to the 1x IWS with event value Redirection, which permits the 1x IWS to determine the IP address of the A21 interface for the target AN. Refer to section 5.1.6.4, A21-Event Notification, for the format and content of this message. 2.8.2.4.2 Failure Operation
34 35 36
When timer Tack-21 expires, the sender may resend the A21-Event Notification message to the receiver and restart timer Tack-21 a configurable number of times. 2.8.2.5 A21-1x Parameters Request
37 38 39
The A21-1x Parameters Request message is sent by the HRPD AN to the IWS on the A21 interface when either the RAND value or an overhead parameter value is needed at the HRPD AN.
2-43
3GPP2 A.S0008-C v2.0

1 2 3 4
2.8.2.5.1
When the 1x overhead parameter values are needed, the HRPD AN sends this message to the IWS and starts timer Tparamreq-21. Refer to section 5.1.6.5, A21-1x Parameters Request, for the format and content of this message. 2.8.2.5.2 Failure Operation
5 6 7 8
If timer Tparamreq-21 expires, HRPD AN may resend the A21-1x Parameters Request message to the IWS and restart timer Tparamreq-21 a configurable number of times.
9 10 11
2.8.2.6
A21-Service Request
This message is sent from the HRPD AN to the IWS to notify the IWS to deliver an HRPD page while the MS/AT is monitoring the 1x system. 2.8.2.6.1 Successful Operation
12 13 14
The HRPD AN sends an A21-Service Request message to the IWS. The HRPD AN starts timer Tpage-21 and awaits the reception of the A21-Service Response message. 2.8.2.6.2 Failure Operation
15 16 17 18
If the A21-Service Response message is not received at the HRPD AN before the expiration of timer Tpage-21, the HRPD AN may resend the A21-Service Request message and restart timer Tpage-21 a configurable number of times. 2.8.2.7 A21-Service Response
19 20 21
This A21 interface message is sent from the IWS to the HRPD AN in response to an A21-Service Request message. 2.8.2.7.1 Successful Operation
22 23 24 25 26 27 28 29
The IWS shall send an A21 Service Response message to the HRPD AN that originated the A21-Service Request message. If the service option to be used in the 1x page message will cause the MS/AT to move directly to the HRPD system, then upon receipt of the A21-Service Request message the IWS sends an A21-Service Response message. If the service option to be used in the 1x page message will cause the MS/AT to send a 1x page response prior to moving to the HRPD system, then upon receipt of the 1x page response the IWS sends an A21-Service Response message. Upon receiving the A21-Service Response message, the HRPD AN stops timer Tpage-21. 2.8.2.7.2 None. 2.8.2.8 A21-Radio Update Request Failure Operation
30 31
32 33 34 35
The A21-Radio Update Request message is sent by the IWS to the HRPD AN on the A21 interface when the IWS needs to acquire current radio information, e.g., current power strength measurements for an MS/AT that is in the process of handing off from HRPD to 1x. 2.8.2.8.1 Successful Operation
36 37 38 39 40
When current radio information, e.g., current power strength measurements are needed for an MS/AT that is handing off from HRPD to 1x, the IWS sends this message to the HRPD AN and starts timer Tradioreq21. Refer to section 5.1.6.8, A21-Radio Update Request, for the format and content of this message. 2-44
3GPP2 A.S0008-C v2.0

1 2 3
2.8.2.8.2
Failure Operation
If timer Tradioreq-21 expires, the IWS may resend the A21-Radio Update Request message to the HRPD AN and restart timer Tradioreq-21 a configurable number of times. 2.8.2.9 A21-Radio Update Response
4 5 6 7
The A21-Radio Update Response message is sent by the HRPD AN to the IWS on the A21 interface when the IWS has requested current radio information, e.g., current power strength measurements for an MS/AT that is in the process of handing off from HRPD to 1x. 2.8.2.9.1 Successful Operation
8 9 10 11 12 13
When the IWS has requested current radio information, e.g., current power strength measurements, for an MS/AT that is handing off from HRPD to 1x, the HRPD AN sends this message to the IWS. When the IWS receives this message, it stops timer Tradioreq-21. Refer to section 5.1.6.9, A21-Radio Update Response, for the format and content of this message. 2.8.2.9.2 None. Failure Operation
14 15
16 17 18 19 20 21 22 23 24 25 26 27 28 29
2.9
A24 AN-AN (IP Tunneling) Interface
This interface allows for tunneling of buffered user data from the source AN to the target AN for an AT, during A13 session transfer. The interface encapsulates the tunneled user data to be transmitted by the source AN, using the GRE key that consists of A24 Connection ID as upper 24 bits provided in the A13Session Information Request message and RLP_ID as lower 8 bits for which the source AN listed in the A13-Session Information Response message. The Buffered Data Information attribute is used to identify whether or not the packet is the last packet of data to be transmitted to the target AN for the RLP_ID. Refer to Annex A, section 2.6.1.5. GRE sequencing should be used if it is necessary to ensure that the Buffer Indicator attribute is not received out of order. The source AN shall send the Buffer Indicator, set to 1 (packet is the last packet), with the last packet sent for every RLP_ID listed in the A13-Session Information Response message. The protocol stack for transport of user traffic on the A24 interface that is available to operators and manufacturers is shown as follows. GRE IP Link Layer Physical Layer
30 31
2-45
3GPP2 A.S0008-C v2.0

1 2 3 4
2-46
3GPP2 A.S0008-C v2.0
1 2 3 4 5 6
3 HRPD IOS Call Flows

This section describes the call flows associated with an HRPD AT. Air interface messages and message sequences shown in the message flows in this document are informative only. It is possible that different air interface messages or different sequences of air interface messages may provide equivalent or better functionality. It is also possible that the use of one or more of the air interface messages may become less desirable as the air interface evolves.
7 8
3.1
AT Originates HRPD Session
This section describes the call flows associated with an AT call origination in the AN. 3.1.1 AT Originates HRPD Session - Successful Access Authentication
9 10
This scenario describes the call flow for a successfully authenticated AT call origination in the AN.
AT AN AN AAA PCF PDSN time
Session Establishment
AT Ready to Exchange Data on Access Stream
PPP and LCP Negotiation
CHAP Challenge - Response A12 Access-Request A12 Access-Accept CHAP - Authentication Success
d e f g
Location Update Procedure
AT Ready to Exchange Data on Service Stream A9-Setup-A8 A11-Registration Request (Lifetime, MEI) A11-Registration Reply (Lifetime, accept) A9-Connect-A8 Establishing PPP connection
i j k l m n
TA8-setup
Tregreq
Transmitting Packet Data
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 3-1
13 14
3GPP2 A.S0008-C v2.0

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
session is established where protocols and protocol configurations are negotiated, stored and used for communications between the AT and the AN. Refer to [10], 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. The AT and the AN initiate Point-to-Point Protocol (PPP) and LCP negotiations for access authentication. Refer to [26]. d. The AN generates a random challenge and sends it to the AT in a CHAP Challenge message in accordance with [29]. 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 [31]). f. 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 [29] and [31]), the AN-AAA sends an AccessAccept message on the A12 interface in accordance with [31]. 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.4.2, AN-AAA Support.
g. The AN returns an indication of CHAP access authentication success to the AT. Refer to [29]. 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. 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). Note that this step may occur at any time after step a. The AN sends an A9-Setup-A8 message to the PCF with Data Ready Indicator (DRI) set to 1 to establish the main A8 connection and starts timer TA8-setup. The A9-Setup-A8 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. Note: This message is sent after the Access Accept message is received on the A12 interface in step f.
j.
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) to set up the main A10 connection. The PCF starts timer Tregreq. l. 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 a non-zero 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 message to the AN. When the AN receives the A9-Connect-A8 message it stops timer TA8-setup. n. PPP connection establishment procedure is performed between the AT and the PDSN, according to [8]. o. At this point the main connection is established and packet data can flow between the AT and the PDSN.
3-2
3GPP2 A.S0008-C v2.0

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
CHAP Challenge - Response A12 Access-Request A12 Access-Reject CHAP - Authentication Failure
d e f g h i
SessionClose SessionClose
4 5
Figure 3.1.2-1 Initial AT Origination - Unsuccessful Access Authentication 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], 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. The AT and the AN initiate PPP and LCP negotiations for access authentication. Refer to [26]. d. The AN generates a random challenge and sends it to the AT in a CHAP Challenge message, in accordance with [29]. 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 [31]). f. 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 [29] and [31]), the AN-AAA sends an AccessReject message on the A12 interface in accordance with [31]. 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. g. The AN returns an indication of CHAP access authentication failure to the AT. Refer to [29]. h. The AN sends a SessionClose message to the AT to close the HRPD session. i. The AT responds with a SessionClose message.
6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24
3-3
3GPP2 A.S0008-C v2.0

1 2
3.2
Re-authentication
This section describes the call flows associated with the re-authentication of an AT. 3.2.1 Re-authentication of an AT in Dormant State
3 4 5
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 Connection Establishment AN AN AAA time a
AT Ready to Exchange Data on Access Stream PPP and LCP Negotiation CHAP Challenge - Response A12 Access-Request A12 Access-Accept CHAP - Authentication Success
c d e f g
Connection Tear-Down (initiated by the AN)

6 7
Figure 3.2.1-1 Re-authentication of an AT in Dormant State a. The AN determines that 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 [26]. 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 [29]. 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 [31]. f. 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 [29] and [31]), the AN-AAA sends an AccessAccept message on the A12 interface in accordance with [31]. 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.4.2, AN-AAA Support.
8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26
g. The AN returns an indication of CHAP access authentication success to the AT. Refer to [29]. h. The AN initiates HRPD connection tear-down. Refer to [10], Connection Layer.
3-4
3GPP2 A.S0008-C v2.0

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 PPP and LCP Negotiation CHAP Challenge - Response A12 Access-Request A12 Access-Accept CHAP - Authentication Success
b c d e f
AT Ready to Exchange Data on Service Stream

4 5
Figure 3.2.2-1 Re-authentication of an AT in Active State a. The AN determines that 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). b. The AT and the AN initiate PPP and LCP negotiations for access authentication. Refer to [26]. 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 [29]. 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 as a RADIUS server in accordance with [31]. 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 [29] and [31]), the AN-AAA sends an AccessAccept message on the A12 interface in accordance with [31]. 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.4.2, AN-AAA Support. f. The AN returns an indication of CHAP access authentication success to the AT. Refer to [29]. 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).
6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26
3-5
3GPP2 A.S0008-C v2.0
1 2
3.3
Data Delivery
This section describes the call flows associated with AT terminated and AT originated data delivery. 3.3.1 Network Initiated Call Re-activation from Dormant State
3 4 5 6
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 Transmitting Packet Data A9-BS Service Request A9-BS Service Response Page message Connection Establishment A9-Setup-A8 PDSN time a b
Tbsreq9
c d e f
Tnet_conn
TA8-setup
A9-Connect-A8
Tregreq
A11-Registration Request A11-Registration Reply
g h i j
Transmitting Packet Data

7 8
Figure 3.3.1-1 Network Initiated Call Re-activation from Dormant State a. The PDSN sends packet data to the PCF. b. The PCF sends an A9-BS Service Request message to the AN to request packet service, and starts timer Tbsreq9. The SR_ID is set to 1 and is ignored by the AN, since this message is a request to set up all A8 connections needed for the IP flow mapping maintained by the AN. 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. d. The AN sends a Page message to the AT, on the control channel. 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], Connection Setup State. f. 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 connections and starts timer TA8-setup. When the PCF receives the A9-Setup-A8 message, it stops timer Tnet_conn.
9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28
g. The PCF sends an A11-Registration Request message to the PDSN with accounting information and starts timer Tregreq. h. The PDSN responds with an A11-Registration Reply message. The PCF stops timer Tregreq. i. j. The PCF sends the A9-Connect-A8 message to the AN. When the AN receives the A9-Connect-A8 message it stops timer TA8-setup. At this point the connection is established and packet data can flow between the AT and the PDSN.
3-6
3GPP2 A.S0008-C v2.0

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 PDSN time a b* A9-Setup-A8 c A11-Registration Request A11-Registration Reply A9-Connect-A8 Transmitting packet data d e f g * = conditional
Connection establishment Flow configuration
T A8-setup
T regreq
4 5
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], Connection Setup State. b. If the connection establishment includes an HRPD Emergency Indicator (e.g., ReservationOnRequest message includes the HRPD Emergency Indicator), the AT and AN also perform flow configuration for emergency services and provide the Emergency Services indicator to the PDSN via the A9 and A11 messaging. c. After the traffic channel is established, the AN sends an A9-Setup-A8 message to the PCF with DRI set to 1 to establish all A8 connections needed for the IP flow mapping maintained by the AN and starts timer TA8-setup. d. The PCF sends an A11-Registration Request message to the PDSN with accounting information and starts timer Tregreq. e. The PDSN responds with an A11-Registration Reply message. The PCF stops timer Tregreq. f. The PCF sends the A9-Connect-A8 message to the AN. When the AN receives the A9-Connect-A8 message it stops timer TA8-setup. Refer to [13], Section 3.17.4.22, MS Initiated Call Re-activation from Dormant State.
6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
g. At this point the connection is established and packet data can flow between the AT and the PDSN.
24 25 26 27
3.3.3
AT Initiated Packet Data Session Establishment from an Established HRPD Session
This scenario describes the call flow associated with an AT establishing a PPP session to the PDSN. It is assumed that the AT and the AN already have an established HRPD Session, that no corresponding A10 connection between the PCF and the PDSN exists.
3-7
3GPP2 A.S0008-C v2.0
AT
AN
PCF
PDSN
time
AT is ready to exchange data on the Service Stream
a A9-Setup-A8 b A11-Registration Request (Lifetime, MEI) A11-Registration Reply (Lifetime, Accept) c d e f g* Transmitting Packet Data h * = conditional
T A8-setup
T regreq
A9-Connect-A8 PPP and LCP Negotiation
IP flow mapping update
1 2
Figure 3.3.3-1 AT Initiated Packet Data Session Establishment from Established HRPD Session a. The AT indicates that it is ready to exchange data on the service stream. b. The AN sends an A9-Setup-A8 message to the PCF with Data Ready Indicator (DRI) set to 0 to establish A8 connection and starts timer TA8-setup. c. The PCF recognizes that no associated A10 connection for 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 CVSE. The 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 Lifetime set to a non-zero value. The PDSN 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. e. The PCF sends the A9-Connect-A8 message to the AN. When the AN receives this message it stops timer TA8-setup. f. The PDSN sends an LCP configure request to initiate PPP and LCP negotiations between the AT and the PDSN according to [8].
3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22
g. If the packet data session is established for emergency services (e.g., the connection establishment includes the HRPD Emergency Indicator), then the AT and AN also performs IP flow mapping update and provide the Emergency Services indicator to the PDSN via the A9 and A11 messaging. Refer to section 3.9.2. h. At this point PPP connection is established and packet data can flow between the AT and the PDSN.
3-8
3GPP2 A.S0008-C v2.0
1 2
3.4
Connection Release
This section describes the call flows associated with an HRPD connection release. 3.4.1 Connection Release on HRPD Network - Initiated by the AT
3 4
This scenario describes the call flow associated with a connection release initiated by an AT.
AT AN PCF PDSN time
Connection Release (Initiated by the AT) A9-Release-A8
a b
Trel9
Tregreq
c d e
A9-Release-A8 Complete
5 6
Figure 3.4.1-1 AT Initiated Connection Release a. The AT initiates HRPD connection release. Refer to [10], 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 all A8 connections. The AN starts timer Trel9. c. The PCF sends an A11-Registration Request message to send an Active Stop accounting record to the PDSN for all IP flows in the activated state associated with the AT and starts timer Tregreq. d. The PDSN sends an A11-Registration Reply message to the PCF. The PCF stops timer Tregreq upon receipt of this message. e. The PCF initiates procedures for releasing all A8 connections and sends an A9-Release-A8 Complete message to the AN. The AN stops timer Trel9. At this time, A10 connections for this call are retained. 3.4.2 Connection Release on HRPD Network - Initiated by the AN.
7 8 9 10 11 12 13 14 15
16 17
This scenario describes the call flow associated with a connection release initiated by the AN/PCF.
AT AN A9-Release-A8 A11-Registration Request PCF PDSN time a b c d e*
Trel9
Tregreq
A11-Registration Reply A9-Release-A8 Complete
Connection Release (Initiated by the AN)

18 19
* = conditional
Figure 3.4.2-1 AN Initiated Connection Release
3-9
3GPP2 A.S0008-C v2.0

1 2 3 4 5 6 7 8 9 10 11
a. The AN initiates release of all A8 connections by transmitting an A9-Release-A8 message to the PCF with the cause value set to Packet call going dormant or Air Link Lost, to request the PCF to release the associated dedicated resources. The AN starts timer Trel9. b. The PCF sends an A11-Registration Request message to send Active Stop accounting records to the PDSN for all IP flows in the activated state associated with the AT and starts timer Tregreq. c. The PDSN responds with an A11-Registration Reply message. The PCF stops timer Tregreq. d. The PCF acknowledges the A9-Release-A8 message by returning an A9-Release-A8 Complete message. The AN stops timer Trel9. At this time, A10 connections for this call are retained. e. If the A9 release was not due to Air Link Lost, the AN shall initiate HRPD connection release. This step may occur in parallel with steps a and b. Refer to [10], Connection Layer.
3-10
3GPP2 A.S0008-C v2.0
1 2
3.5
HRPD Session Release
This section describes the call flows associated with HRPD session release. 3.5.1 HRPD Session Release - Initiated by the AT or AN (A8 Connections Exist)
3 4 5 6
This scenario describes the call flows associated with an HRPD session release initiated by an AT or AN. This subsequently leads to a packet data session release, if present. It is assumed that the A8 connections are already established.
AT AN PCF PDSN
time
Session Release A9-Release-A8 A11-Registration Request (Lifetime=0, Acct data)
a b c
Trel9
Tregreq
A11-Registration Reply (Lifetime=0, Accept) d e
7 8
Figure 3.5.1-1 AT or AN Initiated HRPD Session Release (A8 Connections Exist) a. The AT or AN initiates HRPD Session Release. Refer to [10], 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 all associated dedicated resources and all associated A10 connections. 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 all the A10 connections. Active Stop accounting records are included in the message for all IP flows in the activated state associated with the AT. The PCF starts timer Tregreq. Refer to [13], Section 3.17.5.6, Packet Data Service Session Clearing - MS Initiated. d. The PDSN stores the accounting data for further processing and responds with an A11-Registration Reply message to complete the release of all the A10 connections. The PCF stops timer Tregreq. e. The PCF sends an A9-Release-A8 Complete message to the AN. The AN stops timer Trel9. 3.5.2 HRPD Session Release - Initiated by the AT or AN (A8 Connections do not Exist)
9 10 11 12 13 14 15 16 17 18 19
20 21 22 23
This scenario describes the call flows associated with an HRPD session release initiated by an AT or AN. This subsequently leads to a packet data session release, if present. It is assumed that no A8 connections are not established.
3-11
3GPP2 A.S0008-C v2.0
AT
AN
PCF
PDSN
time
Session Release A9-Update-A8 A11-Registration Request (Lifetime=0, Acct data)
a b c
Tupd9
Tregreq
A11-Registration Reply (Lifetime=0, Accept) A9-Update-A8 Ack d e
1 2
Figure 3.5.2-1 AT or AN Initiated HRPD Session Release (A8 Connections do not Exist) a. The AT or AN initiates HRPD Session Release. Refer to [10], 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 all associated dedicated resources and all associated A10 connections. 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 all the A10 connections. Active Stop accounting records are included in the message for all IP flows in the activated state associated with the AT. The PCF starts timer Tregreq. Refer to [13], Section 3.17.5.6, Packet Data Service Session Clearing - MS Initiated. d. The PDSN stores the accounting data for further processing and responds with an A11-Registration Reply to complete the release of all the A10 connections. The PCF stops timer Tregreq. e. The PCF sends an A9-Update-A8 Ack message to the AN. The AN stops timer Tupd9. 3.5.3 HRPD Session Release - Re-authentication of AT Failure (A8 Connections Exist)
3 4 5 6 7 8 9 10 11 12 13
14 15 16 17 18
This scenario describes the call flows associated with an HRPD session release due to AT reauthentication failure at AN AAA. This may subsequently lead to a packet data session release, if present. It is assumed that the AT has already established an HRPD session and the A8 connections are already established.
3-12
3GPP2 A.S0008-C v2.0
1 2
Figure 3.5.3-1 HRPD Session Release - Re-authentication of AT Failure (A8 Connections Exist) a. The AN determines that 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). b. The AT and the AN initiate PPP and LCP negotiations for access authentication. Refer to [26]. 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 [29]. 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 as a RADIUS server in accordance with [31]. e. The AN-AAA looks up a password based on the User-name attribute in the Access-Request message and if the access authentication failure (as specified in [29] and [31]), the AN-AAA sends an AccessReject message on the A12 interface in accordance with [31]. f. The AN returns an indication of CHAP access authentication fail to the AT. Refer to [29]. g. The AT or AN initiates HRPD Session Release. Refer to [10], Session Layer. h. After the AN closes the HRPD session, if the AN decides to release the packet data session, the AN sends an A9-Release-A8 message with a cause value set to Authentication Failure to the PCF to request the PCF to release all associated dedicated resources and all associated A10 connections. The AN starts timer Trel9. i. The PCF sends an A11-Registration Request message to the PDSN with a Lifetime timer value of zero to close all the A10 connections. Active Stop accounting records are included in the message for all IP flows in the activated state associated with the AT. The PCF starts timer Tregreq. Refer to [13], Section 3.17.5.6, Packet Data Service Session Clearing - MS Initiated. The PDSN stores the accounting data for further processing and responds with an A11-Registration Reply message to complete the release of all the A10 connections. The PCF stops timer Tregreq.
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
j.
k. The PCF sends an A9-Release-A8 Complete message to the AN. The AN stops timer Trel9. 3-13
3GPP2 A.S0008-C v2.0

1
2 3 4 5 6
3.5.4
HRPD Session Release - Re-authentication of AT Failure (A8 Connections do not Exist)
This scenario describes the call flows associated with an HRPD session release due to AT reauthentication failure at AN AAA. This may subsequently lead to a packet data session release, if present. It is assumed that the AT has already established an HRPD session and no A8 connections are already established.
time a b c d e f g h i* j**
Tregreq
Tupd9
k**
*=optional l** **=conditional
7 8 9
Figure 3.5.4-1 HRPD Session Release - Re-authentication of AT Failure (A8 Connections do not Exist) a. The AN determines that 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 [26]. 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 [29]. 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 [31]. f. 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 [29] and [31]), the AN-AAA sends an AccessReject message on the A12 interface in accordance with [31].
10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29
g. The AN returns an indication of CHAP access authentication fail to the AT. Refer to [29]. h. The AT or AN initiates HRPD Session Release. Refer to [10], Session Layer. i. After the AN closes the HRPD session, if the AN decides to release the packet data session, the AN sends an A9-Update-A8 message with a cause value set to Authentication failure to the PCF to request the PCF to release all associated dedicated resources and all associated A10 connections. The AN starts timer Tupd9. 3-14
3GPP2 A.S0008-C v2.0

1 2 3 4 5 6 7
j.
The PCF sends an A11-Registration Request message to the PDSN with a Lifetime timer value of zero to close all the A10 connections. The PCF starts timer Tregreq. Refer to [13], Section 3.17.5.6, Packet Data Service Session Clearing - MS Initiated.
k. The PDSN responds with an A11-Registration Reply message to complete the release of all the A10 connections. The PCF stops timer Tregreq. l. The PCF sends an A9-Update-A8 Ack message to the AN. The AN stops timer Tupd9.
3-15
3GPP2 A.S0008-C v2.0
1 2 3
3.6
Packet Data Session Release - Initiated by the PDSN
This scenario describes the call flow associated with packet data session release initiated by the PDSN. This procedure shall be executed when the PDSN closes the Packet Data (PPP) session.
AT AN PCF PDSN time
PPP Release A11-Registration Update
a b
Tregupd
A11-Registration Acknowledge A11-Registration Request (Lifetime=0) c d e f Conditional g Conditional h Conditional i Conditional
Tregreq
A11-Registration Reply (Lifetime=0, accept) A9-Disconnect-A8
Tdiscon9
A9-Release-A8
Trel9
A9-Release-A8 Complete Connection Release
4 5
Figure 3.6-1
PDSN Initiated Packet Data Session Release
6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22
a. The AT and PDSN close the PPP session. b. The PDSN initiates closure of the A10 connections by sending an A11-Registration Update message to the PCF. The PDSN starts timer Tregupd. c. The PCF responds with an A11-Registration Acknowledge message. The PDSN stops timer Tregupd. d. The PCF sends an A11-Registration Request message with Lifetime set to zero, to the PDSN. The PCF starts timer Tregreq. An Active Stop accounting record is included in the message. e. The PDSN sends an A11-Registration Reply message to the PCF. The PCF closes all the A10 connections for the AT and stops timer Tregreq. Note: If there are no existing A8 connections the remaining steps are omitted. f. The PCF sends an A9-Disconnect-A8 message to the AN and starts timer Tdiscon9. g. 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 all the associated dedicated resources. The AN starts timer Trel9. The PCF stops timer Tdiscon9. h. The PCF acknowledges the A9-Release-A8 message by returning an A9-Release-A8 Complete message. The AN stops timer Trel9. i. The AN may initiate HRPD connection release. Refer to [10], Connection Layer.
3-16
3GPP2 A.S0008-C v2.0
1 2 3 4 5 6
3.7
Dormant Handoff of HRPD AT between ANs - Served by the Same PDSN
This section describes the call flows associated with AT dormant handoff between ANs. Note: If both HRPD and 1x systems are present, then the 1x BS may indicate to the MS/AT whether 1x packet zone boundaries are also HRPD subnet boundaries. If subnet boundaries are also packet zone boundaries, the MS/AT tunes to the HRPD frequency to update its UATI upon crossing a 1x packet zone boundary. Refer to [19]. 3.7.1 AN-AN Dormant Handoff with Successful Retrieval of HRPD Session Information
7 8 9 10
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.
AT Initiate Session Establishment A13-Session Information Request Target AN Target PCF Source AN Source PCF PDSN time a b
TA13req
A13-Session Information Response Complete Session Establishment c d
TA13res
Location Update Procedures A13-Session Information Confirm A9-Setup-A8 e f g h i j*
A11-Registration Request (Lifetime, MEI)
Tregreq
A11-Registration Reply (Lifetime, accept) A11-Registration Update
TA8-setup
Tregupd
A11-Registration Acknowledge A11-Registration Request (Lifetime=0) A11-Registration Reply (Lifetime=0, accept) k* l* m* n * = conditional
Tregreq
A9-Release-A8-Complete
11 12
Figure 3.7.1-1 Inter-PCF/Intra-PDSN Dormant AN-AN HO - Successful Operation a. After the AT crosses a mobility boundary, the AT requests an HRPD connection and 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. 3-17
13 14 15 16 17
3GPP2 A.S0008-C v2.0

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
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. 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 source AN starts timer TA13res. 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. 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). f. 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 associated AT HRPD session information. The source AN stops timer TA13res.
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. This message contains information on all A8 connections needed for the IP flow mapping maintained by the AN as negotiated over the air. This message includes the PDSN address received from the source AN in the A13-Session Information Response message in step c. The handoff indicator of the A9 Indicators IE shall be set to 0. Note that if the AT has not crossed an HRPD packet zone, the target PCF is same entity as the source PCF. h. The target PCF selects the PDSN using the PDSN address provided in the A9-Setup A8 message or using PDSN selection algorithms as specified in [13], and sends an A11-Registration Request message to the PDSN to set up an A10 connection for each service connection signaled by the AN in step g. The A11-Registration Request message includes the MEI within the CVSE and a non-zero Lifetime. This message also includes a CVSE containing Accounting Data (A10 Connection Setup Airlink Record), if new A10 connections are being established, and an NVSE including ANID information (CANID/PANID). The target PCF starts timer Tregreq. Refer to [13], Section 3.17.5.8, Inter-PCF Dormant Handoff - Mobile Continues to be Served by the Serving PDSN. i. The A11-Registration Request message is validated and the PDSN accepts the A10 connections 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. If the subscriber has a Subscriber QoS Profile, the PDSN includes it in an NVSE. The A10 connection binding information at the PDSN is updated to point to the target PCF. The target PCF stops timer Tregreq. If the PDSN has A10 connections to another PCF (e.g., the source-PCF), it initiates closure of the A10 connections with that PCF by sending an A11-Registration Update message. The PDSN starts timer Tregupd.
j.
k. The source PCF responds with an A11-Registration Acknowledge message. The PDSN stops timer Tregupd. l. 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 connections for the AT and stops timer Tregreq.
3-18
3GPP2 A.S0008-C v2.0

1 2 3
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 that this step can occur any time after step i. 3.7.2 AN-AN Dormant Handoff with HRPD Session Information Transfer Failure
4 5 6
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.
AT Initiate Session Establishment A13-Session Information Request Target AN Target PCF Source AN Source PCF AAA-AN PDSN time a b c d
TA13req
A13-Session Information Reject Complete Session Establishment
Location Update Procedures
Access Authentication A9-Setup-A8 A11-Registration Request (Lifetime, MEI)
f g h i j k
Tregreq
TA8-setup
Tregupd
A11-Registration Acknowledge A11-Registration Request (Lifetime=0) A11-Registration Reply (Lifetime=0, accept)
Tregreq
m n o
A9-Release-A8-Complete Connection Release
7 8
Figure 3.7.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 determines 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 determined 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-19
9 10 11 12 13 14 15 16 17 18
3GPP2 A.S0008-C v2.0

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
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. 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. f. 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 [29]. The AN authenticates the results of the challenge with the AN-AAA, which acts as a RADIUS server according to [31]. 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.4, 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. This message contains information on all A8 connections needed for the IP flow mapping maintained by the AN as negotiated over the air. The handoff indicator of the A9 Indicators IE shall be set to 0. h. The target PCF selects a PDSN for this call using PDSN selection algorithms as specified in [13]. The target PCF sends an A11-Registration Request message to the selected PDSN to set up an A10 connection for each service connection signaled by the AN in step g. The A11-Registration Request message includes the MEI within the CVSE and a non-zero Lifetime. This message also includes Accounting Data (A10 Connection Setup Airlink Record) as well as ANID information (CANID/PANID). The target PCF starts timer Tregreq. Refer to [13], Section 3.17.5.8, Inter-PCF Dormant Handoff - Mobile Continues to be Served by the Serving PDSN. i. The A11-Registration Request message is validated and the PDSN accepts the A10 connections 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. If the subscriber has a Subscriber QoS Profile, the PDSN includes it in an NVSE. The A10 connection binding information at the PDSN is updated to point to the target PCF. The target PCF stops timer Tregreq. The PDSN initiates closing of the A10 connections with the source PCF by sending an A11-Registration Update message. The PDSN starts timer Tregupd.
j.
k. The source PCF responds with an A11-Registration Acknowledge message. The PDSN stops timer Tregupd. l. 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 connections 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 that this step can occur any time after step i. o. The AN may initiate HRPD connection release. Refer to [10], Connection Layer.
3-20
3GPP2 A.S0008-C v2.0
1 2
3.8
Miscellaneous Active HRPD Session Call Flows
This section describes miscellaneous call flows associated with an established HRPD session. 3.8.1 Deactivation/Activation of Data Flow During an Active HRPD Packet Data Session
3 4 5
This scenario describes the call flow associated with the deactivation and activation of A8 traffic data flow during an active HRPD packet data session.
AT AN PCF PDSN time
Active HRPD Packet Data Session Data A9-AL Disconnected Data a b c
Tald9
A9-AL Disconnected Ack
Data A9-AL Connected
d e f
Talc9
A9-AL Connected Ack Data
6 7
Data
Figure 3.8.1-1 Activation /De-activation of Data Flow During Active HRPD Packet Data Session a. The PDSN transfers data to the AN through the PCF during an active HRPD packet data session. b. The AN determines that it is preferable not to receive A8 traffic data from the PCF, and the AN sends an A9-AL Disconnected message to the PCF to stop all data flows for the AT and starts timer Tald9. 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. d. The PCF stops the data flow and may buffer data received from the PDSN. Alternatively, the PCF may send an XOFF signal to the PDSN to prevent a buffer overflow at the PCF. In this case, the PDSN may optionally buffer the data. e. When the AN determines that it is preferable for all data flows for the AT to resume, the AN sends an A9-AL Connected message to PCF and starts timer Talc9. f. The PCF responds to the AN with an A9-AL Connected Ack message. The AN stops timer Talc9. g. The PCF resumes transmitting data received from the PDSN and buffered data if it exists.
8 9 10 11 12 13 14 15 16 17 18 19 20
3-21
3GPP2 A.S0008-C v2.0
1 2
3.9
Multiple Connection Procedures
3 4 5 6 7 8
3.9.1
Initial HRPD Call Setup (Default IP Flows Establishment)
As part of HRPD air interface connection establishment, forward and reverse IP flows with Flow ID = FFH are automatically established in the Activated state, and hence the main service connection is set up. If applicable, the PDSNs ROHC configuration parameters are sent to the RAN during main A8/A10 connections setup. Refer to 1.13.1.16. After this step completes, the AT may request additional IP flows, which the AN may map to auxiliary service connections, using the procedures in section 3.9.2. 3.9.2 IP Flow Mapping Update with Service Connection Establishment
9 10 11 12 13
This section describes the call flow associated with additions, deletions, remappings, and/or changes in granted QoS of IP flows that require establishment of a new service connection. The new mapping of IP flows may make existing service connections obsolete, in which case these service connections are released. 3.9.2.1 IP Flow Mapping Update with Service Connection Establishment All New Connections Establishment
14 15 16 17 18
This scenario describes the call flow associated with additions, deletions, remappings, and/or changes in granted QoS of IP flows that require establishment of a new service connection. Both PCF and PDSN support all additional new connections establishment corresponding to the new service connection.
AT Flow Configuration A9-Setup-A8 AN PCF PDSN time a b
T A8-setup
A9-Connect-A8
19 20 21
T regreq
A11-Registration Request (Lifetime) A11-Registration Reply
c d e
Figure 3.9.2.1-1
IP Flow Mapping Update with Service Connection Establishment - All New Connections Establishment
22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37
a. The AT and the AN perform session configuration for the IP flows and the AN maps new IP flows or reactivated IP flows to new service connections. For flow configuration, refer to [10]. Note: If the flow configuration is for emergency services or the AT is informed via SIP signaling that the network intends to initiate an emergency call, the Emergency Services indicator is provided to the PDSN via the A9 and A11 messaging. b. The AN sends an A9-Setup-A8 message to the PCF to establish the A8 connection and starts timer TA8-setup. The A9-Setup-A8 message includes the A8 Traffic ID for the main connection and Additional A8 Traffic IDs for auxiliary A8 connections. The negotiated ROHC configuration parameters are included if this message is establishing forward and/or reverse ROHC channels for PDSN-based ROHC on SO67. The A9-Setup-A8 message includes information on all A8 connections required for the new mapping, both those already established, and those to be established. A8 connections to be released are not included in the A9-Setup-A8 message. c. The PCF sends an A11-Registration Request message to establish the A10 connection. The PCF starts timer Tregreq. The A11-Registration Request message includes the Session Specific Extension IE for the main connection and Additional Session Information for auxiliary connections in NVSEs. The negotiated ROHC configuration parameters are included if this message is establishing forward 3-22
3GPP2 A.S0008-C v2.0

1 2 3 4 5 6 7 8 9 10 11 12 13 14
and/or reverse ROHC channels for PDSN-based ROHC on SO67. The PCF includes information on all A10 connections corresponding to A8 connections for which information was received in step b. d. The PDSN adds the new A10 connection and sends an A11-Registration Reply message to the PCF. The PCF stops timer Tregreq. The A11-Registration Reply message includes the Session Specific Extension for the main connection and Additional Session Information in the NVSE for auxiliary connections. The PDSN includes information on all A10 connections for which information was received in step c. The PDSN and PCF release the A10 connections for which information was not included in this message. e. The PCF adds the new A8 connection and sends an A9-Connect-A8 message to the AN. The AN stops timer TA8-setup. The A9-Connect-A8 message includes the A8 Traffic ID for the main connection and Additional A8 Traffic ID(s) for auxiliary connection(s). The A9-Connect-A8 message includes information on all A8 connections for which information was received in step b. The PCF and AN release the A8 connections for which information was not included in this message.
15 16 17 18 19 20 21 22 23
3.9.2.2
IP Flow Mapping Update with Service Connection Establishment - All New Connections Rejected by PCF/PDSN with Existing Connections Sustained
This scenario describes the call flow associated with additions, deletions, remappings, and/or changes in granted QoS of IP flows that require establishment of one or more new service connections. Either the PCF or the PDSN cannot support any new additional connections establishment due to a resource shortage or for other reasons. This call flow assumes that there are four connections (Main, ID1, ID2 and ID3) requested to be setup in the A9-Setup-A8 message, where Main, ID1 and ID2 are the existing connections. Since one A8 connection maps to one A10 connection, the call flow also uses the same A8 connection ID to identify the corresponding A10 connection.
24 25 26
Figure 3.9.2.2-1 IP Flow Mapping Update with Service Connection Establishment - All New Connections Rejected by PCF/PDSN with Existing Connections Sustained a. The AT and the AN perform session configuration for the IP flows and the AN maps new IP flows or reactivated IP flows to new service connections. For flow configuration, refer to [10]. Note: If the flow configuration is for emergency services or the AT is informed via SIP signaling that the network intends to initiate an emergency call, the Emergency Services indicator is provided to the PDSN via the A9 and A11 messaging. b. The AN sends an A9-Setup-A8 message to the PCF to establish the A8 connection and starts timer TA8-setup. The A9-Setup-A8 message includes the A8 Traffic ID for the main connection and Additional A8 Traffic IDs for auxiliary A8 connections. The negotiated ROHC configuration parameters are included if this message is establishing forward and/or reverse ROHC channels for PDSN-based ROHC on SO67. The A9-Setup-A8 message includes information on all A8 connections required for the new mapping, both those already established, and those to be established. A8 connections to be released are not included in the A9-Setup-A8 message. This call flow assumes that 3-23
27 28 29 30 31 32 33 34 35 36 37 38
3GPP2 A.S0008-C v2.0

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
the main A8 connection and connections ID1 and ID2 are already established, and that the A8 connection ID3 is to be established. The steps c and d are omitted if the PCF rejects any new service connection. c. The PCF sends an A11-Registration Request message to establish the A10 connection. The PCF starts timer Tregreq. The A11-Registration Request message includes the Session Specific Extension IE for the main connection and Additional Session Information for auxiliary connections that the PCF can support regarding its resource in NVSEs. The negotiated ROHC configuration parameters are included if this message is establishing forward and/or reverse ROHC channels for PDSN-based ROHC on SO67. The PCF includes information on all A10 connections corresponding to A8 connections for which the PCF can support to establish. This call flow assumes that the main A10 connection and connections ID1 and ID2 are already established, and that the A10 connection ID3 is to be established. d. The PDSN rejects all new A10 connection and sends an A11-Registration Reply message to the PCF. The PCF stops timer Tregreq. The A11-Registration Reply message includes the Session Specific Extension for the main connection and Additional Session Information in the NVSE for existing auxiliary A10 connection(s). The PDSN and PCF release the A10 connections for which information was not included in this message. In this call flow, it assumes A10 connection ID3 setup is rejected by the PDSN. e. The PCF sends an A9-Connect-A8 message to the AN. The AN stops timer TA8-setup. The A9Connect-A8 message includes the A8 Traffic ID for the main connection and Additional A8 Traffic ID(s) for existing auxiliary A8 connection(s). The A9-Connect-A8 message includes information on all A8 connections corresponding to the all A10 connections for which information was received in step d. The A9-Connect-A8 message includes Cause value Partial Connections. The PCF and AN release the A8 connections for which information was not included in this message. In this call flow, it includes main A8 connection and connections ID1 and ID2. f. AN and AT purge the IP flow which does not map to any A8 connection. AN and AT also update the stored Granted QoS profile. IP Flow Mapping Update with Service Connection Establishment - Partial New Connections Establishment
28 29 30 31 32 33 34 35 36 37
3.9.2.3
This scenario describes the call flow associated with additions, deletions, remappings, and/or changes in granted QoS of IP flows that require establishment of one or more new service connections. Either the PCF or the PDSN can only support partial new additional connections establishment due to a resource shortage or for other reasons. How the PCF or PDSN selects the connection to be rejected is a vendor specific issue. This call flow assumes that there are three connections (ID1, ID2 and ID3) requested to be setup in the A9-Setup-A8 message, however connection ID3 is rejected. Since one A8 connection maps to one A10 connection, the call flow also uses the same A8 connection ID to identify the corresponding A10.
3-24
3GPP2 A.S0008-C v2.0

time a b (Existing:Main;ID1,ID2,ID3) c (Lifetime,Main,ID1,ID2,ID3) d (Main, ID1,ID2) (Main, ID1,ID2)
1 2 3
TA8-setup
Tregreq
e f
Figure 3.9.2.3-1
IP Flow Mapping Update with Service Connection Establishment - Partial New Connections Establishment
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
a. The AT and the AN perform session configuration for the IP flows and the AN maps new IP flows or reactivated IP flows to new service connections. For flow configuration, refer to [10]. Note: If the flow configuration is for emergency services or the AT is informed via SIP signaling that the network intends to initiate an emergency call, the Emergency Services indicator is provided to the PDSN via the A9 and A11 messaging. b. The AN sends an A9-Setup-A8 message to the PCF to establish the A8 connection and starts timer TA8-setup. The A9-Setup-A8 message includes the A8 Traffic ID for the main connection and Additional A8 Traffic IDs for auxiliary A8 connections. The negotiated ROHC configuration parameters are included if this message is establishing forward and/or reverse ROHC channels for PDSN-based ROHC on SO67. The A9-Setup-A8 message includes information on all A8 connections required for the new mapping, both those already established, and those to be established. A8 connections to be released are not included in the A9-Setup-A8 message. This call flow assumes A8 connection ID1 is already established, and that A8 connections ID2 and ID3 are to be established. c. The PCF sends an A11-Registration Request message to establish the A10 connection. The PCF starts timer Tregreq. The A11-Registration Request message includes the Session Specific Extension IE for the main connection and Additional Session Information for auxiliary connections that the PCF can support regarding its resource in NVSEs. The negotiated ROHC configuration parameters are included if this message is establishing forward and/or reverse ROHC channels for PDSN-based ROHC on SO67. The PCF includes information on all A10 connections corresponding to A8 connections for which the PCF can support to establish. This call flow assumes A10 connection ID1 is already established, and that A10 connections ID2 and ID3 are to be established. d. The PDSN rejects part of the new A10 connections and sends an A11-Registration Reply message to the PCF. The PCF stops timer Tregreq. The A11-Registration Reply message includes the Session Specific Extension for the main connection and Additional Session Information in the NVSE for existing auxiliary A10 connection(s). The PDSN includes information on all A10 connections that it can support and Code value Registration Accepted, but partial connections establishment in A11Registration Reply message. The PDSN and PCF release the A10 connections for which information was not included in this message. This call flow assumes A10 connection ID3 setup is rejected by the PDSN. e. The PCF sends an A9-Connect-A8 message to the AN. The AN stops timer TA8-setup. The A9Connect-A8 message includes the A8 Traffic ID for the existing A8 connection(s). The A9-ConnectA8 message includes information on all A8 connections corresponding to the all A10 connections for which information was received in step d. The A9-Connect-A8 message includes Cause value Partial Connections Establishment. The PCF and AN release the A8 connections for which information was not included in this message. In this call flow, it includes A8 connections ID1 is and ID2.
3-25
3GPP2 A.S0008-C v2.0

1 2 3
f.
AN chooses to purge the IP flow which does not map to any A8 connection. AT can choose to accept this action, or to reject it that will close HRPD connection. If AT chooses to accept, AN and AT also update the stored Granted QoS profile. IP Flow Mapping Update with Service Connection Establishment - Main Connection Rejected by PCF/PDSN
4 5 6 7 8
3.9.2.4
This scenario describes the call flow associated with additions, deletions, remappings, and/or changes in granted QoS of IP flows that require establishment of a new service connection. Either the PCF or the PDSN rejects the main connection due to a resource shortage or for other reasons.
9 10 11
Figure 3.9.2.4-1
IP Flow Mapping Update with Service Connection Establishment - Main Connection Rejected by PCF/PDSN
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
a. The AT and the AN perform session configuration for the IP flows and the AN maps new IP flows or reactivated IP flows to new service connections. For flow configuration, refer to [10]. Note: If the flow configuration is for emergency services or the AT is informed via SIP signaling that the network intends to initiate an emergency call, the Emergency Services indicator is provided to the PDSN via the A9 and A11 messaging. b. The AN sends an A9-Setup-A8 message to the PCF to establish the A8 connection and starts timer TA8-setup. The A9-Setup-A8 message includes the A8 Traffic ID for the main connection and Additional A8 Traffic IDs for auxiliary A8 connections. The negotiated ROHC configuration parameters are included if this message is establishing forward and/or reverse ROHC channels for PDSN-based ROHC on SO67. The A9-Setup-A8 message includes information on all A8 connections required for the new mapping, both those already established, and those to be established. A8 connections to be released are not included in the A9-Setup-A8 message. c. The PCF sends an A11-Registration Request message to establish the A10 connection. The PCF starts timer Tregreq. The A11-Registration Request message includes the Session Specific Extension IE for the main connection and Additional Session Information for auxiliary connections that the PCF can support regarding its resource in NVSEs. The negotiated ROHC configuration parameters are included if this message is establishing forward and/or reverse ROHC channels for PDSN-based ROHC on SO67. The PCF includes information on all A10 connections corresponding to A8 connections for which the PCF can support to establish. If PCF rejects the main A8 connection setup, the PCF sends A11-Registration Request message with life time to zero to release all the existing A10 connections. d. If the PDSN rejects the main A10 connection establishment, the PDSN sends an A11-Registration Reply message to the PCF with Code value Registration Denied insufficient resources. If the PDSN receives an A11-Registration Request message with life time to zero, the PDSN sends an A11Registration Reply message to the PCF with Code value Registration Accept. The PCF stops timer Tregreq. The PDSN and PCF release all the existing A10 connections for the AT.
3-26
3GPP2 A.S0008-C v2.0

1 2 3 4 5 6 7 8
e. If the PCF rejects main connection, or receives an A11-Registration Reply message with Code value Registration Denied insufficient resources, the PCF sends A9-Release-A8 Complete message to the AN with Cause value set to PCF resources are not available (when PCF rejects main connection) or PDSN resources are not available (when receiving A11-Registration Reply message with Code value Registration Denied insufficient resources). The AN stops timer TA8-setup. The PCF and AN release the A8 connections for the AT. f. The AN and AT release the HRPD connection. For HRPD Connection release, refer to [10].
9 10 11 12 13
3.9.3
IP Flow Mapping Update with Service Connection Release
This scenario describes the call flow associated with additions, deletions, remappings, and/or changes in granted QoS of IP flows that require release of one or more service connections, but no service connection establishment. This procedure applies to cases where one or more but not all of the established A8/A10 connections are released. This call flow does not apply to release of Flow ID=FFH.
AT Flow Configuration A9-Release-A8 (Cause; Partial connection release) AN PCF PDSN time a b A11-Registration Request (Lifetime) A11-Registration Reply A9-Release-A8 Complete c
Trel9
Tregreq
d e
14 15
Figure 3.9.3-1 IP Flow Mapping Update with Service Connection Release a. The AT and the AN perform session configuration for the IP flows and the AN maps the IP flows to a proper subset of the existing service connections. For flow configuration, refer to [10]. b. The AN sends an A9-Release-A8 message with the Cause value set to Partial connection release to the PCF and starts timer Trel9. The A9-Release-A8 message includes the A8 Traffic ID for the main connection and Additional A8 Traffic IDs for auxiliary connections. The A9-Release-A8 message includes information on A8 connections that are to be used after this release procedure. Information on A8 connections to be released is not included in the A9-Release-A8 message. c. The PCF sends an A11-Registration Request message with lifetime set to a non-zero value to the PDSN. The A11-Registration Request message includes the Session Specific Extension for the main connection and Additional Session Information in the NVSE for auxiliary connections. The A11Registration Request message includes information on A10 connections corresponding to A8 connections for which information was received in step b. Information on A10 connections to be released is not included in the A11-Registration Request message. The PCF starts timer Tregreq. d. The PDSN releases the A10 connections that were not included in the A11-Registration Request message and sends an A11-Registration Reply message to the PCF. The A11-Registration Reply message includes the Session Specific Extension for the main connection and Additional Session Information for auxiliary connections in NVSEs. The A11-Registration Reply message includes information on A10 connections for which information was received in step c. Information on released A10 connections is not included in the A11-Registration Reply message. The PCF stops timer Tregreq. The PCF releases the A10 connections for which information was not included in this message
16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36
3-27
3GPP2 A.S0008-C v2.0

1 2 3 4
e. The PCF releases the A8 connections that were not included in the A9-Release-A8 message and sends an A9-Release-A8 Complete message to the AN. The AN stops Trel9. The AN releases A8 connections for which information was not included in this message.
5 6 7 8
3.9.4
IP Flow to A8/A10 Connection Mapping Update
This scenario describes the call flow associated with additions, deletions, remappings, changes in granted QoS, and/or changes in flow state of IP flows, provided no new service connections are established and no existing service connections are released.
AT Flow Configuration A9-Update-A8 AN PCF PDSN time a b
T upd9
T regreq
A11-Registration Request (Lifetime) A11-Registration Reply
c d e
A9-Update-A8 Ack
9 10
Figure 3.9.4-1 IP Flow Mapping Update a. The AT and the AN perform session configuration for the IP flow(s) and the AN maps the IP flows to the existing service connections. For flow configuration, refer to [10]. Note: If the flow configuration is for emergency services or the AT is informed via SIP signaling that the network intends to initiate an emergency call, the Emergency Services indicator is provided to the PDSN via the A9 and A11 messaging. b. The AN sends an A9-Update-A8 message to the PCF to update the flow mapping information and starts timer Tupd9. c. The PCF sends an A11-Registration Request message including flow mapping changes, with lifetime set to a non-zero value to the PDSN. The A11-Registration Request message includes information on all A10 connections corresponding to service connections for which information was received in step b. The PCF starts timer Tregreq. d. The PDSN sends an A11-Registration Reply message to the PCF. The A11-Registration Reply message includes information on all A10 connections for which information was received in step c. The PCF stops timer Tregreq. e. The PCF sends an A9-Update-A8 Ack message to the AN. The AN stops timer Tupd9. 3.9.5 Subscriber QoS Profile Delivery
11 12 13 14 15 16 17 18 19 20 21 22 23 24 25
26 27 28 29 30 31 32
This scenario describes the call flow associated with delivery of a new or updated Subscriber QoS Profile. Subscriber QoS Profile delivery occurs when the PDSN receives Subscriber QoS information in a RADIUS Access-Accept message and the PPP session exists. The PDSN shall save the Subscriber QoS Profile and include it in an A11-Registration Reply message to the target PCF in the event of a dormant handoff. For Subscriber QoS Profile transfer during dormant handoff, refer to section 3.7. After receiving the Subscriber QoS Profile, the AN may initiate IP Flow Update procedures if needed.
3-28
3GPP2 A.S0008-C v2.0
1 2
Figure 3.9.5-1 Subscriber QoS Profile Transfer a. The AT has an active or dormant packet data session. The PDSN has a new or updated Subscriber QoS profile to deliver to the RAN. The PDSN sends an A11-Session Update message including the Subscriber QoS profile to the PCF. The PDSN starts timer Tsesupd. b. The PCF sends an A9-Update-A8 message containing the Subscriber QoS profile to the AN and starts timer Tupd9. c. The AN sends an A9-Update-A8 Ack message to provide the results of the A9-Update-A8 message. The PCF stops timer Tupd9 upon receipt of this message. d. The PCF sends an A11-Session Update Ack message to the PDSN to show the result of A11-Session Update message. The PDSN stops timer Tsesupd upon receipt of this message. e. If the AN remaps the IP flows, the procedures in sections 3.9.4 to 3.9.5 are performed. This step may occur anytime after step b.
3 4 5 6 7 8 9 10 11 12 13 14
15 16 17 18 19 20 21 22 23
3.9.6
QoS Update by the PDSN
This scenario describes the call flow associated with a QoS Update by the PDSN. The trigger for QoS update by the PDSN is operator configurable and is outside the scope of this document. After receiving the Updated QoS information, the AN/PCF initiates IP Flow Update procedures if needed. The PDSN may send a QoS Update for any IP flow requested by the AT, even if the AN did not grant (but did not reject 23) the IP flow. The QoS update for an IP flow includes a list of one or more Flow Profile IDs. A Flow Profile ID value of 0x0000 indicates that the AN shall inform the AT that requested QoS_SUB_BLOB has been added but is invalid for this AN and the AT should not activate the corresponding IP flow 24.
23
A reservation that is rejected via the attribute update reject message will be deleted; hence it cannot be upgraded later.
24 The AN can signal this to the AT by setting QoS_ATTRIBUTE_SET_ID to 0000000 [8]).
3-29
3GPP2 A.S0008-C v2.0

AT AN PCF Packet Data Session A11-Session Update A9-Update-A8 A9-Update-A8 Ack PDSN
time a b c d e f*
T A8-upd9
A11-Session Update Ack
T sesupd
IP Flow Mapping Update

1 2
* = conditional
Figure 3.9.6-1 QoS Update by the PDSN a. The PDSN and the AT have an active or dormant packet data session. b. The PDSN initiates QoS update for one or more IP flows in the RAN. The PDSN sends an A11Session Update message including updated QoS information to the PCF. The PDSN starts timer Tsesupd. c. The PCF sends an A9-Update-A8 message to the AN and starts timer Tupd9. d. The AN sends an A9-Update-A8 Ack message to show the result of A9-Update-A8 message. The PCF stops timer Tupd9 upon receipt of this message. e. The PCF sends an A11-Session Update Ack message to the PDSN to show the result of A11-Session Update message. If the RAN does not have sufficient resources available to comply with the updated QoS for all of the specified flows, then the PCF may reject the A11-Session Update message by setting the Status IE to Update Denied insufficient resources. If the A11-Session Update message includes updated QoS and the RAN only has resources available to comply with the updated QoS for some of the specified flows, the PCF may respond by sending an A11-Session Update Ack message with the Status IE set to cause value Partial QoS updated. The PDSN stops timer Tsesupd upon receipt of this message. Step f can occur any time after step c. f. If the AN accepted all or part of the QoS update then the procedure in section 3.9.4 is performed. For each IP Flow updated by the PDSN, the AN shall change the granted QoS to the corresponding QoS_ATTRIBUTE_SET_ID in the R_QoS_SUB_BLOB that matches the first acceptable Flow Profile ID in the U_QoS_SUB_BLOB, irrespective of the contents of the Subscriber QoS Profile. If there is a Flow Profile ID with the value 0x0000 in the U_QoS_SUB_BLOB for an IP Flow, then the AN shall inform the AT that requested QoS_SUB_BLOB has been added but is invalid for this AN and the AT should not activate the corresponding IP flow. PDSN Initiated IP Flow Release
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
3.9.7
This section describes the call flow associated with one or more IP flows released by the PDSN. The PDSN should not use this procedure for flow ID FFH and FEH. The trigger for IP flow release by the PDSN is outside of the scope of this document. It could be due to operators policy implementation, OAM&P intervention, or an account shortage for a pre-paid user. The call flow in the section 3.9.6 QoS update by the PDSN shall be used to achieve this purpose by setting the FlowProfile ID value to 0x0000 in the Forward/Reverse Updated QoS Sub-BLOB for the IP flow that the PDSN wants to release. The AN shall inform the AT that the requested QoS_SUB_BLOB has been added but is invalid for this AN and the AT should not activate the corresponding IP flow.
3-30
3GPP2 A.S0008-C v2.0
1 2
3.10
Support for Data Over Signaling Protocol
This section describes call flows associated with the Data Over Signaling (DoS) feature. 3.10.1 AT Originated DoS DoS messages support sending small amounts of data from the AT to the AN over the signaling channel when the AT has a dormant packet data session. The AN should only enable reverse link DoS as defined in [10] for IP flows that require expedited service. This restriction does not apply to reverse link DoS messages as defined in [20]. If an AT with a currently dormant packet data session has a small amount of data to send for a given IP flow and the AN has enabled reverse link DoS for that IP flow, then the AT may transmit the data to the AN in DoS format as specified in [10] or [20]. Data associated with a given IP flow that is received from the AT in a DoS message containing a Flow ID as specified in [20] should be given the same treatment as regular packets of that IP flow. Data received from the AT in a DoS message as specified in [10] does not contain a Flow ID but should be given expedited treatment through the RAN transport network. Expedited treatment is an implementation issue. 3.10.1.1 DoS Delivery from the AT to the PDSN without A13 Procedure
3 4 5 6 7 8 9 10 11 12 13 14
15 16 17
This scenario describes the call flow associated with the receipt of a DoS message as specified in [10] or [20], from the AT and the delivery of the data contained therein to the PDSN.
AT AN PCF PDSN time
Dormant HRPD Packet Data Session IP Flow Reactivation a conditional
DoS Messaging A9-Short Data Delivery Packet Data
b c d
Dormant HRPD Packet Data Session
18 19
Figure 3.10.1.1-1
HRPD DoS from an AT to the PDSN without A13 Procedure
20 21 22 23 24 25 26 27 28
a. The AT decides to send a higher-layer packet in DoS format since the packet data session is dormant. If the IP flow for which the packet needs to be sent is in the Deactivated state, it is transitioned to the Activated state. b. The AT sends DoS messaging to deliver the higher-layer packet to the AN via the common channel. c. The AN sends the data to the PCF in a DoS message format in the A9-Short Data Delivery message (refer to Annex C). d. If the Flow ID is not known, the PCF sends the data with expedited treatment to the PDSN as normal packet data. If the Flow ID is known, the PCF sends the data to the PDSN as normal packet data on the appropriate A10 connection for that IP flow. 3.10.1.2 DoS Delivery from the AT to the PDSN with A13 Procedure
29 30 31
This scenario describes the call flow associated with the receipt of a DoS message as specified in [10] or [20], from the AT and the delivery of the data contained therein to the PDSN. This scenario assumes that 3-31
3GPP2 A.S0008-C v2.0

1 2 3
the target AN needs to acquire the session state information for the AT and the target AN does not have A10 connection with the PDSN. This procedure may be used in support of secondary color code. This call flow assumes intra-PDSN case.
AT Source AN Target AN Source PCF Target PCF PDSN time
Dormant HRPD Packet Data Session DoS Messaging Session Transfer A9- Setup- A8 a b c A11- Registration Request d e f g conditional h i j k l A10 Packet Dormant HRPD Packet Data Session m
TA8- Setup
Tregreq
A9- Release- A8 Complete
A11- Registration Reply
DoS Messaging A11- Registration Update A11- Registration Acknowledge
Tregupd
Tregreq
A11- Registration Request (Lifetime=0) A11- Registration Reply
A9- Short Data Delivery
4 5
Figure 3.10.1.2-1
HRPD DoS from an AT to the PDSN with A13 Procedure
6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
a. The AT sends DoS messaging to deliver the higher-layer packet to the target AN via the common channel. It is assumed that IP flow for the DoS is opened. b. The source AN and the target AN perform session transfer over A13 interface (refer to 3.7). c. 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. d. The target PCF sends an A11-Registration Request message to the PDSN and starts timer Tregreq. e. The PDSN sends an A11-Registration Reply message to the target PCF. Upon receipt of this message, the target PCF stops timer Tregreq. f. The target PCF sends an A9-Release-A8 Complete message. Upon receipt of this message, the target AN stops timer TA8-Setup.
g. The acknowledgement of DoS may be sent, if acknowledgement is required. This step can occur anytime after step b. h. The PDSN sends an A11-Registration Update message to the source PCF to request releasing an A10 connection and starts timer Tregupd. i. j. The source PCF sends an A11-Registration Acknowledge message to the PDSN. Upon receipt of this message, the PDSN stops timer Tregupd. The source PCF sends an A11-Registration Request message with lifetime set to 0 to the PDSN to release the A10 connection and starts timer Tregreq. 3-32
3GPP2 A.S0008-C v2.0

1 2 3 4 5 6 7
k. The PDSN sends an A11-Registration Reply message to the source PCF. Upon receipt of this message, the source PCF stops timer Tregreq. l. The target AN sends the data to the PCF in DoS message format in the A9-Short Data Delivery message (refer to Annex C). This step can occur anytime after step f.
m. If the Flow ID is not known, the target PCF sends the data with expedited treatment to the PDSN as normal packet data. If the Flow ID is known, the target PCF sends the data to the PDSN as normal packet data on the appropriate A10 connection for that IP flow. 3.10.2 AT Terminated DoS When a small amount of data destined for an IP flow on an AT is received at the PCF, the PCF may send this data to the AN in DoS format as specified in [10] or [20]. The PDSN may indicate suitability of sending the data to the AT in DoS format via an attribute in its GRE payload as specified in Annex A. If the AN determines that a DoS message is to be used to deliver the data to the AT, the AN sends the data, in DoS format as specified in [10] or [20], directly to the AT. The PCF is informed of successful delivery of the DoS message via the A9-Short Data Ack message and may subsequently discard the buffered data. If after receiving data from the PCF in DoS format the AN determines that the packet data session should be re-activated, it shall reject the PCFs request to send the data in DoS format by sending the cause value Initiate re-activation of packet data call in the A9-Short Data Ack message. The PCF shall then be required to initiate the re-activation of the packet data session. Once the session is active, the buffered data shall be resent to the AN for transmission to the AT as normal packet data. 3.10.2.1 DoS Delivery from the PDSN to the AT
8 9 10 11 12 13 14 15 16 17 18 19 20
21 22 23
This scenario describes the call flow associated with the receipt of a short data message from the PCF and its delivery to the AT over the control channel.
AT AN PCF PDSN time
Dormant HRPD Packet Data Session Packet Data A9-Short Data Delivery IP Flow Reactivation a b c conditional
Tsdd9
DoS Messaging A9-Short Data Ack d e
24 25
Figure 3.10.2.1-1
HRPD DoS from the PDSN to the AT
26 27 28 29 30 31 32
a. The PDSN sends packet data to the PCF on an existing PPP connection and A10 connection associated with a specific AT. The GRE header may also include an attribute indicating suitability of the payload for transmission in DoS format. b. The PCF sends the packet data to the AN in the A9-Short Data Delivery message and starts timer Tsdd9. The data is sent in DoS format as specified in [10] or [20] and is encapsulated in the ADDS user part IE. This message includes the Flow ID of the IP flow from the GRE header of the packet received across the A10 interface. The PCF buffers the data sent. 3-33
3GPP2 A.S0008-C v2.0

1 2 3 4 5 6 7 8 9 10
c. If the IP flow identified in the A9-Short Data Delivery message is in the De-activated state, the AN initiates signaling to transition it into the active state. d. The AN may send the packet data in DoS format by sending a DoS message directly to the AT, or alternatively the AN may also decide to deliver the data to the AT over a traffic channel after reactivating the packet data session. Subsequent steps in the call flow assume delivery of the message via DoS messaging to the AT. e. The AN sends an A9-Short Data Ack message to the PCF to indicate successful delivery of the data to the AT in DoS format. The PCF stops timer Tsdd9 and discards the buffered data. This message has the cause value set to SDB successfully delivered to indicate the SDB was successfully delivered to the AT. 3.10.2.2 DoS Request from the PDSN AN Refuses Request
11 12 13
This scenario describes the call flow associated with the AN refusal of the PCF DoS request, and subsequent delivery of the data to the AT on a traffic channel.
AT AN PCF PDSN time
Dormant HRPD Packet Data Session Packet Data A9-Short Data Delivery A9-Short Data Ack a b
Tsdd9
Network initiated call re-activation from Dormant State
Active HRPD Packet Data Session
14 15
Figure 3.10.2.2-1
DoS from the PDSN to the AT AN Refuses DoS Request
16 17 18 19 20 21 22 23 24 25 26 27 28 29
a. The PDSN sends packet data to the PCF on an existing PPP connection and A10 connection associated with a specific AT. The GRE header may include an attribute indicating suitability of the payload for SDB transmission in DoS format. b. The PCF sends the packet data to the AN in the A9-Short Data Delivery message and starts timer Tsdd9. The data is sent in DoS format as specified in [10] or [20] and is encapsulated in the ADDS user part IE. This message includes the Flow ID of the IP flow from the GRE header of the packet received across the A10 interface. The PCF buffers the data sent. c. The AN makes the determination, based on its internal algorithm, the data count field in the A9-Short Data Delivery, or any other factors, not to send a DoS message to the AT. The AT sends an A9-Short Data Ack message to the PCF with an indication that a DoS message is not to be sent to the AT by setting the cause value to Initiate re-activation of packet data call. The PCF stops timer Tsdd9. d. The PCF initiates reactivation of the packet data service. Refer to section 3.3.1. Once the packet data session is active, the PCF sends the data buffered earlier for the AT to the AN which forwards the data on to the AT. 3.10.2.3 DoS Delivery from the PDSN to the AT with A13 Procedure
30 31 32 33
DoS Delivery to target AN is performed by using A13 paging procedure. When the AT responds the paging under target AN, the data is delivered over HRPD connection. Refer to section 3.11.3, Idle State Paging Call Flow. 3-34
3GPP2 A.S0008-C v2.0
1 2
3.11
Mobility Management
This section describes the call flows associated with mobility management. 3.11.1 Prior Session Retrieval Procedure This scenario describes the call flow associated with prior session retrieval. This scenario assumes that the network is configured for prior session retrieval, based on an operators policy.
AT
UATI Assignment
3 4 5
Target AN
Source AN a
Hardware ID Acquisition
b optional
Session Establishment Configuration Request (Prior Session Attribute) c A13 Session Information Request TA13req A13 Session Information Response TA13res A13 Session Information Confirm g e f d
Configuration Response (Accept)
6 7
Figure 3.11.1-1
Prior Session Retrieval using Prior Session Attribute
8 9 10 11 12 13 14 15 16 17 18 19 20 21 22
a. The AT had an active session with the source AN but the AT closed the session. The AT subsequently attempts to access the target AN. The AT sends a UATIRequest message with a Random Access Terminal Identifier (RATI) to request that a UATI be assigned to it. Upon receipt of the UATIRequest message, the target AN assigns the new UATI to the AT. b. The target AN may request Hardware ID from the AT. This step may occur anytime before step d. c. The AT performs the session establishment procedure by sending a Configuration Request message including PriorSession Attribute to the target AN. d. Upon receipt of the Configuration Request message with the PriorSession Attribute during the session establishment, the target AN sends an A13-Session Information Request message to the source AN to request the HRPD session information related to the prior session UATI for the AT. This message includes the Sector ID, Security Layer Packet and Hardware ID, if this information is available. The target AN starts timer TA13req. e. When the source AN receives the A13-Session Information Request message, it (depending on operators policy) checks if the Hardware ID and/or the Security Layer Packet sent in the message verify the identity of the session information 25. Subsequently, the source AN sends the requested
25 Based on operators policy, the source AN may not use Security Layer Packet to authenticate the session. However, this may compromise the security of the system.
3-35
3GPP2 A.S0008-C v2.0

1 2 3 4 5 6 7 8 9
HRPD session information for the AT to the target AN in an A13-Session Information Response message and starts timer TA13res. Upon receipt of the A13-Session Information Response message, the target AN stops timer TA13req. f. The target AN sends a Configuration Response message to the AT to complete the session establishment using the prior session information.
g. If the session received from the source AN matches with the AT, then the target AN sends an A13Session Information Confirm message 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 stops timer TA13res and deletes the HRPD session information of the AT. 3.11.2 Prior Session Removal Procedure This scenario describes the call flow to remove prior session information in the case of expiration of the session retrieval timer (i.e. timer TA13req in section 3.11.1) or operators policy.
AT Target AN Source AN
10 11 12
UATI Assignment
a b optional
Hardware ID Acquisition
Session Establishment Configuration Request (Prior Session Attribute) c A13 Resource Release Request TA13rel A13 Resource Release Response
13 14
d e f
Configuration Response (Null)
Figure 3.11.2-1
Prior Session Removal Procedure
15 16 17 18 19 20 21 22 23 24 25 26 27 28
a. The AT had an active session with the source AN but the AT closed the session. The AT subsequently attempts to access the target AN. The AT sends a UATIRequest message with a Random Access Terminal Identifier (RATI) to request that a UATI be assigned to it. Upon receipt of the UATIRequest message, the target AN assigns the new UATI to the AT. b. The target AN may request Hardware ID from the AT. This step may occur anytime before step d. c. The AT performs the session establishment procedure using the Configuration Request message, including the Prior Session Attribute. If the target AN received the Prior Session Attribute in the Configuration Request message, this call flow assumes that the target AN is configured to release the prior session information on the source AN after receiving Prior Session Attribute. d. The target AN sends an A13-Resource Release Request message including the prior session UATI as the session identifier to the source AN. In addition, the target AN includes the Sector ID, Security Layer Packet and Hardware ID, if this information is available. The target AN starts timer TA13rel. e. The target AN sends the Configuration Response message with the Prior Session Attribute set to Null. This step may occur anytime after step c. 3-36
3GPP2 A.S0008-C v2.0

1 2 3 4 5 6 7 8 9
f.
When the source AN receives the A13-Resource Release Request message, it (depending on operators policy) checks if requested session information is stored in the source AN, and releases the session information related to the PriorSession Attribute if the Hardware ID and/or the Security Layer Packet sent in the message verify the identity of the session information 26. In addition, the source AN may initiate release the A8 and A10 connections of the prior session. The source AN sends the A13Resource Release Response message including the result for handling the A13-Resource Release Request message to the target AN. Upon receipt of the A13-Resource Release Response message, the target AN stops timer TA13rel.
10 11 12 13
3.11.3 Inter-AN Paging when the AT is in Idle State This section describes the call flow where the source AN pages an AT in one or more RTs belonging to target ANs. This call flow assumes that the source AN/PCF and the target AN/PCF belong to the same PDSN.
26 Based on operators policy, the source AN may not use Security Layer Packet to authenticate the session. However, this may compromise the security of the system.
3-37
3GPP2 A.S0008-C v2.0
1 2
Figure 3.11.3-1 Inter-AN Paging when the AT is in Idle State Successful Scenario a. The AT registers at a border sector such that the paging area covers one or more RTs belonging to the target ANs. This may be due to distance-based paging or subnet hysteresis using secondary colorcode. The AT subsequently becomes dormant. b. The PDSN sends packet data for the AT to the source PCF. c. The source PCF sends an A9-BS Service Request message to the source AN and starts timer Tbsreq9.
3 4 5 6 7
3-38
3GPP2 A.S0008-C v2.0

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
d. The source AN sends an A9-BS Service Response message back to the source PCF. The source PCF stops timer Tbsreq9. The source AN determines that it needs to page the AT through some RTs in the source AN and some RTs in target AN1 and target AN2. e. The source AN sends an A13-Paging Request message to target AN1 and starts timer Tpreq-13. The A13-Paging Request message contains the necessary session information for the target ANs to determine the paging area and the paging cycle of the AT. The message may optionally include timing information of when the page is to be transmitted over-the-air by the source AN. If the target ANs can transmit the page over-the-air in the same slot, then the chance that the AT will miss the page is reduced. f. The source AN also sends an A13-Paging Request message to target AN2 and starts timer Tpreq-13. g. Target AN1 sends an A13-Paging Request Ack message back to the source AN. Upon receipt of the A13-Paging Request Ack message, the source AN stops the corresponding timer Tpreq-13. h. Target AN2 sends an A13-Paging Request Ack message back to the source AN. Upon receipt of the A13-Paging Request Ack message, the source AN stops the corresponding timer Tpreq-13. i. The source AN, target AN1 and target AN2 transmit the page to the AT over the control channel. This call flow assumes that the AT receives the page from target AN1. If the AT receives the page from the source AN, then the AT accesses through the source AN. Refer to section 3.3.1. After the AT receives the page message, the AT requests an HRPD connection using the UATI assigned by the source AN. This call flow assumes that target AN1 receives the request from the AT. Target AN1 does not recognize the UATI and hence it initiates session retrieval procedure with the AN identified by the UATI.
j.
k. Target AN1 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. If target AN1 can accept buffered data from the source AN, it may also include the Data Transfer IE with the A24 Connection ID to be used for data transfer. Target AN1 starts timer TA13req. Upon receipt of the A13-Session Information Request message, the source AN should stop its attempt to page the AT. l. If target AN1 has indicated that it can accept buffered data and the source AN is capable of sending buffered data, the source AN validates the A13-Session Information Request message and may send an A9-Setup-A8 message, with the Data Ready Indicator set to 1, to the source PCF to establish an A8 connection for receiving the buffered data. The source AN starts timer TA8-setup.
m. The source PCF may send an in-band flow control Xoff signal to the PDSN to stop data transmission from the PDSN, if the flow control feature is activated. n. The source PCF sends an A9-Connect-A8 to the source AN, When the source AN receives this message it stops timer TA8-setup. o. If the source AN initiated setup of the A8 connection, data may be received from the source PCF. p. The source AN validates the A13-Session Information Request and message (if it has not already done so in step l) sends the requested HRPD session information of the AT to target AN1 in an A13-Session Information Response message. If target AN1 has indicated that it can accept buffered data and the source AN has buffered data to send, the source AN may also include the Data Transfer IE listing which RLP_IDs are used for A24 data transfer. Target AN1 stops timer TA13req. q. If the source AN included the Data Transfer IE in the A13-Session Information Response message in step r, it begins sending the buffered data to target AN1. The Buffered Data Information attribute identifies to which RLP flow each packet should be mapped.
3-39
3GPP2 A.S0008-C v2.0

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
r.
Target AN1 sends an A13-Session Information Confirm to the source AN to indicate that target AN1 has received the HRPD session information. Upon receipt of the A13-Session Information Confirm message the source AN deletes the associated AT HRPD session information. The AT and target AN1 complete the establishment of the HRPD session. Depending on the state of the AT and target AN1, either an existing HRPD session may be re-established, or a new HRPD session may be initiated if required. Target AN1 also assigns a new UATI to the AT. If buffered data was received from the source AN in step q, target AN1 may begin sending the data to the AT.
s.
t.
u. The target AN1 sends an A9-Setup-A8 message, with Data Ready Indicator set to 1, to the target PCF and starts timer TA8-setup. v. The target PCF sends an A11-Registration Request message to the PDSN to set up an A10 connection and starts timer Tregreq. w. The A11-Registration Request message is validated and the PDSN accepts the A10 connections 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. If the subscriber has a Subscriber QoS Profile, the PDSN includes it in an NVSE. The A10 connection binding information at the PDSN is updated to point to the target PCF. The target PCF stops timer Tregreq. x. The target PCF responds to target AN1 with an A9-Connect-A8 message. Target AN1 stops timer TA8-setup. y. Once the A8 and A10 connections are established for the AT, target AN1 may begin to receive data for the AT from the PDSN. If the source AN indicated that it had buffered data to send (i.e., the A13Session Information Response message in step p included the Data Transfer IE, target AN1 may choose to delay 27 the new data until the buffer indicator is received from the source AN in the Buffered Data Information attribute or until an implementation specific time after receipt of the A13Session Information Response message, if no buffer indicator is received. z. If the PDSN has A10 connections to another PCF (e.g., the source-PCF), it initiates closure of the A10 connections with that PCF by sending an A11-Registration Update message. The PDSN starts timer Tregupd. aa. The source PCF responds with an A11-Registration Acknowledge message. The PDSN stops timer Tregupd. bb. The source PCF sends an A11-Registration Request message with Lifetime set to zero, to the PDSN. The source AN/PCF starts timer Tregreq. cc. The PDSN sends an A11-Registration Reply message to the source PCF. The source PCF closes the A10 connections for the AT and stops timer Tregreq. dd. If the source AN setup the A8 connection in step l for buffered data transfer, the source PCF sends an A9-Disconnect-A8 message to the source AN and starts timer Tdiscon9. ee. The source AN sends an A9-Release-A8 message with a cause value set to Normal call release, to the source PCF to request the source PCF to release all the associated dedicated resources. The source AN starts timer Trel9. The source PCF stops timer Tdiscon9. ff. The source PCF acknowledges the A9-Release-A8 message by returning an A9-Release-A8 Complete message. The source AN stops timer Trel9.
27 Delay could be for non-real time sensitive data (e.g., not for VoIP). Note if Enhanced Multi-Flow Packet Application is used, the data transfer delay can be avoided by the use of two routes.
3-40
3GPP2 A.S0008-C v2.0

1 2 3 4 5 6
gg. If the source AN had data to send, it waits until after the A8 connection is released to include a buffer indicator in the Buffered Data Information GRE attribute in the A24 buffered data. Refer to Annex A, section 2.6.1.5. hh. If buffered data was sent from the source AN and new data was delayed, then upon receipt of the buffer indicator, target AN1 may begin data deliver between the AT and the PDSN.
3-41
3GPP2 A.S0008-C v2.0
1 2 3
3.12
Connected State HRPD Session Transfer Call Flows
This section describes the call flows associated with an HRPD hard handoff between two ANs when the HRPD session is in Connected State. 3.12.1 Intra-PDSN Connected State HRPD Hard Handoff - Successful Operation This scenario describes the call flow associated with an HRPD hard handoff between ANs when the HRPD session is in Connected State and the source AN cannot include sectors from the target AN in the Active Set. This call flow assumes that the target PCF can reach the source PDSN.
4 5 6 7 8
3-42
3GPP2 A.S0008-C v2.0

AT Source AN decides to transfer the session to Target AN Source AN locks session configuration in the AT A9- AL Disconnected A9- AL Disconnected Ack A16- Session Transfer Request Source AN Source PCF Target AN Target PCF PDSN time a
b c d e f g A9- Setup-A8 A 11Registration Request A11Registration Reply h i Optional Optional Conditional
Tald9
A10 : XOFF
T streq-16
A 16- Session Transfer Response
TA8- setup
Source AN may close connection or may initiate application- layer route reset . At the same time, Source AN assigns new connection to the AT
T regreq
T stcomp- 16
A9- Connect-A8
j k l
A 16- Session Transfer Complete
Target AN acquires the AT and may complete an application layer route reset -
A9- AL Connected
n A11Registration Request ( Active Start) A 11Registration Reply o p Conditional Conditional
T stack-16
T alc9
T regreq
A9- AL Connected Ack
q Conditional r Conditional s Conditional t
Target AN may assign new UATI to the AT and receives confirmation A16- Session Release Indication
T strel-16
A16- Session Release Indication Ack Target AN unlocks session configuration in the AT A11- Registration Update A11- Registration Acknowledge A9- Disconnect-A8 A9- Release-A8 u v Conditional
T regupd w
x y z aa bb cc
T discon9
A11- Registration Request ( Lifetime=0) A11- Registration Reply ( Lifetime=0 , accept)
TSClose-13 T rel9
T regreq
A9- Release-A8 Complete
A13-Keep Alive Request A13-Keep Alive Response
TKeepAlive-13
dd ee ff
TSClose-13
Connection between AT and Target AN closes A13- Resource Release Request A 13- Resource Release Response 1 2
TA13 rel
gg hh
Figure 3.12.1-1 Intra-PDSN Connected State HRPD Hard Handoff -- Successful Operation a. The source AN decides that the HRPD session should be transferred via hard handoff to the target AN. This is triggered according to a session transfer trigger algorithm which can be based on several criteria such as receipt of a RouteUpdate message [10] which indicates that the AT location is too far from the source AN according to a metric defined by the operator and at least one of the reported sectors is supported by the target AN. This call flow assumes that the source AN cannot include sectors that belong to the target AN in the Active Set and so the source AN initiates a hard handoff to the target AN. 3-43
3 4 5 6 7 8 9
3GPP2 A.S0008-C v2.0

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 48
b. The source AN locks the AT session, e.g., by sending a LockConfiguration message to the AT as specified in [10]. New session configuration or attribute update cannot take place while the session is locked. If the AT cannot support locking the session, then the source AN begins to ignore all session reconfiguration requests from the AT. The source AN will only resume processing session reconfiguration requests from the AT if the session transfer is aborted. c. The source AN may send an A9-AL Disconnected message to the source PCF to stop data transmission from the source PCF. The A9-AL Disconnected message may indicate the SR_IDs for which the PCF does not stop transmission. The source AN starts timer Tald9. d. The source PCF may send an in-band flow control Xoff signal to the PDSN to stop data transmission from the PDSN if the flow control feature is activated. e. Upon receiving the A9-AL Disconnected message, the source PCF responds with an A9-AL Disconnected Ack message to the source AN. The source AN stops timer Tald9. f. The source AN sends an A16-Session Transfer Request message to the target AN to request session transfer for the AT. The A16-Session Transfer Request message shall include the Session State Information Records of the current HRPD session and all supported personalities. The latest traffic channel report message is also encapsulated in the A16-Session Transfer Request message indicating that this is a hard handoff request. The source AN starts timer Tstreq-16.
The following steps assume that the target AN accepts the hard handoff request, i.e., it can support a session with all the requested Session State Information Records. Otherwise, refer to section 3.12.2 for call flow that describes how the target AN rejects the session transfer request. g. The target AN determines from the latest traffic channel report message the list of new sectors that the AT should switch to in order to connect to the target AN and then allocates resources required for these sectors. The target AN accepts the hard handoff request by sending an A16-Session Transfer Response message to the source AN. The message also includes Proposed Session State Information Records containing necessary traffic channel parameters of the new sectors. The target AN starts timer Tstcomp-16. Upon receipt of the A16-Session Transfer Response message, the source AN stops timer Tstreq-16. Step h k can occur any time after step f and before step w. h. The target AN sends an A9-Setup-A8 message to the target PCF with Data Ready Indicator (DRI) set to 1 to establish the A8-Connection. The A9-Setup-A8 includes Handoff type field indicating whether the PDSN should wait to start accounting until the handoff is successfully completed. The target AN starts timer TA8-setup. i. The target PCF recognizes that no A10 connection associated with the AT is available. It then establishes A10 connection(s) with the source PDSN. The target PCF sends an A11-Registration Request message to the PDSN with the S bit set to 0 indicating that simultaneous binding is not needed. The source PDSN shall be able to receive data simultaneously from both the source PCF and the target PCF while both A10 connections are still alive. The target PCF starts timer Tregreq. The A11-Registration Request message includes A10 Connection Setup airlink record and may include Active Start airlink record. 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. The A10 connection binding information at the PDSN is updated to point to the target PCF. The target PCF stops timer Tregreq.
j.
k. The target PCF sends the A9-Connect-A8 message to the target AN. When the AN receives the A9Connect-A8 message it stops timer TA8-setup. l. If the source AN cannot transfer SLP states to the target AN or the source AN needs to instruct the AT to switch to a new personality before the target AN can acquire the AT, then the source AN shall also close the connection, e.g., by sending a ConnectionClose message [10], and at the same time 3-44
3GPP2 A.S0008-C v2.0

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 48
assign a new connection between the AT and the target AN e.g., by sending a TrafficChannelAssignment message [10] (refer to sections 3.13.1 and 3.13.2). If the source AN can transfer SLP states to the target AN and does not need to switch to a new personality, then the source AN shall also send an application-layer route reset command, e.g., RLP Reset for Default Packet Application or ResetTxIndication and ResetRxIndication for Multi-flow Packet Application [10], at the same time. This step can occur anytime after step g. The source AN may repeat this step to enhance reliability. m. The source AN sends an A16-Session Transfer Complete message to the target AN. Since some Session State Information records (e.g., state information) may be changed after A16-Session Transfer Request has been sent, this message shall include Session State Information Records that have been changed from the values indicated by the A16-Session Transfer Request message as modified by the session changes in the A16-Session Transfer Response message. The source AN also starts timer Tstack-16. Upon receipt of the A16-Session Transfer Complete message, the target AN stops timer Tstcomp-16. n. After the target AN has acquired the AT, if the target AN has received SLP states in the A16-Session Transfer Complete message and does not receive an application-layer route reset acknowledgement, e.g., RLP ResetAck for Default Packet Application or RLP ResetTxIndicationAck and ResetRxComplete for Multi-flow Packet Application [10], then the target AN instructs the AT to reset the application-layer route. If the target AN receives an application-layer route reset acknowledgement, then the target AN completes the application-layer route reset procedure. If SLP states are not included in the A16-Session Transfer Complete message, then the target should not instruct the AT to reset the application-layer route. The target AN may begin transmitting data to the AT upon completion of this step. o. After the target AN has acquired the AT and if the Handoff Type field is set to 1 in step h, then the target AN sends an A9-AL Connected message to the target PCF and starts timer Talc9. p. Upon receipt of the A9-AL Connected message, the target PCF sends an A11-Registration Request message including Active Start airlink record(s) to the PDSN and starts timer Tregreq. q. Upon receipt of the A11-Registration Request message, the PDSN sends an A11-Registration Reply message to the target PCF. The target PCF stops timer Tregreq. r. s. t. Upon receipt of the A11-Registration Reply message, the target PCF sends the A9-AL Connected Ack message in response to the A9-AL Connected message and stops timer Talc9. If the source AN and the target AN are in different subnets, then the target AN assigns a new UATI to the AT and receives confirmation from the AT that the new UATI is now in use. After the target AN has acquired the AT and is assured that access to the system by the AT would be directed to the target AN, it sends an A16-Session Release Indication message to the source AN. This message indicates that the session is now under control of the target AN hence the source AN/PCF can terminate its connection with the PDSN and can purge the session associated with the AT. The target AN starts timer Tstrel-16. Upon receipt of the A16-Session Release Indication message, the source AN stops timer Tstack-16.
u. The source AN sends an A16-Session Release Indication Ack message to the target AN. Upon receipt of the A16-Session Release Indication Ack message, the target AN stops timer Tstrel-16. If the source AN is the AN that assigned LCM_UATI, it starts timer TSClose-13. v. If the connection was not closed in step l, then the target AN unlocks the AT session, e.g., by sending a UnlockConfiguration message as specified in [10]. New session configuration and attribute update can now be initiated. Step w can occur any time after step j. w. The PDSN initiates closure of the A10 connection with the source PCF by sending an A11-Registration Update message. The PDSN starts timer Tregupd. 3-45
3GPP2 A.S0008-C v2.0

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
x. The source PCF responds with an A11-Registration Acknowledge message. The PDSN stops timer Tregupd. y. The source PCF sends an A9-Disconnect-A8 message to the source AN and starts timer Tdiscon9. z. Upon receipt of A16-Session Release Indication message and A9-Disconnect-A8 message, the source AN sends an A9-Release-A8 message to the source PCF and starts timer Trel9. Upon receipt of the A9-Release-A8 message, the source PCF stops timer Tdiscon9. aa. The source PCF sends an A11-Registration Request message to the PDSN with a Lifetime timer value of zero to close the A10 connection and starts timer Tregreq. bb. The PDSN responds with an A11-Registration Reply message to complete the release of the A10 connection. The source PCF stops timer Tregreq. cc. The source PCF responds to the source AN with an A9-Release-A8 Complete message. The source AN stops timer Trel9. dd. The target AN may send an A13-Keep Alive Request message to the source AN (assuming that the source AN is the AN that assigned LCM_UATI) before TSClose-13 running at the source AN expires (refer to steps e, f and h) and starts timer TKeepAlive-13. ee. Upon receipt of the A13-Keep Alive Request message, the source AN restarts timer TSClose-13 and sends an A13-Keep Alive Response message to the target AN. The target AN stops timer TKeepAlive13. ff. The connection between the AT and the target AN closes. Refer to section 3.4. gg. After the connection between the AT and the target AN closes , the target AN sends an A13-Resource Release Request message to the AN identified by LCM_UATI in the A16-Session Transfer Complete message. In this call flow, this AN is assumed to be the source AN. The target AN starts timer TA13rel. The source PCF stops the timer TSClose-13 upon receipt of this message. hh. Upon receipt of the A13-Resource Release Request message, the source AN sends an A13-Resource Release Response message back to the target AN. The source AN may now re-assign the UATI to another AT. Upon receipt of the A13-Resource Release Response message, the target AN stops timer TA13rel. 3.12.2 Connected State HRPD Hard Handoff - Failure Scenario (Refusal by Target AN) This scenario describes the call flow associated with an HRPD hard handoff between ANs when the HRPD session is in Connected State and the hard handoff request is rejected by the target AN.
28 29 30 31
3-46
3GPP2 A.S0008-C v2.0
1 2 3
Figure 3.12.2-1 Connected State HRPD Session Hard Handoff Failure Scenario (Refusal by Target AN) a. The source AN decides that the HRPD session should be transferred via hard handoff to the target AN. This is triggered according to a session transfer trigger algorithm which can be based on several criteria such as receipt of a RouteUpdate message [10] which indicates that the AT location is too far from the source AN according to a metric defined by the operator and at least one of the reported sectors is supported by the target AN. This call flow assumes that the source AN cannot include sectors that belong to the target AN in the Active Set and so the source AN initiates a hard handoff to the target AN. b. The source AN locks the AT session, e.g., by sending a LockConfiguration message to the AT as specified in [10]. New session configuration or attribute update cannot take place while the session is locked. If the AT cannot support locking the session, then the source AN begins to ignore all session reconfiguration requests from the AT. The source AN will only resume processing session reconfiguration requests from the AT if the session transfer is aborted. c. The source AN may send an A9-AL Disconnected message to the source PCF to stop data transmission from the source PCF. The A9-AL Disconnected message may indicate the SR_IDs for which the PCF does not stop transmission. The source AN starts timer Tald9. d. The source PCF may send an in-band flow control Xoff signal to the PDSN to stop data transmission from the PDSN if the flow control feature is activated. e. Upon receiving the A9-AL Disconnected message, the source PCF responds with an A9-AL Disconnected Ack message to the source AN. The source AN stops timer Tald9. f. The source AN sends an A16-Session Transfer Request message to the target AN to request session transfer for the AT. The A16-Session Transfer Request message shall include the Session State Information Records of the current HRPD session and all supported personalities. The latest traffic channel report message is also encapsulated in the A16-Session Transfer Request message indicating that this is a hard handoff request. The source AN starts timer Tstreq-16.
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
The following steps assume that the target AN rejects the session transfer request either because it cannot support a session with all of the requested Session State Information Records. g. The target AN rejects the session transfer request by sending an A16-Session Transfer Reject message to the source AN with the appropriate cause value. Upon receipt of the A16-Session Transfer Reject message, the source AN stops timer Tstreq-16. h. The source AN may send an A9-AL Connected message to the source PCF to start data transmission from the source PCF. The source AN starts timer Talc9. i. The source PCF may send an in-band flow control Xon signal to the PDSN to resume data transmission from the PDSN if the flow control feature is activated. 3-47
3GPP2 A.S0008-C v2.0

1 2 3
j.
Upon receiving the A9-AL Connected message, the source PCF responds with an A9-AL Connected Ack message to the source AN. The source AN stops timer Talc9.
4 5 6
3.12.3 Connected State HRPD Hard Handoff - Traffic Channel Assignment (TCA) Retry Scenario This scenario describes the call flow associated with an HRPD hard handoff between ANs when the HRPD session is in Connected State and the AT does not receive the traffic channel assignment.
3-48
3GPP2 A.S0008-C v2.0

time a
b c Optional
Tald9
A10 : XOFF
Optional e Conditional d f
Tstreq-16
g h i
TA8- setup T stcomp-16
Tregreq
j k l
T stack-16 T stcomp-16
q r s Conditional Conditional
T stack-16
Talc9
Tregreq
t Conditional
u Conditional v Conditional w
Tstrel-16
x y Conditional
T regupd z T discon9 Trel9 Tregreq
aa bb cc dd ee ff
TSClose-13
T KeepAlive-13
gg hh
ii
TA13rel
1 2
jj kk
Figure 3.12.3-1 Connected State HRPD Hard Handoff TCA Retry Scenario Step a k are identical to step a k in section 3.12.1.
3 4
3-49
3GPP2 A.S0008-C v2.0

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22
l.
If the source AN cannot transfer SLP states to the target AN or the source AN needs to instruct the AT to switch to a new personality before the target AN can acquire the AT, then the source AN shall also close the connection, e.g., by sending a ConnectionClose message [10], and at the same time assign a new connection between the AT and the target AN e.g., by sending a TrafficChannelAssignment message [10] (refer to sections 3.13.1 and 3.13.2). If the source AN can transfer SLP states to the target AN and does not need to switch to a new personality, then the source AN shall also sends an application-layer route reset command, e.g., RLP Reset for Default Packet Application or ResetTxIndication and ResetRxIndication for Multi-flow Packet Application [10], at the same time. However, the AT does not receive these messages. This step can occur anytime after step g.
m. The source AN sends an A16-Session Transfer Complete message to the target AN. This message shall include Session State Information Records that have been changed from the A16-Session Transfer Request message. The source AN also starts timer Tstack-16. Upon receipt of the A16Session Transfer Complete message, the target AN stops timer Tstcomp-16. n. Since the target AN cannot acquire the AT, the target AN resends the A16-Session Transfer Response message to trigger the source AN to re-instruct the AT to switch to the new Active Set. The target AN starts timer Tstcomp-16. Upon receipt of the A16-Session Transfer Response message, the source AN stops timer Tstack-16. o. The source AN resends the messages in step l. Step p kk are identical to step m hh in section 3.12.1.
23 24 25
3.12.4 Connected State HRPD Hard Handoff - Failure Scenario (AT Lost) This scenario describes the call flow associated with an HRPD hard handoff between ANs when the HRPD session is in Connected State and the target AN cannot acquire the AT.
3-50
3GPP2 A.S0008-C v2.0
time a
Tald9
A10: XOFF
c Optional d Optional e Conditional f g h i
Tstreq-16
TA8-setup Tstcomp-16
Tregreq
j k l m n
Tstack-16
Tstcomp-16
o
Tstack-16
Tstabrt-16
r
Tregupd s
t
Tdiscon9 Trel9 Tregreq
u v w x y
1 2
Figure 3.12.4-1 Connected State HRPD Hard Handoff Failure Scenario (AT Lost) Step a k are identical to step a k in section 3.12.1. l. If the source AN cannot transfer SLP states to the target AN or the source AN needs to instruct the AT to switch to a new personality before the target AN can acquire the AT, then the source AN shall also close the connection, e.g., by sending a ConnectionClose message [10], and at the same time assign a new connection between the AT and the target AN e.g., by sending a TrafficChannelAssignment message [10] (refer to sections 3.13.1 and 3.13.2). If the source AN can transfer SLP states to the target AN and does not need to switch to a new personality, then the source AN shall also sends an application-layer route reset command, e.g., RLP Reset for Default Packet Application or ResetTxIndication and ResetRxIndication for Multi-flow Packet Application [10], at
3 4 5 6 7 8 9 10 11 12
3-51
3GPP2 A.S0008-C v2.0

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
the same time. However, the AT does not receive these messages. This step can occur anytime after step g. m. The source AN sends an A16-Session Transfer Complete message to the target AN. This message shall include Session State Information Records that have been changed from the A16-Session Transfer Request message. The source AN also starts timer Tstack-16. Upon receipt of the A16Session Transfer Complete message, the target AN stops timer Tstcomp-16. n. Since the target AN cannot acquire the AT, the target AN resends the A16-Session Transfer Response message to trigger the source AN to re-instruct the AT to switch to the new Active Set. The target AN starts timer Tstcomp-16. Upon receipt of the A16-Session Transfer Response message, the source AN stops timer Tstack-16. o. The source AN resends the messages in step l, The target AN still cannot acquire the AT. p. The source AN sends an A16-Session Transfer Complete message to the target AN. This message shall include Session State Information Records that have been changed from the A16-Session Transfer Request message. The source AN also starts timer Tstack-16. Upon receipt of the A16Session Transfer Complete message, the target AN stops timer Tstcomp-16. q. The target AN decides to abort the session transfer after it has retransmitted the A16-Session Transfer Response message for a configurable number of times. The target AN sends an A16-Session Transfer Abort message with the abort cause value set to AT lost to the source AN. The target AN also starts timer Tstabrt-16. Upon receipt of the A16-Session Transfer Abort message, the source AN stops timer Tstack-16. r. Upon receipt of the A16-Session Transfer Abort message, the source AN sends an A16-Session Transfer Abort Ack message back to the target AN. Upon receipt of the A16-Session Transfer Abort Ack message, the target AN stops timer Tstabrt-16. The target AN can now purge the resource associated with the AT. The source PDSN initiates closure of the A10 connection with the source PCF by sending an A11Registration Update message. The source PDSN starts timer Tregupd. The source PCF responds with an A11-Registration Acknowledge message. The PDSN stops timer Tregupd.
Step s can occur any time after step j. s. t.
u. The source PCF sends an A9-Disconnect-A8 message to the source AN and starts timer Tdiscon9. v. The source AN sends an A9-Release-A8 message to the source PCF and starts timer Trel9. Upon receipt of the A9-Release-A8 message, the source PCF stops timer Tdiscon9. w. The source PCF sends an A11-Registration Request message to the PDSN with a Lifetime timer value of zero to close the A10 connection. x. The PDSN responds with an A11-Registration Reply message to complete the release of the A10 connection. The source PCF stops timer Tregreq. y. The source PCF responds to the source AN with an A9-Release-A8 Complete message. The source AN stops timer Trel9. z. If the connection between the source AN and the AT still exists, the source AN re-establishes A8 connections to the source PCF and the source PCF re-establishes A10 connections to the PDSN. 3.12.5 Intra-PDSN Connected State HRPD Session Transfer with Cross-Connectivity Support Successful Operation This scenario describes the call flow associated with an HRPD session transfer between ANs when the HRPD session is in Connected State and both ANs support cross-connectivity (refer to section 3.13). This 3-52
41 42 43 44
3GPP2 A.S0008-C v2.0

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
call flow assumes that the target AN can reach the source PDSN which is assumed to be the same as the anchor PDSN. If AT supports multiple application-layer route (such as Enhanced Multi-flow Packet Application [20]) and the target AN can also support it, then the ANs perform make-before-break session transfer procedure to reduce disruption in the data flow with the AT. Make-before-break session transfer procedure allows data to flow throughout the session transfer process by adding a separate application-layer data (such as RLP) route through the target AN before tearing down the original route in the source AN. At any given time, only a single AN may control the session of the AT. We define a master AN and a slave AN as follows. The master AN is the AN that controls the session and state associated with signaling protocols (such as SLP [10]). The slave AN is the other AN involved in the session transfer with the master AN. The duties of a master AN during a HRPD Session Transfer with cross-connectivity support are: (i) (ii) Updating necessary state information and attributes in the slave AN such that the slave AN can perform its duties (section 3.12.5.5). During make-before break session transfer, processing received reverse-link signaling protocol headers and forwarding necessary reverse-link signaling messages to the slave AN (section 3.12.5.7). During make-before-break session transfer, adding signaling protocol headers to forward-link signaling messages received from the slave AN and sending them to the AT. Updating state information and attributes of its HRPD session as indicated by the master AN. This also includes managing the current serving sector and adding sectors (section 3.12.5.1 and section 3.12.5.3) or removing sectors (section 3.12.5.2 and section 3.12.5.4) such that the slave AN always communicates with only sectors in the Active Set [10]. During make-before-break session transfer, receiving and selecting reverse-link physical-layer packets received from all sectors in the Active Set. During make-before-break session transfer, processing application-layer packets associated with the application-layer route that runs at the slave AN. During make-before-break session transfer, sending non-signaling forward-link packets associated with the application-layer route that runs at the slave AN to the serving sector. During make-before-break session transfer, sending the signaling forward-link packets associated with the application-layer route that runs at the slave AN to the master AN (section 3.12.5.6). All forward-link signaling messages that it sends to the master AN are also buffered. During make-before-break session transfer, forwarding received application-layer packets on the route supported by the slave AN to the PDSN.
(iii)
The duties of a slave AN during a HRPD make-before-break session transfer are: (i)
(ii) (iii) (iv) (v)
(vi)
3-53
3GPP2 A.S0008-C v2.0

AT Source AN Source AN decides to transfer the session to target AN Source AN locks session configuration in the AT Source PCF Target AN Target PCF PDSN time
Source AN activates new route in the AT A9-AL Disconnected
c d e
Target AN becomes slave AN
conditional
Tald9
A9-AL Disconnected Ack A16-Session Transfer Request
Source AN becomes master AN
f g
Target AN establishes connections to all sectors in the Active Set
State-synchronization messages exchange A9-Setup-A8 A11Registration Request A11Registration Reply
h i j k l m conditional
Target AN becomes master AN
Tstreq-16
TA8-setup
Tregreq
A9-Connect-A8
Tunneling signaling messages to/from slave AN

Source AN becomes slave AN
A16-Session Transfer Response
n o p q r s t
Tstcomp-16
A16-Session Transfer Complete
Talc9
Target AN selects new route in the AT or resets the route
A9-AL Connected A9-AL Connected Ack
Target AN may assign new UATI to the AT and receive confirmation A16-Session Release Indication
Tstack-16
A16-Session Release Indication Ack Target AN unlocks session configuration in the AT
Tstrel-16
u v A11-Registration Update A11-Registration Acknowledge A9-Disconnect-A8
Tregupd
w x y
Source AN detaches from all sectors in the Active Set
A9-Release-A8
Tdiscon9 Tregreq
aa A11-Registration Request (Lifetime=0) bb cc dd
Trel9
A11-Registration Reply (Lifetime=0, accept)
AT closes connection with target AN A13-Resource Release Request A13-Resource Release Response
ee ff gg
TA13rel
1 2 3
Figure 3.12.5-1 Intra-PDSN Connected State HRPD Session Transfer with Cross-Connectivity Support -- Successful Operation a. The source AN decides that the HRPD session should be transferred to the target AN. This is triggered according to a session transfer trigger algorithm which can be based on several criteria such as when the AT reports its location that is too far from the source AN according a metric defined by the operator and at least one of the reported sectors is supported by the target AN. This call flow assumes that, if needed, the source AN has included sectors that belong to the target AN in the Active Set before step a using cross-connectivity (refer to section 3.13). b. The source AN locks the AT session, e.g., by sending a LockConfiguration message to the AT as specified in [10]. New session configuration or attribute update cannot take place while the session is locked. If the AT cannot support locking the session, then the source AN begins to ignore all session 3-54
4 5 6 7 8 9 10 11 12
3GPP2 A.S0008-C v2.0

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 48
reconfiguration requests from the AT. The source AN will only resume processing session reconfiguration requests from the AT if the session transfer is aborted. c. If the source AN decides to perform make-before-break session transfer, the source AN activates a new application-layer route, e.g., the source AN instructs the AT to be ready to receive data on the new RLP route as specified in [20] on all flows. d. The source AN sends an A9-AL Disconnected message to the source PCF so that the source PCF knows that a handoff is in progress. The source AN starts timer Tald9. e. The source PCF responds with an A9-AL Disconnected Ack message and the source AN stops timer Tald9. f. The source AN sends an A16-Session Transfer Request message to the target AN to request session transfer for the AT. The A16-Session Transfer Request message shall include the Session State Information Records of the current HRPD session and all supported personalities. This message also contains the source PDSN address. The source AN starts timer Tstreq-16 and becomes the master AN. Upon receipt of the A16-Session Transfer Request message, the target AN becomes the slave AN.
The following steps assume that the target AN accepts the session transfer request, i.e., it can support a session with all the requested Session State Information Records. g. The target AN connects to all sectors in the Active Set as indicated in the current Session State Information Records. The target AN may need to cross-connect with the source AN or other ANs using the cross-connectivity procedure in section 3.12.5.1. h. The master AN updates the slave AN whenever there is a change in the Session State Information Records of the current session (due to the changes in state information). This step depends on the event that triggers the change in the current session and may trigger cross-connectivity procedure. If the master AN adds new sectors into the Active Set, refer to section 3.12.5.3. If the master AN removes some sectors from the Active Set, refer to section 3.12.5.4. Otherwise, if the master AN only needs to update the Session State Information Records of the current session in the slave AN, or when the serving sector has changed, refer to section 3.12.5.5. This step can occur whenever necessary up until step u. Step i l can occur any time after step f. i. j. The target AN sends an A9-Setup-A8 message to the target PCF with Data Ready Indicator (DRI) set to 1 to establish the A8 connection. The target AN starts timer TA8-setup. The target PCF recognizes that no A10 connection associated with the AT is available. It then establishes A10 connection(s) with the PDSN. The target PCF sends an A11-Registration Request message to the PDSN with the IMSI of the AT and the S bit set to 0 indicating that simultaneous binding is not needed. The PDSN shall be able to receive data simultaneously from both the source PCF and the target PCF while both A10 connections are still alive. The target PCF starts timer Tregreq.
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. The A10 connection binding information at the PDSN is updated to point to the target PCF. The target PCF stops timer Tregreq. l. The target PCF sends the A9-Connect-A8 message to the target AN. When the target AN receives the A9-Connect-A8 message it stops timer TA8-setup.
m. For make-before-break session transfer, the slave AN tunnels signaling messages to the AT through the master AN (refer to section 3.12.5.6). Signaling messages from the AT to the slave AN are also tunneled through the master AN (refer to section 3.12.5.7). This step can occur whenever necessary until step u. n. The target AN accepts the session transfer request by sending an A16-Session Transfer Response message to the source AN with the Session Transfer Accept Indicator set to 1. The target AN starts 3-55
3GPP2 A.S0008-C v2.0

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
timer Tstcomp-16. Upon receipt of the A16-Session Transfer Response message, the source AN stops timer Tstreq-16. o. The source AN sends an A16-Session Transfer Complete message to the target AN. This message shall include the residual state information, the timestamp which the source AN has last processed a signaling message and the last sequence number of the A16-FL Signal Tunnel message processed by the source AN. Upon transmitting the A16-Session Transfer Complete message, the source AN becomes the slave AN. The source AN also starts timer Tstack-16. Upon receipt of the A16-Session Transfer Complete, the target AN becomes the master AN and stops timer Tstcomp-16. The target AN starts processing any buffered signaling messages and A16-FL Signal Tunnel messages starting after the timestamp and sequence number, respectively, as indicated in the A16-Session Transfer Complete message. p. The target AN sends an A9-AL Connected message to the target PCF and starts timer Talc9. q. The target PCF sends an A9-AL Connected Ack message to the target AN. The target AN stops timer Talc9 upon receipt of the message Step r and s can occur in parallel. r. For make-before-break session transfer, the target AN selects the new application-layer route on all flows. The AT then sends its reverse-link data through the new application-layer route as specified in [20]. This step can be omitted if the target AN has already received reverse-link data traffic through the new application-layer route. If the AT only supports one application-layer route, the target AN instructs the AT to reset the route. If the source AN and the target AN are in different subnet, then the target AN assigns a new UATI to the AT and receives confirmation from the AT that the new UATI is now in use. After the target AN is assured that a new application-layer route is selected and that access to the system by the AT would be directed to the target AN, it sends an A16-Session Release Indication message to the source AN. This message indicates that the session is now under control of the target AN hence the source AN/PCF can terminate its connection with the PDSN and that the source AN can purge the session associated with the AT. The target AN starts timer Tstrel-16. Upon receipt of the A16-Session Release Indication message, the source AN stops timer Tstack-16.
s. t.
u. The source AN sends an A16-Session Release Indication Ack message to the target AN. Upon receipt of the A16-Session Release Indication Ack message, the target AN stops timer Tstrel-16. v. The target AN unlocks the AT session, e.g., by sending a UnlockConfiguration message as specified in [10]. New session configuration and attribute update can now be initiated. Step w can occur anytime after step k. w. The source PDSN initiates closure of the A10 connection with the source PCF by sending an A11Registration Update message. The source PDSN starts timer Tregupd. x. The source PCF responds with an A11-Registration Acknowledge message. The PDSN stops timer Tregupd. y. The source PCF sends an A9-Disconnect-A8 message to the source AN and starts timer Tdiscon9 28. This step can happen as soon as the source PCF has depleted all of its FL data. z. After the source AN has depleted all of its data, the source AN detaches from all sectors in the Active Set using cross-connectivity procedure in section 3.12.5.2. This step may occur in parallel with step y.
28 In systems with cross-connectivity, the value of Tdiscon9 needs to take into account the time it takes to deplete the PCF's FL buffer.
3-56
3GPP2 A.S0008-C v2.0

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
aa. After the source AN has depleted all data on its application-layer route, it sends an A9-Release-A8 message to the source PCF and starts timer Trel9. Upon receipt of the A9-Release-A8 message, the source PCF stops timer Tdiscon9. bb. The source PCF sends an A11-Registration Request message to the PDSN with a Lifetime timer value of zero to close the A10 connection. cc. The PDSN responds with an A11-Registration Reply message to complete the release of the A10 connection. The source PCF stops timer Tregreq. dd. The source PCF responds to the source AN with an A9-Release-A8 Complete message. The source AN stops timer Trel9. ee. The connection between the AT and the target AN closes. ff. After the connection between the AT and the target AN closes, the target AN sends an A13-Resource Release Request message to the AN identified by LCM_UATI in the A16-Session Transfer Complete message. In this call flow, this AN is assumed to be the source AN. The target AN starts timer TA13rel. gg. Upon receipt of the A13-Resource Release Request message, the source AN sends an A13-Resource Release Response message back to the target AN. The source AN may now re-assign the UATI to another AT. Upon receipt of the A13-Resource Release Response message, the target AN stops timer TA13rel.
20 21 22 23 24 25 26 27
3.12.5.1
Slave AN attaches to sectors in another AN during Connected State HRPD Session Transfer with Cross-Connectivity Support
This scenario describes the call flow during Connected State HRPD Session Transfer with CrossConnectivity Support where the slave AN attaches to the sector that either belongs to the master AN or the other AN in the ATs Active Set, i.e., to request connection to sectors in the current active set of the AT belonging to the master AN or another AN that have already been allocated for a specific AT. These connections will be used for cross-connectivity during session transfer and after the session transfer has finished.
28 29 30
Figure 3.12.5.1-1 Slave AN attaches to sectors in another AN during Connected State HRPD Session Transfer with Cross-Connectivity Support -- Successful Operation a. The slave AN sends an A17-Slave Attach Request message to another AN to attach to sectors in the Active Set of the AT. Another AN may be the master AN or an AN not involved in the session transfer. The A17-Slave Attach Request message contains the Session State Information Records of the session and also contains the AN Control Endpoint ID and AN Data Endpoint ID of the slave AN. Upon sending the A17-Slave Attach Request message, the slave AN starts timer Tallocreq-17. b. Upon receiving the A17-Slave Attach Request message from the slave AN, the other AN attaches the slave AN to the sectors requested. Subsequently, the other AN sends an A17-Slave Attach Response message to the slave AN. The A17-Slave Attach Response message contains the RT Control and Data Endpoint ID for each requested sector. Note that if the other AN cannot attach the slave AN to a sector, no Control and Data Endpoint ID for the sector would be included in the A17-Slave Allocate 3-57
31 32 33 34 35 36 37 38 39 40
3GPP2 A.S0008-C v2.0

1 2 3
Response message. Upon receiving the A17-Slave Attach Response message, the slave AN stops timer Tallocreq-17.
4 5 6 7 8
3.12.5.2
Slave AN detaches from sectors in another AN during Connected State HRPD Session Transfer with Cross-Connectivity Support
This scenario describes the call flow for the slave AN to detach from the sector that belongs either to the master AN or the other AN in the ATs Active Set during Connected State HRPD Session Transfer with Cross-Connectivity Support.
9 10 11
Figure 3.12.5.2-1 Slave AN detaches from a sector in another AN during Connected State HRPD Session Transfer with Cross-Connectivity Support -- Successful Operation a. The slave AN sends an A17-Slave Detach Request message to the other AN to disconnect from a sector in the Active Set. The other AN may be the master AN or another AN not involved in the session transfer. The A17-Slave Detach Request message contains the AN Control Endpoint ID and AN Data Endpoint ID of the slave AN that the other AN is assigned. Upon sending the A17-Slave Detach Request message, the slave AN starts timer Tdeallocreq-17. b. Upon receiving the A17-Slave Detach Request message from the slave AN, the other AN releases cross-connectivity connection between the slave AN and the sectors requested. Subsequently, the other AN sends an A17-Slave Detach Ack message to the slave AN. Upon receiving the A17-Slave Detach Ack message, the slave AN stops timer Tdeallocreq-17.
12 13 14 15 16 17 18 19 20 21
22 23 24 25
3.12.5.3
Master AN adds new sectors to Active Set during Session Transfer with CrossConnectivity Support
This scenario describes the call flow for adding pilot(s) into the ATs Active Set during Connected State HRPD Session Transfer with Cross-Connectivity Support.
3-58
3GPP2 A.S0008-C v2.0
1 2 3
Figure 3.12.5.3-1 Master AN adds new sectors to Active Set during Connected State HRPD Session Transfer with Cross-Connectivity Support -- Successful Operation a. During Session Transfer with cross-connectivity support, the AT reports new pilots. The new pilots may belong to the master AN, slave AN or the other AN. The master AN decides to add the new pilots to the Active Set. b. If the new pilots belong to the slave AN, the master AN sends the A17-Allocate Request message to the slave AN to request it to allocate resources at these sectors as specified in section 3.13.2. The master AN starts timer Tallocreq-17. The A17-Allocate Request message contains the Session State Information Records and the Proposed Session State Information Record and also contains the AN Control Endpoint ID and AN Data Endpoint ID of the master AN that the slave AN is to use to send A19 control and A18 data information to, respectively. c. Upon receiving the A17-Allocate Request message from the master AN, the slave AN allocates resources for those pilots belonging to the slave AN. Subsequently, the slave AN sends an A17Allocate Response message to the master AN in response to the request from the master AN. The A17-Allocate Response message contains the Proposed Session State Information Records. It also contains the RT Control Endpoint ID and RT Data Endpoint IDs of the slave AN that the master AN is to use to send A17 control and data information to for these pilots. Upon receiving the A17Allocate Response message, the master AN stops timer Tallocreq-17. d. If the new pilots belong to the other AN, the master AN sends the A17-Allocate Request message to the other AN to request it to allocate resources at these sectors as specified in section 3.13.2. The master AN starts timer Tallocreq-17. The A17-Allocate Request message contains the Session State Information Records and the Proposed Session State Information Record and also contains the AN 3-59
4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
3GPP2 A.S0008-C v2.0

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
Control Endpoint ID and AN Data Endpoint ID of the master AN that the other AN is to use to send A19 control and A18 data information to, respectively. e. Upon receiving the A17-Allocate Request message from the master AN, the other AN allocates resources for those pilots belonging to the other AN. Subsequently, the other AN sends an A17Allocate Response message to the master AN in response to the request from the master AN. The A17-Allocate Response message contains the Proposed Session State Information Records. It also contains the RT Control Endpoint ID and RT Data Endpoint IDs of the other AN that the master AN is to use to send A17 control and data information to for these pilots. Upon receiving the A17Allocate Response message, the master AN stops timer Tallocreq-17. f. The master AN sends an A16-Attributes Update message to the slave AN with the Proposed Session State Information Record reflecting the new Active Set. The master AN may also includes Sector Endpoint Information of the new sectors in the message. The master AN starts timer Tattribupd-16.
g. Upon receiving the A16-Attributes Update message from the master AN, the slave AN connects to its own sectors in the new Active Set. It also cross-connects to all new sectors in the Active Set in the master AN and the other AN using the procedure specified in section 3.12.5.1. h. After the slave AN has connected to all new sectors in the Active Set, it sends an A16-Attributes Update Ack message back to the master AN. The message contains the Proposed Session State Information Record reflecting the new Active Set. Upon receiving the A16-Attributes Update Ack message, the master AN stops timer Tattribupd-16. i. The master AN sends an A17-Set Attributes message to the slave AN containing the Alternate Session State Information Records to be used for the connection. The master AN starts timer Tsetattrib17. The Alternate Session State Information Records are included because the access network does not know the exact value of some parameters until the traffic channels are updated. The slave AN acknowledges the A17-Set Attributes message from the master AN by sending an A17Set Attributes Ack message to the master AN. Upon receiving the A17-Set Attributes Ack message, the master AN stops timer Tsetattrib-17.
j.
k. The master AN sends an A17-Set Attributes message to the other AN containing the Alternate Session State Information Records to be used for the connection. The master AN starts timer Tsetattrib17. The Alternate Session State Information Records are included because the access network does not know the exact value of some parameters until the traffic channels are updated. l. The other AN acknowledges the A17-Set Attributes message from the master AN by sending an A17Set Attributes Ack message to the master AN. Upon receiving the A17-Set Attributes Ack message, the master AN stops timer Tsetattrib-17.
m. The master AN instructs the AT to update the traffic channels according to the new Active Set. n. The master AN sends an A17-Set Attributes message to the RT Resource Control Endpoint ID of the slave AN containing the new Session State Information Record to be used for the connection. The master AN starts timer Tsetattrib-17. o. The slave AN acknowledges the A17-Set Attributes message from the master AN by sending an A17Set Attributes Ack message to the master AN. Upon receiving the A17-Set Attributes Ack message, the master AN stops timer Tsetattrib-17. p. The master AN sends an A17-Set Attributes message to the RT Resource Control Endpoint ID of the other AN containing the new Session State Information Record to be used for the connection. The master AN starts timer Tsetattrib-17. q. The other AN acknowledges the A17-Set Attributes message from the master AN by sending an A17Set Attributes Ack message to the master AN. Upon receiving the A17-Set Attributes Ack message, the master AN stops timer Tsetattrib-17.
3-60
3GPP2 A.S0008-C v2.0

1 2 3 4 5 6
r. s.
The master AN sends an A16-Attributes Update message to the slave AN containing the new Session State Information Record to be used for the connection. The master AN starts timer Tattribupd-16. The slave AN acknowledges the A16-Attributes Update message from the master AN by sending an A16-Attributes Update Ack message to the master AN. Upon receiving the A16-Attributes Update Ack message, the master AN stops timer Tattribupd-16.
7 8 9 10
3.12.5.4
Master AN removes sectors from the Active Set during Connected State HRPD Session Transfer with Cross-Connectivity Support
This scenario describes the call flow for removing pilot(s) from the ATs Active Set during Connected State HRPD Session Transfer with Cross-Connectivity Support.
11 12 13
Figure 3.12.5.4-1 Master AN removes sectors from the Active Set during Connected State HRPD Session Transfer with Cross-Connectivity Support -- Successful Operation a. The AT reports its measured pilots strength and the master AN determines that it would like to drop some pilots from its Active Set. Some of the pilots may belong to the slave AN or the other AN. b. The master AN sends an A17-Deallocate Request message to the slave AN to inform the slave AN to deallocate pilots belonging to the slave AN. The master AN starts timer Tallocreq-17. This message is sent only if the pilots to be removed belong to the slave AN. c. Upon receipt of the A17-Deallocate Request message, the slave AN sends an A17-Deallocate Ack message back to the master AN. The slave AN deallocates resources related to the dropped pilots. The master AN stops timer Tallocreq-17. d. The master AN sends an A17-Deallocate Request message to the other AN to inform the other AN to deallocate pilots belonging to the other AN. The master AN starts timer Tallocreq-17. This message is sent only if the pilots to be removed belong to the other AN. 3-61
14 15 16 17 18 19 20 21 22 23 24
3GPP2 A.S0008-C v2.0

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
e. Upon receipt of the A17-Deallocate Request message, the other AN sends an A17-Deallocate Ack message back to the master AN. The other AN deallocates resources related to the dropped pilots. The master AN stops timer Tallocreq-17. Step f g and h i can occur in parallel. f. The master AN sends an A17-Set Attributes message to the slave AN containing the Alternate Session State Information Records to be used for the connection. The master AN starts timer Tsetattrib17. The Alternate Session State Information Records are included because the access network does not know the exact instance that the values of some parameters are effective at the AT 29 This message is sent only if there are sectors belonging to the slave AN in the ATs Active Set.
g. The slave AN acknowledges the A17-Set Attributes message from the master AN by sending an A17Set Attributes Ack message back to the master AN. Upon receiving the A17-Set Attributes Ack message from the slave AN, the master AN stops timer Tsetattrib-17. h. The master AN also sends an A17-Set Attributes message to the other AN containing the Alternate Session State Information Records to be used for the connection. The master AN starts timer Tsetattrib17. This message is sent only if there are sectors belonging to the other AN in the ATs Active Set. i. The other AN acknowledges the A17-Set Attributes message from the master AN by sending an A17Set Attributes Ack message back to the master AN. Upon receiving the A17-Set Attributes Ack message from the other AN, the master AN stops timer Tsetattrib-17. The traffic channels are updated to reflect the new Active Set.
j.
Step k l and m n can occur in parallel. k. The master AN deallocates its resources used for connecting to the dropped pilots. The master AN sends an A17-Set Attributes message to the slave AN containing the Session State Information Records reflecting the new Active Set to be used for the connection. The master AN starts timer Tsetattrib-17. This message is sent only if there are sectors belonging to the slave AN in the ATs Active Set. l. The slave AN acknowledges the A17-Set Attributes message from the master AN by sending an A17Set Attributes Ack message back to the master AN. Upon receiving the A17-Set Attributes Ack message, the master AN stops timer Tsetattrib-17.
m. The master AN also sends an A17-Set Attributes message to the other AN containing the Session State Information Records reflecting the new Active Set to be used for the connection. The master AN starts timer Tsetattrib-17. This message is sent only if there are sectors belonging to the other AN in the ATs Active Set. n. The other AN acknowledges the A17-Set Attributes message from the master AN by sending an A17Set Attributes Ack message back to the master AN. Upon receiving the A17-Set Attributes Ack message, the master AN stops timer Tsetattrib-17. o. The master AN sends an A16-Attributes Update message to the slave AN containing the new Session State Information Record to be used for the connection. The master AN also include Sector Endpoint Information of the sectors in the current active set of the AT (i.e. the dropped sectors are not included) in the message. The master AN starts timer Tattribupd-16. p. The slave AN updates its session according to the A16-Attributes Update message and acknowledges the A16-Attributes Update message from the master AN by sending an A16-Attributes Update Ack message to the master AN. Upon receiving the A16-Attributes Update Ack message, the master AN stops timer Tattribupd-16.
29 An example of such parameters is DRCLength.
3-62
3GPP2 A.S0008-C v2.0

1 2 3
q. The slave AN detaches from the removed sectors using cross-connectivity procedure in section 3.12.5.2.
4 5 6 7 8
3.12.5.5
Master AN updates Slave AN with the updated session during Connected State Session Transfer with Cross-Connectivity Support
This scenario describes the call flow where the master AN updates the slave AN with Session State Information Records, Serving Sector Information and/or Sector Endpoint Information during Connected State HRPD Session Transfer with Cross-Connectivity Support.
9 10 11 12
Figure 3.12.5.5-1 Master AN updates Slave AN with the updated Session State Information Records or Serving Sector during Connected-State Session Transfer with Cross-Connectivity Support a. Whenever there is a change in the Session State Information Records, or when there is a change in the serving sector or Sector Endpoint Information, the master AN sends an A16-Attributes Update message containing the updated Session State Information Records, Serving Sector Information and/or Sector Endpoint Information to the slave AN. The master AN starts timer Tattribupd-16. b. The slave AN acknowledges the A16-Attributes Update message from the master AN by sending an A16-Attributes Update Ack message to the master AN. Upon receiving the A16-Attributes Update Ack message, the master AN stops timer Tattribupd-16.
13 14 15 16 17 18 19 20
21 22 23 24
3.12.5.6
Slave AN tunnels signaling messages to AT through Master AN during Make-beforebreak Session Transfer
This scenario describes the call flow where slave AN sends signaling messages (including DoS) to the AT through the master AN during make-before-break session transfer.
25 26 27
Figure 3.12.5.6-1
Slave AN tunnels signaling messages to AT through Master AN during Make-before-break Session Transfer
28 29 30 31 32
a. When the slave AN needs to send an AT signaling message (including DoS) to the AT, e.g., a signaling message related to the application-layer route of the slave AN, the slave AN encapsulates the AT signaling message in an A16-FL Signal Tunnel message. The slave AN sends the A16-FL Signal Tunnel message to the master AN to tunnel the AT signaling message to the AT. The master AN starts timer Tsigtunnel-16. 3-63
3GPP2 A.S0008-C v2.0

1 2 3 4 5 6
b. Upon receipt of the A16-FL Signal Tunnel message, the master AN sends an A16-FL Signal Tunnel Ack message to the slave AN. Upon receiving the A16-FL Signal Tunnel Ack message, the slave AN stops timer Tsigtunnel-16. c. The master AN sends the encapsulated signaling message to the AT. This step can occur anytime after step a.
7 8 9 10 11
3.12.5.7
Tunneling of signaling messages from the AT to Slave AN during Make-before-break Session Transfer
This scenario describes the call flow where master AN forwards air-interface signaling messages (including DoS) related to the slave AN, e.g., signaling messages related to application-layer route in the slave AN, to the slave AN during make-before-break session transfer.
12 13 14
Figure 3.12.5.7-1
Tunneling of signaling messages from the AT to Slave AN during Makebefore-break Session Transfer
15 16 17 18 19 20 21
a. The master AN receives a signaling message (including DoS) related to the slave AN, e.g., a signaling message related to the application-layer route of the slave AN, from the AT. b. The master AN sends an A16-RL Signal Tunnel message to the slave AN. The message encapsulates the received AT signaling message. The master AN starts timer Tsigtunnel-16. c. Upon receipt of the A16-RL Signal Tunnel message, the slave AN sends an A16-RL Signal Tunnel Ack message to the master AN. Upon receiving the A16-RL Signal Tunnel Ack message, the master AN stops timer Tsigtunnel-16. 3.12.6 Data Flow during Make-before-break Session Transfer This section describes the flow of data during make-before-break session transfer. Before make-before-break session transfer starts, the forward-link data from the PDSN flows through A10 connection(s) between the PDSN and the source PCF. The source PCF forwards the data through the corresponding A8 connection(s) to the source AN which then transmits the data over-the-air through the application-layer route belonging to the source AN. In this example, the source AN is assumed to use RLP route A. Similarly, the reverse-link data from the AT will be transmitted using RLP route A through the source AN/PCF to the PDSN.
22 23 24 25 26 27 28 29
3-64
3GPP2 A.S0008-C v2.0
1 2
Figure 3.12.6-1 Data Flow before Make-before-break Session Transfer starts After (i) the target AN has received the A16-Session Transfer Request message (step f in Figure 3.12.1-1), (ii) the target AN has established cross-connectivity with all RTs in the Active Set (step g in Figure 3.12.1-1) and (iii) the corresponding A8/A10 connections have been established through the target PCF and the PDSN (step k in Figure 3.12.1-1), new forward-link data now flows through the target AN/PCF. The target AN encapsulates the data in RLP route B during transmission to the AT. Note that the actual over-the-air transmission may occur in RTs in either the source AN or the target AN due to cross-connectivity. The source AN can still forward any buffered data to the AT using RLP route A. Once the AT has received the forward-link data on RLP route B or when the target AN has sent a message to the AT indicating that RLP route B shall be used (step n in Figure 3.12.1-1), the AT transmits new reverse-link data on RLP route B. The target AN subsequently forwards the data on the corresponding A8/A10 connection(s) to the PDSN. Note that the source AN may still request and receive retransmission of RLP route A packets.
3 4 5 6 7 8 9 10 11 12 13 14
15 16
Figure 3.12.6-2 Data Flow during Make-before-break Session Transfer Once the source AN has depleted all buffered data in the forward-link and no longer has any outstanding retransmission on the reverse-link, the source AN tears down the corresponding A8/A10 connection(s) with the source PCF and the PDSN. As a result, the data now only flows through the target AN and PCF to the PDSN through RLP route B.
17 18 19 20
21 22
Figure 3.12.6-3 Data Flow after Make-before-break Session Transfer finishes
23
3-65
3GPP2 A.S0008-C v2.0
1 2 3 4 5
3.13
Hard Handoff Negotiation Procedures with Example of Air-interface Signaling
This section describes the call flows associated with the negotiation procedure between the source AN and the target AN for the hard handoff procedure. For simplicity, A9 and A11 interface signaling is not shown. 3.13.1 HRPD Hard Handoff without SLP States Transfer This section describes the call flow associated with the hard handoff procedure without personality negotiation and without SLP states transfer between the source AN and the target AN.
AT Source AN Target AN time
6 7 8
Tstreq-16
A16-Session Transfer Request [UATI, SSIR = AT's main personality, ESSIR = All of AT's negotiated personality, Encapsulated Message = OTA RouteUpdate message]
A16-Session Transfer Response [SLP Reset Required = 1, Proposed SSIR = RouteUpdate Parameter (RouteUpdateProtocol)]
Source AN closes connection and assigns new connection
Tstcomp-16
c d
A16-Session Transfer Complete [UATI, Confirmed UATI, Assigned UATI, LCM_UATI]
Connection Establishment between AT and Target AN
9 10
Figure 3.13.1-1 HRPD Hard Handoff without SLP States Transfer a. When the source AN is ready to transfer the session to the target AN, the source AN sends an A16Session Transfer Request message to the target AN and starts timer Tstreq-16. This message includes the session state information records for the main personality of the AT in the SSIR IE and all negotiated personalities in the ESSIR IE. It also includes the encapsulated over-the-air RouteUpdate message that the source AN receives from the AT. b. The target AN reserves its resource for the AT based on the information in the A16-Session Transfer Request message and responds with an A16-Session Transfer Response message to the source AN and starts timer Tstcomp-16. This message includes the SLP Reset Required indicator set to 1 to indicate that the target AN cannot receive SLP states. It also includes RouteUpdate parameters in the Proposed SSIR IE. The source AN stops timer Tstreq-16 upon receipt of the message. c. The source AN closes the connection with the AT and at the same time assigns a new connection to the AT, e.g., by sending ConnectionClose and TrafficChannelAssignment messages in the same Security Layer Packet [10]. The connection shall be assigned according to the RouteUpdate parameters in the Proposed SSIR IE in the A16-Session Transfer Response message. d. The source AN sends an A16-Session Transfer Complete message to the target AN. Given a snapshot of the SSIRs at the source AN taken immediately before the message(s) was sent that closed the connection in step c, this message includes any SSIRs of the source AN in that snapshot that are different from the SSIR set that the target AN expects. The set that the target AN expects consists of 3-66
11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28
3GPP2 A.S0008-C v2.0

1 2 3 4 5 6
the SSIRs contained in the A16-Session Transfer Request message as modified by the session changes in the A16-Session Transfer Response message. Any SSIRs received in the A16-Session Transfer Complete message shall take precedence over SSIRs in the A16-Session Transfer Request message. The target AN stops timer Tstcomp-16 upon receipt of the message. e. The AT establishes a connection with the target AN. The target AN ignores any unsolicited ConnectionClose messages from the AT with Close Reason being 0x01 (Close Reply). 3.13.2 HRPD Hard Handoff with Personality Switch This section describes the call flow associated with the hard handoff procedure with personality switch.
AT Source AN Target AN time
7 8
Tstreq-16
A16-Session Transfer Request [UATI, SSIR = AT's main personality, ESSIR = All of AT's negotiated personality, Encapsulated Message = OTA RouteUpdate message]
A16-Session Transfer Response [SLP Reset Required = 1, Proposed SSIR = RouteUpdate Parameter (RouteUpdateProtocol), Proposed SSIR = Session Configuration Token of the selected personality]
Unlock the configuration
Tstcomp-16
Personality Changes d
Source AN closes connection and assigns new connection
e A16-Session Transfer Complete [UATI, Confirmed UATI, Assigned UATI, LCM_UATI] f
Connection Establishment between AT and Target AN
9 10
Figure 3.13.2-1 HRPD Hard Handoff with Personality Switch a. When the source AN is ready to transfer the session to the target AN, the source AN sends an A16Session Transfer Request message to the target AN and starts timer Tstreq-16. This message includes the session state information records for the main personality of the AT in the SSIR IE and all negotiated personalities in the ESSIR IE, and it also includes the encapsulated overthe-air RouteUpdate message that the source AN receives from the AT. b. The target AN determines that the current personality is not acceptable and chooses one of the personalities from the SSIR and ESSIRs received in the A16-Session Transfer Request message, and sends an A16-Session Transfer Response message to the source AN indicating an acceptable personality index in the form of the Session Configuration Token in the Proposed SSIR IE. The target AN reserves its resources for the AT based on the selected personality session information and starts timer Tstcomp-16. This message includes the SLP Reset Required indicator set to 1 to indicate that the target AN cannot receive SLP states. It also includes RouteUpdate parameters in the Proposed SSIR IE. The source AN stops timer Tstreq-16 upon receipt of the message. c. The source AN unlocks the configuration to allow new session configuration with the AT. d. The source AN switches the ATs personality to one that is acceptable to the target AN. This will take effect after the connection is closed. 3-67
11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26
3GPP2 A.S0008-C v2.0

1 2 3 4 5 6 7 8 9 10 11 12 13 14
e. The source AN closes the connection with the AT and at the same time assigns a new connection to the AT, e.g., by sending ConnectionClose and TrafficChannelAssignment messages in the same Security Layer Packet [10]. The connection shall be assigned based on the personality chosen by the target AN. f. The source AN sends an A16-Session Transfer Complete message to the target AN. Given a snapshot of the SSIRs at the source AN taken immediately before the message(s) was sent that closed the connection in step e, this message includes any SSIRs of the source AN in that snapshot that are different from the SSIR set that the target AN expects. The set that the target AN expects consists of the SSIRs contained in the A16-Session Transfer Request message as modified by the session changes in the A16-Session Transfer Response message. Any SSIRs received in the A16-Session Transfer Complete message shall take precedence over SSIRs in the A16-Session Transfer Request message.
g. The AT establishes a connection with the target AN. The target AN ignores any unsolicited ConnectionClose messages from the AT with Close Reason being 0x01 (Close Reply).
3-68
3GPP2 A.S0008-C v2.0
1 2
3.14
HRPD IOS Cross-Connectivity Call Flows
This section describes the call flows associated with cross-connectivity for an HRPD AT. 3.14.1 AT Connection Setup This section describes the call flow associated with an AT connection setup where one pilot in the ATs Active Set belongs to one target AN and another pilot in the ATs Active Set belongs to a second target AN. Figure 3.14.1-1 illustrates the call flow for an AT connection setup where an RT that is connected to target AN 1 becomes the serving RT. For reference, RT 0 belongs to the source AN, RT 1 belongs to target AN 1, and RT 2 belongs to target AN 2. All three sectors are in the ATs Active Set upon completion of connection setup.
3 4 5 6 7 8 9 10
3-69
3GPP2 A.S0008-C v2.0

AT Source AN (RT0) AT initiates connection establishment procedure Tallocreq-17 Target AN 1 (RT1) Target AN 2 (RT2) Time
a A17-Allocate Request (SSIRs, Proposed SSIR which needs to be filled in) A17-Allocate Response (Proposed SSIR filled in) A17-Allocate Request (SSIRs, Proposed SSIR which needs to be filled in) A17-Allocate Response (Proposed SSIR filled in) A17-Set Attributes (SSIRs, Power Ramp-Up Bias) A17-Set Attributes Ack A17-Set Attributes (SSIRs, Power Ramp-Up Bias) A17-Set Attributes Ack A17-CCPacket A17-CCPacket b c d e f g h i j k l
Tallocreq-17
Tsetattrib-17
Tsetattrib-17
Traffic channel assigned
Traffic channel assigned Twaitacq-17 Traffic channel assigned Pilot + DRC Pilot + DRC Pilot + DRC A19-Acquisition Status A19-Acquisition Status Ack A19-Acquisition Status A19-Acquisition Status Ack Tsetattrib-17 A17-Set Attributes (RTCH Power Control Setpoint) A17-Set Attributes Ack A17-Set Attributes (RTCH Power Control Setpoint) A17-Set Attributes Ack Tacqstatus-19 Twaitacq-17
n o p q r s
Tacqstatus-19
t u v w x y
Tsetattrib-17
1 2
Figure 3.14.1-1 AT Connection Setup a. The AT initiates connection establishment procedures with the source AN. The AT reports that it would like to add at least one pilot belonging to the source AN to its Active Set (in this example, RT 0). The AT also reports that it would like to add the RT 1 pilot and RT 2 pilot to its Active Set. b. The source AN decides to add the RT 0, RT 1, and RT 2 pilots to the ATs Active Set. The AT may report multiple pilots; some of them belonging to the target ANs. For those pilots the source AN sends an A17-Allocate Request message to the target ANs to request them to allocate resources at those sectors. In this example call flow there are two sectors (i.e., RT 1 and RT 2). The source AN sends an A17-Allocate Request message to target AN 1. The source AN starts timer Tallocreq-17. The 3-70
3 4 5 6 7 8 9 10
3GPP2 A.S0008-C v2.0

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 48 49 50
A17-Allocate Request message contains the Session State Information Records and the Proposed Session State Information Record with fields that need to be filled in by target AN 1 for each sector that it adds to the ATs Active Set. If the Default RouteUpdate Protocol [10] is in use, then the Proposed Session State Information Record contains the RouteUpdate Parameter Record [10] and may contain the ExtendedRouteUpdate Parameter Record [10], and the target AN shall fill out values for either MACIndex or MACIndexLSB and MACIndexMSB [10] as appropriate in the A17-Allocate Response message. It also contains the AN A19 Control Endpoint ID and AN A18 Data Endpoint ID of the source AN that target AN 1 is to use to send A19 control and A18 data information to, respectively. Additionally, the A17-Allocate Request message contains round trip delay information to assist RT 1 with the acquisition of the AT. c. Upon receiving the A17-Allocate Request message from the source AN, target AN 1 decides that it can allocate resources at RT 1. Subsequently, target AN 1 sends an A17-Allocate Response message to the source AN in response to the request from the source AN. The A17-Allocate Response message contains the Proposed Session State Information Record with fields filled in by target AN 1 for RT 1. It also contains the RT A19 Control Endpoint ID and RT A18 Data Endpoint ID of target AN 1 that the source AN is to use to send A19 control and A18 data information to for RT 1, respectively. Note that if target AN 1 had decided that it could not allocate resources at RT 1, no Proposed Session State Information Record and no RT A19 Control Endpoint ID/RT A18 Data Endpoint ID would be included in the A17-Allocate Response message. Upon receiving the A17-Allocate Response message, the source AN stops timer Tallocreq-17. The source AN stops timer Tallocreq-17 associated with an A17-Allocate Request message when an A17-Allocate Response message is received. Target AN 1 starts timer Twaitacq-17 and waits to acquire the AT. d. The source AN sends an A17-Allocate Request message to target AN 2. The source AN starts timer Tallocreq-17. Step d can occur in parallel with step b. e. Upon receiving the A17-Allocate Request message from the source AN, target AN 2 decides that it can allocate resources at RT 2. Subsequently, target AN 2 sends an A17-Allocate Response message to the source AN in response to the request from the source AN. Upon receiving the A17-Allocate Response message, the source AN stops timer Tallocreq-17. Target AN 2 starts timer Twaitacq-17 and waits to acquire the AT. f. The source AN sends an A17-Set Attributes message to target AN 1. The message includes the Session State Information Records and Power Ramp-Up Bias to be used . The source AN starts timer Tsetattrib-17.
g. Target AN 1 acknowledges the A17-Set Attributes message from the source AN by sending an A17Set Attributes Ack message to the source AN. Upon receiving the A17-Set Attributes Ack message, the source AN stops timer Tsetattrib-17. h. The source AN sends an A17-Set Attributes message to target AN 2. The message includes the Session State Information Records and Power Ramp-Up Bias to be used. The source AN starts timer Tsetattrib-17. Step h can occur in parallel with step f. i. Target AN 2 acknowledges the A17-Set Attributes message from the source AN by sending an A17Set Attributes Ack message to the source AN. Upon receiving the A17-Set Attributes Ack message, the source AN stops timer Tsetattrib-17. The source AN assigns traffic channels for the AT. The source AN sends an A17-CC Packet message to target AN 1 containing the traffic channel assignments so that RT 1 can transmit the traffic channel assignment information to the AT on its forward control channel. The A17-CC Packet message also contains information indicating when the traffic channel assignment is to be transmitted on the forward control channel to the AT. Note that the source AN sends the A17-CC Packet message to target AN 1 so that the traffic channel assignment information can be sent on the control channel of all sectors that the AT has reported as wanting to add to its Active Set in step a. This is done because the source AN cannot be sure which sector the AT is listening to for the traffic channel assignment information. 3-71
j.
3GPP2 A.S0008-C v2.0

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
k. The source AN sends an A17-CC Packet message to target AN 2 containing the traffic channel assignments so that RT 2 can transmit the traffic channel assignment information to the AT on its forward control channel. Note that the source AN sends the A17-CC Packet message to target AN 2 so that the traffic channel assignment information can be sent on the control channel of all sectors that the AT has reported as wanting to add to its Active Set in step a. This is done because the source AN cannot be sure which sector the AT is listening to for the traffic channel information. l. The source AN transmits the traffic channel assignment information to the AT on RT 0s control channel during the specified time.
m. Target AN 1 transmits the traffic channel assignment information to the AT on RT 1s control channel during the specified time. n. Target AN 2 transmits the traffic channel assignment information to the AT on RT 2s control channel during the specified time. o. The AT transmits pilot + DRC with the DRC pointing to RT 1. This is received by RT 0. p. Same as step o except that pilot + DRC are received by RT 1. Steps o, p and q occur simultaneously. q. Same as steps o and p except that pilot + DRC are received by RT 2. Steps o, p, and q occur simultaneously. r. RT 1 acquires the ATs reverse traffic channel and target AN 1 sends an A19-Acquisition Status message to the AN A19 Control Endpoint ID of the source AN indicating this. The target AN 1 starts timer Tacqstatus-19. The A19-Acquisition Status message contains sector information (i.e., leg number of the sector) indicating which sector from the ATs Active Set has acquired the ATs reverse traffic channel (in this case, RT 1). This step can occur anytime after step p. Upon receiving the A19-Acquisition Status message from target AN 1, the source AN sends an A19Acquisition Status Ack message to the RT A19 Control Endpoint ID of RT 1. Upon receiving the A19-Acquisition Status Ack message, target AN 1 stops timer Tacqstatus-19. RT 2 acquires the ATs reverse traffic channel and target AN 2 sends an A19-Acquisition Status message to the AN Control Endpoint ID of the source AN indicating this. The target AN starts timer Tacqstatus-19. The A19-Acquisition Status message contains sector information (i.e., leg number of the sector) indicating which sector from the ATs Active Set has acquired the ATs reverse traffic channel (in this case, RT 2). This step can occur anytime after step q.
s.
t.
u. Upon receiving the A19-Acquisition Status message from target AN 2, the source AN sends an A19Acquisition Status Ack message to the RT Control Endpoint ID of RT 2. Upon receiving the A19Acquisition Status Ack message, target AN 2 stops timer Tacqstatus-19. v. After the source AN has received A19-Acquisition Status message, the source AN sends an A17-Set Attributes message with the AT Acquired Flag IE to target AN 1 to indicate that the AT has been acquired. The source AN starts timer Tsetattrib-17. Note that if RT 0 had acquired the ATs reverse traffic channel, the source AN would still send the A17-Set Attributes message to target AN 1. Target AN 1 stops timer Twaitacq-17. Step v can occur in parallel with step s. w. Target AN 1 acknowledges the A17-Set Attributes message from the source AN by sending an A17Set Attributes Ack message to the source AN. Upon receiving the A17-Set Attributes Ack message, the source AN stops timer Tsetattrib-17. x. The source AN sends an A17-Set Attributes message with the AT Acquired Flag IE to target AN 2 to indicate that the AT has been acquired. The source AN starts timer Tsetattrib-17. Note that if RT 0 had acquired the ATs reverse traffic channel, the source AN would still send the A17-Set Attributes message to target AN 2. Target AN 2 stops timer Twaitacq-17. Step x can occur in parallel with steps s and v.
3-72
3GPP2 A.S0008-C v2.0

1 2 3
y. Target AN 2 acknowledges the A17-Set Attributes message from the source AN by sending an A17Set Attributes Ack message to the source AN. Upon receiving the A17-Set Attributes Ack message, the source AN stops timer Tsetattrib-17. 3.14.2 Add Pilot Belonging to Target AN to ATs Active Set This section describes the call flow associated with adding a pilot that belongs to a target AN to the ATs Active Set. Figure 3.14.2-1 illustrates the call flow for adding a pilot that belongs to target AN 1 to the ATs Active Set. For reference, RT 0 belongs to the source AN, RT 1a and RT 1b belong to target AN 1, and RT 2 belongs to target AN 2. RT 0, RT 1a, and RT 2 are in the ATs Active Set at the start of the add pilot procedure.
4 5 6 7 8 9 10
11 12
Figure 3.14.2-1 Add Pilot Belonging to Target AN to ATs Active Set a. The AT is in connected state and has the RT 0, RT1a, and RT 2 pilots in its Active Set. b. The AT reports that it would like to add the RT 1b pilot to its Active Set. c. The source AN decides to add the RT 1b pilot to the ATs Active Set. The AT may report multiple pilots; some of them belonging to the target ANs. For those pilots the source AN sends an A17Allocate Request message to the target ANs to request them to allocate resources at these sectors. In this example call flow there is only one additional sector (i.e., RT 1b). The source sends an A17Allocate Request message to target AN 1. The source AN starts timer T17-allocreq. The A17-Allocate Request message contains the Session State Information Records and the Proposed Session State Information Record with fields that need to be filled in by target AN 1 for each sector that it adds to the ATs Active Set. If the Default RouteUpdate Protocol [10] is in use, then the Proposed Session State Information Record contains the RouteUpdate Parameter Record [10] and the target AN shall fill out values for either MACIndex or MACIndexLSB and MACIndexMSB [10] as appropriate in the A17-Allocate Response message. It also contains the AN A19 Control Endpoint ID and AN A18 Data Endpoint ID of the source AN that target AN 1 is to use to send A19 control and A18 data information to, respectively. Additionally, the A17-Allocate Request message contains round trip delay information to assist RT 1b with the acquisition of the AT. d. Upon receiving the A17-Allocate Request message from the source AN, target AN 1 decides that it can allocate resources at RT 1b. Subsequently, target AN 1 sends an A17-Allocate Response message 3-73
13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30
3GPP2 A.S0008-C v2.0

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
to the source AN in response to the request from the source AN. The A17-Allocate Response message contains the Proposed Session State Information Record with fields filled in by target AN 1 for RT 1b. It also contains the RT A19 Control Endpoint ID and RT A18 Data Endpoint ID of target AN 1 that the source AN is to use to send A19 control and A18 data information to for RT 1b, respectively. Note that if target AN 1 had decided that it could not allocate resources at RT 1b, no Proposed Session State Information Record and no RT A19 Control EndpointID/RT A18 Data Endpoint ID would be included in the A17-Allocate Response message. Upon receiving the A17-Allocate Response message, the source AN stops timer Tallocreq-17. The source AN stops timer Tallocreq-17 associated with an A17-Allocate Request message when an A17-Allocate Response message is received. e. The source AN sends an A17-Set Attributes message to target AN 1 containing the Alternative Session State Information Records to be used. The source AN starts timer Tsetattrib-17. If Default RouteUpdate Protocol [10] is in use, then the message contains two instances of Alternative Session State Information Record IE. The first instance contains the old RouteUpdate Parameter Record [10] before the traffic channel is updated while the second instance contains the new RouteUpdate Parameter Record. The Alternative Session State Information Records are included because target AN 1 does not know exactly when the value of some parameters takes effect until the traffic channels are updated. For Default RouteUpdate Protocol [10], the DRCLength parameter being used by the AT is not known until the traffic channels are updated. f. Target AN 1 acknowledges the A17-Set Attributes message from the source AN by sending an A17Set Attributes Ack message to the source AN. Upon receiving the A17-Set Attributes Ack message, the source AN stops timer Tsetattrib-17.
g. The source AN sends an A17-Set Attributes message to target AN 2 containing the Alternative Session State Information Records to be used. The source AN starts timer Tsetattrib-17. Step g can occur in parallel with step e. h. Target AN 2 acknowledges the A17-Set Attributes message from the source AN by sending an A17Set Attributes Ack message to the source AN. Upon receiving the A17-Set Attributes Ack message, the source AN stops timer Tsetattrib-17. i. j. The traffic channels between the AT and RT 0, RT 1a, and RT 2 are updated and the traffic channel between the AT and RT 1b is established. The source AN sends an A17-Set Attributes message to target AN 1 containing the Session State Information Records to be used. The source AN starts timer Tsetattrib-17.
k. Target AN 1 acknowledges the A17-Set Attributes message from the source AN by sending an A17Set Attributes Ack message to the source AN. Upon receiving the A17-Set Attributes Ack message, the source AN stops timer Tsetattrib-17. l. The source AN sends an A17-Set Attributes message to target AN 2 containing the Session State Information Records to be used. The source AN starts timer Tsetattrib-17. Step l can occur in parallel with step j.
m. Target AN 2 acknowledges the A17-Set Attributes message from the source AN by sending an A17Set Attributes Ack message to the source AN. Upon receiving the A17-Set Attributes Ack message, the source AN stops timer Tsetattrib-17. 3.14.3 Drop Pilot Belonging to Target AN from ATs Active Set This section describes the call flow associated with dropping a pilot that belongs to a target AN from the ATs Active Set. Figure 3.14.3-1 illustrates the call flow for dropping a pilot that belongs to target AN 1 from the ATs Active Set. For reference, RT 0 belongs to the source AN, RT 1a and RT 1b belong to target AN 1, and RT 2 belongs to target AN 2. All four sectors are in the ATs Active Set at the start of the drop pilot procedure. 3-74
42 43 44 45 46 47 48
3GPP2 A.S0008-C v2.0

1
2 3
Figure 3.14.3-1 Drop Pilot Belonging to Target AN from ATs Active Set a. The AT is in connected state and has the RT 0, RT 1a and RT 1b, and RT 2 pilots in its Active Set. b. The AT reports that it would like to drop the RT 1b pilot from its Active Set. The source AN decides to drop the RT 1b pilot from the ATs Active Set. The AT may report multiple pilots; some of them belonging to the target ANs. c. The source AN sends an A17-Set Attributes message to target AN 1 containing the Alternative Session State Information Records to be used. The source AN starts timer Tsetattrib-17. If Default RouteUpdate Protocol [10] is in use, then the message contains two instances of Alternative Session State Information Record IE. The first instance contains the old RouteUpdate Parameter Record [10] before the traffic channel is updated while the second instance contains the new RouteUpdate Parameter Record. The Alternative Session State Information Records are included because target AN 1 does not know exactly when the value of some parameters takes effect until the traffic channels are updated. For Default RouteUpdate Protocol [10], the DRCLength parameter being used by the AT is not known until the traffic channels are updated. Note that the source AN sends the A17-Set Attributes message to target AN 1 only if there are still sectors belonging to target AN 1 in the ATs Active Set. In this example, RT 1a is still in the ATs Active Set; therefore, the source AN sends the A17-Set Attributes message to target AN 1. d. Target AN 1 acknowledges the A17-Set Attributes message from the source AN by sending an A17Set Attributes Ack message to the source AN. Upon receiving the A17-Set Attributes Ack message, the source AN stops timer Tsetattrib-17. e. The source AN sends an A17-Set Attributes message to target AN 2 containing the Alternative Session State Information Records to be used. The source AN starts timer Tsetattrib-17. Step e can occur in parallel with step c. f. Target AN 2 acknowledges the A17-Set Attributes message from the source AN by sending an A17Set Attributes Ack message to the source AN. Upon receiving the A17-Set Attributes Ack message, the source AN stops timer Tsetattrib-17.
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
g. The traffic channels between the AT and RT 0, RT 1a, and RT 2 are updated and the traffic channel between the AT and RT 1b is torn down. 3-75
3GPP2 A.S0008-C v2.0

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
h. The source AN sends an A17-Deallocate Request message to target AN 1. The source AN starts timer Tdeallocreq-17. The A17-Deallocate Request message contains sector information (i.e., leg number of the sector) indicating which sector is to be dropped from the ATs Active Set (in this case, RT 1b). The A17-Deallocate Request message also contains the Deallocation Timer IE. Target AN 1 uses the Deallocation Timer IE to determine when it should deallocate all RT 1b MAC resources for the AT. In this example, the Deallocation Timer IE is set to zero milliseconds. Therefore, target AN 1 immediately deallocates all RT 1b resources for the AT upon receiving the A17-Deallocate Request message. i. Upon receiving the A17-Deallocate Request message from the source AN, target AN 1 deallocates resources at RT 1b. Subsequently, target AN 1 sends an A17-Deallocate Ack message to the source AN in response to the request from the source AN. Upon receiving the A17-Deallocate Ack message, the source AN stops timer Tdeallocreq-17. The source AN sends an A17-Set Attributes message to target AN 1 containing the Session State Information Records to be used. The source AN starts timer Tsetattrib-17. Note that the source AN sends the A17-Set Attributes message to target AN 1 only if there are still sectors belonging to target AN 1 in the ATs Active Set. In this example, RT 1a is still in the ATs Active Set; therefore, the source AN sends the A17-Set Attributes message to target AN 1.
j.
k. Target AN 1 acknowledges the A17-Set Attributes message from the source AN by sending an A17Set Attributes Ack message to the source AN. Upon receiving the A17-Set Attributes Ack message, the source AN stops timer Tsetattrib-17. l. The source AN sends an A17-Set Attributes message to target AN 2 containing the Session State Information Records to be used. The source AN starts timer Tsetattrib-17.
m. Target AN 2 acknowledges the A17-Set Attributes message from the source AN by sending an A17Set Attributes Ack message to the source AN. Upon receiving the A17-Set Attributes Ack message, the source AN stops timer Tsetattrib-17. 3.14.4 AT Connection Close This section describes the call flows for AT connection close (both graceful and nongraceful). 3.14.4.1 Graceful Connection Close
26 27
28 29 30 31
Figure 3.14.4.1-1 illustrates the call flow for a graceful AT connection close. For reference, RT 0 belongs to the source AN and RT 1a and RT 1b belong to target AN 1. All three sectors are in the ATs Active Set upon start of connection close.
AT Source AN Target AN 1 Time
Connection closed
Tdeallocreq-17
A17-Deallocate Request (Sector Information, Deallocation Timer = 0 msec) A17-Deallocate Ack
b c
32 33
Figure 3.14.4.1-1
Graceful Connection Close
34 35 36 37
a. The source AN determines that it needs to close the air-interface connection either because the AT has requested the source AN to do so or because the source AN has chosen to close the air-interface connection. The source AN either receives a message from the AT requesting the air-interface connection to be closed or the source AN initiates connection close and receives confirmation from 3-76
3GPP2 A.S0008-C v2.0

1 2 3 4 5 6 7 8 9 10 11 12 13 14
the AT for closing the connection. Consequently, the source AN closes the connection and initiates step b. b. The source AN sends an A17-Deallocate Request message to target AN 1. The source AN starts timer Tdeallocreq-17. The A17-Deallocate Request message contains sector information (i.e., leg number of the sector) indicating which sectors are to be dropped from the ATs Active Set (in this case, all sectors are to be dropped, which, in this example, happens to be RT 1a and RT 1b). The A17Deallocate Request message also contains the Deallocation Timer IE. Target AN 1 uses the Deallocation Timer IE to determine when it should deallocate all RT 1a and RT 1b MAC resources for the AT. In this example, the Deallocation Timer IE is set to zero milliseconds. Therefore, target AN 1 immediately deallocates all RT 1a and RT 1b resources for the AT upon receiving the A17Deallocate Request message. c. Target AN 1 sends an A17-Deallocate Ack message to the source AN in response to the request from the source AN. Upon receiving the A17-Deallocate Ack message, the source AN stops timer Tdeallocreq-17. 3.14.4.2 Non-Graceful Connection Close: Scenario 1
15 16 17 18
Figure 3.14.4.2-1 illustrates the call flow for a non-graceful AT connection close. For reference, RT 0 belongs to the source AN and RT 1a and RT 1b belong to target AN 1. All three sectors are in the ATs Active Set upon start of connection close.
19 20
Figure 3.14.4.2-1
Non-Graceful Connection Close: Scenario 1
21 22 23 24 25 26 27 28 29 30 31 32 33 34
a. RT 1a loses the ATs reverse traffic channel and target AN 1 sends an A19-Acquisition Status message to the AN A19 Control Endpoint ID of the source AN indicating this. Target AN 1 starts timer Tacqstatus-19. The A19-Acquisition Status message contains sector information (i.e., leg number of the sector) indicating which sector from the ATs Active Set has lost the ATs reverse traffic channel (in this case, RT 1a). RT 0 also loses the ATs reverse traffic channel and indicates this to the source AN. b. Upon receiving the A19-Acquisition Status message sent by target AN 1 in step a, the source AN sends an A19-Acquisition Status Ack message to the RT A19 Control Endpoint ID of RT 1a. Upon receiving the A19-Acquisition Status Ack message, target AN 1 stops timer Tacqstatus-19. c. RT 1b also loses the ATs reverse traffic channel and target AN 1 sends an A19-Acquisition Status message to the AN A19 Control Endpoint ID of the source AN indicating this. Target AN 1 starts timer Tacqstatus-19. Consequently, since all sectors in the ATs Active Set have lost the ATs reverse traffic channel, the source AN closes the air-interface connection and initiates step e. Step c can occur in parallel with step a.
3-77
3GPP2 A.S0008-C v2.0

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
d. Upon receiving the A19-Acquisition Status message by target AN 1 in step c, the source AN sends an A19-Acquisition Status Ack message to the RT A19 Control Endpoint ID of RT 1b. Upon receiving the A19-Acquisition Status Ack message, target AN 1 stops timer Tacqstatus-19. e. The source AN sends an A17-Deallocate Request message to target AN 1. The source AN starts timer Tdeallocreq-17. The A17-Deallocate Request message contains sector information (i.e., leg number of the sector) indicating which sectors are to be dropped from the ATs Active Set (in this case, all sectors are to be dropped, which, in this example, happens to be RT 1a and RT 1b). The A17Deallocate Request message also contains the Deallocation Timer IE. Target AN 1 uses the Deallocation Timer IE to determine when it should deallocate all RT 1a and RT 1b MAC resources for the AT. In this example, the Deallocation Timer information is set to x milliseconds. Therefore, target AN 1 waits x milliseconds before deallocating all RT 1a and RT 1b resources for the AT upon receiving the A17-Deallocate Request message. 30 f. Target AN 1 sends an A17-Deallocate Ack message to the source AN in response to the request from the source AN. Upon receiving the A17-Deallocate Ack message, the source AN stops timer Tdeallocreq-17. Non-Graceful Connection Close: Scenario 2
16 17 18 19 20
3.14.4.3
Figure 3.14.4.3-1 illustrates the call flow for another non-graceful AT connection close. For reference, RT 0 belongs to the source AN and RT 1a and RT 1b belong to the target AN. All three sectors are in the ATs Active Set upon start of connection close.
Source AN Source AN indicates it wants to close the connection A17-Deallocate Request (Deallocation Timer = x msec) A17-Deallocate Ack Target AN 1
AT
Time
b c
Tdeallocreq-17
21 22
Figure 3.14.4.3-1
Non-Graceful Connection Close: Scenario 2
23 24 25 26 27 28 29 30 31 32 33
a. The source AN determines that it needs to close the air-interface connection and initiates connection close. The source AN does not receive confirmation from the AT within a time interval specified by the air-interface specification [10]. Consequently, the source AN closes the connection and initiates Step b. b. The source AN sends an A17-Deallocate Request message to target AN 1. The source AN starts timer Tdeallocreq-17. The A17-Deallocate Request message contains sector information (i.e., leg number of the sector) indicating which sectors are to be dropped from the ATs Active Set (in this case, all sectors are to be dropped, which, in this example, happens to be RT 1a and RT 1b). The A17Deallocate Request message also contains the Deallocation Timer IE. Target AN 1 uses the Deallocation Timer IE to determine when it should deallocate all RT 1a and RT 1b MAC resources for the AT. In this example, the Deallocation Timer IE is set to x milliseconds. Therefore, target AN
30
For example, if Deallocation Timer = x milliseconds, then each sector belonging to the target AN that is part of the ATs Active Set is required to set the ForwardTrafficValid field [10] associated with the ATs MACIndex to zero for x milliseconds via the QuickConfig message as defined in [10].
3-78
3GPP2 A.S0008-C v2.0

1 2 3 4 5
1 waits x milliseconds before deallocating all RT 1a and RT 1b resources for the AT upon receiving the A17-Deallocate Request message. 31 c. Target AN 1 sends an A17-Deallocate Ack message to the source AN in response to the request from the source AN. Upon receiving the A17-Deallocate Ack message, the source AN stops timer Tdeallocreq-17. 3.14.5 Source AN Requests Resource Modification at Target AN This section describes the call flow associated with modifying resources per the source ANs request at sectors belonging to the target AN that are part of the ATs Active Set. Figure 3.14.5-1 illustrates the call flow for modifying resources at sectors belonging to target AN 1 and target AN 2 that are part of the ATs Active Set as requested by the source AN. For reference, RT 0 belongs to the source AN, RT 1 belongs to target AN 1, and RT 2 belongs to the target AN 2. All three sectors are in the ATs Active Set at the start of the resource modification procedure.
6 7 8 9 10 11 12
13 14
Figure 3.14.5-1 Modify Resources at Sector Belonging to Target AN per Source ANs Request a. The AT is in connected state and has the RT 0, RT1, and RT 2 pilots in its Active Set. b. The source AN determines that it needs to modify resources at RT 0, RT 1, and RT 2. The source AN sends an A17-Modify Request message to target AN 1 to modify resources at RT 1. The source AN starts timer Tmodreq-17. The A17-Modify Request message contains the Proposed Session State Information Records. It also contains the Rapid Commit IE which indicates to target AN 1 whether or not it shall wait until receiving an A17-Set Attributes message from the source AN containing Session State Information Records before modifying resources. 32 In this example, the Rapid Commit IE indicates that target AN 1 shall wait. Note that the source AN sends an A17-Modify Request message to target AN 1 only if it does not know a priori that target AN 1 will accept the requested changes as indicated in the Proposed Session State Information Records contained in the A17-Modify Request
15 16 17 18 19 20 21 22 23 24
31
For example, if Deallocation Timer = x milliseconds, then each sector belonging to the target AN that is part of the ATs Active Set is required to set the ForwardTrafficValid field [10] associated with the ATs MACIndex to zero for x milliseconds via the QuickConfig message as defined in [10].
32 For example, if there are sectors belonging to more than one target AN that are part of the ATs Active Set that the source AN sends an A17-Modify Request message to, the Rapid Commit information element indicates that a target AN shall wait until receiving an A17-Set Attributes message from the source AN containing Session State Information Records before modifying resources.
3-79
3GPP2 A.S0008-C v2.0

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
message. Otherwise, the source AN sends an A17-Set Attributes message to target AN 1 to update resources. c. Upon receiving the A17-Modify Request message from the source AN, target AN 1 decides that it can modify resources at RT 1. Subsequently, target AN 1 sends an A17-Modify Response message to the source AN in response to the request from the source AN. The source AN stops timer Tmodreq-17 when an A17-Modify Response message is received. d. The source sends an A17-Modify Request message to target AN 2 to modify resources at RT 2. The source AN starts timer Tmodreq-17. The A17-Modify Request message contains the Proposed Session State Information Records. It also contains the Rapid Commit IE which indicates to target AN 2 that it shall wait until receiving an A17-Set Attributes message from the source AN containing Session State Information Records before modifying resources. Note that the source AN sends an A17Modify Request message to target AN 2 only if it does not know a priori that target AN 2 will accept the requested changes as indicated in the Proposed Session State Information Records contained in the A17-Modify Request message. Otherwise, the source AN sends an A17-Set Attributes message to target AN 2 to update resources. Step d can occur in parallel with step b. e. Upon receiving the A17-Modify Request message from the source AN, target AN 2 decides that it can modify resources at RT 2. Subsequently, target AN 2 sends an A17-Modify Response message to the source AN in response to the request from the source AN. Upon receiving the A17-Modify Response message, the source AN stops timer Tmodreq-17. f. The source AN sends an A17-Set Attributes message to target AN 1 containing the Session State Information Records to be used. The source AN starts timer Tsetattrib-17. Note that the source AN sends the A17-Set Attributes message to target AN 1 only if the Rapid Commit IE included in the A17-Modify Request message in step b indicated that target AN 1 shall wait until receiving an A17Set Attributes message from the source AN containing Session State Information Records before modifying resources. In this example, the Rapid Commit IE indicated that target AN 1 shall wait.
g. Target AN 1 acknowledges the A17-Set Attributes message from the source AN by sending an A17Set Attributes Ack message to the source AN. Upon receiving the A17-Set Attributes Ack message, the source AN stops timer Tsetattrib-17. h. The source AN sends an A17-Set Attributes message to target AN 2 containing the Session State Information Records to be used. The source AN starts timer Tsetattrib-17. Note that the source AN sends the A17-Set Attributes message to target AN 2 only if the Rapid Commit IE included in the A17-Modify Request message in step d indicated that target AN 2 shall wait until receiving an A17Set Attributes message from the source AN containing Session State Information Records before modifying resources. In this example, the Rapid Commit IE indicated that target AN 2 shall wait. Step h can occur in parallel with step f. i. Target AN 2 acknowledges the A17-Set Attributes message from the source AN by sending an A17Set Attributes Ack message to the source AN. Upon receiving the A17-Set Attributes Ack message, the source AN stops timer Tsetattrib-17.
39 40 41 42 43 44 45
3.14.6 Target AN Requests Resource Modification at Target AN This section describes the call flow associated with modifying resources per a target ANs request at sectors belonging to the target AN that are part of the ATs Active Set. Figure 3.14.6-1 illustrates the call flow for modifying resources at an RT belonging to target AN 1 that is part of the ATs Active Set as requested by target AN 1. For reference, RT 0 belongs to the source AN, RT 1 belongs to target AN 1, and RT 2 belongs to the target AN 2. All three sectors are in the ATs Active Set at the start of the resource modification procedure.
3-80
3GPP2 A.S0008-C v2.0
1 2
Figure 3.14.6-1 Modify Resources at Sector Belonging to Target AN per Target ANs Request a. The AT is in connected state and has the RT 0, RT1, and RT 2 pilots in its Active Set. b. Target AN 1 determines that it needs to modify resources at RT 1. Target AN 1 sends an A17-Target Modify Request message the source AN. Target AN 1 starts timer Ttgtmodreq-17. The A17-Target Modify Request message contains the Proposed Session State Information Records. c. Upon receiving the A17-Target Modify Request message from target AN 1, the source AN sends an A17-Modify Request message to target AN 2 to modify resources at RT 2. The source AN starts timer Tmodreq-17. It also contains the Rapid Commit IE which indicates to target AN 2 whether or not it shall wait until receiving an A17-Set Attributes message from the source AN containing Session State Information Records before modifying resources. 33 In this example, the Rapid Commit IE indicates that target AN 2 does not have to wait. Note that the source AN sends an A17-Modify Request message to target AN 2 only if it does not know a priori that target AN 2 will accept the requested changes as indicated in the Proposed Session State Information Records contained in the A17-Modify Request message. Otherwise, the source AN sends an A17-Set Attributes message to target AN 2 to update resources. d. Upon receiving the A17-Modify Request message from the source AN, target AN 2 decides that it can modify resources at RT 2. Subsequently, target AN 2 sends an A17-Modify Response message to the source AN in response to the request from the source AN. Upon receiving the A17-Modify Response message, the source AN stops timer Tmodreq-17. The source AN stops timer Tmodreq-17 when an A17-Modify Response message is received. e. Upon receiving the A17-Modify Response message from target AN 2, the source AN decides that it can accept the resource modification at RT 1 as requested by target AN 1 in step b and sends an A17-Target Modify Response message to target AN 1 in response to the request from target AN 1. Upon receiving the A17-Target Modify Response message, target AN 1 stops timer Ttgtmodreq-17. Target AN 1 stops timer Ttgtmodreq- when an A17-Target Modify Response message is received. 3.14.7 Serving RT Switching This section describes the call flows for serving RT switching. For more details on the serving RT switching procedure, refer to section 2.7.4.1. In the following call flows, x, y, z, w, t1, and t2 are non-negative integers. No ordering is assumed with respect to these numbers.
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
33 For example, if there are sectors belonging to more than one target AN that are part of the ATs Active Set, the Rapid Commit information element indicates that a target AN shall wait until receiving an A17-Set Attributes message from the source AN containing Session State Information Records before modifying resources.
3-81
3GPP2 A.S0008-C v2.0

1 2 3 4 5 6 7 8 9
In the following procedures, we refer to the source AN receiving messages from an RT. It should be noted that if the sector belongs to the source AN, then such messages are exchanged between the source AN and its sector and are part of the source AN-source RT interface and, hence, are beyond the scope of this standard (i.e., the source AN can choose its own proprietary messages to communicate with its sectors). Similarly, in the following procedures, we refer to the source AN sending messages to the sectors. When the sector belongs to the source AN, then such messages are exchanged between the source AN and its sector and are part of the source AN-source RT interface and, hence, are beyond the scope of this standard. 3.14.7.1 Serving RT Change: Serving RT Moves to Target AN
10 11 12 13
Figure 3.14.7.1-1 illustrates a call flow where the serving RT changes from an RT belonging to the source AN to an RT belonging to a target AN. For reference, RT 0 belongs to the source AN and RT 1 belongs to target AN 1. Both sectors are in the ATs Active Set.
Target AN 1 Source AN
Endpoint ID 1 (for RT 1)
Time
Serving sector is RT 0 (belongs to source AN) A18-FTCH Packet (destination is RT 1, PacketID: x to x+w, DTGTag = t1, DTGFirstPacketID = x) A19-Forward Desired (source is RT 1) Tservrtch-19 A19-Forward Desired Ack (destination is RT 1) Serving sector is RT 1 (belongs to target AN 1)
a b c d e
14 15
Figure 3.14.7.1-1
Serving RT Change: Serving RT Moves to Target AN
16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36
a. The serving RT (in this example, RT 0) belongs to the source AN. b. If the source AN chooses to perform multicasting, the source AN starts sending the A18-FTCH Packet messages to the RT A18 Data Endpoint IDs of all the sectors that are in the ATs Active Set (in this example, the RT A18 Data Endpoint ID of RT 1). This is referred to as multicasting. The source AN starts multicasting as a result of receiving an early indication from one of its own sectors (in this example, RT 0) that the serving RT chosen by the AT has changed. In this scenario, the source AN performs multicasting, it sends the A18-FTCH Packet message to the RT Data Endpoint ID of RT 1. At the same time, the source AN sends the same data to RT 0. c. An RT that belongs to target AN 1 (in this example, RT 1) detects that the AT has chosen it as the serving RT. RT 1 indicates this to the source AN by sending an A19-Forward Desired message to the AN A19 Control Endpoint ID of the source AN. RT 1 starts timer Tservrtch-19. RT 1 is now added to the Candidate Serving Set. The Candidate Serving Set contains two sectors at this time (RT 0 and RT 1). If the selected target RT is unable to support the RT switch, the target RT may notify the AT that it cannot support the AT at this moment (e.g., by setting DRC Lock = 0 [10]), and does not send the A19-Forward Desired message to the source AN. There may be other actions that the target RT can perform in this scenario. d. Upon receiving the A19-Forward Desired message from RT 1, the source AN sends an A19-Forward Desired Ack message to the RT A19 Control Endpoint ID of RT 1. Upon receiving the A19-Forward Desired Ack message, RT 1 stops timer Tservrtch-19. e. The sector that sent the A19-Forward Desired message in step c (in this example, RT 1) is now the serving RT. The source AN stops multicasting as soon as it determines that there is only one sector in 3-82
3GPP2 A.S0008-C v2.0

1 2
the Candidate Serving Set. This determination is made after receiving an indication from one of its own sectors (in this example, RT 0) that the AT has changed the serving RT to another sector. 3.14.7.2 Serving RT Change: Serving RT Moves to Source AN
3 4 5 6
Figure 3.14.7.2-1 illustrates a call flow where the serving RT changes from an RT belonging to a target AN to an RT belonging to the source AN. For reference, RT 0 belongs to the source AN and RT 1 belongs to target AN 1. Both sectors are in the ATs Active Set.
7 8
Figure 3.14.7.2-1
Serving RT Change: Serving RT Moves to Source AN
9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26
a. The serving RT (in this example, RT 1) belongs to target AN 1. b. Target AN 1 (specifically, RT 1) early detects that the AT has selected another sector as the serving RT. RT 1 indicates this to the source AN by sending an A19-Serving RT Changed message to the AN A19 Control Endpoint ID of the source AN. RT 1 starts timer Tservrtch-19. The A19-Serving RT Changed message contains zero or one instance of the Sector Information IE. The Sector Information IE identifies the sector which the AT has chosen as the serving RT (in this example, RT 0). Note that the Sector Information IE is not included if RT 1 is not certain which sector the AT has chosen as the serving RT). 34 c. Upon receiving the A19-Serving RT Changed message from RT 1, the source AN sends an A19Serving RT Changed Ack message to the RT A19 Control Endpoint ID of RT 1. Upon receiving the A19-Serving RT Changed Ack message, RT 1 stops timer Tservrtch-19. d. If the source AN chooses to perform multicasting, the source AN starts sending A18-FTCH Packet messages to the RT A18 Data Endpoint IDs of all the sectors that are in the ATs Active Set (in this example, the RT A18 Data Endpoint ID of RT 1). This is referred to as multicasting (refer to Annex A for recommended multicasting procedures). Not shown, one of the sectors belonging to the source AN (in this example, RT 0) indicates to the source AN over the proprietary source AN-source RT interface that the AT has chosen it as the serving RT. RT 0 is added to the Candidate Set. The Candidate Serving Set contains two sectors at this time (RT 0 and RT 1). In this scenario, the source
34
For example, there could be a DSC erasure [10].
3-83
3GPP2 A.S0008-C v2.0

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
AN performs multicasting, it sends the A18-FTCH Packet message to the RT Data Endpoint ID of RT 1. At the same time, the source AN sends the same data to RT 0. e. The previous serving RT (in this example, RT 1) determines that another sector has been chosen by the AT as the serving RT. RT 1 indicates this to the source AN by sending an A19-Forward Stopped message to the AN A19 Control Endpoint ID of the source AN. RT 1 starts timer Tservrtch-19. f. Upon receiving the A19-Forward Stopped message from RT 1, the source AN sends an A19-Forward Stopped Ack message to the RT A19 Control Endpoint ID of RT 1. Upon receiving the A19-Forward Stopped Ack message, RT 1 stops timer Tservrtch-19.
g. An RT belonging to the source AN (in this example, RT 0) is now the serving RT. The source AN stops multicasting. h. When the source AN stops multicasting, it sends an A19-Flush message to the RT A19 Control Endpoint IDs of all the sectors in the ATs Active Set except the serving RT. In this example, the source AN sends an A19-Flush message to the RT A19 Control Endpoint ID of RT 1. The source AN starts timer Tflush-19. i. Upon receiving the A19-Flush message from the source AN, RT 1 sends an A19-Flush Ack message to the AN A19 Control Endpoint ID of the source AN. Upon receiving the A19-Flush Ack message, the source AN stops timer Tflush-19. Serving RT Change: Serving RT Remains in Target AN (Different Endpoint ID)
18 19 20 21 22
3.14.7.3
Figure 3.14.7.3-1 illustrates a call flow where the serving RT changes from an RT belonging to a target AN to another sector belonging to the same target AN. Each sector has a different Endpoint ID. For reference, RT 0 belongs to the source AN and RT 1a and RT 1b belong to target AN 1. All three sectors are in the ATs Active Set.
Endpoint ID 1a (for RT1a) Endpoint ID Time 1b (for RT 1b)
Time
Serving sector is RT 1a (belongs to target AN 1) A19-Serving RT Changed (source is RT 1a, new serving sector is RT 1b, LastPacketID = x) Tservrtch-19 A19-Serving RT Changed Ack A18-FTCH Packet (destination is RT 1a, PacketID: x+1 to x+1+w, DTGFirstPacketID = y, DTGTag=t1) A18-FTCH Packet (destination is RT 1b, PacketID: x+1 to x+1+w, DTGFirstPacketID = x+1, DTGTag=t2) A19-Forward Desired (source is RT 1b) A19-Forward Desired Ack A19-Forward Stopped (source is RT 1a) Tservrtch-19 A19-Forward Stopped Ack
b c d e f Tservrtch-19 g h i
Serving sector is RT 1b (belongs to target AN 1)
A19-Flush (destination is RT1a) Tflush-19 A19-Flush Ack

23
k l
3-84
3GPP2 A.S0008-C v2.0

1 2
Figure 3.14.7.3-1
Serving RT Change: Serving RT Remains in Same Target AN (Different Endpoint ID)
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
a. The serving RT (in this example, RT 1a) belongs to target AN 1. b. Target AN 1 (specifically, RT 1a) early detects that the AT has selected another sector as the serving RT. RT 1a indicates this to the source AN by sending an A19-Serving RT Changed message to the AN A19 Control Endpoint ID of the source AN. RT 1a starts timer Tservrtch-19. The A19Serving RT Changed message contains zero or one instance of the Sector Information IE. The Sector Information IE identifies the sector which the AT has chosen as the serving RT (in this example, RT 1b). Note that the Sector Information IE is not included if RT 1a is not certain which sector the AT has chosen as the serving RT). 35 c. Upon receiving the A19-Serving RT Changed message from RT 1a, the source AN sends an A19Serving RT Changed Ack message to the RT A19 Control Endpoint ID of RT 1a. Upon receiving the A19-Serving RT Changed Ack message, RT 1a stops timer Tservrtch-19. d. If the source AN chooses to perform multicasting, the source AN starts sending A18-FTCH Packet messages to the RT A18 Data Endpoint IDs of all the sectors that are in the ATs Active Set (in this example, the RT A18 Data Endpoint IDs of RT 1a and RT 1b). This is referred to as multicasting (refer to Annex A for recommended multicasting procedures). In this scenario, the source AN performs multicasting, it sends the A18-FTCH Packet message to the RT A18 Data Endpoint ID of RT 1a. Step d occurs in parallel with step e. e. The source AN sends the A18-FTCH Packet message to the RT A18 Data Endpoint ID of RT 1b. f. An RT that belongs to target AN 1 (in this example, RT 1b) detects that the AT has chosen it as the serving RT. RT 1b indicates this to the source AN by sending an A19-Forward Desired message to the AN A19 Control Endpoint ID of the source AN. RT 1b starts timer Tservrtch-19. RT 1b is now added to the Candidate Serving Set. The Candidate Serving Set contains two sectors at this time (RT 1a and RT 1b).
g. Upon receiving the A19-Forward Desired message from RT 1b, the source AN sends an A19Forward Desired Ack message to the RT A19 Control Endpoint ID of RT 1b. Upon receiving the A19-Forward Desired Ack message, RT 1b stops timer Tservrtch-19. h. The previous serving RT (in this example, RT 1a) determines that the AT no longer chooses it as the serving RT. RT 1a indicates this to the source AN by sending an A19-Forward Stopped message to the AN A19 Control Endpoint ID of the source AN. RT 1a starts timer Tservrtch-19. i. Upon receiving the A19-Forward Stopped message from RT 1a, the source AN sends an A19Forward Stopped Ack message to the RT A19 Control Endpoint ID of RT 1a. Upon receiving the A19-Forward Stopped Ack message, RT 1a stops timer Tservrtch-19. Another sector belonging to the target AN (in this example, RT 1b) is now the serving RT. The source AN stops multicasting.
j.
k. When the source AN stops multicasting, it sends an A19-Flush message to the RT A19 Control Endpoint IDs of all the sectors in the ATs Active Set except the serving RT. In this example, the source AN sends an A19-Flush message to the RT A19 Control Endpoint ID of RT 1a. The source AN starts timer Tflush-19. l. Upon receiving the A19-Flush message from the source AN, RT 1a sends an A19-Flush Ack message to the AN A19 Control Endpoint ID of the source AN. Upon receiving the A19-Flush Ack message, the source AN stops timer Tflush-19.
35
3-85
3GPP2 A.S0008-C v2.0

1 2 3 4 5
3.14.7.4
Serving RT Change: Serving RT Remains in Same Target AN (Same Endpoint ID)
Figure 3.14.7.4-1 illustrates a call flow where the serving RT changes from an RT belonging to a target AN to another sector belonging to the same target AN. Both sectors have the same Endpoint ID. For reference, RT 0 belongs to the source AN and RT 1a and RT 1b belong to target AN 1. All three sectors are in the ATs Active Set.
Endpoint ID 1 (for RT 1a and RT 1b)
Time
Serving sector is RT 1a (belongs to target AN 1) A19-Serving RT Changed (source is RT 1a, new serving sector is RT 1b, LastPacketID = x) Tservrtch-19 A19-ServingRTChangedAck A18-FTCH Packet (destination is RT 1a, PacketID: x+1 to x+1+w, DTGFirstPacketID = y, DTGTag=t1) A18-FTCH Packet (destination is RT 1b, PacketID: x+1 to x+1+w,DTGFirstPacketID = x+1, DTGTag=t2) A19-Forward Desired (source is RT 1b) Tservrtch-19 A19-Forward Desired Ack A19-Forward Stopped (source is RT 1a) Tservrtch-19 A19-Forward Stopped Ack
b c d e f g h i
A19-Flush (destination is RT 1a) Tflush-19 A19-Flush Ack

6 7 8
k l
Figure 3.14.7.4-1
Serving RT Change: Serving RT Remains in Same Target AN (Same Endpoint ID)
9 10
The description of all the steps in Figure 3.14.7.4-1 is identical to those in Figure 3.14.7.3-1 except for the fact that RT 1a and RT 1b have the same Endpoint ID. 3.14.7.5 Serving RT Change: Serving RT Remains in Same Target AN (Different Endpoint ID), and No Early Detection
11 12 13 14 15 16 17
Figure 3.14.7.5-1 illustrates a call flow where the serving RT changes from an RT belonging to a target AN to another sector belonging to the same target AN. Each sector has a different Endpoint ID. For reference, RT 0 belongs to the source AN and RT 1a and RT 1b belong to target AN 1. This call flow assumes that the current serving RT is unable to early detect serving RT change. All three sectors are in the ATs Active Set.
3-86
3GPP2 A.S0008-C v2.0

Endpoint ID 1a (for RT1a) Endpoint ID Time 1b (for RT 1b)
Time
Serving sector is RT 1a (belongs to target AN 1)
A19-Forward Desired (source is RT 1b) A19-Forward Desired Ack A19-Forward Stopped (source is RT 1a) Tservrtch-19 A19-Forward Stopped Ack
b Tservrtch-19 c d e
A19-Flush (destination is RT1a) Tflush-19 A19-Flush Ack
g h
1 2 3
Figure 3.14.7.5-1
Serving RT Change: Serving RT Remains in Same Target AN (Different Endpoint ID), and No Early Detection
4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26
a. The serving RT (in this example, RT 1a) belongs to target AN 1. b. An RT that belongs to target AN 1 (in this example, RT 1b) detects that the AT has chosen it as the serving RT. RT 1b indicates this to the source AN by sending an A19-Forward Desired message to the AN A19 Control Endpoint ID of the source AN. RT 1b starts timer Tservrtch-19. RT 1b is now added to the Candidate Serving Set. The Candidate Serving Set contains two sectors at this time (RT 1a and RT 1b). c. Upon receiving the A19-Forward Desired message from RT 1b, the source AN sends an A19Forward Desired Ack message to the RT A19 Control Endpoint ID of RT 1b. Upon receiving the A19-Forward Desired Ack message, RT 1b stops timer Tservrtch-19. d. The previous serving RT (in this example, RT 1a) determines that the AT no longer chooses it as the serving RT. RT 1a indicates this to the source AN by sending an A19-Forward Stopped message to the AN A19 Control Endpoint ID of the source AN. RT 1a starts timer Tservrtch-19. e. Upon receiving the A19-Forward Stopped message from RT 1a, the source AN sends an A19Forward Stopped Ack message to the RT A19 Control Endpoint ID of RT 1a. Upon receiving the A19-Forward Stopped Ack message, RT 1a stops timer Tservrtch-19. f. Another sector belonging to the target AN (in this example, RT 1b) is now the serving RT. g. The source AN sends an A19-Flush message to the RT A19 Control Endpoint IDs of all the sectors in the ATs Active Set except the serving RT. In this example, the source AN sends an A19-Flush message to the RT A19 Control Endpoint ID of RT 1a. The source AN starts timer Tflush-19. h. Upon receiving the A19-Flush message from the source AN, RT 1a sends an A19-Flush Ack message to the AN A19 Control Endpoint ID of the source AN. Upon receiving the A19-Flush Ack message, the source AN stops timer Tflush-19.
3-87
3GPP2 A.S0008-C v2.0

1 2 3 4
3-88
3GPP2 A.S0008-C v2.0
1 2 3 4 5 6 7 8 9 10
4 HRPD and 1x IOS Transition Call Flows

This section describes the call flows associated with handoffs between HRPD and 1x systems for MS/ATs. Where the AN and PCF are combined 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. When the BS and the PCF are combined into one entity, refer to [16] for details on A8/A9 messaging. While specific air interface messages may be identified in the HRPD IOS call flows, they are provided only for AN trigger references. Refer to [10] for the definitions and formats of these messages. Note: For simplicity, the 1x and HRPD transition scenarios (sections 4.1 and 4.2) do not show interactions with the MSC. Note: Only the main A10 connection may be handed off between the HRPD system and 1x system.
11 12
4.1
Dormant Cross System Handoff - AT Served by the Same PDSN.
This section describes the call flows for dormant handoffs between HRPD and 1x systems. 4.1.1 1x to HRPD Dormant Packet Data Session Handoff - Existing HRPD Session
13 14 15 16 17 18 19 20 21 22 23
This scenario describes the call flow associated with an MS/AT dormant handoff from an 1x to an HRPD system, when the HRPD system supports unsolicited LocationNotification messages. Refer to [10] or [20]. Based on the MS/AT changing to a different ANID or for other reasons, a dormant handoff from 1x 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, it is assumed that 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 target AN may retrieve the HRPD session information from the source AN over the A13 interface (refer to section 3.7.1).
MS/AT Target AN Target PCF Source BSC/PCF PDSN time
Location Update Procedures A9-Setup-A8 A11-Registration Request (Lifetime, MEI)
a b c
Tregreq
A11-Registration Reply (Lifetime, accept) d
A11-Registration Update
TA8-setup
Tregupd
A11-Registration Acknowledge f
A11-Registration Request (Lifetime=0)
Tregreq
A11-Registration Reply (Lifetime=0, accept) A9-Release-A8 Complete
24 25
h i
Figure 4.1.1-1 1x 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] or [20]. 4-1
26
3GPP2 A.S0008-C v2.0

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22
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. If the target AN successfully retrieved the previous ANID of the MS/AT in step a, the Access Network Identifiers IE is populated with this value and included in this message. c. The target PCF determines a PDSN for this connection. The target PCF sends an A11-Registration Request message to the PDSN. The A11-Registration Request message includes the MEI within the CVSE and the PANID and CANID within the NVSE. The target 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 PCF. The target PCF stops timer Tregreq. e. The PDSN initiates closure of the A10 connection with the source BS/PCF by sending an A11-Registration Update message. The PDSN starts timer Tregupd. f. The source BS/PCF responds with an A11-Registration Acknowledge message. The PDSN stops timer Tregupd.
g. The source BS/PCF sends an A11-Registration Request message with Lifetime set to zero, to the PDSN. The source BS/PCF starts timer Tregreq. h. The PDSN sends an A11-Registration Reply message to the source BS/PCF. The source BS/PCF closes the A10 connection for the MS/AT and stops timer Tregreq. i. The target PCF responds to the target AN with an A9-Release-A8 Complete message. The target AN stops timer TA8-setup. Note that this step can occur any time after step d. 1x to HRPD Dormant Packet Data Session Handoff - New HRPD Session
23 24 25 26 27
4.1.2
This scenario describes the call flow associated with an MS/AT dormant handoff from an 1x to an 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 1x to HRPD is determined to be required when the dormant MS/AT transitions from 1x to HRPD.
4-2
3GPP2 A.S0008-C v2.0

MS/ AT Session Establishment Target AN/PCF Source BSC/PCF Target AN AAA PDSN time a
c d A12 Access-Request A12 Access-Accept e f g
CHAP Challenge - Response
CHAP - Authentication Success Location Update Procedures
AT Ready to Exchange Data on Service Stream A11-Registration Request (Lifetime, MEI)
i j k l
Tregreq
Tregupd
A11-Registration Acknowledge A11-Registration Request (Lifetime=0) A11-Registration Reply (Lifetime=0, accept)
1 2
m n o
Tregreq
Figure 4.1.2-1 1x to HRPD Dormant Packet Data Session Handoff - New HRPD Session a. The AT and the target AN initiate HRPD session establishment. During this procedure, the target 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 target AN. Refer to [10], 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 target AN is in the open state). c. After HRPD session configuration the MS/AT initiates PPP and LCP negotiations for access authentication. Refer to [26]. d. The target AN/PCF generates a random challenge and sends it to the MS/AT in a CHAP Challenge message in accordance with [29]. 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 target AN-AAA which acts as a RADIUS server in accordance with [31]. f. 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 [29] and [31]), the target AN-AAA sends an Access-Accept message on the A12 interface in accordance with [31] (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. Note that in this scenario the MN ID is the same as the ATs IMSI. Refer to section 2.4.2, AN-AAA Support. 4-3
3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22
3GPP2 A.S0008-C v2.0

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24
g. The target AN/PCF returns an indication of CHAP access authentication success to the MS/AT. Refer to [29]. 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. i. j. 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). The target AN/PCF sends an A11-Registration Request message to the PDSN. The A11-Registration Request message includes the MEI within the CVSE and the PANID and the CANID within the NVSE. If PANID is not sent in step h, the target AN/PCF sets the PANID field to zero and the CANID field to its own ANID. The target AN/PCF starts timer Tregreq.
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. l. The PDSN initiates closure of the A10 connection with the source BS/PCF by sending an A11-Registration Update message. The PDSN starts timer Tregupd.
m. The source BS/PCF responds with an A11-Registration Acknowledge message. The PDSN stops timer Tregupd. n. The source BS/PCF sends an A11-Registration Request message with Lifetime set to zero, to the PDSN. The source BS/PCF starts timer Tregreq. o. The PDSN sends an A11-Registration Reply message to the source BS/PCF. The source BS/PCF closes the A10 connection for the MS/AT and stops timer Tregreq. 4.1.3 HRPD to 1x Dormant Packet Data Session Handoff
25 26 27 28 29
This scenario describes the call flow associated with an MS/AT dormant handoff from an HRPD to a 1x system. Based on the MS/AT changing to a different ANID or for other reasons, a dormant handoff from HRPD to 1x 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.
4-4
3GPP2 A.S0008-C v2.0

MS/AT Target BSC/PCF Source AN/PCF PDSN time a
Origination (DRS='0')
BS Ack Order A11-Registration Request (Lifetime, MEI)
c d
Tregreq
A11-Registration Reply (Lifetime, accept)
Tregupd
A11-Registration Acknowledge f
A11-Registration Request (Lifetime=0)
g h
Tregreq
A11-Registration Reply (Lifetime=0, accept)
1 2
Figure 4.1.3-1 HRPD to 1x Dormant Packet Data Session Handoff a. Upon transitioning to the 1x 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 BS/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 BS/PCF sends to the PDSN. b. The target BS/PCF acknowledges receipt of the Origination Message with a Base Station Acknowledgment Order to the MS/AT. c. The target BS/PCF sends an A11-Registration Request message to the PDSN. The A11-Registration Request message includes the MEI within the CVSE and the PANID and the CANID within the NVSE. The target BS/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 BS/PCF. The target BS/ PCF stops timer Tregreq. If the PDSN responds to the target BS/PCF with the Data Available Indicator, the target BS/PCF establishes a traffic channel. 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. f. The source AN/PCF responds with an A11-Registration Acknowledge message. The PDSN stops timer Tregupd.
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
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.
4-5
3GPP2 A.S0008-C v2.0

1 2 3 4 5 6
4.2
MS/AT Terminated Voice Call During Active HRPD Packet Data Session
This section describes the call flows associated with an MS/AT terminated 1x voice call during an active HRPD packet data session when there is no connection between the HRPD and 1x systems. The call flows in this section assume that the MS/AT periodically retunes to the 1x system to check for pages while it is monitoring the HRPD system. For call flows using the A1/A1p interface and CSNA, refer to sections 4.5 and 4.6. 4.2.1 MS/AT Terminated Voice Call During Active HRPD Packet Data Session (IntraPDSN/Inter-PCF)
7 8 9 10 11
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 may transition to the 1x system as a concurrent call service if the 1x system has this capability and the MS/AT selects this capability.
MS/ AT 1x BS PCF1 AN HRPD PCF2 PDSN time
Active HRPD Packet Data Session Page MS/AT stops transmitting to the AN X A9-Release-A8 (Cause: Air link lost) a b c A11-Registration Request A11-Registration Reply d e f g h i j* A9-Setup-A8 k* A11-Registration Request (Lifetime, MEI) A11-Registration Reply (Lifetime, accept) l* m * n* Active 1x Packet Data Session Connect Order A11-Registration Update o* p q*
Trel9
Tregreq
A9-Release-A8 Complete Page Response TCH setup Alert with Info

Origination for concurrent service
TA8-setup
Tregreq
A9-Connect-A8
Tregup
A11-Registration Ack r* s* A11-Registration Request (Lifetime=0) A11-Registration Reply (Lifetime=0, accept) * = conditional
12 13
Tregreq
t*
Figure 4.2.1-1 Voice Call Termination During Active HRPD Packet Data Session (Inter-PCF) a. The BS sends a Page Message containing the MS/AT address over the paging channel. If the user elects to continue the HRPD session, then the MS/AT takes no further action, and the remaining steps are not performed. b. The MS/AT stops transmitting to the AN. The AN determines that it is not receiving any transmissions from the MS/AT and considers the connection to be lost at this point.
14 15 16 17 18
4-6
3GPP2 A.S0008-C v2.0

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
c. The AN sends an A9-Release-A8 message with cause value indicating Air link lost, to PCF2 and starts timer Trel9. The AN may send an A9-AL Disconnected message to PCF2 (refer to section 3.8.1) before it determines that a connection has been lost. d. PCF2 sends an A11-Registration Request message containing an Active Stop accounting record to the PDSN and starts timer Tregreq. e. The PDSN sends an A11-Registration Reply message to PCF2. PCF2 stops timer Tregreq upon receipt of this message. f. PCF2 sends an A9-Release-A8 Complete message to the AN. The AN stops timer Trel9. g. The MS/AT sends a Page Response message to the BS. This step can occur any time after step b. h. The BS establishes a traffic channel. i. j. The BS sends an Alert with Info message to instruct the MS/AT to ring. If the 1x system supports concurrent services and the MS/AT selects to transition the packet data session to the 1x system, the MS/AT and the 1x system set up the packet data session as a concurrent service. Refer to [13], Section 3.18.1.1. Otherwise the call flow ends here.
k. The BS sends an A9-Setup-A8 message to PCF1 to establish the 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 Data Ready Indicator to 0. l. PCF1 sends an A11-Registration Request message to the PDSN to establish the A10 connection. PCF1 starts timer Tregreq.
m. 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. n. PCF1 sends an A9-Connect-A8 message after the completion of the A10 connection setup. The BS stops timer TA8-setup. o. At this point, the packet data session is successfully transitioned from the HRPD to the 1x system. p. The MS/AT sends a Connect Order message when the call is answered at the MS/AT. This step can occur any time after step i. q. The PDSN Initiates closure of the A10 connection with PCF2 by sending an A11-Registration Update message. The PDSN starts timer Tregupd. This step may occur immediately after step l. r. s. t. PCF2 responds with an A11-Registration Acknowledge message. The PDSN stops timer Tregupd. PCF2 sends an A11-Registration Request message with Lifetime set to zero, to the PDSN. PCF2 starts timer Tregreq. The PDSN sends an A11-Registration Reply message to PCF2. PCF2 closes the A10 connection for the MS/AT and stops timer Tregreq. MS/AT Terminated Voice Call During Active HRPD Packet Data Session (Intra-PCF)
34 35 36 37
4.2.2
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 transitioned to the 1x system as a concurrent call service if the 1x system has this capability and the MS/AT selects this capability.
4-7
3GPP2 A.S0008-C v2.0

MS/ AT 1x BS AN HRPD PCF PDSN time Active HRPD Packet Data Session Page MS/AT stops transmitting to the AN X A9-Release-A8 (Cause: Air link lost) a b c
Trel9
Tregreq
A11-Registration Request A11 Registration Reply
d e f g h i j
Page Response TCH Setup Alert with Info Origination for Concurrent Service A9-Setup-A8
TA8-setup
A9-Connect-A8
Tregreq
l m n o
Active 1x Packet Data Session
Connect Order
1 2
Figure 4.2.2-1 Voice Call Termination During Active HRPD Packet Data Session (Intra-PCF) a. The BS sends a Page Message containing the MS/AT address over the paging channel. If the user elects to continue the HRPD session, then the MS/AT takes no further action, and the remaining steps are not performed. b. The MS/AT stops transmitting to the AN. The AN determines that it is not receiving any transmissions from the MS/AT and considers the connection to be lost at this point. The AN may send an A9-AL Disconnected message to the PCF (refer to section 3.8.1) before it determines that a connection has been lost. c. The AN sends an A9-Release-A8 message with cause value indicating Air link lost, to the PCF and starts timer Trel9. d. The PCF sends an A11-Registration Request message containing an Active Stop accounting record to the PDSN and starts timer Tregreq. e. The PDSN sends an A11-Registration Reply message to the PCF. The PCF stops the timer Tregreq upon receipt of the message. f. 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.
3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
g. The MS/AT sends a Page Response message to the BS. This step can occur any time after step b. h. The BS establishes a traffic channel. i. j. The BS sends an Alert with Info message to instruct the MS/AT to ring. The MS/AT and 1x system set up the packet data session as a concurrent service if the MS/AT supports concurrent services and selects to transition the packet data session to the 1x system. Refer to [13], Section 2.17.2.1 steps (a) to step (g).
4-8
3GPP2 A.S0008-C v2.0

1 2 3 4 5 6 7 8 9 10 11 12 13
k. The BS sends an A9-Setup-A8 message to the PCF to establish the A8 connection and starts timer TA8-setup. 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 Data Ready Indicator to 0. l. The PCF sends an A11-Registration Request message containing an Active Start accounting record to the PDSN and starts timer Tregreq.
m. The PDSN sends an A11-Registration Reply message to the PCF. The PCF stops the timer Tregreq upon receipt of the message. n. The PCF sends an A9-Connect-A8 message to the BS. The BS stops timer TA8-setup. o. At this point, the packet data session has successfully transitioned from the HRPD system to the 1x system. p. The MS/AT sends a Connect Order message when the call is answered at the MS/AT. This step can occur any time after step i.
4-9
3GPP2 A.S0008-C v2.0
1 2 3 4 5 6 7 8 9 10 11 12
4.3
1x to HRPD Active Packet Data Session Handoff
This section describes the call flow associated with an MS/AT AN change from an 1x to an HRPD system. The MS/AT determines that an AN change from 1x 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 1x packet data session occurs via the dormant state. The transition from 1x active to dormant may occur, e.g., according to [13] 3.17.4.3, MS Initiated Call Release to Dormant State. The dormant handoff from 1x to HRPD occurs according to section 4.1.1 or 4.1.2 (1x 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).
4-10
3GPP2 A.S0008-C v2.0
1 2
4.4
Status Management Supported by Feature Invocation
This scenario describes the call flow associated with status management using feature invocation.
MS/AT Origination (Feature Code)
BS
1x
MSC
HRPD
AN
time a
Mobile Originating Call Setup
b c
MSC Initiated Call Clearing Mobile Initiated HRPD Connection Setup
Mobile Initiated HRPD Connection Release
Origination (Feature Code) Mobile Originating Call Setup
f g
MSC Initiated Call Clearing
3 4
Figure 4.4-1
Terminal Based Status Management (Using Feature Invocation)
5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
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 set up the call. Refer to [13], Section 3.1.1, Mobile Origination. c. The BS and the MSC clear the call. Refer to [13], Section 3.2.4.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 Reactivation from Dormant State (Existing HRPD Session). 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 (A8 Connections do not Exist). f. 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.
g. The BS and the MSC set up the call. Refer to [13], Section 3.1.1, Mobile Origination. h. The BS and the MSC clear the call. Refer to [13], Section 3.2.4.3, Call Clear Initiated by MSC.
4-11
3GPP2 A.S0008-C v2.0
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
4.5
CSNA in the HRPD System
This section describes the call flows associated with the MS/AT: sending a MO SMS message via the 1x MSC while in an HRPD system, receiving a MT SMS message from the 1x MSC while in an HRPD system, receiving a 1x page while in an HRPD system or receiving an HRPD page while in a 1x system. The call flows in this section and section 4.6 use the A1/A1p interface to tunnel certain 1x messages between the IWS and the 1x MSC in support of CSNA. Certain call flows in this section and section 4.6 also use the A21 interface to tunnel certain 1x messages between the HRPD AN and an IWS-1xBS or standalone IWS. Call flows are also provided that describe facilities for the 1x RAN and the HRPD RAN to communicate with each other to indicate which RAN the MS/AT is monitoring. The CSNA functionality addresses operation of an MS/AT that otherwise would have to periodically retune to the 1x system to check for pages while it is monitoring the HRPD system. For CSNA, the AT and the AN configure a filtering mechanism to allow notifications associated with certain services to be tunneled between 1x and HRPD systems. CSNA also ensures that the AT may stay registered in the 1x core circuit network even when it is monitoring the HRPD system. For call flows showing voice call delivery during an active HRPD session without CSNA, refer to section 4.2. In this section, HRPD: denotes a message sent using the HRPD air interface and frequency while 1x: denotes a message sent using the 1x air interface and frequency. Refer to [9] and [19]. It is necessary that the MS/AT receive the 3G1XParameters information prior to sending or receiving any 1x air interface messages over CSNA. Such messages require that the MS/AT know the P_Rev level of the IWS, so that they may be formatted properly. Some of the scenarios in this section explicitly show the delivery of the 3G1XParameters information to the MS/AT. When this is not shown, it is important to remember this basic requirement. Note: The HRPD AN only tunnels 1x messages to the MS/AT in the HRPD system if the Idle Tunnel timer is active. For the call flows in this section and section 4.6, where the MS/AT is registered in and monitoring the HRPD system, it is assumed that the Idle Tunnel timer is active. The MS/AT receiving an HRPD service option while in the 1x system is supported in this specification. Refer to [19]. 4.5.1 SMS Mobile Originated Point-to-Point (ADDS Transfer)
30 31 32
This section contains call flows that describe the delivery of mobile originated SMS messages being delivered to the 1x MSC while the MS/AT is in the HRPD system. 4.5.1.1 SMS Mobile Originated Point-to-Point (ADDS Transfer) IWS-AN
33 34 35 36
This scenario describes the call flow for delivery of unicast Short Message Service (SMS) sent from an MS/AT over the HRPD air interface using the IWS-AN function. The MS/AT is registered in and monitoring the HRPD system when the SMS message is sent.
MS/AT HRPD AN/ IWS-AN HRPD: data burst message HRPD: ack ADDS Transfer MSC time
a b conditional c
37 38
Figure 4.5.1.1-1
Mobile Originated Point-to-Point SMS in an HRPD System IWS-AN 4-12
3GPP2 A.S0008-C v2.0

1 2 3 4 5
a. The MS/AT sends a short message contained within a 1x Data Burst Message to the HRPD AN. b. If an acknowledgement was solicited, the HRPD AN acknowledges the receipt of the 1x data burst message. c. The IWS-AN sends an ADDS Transfer message to the MSC.
6 7 8 9
4.5.1.2
SMS Mobile Originated Point-to-Point (ADDS Transfer) IWS-1xBS
This scenario describes the call flow for delivery of unicast Short Message Service (SMS) sent from an MS/AT over the HRPD air interface using the IWS-1xBS function. The MS/AT is registered in and monitoring the HRPD system when the SMS message is sent.
MS/AT HRPD AN HRPD: data burst m essage HRPD: ack IW S-1xBS MSC time
a A21-1x Air Interface Signaling [data burst message] A21-Ack ADDS Transfer b conditional c d e
T ack-21
10 11
Figure 4.5.1.2-1
Mobile Originated Point-to-Point SMS in an HRPD System IWS-1xBS
12 13 14 15 16 17 18 19 20
a. The MS/AT sends a short message contained within a 1x Data Burst Message (DBM) to the HRPD AN. b. If an acknowledgement was solicited, the HRPD AN acknowledges the receipt of the data burst message. c. The HRPD AN sends an A21-1x Air Interface Signaling message to the IWS-1xBS that contains the data burst message containing the short message. The HRPD AN starts timer Tack-21. d. The IWS-1xBS acknowledges the message with an A21-Ack message. The HRPD AN stops timer Tack-21. e. The 1x BS sends an ADDS Transfer message to the MSC containing the short message. 4.5.2 SMS Mobile Terminated Point-to-Point (ADDS Page / ADDS Page Ack)
21 22 23
This section contains call flows that describe the delivery of mobile terminated SMS messages being delivered to the MS/AT while the MS/AT is in the HRPD system. 4.5.2.1 SMS Mobile Terminated Point-to-Point (ADDS Page / ADDS Page Ack) without A13 Procedure IWS-AN
24 25 26 27 28
This scenario describes the call flow for delivery of unicast SMS to an MS/AT over the HRPD air interface using the IWS-AN function. The MS/AT is registered in and monitoring the HRPD system when the SMS message arrives at the MSC, destined for the MS/AT.
4-13
3GPP2 A.S0008-C v2.0

M S /A T HRPD AN/ IW S -A N A D DS Page H R P D : d a ta b u rs t m e s s a g e HR PD: ack AD D S Page Ack
1 2 3
MSC
tim e a b c d co n d itio n a l co n d itio n a l
T 3113
Figure 4.5.2.1-1
Mobile Terminated Point-to-Point SMS without A13 Procedure in an HRPD System IWS-AN
4 5 6 7 8 9 10 11 12 13 14 15
a. The MSC determines that a point-to-point short message is to be sent to an MS/AT. The MSC sends an ADDS Page message to the IWS-AN. The ADDS Page message contains the short message in its ADDS User Part IE. If the MSC requires an acknowledgement, it includes the Tag IE in the ADDS Page message and starts timer T3113. b. The HRPD AN sends a 1x Data Burst Message containing the short message to the MS/AT via CSNA. Before sending the short message, the HRPD AN may perform vendor specific procedures such as paging the MS/AT to determine the cell in which the MS/AT is located. If an ack was requested by the MSC, the HRPD AN requests an ack from the MS/AT. c. If an acknowledgement was solicited, the MS/AT acknowledges the receipt of the message. d. If the MSC requested an acknowledgment by including the Tag IE in the ADDS Page message, the IWS-AN replies with an ADDS Page Ack message including the Tag IE set identical to the value sent by the MSC. If timer T3113 was previously started, it is now stopped. 4.5.2.2 SMS Mobile Terminated Point-to-Point (ADDS Page / ADDS Page Ack) without A13 Procedure IWS-1xBS
16 17 18 19 20 21 22 23 24
This scenario describes the call flow for delivery of unicast SMS to an MS/AT over the HRPD air interface using the IWS-1xBS function. The MS/AT is registered in and monitoring the HRPD system when the SMS message arrives at the MSC, destined for the MS/AT. It is assumed that prior to step a, the MSC will have knowledge that the MS/AT can be paged via the 1x BS. It is further assumed that the IWS-1xBS will have knowledge that the MS/AT can be reached across the A21 interface to the HRPD AN. This may have occurred, for example, through a successful 1x registration by the MS/AT via CSNA.
MS/AT HRPD AN IWS-1xBS ADDS Page A21:1x Air Interface Signaling HRPD: data burst message HRPD: ack A21-Ack ADDS Page Ack MSC time a b
Tack-21
T3113
c d e f conditional conditional
25 26 27
Figure 4.5.2.2-1
Mobile Terminated Point-to-Point SMS without A13 Procedure in an HRPD System IWS-1xBS 4-14
3GPP2 A.S0008-C v2.0

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
a. The MSC determines that a point-to-point short message is to be sent to an MS/AT. The MSC sends an ADDS Page message to the 1x BS. The ADDS Page message contains the short message in its ADDS User Part information element (IE). If the MSC requires an acknowledgement, it includes the Tag IE in the ADDS Page message and starts timer T3113. b. The IWS-1xBS sends the SMS as a 1x Data Burst Message in an A21-Air Interface Signaling message. The IWS-1xBS starts timer Tack-21. c. The HRPD AN sends the Data Burst Message to the MS/AT. Before sending the Data Burst Message, the HRPD AN may perform vendor specific procedures such as paging the MS/AT to determine the cell in which the MS/AT is located. d. If an acknowledgement was solicited, the MS/AT acknowledges the receipt of the message. e. The HRPD AN sends an A21-Ack message to the IWS-1xBS. The IWS-1xBS stops timer Tack-21. This step occurs immediately after step b if an acknowledgement was not requested by the MSC. f. If the MSC requested an acknowledgment by including the Tag IE in the ADDS Page message, the 1x BS replies with an ADDS Page Ack message including the Tag IE set identical to the value sent by the MSC. If timer T3113 was previously started, it is now stopped. SMS Mobile Terminated Point-to-Point (ADDS Page / ADDS Page Ack) with A13 Procedure IWS-AN
16 17 18 19 20 21 22
4.5.2.3
This scenario describes the call flow for delivery of unicast SMS to an MS/AT over the HRPD air interface using the IWS-AN function. The AT registers at a border sector such that the paging area covers an RT belonging to the target AN. This may be due to distance-based paging or subnet hysteresis using secondary colorcode. The AT subsequently becomes dormant. The MS/AT is monitoring the HRPD system when the SMS message arrives at the MSC, destined for the MS/AT.
time a b
Tpreq-13
c d e Session Transfer Connection Establishment
T3113
f g h i j conditional conditional conditional conditional
Tpreq-13
k l
23 24 25
Figure 4.5.2.3-1
Mobile Terminated Point-to-Point SMS with A13 Procedure in an HRPD System IWS-AN
26 27
a. The MSC determines that a point-to-point short message is to be sent to an MS/AT. The MSC sends an ADDS Page message to the IWS-AN. The ADDS Page message contains the short message in its 4-15
3GPP2 A.S0008-C v2.0

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
ADDS User Part information element (IE). If the MSC requires an acknowledgement, it includes the Tag IE in the ADDS Page message and starts timer T3113. b. The source AN determines that it needs to page the AT through some RTs in the source AN and some RTs in the target AN. The source AN sends an A13-Paging Request message to target AN1 and starts timer Tpreq-13. The A13-Paging Request message includes the data burst message that is to be sent over the air via CSNA. c. The target AN sends an A13-Paging Request Ack message back to the source AN. Upon receipt of the A13-Paging Request Ack message, the source AN stops the corresponding timer Tpreq-13. d. The source AN, the target AN transmit the page to the AT over the control channel. This call flow assumes that the AT receives the page from the target AN. e. AT send ConnectionRequest message to target AN. f. The target AN perform session transfer (refer to section 3.7). g. The AN and the AT establish the connection. h. The HRPD target AN sends a 1x Data Burst Message containing the short message to the MS/AT via CSNA. Before sending the short message, the HRPD AN may perform vendor specific procedures such as paging the MS/AT to determine the cell in which the MS/AT is located. If an ack was requested by the MSC, the HRPD AN requests an ack from the MS/AT. i. j. If an acknowledgement was solicited, the MS/AT acknowledges the receipt of the message. The target AN sends an A13-Paging Delivered message to the source AN, and starts timer Tpreq-13.
k. The source AN sends an A13-Paging Delivered Ack message back to the target AN. Upon receipt of the A13-Paging Delivered Ack message, the target AN stops the corresponding timer Tpreq-13. l. If the MSC requested an acknowledgment by including the Tag IE in the ADDS Page message, the IWS-AN replies with an ADDS Page Ack message including the Tag IE set identical to the value sent by the MSC. If timer T3113 was previously started, it is now stopped.
26 27 28 29 30 31 32 33 34 35 36
4.5.2.4
SMS Mobile Terminated Point-to-Point (ADDS Page / ADDS Page Ack) with A13 Procedure IWS-1xBS
This scenario describes the call flow for delivery of unicast SMS to an MS/AT over the HRPD air interface using the IWS-1xBS function. The AT registers at a border sector such that the paging area covers an RT belonging to the target AN. This may be due to distance-based paging or subnet hysteresis using secondary colorcode. The AT subsequently becomes dormant. The MS/AT is monitoring the HRPD system when the SMS message arrives at the MSC, destined for the MS/AT. It is assumed that prior to step a, the MSC will have knowledge that the MS/AT can be paged via the 1x BS. It is further assumed that the IWS-1xBS will have knowledge that the MS/AT can be reached across the A21 interface to the HRPD AN. This may have occurred, for example, through a successful 1x registration by the MS/AT via CSNA.
4-16
3GPP2 A.S0008-C v2.0

time a b c
Tpreq-13
d e f
Session Transfer Connection Establishment
Tack-21
T3113
h i j k conditional conditional conditional conditional conditional
Tpreq-13
l m n
1 2 3
Figure 4.5.2.4-1
Mobile Terminated Point-to-Point SMS with A13 Procedure in an HRPD System IWS-1xBS
4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24
a. The MSC determines that a point-to-point short message is to be sent to an MS/AT. The MSC sends an ADDS Page message to the 1x BS. The ADDS Page message contains the short message in its ADDS User Part information element (IE). If the MSC requires an acknowledgement, it includes the Tag IE in the ADDS Page message and starts timer T3113. b. The IWS-1xBS sends the SMS as a 1x Data Burst Message in an A21-Air Interface Signaling message. The IWS-1xBS starts timer Tack-21. c. The source AN determines that it needs to page the AT through some RTs in the source AN and some RTs in the target AN. The source AN sends an A13-Paging Request message to target AN1 and starts timer Tpreq-13. The A13-Paging Request message includes the data burst message that is to be sent over the air via CSNA. d. The target AN sends an A13-Paging Request Ack message back to the source AN. Upon receipt of the A13-Paging Request Ack message, the source AN stops the corresponding timer Tpreq-13. e. The source AN, the target AN transmit the page to the AT over the control channel. This call flow assumes that the AT receives the page from the target AN. f. AT send ConnectionRequest message to target AN. g. The target AN perform session transfer. h. The AN and the AT establish the connection. i. The HRPD AN sends the Data Burst Message to the MS/AT. Before sending the Data Burst Message, the HRPD AN may perform vendor specific procedures such as paging the MS/AT to determine the cell in which the MS/AT is located. The MS/AT acknowledges the receipt of the message if the acknowledge is required in step i. 4-17
j.
3GPP2 A.S0008-C v2.0

1 2 3 4 5 6 7 8 9
k. The target AN sends an A13-Paging Delivered message to the source AN, and starts timer Tpreq-13. l. The source AN sends an A13-Paging Delivered Ack message back to the target AN. Upon receipt of the A13-Paging Delivered Ack message, the target AN stops the corresponding timer Tpreq-13.
m. The HRPD AN sends an A21-Ack message to the IWS-1xBS. The IWS-1xBS stops timer Tack-21. This step occurs immediately after step b if the acknowledge is not required by the IWS-1xBS. n. If the MSC requested an acknowledgment by including the Tag IE in the ADDS Page message, the 1x BS replies with an ADDS Page Ack message including the Tag IE set identical to the value sent by the MSC. If timer T3113 was previously started, it is now stopped.
10 11 12
4.5.3
1x Page Delivery to the MS/AT in an HRPD System (Paging Request)
This section contains call flows that describe the delivery of 1x pages to the MS/AT while the MS/AT is in an HRPD system. 4.5.3.1 1x Page Delivery to the MS/AT in an HRPD System (Paging Request) without A13 Procedure IWS-AN Successful Operation
13 14 15 16 17 18
This scenario describes the call flow associated with an MS/AT 1x call termination, paging and service option notification over the HRPD air interface. The MS/AT is registered in and monitoring the HRPD system when the call arrives at the MSC, destined for the MS/AT. This scenario uses the IWS-AN function.
MS/AT HRPD AN/ IWS-AN 1x BS Paging Request Paging Request HRPD: 3G1XServices packet (GPM+FN) 1x: Page Response Message Complete L3 Info: Paging Response 1x MT Call Setup Proceeds MSC time a b
T3113 T3113
c d
Event Notification Event Notification Ack

19 20 21
Tevent
f g
optional conditional
Figure 4.5.3.1-1
1x Page Delivery to the MS/AT in an HRPD System without A13 Procedure IWS-AN
22 23 24 25 26 27 28 29 30 31 32
a. The MSC determines that an incoming call terminates to an MS/AT within its serving region. The MSC sends a Paging Request message to the IWS-AN and one or more 1x BSs reachable by an MS/AT within the HRPD ANs paging area. The MSC may optionally include calling party information in this message. The MSC starts an instance of timer T3113 for each Paging Request message sent. Note that the Paging Request message may contain a Virtual Page Indicator (VPI) identifying that the 1x BS shall prepare to receive a Page Response Message from the MS/AT. b. The HRPD AN sends a General Page Message to the MS/AT. If the MSC included calling party information in step a, the HRPD AN includes a Feature Notification Message containing the calling party information in the same HRPD message. c. The MS/AT tunes to the 1x system and acknowledges the page by transmitting a Page Response Message over the 1x Access Channel.
4-18
3GPP2 A.S0008-C v2.0

1 2 3 4 5 6 7 8 9 10 11 12
d. The 1x BS constructs the Paging Response message, places it in the Complete Layer 3 Information message, and sends the message to the MSC. If the Paging Request message contained a Tag IE, the 1x BS includes this IE in the Paging Response message. The MS/AT is implicitly registered in the 1x system. Refer to [13] for completion of the MS call termination in the 1x system. The MSC stops all instances of timer T3113 for this MS/AT. e. The 1x BS/MSC continues with MT call setup procedures. Refer to [13] for completion of the MS call termination in the 1x system. f. The MSC may determine that the MS/AT, which has subscribed to Cross Notification services, has registered with the 1x system, send an Event Notification message to the IWS-AN containing the registration event, and start timer Tevent. This step can occur anytime after step d.
g. The HRPD AN replies with an Event Notification Ack message. The MSC stops timer Tevent.
13 14 15 16 17 18
4.5.3.2
1x Page Delivery to the MS/AT in an HRPD System (Paging Request) without A13 Procedure IWS-1xBS Successful Operation
This scenario describes the call flow associated with an MS/AT 1x call termination, paging and service option notification over the HRPD air interface. The MS/AT is registered in and monitoring the HRPD system when the call arrives at the MSC, destined for the MS/AT. This scenario uses the IWS-1xBS function.
MS/AT HRPD AN IWS-1xBS Paging Request A21-1x Air Interface Signaling (GPM) MSC time a b
HRPD: 3G1XServices packet (GPM) HRPD: 3G1XServicesAck
Tack-21 T3113
A21-Ack
c d e f Complete L3 Info: Paging Response g h i j
1x: Page Response Message
1x MT Call Setup Proceeds A21-Event Notification A21-Ack

19 20 21
Tack-21
Figure 4.5.3.2-1
1x Page Delivery to the MS/AT in an HRPD System without A13 Procedure IWS-1xBS
22 23 24 25 26 27 28
a. The MSC determines that an incoming call terminates to an MS/AT within its serving region. The MSC sends a Paging Request message to the 1x BS. The MSC starts timer T3113. b. The IWS-1xBS sends an A21-1x Air Interface Signaling message containing a 1x paging message to the HRPD AN and starts timer Tack-21. The IWS-1xBS ensures that resources are available to support the 1x call prior to requesting the HRPD AN to page the MS/AT. c. The HRPD AN sends the 1x paging message to the MS/AT d. The MS/AT acknowledges receipt of the 1x paging message.
4-19
3GPP2 A.S0008-C v2.0

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
e. The HRPD AN acknowledges receipt of the A21 message by sending an A21-Ack to the IWS-1xBS. The IWS-1xBS stops timer Tack-21. If the MS/AT was not found at the HRPD AN, the HRPD AN sends an A21-Ack message with the Cause field set to Unknown MS/AT to the IWS-1xBS to indicate this result and the call flow ends. f. The MS/AT tunes to the 1x system and acknowledges the page by transmitting a Page Response message over the 1x Access Channel.
g. The 1x BS constructs the Paging Response message, places it in the Complete Layer 3 Information message, and sends the message to the MSC. If the Paging Request message contained a Tag IE, the 1x BS includes this IE in the Paging Response message. The MS/AT is implicitly registered in the 1x system. The MSC stops all instances of timer T3113 for this MS/AT. h. The 1x BS/MSC continues with MT call setup procedures. Refer to [13] for completion of the MS call termination in the 1x system. i. j. The IWS-1xBS sends an A21-Event Notification message to the HRPD AN to inform it that the MS/AT is now receiving services from the 1x network. The IWS-1xBS starts timer Tack-21. The HRPD AN sends an A21-Ack message to the IWS-1xBS. The IWS-1xBS stops timer Tack-21.
17 18 19 20 21 22 23 24 25 26
4.5.3.3
1x Page Delivery to the MS/AT in an HRPD System (Paging Request) from Multiple IWS-1xBSs Successful Operation
This scenario describes the call flow associated with an MS/AT 1x call termination, paging and service option notification over the HRPD air interface. The MS/AT is registered in and monitoring the HRPD system when the call arrives at the MSC, destined for the MS/AT. This scenario uses the IWS-1xBS function. Multiple IWS-1xBSs attempt to have the AN page the MS/AT. Only the first such request is accepted. All other IWS-1xBSs are informed that paging activity is already underway. It is assumed that the 1x MSC will not have multiple distinct paging activities running concurrently for the same mobile. It is also assumed that the 1x system has previously sent the 1x overhead parameter values to the HRPD AN.
4-20
3GPP2 A.S0008-C v2.0

MS/AT HRPD AN IWS-1xBS 1 IWS-1xBS 2 IWS-1xBS 3 MSC
time a b
Paging Request A21-1x Air Interface Signaling (GPM) Paging Request A21-1x Air Interface Signaling (GPM) A21-Ack (Already Paging) Paging Request A21-1x Air Interface Signaling (GPM)
c d
Tack-21
e f g
Tack-21
A21-Ack (Already Paging) HRPD: 3G1XParameters HRPD: Ack HRPD: 3G1XServices packet (GPM) HRPD: 3G1XServicesAck A21-Ack 1x: Page Response Message
Tack-21
h T3113
T3113
i j
T3113
k l m n Complete L3 Info: Paging Response 1x MT Call Setup Proceeds A21-Event Notification A21-Ack o p q
Tack-21
r
1 2 3
Figure 4.5.3.3-1
1x Page Delivery to the MS/AT in an HRPD System (Paging Request) from Multiple IWS-1xBSs
4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
a. The MSC determines that an incoming call terminates to an MS/AT within its serving region. The MSC sends a Paging Request message to 1x BS 1. The MSC starts timer T3113. b. IWS-1xBS 1 sends an A21-1x Air Interface Signaling message containing a 1x paging message to the HRPD AN and starts timer Tack-21. IWS-1xBS 1 ensures that resources are available to support the 1x call prior to requesting the HRPD AN to page the MS/AT. The A21-1x Air Interface Signaling message contains and indication that this is a paging message. The HRPD AN queues the 1x message to await the slot cycle for the MS/AT. c. The MSC sends a Paging Request message to 1x BS 2. The MSC starts another instance of timer T3113. d. The IWS-1xBS 2 sends an A21-1x Air Interface Signaling message containing a 1x paging message to the HRPD AN and starts timer Tack-21. IWS-1xBS 2 ensures that resources are available to support the 1x call prior to requesting the HRPD AN to page the MS/AT. The A21-1x Air Interface Signaling message contains an indication that this is a paging message. e. When the HRPD AN receives the A21-1x Air Interface Signaling message from IWS-1xBS 2, it notes that this is a 1x paging message and that it already has a paging message outstanding for the MS/AT. 4-21
3GPP2 A.S0008-C v2.0

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
The HRPD AN sends an A21-Ack message to IWS-1xBS 2 with a cause value indicating that paging activity is already taking place. IWS-1xBS 2 stops timer Tack-21. f. The MSC sends a Paging Request message to 1x BS 3. The MSC starts another instance of timer T3113.
g. IWS-1xBS 3 sends an A21-1x Air Interface Signaling message containing a 1x paging message to the HRPD AN and starts timer Tack-21. IWS-1xBS 3 ensures that resources are available to support the 1x call prior to requesting the HRPD AN to page the MS/AT. The A21-1x Air Interface Signaling message contains and indication that this is a paging message. h. When the HRPD AN receives the A21-1x Air Interface Signaling message from IWS-1xBS 3, it notes that this is a 1x paging message and that it already has a paging message outstanding for the MS/AT. The HRPD AN sends an A21-Ack message to IWS-1xBS 3 with a cause value indicating that paging activity is already taking place. IWS-1xBS 3 stops timer Tack-21. i. j. l. The HRPD AN sends the 1x overhead parameters to the MS/AT. These values have been previously received from the 1x system. The MS/AT acknowledges receipt of the 1x overhead parameters. The MS/AT acknowledges receipt of the 1x paging message.
k. The HRPD AN sends the 1x paging message to the MS/AT. m. The HRPD AN acknowledges receipt of the A21 message by sending an A21-Ack to IWS-1xBS 1. IWS-1xBS 1 stops timer Tack-21. n. The MS/AT tunes to the 1x system and acknowledges the page by transmitting a Page Response message over the 1x Access Channel. In this example, it is assumed that 1x BS 2 receives the Page Response message. o. 1x BS 2 constructs the Paging Response message, places it in the Complete Layer 3 Information message, and sends the message to the MSC. If the Paging Request message contained a Tag IE, 1x BS 2 includes this IE in the Paging Response message. The MS/AT is implicitly registered in the 1x system. The MSC stops all instances of timer T3113 for this MS/AT. p. 1x BS 2 and the MSC continue with MT call setup procedures. Refer to [13] for completion of the MS call termination in the 1x system. q. IWS-1xBS 2 sends an A21-Event Notification message to the HRPD AN to inform it that the MS/AT is now receiving services from the 1x network. IWS-1xBS 2 starts timer Tack-21. r. The HRPD AN acknowledges the event notification by sending an A21-Ack message. IWS-1xBS 2 stops timer Tack-21.
34 35 36 37 38 39 40 41
4.5.3.4
1x Page Delivery to the MS/AT in an HRPD System (Paging Request) with A13 Procedure IWS-AN Successful Operation
This scenario describes the call flow associated with an MS/AT 1x call termination, paging and service option notification over the HRPD air interface using IWS-AN function. The MS/AT registers at a border sector (corresponding to source AN) such that the paging area covers an RT belonging to the target AN. This may be due to distance-based paging or subnet hysteresis using secondary colorcode. The AT subsequently becomes dormant. The MS/AT is monitoring the HRPD system when the call arrives at the MSC, destined for the MS/AT. This call flow only shows the target ANs page procedure.
4-22
3GPP2 A.S0008-C v2.0
1 2 3
Figure 4.5.3.4-1
1x Page Delivery to the MS/AT in an HRPD System with A13 Procedure IWS-AN
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
a. The MSC determines that an incoming call terminates to an MS/AT within its serving region. The MSC sends a Paging Request message to the IWS-AN and one or more 1x BSs reachable by an MS/AT within the HRPD source ANs paging area. The MSC may optionally include calling party information in this message. The MSC starts an instance of timer T3113 for each Paging Request message sent. Note that the Paging Request message may contain a Virtual Page Indicator (VPI) identifying that the 1x BS shall prepare to receive a Page Response Message from the MS/AT. b. The source AN determines that it needs to page the MS/AT through some RTs in the source AN and some RTs in the one or more target ANs (it is shown one target AN in this example). The source AN sends an A13-Paging Request message to the target AN and starts timer Tpreq-13. The A13-Paging Request message contains the necessary session information for the target AN to determine the paging area and the paging cycle of the MS/AT. The message may optionally include timing information of when the page is to be transmitted over-the-air by the source AN. If the target AN can transmit the page over-the-air in the same slot, then the chance that the AT will miss the page is reduced. If the calling party information is included in step a, a Feature Notification Message containing the calling party information that is also included in this message. c. The target AN sends an A13-Paging Request Ack message to the source AN. Upon receipt of the A13-Paging Request Ack message, the source AN stops the corresponding timer Tpreq-13. d. The target AN transmit the page to the MS/AT over the control channel. If the MSC included calling party information in step a, the target AN includes the Feature Notification Message containing the calling party information in the same HRPD message. This call flow assumes that the MS/AT receives the page from the target AN. If the MS/AT receives the page from the source AN, refer to section 4.5.3.1. e. The MS/AT tunes to the 1x system and acknowledges the page by transmitting a Page Response message over the 1x Access Channel. f. The 1x BS constructs the Paging Response message, places it in the Complete Layer 3 Information message, and sends the message to the MSC. If the Paging Request message contained a Tag IE, the 1x BS includes this IE in the Paging Response message. The MS/AT is implicitly registered in the 1x system. The MSC stops all instances of timer T3113 for this MS/AT.
g. The 1x BS/MSC continues with MT call setup procedures. Refer to [13] for completion of the MS call termination in the 1x system.
4-23
3GPP2 A.S0008-C v2.0

1 2 3 4 5
h. The MSC may determine that the MS/AT, which has subscribed to Cross Notification services, has registered with the 1x system and send an Event Notification message to the IWS-AN containing registration event. This step can occur anytime after step f. i. The HRPD AN replies with an Event Notification Ack message. The MSC stops timer Tevent.
6 7 8 9 10 11 12 13
4.5.3.5
1x Page Delivery to the MS/AT in an HRPD System (Paging Request) with A13 Procedure IWS-1xBS Successful Operation
This scenario describes the call flow associated with an MS/AT 1x call termination, paging and service option notification over the HRPD air interface using the IWS-1x BS function. The MS/AT registers at a border sector (corresponding to source AN) such that the paging area covers an RT belonging to the target AN. This may be due to distance-based paging or subnet hysteresis using secondary colorcode. The AT subsequently becomes dormant. The MS/AT is monitoring the HRPD system when the call arrives at the MSC, destined for the MS/AT. This call flow only shows the target ANs page procedure.
MS/AT HRPD Target AN HRPD Source AN IWS-1xBS
Paging Request A21-1x Air Interface Signaling (GPM) A13-Paging Request A13-Paging Request Ack HRPD: 3G1XServices packet (GPM) HRPD: 3G1XServicesAck A13-Paging Delivered A13-Paging Delivered Ack A21-Ack 1x: Page Response Message Complete L3 Info: Paging Response 1x MT Call Setup Proceeds A21-Event Notification A21-Ack
MSC
time
a b c d
Tpreq-13
Tack-21
e T3113 f
Tpreq-13
g h i j k l
Tack-21
m n
14 15 16
Figure 4.5.3.5-1
1x Page Delivery to the MS/AT in an HRPD System with A13 Procedure IWS-1x BS
17 18 19 20 21 22 23 24 25 26 27 28 29
a. The MSC determines that an incoming call terminates to an MS/AT within its serving region. The MSC sends a Paging Request message to the 1x BS. The MSC starts timer T3113. b. The IWS-1xBS sends an A21-1x Air Interface Signaling message containing a 1x paging message to the HRPD source AN and starts timer Tack-21. The IWS-1xBS ensures that resources are available to support the 1x call prior to requesting the HRPD AN to page the MS/AT. c. The source AN determines that it needs to page the MS/AT through some RTs in the source AN and some RTs in the one or more target ANs (it is shown one target AN in this example). The source AN sends an A13-Paging Request message to the target AN and starts timer Tpreq-13. The A13-Paging Request message contains the necessary session information for the target AN to determine the paging area and the paging cycle of the MS/AT. The message may optionally include timing information of when the page is to be transmitted over-the-air by the source AN. If the target AN can transmit the page over-the-air in the same slot, then the chance that the AT will miss the page is reduced.
4-24
3GPP2 A.S0008-C v2.0

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
d. The target AN sends an A13-Paging Request Ack message to the source AN. Upon receipt of the A13-Paging Response message, the source AN stops the corresponding timer Tpreq-13. e. The target AN transmit the page to the MS/AT over the control channel. This call flow assumes that the MS/AT receives the page from the target AN. If the MS/AT receives the page from the source AN, refer to section 4.5.3.2. f. The MS/AT acknowledges target AN receipt of the 1x paging message. g. The target AN sends an A13-Paging Delivered message to the source AN to acknowledge the response from MS/AT, and starts timer Tpreq-13. h. The source AN sends an A13-Paging Delivered Ack message back to the target AN. Upon receipt of the A13-Paging Delivered Ack message, the target AN stops the corresponding timer Tpreq-13. i. The source AN acknowledges receipt of the A21 message by sending an A21-Ack to the IWS-1xBS. The IWS-1xBS stops timer Tack-21. If the MS/AT was not found at the HRPD source AN, and source AN does not receive A13-Paging Delivered message from target AN, the source AN sends an A21Ack message with the Cause field set to Unknown MS/AT to the IWS-1xBS to indicate this result and the call flow ends. The MS/AT tunes to the 1x system and acknowledges the page by transmitting a Page Response message over the 1x Access Channel.
j.
k. The 1x BS constructs the Paging Response message, places it in the Complete Layer 3 Information message, and sends the message to the MSC. If the Paging Request message contained a Tag IE, the 1x BS includes this IE in the Paging Response message. The MS/AT is implicitly registered in the 1x system. The MSC stops all instances of timer T3113 for this MS/AT. l. The 1x BS/MSC continues with MT call setup procedures. Refer to [13] for completion of the MS call termination in the 1x system.
m. The IWS-1xBS sends an A21-Event Notification message to the HRPD AN to inform it that the MS/AT is now receiving services from the 1x network. The IWS-1xBS starts timer Tack-21. n. The HRPD AN sends an A21-Ack message to the IWS-1xBS. The IWS-1xBS stops timer Tack-21.
28 29 30
4.5.4
Refusal of a 1x Page Delivery to the MS/AT in an HRPD System
This section contains call flows that describe the delivery of 1x pages to the MS/AT while the MS/AT is in an HRPD system, followed by refusal of the page by the MS/AT 4.5.4.1 Refusal of a 1x Page Delivery to the MS/AT in an HRPD System (Paging Request) without A13 Procedure IWS-AN
31 32 33 34 35
This scenario describes the call flow associated with an MS/AT refusal of a 1x call termination, tunneled over the HRPD air interface. The MS/AT is registered in and monitoring the HRPD system when the call arrives at the MSC, destined for the MS/AT.
4-25
3GPP2 A.S0008-C v2.0
1 2 3
Figure 4.5.4.1-1
Refusal of a 1x Page Delivery to the MS/AT in an HRPD System without A13 Procedure-IWS-AN
4 5 6 7 8 9 10 11 12 13 14 15
a. The MSC determines that an incoming call terminates to an MS/AT within its serving region. The MSC sends a Paging Request message to the IWS-AN and one or more 1x BSs reachable by an MS/AT within the HRPD ANs paging area. The MSC may optionally include calling party information in this message. The MSC starts an instance of timer T3113 for each Paging Request message sent. Note that the Paging Request message may contain a Virtual Page Indicator (VPI) identifying that the 1x BS shall prepare to receive a Page Response Message from the MS/AT. b. The HRPD AN sends a General Page Message to the MS/AT. If the MSC included calling party information in step a, the HRPD AN includes a Feature Notification Message containing the calling party information in the same HRPD message. c. The user chooses not to accept the call and the MS/AT sends a Release Order to the HRPD AN. d. The IWS-AN sends a Rejection message to the MSC to indicate that the MS/AT has not accepted the call. The MSC stops all instances of timer T3113 for this MS/AT. 4.5.4.2 MS/AT Rejects 1x Page in HRPD System without A13 Procedure IWS-1xBS
16 17 18 19
This scenario describes the call flow associated with an MS/AT 1x call termination, paging and service option notification over the HRPD air interface. The MS/AT decides not to accept the 1x circuit voice call. The HRPD AN notifies the IWS-1xBS and further paging may be aborted.
4-26
3GPP2 A.S0008-C v2.0

MS/AT HRPD AN IWS-1xBS Paging Request A21-1x Air Interface Signaling (GPM, FN) MSC time a b
HRPD: 3G1XServices packet (GPM) HRPD: 3G1XServicesAck
Tack-21
A21-Ack
c d
T3113
e f
HRPD: 3G1XServices packet (Release Order)
Tack-21
A21-Air Interface Signaling (Release Order) A21-Ack Rejection A21-Event Notification [Idle] A21-Ack * = Optional ** = Conditional
g h i j* k**
Tack-21
1 2 3
Figure 4.5.4.2-1
MS/AT Rejects 1x Page in HRPD System without A13 Procedure IWS1xBS
4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26
a. The MSC determines that an incoming call terminates to an MS/AT within its serving region. The MSC sends a Paging Request message to the 1x BS. The MSC starts timer T3113. The MSC may optionally include calling party information in this message. b. The IWS-1xBS sends an A21-1x Air Interface Signaling message containing a 1x paging message to the HRPD AN and starts timer Tack-21. If the MSC has included calling party information, the IWS1xBS includes a feature notification 1x air interface message as well, and indicates that both messages should be transmitted simultaneously, e.g., in the same HRPD radio frame. c. The HRPD AN sends the 1x paging message to the MS/AT. d. The MS/AT acknowledges receipt of the 1x paging message. e. The HRPD AN acknowledges receipt of the A21 message by sending an A21-Ack to the IWS-1xBS. The IWS-1xBS stops timer Tack-21. f. The MS/AT sends a 1x Release order encapsulated in an HRPD CSNA message to reject the 1x page. g. The HRPD AN forwards the MS/ATs Release Order to the IWS-1xBS over the A21 interface and starts the timer Tack-21. h. The IWS-1xBS sends an A21-Ack message to the HRPD AN, and the HRPD AN stops timer Tack-21. i. j. The 1x BS sends a Rejection message to the MSC to indicate that the MS/AT rejected the 1x circuit voice call. The MSC aborts further paging of the MS/AT in response to the message from the 1x BS. If the rejection due to ATs active packet data session, the HRPD AN may send an A21-Event Notification message to the IWS-1xBS to notify it when the ATs packet data session transitions to dormancy (idle) and the 1x network may resume paging the MS/AT for 1x service. The HRPD AN starts timer Tack-21.
k. If the HRPD AN sends an A21-Event Notification message in step j, the IWS-1xBS sends an A21Ack message. The HRPD AN stops timer Tack-21.
4-27
3GPP2 A.S0008-C v2.0

1 2 3 4 5 6 7 8
4.5.4.3
Refusal of a 1x Page Delivery to the MS/AT in an HRPD System (Paging Request) with A13 Procedure IWS-AN
This scenario describes the call flow associated with an MS/AT refusal of 1x call termination, tunneled over the HRPD air interface using IWS-AN function. The MS/AT registers at a border sector (corresponding to source AN) such that the paging area covers an RT belonging to the target AN. This may be due to distance-based paging or subnet hysteresis using secondary colorcode. The AT subsequently becomes dormant. The MS/AT is monitoring the HRPD system when the call arrives at the MSC, destined for the MS/AT. This call flow only shows the target ANs page procedure.
9 10 11
Figure 4.5.4.3-1
Refusal of a 1x Page Delivery to the MS/AT in an HRPD System with A13 Procedure - IWS-AN
12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34
a. The MSC determines that an incoming call terminates to an MS/AT within its serving region. The MSC sends a Paging Request message to the source AN and one or more 1x BSs reachable by an MS/AT within the HRPD ANs paging area. The MSC may optionally include calling party information in this message. The MSC starts an instance of timer T3113 for each Paging Request message sent. Note that the Paging Request message may contain a Virtual Page Indicator (VPI) identifying that the 1x BS shall prepare to receive a Page Response Message from the MS/AT. b. The source AN determines that it needs to page the MS/AT through some RTs in the source AN and some RTs in the one or more target ANs (it is shown one target AN in this example). The source AN sends an A13-Paging Request message to the target AN and starts timer Tpreq-13. The A13-Paging Request message contains the necessary session information for the target AN to determine the paging area and the paging cycle of the MS/AT. The message may optionally include timing information of when the page is to be transmitted over-the-air by the source AN. If the target AN can transmit the page over-the-air in the same slot, then the chance that the AT will miss the page is reduced. If the MSC included calling party information in step a, a Feature Notification Message containing the calling party information is included in this message. c. The target AN sends an A13-Paging Request Ack message to the source AN. Upon receipt of the A13-Paging Request Ack message, the source AN stops the timer Tpreq-13. d. The target AN transmits the page to the MS/AT over the control channel. If the MSC included calling party information in step a, the target AN includes the Feature Notification Message containing the calling party information in the same HRPD message. This call flow assumes that the MS/AT receives the page from the target AN. If the MS/AT receives the page from the source AN, refer to section 4.5.4.1. e. The user chooses not to accept the call and the MS/AT sends a Release Order to the HRPD target AN. 4-28
3GPP2 A.S0008-C v2.0

1 2 3 4 5 6 7
f.
The target AN forwards the Release Order to the source AN in A13-1x Air Interface Signaling message and start the timer Tpreq-13.
g. The source AN acknowledges the receipt of A13-1x Air Interface Signaling by sending A13-1x Air Interface Signaling Ack message to the target AN. The target AN stops the timer Tpreq-13. h. The source AN sends a Rejection message to the MSC to indicate that the MS/AT has not accepted the call. The MSC stops all instances of timer T3113 for this MS/AT.
8 9 10 11 12 13 14
4.5.4.4
MS/AT Rejects 1x Page in HRPD System with A13 Procedure IWS-1xBS
This scenario describes the call flow associated with an MS/AT refusal of 1x call termination, tunneled over the HRPD air interface using IWS-1x BS function. The MS/AT registers at a border sector (corresponding to source AN) such that the paging area covers an RT belonging to the target AN. This may be due to distance-based paging or subnet hysteresis using secondary colorcode. The AT subsequently becomes dormant. The MS/AT is monitoring the HRPD system when the call arrives at the MSC, destined for the MS/AT. This call flow only shows the target ANs page procedure.
MS/AT HRPD Target AN HRPD Source AN IWS-1xBS
Paging Request
MSC
time
a b c d e
A13-Paging Request A13-Paging Request Ack HRPD: 3G1XServices packet (GPM+FN) HRPD: 3G1XServicesAck
A21-1x Air Interface Signaling (GPM+FN)
Tpreq-13
Tack-21
f A13-Paging Delivered A13-Paging Delivered Ack T3113 A21-Ack A13-1x Air Interface Signaling (Release Order) A13-1x Air Interface Signaling Ack A21-1x Air Interface Signaling (Release Order) A21-Ack Rejection g h i j k l m n o
Tpreq-13
HRPD: 3G1XServices packet (Release Order)
Tpreq-13
Tack-21
15 16
Figure 4.5.4.4-1
MS/AT Rejects 1x Page in HRPD System with A13 procedure IWS-1xBS
17 18 19 20 21 22 23 24 25 26 27
a. The MSC determines that an incoming call terminates to an MS/AT within its serving region. The MSC sends a Paging Request message to the 1x BS. The MSC starts timer T3113. The MSC may optionally include calling party information in this message. b. The IWS-1xBS sends an A21-1x Air Interface Signaling message containing a 1x paging message to the HRPD source AN and starts timer Tack-21. If the MSC has included calling party information, the IWS-1xBS includes a feature notification 1x air interface message as well, and indicates that both messages should be transmitted simultaneously, e.g., in the same HRPD radio frame. c. The source AN determines that it needs to page the MS/AT through some RTs in the source AN and some RTs in the one or more target ANs (it is shown one target AN in this example). The source AN sends an A13-Paging Request message to the target AN and starts timer Tpreq-13. The A13-Paging Request message contains the necessary session information for the target AN to determine the 4-29
3GPP2 A.S0008-C v2.0

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
paging area and the paging cycle of the MS/AT. The message may optionally include timing information of when the page is to be transmitted over-the-air by the source AN. If the target AN can transmit the page over-the-air in the same slot, then the chance that the AT will miss the page is reduced. If the MSC included calling party information in step a, a Feature Notification Message containing the calling party information is included in this message. d. The target AN sends an A13-Paging Request Ack message to the source AN. Upon receipt of the A13-Paging Request Ack message, the source AN stops the timer Tpreq-13. e. The target AN transmits the page to the MS/AT over the control channel. If the MSC included calling party information in step a, the target AN includes the Feature Notification Message containing the calling party information in the same HRPD message. This call flow assumes that the MS/AT receives the page from the target AN. If the MS/AT receives the page from the source AN, refer to section 4.5.4.2. f. The MS/AT acknowledges target AN receipt of the 1x paging message. g. The target AN sends an A13-Paging Delivered message to the source AN to acknowledge the response from MS/AT, and starts timer Tpreq-13. h. The source AN sends an A13-Paging Delivered Ack message back to the target AN. Upon receipt of the A13-Paging Delivered Ack message, the target AN stops the timer Tpreq-13. i. The HRPD AN acknowledges receipt of the A21 message by sending an A21-Ack to the IWS-1xBS. The IWS-1xBS stops timer Tack-21. If the MS/AT was not found at the HRPD source AN, and source AN does not receive A13-Paging Delivered message from target AN, the HRPD source AN sends an A21-Ack message with the Cause field set to Unknown MS/AT to the IWS-1xBS to indicate this result and the call flow ends. The user chooses not to accept the call and the MS/AT sends a Release Order to the HRPD target AN.
j.
k. The target AN forwards the Release Order to the source AN in A13-1x Air Interface Signaling message and starts the timer Tpreq-13. l. The source AN acknowledges the receipt of A13-1x Air Interface Signaling by sending A13-1x Air Interface Signaling Ack message to the target AN. The target AN stops the timer Tpreq-13.
m. The source AN forwards the MS/ATs Release Order to the IWS-1xBS over the A21 interface and starts timer Tack-21. n. The IWS-1xBS sends an A21-Ack message to the source AN. The source AN stops timer Tack-21. o. The 1x BS sends a Rejection message to the MSC to indicate that the MS/AT rejected the 1x circuit voice call. The MSC aborts further paging of the MS/AT in response to the message from the 1x BS. The MSC stops the timer T3113.
35 36 37
4.5.5
HRPD Page Delivery in a 1x System - MS/AT Idle
This section contains call flows that describe the delivery of HRPD pages to the MS/AT while the MS/AT is in the 1x system. 4.5.5.1 HRPD Page Delivery in a 1x System - MS/AT Idle IWS-AN
38 39 40 41 42 43
This scenario describes the call flow associated with delivery of an HRPD page to the MS/AT over the 1x air interface and data delivered over the HRPD air interface. The MS/AT is registered in and monitoring the 1x system and idle when the packet data arrives at the HRPD AN/PCF, destined for the MS/AT. Refer to section 4.5.6 when the MS/AT is active with a voice call. Note: If the MS/AT decides not to accept the HRPD page, the call flow would end at step g.
4-30
3GPP2 A.S0008-C v2.0

MS/AT 1x BS MSC HRPD AN/PCF (IWS-AN) packet data BS Service Request BS Service Response Paging Request 1x: page 1x: Page Response PDSN time a b c d
T311
T3113
Complete L3 Info: Paging Response
e f* g* h*
1x: L2 Ack Connection establishment
Registration and location updating procedures
j*
A11 acct. Data flow

1 2
k l * = optional
Data flow
Figure 4.5.5.1-1
HRPD Page Delivery in a 1x System - MS/AT Idle IWS-AN
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
a. The PDSN sends packet data to the HRPD AN/PCF on an existing PPP connection associated with a specific MS/AT and dormant packet data session. b. Based on vendor specific procedures (e.g., stored information indicating that the MS/AT has registered with the 1x system), the IWS-AN sends a BS Service Request message, containing an HRPD service option, to the MSC and starts timer T311. This message contains a data burst of type 7; refer to [19]. c. The MSC responds with a BS Service Response message. The IWS-AN stops timer T311. d. Receipt of a BS Service Request message, containing the HRPD service option, triggers the MSC to send a Paging Request message, containing the HRPD service option, to the 1x BS. The MSC starts timer T3113. e. The 1x BS pages the MS/AT with the HRPD service option. f. If required by the BS, the MS/AT acknowledges the page by transmitting a Page Response message over the 1x Access Channel. Otherwise the MS/AT proceeds to step i.
g. The 1x BS constructs the Paging Response message, places it in a Complete Layer 3 Information message and sends the message to the MSC. The MSC stops timer T3113 upon receipt of the Paging Response message. Note: The 1x BS does not start timer T303 and does not anticipate receiving an Assignment Request message from the MSC or an SCCP connection response from the MSC. h. The 1x BS sends a Layer 2 Ack to the MS/AT in response to the Page Response. i. j. The MS/AT tunes to the HRPD system and initiates connection establishment procedures with the HRPD AN. Refer to [10], Connection Setup State. The MS/AT may register with the IWS-AN and the IWS-AN may then perform Location Updating procedures with the MSC. Refer to section 4.6.1 for registration and location updating procedures. At this point the connection is established and HRPD packet data can flow between the MS/AT and the PDSN. 4-31
k. A11 accounting procedures take place on the A11 interface. l.
3GPP2 A.S0008-C v2.0

1 2 3 4 5
4.5.5.2
HRPD Page Delivery in a 1x System - MS/AT Idle IWS-1xBS
This scenario describes the call flow associated with delivery of an HRPD page to the MS/AT over the 1x air interface and data delivered over the HRPD air interface. The MS/AT is registered in and monitoring the 1x system and idle when the packet data arrives at the HRPD AN/PCF, destined for the MS/AT. Refer to section 4.5.6 when the MS/AT is active with a voice call.
MS/AT IWS-1xBS MSC HRPD AN/PCF packet data A21-Service Request 1x: page 1x: Page Response A21-Service Response 1x: L2 Ack PDSN time a b c
Tpage-21
d* e
f* Connection establishment g*
Registration and location updating procedures
h*
A11 acct. Data flow A21-Event Notification A21-Ack

6 7
i* j* k*
Data flow
Tack-21
* = Optional ** = Conditional
l**
Figure 4.5.5.2-1
HRPD Page Delivery in a 1x System - MS/AT Idle
8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27
a. The PDSN sends packet data to the HRPD AN/PCF on an existing PPP connection associated with a specific MS/AT and dormant packet data session. b. Based on vendor specific procedures (e.g., stored information indicating that the MS/AT has registered with the 1x system), the HRPD AN sends an A21-Service Request message, containing an HRPD service option, to the IWS-1xBS and starts timer Tpage-21. c. The 1x BS pages the MS/AT with the HRPD service option. d. If required by the BS, the MS/AT acknowledges the page by transmitting a Page Response message over the 1x Access Channel. Otherwise the MS/AT proceeds to step g. If the MS/AT sends a 1x page response, then the IWS-1xBS shall send an A21-Service Response back to the HRPD AN at this point. e. If the service option to be used in the 1x page message will cause the MS/AT to not respond to the 1x page and move immediately to HRPD, then the IWS-1xBS responds with an A21-Service Response message after step b. If the service option to be used in the 1x page message will cause the MS/AT to send a 1x page response prior to moving to HRPD, then the IWS-1xBS shall send the A21-Service Response message after receiving the 1x page response shown in step d in the figure. The HRPD AN stops timer Tpage-21 upon receipt of the A21-Service Response message. f. If the 1x BS receives a 1x Page Response message, the 1x BS sends a Layer 2 Ack to the MS/AT in response to the Page Response message.
g. The MS/AT tunes to the HRPD system and initiates connection establishment procedures with the HRPD AN. Refer to [10], Connection Setup State. 4-32
3GPP2 A.S0008-C v2.0

1 2 3 4 5 6 7 8 9 10 11 12
h. The MS/AT may register with the HRPD AN/PCF and the HRPD AN/PCF may then perform Location Updating procedures with the MSC. Refer to section 4.6.1 for registration and location updating procedures. i. j. A11 accounting procedures take place on the A11 interface. At this point the connection is established and HRPD packet data can flow between the MS/AT and the PDSN.
k. The HRPD AN may send an A21-Event Notification to the IWS-1xBS notifying it that the MS/AT is now operating on the HRPD system. This step may occur anytime after step g. The HRPD AN starts timer Tack-21. l. If the HRPD AN sends an A21-Event Notification in step k, the IWS-1xBS acknowledges the event notification by sending an A21-Ack message. The HRPD AN stops timer Tack-21.
13 14 15 16 17
4.5.5.3
HRPD Page Delivery in a 1x System - MS/AT Idle MS/AT Rejects HRPD Page IWSAN
This scenario describes the call flow associated with notification of packet data to an MS/AT that is idle in a 1x system, followed by rejection of that page by the MS/AT. This scenario uses the IWS-AN function.
MS/AT 1x BS MSC HRPD AN/PCF IWS-AN packet data BS Service Request BS Service Response Paging Request 1x: page 1x: Page Response 1x: L2 Ack Rejection Rejection PDSN time a b c d e
T311
T3113
f g* h i * = Optional
18 19 20
Figure 4.5.5.3-1
HRPD Page Delivery in a 1x System - MS/AT Idle MS/AT Rejects HRPD Page IWS-AN
21 22 23 24 25 26 27 28 29 30 31
a. The PDSN sends packet data to the HRPD AN/PCF on an existing PPP connection associated with a specific MS/AT and dormant packet data session. b. Based on vendor specific procedures (e.g., stored information indicating that the MS/AT has registered with the 1x system), the IWS-AN sends a BS Service Request message indicating that packet data is received at the HRPD system to the MSC and starts timer T311. This message contains a data burst of type 7; refer to [19]. c. The MSC responds with a BS Service Response message. The IWS-AN stops timer T311. d. Receipt of a BS Service Request message, containing the HRPD service option, triggers the MSC to send a Paging Request message, containing the HRPD service option, to the 1x BS. The MSC starts timer T3113. e. The 1x BS pages the MS/AT with the HRPD service option.
4-33
3GPP2 A.S0008-C v2.0

1 2 3 4 5 6 7 8
f.
The MS/AT responds with a Page Response message with the service option field SO=0 indicating that the MS/AT is refusing to accept packet data service.
g. The 1x BS sends a Layer 2 Ack to the MS/AT in response to the Page Response. h. The BS sends a Rejection message to the MSC indicating that the MS/AT rejected the page for packet data service. i. The MSC forwards the Rejection message to the IWS-AN. The IWS-AN aborts further paging of the MS/AT.
9 10 11 12 13
4.5.5.4
HRPD Page Delivery in a 1x System - MS/AT Idle MS/AT Rejects HRPD Page IWS1xBS
This scenario describes the call flow associated with notification of packet data to an MS/AT that is idle in a 1x system, followed by rejection of that page by the MS/AT. This scenario uses the IWS-1xBS function.
MS/AT IWS-1xBS MSC HRPD AN/PCF packet data A21-Service Request PDSN time a b
Tpage-21
A21-Service Response 1x: Page 1x: Page Response c d e
1x: L2 Ack A21-Event Notification (Service Reject) A21-Ack
f* g h
Tack-21
14 15 16
Figure 4.5.5.4-1
HRPD Page Delivery in a 1x System - MS/AT Idle MS/AT Rejects HRPD Page IWS-1xBS
17 18 19 20 21 22 23 24 25 26 27 28 29
a. The PDSN sends packet data to the HRPD AN/PCF on an existing PPP connection associated with a specific MS/AT and dormant packet data session. b. The HRPD AN/PCF, aware that the MS/AT is currently registered in the 1x system, sends an A21Service Request message, containing an HRPD service option, to the IWS-1xBS and starts timer Tpage-21. c. If the service option to be used in the 1x page message will cause the MS/AT to not respond to the 1x page and move directly to the HRPD system, then the IWS-1xBS responds with an A21-Service Response message. The HRPD AN stops timer Tpage-21. If the service option to be used in the 1x page message will cause the MS/AT to send a 1x page response prior to moving to the HRPD system, then the IWS-1xBS shall not send an A21-Service Response until it receives the 1x page response. d. The 1x BS pages the MS/AT with the HRPD service option. e. The MS/AT rejects the HRPD page for service by sending a 1x Page Response message with SO=0 to the 1x BS. 4-34
3GPP2 A.S0008-C v2.0

1 2 3 4 5 6 7 8 9
f.
The 1x BS acknowledges receipt of the Page Response with a layer 2 ack.
g. If the IWS-1xBS has already sent an A21-Service Response, then the IWS-1xBS shall send an A21Event Notification to the HRPD AN indicating that the MS/AT has rejected the 1x page; otherwise, the IWS-1xBS sends an A21-Service Response message containing an indication that the MS/AT rejected the 1x page. If the IWS-1xBS sends an A21-Event Notification message, it starts timer Tack21. h. The HRPD AN send an A21-Ack to acknowledge the event notification. The IWS-1xBS stops timer Tack-21.
10 11 12
4.5.6
HRPD Page Delivery in a 1x System - MS/AT on a Traffic Channel (TCH)
This section contains call flows that describe the delivery of HRPD pages to the MS/AT while the MS/AT is in the 1x system and active on a traffic channel. 4.5.6.1 HRPD Page Delivery in a 1x System - MS/AT on a Traffic Channel IWS-AN
13 14 15 16 17 18
This scenario describes the call flow associated with delivery and acceptance of an HRPD page to the MS/AT over the 1x air interface and data delivered over the HRPD air interface. The MS/AT is registered in the 1x system and on a traffic channel when the packet data arrives at the HRPD AN/PCF, destined for the MS/AT. Note: If the MS/AT decides not to accept the HRPD page, the call flow would end at step g.
MS/AT 1x BS MSC HRPD AN/PCF (IWS-AN) packet data BS Service Request BS Service Response ADDS Deliver 1x: Data Burst Message 1x: Layer 2 Ack ADDS Deliver Ack 1x: release PDSN time a b c d e
T311
T3113
f g h
T300
1x: release
Clear Request Clear Command
i j
T315
Clear Complete Connection establishment
k l m n*
Registration procedures
A11 acct.
Data flow
19 20
Data flow
p * = optional
Figure 4.5.6.1-1
HRPD Page Delivery in a 1x System - MS/AT on TCH - IWS-AN 4-35
3GPP2 A.S0008-C v2.0

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
a. The PDSN sends packet data to the HRPD AN/PCF on an existing PPP connection associated with a specific MS/AT and dormant packet data session. b. Based on vendor specific procedures (e.g., stored information indicating that the MS/AT has registered with the 1x system), the IWS-AN sends a BS Service Request message indicating that packet data is received at the HRPD system to the MSC and starts timer T311. This message contains a data burst of type 7; refer to [19]. c. The MSC responds with a BS Service Response message. The IWS-AN stops timer T311. d. Receipt of the BS Service Request message, and the MS/AT being on a traffic channel, triggers the MSC to send an ADDS Deliver message to the 1x BS. The MSC starts timer T3113. e. The 1x BS transmits the data burst received in step d over the forward traffic channel. f. The MS/AT acknowledges delivery of the data burst on the traffic channel with a Layer 2 Ack. g. If the MSC had requested a response by including the Tag IE in the ADDS Deliver message, the 1x BS replies with an ADDS Deliver Ack message including the same Tag IE in the ADDS Deliver message when it has received acknowledgement from the MS/AT that the message was delivered. h. The MS/AT initiates call clearing by transmitting a release over the reverse traffic channel. i. j. The 1x BS sends a Clear Request message to the MSC to initiate the call clearing transaction. The 1x BS starts timer T300. The MSC sends a Clear Command message to the 1x BS to instruct the 1x BS to release the associated dedicated resource and starts timer T315. The 1x BS stops timer T300.
k. In response to the Clear Command message the 1x BS releases the terrestrial circuit, if allocated. The 1x BS then acknowledges the MS/AT by sending a release over the forward traffic channel and releases the radio resource. l. The 1x BS returns a Clear Complete message to the MSC. The MSC stops timer T315 upon receipt of the Clear Complete message and releases the underlying transport connection.
m. The MS/AT tunes to the HRPD system and initiates connection establishment procedures with the HRPD AN. refer to [10], Connection Setup State. n. The MS/AT may register with the HRPD AN/PCF. o. A11 accounting procedures take place on the A11 interface. p. At this point the connection is established and HRPD packet data can flow between the MS/AT and the PDSN.
32 33 34 35 36
4.5.6.2
HRPD Page Delivery in a 1x System - MS/AT on a Traffic Channel IWS-1xBS
This scenario describes the call flow associated with delivery and acceptance of an HRPD page to the MS/AT over the 1x air interface and data delivered over the HRPD air interface. The MS/AT is registered in the 1x system and on a traffic channel when the packet data arrives at the HRPD AN/PCF, destined for the MS/AT.
4-36
3GPP2 A.S0008-C v2.0
1 2
Figure 4.5.6.2-1
HRPD Page Delivery in a 1x System - MS/AT on TCH IWS-1xBS
3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
a. The PDSN sends packet data to the HRPD AN/PCF on an existing PPP connection associated with a specific MS/AT and dormant packet data session. b. Based on vendor specific procedures (e.g., stored information indicating that the MS/AT has registered with the 1x system), the HRPD AN sends an A21-Service Request message indicating that packet data is received at the HRPD system to the IWS-1xBS and starts timer Tpage-21. This message contains a service option value. The 1x BS will use this value to build and transmit a data burst of type 7; refer to [19]. The HRPD AN ensures that resources are available to support the packet call prior to requesting the IWS-1xBS to send the page to the MS/AT. c. The IWS-1xBS responds with an A21-Service Response message. The HRPD AN stops timer Tpage21 upon receipt of the A21-Service Response message. d. The 1x BS transmits the data burst built in step b. e. The MS/AT acknowledges delivery of the data burst on the traffic channel with a Layer 2 Ack. f. The MS/AT initiates call clearing by transmitting a release over the reverse traffic channel. g. The 1x BS sends a Clear Request message to the MSC to initiate the call clearing transaction. The 1x BS starts timer T300. h. The MSC sends a Clear Command message to the 1x BS to instruct the 1x BS to release the associated dedicated resource and starts timer T315. The 1x BS stops timer T300. 4-37
3GPP2 A.S0008-C v2.0

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
i.
In response to the Clear Command message the 1x BS releases the terrestrial circuit, if allocated. The 1x BS then acknowledges the MS/AT by sending a release over the forward traffic channel and releases the radio resource. The 1x BS returns a Clear Complete message to the MSC. The MSC stops timer T315 upon receipt of the Clear Complete message and releases the underlying transport connection.
j.
k. The MS/AT tunes to the HRPD system and initiates connection establishment procedures with the HRPD AN. Refer to [10], Connection Setup State. l. The MS/AT may register with the HRPD AN/PCF. m. A11 accounting procedures take place on the A11 interface. n. At this point the connection is established and HRPD packet data can flow between the MS/AT and the PDSN. o. The HRPD AN may send an A21-Event Notification to the IWS-1xBS notifying it that the MS/AT is now operating on the HRPD system. This step may occur anytime after step k. The HRPD AN starts timer Tack-21. p. If the HRPD AN sends an A21-Event Notification in step o, the IWS-1xBS acknowledges the event notification by sending an A21-Ack message. The HRPD AN stops timer Tack-21. 4.5.6.3 HRPD Page Delivery in a 1x System - MS/AT on a Traffic Channel MS/AT Rejects HRPD IWS-AN
17 18 19 20 21 22
This scenario describes the call flow associated with delivery and rejection of an HRPD page to the MS/AT over the 1x air interface. The MS/AT is registered in the 1x system and on a traffic channel when the packet data arrives at the HRPD AN/PCF, destined for the MS/AT. This scenario uses the IWS-AN function.
MS/AT 1x BS MSC HRPD AN/PCF (IWS-AN) packet data BS Service Request BS Service Response ADDS Deliver 1x: Data Burst Message 1x: Layer 2 Ack ADDS Deliver Ack 1x: MS Reject Order 1x: Layer 2 Ack Rejection Rejection PDSN time a b c d e
T311
T3113
f g h i j k
23 24 25
Figure 4.5.6.3-1
HRPD Page Delivery in a 1x System - MS/AT on a Traffic Channel MS/AT Rejects HRPD IWS-AN
26 27 28 29 30 31 32
a. The PDSN sends packet data to the HRPD AN/PCF on an existing PPP connection associated with a specific MS/AT and dormant packet data session. b. Based on vendor specific procedures (e.g., stored information indicating that the MS/AT has registered with the 1x system), the IWS-AN sends a BS Service Request message indicating that packet data is received at the HRPD system to the MSC and starts timer T311. This message contains a data burst of type 7; refer to [19]. c. The MSC responds with a BS Service Response message. The IWS-AN stops timer T311. 4-38
3GPP2 A.S0008-C v2.0

1 2 3 4 5 6 7 8 9 10 11 12 13 14
d. Receipt of the BS Service Request message, and the MS/AT being on a traffic channel, triggers the MSC to send an ADDS Deliver message to the 1x BS. The MSC starts timer T3113. e. The 1x BS transmits the data burst received in step d over the forward traffic channel. f. The MS/AT acknowledges delivery of the data burst on the traffic channel with a Layer 2 Ack. g. If the MSC had requested a response by including the Tag IE in the ADDS Deliver message, the 1x BS replies with an ADDS Deliver Ack message including the same Tag IE in the in the ADDS Deliver message when it has received acknowledgement from the MS/AT that the message was delivered. h. The MS/AT rejects the HRPD page for service by sending a 1x MS Reject order to the 1x BS. i. j. The 1x BS acknowledges receipt of the 1x MS Reject Order with a Layer 2 Ack. The BS sends a Rejection message to the MSC to convey the information contained in the Reject Order.
k. The MSC forwards the Rejection message to the IWS-AN. The IWS-AN aborts further paging of the MS/AT. 4.5.6.4 HRPD Page Delivery in a 1x System - MS/AT on a Traffic Channel MS/AT Rejects HRPD Page IWS-1xBS
15 16 17 18 19 20
This scenario describes the call flow associated with delivery and rejection of an HRPD page to the MS/AT over the 1x air interface. The MS/AT is registered in the 1x system and on a traffic channel when the packet data arrives at the HRPD AN/PCF, destined for the MS/AT. This scenario uses the IWS-1xBS function.
21 22 23
Figure 4.5.6.4-1
HRPD Page Delivery in a 1x System - MS/AT on a Traffic Channel MS/AT Rejects HRPD Page IWS-1xBS
24 25 26 27 28 29 30 31 32 33
a. The PDSN sends packet data to the HRPD AN/PCF on an existing PPP connection associated with a specific MS/AT and dormant packet data session. b. The HRPD AN/PCF, aware that the MS/AT is currently registered in the 1x RAN, sends an A21Service Request message, containing an HRPD service option, to the IWS-1xBS and starts timer Tpage-21. c. The IWS-1xBS responds with an A21-Service Response message. The HRPD AN stops timer Tpage21. d. The 1x BS sends a 1x Data Burst message to the MS/AT over the traffic channel with the Burst Type field set to 000111 to page the mobile. e. The MS/AT rejects the HRPD page for service by sending a 1x MS Reject order to the 1x BS. 4-39
3GPP2 A.S0008-C v2.0

1 2 3 4 5 6
f.
The 1x BS acknowledges receipt of the 1x MS Reject Order with a layer 2 ack.
g. The IWS-1xBS sends an A21-Event Notification message containing an indication that the MS/AT rejected the HRPD Page Request. The IWS-1xBS starts timer Tack-21. h. The HRPD AN acknowledges the event notification by sending an A21-Ack message. The IWS1xBS stops timer Tack-21.
4-40
3GPP2 A.S0008-C v2.0

1 2 3 4 5 6 7 8 9 10 11 12 13 14
4.6
Mobility Management for CSNA in the HRPD System
This section describes how mobility management is performed with the HRPD network while the MS/AT is monitoring 1x and vice-versa. Various 1x air interface parameters control registration on the 1x system for an MS. When the mobile has HRPD capabilities also (MS/AT), those parameters may cause the MS/AT to register with the 1x system either directly or via an HRPD AN/PCF. When the 1x MSC receives a registration from an MS/AT, it makes note of the RAN equipment from which it received the registration. Subsequent paging activities may thus be directed toward that RAN equipment. However, paging activities by the MSC are not limited to the single RAN equipment from which the registration was received. The MSC may choose to page a wider area, including inter-system paging. If the MSC has direct interfaces to IWS-ANs, as well as to 1x BSs, the MSC may choose to do direct paging activities to both HRPD and 1x RAN equipments in its attempts to contact the MS/AT. Refer also to section 4.5 for procedures related to cross-paging. In this section, HRPD: denotes a message sent using the HRPD air interface and frequency while 1x: denotes a message sent using the 1x air interface and frequency. 4.6.1 1x Registration Over HRPD
15 16
This section contains call flows that describe 1x Registration Over HRPD. 4.6.1.1 1x Registration Over HRPD IWS-AN
17 18 19 20 21 22 23 24 25 26 27
This scenario describes the call flow associated with an MS/AT in an HRPD system maintaining registration in the 1x system. The HRPD air interface may or may not broadcast route update triggers on the control channel. When route update triggers are sent, the MS/AT (both in idle or connected state), uses this information to send a RouteUpdate message for subsequent determination as to whether registration is required. If route update triggers are not provided, determination for sending a RouteUpdate message for the idle MS/AT may also be due to noticing a new registration zone during a periodic visit to the 1x system. This call flow does not take into consideration how the IWS-AN determines that registration is required (e.g., an inter-AN dormant handoff may have occurred), only that a registration is to be performed with the 1x system.
MS/AT HRPD: RouteUpdate HRPD: Registration Order HRPD: Registration Message Location Updating Request Location Updating Accept HRPD: Registration Accepted Order HRPD AN/ IWS-AN Target MSC time a b c d e f
T3210
28 29
Figure 4.6.1.1-1
1x Registration Over HRPD IWS-AN
30 31 32 33 34 35
a. The MS/AT sends a RouteUpdate message. b. The HRPD AN determines that registration is required and sends a Registration Order to the MS/AT. c. The MS/AT sends a Registration message to the HRPD AN. d. On reception of the Registration message, the IWS-AN constructs the Location Updating Request message, places it in the Complete Layer 3 Information message, and sends it to the target MSC. The IWS-AN then starts timer T3210. 4-41
3GPP2 A.S0008-C v2.0

1 2 3 4 5 6
e. The target MSC sends the Location Updating Accept message to the IWS-AN to indicate that the Location Updating Request message has been processed. The MSC may note internally that the MS/AT is accessible via the IWS-AN. Upon receipt of the Location Updating Accept message, the IWS-AN stops timer T3210. f. The HRPD AN sends a Registration Accepted Order to the MS/AT.
7 8 9 10 11 12 13 14
4.6.1.2
1x Registration Over HRPD IWS-1xBS
This scenario describes the call flow associated with an MS/AT in an HRPD system maintaining registration in the 1x system. The HRPD air interface may or may not broadcast route update triggers on the control channel. When route update triggers are sent, the MS/AT (both in idle or connected state), uses this information to send a RouteUpdate message for subsequent determination as to whether registration is required. If route update triggers are not provided, determination for sending a RouteUpdate message for the idle MS/AT may also be due to noticing a new registration zone during a periodic visit to the 1x system.
MS/AT HRPD: RouteUpdate A21-Event Notification [Idle/Active on HRPD] A21-1x Air Interface Signaling (Registration Order) HRPD: Registration Order HRPD:3G1XServicesAck A21-Ack HRPD: Registration Message A21-1x Air Interface Signaling (Registration) A21-Ack Location Updating Request Location Updating Accept HRPD AN IWS-1xBS Target MSC time a* b* c*
Tack-21
d* e* f g h i
Tack-21
T3210
A21-1x Air Interface Signaling (Registration Accepted Order) HRPD: Registration Accepted Order HRPD:3G1XServicesAck A21-Ack
15 16
j k l m n o * = optional
Tack-21
Figure 4.6.1.2-1
1x Registration Over HRPD IWS-1xBS
17 18 19 20 21 22 23 24
Steps a e are optional, since the MS/AT can autonomously decide to send a 1x Registration Message over CSNA. a. The MS/AT sends a RouteUpdate message. b. The HRPD AN may send an A21-Event Notification to the IWS-1xBS to notify it that the MS/AT is operating on the HRPD system. c. The IWS-1xBS, upon receiving the A21-Event Notification may decide to send a Registration Order to the MS/AT. If this is the case, the IWS-1xBS shall send a 1x Registration Order in an A21-1x Air Interface Signaling message to the HRPD AN and shall start timer Tack-21. 4-42
3GPP2 A.S0008-C v2.0

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
d. The HRPD AN may determine that registration is required and send a Registration Order to the MS/AT, or the HRPD AN may have received a Registration Order as a result of step b. Note: The MS/AT may also decide autonomously to send a Registration Message. In all cases, the scenario continues as in step g below. e. The AT acknowledges receipt of the 1x message. f. If the HRPD AN receives an indication that the Registration Order was delivered to the AT, it shall send an A21-Ack message to the IWS-1xBS. The IWS-1xBS stops timer Tack-21.
g. The MS/AT sends a Registration message to the HRPD AN. h. The HRPD AN sends the Registration message to the IWS-1xBS in an A21-Air Interface Signaling message and starts timer Tack-21. i. j. The IWS-1xBS acknowledges receipt of the A21 message by sending an A21-Ack message. The HRPD AN stops timer Tack-21. On reception of the Registration message, the 1x BS constructs the Location Updating Request message, places it in the Complete Layer 3 Information message, and sends it to the target MSC. The 1x BS then starts timer T3210.
k. The target MSC sends the Location Updating Accept message to the 1x BS to indicate that the Location Updating Request message has been processed. Upon receipt of the Location Updating Accept message, the 1x BS stops timer T3210. l. The IWS-1xBS sends a Registration Accepted Order to the HRPD AN in an A21-Air Interface Signaling message and starts timer Tack-21.
m. The HRPD AN sends the Registration Accepted Order to the MS/AT. n. The MS/AT acknowledges receipt of the Registration Accepted Order. o. The HRPD AN acknowledges receipt of the A21 message by sending an A21-Ack message. The IWS-1xBS stops timer Tack-21.
26 27 28 29 30 31 32 33 34 35 36 37 38
4.6.2
Event Notification From HRPD AN to IWS-1xBS
This section contains a call flow that describes the HRPD AN notifying the 1x BS of events pertinent to handling of a particular MS/AT. Note that this call flow only pertains to the situation using the IWS-1xBS function. In this particular scenario, it is assumed that the MS/AT has arrived at the HRPD AN as a result of an idle handoff. The HRPD AN notes the MEID of the mobile and decides to notify the IWS-1xBS that the MS/AT is currently on the HRPD system. This procedure may be used to notify the IWS-1xBS when a cross-paging service request was rejected, when an idle handoff to the HRPD AN occurred, when an MS has left an HRPD AN or arrived at HRPD AN. e.g. after an intra-HRPD active handoff, if an MS/AT for which an A21 message was received was not found, or when a call state change (busy/idle) occurred for an MS/AT. The manner in which the HRPD AN decides to notify the IWS-1xBS, and which IWS-1xBS is notified is an implementation issue. The HRPD AN can request the identity of the MS/AT, and might find that same identity in some stored data associated with a particular A21 interface.
4-43
3GPP2 A.S0008-C v2.0

HRPD AN A21-Event Notification A21-Ack
1 2
IWS-1xBS
time a b
Tack-21
Figure 4.6.2-1 Event Notification From HRPD AN to IWS-1xBS a. The HRPD AN, having decided to notify the IWS-1xBS that the MS/AT is currently on the HRPD system, sends an A21-Event Notification to the IWS-1xBS. The HRPD AN starts timer Tack-21. b. The IWS-1xBS acknowledges the event notification by sending an A21-Ack message to the HRPD AN. The HRPD AN stops timer Tack-21. 4.6.3 Event Notification From IWS-1xBS to HRPD AN
3 4 5 6
7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24
This section contains a call flow that describes the IWS-1xBS notifying the HRPD AN of events pertinent to handling of a particular MS/AT. Note that this call flow only pertains to the situation using the IWS1xBS function. In this particular scenario, it is assumed that the MS/AT has arrived at the 1x BS as a result of an idle handoff. The IWS-1xBS notes the MEID of the mobile and decides to notify the HRPD AN that the MS/AT is currently on the 1x system. The IWS-1xBS need not attempt to notify one or more ANs that may have no interest in the fact that the MS/AT is in communication with the IWS-1xBS, e.g., a mobile that has just powered on will likely have no state established with a nearby HRPD AN. Therefore, the IWS-1xBS shall review internal information, e.g., data indicating association of MEIDs/IMSIs with particular A21 interfaces, to determine whether the MS/AT has previously been associated with an HRPD AN. If such a relationship is discovered, then the IWS-1xBS may attempt to notify the particular HRPD AN that the MS/AT is operating in the 1x system and is in communication with the IWS-1xBS, when an MS has left a 1xBS or arrived at a 1xBS. e.g. after an intra-1x active handoff. This procedure may be used to notify the HRPD AN when a cross-paging service request was rejected, when an idle/active handoff to the 1x network occurred, or if a call state change (busy/idle) occurred for an MS/AT. The trigger for when the IWS-1xBS decides to notify the HRPD AN of an event is an implementation issue.
HRPD AN A21-Event Notification IWS-1xBS time a
Tack-21
A21-Ack
25 26
Figure 4.6.3-1 Event Notification From IWS-1xBS to HRPD AN a. The IWS-1xBS, having decided to notify the HRPD AN that the MS/AT is currently on the 1x system, sends an A21-Event Notification to the HRPD AN. The IWS-1xBS starts timer Tack-21. b. The HRPD AN acknowledges the event notification by sending an A21-Ack message to the IWS1xBS. The IWS-1xBS stops timer Tack-21.
27 28 29 30 31
4-44
3GPP2 A.S0008-C v2.0
1 2 3 4 5 6
4.7
Hard Handoff Between HRPD and 1x
This section describes how hard handoffs are accomplished between HRPD and 1x systems. This section shows the call flows for the IWS in the 1x BS and those for the IWS in HRPD AN. Although call flows for standalone IWS are not explicitly shown in this section, it is achieved if A21 procedures from call flows for the IWS in the 1x BS, A1 procedures from all flows for the IWS in HRPD AN, and A1 procedures defined in Annex B are combined. 4.7.1 Hard Handoff of a Voice Call from HRPD VoIP to 1x Circuit Service - IWS-1xBS
7 8 9 10 11
This scenario describes the way in which a voice call being supported as a VoIP call on HRPD is handed off to become a 1x circuit voice call using the IWS-1xBS function. The MS/AT is assumed to be in an active VoIP call on the HRPD network prior to the beginning of this call flow.
4-45
3GPP2 A.S0008-C v2.0
1 2
Figure 4.7.1-1 Hard Handoff of a Voice Call From HRPD VoIP to 1x Circuit Service - IWS-1xBS Steps a - c may occur any time prior to step d. a. The HRPD AN may send an A21-1x Parameters Request message to the IWS-1xBS to request 1x overhead parameters. The HRPD AN starts timer Tparamreq-21. b. The IWS-1xBS provides the HRPD AN with the 1x overhead parameters and the RAND value (when applicable), and starts timer Tack-21. If the HRPD AN has sent the A21-1x Parameters Request message in step a, then the HRPD AN stops timer Tparamreq-21. 4-46
3 4 5 6 7 8
3GPP2 A.S0008-C v2.0

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
c. The HRPD AN sends an A21-Ack message to acknowledge receipt of the overhead parameters and RAND. The 1x BS stops timer Tack-21. d. The MS/AT sends power measurements to the HRPD AN. These power measurements may include radio environment measurement information from the HRPD or 1x systems. e. At some point, the HRPD AN determines that the radio environment within the 1x network is preferable for supporting communication with the MS/AT. It prepares for the hard handoff by sending the 1x overhead parameters and RAND value to the MS/AT via CSNA. Note that the HRPD AN may send the 1x overhead parameters to the MS/AT at any time. The HRPD AN is responsible for providing the proper RAND value to the MS/AT prior to the remainder of this call flow occurring. f. The MS/AT acknowledges receipt of the 1x overhead parameters. g. After the HRPD AN is certain that the MS/AT has received the latest 1x overhead parameters, the HRPD AN sends a 1x Service Redirection Message to the MS/AT using the CSNA protocol. When the MS/AT receives the 1x Service Redirection Message, it interprets that message as an indication that the MS/AT should begin procedures to move the active call to the 1x system. Those procedures involve originating a call on the 1x system by sending 1x signaling via the HRPD system using CSNA. h. The MS/AT acknowledges receipt of the 1x Service Redirection Message. i. j. The MS/AT sends an Origination Message to the HRPD AN via the CSNA protocol. The HRPD AN acknowledges receipt of the Origination Message.
k. The HRPD AN encapsulates the Origination Message in an A21-1x Air Interface Signaling message and sends it to the IWS-1xBS, and starts timer Tack-21. l. The IWS-1xBS sends an A21-Ack message to acknowledge receipt of the A21-1x Air Interface Signaling message. The HRPD AN stops timer Tack-21.
m. The 1x BS receives and processes the Origination Message and sends a CM Service Request to the 1x MSC, and starts timer T303. At this point, parallel activity takes place. While the remainder of the procedure shown in this figure completes, the core network takes appropriate actions to reroute the voice bearer from packet data on the HRPD network to the 1x MSC. This rerouting action is expected to complete prior to the completion of radio interface actions to establish the circuit voice call on the 1x network. n. The MSC sends an Assignment Request message to the 1x BS. The 1x BS stops timer T303. The MSC starts timer T10. o. The IWS-1xBS may determine that the radio data received in step k is no longer current and decide to obtain more current radio data from the HRPD AN. To do this, the IWS-1xBS sends an A21-Radio Update Request message to the HRPD AN and starts timer Tradioreq-21. p. The HRPD AN may request and, if so, the AT replies with updated radio data. The AT may reply with a different set of pilots than requested in the previous A21-Radio Update Request message. q. The HRPD AN sends the requested information to the IWS-1xBS in an A21-Radio Update Response message. The IWS-1xBS stops timer Tradioreq-21. r. The IWS-1xBS creates a 1x handoff direction message and encapsulates it in an A21-1x Air Interface Signaling message and sends it to the HRPD AN, indicating in the transmission control information included in this A21 message that an acknowledgment is required. The IWS-1xBS starts timer Tack21. The HRPD AN delivers the 1x handoff direction message to the MS/AT via the CSNA protocol. The HRPD AN notes that an acknowledgement is required from the MS/AT, and delays sending an A21Ack message until it receives an air interface delivery acknowledgement. 4-47
s.
3GPP2 A.S0008-C v2.0

1 2 3 4 5 6 7
t.
The MS/AT acknowledges delivery of the 1x handoff direction message.
u. The HRPD AN sends an A21-Ack message to the IWS-1xBS. The IWS-1xBS stops timer Tack-21. v. The MS/AT retunes to the 1x radio network and performs traffic channel acquisition with the 1x BS. w. The MS/AT sends a 1x handoff completion message to the 1x BS 36. x. The 1x BS sends an Assignment Complete message to the 1x MSC. The MSC stops timer T10. At this point, the voice call has been moved from VoIP over the HRPD network to circuit voice over the 1x network. 4.7.2 Hard Handoff of a Voice Call From HRPD VoIP to 1x Circuit Service, IWS-AN
8 9 10 11 12
This scenario describes the way in which a voice call being supported as a VoIP call on HRPD is handed off to become a 1x circuit voice call using the IWS-AN function. The MS/AT is assumed to be in an active VoIP call on the HRPD network prior to the beginning of this call flow.
36 This may be a Handoff Completion Message, or an Extended Handoff Completion Message as appropriate.
4-48
3GPP2 A.S0008-C v2.0
1 2
Figure 4.7.2-1 Hard Handoff of a Voice Call From HRPD VoIP to 1x Circuit Service, IWS-AN a. The MS/AT sends power measurements to the HRPD AN. b. The IWS-AN determines that the radio environment within the 1x network will be better for the continuation of communication by the MS/AT. It prepares for the hard handoff by sending the 1x
3 4 5
4-49
3GPP2 A.S0008-C v2.0

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
overhead parameters and RAND value to the MS/AT via CSNA 37. Note that the IWS-AN may send the 1x overhead parameters and RAND value to the MS/AT at any time. The IWS-AN is responsible for providing the proper RAND value to the MS/AT prior to the remainder of this call flow occurring. c. The MS/AT acknowledges receipt of the 1x overhead parameters. d. The IWS-AN sends a 1x Service Redirection Message to the MS/AT using the CSNA protocol. When the MS/AT receives the 1x Service Redirection Message, it interprets that message as an indication that the MS/AT should begin procedures to move the active call to the 1x system. Those procedures involve originating a call on the 1x system by sending 1x signaling via the HRPD system using CSNA. e. The MS/AT acknowledges receipt of the 1x Service Redirection Message. f. The MS/AT sends an Origination Message to the IWS-AN using the CSNA protocol to tunnel the message across the HRPD air interface.
g. The IWS-AN acknowledges receipt of the Origination Message. h. The IWS-AN creates a CM Service Request message, sends it to the MSC, and starts timer T303. i. The MSC knows that the CM Service Request came from an HRPD system, so it does not attempt to establish an A2 circuit for the voice call. Instead, it knows that a handoff will follow immediately and so handles the call origination processing, but delays bearer assignment until receiving the Handoff Required. The MSC sends an Assignment Request to the HRPD system. The IWS-AN stops timer T303. The MSC starts timer T10.
At this point, parallel activity takes place. While the remainder of the procedure shown in this figure completes, the core network takes appropriate actions to reroute the voice bearer from packet data on the HRPD network to the 1x MSC. This rerouting action is expected to complete prior to the completion of radio interface actions to establish the circuit voice call on the 1x network. j. The IWS-AN creates an Assignment Complete message and sends it to the MSC. The MSC stops timer T10.
k. The IWS-AN now creates a Handoff Required message using either actual or calculated 1x power and one-way delay information (refer to section 2.8.2) and sends it to the MSC. The IWS-AN starts timer T7. l. The MSC sends a Handoff Request message to the BS with the IS-95 Channel Identity IE or the IS2000 Channel Identity IE present, based on if the corresponding IS-2000 or IS-95 Channel Identity IE was present in the Handoff Required message. The MSC starts timer T11.
m. Upon receipt of the Handoff Request message from the MSC, the BS allocates appropriate radio resources as specified in the message. As the Handoff Request message can have multiple cell(s) specified, the BS can also choose to set up multiple cell(s) for the handoff request. The BS sends null forward traffic channel frames to the MS/AT. The BS sends a Handoff Request Acknowledge message to the MSC and starts timer T9 to wait for arrival of the MS/AT on its radio channel. The MSC stops timer T11 upon the receipt of this message. The first cell in the cell identifier list IE of the message is treated as the new designated cell by the MSC. The change of designated cell occurs upon receipt of the Handoff Complete message. If the service option received in the Handoff Request message is not available at the BS and the BS selected a different service option for the handoff then the BS shall include the service option it selected in the service configuration records.
37 The manner in which the HRPD AN receives the 1x RAND value and overhead parameter values is not defined. These values may be provisioned, or provided in some proprietary manner to the HRPD AN.
4-50
3GPP2 A.S0008-C v2.0

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
n. The MSC sends a Handoff Command message to the IWS-AN. The IWS-AN stops timer T7. The MSC shall include in the Handoff Command message the service configuration records it received in the Handoff Request Acknowledge message. o. The IWS-AN delivers the 1x handoff direction message to the MS/AT using the CSNA protocol. p. The MS/AT acknowledges delivery of the 1x handoff direction message q. The IWS-AN sends a Handoff Commenced message to the MSC. The IWS starts timer T306 to await the Clear Command message from the MSC. Note: If the IWS-AN detects HRPD air link lost, the IWS-AN should wait for timer T306 to expire before sending a Clear Request message to the MSC. r. s. t. The MS/AT retunes to the 1x radio network and performs traffic channel acquisition with the 1x BS. The 1x BS connects the bearer path. The MS/AT sends a 1x Handoff Complete Message to the 1x BS. The 1x BS stops timer T9. The 1x BS sends a Handoff Complete message to the 1x MSC.
At this point, the voice call has been moved from VoIP over the HRPD network to circuit voice over the 1x network. u. The MSC sends a Clear Command message to the IWS-AN and starts timer T315. The IWS-AN stops timer T306. v. The IWS-AN sends a Clear Complete message to the MSC to notify it that clearing has been accomplished. The MSC stops timer T315.
4-51
3GPP2 A.S0008-C v2.0

1 2 3 4 5 6
4-52
3GPP2 A.S0008-C v2.0
1 2
5 Messages, Information Elements and Timer Definitions

5.1 Message Definitions
3 4
5.1.1 5.1.1.1
A13 Message Definitions A13-Session Information Request
6 7 8
This message is sent from the target AN to the source AN to request session control information for a particular AT. Information Element A13 Message Type UATI 128 Security Layer Packet Sector ID (target) Hardware ID A13 Vendor-Specific Information Data Transfer Section Reference 5.2.1.3 5.2.1.4 5.2.1.5 5.2.1.6 5.2.1.18 5.2.1.24 5.2.1.28 Element Direction Target Source Target Source Target Source Target Source Target Source Target Source Target Source O
a
Type M R R R C C C O O O O
b b c
9 10 11 12
a. b. c.
Refer to section 2.5 for information on this IE. This IE is included when the information is available to the target AN. This IE may be included if the target AN supports data transfer during A13 session transfer. 5.1.1.1 A13-Session Information Request 7 6 5 4 3 2 1 0 Octet 1 1 2 3 4 A13 Message Type = [01H] Length = [10H]
The following table shows the bitmap layout for the A13-Session Information Request message.
UATI 128: A13 Element Identifier = [01H] UATI
(MSB)
(LSB) (MSB) Security Layer Packet: A13 Element Identifier = [02H] Length = [variable] Security Layer Packet
18 1 2 3 4
(LSB) 5-1
3GPP2 A.S0008-C v2.0 5.1.1.1 A13-Session Information Request 7 6 (MSB) 5 4 3 2 1 0 Octet 1 2 3 4 Sector ID: A13 Element Identifier = [03H] Length = [10H] Sector ID
(LSB) Hardware ID : A13 Element Identifier = [0DH] Length = [variable] Hardware ID Length = [variable] (MSB) Hardware ID Type = <any value> (LSB) (MSB) Hardware ID Value = <any value>
18 1 2 3 4 5 6 7
(LSB) (MSB) A13 Vendor-Specific Information: A13 Element Identifier = [15H] Length = [variable] Vendor-Specific Information = <printable ASCII characters> (LSB) Data Transfer: A13 Element Identifier = [19H] Length = [variable] Data Transfer Type = [01H] (MSB) A24 Connection ID = <any value> (LSB) Address Type = [01H, 02H] (MSB) Target IP Address = <any value> (LSB)
1
n 1 2 3 n 1 2 3 4 5 6 7 8 n
2 3 4
5.1.1.2
A13-Session Information Response
This message is sent from the source AN to the target AN and includes the requested session control information.
5-2
3GPP2 A.S0008-C v2.0 Information Element A13 Message Type UATI 128 Mobile Identity (MN ID) PDSN IP Address Access Network Identifiers Session State Information Record Extended Session State Information Record Forward QoS Information Reverse QoS Information Subscriber QoS Profile Forward QoS Update Information Reverse QoS Update Information A13 Vendor-Specific Information Data Transfer
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22
Section Reference 5.2.1.3 5.2.1.4 5.2.1.8 5.2.1.9 5.2.1.10 5.2.1.11 5.2.1.12 5.2.1.13 5.2.1.14 5.2.1.15 5.2.1.16 5.2.1.17 5.2.1.24 5.2.1.28
Element Direction Source Target Source Target Source Target Source Target Source Target Source Target Source Target Source Target Source Target Source Target Source Target Source Target Source Target Source Target
Type M O O O O O
a
R C C C R C C C C C C C C
g g g
Ob,c,d,f
c,d,e,f
Og O O O
g
Og,h
g,i g,i g j
a. The UATI is set to the same value as the UATI sent in the A13-Session Information Request message. b. Multiple instances of this IE may be included, where one instance of this IE contains one Session State Information Record (SSIR) for the main HRPD personality, as specified in [10]. Therefore the target AN knows that the Personality Index for this SSIR is 0. c. SSIR and/or E-SSIR includes the requested QoS Sub BLOB and granted QoS Sub BLOB formatted as specified in [10] if the corresponding personality includes those Sub Blobs. Refer to [8] and [10] for detailed information. d. Attributes with default values shall not be sent to the target node. If an attribute is not contained in the SSIR, the target node shall assume that the missing attribute(s) have the default values (specified for each attribute in each protocol). e. This IE is included when the HRPD session includes multiple personalities. Multiple instances of this IE may be included, where one instance of this IE contains one SSIR for an HRPD personality that is not the main personality, as specified in [10]. Multiple instances of this IE shall be sorted in order of increasing personality index. f. SSIRs of protocol types with HardLink subtype shall not be sent to the target node unless specified otherwise. SSIRs of Session Configuration Protocol Types may be sent even if the subtype is set to HardLink.
g. This IE is included if the information is available at the source AN. h. Subject to configuration 38, this IE is included if the information is available at the source AN. If the target AN subsequently receives this information from the PDSN, then the information received from the PDSN takes precedence.
38
This specification calls for this information to be sent from the PDSN (via the target PCF) to the target AN. However in certain configurations outside the scope of this specification, this information may be sent from the source AN in the A13Session Information Response message instead. This information should not be sent over both A11 and A13.
5-3
3GPP2 A.S0008-C v2.0

1 2 3 4 5 6 7 8 9
i.
This IE is included to convey the PDSN updated QoS of one or more IP flows in the specified direction. Multiple instances of this IE may be included, where one instance of this IE contains all of the PDSN updated QoS for a given personality. The target AN shall store the updated QoS lists received from the PDSN and use them to grant the QoS irrespective of the contents of the subscriber QoS Profile. This IE may be included if the target AN support data transfer during session transfer (as indicated in the A13-Session Information Request message) and the source AN has data to send.
j.
The following table shows the bitmap layout for the A13-Session Information Response message. 5.1.1.2 A13-Session Information Response 7 6 (MSB) 5 4 3 2 1 0 Octet 1 1 2 3 4 A13 Message Type = [04H] Length = [10H] UATI
UATI 128: A13 Element Identifier = [01H]
(LSB) Mobile Identity (MN ID): A13 Element Identifier = [05H] Length = [06H - 08H] (10 - 15 digits)
Identity Digit 1 = [0H-9H] (BCD) Odd/even Indicator = [1,0] Type of Identity = [110] (MN ID)
18 1 2
3
Identity Digit 3 = [0H-9H] (BCD)
Identity Digit N+1 = [0H-9H] (BCD) = [1111] (if even number of digits) (MSB)
Identity Digit N = [0H-9H] (BCD)
Identity Digit N+2 = [0H-9H] (BCD)
n+1 1 2 3 4 5
PDSN IP Address: A13 Element Identifier = [06H] Length = [04H] PDSN IP Address
(LSB) Access Network Identifiers: A13 Element Identifier = [07H] Type = 01H Length = [05H]
Reserved
6 1 2 3 4
(MSB)
SID (LSB) NID 5-4
5 6
(MSB)
3GPP2 A.S0008-C v2.0 5.1.1.2 A13-Session Information Response 7 6 5 4 PZID (MSB) (MSB) Session State Information Record: A13 Element Identifier = [08H] Length = [variable] (LSB) Session State Information Record 3 2 1 0 (LSB) Octet 7 8 1 2 3 4
(LSB) (MSB) Reserved = [0000] (MSB) Extended Session State Information Record: A13 Element Identifier = [09H] Length = [variable] (LSB) Personality Index Session State Information Record
n 1 2 3 4 5
(LSB) Forward QoS Information: A13 Element Identifier = [0AH] Length = [variable] Forward QoS Information Entry { 1-31: Entry Length = [variable] SR_ID = [01H-1FH] Reserved = [000] Forward Flow Count = [1 - 31] Entry Length = [01H] Forward Flow ID = [00H FFH] } Forward Flow Entry } Forward QoS Information Entry Reverse QoS Information: A13 Element Identifier = [0BH] Forward Flow Entry { Forward Flow ID Count :
n 1 2 j j+1 j+2 k k+1
1 2 j j+1 j+2 k k+1
Length = [variable] Reverse QoS Information Entry { 1-31: Entry Length = [variable] SR_ID = [01H-1FH] Reserved = [000] Reverse Flow Entry { Reverse Flow Count : Entry Length = [01H] Reverse Flow ID = [00H FFH] } Reverse Flow Entry 5-5 Reverse Flow Count = [1 - 31]
3GPP2 A.S0008-C v2.0 5.1.1.2 A13-Session Information Response 7 (MSB) 6 5 4 3 2 1 0 Octet 1 2 3 4 } Reverse QoS Information Entry Subscriber QoS Profile: A13 Element Identifier = [0CH] Length = [variable] Subscriber QoS Profile = <any value>
(LSB) Forward QoS Update Information: A13 Element Identifier = [0DH] Length = [variable] Reserved = [0000] Forward Flow Entry { Forward Flow ID Count : Forward Flow ID = [00H FFH] Forward Updated QoS Sub-BLOB Length = [variable] (MSB) Forward Updated QoS Sub-BLOB = <any value> (LSB) } Forward Flow Entry Reverse QoS Update Information: A13 Element Identifier = [0EH] Length = [variable] Reserved = [0000] Reverse Flow Entry { Reverse Flow ID Count : Reverse Flow ID = [00H FFH] Reverse Updated QoS Sub-BLOB Length = [variable] (MSB) Reverse Updated QoS Sub-BLOB = <any value> (LSB) } Reverse Flow Entry (MSB) A13 Vendor-Specific Information: A13 Element Identifier = [15H] Length = [variable] Vendor-Specific Information = <printable ASCII characters> (LSB) 5-6 Personality Index = [0H FH] Reverse Flow Count = [01H FFH] Personality Index = [0H FH] Forward Flow Count = [01H FFH]
n 1 2 3 4 i i+1 i+2 i+3 j 1 2 3 4 j j+1 j+2 j+3 k 1 2 3 n
3GPP2 A.S0008-C v2.0 5.1.1.2 A13-Session Information Response 7 6 5 4 3 2 1 0 Octet 1 2 3 4 n Data Transfer: A13 Element Identifier = [19H] Length = [variable] Data Transfer Type = [02H] RLP Count = [variable] RLP ID List for Data Transfer { RLP Count: RLP_ID = [00H FFH] } RLP ID List for Data Transfer
1
2 3 4
5.1.1.3
A13-Session Information Confirm
This message is sent from the target AN to the source AN to indicate that the target AN has successfully received the session control information for the requested AT. Information Element A13 Message Type UATI 128 Section Reference 5.2.1.3 5.2.1.4 Element Direction Target Source Target Source Oa Type M R
a. The UATI is set to the same value as the UATI sent in the A13-Session Information Request message. The following table shows the bitmap layout for the A13-Session Information Confirm message. 5.1.1.3 A13-Session Information Confirm 7 6 (MSB) 5 4 3 2 1 0 Octet 1 1 2 3 4 A13 Message Type = [02H] Length = [10H] UATI
(LSB)
7
18
8 9 10
5.1.1.4
A13-Session Information Reject
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 A13 Message Type UATI 128 Cause Section Reference 5.2.1.3 5.2.1.4 5.2.1.7 Element Direction Source Target Source Target Source Target O
a
Type M R R O
11
a. The UATI is set to the same value as the UATI sent in the A13-Session Information Request message. 5-7
3GPP2 A.S0008-C v2.0

1
The following table shows the bitmap layout for the A13-Session Information Reject message. 5.1.1.4 A13-Session Information Reject 7 6 (MSB) 5 4 3 2 1 0 Octet 1 1 2 3 4 A13 Message Type = [03H] Length = [10H] UATI
(LSB) Cause: A13 Element Identifier = [04H] Length = [01H] 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)]
2
18 1 2 3
3 4 5
5.1.1.5
A13-Resource Release Request
This message is sent from the target AN to the AN identified by UATI 128 to request a release of the UATI or the stale session identified in this message. Information Element A13 Message Type UATI 128 Security Layer Packet Sector ID (target) Hardware ID Section Reference 5.2.1.3 5.2.1.4 5.2.1.5 5.2.1.6 5.2.1.18 Element Direction 39 Target Source Target Source Target Source Target Source Target Source Oa O
b
Type M R C C C
Ob Ob
6 7 8 9 10
a. This IE includes the UATI assigned to the AT by the source AN. For stale session release procedure, this IE includes the prior UATI received from the AT. b. This IE is included when it is available to the target AN for stale session release procedure. The following table shows the bitmap layout for the A13-Resource Release Request message.
39 Source AN is the AN identified by UATI 128.
5-8
3GPP2 A.S0008-C v2.0 5.1.1.5 A13-Resource Release Request 7 6 (MSB) 5 4 3 2 1 0 Octet 1 1 2 3 4 A13 Message Type = [05H] Length = [10H] UATI
(LSB) (MSB) Security Layer Packet: A13 Element Identifier = [02H] Length = [variable] Security Layer Packet
18 1 2 3 4
(LSB) (MSB) Sector ID: A13 Element Identifier = [03H] Length = [10H] Sector ID = <any value>
n 1 2 3 4
(LSB) Hardware ID : A13 Element Identifier = [0DH] Length = [variable] Hardware ID Length = [variable] (MSB) Hardware ID Type = <any value> (LSB) (MSB) Hardware ID Value = <any value>
18 1 2 3 4 5 6 7
(LSB)
1
2 3
5.1.1.6
A13-Resource Release Response
This message is sent in response to an A13-Resource Release Request message. Information Element A13 Message Type UATI 128 Cause Section Reference 5.2.1.3 5.2.1.4 5.2.1.7 5-9 Element Direction Type Source Target Source Target Source Target Oa O
b
M R C
3GPP2 A.S0008-C v2.0

1 2 3 4
a. The UATI is set to the same value as the UATI sent in the A13-Resource Release Request message. b. This IE is included when the message is sent in response to a stale session release request. The following table shows the bitmap layout for the A13-Resource Release Response message. 5.1.1.6 A13-Resource Release Response 7 6 (MSB) 5 4 3 2 1 0 Octet 1 1 2 3 4 A13 Message Type = [06H] Length = [10H] UATI
(LSB) (MSB) Cause: A13 Element Identifier = [04H] Length = [01H] Cause Value = [06H (Requested prior session released), 07H (Requested prior session not found), 08H (Requested prior session not authentic) ] (LSB)
18 1 2 3
6 7 8
5.1.1.7
A13-Paging Request
This message is sent from the source AN to the target AN to request the target AN to transmit a page message on the target AN control channel for a particular AT. Information Element A13 Message Type UATI 128 AT-ID Correlation ID Session State Information Record Paging Control Information AT Designated Frequency ADDS User Part A13 1x LAC Encapsulated PDU A13 1x Message Transmission Control Section Reference 5.2.1.3 5.2.1.4 5.2.1.19 5.2.1.20 5.2.2.10 5.2.1.21 5.2.1.23 5.2.1.25 5.2.1.26 5.2.1.27 Element Direction Source Target Source Target Source Target Source Target Source Target Source Target Source Target Source Target Source Target Source Target Oa O O O O
a b c
Type M R R C R C C C C C
Oe O O
f
Og
h
9 10 11
a. This IE contains the identity of the recipient of the page message. b. If this IE is included in this message, its value shall be returned in the Correlation ID IE in the corresponding A13-Paging Request Ack message.
5-10
3GPP2 A.S0008-C v2.0

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
c. Multiple instances of this IE may be included where each instance of this IE contains a session state information record that is necessary for determining the current paging cycle and the paging area of the AT 40. d. This IE may be included to provide additional information that the target AN may use to improve paging performance. Multiple records may be included in this IE. e. This IE is included when the source AN requests the target AN to page the AT on a designated frequency (e.g., while the mobile is receiving a broadcast flow and is not operating on its normal carrier). f. This IE is used to transfer DoS content. This IE contains the packet data to be sent in an A9-Short Data Delivery message in a SDB format as specified in [10] in target side.
g. This IE contains the 1x LAC Encapsulated PDU. Multiple instances of this IE may be included, where each instance of this IE contains one 1x LAC encapsulated PDU. For example, General Page Message and Feature Notification message can be included respectively. This IE is used to send MT SMS using CSNA. h. This IE contains information about the encapsulated 1x air interface message to be transmitted over the Circuit Services Notification Application [9]. The following table shows the bitmap layout for the A13-Paging Request message. 5.1.1.7 A13-Paging Request 7 6 (MSB) 5 4 3 2 1 0 Octet 1 1 2 3 4 A13 Message Type = [07H] Length = [04H] UATI = <any value>
(LSB) Reserved (MSB) AT-ID: A13 Element Identifier = [10H] Length = [05H] ATI Type = [0010 (UATI 32)] AT-ID
18 1 2 3 4 5 6 (LSB) 7 1 2 3
(MSB)
Correlation ID: A13 Element Identifier = [11H] Length = [04H] Correlation Value = <any value>
40
The information includes SupportSecondaryColorCodes, RouteUpdateRadiusAdd and RouteUpdateRadiusMultiply attributes, SessionSeed parameter and PreferredControlChannelCycle attribute [10].
5-11
3GPP2 A.S0008-C v2.0 5.1.1.7 A13-Paging Request 7 6 5 4 3 2 1 0 Octet 4 5 (LSB) (MSB) (MSB) Session State Information Record: A13 Element Identifier = [08H] Length = [variable] (LSB) Session State Information Record 6 1 2 3 4
(LSB) Paging Control Information: A13 Element Identifier = [12H] Length = [variable] IF Paging Control Information Type = 01H (Message Transmission Time) { (MSB) Paging Control Information Type = [01H (Message Transmission Time)] Paging Control Information Length = [08H] Message Priority = <any value> (MSB) System Time for Packet Transmission = <any value> (LSB) Reserved = [0000] (MSB) Tc = <any value> (LSB)
p 1 2 q q+1 q+2 q+3 q+4 q+5 q+6 q+7 q+8 (LSB) q+9
} END Paging Control Information Type = 01H (Message Transmission Time) IF Paging Control Information Type = 02H (Registration Location Information) { (MSB) Paging Control Information Type = [02H (Registration Location Information)] Paging Control Information Length = [08H] (MSB) Paging Latitude = <any value> (LSB) (MSB) Paging Longitude = <any value> (LSB) (MSB) (LSB) Paging Radius = <any value> Reserved = [0 0000] 5-12 Reserved = [0] Reserved = [00] (LSB) r r+1 r+2 r+3 r+4 r+5 r+6 r+7 r+8 r+9
3GPP2 A.S0008-C v2.0 5.1.1.7 A13-Paging Request 7 6 5 4 3 2 1 0 Octet 1 2 CDMA channel (high part) = [000 - 111] 3 4 5 6 7 8 9 Reserved = [00] (MSB) ADDS User Part: A13 Element Identifier = [16H] Data Burst Type = [00H (DoS)] Application Data Message = <any value> 1 2 3 4 Length = [variable] } END Paging Control Information Type = 02H (Registration Location Information) AT Designated Frequency: Band Class = [00000 - 11111] A13 Element Identifier = [14H] Length = [07H]
CDMA channel (low part) = [00H FFH] CDMA System Time = [variable]
(LSB) (MSB) A13 1x LAC Encapsulated PDU: A13 Element Identifier = [17H] Length = [variable] LAC Encapsulated PDU = <any value> (LSB) A13 1x Message Transmission Control: A13 Element Identifier = [18H] Length = [02H] Reserved = [000000] 3G1X Ack Required Logical Channel =[0,1] =[0,1]
n 1 2 3 n 1 2 3
ProtocolRevision = <any value>

1
2 3 4
5.1.1.8
A13-Paging Request Ack
This message is sent from the target AN to the source AN in response to the paging request from the source AN. Information Element A13 Message Type UATI 128 AT-ID Section Reference 5.2.1.3 5.2.1.4 5.2.1.19 5-13 Element Direction Target Source Target Source Target Source O O
a a
Type M R R
3GPP2 A.S0008-C v2.0 Information Element Correlation ID Paging Cause

1 2 3 4 5
Section Reference 5.2.1.20 5.2.1.22
Element Direction Target Source Target Source
Type Ob O C R
a. This IE contains the value of the same IE in the corresponding A13-Paging Request message. b. This IE shall be included if it was also included in the corresponding A13-Paging Request message and shall be set to the value received in that message. The following table shows the bitmap layout for the A13-Paging Request Ack message. 5.1.1.8 A13-Paging Request Ack 7 6 (MSB) 5 4 3 2 1 0 Octet 1 1 2 3 4 A13 Message Type = [08H] Length = [04H] UATI = <any value>
18 1 2 3 4 5 6 (LSB) 7 1 2 3 4 5 (LSB) 6 1 2 3
(MSB)
Paging Cause: A13 Element Identifier = [13H] Length = [01H]
Cause Value = [ 00H (Page transmission time unknown or not in specified slot), 01H (Page transmission in specified slot), 02H (Paging request rejected no reason specified), 03H (Paging request accepted for a subset of sectors) ]
6
5-14
3GPP2 A.S0008-C v2.0

1 2 3
5.1.1.9
A13-Paging Delivered
This message is sent from the target AN to the source AN to indicate that a previous page has been delivered to AT. Information Element A13 Message Type UATI 128 AT-ID Correlation ID Section Reference 5.2.1.3 5.2.1.4 5.2.1.19 5.2.1.20 Element Direction Target Source Target Source Target Source Target Source Oa O O
a b
Type M R R C
4 5 6 7 8
a. This IE contains the identity of the recipient of the encapsulated security layer packet. b. If this IE is included in this message, its value shall be returned in the Correlation ID IE in the corresponding A13-Paging Delivered Ack message. The following table shows the bitmap layout for the A13-Paging Delivered message. 5.1.1.9 A13-Paging Delivered 7 6 (MSB) 5 4 3 2 1 0 Octet 1 1 2 3 4 A13 Message Type = [0BH] Length = [04H] UATI = <any value>
18 1 2 3 4 5 6 (LSB) 7 1 2 3 4 5 (LSB) 6
(MSB)
5-15
3GPP2 A.S0008-C v2.0

1 2 3
5.1.1.10
A13-Paging Delivered Ack
This message is sent from the source AN to the target AN in response to the A13-Paging Delivered message from target AN. Information Element A13 Message Type UATI 128 AT-ID Correlation ID Section Reference 5.2.1.3 5.2.1.4 5.2.1.19 5.2.1.20 Element Direction Target Source Target Source Target Source Target Source Oa O O
a b
Type M R R C
4 5 6 7 8
a. This IE contains the value of the same IE in the corresponding A13-Paging Request message. b. This IE shall be included if it was also included in the corresponding A13-Paging Delivered message and shall be set to the value received in that message. The following table shows the bitmap layout for the A13-Paging Delivered Ack message. 5.1.1.10 7 6 (MSB) 5 4 A13-Paging Delivered Ack 3 2 1 0 Octet 1 1 2 3 4
A13 Message Type = [0CH] Length = [04H] UATI = <any value>
18 1 2 3 4 5 6 (LSB) 7 1 2 3 4 5 (LSB) 6
(MSB)
5-16
3GPP2 A.S0008-C v2.0

1 2 3
5.1.1.11
A13-Keep Alive Request
This message is sent from the serving AN to the AN that assigned LCM_UATI to perform keep alive over the A13 interface. Information Element A13 Message Type UATI 128 AT-ID Mobile Identity (MN ID) Hardware ID Section Reference 5.2.1.3 5.2.1.4 5.2.1.19 5.2.1.8 5.2.1.18 Element Direction Serving Assigning Serving Assigning Serving Assigning Serving Assigning Serving Assigning Oa O O
b c
Type M R R C C
4 5 6 7 8 9 10 11 12
a. Refer to section 2.5 for information on this IE. The UATI 128 identifies the session of the AT at the serving AN. b. This IE identifies the session of the AT and shall be set to the LCM_UATI. c. This IE is included when it is available at the target AN. This information may be used to confirm at the AN that assigned LCM_UATI that the indicated LCM_UATI is for the AT. d. This IE is included when it is available at the target AN. This information may be used to confirm at the AN that assigned LCM_UATI that the indicated LCM_UATI is for the AT. The following table shows the bitmap layout for the A13-Keep Alive Request message. 5.1.1.11 7 6 (MSB) 5 4 A13-Keep Alive Request 3 2 1 0 Octet 1 1 2 3 4
A13 Message Type = [09H] Length = [10H] UATI
(LSB) AT-ID: A13 Element Identifier = [10H] Length = [05H] Reserved = [0000] (MSB) AT-ID ATI Type = [0010 (UATI32)]
18 1 2 3 4 5 6 (LSB) 7 1 2 Type of Identity = [110] (MN ID) 3
Mobile Identity (MN ID): A13 Element Identifier = [05H] Length = [06H 08H] (10 15 digits) Odd/even Indicator = [1,0]
Identity Digit 2 = [0H-9H] (BCD) 5-17
3GPP2 A.S0008-C v2.0 5.1.1.11 7 6 5 4 A13-Keep Alive Request 3 2 1 0 Octet
Identity Digit N+1 = [0H-9H] (BCD) = [1111] (if even number of digits)
Identity Digit N = [0H-9H] (BCD) Identity Digit N+2 = [0H-9H] (BCD)
n n+1 1 2 3 4 5 (LSB) 6 7
Hardware ID: A13 Element Identifier = [0DH] Length = [variable] Hardware ID Length = [variable]
(MSB)
Hardware ID Type = <any value>
(MSB)
Hardware ID Value = <any value>
(LSB)
1
2 3
5.1.1.12
A13-Keep Alive Response
This message is used to respond to the A13-Keep Alive Request message. Information Element A13 Message Type UATI 128 Cause Section Reference 5.2.1.3 5.2.1.4 5.2.1.7 Element Direction Assigning Serving Assigning Serving Assigning Serving Oa O
b
Type M R C
4 5 6 7 8
a. The UATI is set to the same value as the UATI received in the A13-Keep Alive Request message. b. This IE is included when the AN that received the A13-Keep Alive Request message can not process the received message. The following table shows the bitmap layout for the A13-Keep Alive Response message. 5.1.1.12 7 6 (MSB) 5 4 A13-Keep Alive Response 3 2 1 0 Octet 1 1 2 3 4
A13 Message Type = [0AH] Length = [10H] UATI
(LSB) Cause: A13 Element Identifier = [04H] Length = [01H] 5-18
18 1 2
3GPP2 A.S0008-C v2.0 5.1.1.12 7 6 5 4 A13-Keep Alive Response 3 2 1 0 Octet 3
Cause Value = [ 04H (Requested session not found), 09H (Requested session is not in handoff) ]
1
2 3 4
5.1.1.13
A13-1x Air Interface Signaling
This message is sent from target AN to source AN and includes the 1x air interface message received from the MS/AT via CSNA. Information Element Section Reference Element Direction Type A13 Message Type Correlation ID UATI 128 AT-ID A13 1x LAC Encapsulated PDU 5.2.1.3 5.2.1.20 5.2.1.4 5.2.1.19 5.2.1.26 Target Source Target Source Target Source Target Source Target Source O O O O
a
M R R R R
5 6 7 8
a. This IE contains information about the encapsulated 1x air interface message received from CSNA [9]. The following table shows the bitmap layout for the A13-1x Air Interface Signaling message. 5.1.1.13 A13-1x Air Interface Signaling 7 6 (MSB) (MSB) 5 4 3 2 1 0 Octet 1 1 2 3 (LSB) UATI 128: A13 Element Identifier = [01H] Length = [04H] UATI = <any value> 6 1 2 3 4 A13 Message Type = [0DH] Length = [04H] Correlation Value = <any value>
Correlation ID: A13 Element Identifier = [11H]
18 1 2 3 4 5 6 (LSB) 5-19 7
3GPP2 A.S0008-C v2.0 5.1.1.13 7 (MSB) 6 5 4 A13-1x Air Interface Signaling 3 2 1 0 Octet 1 2 3 4 (LSB) } 1x LAC Encapsulated PDUs
1
A13 1x LAC Encapsulated PDU: A13 Element Identifier = [17H] Length = variable 1x LAC Encapsulated PDU = <any value>
2 3 4
5.1.1.14
A13-1x Air Interface Signaling Ack
The A13-1x Air Interface Signaling Ack message is sent to acknowledge receipt of A13-1x Air Interface Signaling message. Information Element Section Reference Element Direction Type A13 Message Type Correlation ID UATI 128 AT-ID 5.2.1.3 5.2.1.20 5.2.1.4 5.2.1.19 Source Target Source Target Source Target Source Target O O O M R R R
5 6
The following table shows the bitmap layout for the A13-1x Air Interface Signaling Ack message. 5.1.1.14 A13-1x Air Interface Signaling Ack 7 6 (MSB) 5 4 3 2 1 0 Octet 1 1 2 3 4 5 (LSB) (MSB) UATI 128: A13 Element Identifier = [01H] Length = [04H] UATI = <any value> 6 1 2 3 4 A13 Message Type = [0EH] Length = [04H] Correlation Value = <any value>
(LSB) Reserved AT-ID: A13 Element Identifier = [10H] Length = [05H] ATI Type = [0010 (UATI 32)] 5-20
18 1 2 3
3GPP2 A.S0008-C v2.0 5.1.1.14 7 (MSB) 6 5 A13-1x Air Interface Signaling Ack 4 3 AT-ID 2 1 0 Octet 4 5 6 (LSB)
1
2 3
5.1.2
A16 Message Definitions
4 5 6
5.1.2.1
A16-Session Transfer Request
This message is sent from the source AN to the target AN to request Connected State HRPD Session Transfer (hard handoff or with cross-connectivity support) for a particular AT. Information Element A16 Message Type AT-ID Correlation ID Mobile Identity (MN ID) Access Network Identifier Source PDSN address Session State Information Record Extended Session State Information Record Encapsulated Message Forward QoS Information Reverse QoS Information Subscriber QoS Profile Forward QoS Update Information Reverse QoS Update Information Serving Sector Information Sector Endpoint Information Assigning SC IP Address Timers RTD Information Serving Sector ID Target Sector ID Section Reference 5.2.2.3 5.2.2.13 5.2.2.25 5.2.2.4 5.2.2.5 5.2.2.7 5.2.2.10 5.2.2.12 5.2.2.6 5.2.2.19 5.2.2.20 5.2.2.21 5.2.2.22 5.2.2.23 5.2.2.29 5.2.2.31 5.2.2.33 5.2.2.34 5.2.2.35 5.2.2.36 5.2.2.37 Element Direction Type Source Target Source Target Source Target Source Target Source Target Source Target Source Target Source Target Source Target Source Target Source Target Source Target Source Target Source Target Source Target Source Target Source Target Source Target Source Target Source Target Source Target O O O O O
b a i
M R C R R R R C R C C C C C C C C C C C C
Oc O
d
Oe O O O O O O O O O
f f g h
Oh
j
Ok
l
Om
n o p
7 8
a. This IE identifies the session of the AT and shall be set to the last UATI that the AT has confirmed before this message is sent.
5-21
3GPP2 A.S0008-C v2.0

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
b. This IE carries the IP address of the A11 interface on the PDSN currently connected to the source PCF. c. Multiple instances of this IE may be included, where one instance of this IE contains one Session State Information Record of the main personality in the source AN. d. Multiple instances of this IE may be included, where one instance of this IE contains one Session State Information Record of the personality other than the main personality in the source AN. e. This IE encapsulates the air interface message from the AT that contains an estimate of the radio link conditions surrounding the AT. If the Default Route Update protocol [10] is configured for the current personality, then this IE carries a RouteUpdate message as specified in [10]. f. This IE is included if the information is available at the source AN. g. Subject to configuration 41, this IE is included if the information is available at the source AN. If the target AN subsequently receives this information from the PDSN, then the information received from the PDSN takes precedence. h. This IE is included to convey the PDSN updated QoS of one or more IP flows in the specified direction. The target AN shall store the updated QoS lists received from the source AN and use them when the specified personality is active when determining what QoS to grant for the associated IP flows irrespective of the contents of the Subscriber QoS Profile. i. j. If this IE is included in this message, its value shall be returned in the Correlation ID IE in the corresponding A16-Session Transfer Response message. This IE carries the sector information of the current serving sector to the target AN. Inclusion of this IE implies that the source AN is requesting make-before-break session transfer.
k. Multiple instances of this IE may be included, where one instance of this IE contains one sector information in the Active Set and the associated IP address and UDP port information. The target AN may send an A17-Slave Attach Request message to the IP address and UDP port during Connected State Session Transfer with cross-connectivity support to attach to the sector identified in the IE. l. If the target AN can determine the unique assigning SC IP address from AT-ID, this IE may be omitted. Otherwise, this IE shall be included.
m. If this IE is not included in this message, the target AN applies operator/manufacturer specific means to perform LCM_UATI keep alive procedure. n. This IE carries a round trip delay for the ATs reference pilot. If it is available, the source AN shall include this information to assist the target AN in locating the center of search window of the sector(s) to which the AT may switch. This IE is not sent for make-before-break session transfer. o. This IE shall be included by an entity implemented to this revision of the specification. p. This IE may be included. If the Encapsulated Message includes pilots on the target AN, then this IE identifies the strongest reported pilot on the target AN to assist the target AN with mapping pilots. The following table shows the bitmap layout for the A16-Session Transfer Request message. 5.1.2.1 A16-Session Transfer Request 7 6 5 4 3 2 1 0 Octet 1 A16 Message Type = [01H]
41
This specification calls for this information to be sent from the PDSN (via the target PCF) to the target AN. However in certain configurations outside the scope of this specification, this information may be sent from the source AN in the A16Session Transfer Request message instead. This information should not be sent over both A11 and A16.
5-22
3GPP2 A.S0008-C v2.0 5.1.2.1 A16-Session Transfer Request 7 6 Reserved (MSB) 5 4 3 2 1 0 Octet 1 2 ATI Type = [0010 (UATI 32)] AT-ID 3 4 5 6 (LSB) (MSB) Correlation ID: A16 Element Identifier = [18H] Length = [04H] Correlation Value = <any value> 7 1 2 3 4 5 (LSB) Mobile Identity (MN ID): A16 Element Identifier = [01H] Length = [06H - 08H] (10 - 15 digits) Identity Digit 1 = [0H-9H] (BCD) Odd/even Indicator = [1,0] Type of Identity = [110] (MN ID) 6 1 2 3 AT-ID: A16 Element Identifier = [0CH] Length = [05H]
Identity Digit N+1 = [0H-9H] (BCD) = [1111] (if even number of digits)
Identity Digit N+2 = [0H-9H] (BCD)
n+1 1 2 3
Access Network Identifiers: A16 Element Identifier = [02H] Type = 01H Length = [05H]
Reserved (MSB)
(MSB) NID
SID (LSB) (LSB) PZID
4 5 6 7 8 1 2 3 4 5 (LSB) 6
(MSB)
Source PDSN Address: A16 Element Identifier = [06H] Length = [04H] PDSN IP Address
5-23
3GPP2 A.S0008-C v2.0 5.1.2.1 A16-Session Transfer Request 7 (MSB) (MSB) 6 5 4 3 2 1 0 Octet 1 2 (LSB) Session State Information Record 3 4 Session State Information Record {1+: Session State Information Record: A16 Element Identifier = [03H] Length = [variable]
(LSB) } Session State Information Record Extended Session State Information Record {0, 1+: (MSB) Reserved = [0000] (MSB) Extended Session State Information Record: A16 Element Identifier = [05H] Length = [variable] (LSB) Personality Index = [0H FH] Session State Information Record
1 2 3 4 5
(LSB) } Extended Session State Information Record Encapsulated Message {0, 1: (MSB) Encapsulated Message: A16 Element Identifier = [09H] Length = [variable] Protocol Type and Subtype = [000000H FFFFFFH] (LSB) (MSB) Encapsulated Message
1 2 3 4 5 6
(LSB) } Encapsulated Message Forward QoS Information: A16 Element Identifier = [12H]
n 1 2 j j+1 j+2 k k+1
Length = [variable] Forward QoS Information Entry { 1-31: Entry Length = [variable] SR_ID = [01H-1FH] Reserved = [000] Forward Flow Count = [1 - 31] Entry Length = [01H] Forward Flow ID = [00H FFH] 5-24 Forward Flow Entry { Forward Flow ID Count :
3GPP2 A.S0008-C v2.0 5.1.2.1 A16-Session Transfer Request 7 6 5 4 3 2 1 0 Octet } Forward Flow Entry } Forward QoS Information Entry Reverse QoS Information: A16 Element Identifier = [13H] 1 2 j j+1 j+2 k k+1 Length = [variable] Reverse QoS Information Entry { 1-31: Entry Length = [variable] SR_ID = [01H-1FH] Reserved = [000] Reverse Flow Entry { Reverse Flow Count : Entry Length = [01H] Reverse Flow ID = [00H FFH] } Reverse Flow Entry } Reverse QoS Information Entry (MSB) Subscriber QoS Profile: A16 Element Identifier = [14H] 1 2 3 4 Length = [variable] Subscriber QoS Profile = <any value> Reverse Flow Count = [1 - 31]
(LSB) Forward QoS Update Information: A16 Element Identifier = [15H] Length = [variable] Reserved = [0000] Forward Flow Entry { Forward Flow ID Count : Forward Flow ID = [00H FFH] Forward Updated QoS Sub-BLOB Length = [variable] (MSB) Forward Updated QoS Sub-BLOB = <any value> (LSB) } Forward Flow Entry Reverse QoS Update Information: A16 Element Identifier = [16H] Length = [variable] Reserved = [0000] Reverse Flow Entry { Reverse Flow ID Count : 5-25 Personality Index = [0H FH] Reverse Flow Count = [01H FFH] Personality Index = [0H FH] Forward Flow Count = [01H FFH]
n 1 2 3 4 i i+1 i+2 i+3 j 1 2 3 4
3GPP2 A.S0008-C v2.0 5.1.2.1 A16-Session Transfer Request 7 6 5 4 3 2 1 0 Octet j j+1 j+2 j+3 (LSB) } Reverse Flow Entry Serving Sector Information {0, 1 Serving Sector Information: A16 Element Identifier = [1CH] Length = [05H] Pilot PN (low part) = <any value> Pilot PN (high part) = <any value> (MSB) Reserved = [000 0000] 1 2 3 4 k Reverse Flow ID = [00H FFH] Reverse Updated QoS Sub-BLOB Length = [variable] (MSB) Reverse Updated QoS Sub-BLOB = <any value>
Channel (LSB)
5 6 7
} Serving Sector Information Sector Endpoint Information {1+: Sector Endpoint Information: A16 Element Identifier = [1EH] Length = [0BH] Pilot PN (low part) = <any value> Pilot PN (high part) = <any value> (MSB) Reserved = [000 0000] 1 2 3 4
Channel (LSB)
5 6 7 8 (LSB) 9 10 11 12 (LSB) 13
(MSB) (MSB)
UDP Port = [0000H FFFFH] IPv4 Address = <any value>
} Sector Endpoint Information 5-26
3GPP2 A.S0008-C v2.0 5.1.2.1 A16-Session Transfer Request 7 (MSB) 6 5 4 3 2 1 0 Octet 1 2 3 4 5 (LSB) Timer { 1: Timer Type = [01H (Tsclose) ] Timer Length = [05H] (MSB) Starting Time n n+1 n+2 n+3 n+4 n+5 (LSB) } Timer RTD Information: A16 Element Identifier = [22H] Length = [03H] Reference Pilot PN (low part) = <any value> Referenc e Pilot PN (high part) = <any value> Reserved = [000 0000] 1 2 3 4 n+6 Timers: A16 Element Identifier = [21H] Length = [07H] 6 1 2 Assigning SC IP Address: A16 Element Identifier = [20H] Length = [04H] Assigning SC IP Address
Round Trip Delay = <any value> Serving Sector ID: A16 Element Identifier = [23H] Length = [11H] Reserved = [000 0000] Sector ID Same as OTA = [0,1]
5 1 2 3
(MSB)
Serving Sector ID = <any value> (LSB) Target Sector ID: A16 Element Identifier = [24H] Length = [11H]
4 19 1 2
5-27
3GPP2 A.S0008-C v2.0 5.1.2.1 A16-Session Transfer Request 7 6 5 4 3 2 1 0 Sector ID Same as OTA = [0,1] Octet 3 Reserved = [000 0000]
(MSB)
Target Sector ID = <any value> (LSB)
4 19
2 3 4
5.1.2.2
A16-Session Transfer Response
This message is sent from the target AN to the source AN in response to an A16-Session Transfer Request message. Information Element A16 Message Type AT-ID Correlation ID Session Transfer Information Proposed Session State Information Record Extended Session State Information Record Section Reference 5.2.2.3 5.2.2.13 5.2.2.25 5.2.2.8 5.2.2.10 5.2.2.12 Element Direction Type Target Source Target Source Target Source Target Source Target Source Target Source O O
a
M R C R R C Og
b c,d,f
Oe,f
5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
a. This IE shall be set to the value of AT-ID in the A16-Session Transfer Request message. b. If SLP Reset Required bit is set to 1 then the source AN shall close the connection when instructing the AT to switch to the target AN during HRPD Hard Handoff. c. The source AN shall modify the main personality of the session according to the included Proposed Session State Information Record before continuing with the session transfer. d. The target AN shall include the necessary Proposed Session State Information Records for the source AN to instruct the AT to connect to the new Active Set. e. The source AN shall modify the non-main personality according to the included Extended Session State Information Record before continuing with the session transfer. f. The target AN shall not request the source AN to both modify the main personality and to set up a new personality and instruct the AT to switch to that new personality. Multiple instances of this IE may be included, where one instance of this IE contains one proposed Session State Information Record for the indicated personality.
g. This IE shall be included if it was also included in the corresponding A16-Session Transfer Request message and shall be set to the value received in that message. If it is not included in the A16-Session Transfer Request message, this IE may be included in this message.
5-28
3GPP2 A.S0008-C v2.0

1 2
The following table shows the bitmap layout for the A16-Session Transfer Response message. 5.1.2.2 A16-Session Transfer Response 7 6 5 4 3 2 1 0 Octet 1 1 2 ATI Type = [0010 (UATI32)] AT-ID 3 4 5 6 (LSB) (MSB) Correlation ID: A16 Element Identifier = [18H] Length = [04H] Correlation Value = <any value> 7 1 2 3 4 5 (LSB) Session Transfer Information: A16 Element Identifier = [0AH] Length = [01H] Reserved = [0000 000] SLP Reset Require d= {0,1} 6 1 2 3 A16 Message Type = [02H] Length = [05H] Reserved = [0000] (MSB)
AT-ID: A16 Element Identifier = [0CH]
Proposed Session State Information Record {0, 1+: (MSB) (MSB) Proposed Session State Information Record: A16 Element Identifier = [04H] Length = [variable] (LSB) Session State Information Record 1 2 3 4
(LSB) } Proposed Session State Information Record Extended Session State Information Record {0, 1+: (MSB) Reserved = [0000] Extended Session State Information Record: A16 Element Identifier = [05H] Length = [variable] (LSB) Personality Index = <any value> 5-29
1 2 3 4
3GPP2 A.S0008-C v2.0 5.1.2.2 A16-Session Transfer Response 7 (MSB) 6 5 4 3 2 1 0 Octet 5 Session State Information Record
(LSB) } Extended Session State Information Record

1
2 3 4
5.1.2.3
A16-Session Transfer Complete
This message is sent from the source AN to the target AN to transfer the control of the AT session and any residual state information. Information Element A16 Message Type AT-ID Correlation ID Session State Information Record Extended Session State Information Record ConfirmedUATI AssignedUATI LCM_UATI SLP-D Parameters SLP-F Parameters SLP Reset Message SEQ Info Fixed Rate Mode Session Transfer Complete Parameters Serving Sector Information Section Reference 5.2.2.3 5.2.2.13 5.2.2.25 5.2.2.10 5.2.2.12 5.2.2.14 5.2.2.15 5.2.2.16 5.2.2.17 5.2.2.18 5.2.2.32 5.2.2.28 5.2.2.26 5.2.2.29 Element Direction Type Source Target Source Target Source Target Source Target Source Target Source Target Source Target Source Target Source Target Source Target Source Target Source Target Source Target Source Target O O
a
M R C C C C C C C C C C C C Og
b
Oc Od Oe O O O O O
O
d f f f h
Oj
5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
a. This IE shall be set to the value of AT-ID in the A16-Session Transfer Request message. b. For hard handoff, multiple instances of this IE may be included, where each instance of this IE contains an Session State Information Record that has been changed from the session indicated by the A16-Session Transfer Request message as modified by the session changes in the A16-Session Transfer Response message. For session transfer with cross-connectivity support, multiple instances of this IE may be included, where each instance of this IE contains an Session State Information Record that has been changed from the latest information acknowledged by the target AN, i.e., the IE sent in A16-Attributes Update message with the largest sequence number that was acknowledged or the IE in A16-Session Transfer Request message if no A16-Attributes Update message was sent. If the value of an Session State Information Record has been changed from a non-default value to the default value, the default value shall also be included. c. For hard handoff, multiple instances of this IE may be included, where each instance of this IE contains an Extended Session State Information Record that has been changed from the session indicated by the A16-Session Transfer Request message as modified by the session changes in the A16-Session Transfer Response message. For session transfer with cross-connectivity support, 5-30
3GPP2 A.S0008-C v2.0

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
multiple instances of this IE may be included, where each instance of this IE contains an Extended Session State Information Record that has been changed from the latest information acknowledged by the target AN, i.e., the IE sent in A16-Attributes Update message with the largest sequence number that was acknowledged or the IE in A16-Session Transfer Request message if no A16-Attributes Update message was sent. If the value of an Extended Session State Information Record has been changed from a non-default value to the default value, the default value shall also be included. d. This IE shall be included if the value of the UATI contained in this IE is different or cannot be derived from AT-ID. e. This IE shall be included only if the session transfer is performed while there is an outstanding UATIAssignment message [10] for which the source AN has not received a confirmation. f. This IE shall be included only if the source AN wants to transfer the SLP state [20] [10] to the target AN.
g. This IE shall only be included if it was also included in the A16-Session Transfer Response message and shall be set to the value received in that message. h. This IE shall be included only if the session transfer is performed while the Forward Traffic Channel MAC protocol is in the Fixed Rate State [10]. i. j. This IE shall be included only for make-before-break session transfer. This IE carries the sector information of the current serving sector to the target AN. This IE is included if the information is available at the source AN and has been changed from the latest information acknowledged by the target AN, i.e., the IE sent in A16-Attributes Update message with the largest sequence number that was acknowledged or the IE in A16-Session Transfer Request message if no A16-Attributes Update message was sent.
The following table shows the bitmap layout for the A16-Session Transfer Complete message. 5.1.2.3 A16-Session Transfer Complete 7 6 5 4 3 2 1 0 Octet 1 1 2 ATI Type = [0010 (UATI32)] AT-ID 3 4 5 6 (LSB) (MSB) Correlation ID: A16 Element Identifier = [18H] Length = [04H] Correlation Value = <any value> 7 1 2 3 4 5 (LSB) Session State Information Record {0, 1+ 5-31 6 A16 Message Type = [03H] Length = [05H] Reserved = [0000] (MSB)
3GPP2 A.S0008-C v2.0 5.1.2.3 A16-Session Transfer Complete 7 (MSB) (MSB) 6 5 4 3 2 1 0 Octet 1 2 (LSB) Session State Information Record 3 4 Session State Information Record: A16 Element Identifier = [03H] Length = [variable]
(LSB) } Session State Information Record Extended Session State Information Record {0, 1+: (MSB) Reserved = [0000] (MSB) Extended Session State Information Record: A16 Element Identifier = [05H] Length = [variable] (LSB) Personality Index Session State Information Record
1 2 3 4 5
(LSB) } Extended Session State Information Record (MSB) ConfirmedUATI: A16 Element Identifier = [0DH] Length = [10H] ConfirmedUATI = <any value>
n 1 2 3 4
(LSB) AssignedUATI {0,1 (MSB) AssignedUATI: A16 Element Identifier = [0EH] Length = [10H] AssignedUATI = <any value> 1 2 3 4 18
(LSB) } AssignedUATI (MSB) LCM_UATI: A16 Element Identifier = [0FH] Length = [10H] LCM_UATI = <any value> 1 2 3 4 18
(LSB) 5-32 18
3GPP2 A.S0008-C v2.0 5.1.2.3 A16-Session Transfer Complete 7 6 5 4 3 2 1 0 Octet 1 2 SLPD_VN = [0H FH] RxVector = [00H FFH] SLPD_VS = [0H FH] (MSB) (MSB) (MSB) (LSB) SLPD_OutstandingCount = [0H FH] (LSB) (LSB) 3 4 5 1 2 3 4 5 SLP Parameters {0, 1 SLP-D Parameters: A16 Element Identifier = [10H] Length = [variable] Reserved (MSB)
If (SLPD_OutstandingCount > 0) { SLPD_OutstandingCount Time2Rexmit = [00H FFH] NumXmitted = [0H FH] SLPD_PayloadLength = [00H FFH] SLPD_Payload SPLD_SequenceNumber = [0H FH]
(LSB) } (SLPD_OutstandingCount > 0) Reserved SLPF_S ync SLP-F Parameters: A16 Element Identifier = [11H] Length = [variable] SLPF_VS LastSequenceNumber SLPF_BufferLength = [00H FFH] SLPF_Buffer (LSB) 1 2 3 4 5 1 2 m
Reserved (MSB) (MSB) SLPF_Buffer { SLPF_BufferLength
(LSB) } SLPF_Buffer } SLP Parameters SLP Reset Message SEQ Info {0,1 (MSB) SLP Reset Message SEQ Info: A16 Element Identifier = [1FH] Length = [01H] SLP Reset Message SEQ Info = <any value> (LSB) } SLP Reset Message SEQ Info Fixed Rate Mode {0, 1 Fixed Rate Mode: A16 Element Identifier = [1BH] Length = [0AH] 5-33 1 2 1 2 3 n
3GPP2 A.S0008-C v2.0 5.1.2.3 A16-Session Transfer Complete 7 Pilot PN (high part) = <any value> (MSB) 6 5 4 3 2 1 0 Octet 3 4 Pilot PN (low part) = <any value> Reserved = [000 0000]
Channel (LSB)
5 6 7 8 9 (LSB) 10
(MSB) (MSB) } Fixed Rate Mode
DRC Value = [00H 0FH] EndTime = [0000H FFFFH]
(LSB)
Session Transfer Complete Parameters {0, 1: (MSB) (MSB) Serving Sector Information {0, 1 (MSB) Pilot PN (high part) = <any value> (MSB) Serving Sector Information: A16 Element Identifier = [1CH] Length = [05H] Pilot PN (low part) = <any value> Reserved = [000 0000] 1 2 3 4 Session Transfer Complete Parameters: A16 Element Identifier = [19H] Length = [03H] Timestamp (LSB) Sequence Number (LSB) } Session Transfer Complete Parameters 1 2 3 4 5
Channel (LSB)
5 6 7
} Serving Sector Information

1 2 3
5.1.2.4
A16-Session Release Indication
This message is sent from the target AN to the source AN. This message indicates that the source AN may purge the session associated with the AT. Information Element A16 Message Type Section Reference 5.2.2.3 5-34 Element Direction Type Target Source M
3GPP2 A.S0008-C v2.0 Information Element AT-ID Correlation ID

1 2 3 4 5
Element Direction Type Target Source Target Source Oa O

b
R C
a. This IE shall be set to the value of AT-ID in the A16-Session Transfer Request message. b. If this IE is included in this message, its value shall be returned in the Correlation ID IE in the corresponding A16-Session Release Indication Ack message. The following table shows the bitmap layout for the A16-Session Release Indication message. 5.1.2.4 A16-Session Release Indication 7 6 5 4 3 2 1 0 Octet 1 1 2 ATI Type = [0010 (UATI32)] AT-ID 3 4 5 6 (LSB) (MSB) Correlation ID: A16 Element Identifier = [18H] Length = [04H] Correlation Value = <any value> 7 1 2 3 4 5 (LSB) 6 A16 Message Type = [04H] Length = [05H] Reserved = [0000] (MSB)
6 7
5.1.2.5
A16-Session Release Indication Ack
This message is sent in response to an A16-Session Release Indication message. Information Element A16 Message Type AT-ID Correlation ID Section Reference 5.2.2.3 5.2.2.13 5.2.2.25 Element Direction Type Source Target Source Target Source Target O
a
M R C Ob
8 9 10 11
a. This IE shall be set to the value of AT-ID in the A16-Session Transfer Request message. b. This IE shall only be included if it was also included in the A16-Session Release Indication message and shall be set to the value received in that message.
5-35
3GPP2 A.S0008-C v2.0

1
The following table shows the bitmap layout for the A16-Session Release Indication Ack message. 5.1.2.5 A16-Session Release Indication Ack 7 6 5 4 3 2 1 0 Octet 1 1 2 ATI Type = [0010 (UATI32)] AT-ID 3 4 5 6 (LSB) (MSB) Correlation ID: A16 Element Identifier = [18H] Length = [04H] Correlation Value = <any value> 7 1 2 3 4 5 (LSB) 6 A16 Message Type = [05H] Length = [05H] Reserved = [0000] (MSB)
3 4 5
5.1.2.6
A16-Session Transfer Abort
This message is sent from either the source or the target AN to the other AN to abort the session transfer for the AT. Information Element A16 Message Type AT-ID Correlation ID Session Transfer Abort Cause Section Reference 5.2.2.3 5.2.2.13 5.2.2.25 5.2.2.9 Element Direction Type Source Target Source Target Source Target Source Target O O
a b
M R C R
6 7 8 9 10
a. This IE shall be set to the value of AT-ID in the A16-Session Transfer Request message. b. If this IE is included in this message, its value shall be returned in the Correlation ID IE in the corresponding A16-Session Transfer Abort Ack message. The following table shows the bitmap layout for the A16-Session Transfer Abort message. 5.1.2.6 A16-Session Transfer Abort 7 6 5 4 3 2 1 0 Octet 1 1 2 3 4 A16 Message Type = [06H] Length = [05H] Reserved = [0000] (MSB) ATI Type = [0010 (UATI32)] AT-ID 5-36
3GPP2 A.S0008-C v2.0 5.1.2.6 A16-Session Transfer Abort 7 6 5 4 3 2 1 0 Octet 5 6 (LSB) (MSB) Correlation ID: A16 Element Identifier = [18H] Length = [04H] Correlation Value = <any value> 7 1 2 3 4 5 (LSB) (MSB)
1
6 1 2 3
Session Transfer Abort Cause: A16 Element Identifier = [0BH] Length = [01H] Abort Cause Value = <any value> (LSB)
2 3
5.1.2.7
A16-Session Transfer Abort Ack
This message is sent in response to an A16-Session Transfer Abort message. Information Element A16 Message Type AT-ID Correlation ID Section Reference 5.2.2.3 5.2.2.13 5.2.2.25 Element Direction Type Target Source Target Source Target Source O
a
M R C Ob
4 5 6 7 8
a. This IE shall be set to the value of AT-ID in the A16-Session Transfer Request message. b. This IE shall only be included if it was also included in the A16-Session Transfer Abort message and shall be set to the value received in that message. The following table shows the bitmap layout for the A16-Session Transfer Abort Ack message. 5.1.2.7 A16-Session Transfer Abort Ack 7 6 5 4 3 2 1 0 Octet 1 1 2 ATI Type = [0010 (UATI32)] AT-ID 3 4 5 6 (LSB) Correlation ID: A16 Element Identifier = [18H] 5-37 7 1 A16 Message Type = [07H] Length = [05H] Reserved = [0000] (MSB)
3GPP2 A.S0008-C v2.0 5.1.2.7 A16-Session Transfer Abort Ack 7 (MSB) 6 5 4 3 2 1 0 Octet 2 3 4 5 (LSB)
1
Length = [04H] Correlation Value = <any value>
2 3 4
5.1.2.8
A16-Session Transfer Reject
This message is sent from the target AN to the source AN in response to an A16-Session Transfer Request message to reject the session transfer request from the source AN. Information Element A16 Message Type AT-ID Correlation ID Session Transfer Reject Cause Section Reference 5.2.2.3 5.2.2.13 5.2.2.25 5.2.2.24 Element Direction Type Target Source Target Source Target Source Target Source O O
a
M R C R Ob
5 6 7 8 9 10
a. This IE shall be set to the value of AT-ID in the A16-Session Transfer Request message. b. This IE shall only be included if it was also included in the A16-Session Transfer Request message and shall be set to the value received in that message. The following table shows the bitmap layout for the A16-Session Transfer Reject message. 5.1.2.8 A16-Session Transfer Reject 7 6 5 4 3 2 1 0 Octet 1 1 2 ATI Type = [0010 (UATI32)] AT-ID 3 4 5 6 (LSB) (MSB) Correlation ID: A16 Element Identifier = [18H] Length = [04H] Correlation Value = <any value> 7 1 2 3 4 5 (LSB) 5-38 6 A16 Message Type = [08H] Length = [05H] Reserved = [0000] (MSB)
3GPP2 A.S0008-C v2.0 5.1.2.8 A16-Session Transfer Reject 7 6 5 4 3 2 1 0 Octet 1 2 3 Session Transfer Reject Cause: A16 Element Identifier = [17H] Length = [01H] Cause Value = [ 00H (No reason specified), 01H (The target AN cannot support some Session State Information Records and/or Extended Session State Information Records), 02H (Insufficient radio resources in the target AN to support the session), 03H (Insufficient network resources in the target AN to support the session), 04H (Equipment failure), 05H (Make before break is not supported)]
1
2 3 4 5
5.1.2.9
A16-FL Signal Tunnel
This message is sent from the slave AN to the A16 Endpoint ID corresponding to an AT at the master AN during make-before-break session transfer to request the master AN to transmit the encapsulated signaling message to the AT. Information Element A16 Message Type AT-ID FL Signal Tunnel Parameter Sequence Number Encapsulated Message Section Reference 5.2.2.3 5.2.2.13 5.2.2.30 5.2.2.27 5.2.2.6 Element Direction Type Slave Master Slave Master Slave Master Slave Master Slave Master Oa O O
b
M R R R R
Oc
d
6 7 8 9 10 11 12 13 14
a. This IE shall be set to the value of AT-ID in the A16-Session Transfer Request message. This element shall follow A16 Message Type. b. This IE shall be set to indicate whether the encapsulated signaling message should be transmitted reliably over the air interface. c. This IE carries the sequence number associated with the encapsulated message. d. This IE carries the signaling message that the slave AN is requesting the master AN to transmit to the AT. The following table shows the bitmap layout for the A16-FL Signal Tunnel message. 5.1.2.9 A16-FL Signal Tunnel 7 6 (MSB) 5 4 3 2 1 0 Octet 1 1 2 3 4 5 5-39 A16 Message Type = [09H] Length = [04H] AT-ID
3GPP2 A.S0008-C v2.0 5.1.2.9 A16-FL Signal Tunnel 7 6 5 4 3 2 1 0 (LSB) FL Signal Tunnel Parameter: A16 Element Identifier = [1DH] Length = [01H] Reserved = [0000 000] (MSB) (MSB) Sequence Number: A16 Element Identifier = [1AH] Length = [01H] Sequence Number Encapsulated Message: A16 Element Identifier = [09H] Length = [variable] Protocol Type and Subtype = [000000H FFFFFFH] (LSB) (MSB) Encapsulated Message (LSB)
1
Octet 6 1 2 3 1 2
Reliable Flag
(LSB)
3 1 2 3 4 5 6 n
2 3 4
5.1.2.10
A16-FL Signal Tunnel Ack
This message is sent from the master AN to the slave AN in response to an A16-FL Signal Tunnel message. Information Element A16 Message Type AT-ID Sequence Number Section Reference 5.2.2.3 5.2.2.13 5.2.2.27 Element Direction Type Master Slave Master Slave Master Slave O O
a b
M R R
5 6 7 8 9 10
a. This IE shall be set to the value of AT-ID in the A16-Session Transfer Request message. This element shall follow A16 Message Type. b. This IE carries the largest consecutive sequence number of the A16-FL Signal Tunnel messages that the master AN has received. The following table shows the bitmap layout for the A16-FL Signal Tunnel Ack message. 5.1.2.10 7 6 (MSB) 5 4 A16-FL Signal Tunnel Ack 3 2 1 0 Octet 1 1 2 3
A16 Message Type = [0AH] Length = [04H] AT-ID 5-40
3GPP2 A.S0008-C v2.0 5.1.2.10 7 6 5 4 A16-FL Signal Tunnel Ack 3 2 1 0 Octet 4 5 (LSB) (MSB)
1 2 3
6 1 2
Sequence Number: A16 Element Identifier = [1AH] Length = [01H] Sequence Number (LSB)
5.1.2.11
A16-RL Signal Tunnel
This message is sent from the master AN to the A16 Endpoint ID corresponding to an AT at the slave AN to relay an air-interface signaling message that terminates at the slave AN for the AT. Information Element A16 Message Type AT-ID Sequence Number Encapsulated Message Section Reference 5.2.2.3 5.2.2.13 5.2.2.27 5.2.2.6 Element Direction Type Master Slave Master Slave Master Slave Master Slave O O O
a b c
M R R R
4 5 6 7 8 9
a. This IE shall be set to the value of AT-ID in the A16-Session Transfer Request message. This element shall follow A16 Message Type. b. This IE carries the sequence number associated with the encapsulated message. c. This IE carries the signaling message that the master AN is forwarding to the slave AN. The following table shows the bitmap layout for the A16-RL Signal Tunnel message. 5.1.2.11 7 6 (MSB) 5 4 A16-RL Signal Tunnel 3 2 1 0 Octet 1 1 2 3 4 5 (LSB) (MSB) (MSB) Sequence Number: A16 Element Identifier = [1AH] Length = [01H] Sequence Number Encapsulated Message: A16 Element Identifier = [09H] Length = [variable] Protocol Type and Subtype = [000000H FFFFFFH] (LSB) 6 1 2 3 1 2 3 4 5-41
A16 Message Type = [0BH] Length = [04H] AT-ID
3GPP2 A.S0008-C v2.0 5.1.2.11 7 (MSB) 6 5 4 A16-RL Signal Tunnel 3 2 1 0 (LSB) Encapsulated Message (LSB)
1 2 3
Octet 5 6 n
5.1.2.12
A16-RL Signal Tunnel Ack
This message is sent from the slave AN to the master AN in response to an A16-RL Signal Tunnel message. Information Element A16 Message Type AT-ID Sequence Number Section Reference 5.2.2.3 5.2.2.13 5.2.2.27 Element Direction Type Slave Master Slave Master Slave Master O O
a b
M R R
4 5 6 7 8 9
a. This IE shall be set to the value of AT-ID in the A16-Session Transfer Request message. This element shall follow A16 Message Type. b. This IE carries the largest consecutive sequence number of the A16-RL Signal Tunnel message that the slave AN has received. The following table shows the bitmap layout for the A16-RL Signal Tunnel Ack message. 5.1.2.12 7 6 (MSB) 5 4 A16-RL Signal Tunnel Ack 3 2 1 0 Octet 1 1 2 3 4 5 (LSB) (MSB) Sequence Number: A16 Element Identifier = [1AH] Length = [01H] Sequence Number (LSB) 6 1 2 3
A16 Message Type = [0CH] Length = [04H] AT-ID
10
11 12 13
5.1.2.13
A16-Attributes Update
This message is sent from the master AN to the A16 Endpoint ID at the slave AN to update the Session State Information Records in the slave AN. Information Element A16 Message Type Section Reference 5.2.2.3 5-42 Element Direction Master Slave Type M
3GPP2 A.S0008-C v2.0 AT-ID Sequence Number Session State Information Record Extended Session State Information Record Proposed Session State Information Record Serving Sector Information Sector Endpoint Information
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
5.2.2.13 5.2.2.27 5.2.2.10 5.2.2.12 5.2.2.11 5.2.2.29 5.2.2.31
Master Slave Master Slave Master Slave Master Slave Master Slave Master Slave Master Slave
Oa Ob O O
c d
R R C C C C C
Oe Of O
g
a. This IE shall be set to the value of AT-ID in the A16-Session Transfer Request message. This element shall follow A16 Message Type. b. This IE carries the sequence number associated with the message. c. Multiple instances of this IE may be included, where each instance of this IE contains a Session State Information Record that has been changed from the latest information acknowledged by the target AN, i.e., the IE sent in A16-Attributes Update message with the largest sequence number that was acknowledged or the IE in A16-Session Transfer Request message if no A16-Attributes Update message was sent. If the value of a Session State Information Record has been changed from a nondefault value to the default value, the default value shall also be included. d. Multiple instances of this IE may be included, where each instance of this IE contains an Extended Session State Information Record that has been changed from the latest information acknowledged by the target AN, i.e., the IE sent in A16-Attributes Update message with the largest sequence number that was acknowledged or the IE in A16-Session Transfer Request message if no A16-Attributes Update message was sent. If the value of an Extended Session State Information Record has been changed from a non-default value to the default value, the default value shall also be included. e. This IE is included when the message is sent to trigger the slave AN to add new sectors into the Active Set (refer to section 3.12.5.3). f. This IE carries sector information of the current serving sector to the target AN. This IE is included if the information is available at the source AN and has been changed from the latest information acknowledged by the target AN, i.e., the IE sent in A16-Attributes Update message with the largest sequence number that was acknowledged or the IE in A16-Session Transfer Request message if no A16-Attributes Update message was sent.
g. Multiple instances of this IE may be included, where one instance of this IE contains one sector information in the Active Set and the associated IP address and UDP port information. Both those sectors already attached and those sectors to be attached are included, and those sectors to be released are not included in the A16-Attributes Update message. When the slave AN determines that sectors are newly added, the slave AN may send an A17-Slave Attach Request message to the IP address and UDP port during connected-state session transfer with cross-connectivity support to attach to the newly added sector. When the slave AN determines that sectors are newly dropped (e.g. the sectors are no longer included), the slave AN may send an A17-Slave Detach Request message to the IP address and UDP port during connected-state session transfer with cross-connectivity support to detach to the newly dropped sector. The following table shows the bitmap layout for the A16-Attributes Update message. 5.1.2.13 7 6 5 4 A16-Attributes Update 3 2 1 0 Octet 1
A16 Message Type = [0DH] 5-43
3GPP2 A.S0008-C v2.0 5.1.2.13 7 6 (MSB) 5 4 A16-Attributes Update 3 2 1 0 Octet 1 2 3 4 5 (LSB) (MSB) (MSB) (MSB) Sequence Number: A16 Element Identifier = [1AH] Length = [01H] Sequence Number (LSB) Session State Information Record {0, 1+: Session State Information Record: A16 Element Identifier = [03H] Length = [variable] (LSB) Session State Information Record = <any value> (LSB) } Session State Information Record Extended Session State Information Record {0, 1+ (MSB) Reserved = [0 0000] (MSB) Extended Session State Information Record: A16 Element Identifier = [05H] Length = [variable] (LSB) Personality Index Session State Information Record (LSB) } Extended Session State Information Record Proposed Session State Information Record {0, 1+: (MSB) (MSB) Proposed Session State Information Record: A16 Element Identifier = [04H] Length = [variable] (LSB) Proposed Session State Information Record = <any value> (LSB) } Proposed Session State Information Record Serving Sector Information {0, 1 Serving Sector Information: A16 Element Identifier = [1CH] 5-44 1 1 2 3 4 n 1 2 3 4 5 n 1 2 3 4 n 6 1 2 3
AT-ID: A16 Element Identifier = [0CH] Length = [04H] AT-ID
3GPP2 A.S0008-C v2.0 5.1.2.13 7 (MSB) Pilot PN (high part) = <any value> (MSB) 6 5 4 A16-Attributes Update 3 2 1 0 Octet 2 3 4
Length = [05H] Pilot PN (low part) = <any value> Reserved = [000 0000]
Channel (LSB)
5 6 7
} Serving Sector Information Sector Endpoint Information {1+: Sector Endpoint Information: A16 Element Identifier = [1EH] Length = [0BH] Pilot PN (low part) = <any value> Pilot PN (high part) = <any value> (MSB) Reserved = [000 0000] 1 2 3 4
Channel (LSB)
5 6 7 8 (LSB) 9 10 11 12 (LSB) 13
(MSB) (MSB)
UDP Port = [0000H FFFFH] IPv4 Address = <any value>
} Sector Endpoint Information

1
2 3 4
5.1.2.14
A16-Attributes Update Ack
This message is sent from the slave AN to the master AN to acknowledge the receipt an A16-Attributes Update message from the master AN. Information Element A16 Message Type AT-ID Sequence Number Section Reference 5.2.2.3 5.2.2.13 5.2.2.27 5-45 Element Direction Slave Master Slave Master Slave Master O
a
Type M R R Ob
3GPP2 A.S0008-C v2.0

1 2 3 4 5
a. This IE shall be set to the value of AT-ID in the A16-Session Transfer Request message. This IE shall follow A16 Message Type. b. This IE carries the largest consecutive sequence number of the A16-Attributes Update message that the slave AN has received. The following table shows the bitmap layout for the A16-Attributes Update Ack message. 5.1.2.14 7 6 (MSB) 5 4 A16-Attributes Update Ack 3 2 1 0 Octet 1 1 2 3 4 5 (LSB) (MSB) Sequence Number: A16 Element Identifier = [1AH] Length = [01H] Sequence Number (LSB) 6 1 2 3
A16 Message Type = [0EH] Length = [04H] AT-ID
7 8 9
5.1.3
A17 Message Definitions
Note: The A17, A18 and A19 interfaces share a common set of IEIs and are identified by the first interface listed, A17. 5.1.3.1 A17-Allocate Request
10 11 12
This message is sent from the source AN to the target AN to request allocation of resources at sectors belonging to the target AN to support soft/softer handoff for a specific AT. Information Element Message Type III AT-ID Correlation ID Current Record Session State Information Section Reference 5.2.3.3 5.2.3.4 5.2.3.9 5.2.3.5 5.2.3.6 5.2.3.28 5.2.3.29 Element Direction Source Target Source Target Source Target Source Target Source Target Source Target Source Target O O O
a b c
Type M R C R R R R
Proposed Session State Information Record AN Leg Information Leg-Sector Association

13 14 15 16 17
Od Oe O
a. This IE identifies the session of the AT and shall be set to the LCM_UATI. b. If this IE is included in this message, its value shall be returned in the Correlation ID IE in the corresponding A17-Allocate Response message. c. Multiple instances of this IE may be included for all sectors that the source AN requests resource allocation, where one instance of this IE contains one Session State Information Record of the current 5-46
3GPP2 A.S0008-C v2.0

1 2 3 4 5 6 7 8 9
personality in the source AN. If the SSIR for the current personality includes hard link to the main personality, this IE shall include the Session State Information Record of the main personality instead of including hard link. d. This IE contains information for all sectors that the source AN requests resource allocation. Certain fields need to be filled in by the target AN for each sector that the target AN adds to the ATs Active Set. 42 e. One instance of this IE is included for each RT for which the source AN requests resource allocation. Multiple instances of this IE may be included. The following table shows the bitmap layout for the A17-Allocate Request message. 5.1.3.1 A17-Allocate Request 7 6 5 4 3 2 1 0 Octet 1 1 2 3 4 5 6 (LSB) (MSB) Correlation ID: A17 Element Identifier = [0BH] Length = [04H] Correlation Value = <any value> 7 1 2 3 4 5 (LSB) Session State Information Record {1+: (MSB) (MSB) Current Session State Information Record: A17 Element Identifier = [02H] Length = [variable] (LSB) Session State Information Record = <any value> 1 2 3 4 6 Message Type III = [01H] Length = [05H] Reserved = [0000] (MSB) ATI Type = [0010 (UATI32)] AT-ID
AT-ID: A17 Element Identifier = [21H]
(LSB) } Session State Information Record Proposed Session State Information Record {1:
42 If Default RouteUpdate protocol [10] is in use, the Proposed Session State Information Record contains the RouteUpdate Parameter Record [10] and the target AN shall fill in values for either MACIndex or MACIndexLSB and MACIndexMSB [10] as appropriate in the A17-Allocate Response message. The source AN shall set MACIndexLSBs to 0.
5-47
3GPP2 A.S0008-C v2.0 5.1.3.1 A17-Allocate Request 7 6 (MSB) (MSB) 5 4 3 2 1 0 Octet 1 2 (LSB) Proposed Session State Information Record = <any value> 3 4 Proposed Session State Information Record: A17 Element Identifier = [03H] Length = [variable]
(LSB) } Proposed Session State Information Record AN Leg Information: A17 Element Identifier = [22H] Length = [variable] Leg Number = [00H FFH] AN A19 Control Endpoint ID { 1:
AT-ID Required Flag = [0, 1]
n 1 2 3 4
Endpoint Type = [01H (UDP/IPv4)]
(MSB) (MSB)
UDP Port = [0000H FFFFH] (LSB) IPv4 Address = <any value>
5 6 7 8 9 (LSB) 10
} AN A19 Control Endpoint ID AN A18 Data Endpoint ID { 1:

11
(MSB) (MSB)
12 13 14 15 16 (LSB) 17 1 2 3 4
} AN A18 Data Endpoint ID Leg-Sector Association: A17 Element Identifier = [23H] Length = [variable] Leg Number = [00H FFH] Sector Information Count = [01H FFH] 5-48
3GPP2 A.S0008-C v2.0 5.1.3.1 A17-Allocate Request 7 6 5 4 3 2 1 0 Octet Sector and Parameter Entry{ Sector Information Count: Sector Information { 1: Sector Information Type = [01H (Pilot PN and Channel)] Sector Information Length = [05H] (MSB) (MSB) Pilot PN (LSB) Channel (LSB) } Sector Information Sector Parameter { 1: Parameter Type = [01H (RTDT Estimation)] Parameter Length = [01H] Round Trip Delay Time (RTDT) Estimation Parameter } Sector Parameter } Sector and Parameter Entry
1 2 3
n n+1 n+2 n+3 n+4 n+5 n+6
n+7 n+8 n+9
5.1.3.2
A17-Allocate Response
This message is sent from the target AN to the source AN in response to an A17-Allocate Request message from the source AN. Information Element Message Type III AT-ID Correlation ID Proposed Session State Information Record RT Leg Information Section Reference 5.2.3.3 5.2.3.4 5.2.3.9 5.2.3.6 5.2.3.30 Element Direction Target Source Target Source Target Source Target Source Target Source Oa O
b
Type M R C C C
Oc Od
4 5 6 7 8 9 10
a. The target AN shall set the value of this IE to the value of the AT-ID IE of the A17-Allocate Request message to which it is responding. b. This IE shall be included if it was also included in the A17-Allocate Request message and shall be set to the value received in that message. c. If the target AN adds at least one sector to the ATs Active Set as requested by the source AN in the A17-Allocate Request message to which it is responding, it shall set the value of this IE to the Proposed Session State Information Record of the A17-Allocate Request message. The target AN
5-49
3GPP2 A.S0008-C v2.0

1 2 3 4 5 6
shall fill in the appropriate fields of the Proposed Session State Record for each sector that it adds to the ATs Active Set. 43 Otherwise, this IE is not included. d. One instance of this IE is included for each RT for which the target AN allocates resources as requested by the source AN in the A17-Allocate Request message. Multiple instances of this IE may be included. The following table shows the bitmap layout for the A17-Allocate Response message. 5.1.3.2 A17-Allocate Response 7 6 5 4 3 2 1 0 Octet 1 1 2 3 4 5 6 (LSB) (MSB) Correlation ID: A17 Element Identifier = [0BH] Length = [04H] Correlation Value = <any value> 7 1 2 3 4 5 (LSB) Proposed Session State Information Record {0, 1: (MSB) (MSB) Proposed Session State Information Record: A17 Element Identifier = [03H] Length = [variable] (LSB) Proposed Session State Information Record = <any value> 1 2 3 4 6 Message Type III = [02H] Length = [05H] Reserved = [0000] (MSB) ATI Type = [0010 (UATI32)] AT-ID
(LSB) } Proposed Session State Information Record RT Leg Information: A17 Element Identifier = [24H] Length = [variable] Leg Number = [00H FFH] RT A19 Control Endpoint ID { 1:
m 1 2 3
43 If Default RouteUpdate protocol [10] is in use, the Proposed Session State Information Record contains the RouteUpdate Parameter Record [10] and the target AN shall fill in values for either MACIndex or MACIndexLSB and MACIndexMSB [10] as appropriate, and shall not change other parameters.
5-50
3GPP2 A.S0008-C v2.0 5.1.3.2 A17-Allocate Response 7

Octet 4
(MSB) (MSB)
5 6 7 8 9 (LSB) 10
} RT A19 Control Endpoint ID RT A18 Data Endpoint ID { 1:

11
(MSB) (MSB)
12 13 14 15 16 (LSB) 17
} RT A18 Data Endpoint ID RT Parameter { 1: Parameter Type = [01H (RT Buffer Size)] Parameter Length = [02H] (MSB) } RT Parameter
1 2 3
n n+1 n+2 (LSB) n+3
Buffer Size = [0000H FFFFH]
5.1.3.3
A17-Set Attributes
This message is sent from the source AN to the target AN to update resources at sectors belonging to the target AN to support soft/softer handoff for a specific AT. Information Element Message Type III AT-ID Correlation ID Current Record Session State Information Section Reference 5.2.3.3 5.2.3.4 5.2.3.9 5.2.3.5 5-51 Element Direction Source Target Source Target Source Target Source Target O O
a
Type M R C C Ob
c
3GPP2 A.S0008-C v2.0 Information Element Alternative Session State Information Record AT Acquired Flag RTCH Power Control Setpoint Power Ramp-Up Bias
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
Section Reference 5.2.3.7 5.2.3.10 5.2.3.11 5.2.3.13
Element Direction Source Target Source Target Source Target Source Target
Type Od Oe O
f
C C C C
Og
a. The source AN shall set the value of this IE to the value of AT-ID in the A17-Allocate Request message. b. If this IE is included in this message, its value shall be returned in the Correlation ID IE in the corresponding A17-Set Attributes Ack message. c. Multiple instances of this IE may be included for all sectors that the source AN updates resources, where one instance of this IE contains one Session State Information Record of the current personality in the source AN. If the SSIR for the current personality includes hard link to the main personality, this IE shall include the Session State Information Record of the main personality instead of including hard link. d. This IE is included for an SSIR when the value of one or more of its session parameters/attributes will change after the traffic channels are updated. 44 This IE contains the new value(s) to be used after the traffic channels are updated. Multiple instances of this IE may be included, one instance per SSIR. e. This IE is included if the source AN indicates to the target AN that the ATs reverse traffic channel has been acquired by an RT during connection setup and add pilot. f. This IE is included if the source AN indicates to the target AN the reverse traffic channel power setpoint 45 to be used by sectors belonging to the target AN that are in the ATs Active Set.
g. This IE is included if the source AN indicates to the target AN a reverse power control upward bias to be used by sectors belonging to the target AN that are in the ATs Active Set for reverse power control during AT connection setup. 46 The following table shows the bitmap layout for the A17-Set Attributes message. 5.1.3.3 A17-Set Attributes 7 6 5 4 3 2 1 0 Octet 1 1 2 3 4 5 Message Type III = [03H] Length = [05H] Reserved = [0000] (MSB) ATI Type = [0010 (UATI32)] AT-ID
44 45 46
For Default RouteUpdate protocol [10], the DRCLength parameter [10] being used by the AT is not known until the traffic channels are updated. For example, the sectors will attempt to power control the AT via power control decisions sent on the forward link so that the received pilot Eo/Nt matches the supplied value [10]. For example, this helps the sectors achieve a certain power ramp-up bias during connection setup by having them send power up and down commands pseudo-randomly with a bias towards the up command, where the power up and down commands are sent on the Reverse Power Control Channel (RPC) as defined in [10].
5-52
3GPP2 A.S0008-C v2.0 5.1.3.3 A17-Set Attributes 7 6 5 4 3 2 1 0 (LSB) (MSB) Correlation ID: A17 Element Identifier = [0BH] Length = [04H] Correlation Value = <any value> Octet 6 7 1 2 3 4 5 (LSB) Session State Information Record {0, 1+: (MSB) (MSB) Current Session State Information Record: A17 Element Identifier = [02H] Length = [variable] (LSB) Session State Information Record = <any value> 1 2 3 4 6
(LSB) } Session State Information Record Alternative Session State Information Record {0, 1: (MSB) (MSB) Alternative Session State Information Record: A17 Element Identifier = [04H] Length = [variable] (LSB) Alternative Session State Information Record = <any value>
1 2 3 4
(LSB) } Alternative Session State Information Record AT Acquired Flag {0, 1: } AT Acquired Flag RTCH Power Control Setpoint {0, 1: Reserved = [0] RTCH Power Control Setpoint: A17 Element Identifier = [0DH] Length = [01H] RTCH Power Control Setpoint = [00H- 7FH] AT Acquired Flag: A17 Element Identifier = [0CH] Length = [00H]
1 2
1 2 3
} RTCH Power Control Setpoint Power Ramp-Up Bias {0, 1: 5-53
3GPP2 A.S0008-C v2.0 5.1.3.3 A17-Set Attributes 7 6 5 4 3 2 1 0 Octet 1 2 3 Power Ramp-Up Bias: A17 Element Identifier = [0FH] Length = [01H] Power Ramp-Up Bias = [00H 28H] } Power Ramp-Up Bias
1 2 3
5.1.3.4
A17-Set Attributes Ack
This message is sent from the target AN to the source AN to acknowledge the receipt an A17-Set Attributes message from the source AN. Information Element Message Type III AT-ID Correlation ID A17 Cause Section Reference 5.2.3.3 5.2.3.4 5.2.3.9 5.2.3.32 Element Direction Target Source Target Source Target Source Target Source O O
a b
Type M R C C
Oc
4 5 6 7 8 9 10 11
a. The target AN shall set the value of this IE to the value of the AT-ID IE of the A17-Set Attributes message to which it is responding. b. This IE shall be included if it was also included in the corresponding A17-Set Attributes message and shall be set to the value received in that message. c. When the target AN is unable to process the received A17-Set Attributes message, this IE is included to indicate the cause of failure. When the source AN receives this IE, the source AN assumes that the session information at the target AN did not change per the A17-Set Attributes message. The following table shows the bitmap layout for the A17-Set Attributes Ack message. 5.1.3.4 A17-Set Attributes Ack 7 6 5 4 3 2 1 0 Octet 1 1 2 3 4 5 6 (LSB) (MSB) Correlation ID: A17 Element Identifier = [0BH] Length = [04H] Correlation Value = <any value> 7 1 2 3 4 5 (LSB) 5-54 6 Message Type III = [04H] Length = [05H] Reserved = [0000] (MSB) ATI Type = [0010 (UATI32)] AT-ID
3GPP2 A.S0008-C v2.0 5.1.3.4 A17-Set Attributes Ack 7 6 5 4 3 2 1 0 Octet 1 2 3 A17 Cause: A17 Element Identifier = [26H] Length = [01H] Cause Value = [ 02H (Reject No reason specified), 03H (Reject Radio resource unavailable), 04H (Reject Network resource unavailable), 07H (Equipment failure) ]
1 2 3 4
5.1.3.5
A17-Modify Request
This message is sent from the source AN to the target AN to request modification of resources at sectors belonging to the target AN to support soft/softer handoff for a specific AT. This message is sent only if the source AN does not know a priori that the target AN will accept the resource modification request. Information Element Message Type III AT-ID Correlation ID Proposed Session State Information Record Rapid Commit Section Reference 5.2.3.3 5.2.3.4 5.2.3.9 5.2.3.6 5.2.3.23 Element Direction Source Target Source Target Source Target Source Target Source Target O O
a
Type M R C R R Ob
c
Od
5 6 7 8 9 10 11 12 13 14 15
a. The source AN shall set the value of this IE to the value of AT-ID in the A17-Allocate Request message. b. If this IE is included in this message, its value shall be returned in the Correlation ID in the corresponding A17-Modify Response message. c. Multiple instances of this IE may be included for all sectors that the source AN requests resource modification, where one instance of this IE contains one Proposed Session State Information Record indicating the requested modifications to the current session in the source AN. d. This IE indicates to the target AN whether or not it should wait until it receives an A17-Set Attributes message from the source AN containing Session State Information Record IEs before modifying resources. 47 The following table shows the bitmap layout for the A17-Modify Request message. 5.1.3.5 A17-Modify Request 7 6 5 4 3 2 1 0 Octet 1 1 2 3 Message Type III = [05H] Length = [05H] Reserved = [0000] ATI Type = [0010 (UATI32)]
47 If there are sectors belonging to more than one target AN that are part of the ATs Active Set that the source AN sends an A17-Modify Request message to, this element indicates that the target AN shall wait until receiving an A17-Set Attributes message from the source AN containing Session State Information Records before modifying resources.
5-55
3GPP2 A.S0008-C v2.0 5.1.3.5 A17-Modify Request 7 (MSB) 6 5 4 3 AT-ID 2 1 0 Octet 4 5 6 (LSB) (MSB) Correlation ID: A17 Element Identifier = [0BH] Length = [04H] Correlation Value = <any value> 7 1 2 3 4 5 (LSB) Proposed Session State Information Record {1+: (MSB) (MSB) Proposed Session State Information Record: A17 Element Identifier = [03H] Length = [variable] (LSB) Proposed Session State Information Record = <any value> 1 2 3 4 6
(LSB) } Proposed Session State Information Record Rapid Commit: A17 Element Identifier = [1AH] Length = [01H] Reserved = [0000 000]
1 2 3
n 1 2 Flag 3
5.1.3.6
A17-Modify Response
This message is sent from the target AN to the source AN in response to an A17-Modify Request message from the source AN. Information Element Message Type III AT-ID Correlation ID A17 Cause Proposed Session State Information Record Section Reference 5.2.3.3 5.2.3.4 5.2.3.9 5.2.3.32 5.2.3.6 Element Direction Target Source Target Source Target Source Target Source Target Source O O O
a b d
Type M R C R C
Oc
4 5 6 7
a. The target AN shall set the value of this IE to the value of the AT-ID IE of the A17-Modify Request message to which it is responding. b. This IE shall be included if it was also included in the corresponding A17-Modify Request message and shall be set to the value received in that message. 5-56
3GPP2 A.S0008-C v2.0

1 2 3 4 5 6 7 8 9 10
c. If the target AN accepts all or rejects all SSIRs sent in the A17-Modify Request message, this IE is omitted. Otherwise, it shall include all SSIRs received in the A17-Modify Request message. The values of the SSIRs may be modified according to a counter-proposal. d. If the target AN accepts all requested modifications, the A17-Modify Response message includes Successful operation in the cause value. If the target AN rejects all requested modifications, the A17-Modify Response message includes a Reject reason in the cause value. If the target AN does not accept all of the requested modifications but wants to make a counter-proposal for one or more of the session state information records, the A17-Modify Response message includes Counter proposal in the cause value. The following table shows the bitmap layout for the A17-Modify Response message. 5.1.3.6 A17-Modify Response 7 6 5 4 3 2 1 0 Octet 1 1 2 3 4 5 6 (LSB) (MSB) Correlation ID: A17 Element Identifier = [0BH] Length = [04H] Correlation Value = <any value> 7 1 2 3 4 5 (LSB) A17 Cause: A17 Element Identifier = [26H] Length = [01H] Cause Value = [ 00H (Successful operation), 01H (Counter proposal), 02H (Reject No reason specified), 03H (Reject - Radio resource unavailable), 04H (Reject Network resource unavailable) ] 6 1 2 3 Message Type III = [06H] Length = [05H] Reserved = [0000] (MSB) ATI Type = [0010 (UATI32)] AT-ID
Proposed Session State Information Record {0, 1+: (MSB) (MSB) Proposed Session State Information Record: A17 Element Identifier = [03H] Length = [variable] (LSB) Proposed Session State Information Record = <any value> 1 2 3 4
(LSB)
5-57
3GPP2 A.S0008-C v2.0 5.1.3.6 A17-Modify Response 7 6 5 4 3 2 1 0 Octet } Proposed Session State Information Record
1 2 3
5.1.3.7
A17-Target Modify Request
This message is sent from the target AN to the source AN to request modification of resources at sectors belonging to the target AN to support soft/softer handoff for a specific AT. Information Element Message Type III AT-ID Correlation ID Proposed Session State Information Record Section Reference 5.2.3.3 5.2.3.4 5.2.3.9 5.2.3.6 Element Direction Target Source Target Source Target Source Target Source Oa O
a
Type M R C R
Oc
4 5 6 7 8 9 10 11
a. The target AN shall set the value of this IE to the value of AT-ID in the A17-Allocate Request message. b. If this IE is included in this message, its value shall be returned in the Correlation ID IE in the corresponding A17-Target Modify Response message. c. Multiple instances of this IE may be included for all sectors belonging to the target AN that the target AN requests resource modification, where one instance of this IE contains one Proposed Session State Information Record indicating the requested modifications to the current session in the source AN. The following table shows the bitmap layout for the A17-Target Modify Request message. 5.1.3.7 A17-Target Modify Request 7 6 5 4 3 2 1 0 Octet 1 1 2 3 4 5 6 (LSB) (MSB) Correlation ID: A17 Element Identifier = [0BH] Length = [04H] Correlation Value = <any value> 7 1 2 3 4 5 (LSB) Proposed Session State Information Record {1+: Proposed Session State Information Record: A17 Element Identifier = [03H] 5-58 1 6 Message Type III = [07H] Length = [05H] Reserved = [0000] (MSB) ATI Type = [0010 (UATI32)] AT-ID
3GPP2 A.S0008-C v2.0 5.1.3.7 A17-Target Modify Request 7 (MSB) (MSB) 6 5 4 3 Length = [variable] (LSB) Proposed Session State Information Record = <any value> 2 1 0 Octet 2 3 4
(LSB) } Proposed Session State Information Record

1 2 3
5.1.3.8
A17 Target Modify Response
This message is sent from the source AN to the target AN in response to an A17-Target Modify Request message from the target AN. Information Element Message Type III AT-ID Correlation ID A17 Cause Proposed Session State Information Record Section Reference 5.2.3.3 5.2.3.4 5.2.3.9 5.2.3.32 5.2.3.6 Element Direction Source Target Source Target Source Target Source Target Source Target Oa O
b
Type M R C R C
Od O
c
4 5 6 7 8 9 10 11 12 13 14 15 16 17
a. The source AN shall set the value of this IE to the value of the AT-ID IE of the A17-Target Modify Request message to which it is responding. b. This IE shall be included if it was also included in the A17-Target Modify Request message and shall be set to the value received in that message. c. If the source AN accepts all or rejects all SSIRs sent in the A17-Target Modify Request message, this IE is omitted. Otherwise, it shall include all SSIRs received in the A17-Target Modify Request message. The values of the SSIRs may be modified according to a counter-proposal. d. If the source AN accepts all requested modifications, the A17-Target Modify Response message includes Successful operation in the cause value. If the source AN rejects all requested modifications, the A17-Target Modify Response message includes a Reject reason in the cause value. If the source AN does not accept all of the requested modifications but wants to make a counterproposal for one or more of the session state information records, the A17-Target Modify Response message includes Counter proposal in the cause value. The following table shows the bitmap layout for the A17-Target Modify Response message. 5.1.3.8 A17 Target Modify Response 7 6 5 4 3 2 1 0 Octet 1 1 2 3 4 5 5-59 Message Type III = [08H] Length = [05H] Reserved = [0000] (MSB) ATI Type = [0010 (UATI32)] AT-ID
3GPP2 A.S0008-C v2.0 5.1.3.8 A17 Target Modify Response 7 6 5 4 3 2 1 0 (LSB) (MSB) Correlation ID: A17 Element Identifier = [0BH] Length = [04H] Correlation Value = <any value> Octet 6 7 1 2 3 4 5 (LSB) A17 Cause: A17 Element Identifier = [26H] Length = [01H] Cause Value = [ 00H (Successful operation), 01H (Counter proposal), 02H (Reject No reason specified), 03H (Reject - Radio resource unavailable), 04H (Reject Network resource unavailable) ] 6 1 2 3
Proposed Session State Information Record {0, 1+: (MSB) (MSB) Proposed Session State Information Record: A17 Element Identifier = [03H] Length = [variable] (LSB) Proposed Session State Information Record = <any value> 1 2 3 4
(LSB) } Proposed Session State Information Record

1 2 3
5.1.3.9
A17-Deallocate Request
This message is sent from the source AN to the target AN to request deallocation of resources at sectors belonging to the target AN to support soft/softer handoff for a specific AT. Information Element Message Type III AT-ID Correlation ID Leg Number Deallocation Timer Section Reference 5.2.3.3 5.2.3.4 5.2.3.9 5.2.3.27 5.2.3.12 Element Direction Source Target Source Target Source Target Source Target Source Target O O O
a b
Type M R C C R
Oc
d
4 5
a. The source AN shall set the value of this IE to the value of AT-ID in the A17-Allocate Request message.
5-60
3GPP2 A.S0008-C v2.0

1 2 3 4 5 6 7 8 9 10 11 12 13
b. If this IE is included in this message, its value shall be returned in the Correlation ID IE in the corresponding A17-Deallocate Ack message. c. This IE specifies the sector for which the source AN requests resource deallocation. Its value is the leg number communicated to the source AN by the target AN in the corresponding A17-Allocate Response message. One instance of this IE is included for each sector that the source AN requests resource deallocation. If no instances of this IE are included in the A17-Deallocate Request message, the receiver shall release all resources for the AT. d. If the value of this IE is non-zero, then each sector that the source AN is requesting resource deallocation for as indicated by the Leg Number IE shall immediately indicate to the AT 48 that the air-interface resources allocated to it at that RT have been deallocated and subsequently deallocate resources after Deallocation Timer milliseconds have elapsed. Otherwise, each sector shall immediately deallocate resources upon receiving the A17-Deallocate Request message. The following table shows the bitmap layout for the A17-Deallocate Request message. 5.1.3.9 A17-Deallocate Request 7 6 5 4 3 2 1 0 Octet 1 1 2 3 4 5 6 (LSB) (MSB) Correlation ID: A17 Element Identifier = [0BH] Length = [04H] Correlation Value = <any value> 7 1 2 3 4 5 (LSB) Leg Number {1+: Leg Number: A17 Element Identifier = [1FH] Length = [01H] Leg Number = [00H-FFH] } Leg Number (MSB) Deallocation Timer: A17 Element Identifier = [0EH] Length = 02H] Deallocation Timer 1 2 3 1 2 3 6 Message Type III = [09H] Length = [05H] Reserved = [0000] (MSB) ATI Type = [0010 (UATI32)] AT-ID
48
For example, if Deallocation Timer = x milliseconds, then each sector belonging to the target AN that is part of the ATs Active Set whose resources are being deallocated is required to set the ForwardTrafficValid field associated with the ATs MACIndex to zero for x milliseconds via the QuickConfig message as defined in [10].
5-61
3GPP2 A.S0008-C v2.0 5.1.3.9 A17-Deallocate Request 7 6 5 4 3 2 1 0 (LSB)

1 2 3
Octet 4
5.1.3.10
A17-Deallocate Ack
This message is sent from the target AN to the source AN in response to an A17-Deallocate Request message from the source AN. Information Element Message Type III AT-ID Correlation ID Section Reference 5.2.3.3 5.2.3.4 5.2.3.9 Element Direction Target Source Target Source Target Source Oa O
b
Type M R C
4 5 6 7 8
a. The target AN shall set the value of this IE to the value of the AT-ID IE of the A17-Deallocate Request message to which it is responding. b. This IE shall be included if it was also included in the corresponding A17-Deallocate Request message and shall be set to the value received in that message. The following table shows the bitmap layout for the A17-Deallocate Ack message. 5.1.3.10 7 6 5 4 A17-Deallocate Ack 3 2 1 0 Octet 1 1 2 3 4 5 6 (LSB) (MSB) Correlation ID: A17 Element Identifier = [0BH] Length = [04H] Correlation Value = <any value> 7 1 2 3 4 5 (LSB) 6
Message Type III = [0AH] Length = [05H]
AT-ID: A17 Element Identifier = [21H] ATI Type = [0010 (UATI32)] AT-ID
Reserved = [0000] (MSB)
9 10 11
5.1.3.11
A17-Target Deallocate Request
This message is sent from the target AN to the source AN to request deallocation of resources at sectors belonging to the target AN to support soft/softer handoff for a specific AT.
5-62
3GPP2 A.S0008-C v2.0 Information Element Message Type III AT-ID Correlation ID Leg Number A17 Cause
1 2 3 4 5 6 7 8 9
Section Reference 5.2.3.3 5.2.3.4 5.2.3.9 5.2.3.27 5.2.3.32
Element Direction Target Source Target Source Target Source Target Source Target Source O O
Type M
a
R C R R
Oc O
a. The target AN shall set the value of this IE to the value of AT-ID in the A17-Allocate Request message. b. If this IE is included in this message, its value shall be returned in the Correlation ID IE in the corresponding A17-Target Deallocate Ack message. c. This IE contains the leg number that represents the sector that the target AN requests resource deallocation. The leg number is communicated to the source AN by the target AN in the corresponding A17-Allocate Response message. One instance of this IE is included for each sector that the target AN requests resource deallocation. The following table shows the bitmap layout for the A17-Target Deallocate Request message. 5.1.3.11 7 6 5 4 A17-Target Deallocate Request 3 2 1 0 Octet 1 1 2 3 4 5 6 (LSB) (MSB) Correlation ID: A17 Element Identifier = [0BH] Length = [04H] Correlation Value = <any value> 7 1 2 3 4 5 (LSB) Leg Number {1+: Leg Number: A17 Element Identifier = [1FH] Length = [01H] Leg Number = [00H-FFH] } Leg Number A17 Cause: A17 Element Identifier = [26H] Length = [01H] 1 2 1 2 3 6 Message Type III = [0BH] Length = [05H] Reserved = [0000] (MSB) ATI Type = [0010 (UATI32)] AT-ID
5-63
3GPP2 A.S0008-C v2.0 5.1.3.11 7 6 5 4 A17-Target Deallocate Request 3 2 1 0 Octet 3
Cause Value = [ 05H (No reason specified), 06H (Air link lost), 07H (Equipment failure) ]
1 2 3
5.1.3.12
A17-Target Deallocate Ack
This message is sent from the source AN to the target AN in response to an A17-Target Deallocate Request message from the target AN. Information Element Message Type III AT-ID Correlation ID Section Reference 5.2.3.3 5.2.3.4 5.2.3.9 Element Direction Source Target Source Target Source Target O O
a b
Type M R C
4 5 6 7 8
a. The source AN shall set the value of this IE to the value of the AT-ID IE of the A17-Target Deallocate Request message to which it is responding. b. b. This IE shall be included if it was also included in the corresponding A17-Target Deallocate Request message and shall be set to the value received in that message. The following table shows the bitmap layout for the A17-Target Deallocate Ack message. 5.1.3.12 7 6 5 4 A17-Target Deallocate Ack 3 2 1 0 Octet 1 1 2 3 4 5 6 (LSB) (MSB) Correlation ID: A17 Element Identifier = [0BH] Length = [04H] Correlation Value = <any value> 7 1 2 3 4 5 (LSB) 6
Message Type III = [0CH] Length = [05H]
9 10 11
5.1.3.13
A17-CC Packet
This message is sent by the source AN to the target AN to request that a specific sector(s) belonging to the target AN transmit signaling information to a specific AT on the forward control channel.
5-64
3GPP2 A.S0008-C v2.0 Information Element Message Type III AT-ID Leg Number CC Packet Control Information FL Application Layer Packet
1 2 3 4 5 6 7 8 9 10 11
Section Reference 5.2.3.3 5.2.3.4 5.2.3.27 5.2.3.17 5.2.3.20
Element Direction Source Target Source Target Source Target Source Target Source Target O O O O
Type M
a
R R R R
b c
d,e
a. The source AN shall set this IE to the LCM_UATI. b. This IE contains the leg number that represents the sector that the source AN requests to transmit signaling information to the AT on the forward control channel. The leg number is communicated to the source AN by the target AN in the corresponding A17-Allocate Response message. One instance of this IE is included for each sector for which the source AN makes this request. c. The IE indicates to the target AN the type of forward control channel capsule to be used to transmit the signaling information to the AT and timing information as appropriate. d. This IE contains the air-interface signaling header information to be used by an RT to construct the forward control channel message that it sends to the AT. 49 e. This IE contains the actual signaling information. 50 The following table shows the bitmap layout for the A17-CC Packet message. 5.1.3.13 7 6 5 4 A17-CC Packet 3 2 1 0 Octet 1 1 2 3 4 5 6 (LSB) Leg Number {1+: Leg Number: A17 Element Identifier = [1FH] Length = [01H] Leg Number = [00H-FFH] } Leg Number CC Packet Control Information: A17 Element Identifier = [13H] Length = [02H, 04H] 1 2 1 2 3 7
Message Type III = [0DH] Length = [05H]
49 For example, this element contains SLP-D header information as defined in [10] that is used by an RT to construct the header of the SLP-D packet. 50 For example, this element contains the upper layer signaling information that an RT will encapsulate in an SLP-D packed as defined in [10].
5-65
3GPP2 A.S0008-C v2.0 5.1.3.13 7 6 5 4 A17-CC Packet 3 2 1 0 Octet 3 4
Message Priority CC Capsule Type = [ 01H (Asynchronous) 02H (Next immediate synchronous) 03H (Synchronous after time T) 04H (Sub-synchronous after time T) IF (CC Capsule Type = 03H (Synchronous after time T) or 04H (Sub-synchronous after time T) {1: (MSB) System Time for Packet Transmission (LSB) } CC Capsule Type = 03H or 04H (MSB) FL Application Layer Packet: A17 Element Identifier = [16H] Length = [variable] (LSB) Stream ID = [00] Route Substream ID = [000 0000] Length = [variable] Reserved = [0000 000] Signaling Header (MSB) IF (Stream ID = 00) Air-Interface Signaling Header { 1:
1 2 1 2 3 4 5 6 7 8
(LSB) } Air-Interface Signaling Header (MSB) Application Layer Payload = <any value>
m p
(LSB)
1 2 3
5.1.3.14
A17-Neighbor Information Request
This message is sent from the source AN to the target AN to request neighbor information for sectors belonging to the target AN. Information Element Message Type III Correlation ID Requested Sector Information AN A17 IPv4 Address Section Reference 5.2.3.3 5.2.3.9 5.2.3.31 5.2.3.25 Element Direction Source Target Source Target Source Target Source Target Oa O
b,c d
Type M C R R
4 5
a. If this IE is included in this message, its value shall be returned in the Correlation ID IE in the corresponding A17-Neighbor Information Notification message.
5-66
3GPP2 A.S0008-C v2.0

1 2 3 4 5 6 7 8 9 10 11 12 13
b. This IE contains the sector information that identifies the sector which the source AN requests neighbor information. One instance of this IE is included for each sector that the source AN requests neighbor information. c. The cookie value in this IE uniquely identifies the neighbor information that the source AN currently has associated with the sector in Sector Information field. The value of this IE is set according to the Cookie IE associated with the sector received in a previous A17-Neighbor Information Notification message. One instance of this IE may be included for each Sector Information field that the source AN requests neighbor information. If the cookie value is not included, the target AN shall return the neighbor information associated with the sector in the A17-Neighbor Information Notification message. d. This IE contains the IPv4 address of the source AN to be used by the target AN as the destination IP address in an IP packet that carries an unsolicited A17-Neighbor Information Notification message on the A17 interface. The following table shows the bitmap layout for the A17-Neighbor Information Request message. 5.1.3.14 7 6 (MSB) 5 A17-Neighbor Information Request 4 3 2 1 0 Octet 1 1 2 3 4 5 (LSB) Requested Sector Information: A17 Element Identifier = [25H] Length = [variable] Sector Information { 1: Sector Information Type = [01H (Pilot PN and Channel)] Sector Information Length = [05H] (MSB) (MSB) Pilot PN (LSB) Channel (LSB) } Sector Information Parameter Information {0,1: Parameter Type = [01H (Cookie)] Length = [02H] (MSB) } Parameter Information AN A17 IPv4 Address: A17 Element Identifier = [1CH] 5-67 1 Cookie = [0000H FFFFH] (LSB) 10 11 12 13 3 4 5 6 7 8 9 6 1 2 Message Type III = [1EH] Length = [04H] Correlation Value = <any value>
14
Correlation ID: A17 Element Identifier = [0BH]
3GPP2 A.S0008-C v2.0 5.1.3.14 7 (MSB) 6 5 A17-Neighbor Information Request 4 3 2 1 0 Octet 2 3 4 5 (LSB)
1 2 3 4 5
Length = [04H] IPv4 Address = <any value>
5.1.3.15
A17-Neighbor Information Notification
This message is sent from the target AN to the source AN in response to an A17-Neighbor Information Request message from the source AN. This message is also sent from the target AN to the source AN when the target AN wants to send unsolicited neighbor information to the source AN for sectors belonging to the target AN. Information Element Message Type III Correlation ID Neighbor Information Section Reference 5.2.3.3 5.2.3.9 5.2.3.26 Element Direction Target Source Target Source Target Source O
a
Type M C C Ob,c
6 7 8 9 10 11 12 13 14 15 16 17 18
a. This IE shall be included if it was also included in the corresponding A17-Neighbor Information Request message and shall be set to the value received in that message. If it is not included in the A17-Neighbor Information Request message, this IE may be included in this message. b. Multiple instances of this IE may be included, where one instance of this IE contains neighbor information of the sector identified in the Sector Information field of this IE. The neighbor information contains the IPv4 addresses for each neighbor sector to be used by the source AN as the destination IP address of the A16 and A17 interface. The neighbor information may be omitted, if the received Cookie value in the A17-Neighbor Information Request message indicates that the source AN has the current neighbor information associated with the sector. c. Cookie value in this IE uniquely identifies the current neighbor information that the target AN currently has associated with the specified sector. The target AN may not include this IE if it wants to provide the complete neighbor information every time the A17-Neighbor Information Request message is received. The following table shows the bitmap layout for the A17-Neighbor Information Notification message. 5.1.3.15 7 6 (MSB) 5 A17-Neighbor Information Notification 4 3 2 1 0 Octet 1 1 2 3 4 5 (LSB) Neighbor Information: A17 Element Identifier = [1DH] 5-68 6 1 Message Type III = [1FH] Length = [04H] Correlation Value = <any value>
19
3GPP2 A.S0008-C v2.0 5.1.3.15 7 (MSB) Sector Information { 1: Sector Information Type = [01H (Pilot PN and Channel)] Sector Information Length = [05H] (MSB) (MSB) Pilot PN (LSB) Channel (LSB) } Sector Information Number of Neighbors = [00H FFH] Neighbor Information Entry { Number of Neighbors : Entry Length = [variable] Neighbor Sector Information { 1: Sector Information Type = [01H (Pilot PN and Channel)] Sector Information Length = [05H] (MSB) (MSB) Pilot PN-n (LSB) Channel-n (LSB) } Neighbor Sector Information (MSB) AN A17 IPv4 Address = <any value> m+8 m+9 m+10 (LSB) (MSB) AN A16 IPv4 Address = <any value> m+11 m+12 m+13 m+14 (LSB) (MSB) } Neighbor Information Entry Neighbor Parameter { 0, 1: Parameter Type = [01H (Cookie)] 5-69 n RT Identifier = <any value> (LSB) m+15 m+16 m+17 m+1 m+2 m+3 m+4 m+5 m+6 m+7 m 11 4 5 6 7 8 9 10 6 5 A17-Neighbor Information Notification 4 3 Length = [variable] (LSB) 2 1 0 Octet 2 3
3GPP2 A.S0008-C v2.0 5.1.3.15 7 (MSB) } Neighbor Parameter

1 2 3
A17-Neighbor Information Notification 4 3 2 1 0 Octet n+1 n+2 (LSB) n+3 Parameter Length = [02H] Cookie = [0000H FFFFH]
5.1.3.16
A17-Neighbor Information Notification Ack
This message is sent from the source AN to the target AN to acknowledge the receipt an A17-Neighbor Information Notification message from the target AN. Information Element Message Type III Correlation ID Section Reference 5.2.3.3 5.2.3.9 Element Direction Source Target Source Target O
a
Type M C
4 5 6 7
a. This IE shall be included if it was also included in the corresponding A17-Neighbor Information Notification message and shall be set to the value received in that message. The following table shows the bitmap layout for the A17-Neighbor Information Notification Ack message. 5.1.3.16 7 6 (MSB) 5 A17-Neighbor Information Notification Ack 4 3 2 1 0 Octet 1 1 2 3 4 5 (LSB) 6 Message Type III = [20H] Length = [04H] Correlation Value = <any value>
9 10 11 12
5.1.3.17
A17-Slave Attach Request
This message is sent from the slave AN to a master or another target AN to request cross-connectivity to existing resources at sectors belonging to the master AN or another target AN that have already been allocated for a specific AT. Information Element Message Type III AT-ID Correlation ID Section Reference 5.2.3.3 5.2.3.4 5.2.3.9 Element Direction Slave Master or another target Slave Master or another target Slave Master or another target Oa Ob Type M R C
5-70
3GPP2 A.S0008-C v2.0 Information Element AN Leg Information Leg-Sector Association

1 2 3 4 5 6 7 8 9 10 11 12 13
Element Direction Slave Master or another target Slave Master or another target
Type Oc Od R R
a. The slave AN shall set the value of this IE to the value of AT-ID for which the slave AN is requesting cross-connectivity. b. If this IE is included in this message, its value shall be returned in the Correlation ID IE in the corresponding A17-Slave Attach Response message. c. One instance of this IE is included for each RT for which the slave AN requests resource allocation. Multiple instances of this IE may be included. d. This IE contains the leg number that represents the sector for which the slave AN requests to attach. This number shall be unique in the slave AN for each sector in the Active Set for the AT. One instance of this IE is included for each sector for which the slave AN requests to attach. This IE also contains the Pilot PN and Channel of the sector existing resources, to which the slave AN requests connection. One instance of this IE is included for each sector for which the slave AN makes this request. The following table shows the bitmap layout for the A17-Slave Attach Request message. 5.1.3.17 7 6 (MSB) 5 4 A17-Slave Attach Request 3 2 1 0 Octet 1 1 2 3 4 5 (LSB) (MSB) Correlation ID: A17 Element Identifier = [0BH] Length = [04H] Correlation Value = <any value> 6 1 2 3 4 5 (LSB) AN Leg Information: A17 Element Identifier = [22H] Length = [variable] Leg Number = [00H FFH] AN A19 Control Endpoint ID { 1:
Message Type III = [21H] Length = [04H] AT-ID
6 1 2 3 4
5-71
3GPP2 A.S0008-C v2.0 5.1.3.17 7 (MSB) (MSB) 6 5 4 A17-Slave Attach Request 3 2 1 0 (LSB) IPv4 Address = <any value> Octet 5 6 7 8 9 (LSB) } AN A19 Control Endpoint ID AN A18 Data Endpoint ID { 1:
UDP Port = [0000H FFFFH]
10
11
(MSB) (MSB)
12 13 14 15 16 (LSB) 17 1 2 3 4
} AN A18 Data Endpoint ID Leg-Sector Association: A17 Element Identifier = [23H] Length = [variable] Leg Number = [00H FFH] Sector Information Count = [01H FFH] Sector and Parameter Entry{ Sector Information Count: Sector Information { 1: Sector Information Type = [01H (Pilot PN and Channel)] Sector Information Length = [05H] (MSB) (MSB) Pilot PN (LSB) Channel (LSB) } Sector Information Sector Parameter { 1: Parameter Type = [01H (RTDT Estimation)] Parameter Length = [01H] Round Trip Delay Time (RTDT) Estimation Parameter } Sector Parameter 5-72 n+7 n+8 n+9 n n+1 n+2 n+3 n+4 n+5 n+6
3GPP2 A.S0008-C v2.0 5.1.3.17 7 6 5 4 } Sector and Parameter Entry

1 2 3
A17-Slave Attach Request 3 2 1 0 Octet
5.1.3.18
A17-Slave Attach Response
This message is sent by the master AN or another target AN in response to an A17-Slave Attach Request message from the slave AN. Information Element Message Type III AT-ID Correlation ID RT Leg Information Section Reference 5.2.3.3 5.2.3.4 5.2.3.9 5.2.3.30 Element Direction Master or another target Slave Master or another target Slave Master or another target Slave Master or another target Slave Oa Ob Oc Type M R C C
4 5 6 7 8 9 10 11
a. The master or another target AN shall set the value of this IE to the value of the AT-ID element of the A17-Slave Attach Request message to which it is responding. b. This IE shall be included if it was also included in the A17-Slave Attach Request message and shall be set to the value received in that message. c. One instance of this IE is included for each RT for which the master AN or another target AN allocates resources as requested by the slave AN in the A17-Slave Attach Request message. Multiple instances of this IE may be included. The following table shows the bitmap layout for the A17-Slave Attach Response message. 5.1.3.18 7 6 (MSB) 5 4 A17-Slave Attach Response 3 2 1 0 Octet 1 1 2 3 4 5 (LSB) (MSB) Correlation ID: A17 Element Identifier = [0BH] Length = [04H] Correlation Value = <any value> 6 1 2 3 4 5 (LSB) RT Leg Information: A17 Element Identifier = [24H] 5-73 6 1
3GPP2 A.S0008-C v2.0 5.1.3.18 7 6 5 4 A17-Slave Attach Response 3 2 1 0 Octet 2 3 4
Length = [variable] Leg Number = [00H FFH] RT A19 Control Endpoint ID { 1:

(MSB) (MSB)
5 6 7 8 9 (LSB) 10
} RT A19 Control Endpoint ID RT A18 Data Endpoint ID { 1:

11
(MSB) (MSB)
12 13 14 15 16 (LSB) 17
} RT A18 Data Endpoint ID RT Parameter { 1: Parameter Type = [01H (RT Buffer Size)] Parameter Length = [02H] (MSB) } RT Parameter
1
n n+1 n+2 (LSB) n+3
Buffer Size = [0000H FFFFH]
2 3 4
5.1.3.19
A17-Slave Detach Request
This message is sent from the slave AN to a master or another target AN to request cross-connectivity connection release between the slave AN and the RTs in the master or another target AN.
5-74
3GPP2 A.S0008-C v2.0 Information Element Message Type III AT-ID Correlation ID Leg Number
1 2 3 4 5 6 7 8 9
Element Direction Slave Master or another target Slave Master or another target Slave Master or another target Slave Master or another target
Type M Oa Ob Oc R R R
a. The slave AN shall set the value of this IE to the value of AT-ID for which the slave AN is requesting cross-connectivity connection release. b. The slave AN shall set the value of this IE so as to uniquely identify each A17-Slave Detach Request message that it sends. c. This IE contains the leg number that represents the sector that the slave AN requests crossconnectivity release. The leg number is communicated either in the corresponding A17-Allocate Request or A17-Slave Attach Request message. One instance of this IE is included for each sector that the slave AN requests cross-connectivity connection release. The following table shows the bitmap layout for the A17-Slave Detach Request message. 5.1.3.19 7 6 (MSB) 5 4 A17-Slave Detach Request 3 2 1 0 Octet 1 1 2 3 4 5 (LSB) (MSB) Correlation ID: A17 Element Identifier = [0BH] Length = [04H] Correlation Value = <any value> 6 1 2 3 4 5 (LSB) Leg Number {1+: Leg Number: A17 Element Identifier = [1FH] Length = [01H] Leg Number = [00H-FFH] } Leg Number 1 2 3 6
5-75
3GPP2 A.S0008-C v2.0

1 2 3 4
5.1.3.20
A17-Slave Detach Ack
This message is sent by the master AN or another target AN in response to an A17-Slave Detach Request message from the slave AN.
Information Element Message Type III AT-ID Correlation ID

5 6 7 8 9
Section Reference 5.2.3.3 5.2.3.4 5.2.3.9
Element Direction Master or another target Slave Master or another target Slave Master or another target Slave
Type M Oa Ob R R
a. The sending AN shall set the value of this IE to the value of the AT-ID IE of the A17-Slave Detach Request message to which it is responding. b. The sending AN shall set the value of this IE to the value of the Correlation ID IE of the A17-Slave Detach Request message to which it is responding. The following table shows the bitmap layout for the A17-Slave Detach Ack message. 5.1.3.20 7 6 (MSB) 5 4 A17-Slave Detach Ack 3 2 1 0 Octet 1 1 2 3 4 5 (LSB) (MSB) Correlation ID: A17 Element Identifier = [0BH] Length = [04H] Correlation Value = <any value> 6 1 2 3 4 5 (LSB) 6
10
11
5.1.4 5.1.4.1
A18 Message Definitions A18-FTCH Packet
12 13 14
This message is sent from the source AN to the target AN to request that a specific sector belonging to the target AN transmit a packet to a specific AT on the forward traffic channel.
5-76
3GPP2 A.S0008-C v2.0 Information Element Message Type III AT-ID Leg Number FL Application Layer Packet
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24
Element Direction Source Target Source Target Source Target Source Target O
Type M O O
a
C R R
c,d,e,f,g
a. The source AN shall set the value of this IE to the value of AT-ID in the A17-Allocate Request message. The source AN may omit this IE if the AT-ID Required Flag is set to 0 in the corresponding RT Data Endpoint ID IE in the A17-Allocate Response message. b. This IE contains the leg number that represents the sector to which the source AN is sending the A18FTCH Packet message. The leg number is communicated to the source AN by the target AN in the corresponding A17-Allocate Response message. c. This IE contains flow multiplexing information to be used by the sector to construct either the header of the air-interface signaling message 51 or the header of the air-interface data message 52. d. The FTCH Control Information field of this IE contains control information to be used by the sector during both unicast and multicast transmission from the source AN to infer if packets have arrived in order from the source AN and to wait for any packets that have been delayed. It also allows the sector to perform duplicate packet detection. Additionally, it allows the sector to determine if leading octets of the FL Application Layer Packet IE have already been transmitted to the AT and, if so, which leading octets. If a portion of the FL Application Layer Packet IE has already been transmitted to the AT for the corresponding Packet ID, the Offset field is non-zero and indicates to the sector the leading octets which have already been transmitted. e. The Air Interface Signaling Header field of this IE contains air-interface signaling header information to be used by the sector to construct the header of the air-interface signaling message 53. This IE is included if the Stream ID field of the Queue ID Information IE equals 00. f. The Air-Interface Application Header field of IE contains air-interface application header information to be used by the sector to construct the header of the air-interface data message 54. This IE is included if the Stream ID field of the Queue ID Information IE equals 01, 10, or 11.
g. Multiple instances of this IE may be included. The following table shows the bitmap layout for the A18-FTCH Packet message. 5.1.4.1 A18-FTCH Packet 7 6 5 4 3 2 1 0 Octet 1 Message Type III = [10H]
51 If the Stream ID field equals 00, then the Substream ID field is set to 00H and ignored by the sector. The Stream ID field contains information that is used by the sector to construct the header of the Stream Layer packet as defined in [10]. 52 If the Stream ID field equals 01, 10, or 11 and the Stream is assigned to the Default Packet Application as defined in [10] then the Substream ID field is set to 00H and ignored by the sector. The Stream ID field is used by the sector to construct the header of the Stream Layer packet as defined in [10]. If the Stream is assigned to the Multi-Flow Packet Application as defined in [10] or Enhanced Multi-Flow Packet Application as defined in [20], then the Substream ID field contains the RLP Flow identifier or the Link Flow identifier, respectively. The Stream ID field is again used by the sector to construct the header of the Stream Layer packet. For example, this element contains SLP-D header information as defined in [10] that is used by the sector to construct the header of the SLP-D packet. For example, this element contains RLP header information as defined in [20], [10] that is used by the sector to construct the header of the RLP packet.
53 54
5-77
3GPP2 A.S0008-C v2.0 5.1.4.1 A18-FTCH Packet 7 6 5 4 3 2 1 0 Octet 1 2 3 4 5 6 (LSB) Leg Number: A17 Element Identifier = [1FH] Length = [01H] Leg Number = [00H-FFH] (MSB) FL Application Layer Packet: A17 Element Identifier = [16H] Length = [variable] Stream ID = [00, 01, 10, 11] Route (MSB) (MSB) (MSB) (MSB) } FL Control Information IF (Stream ID = 00) Air-Interface Signaling Header { 1: Length = [variable] Reserved = [0000 000] Signaling Header (MSB) n n+1 n+2 Substream ID = [000 0000 111 1111] Packet ID (LSB) Data Transmission Group (DTG) Tag (LSB) DTG First Packet ID (LSB) Offset (LSB) IF (Stream ID = 01,10,11) FTCH Control Information { 1: 6 7 8 9 10 11 12 13 7 1 2 3 1 2 3 4 5 AT-ID: A17 Element Identifier = [21H] Length = [05H] Reserved = [0000] (MSB) ATI Type = [0010 (UATI32)] AT-ID
(LSB) } Air-Interface Signaling Header , ELSE IF (Stream ID = 01, 10, 11) Air-Interface Application Header {1: Length = [variable] Reserved = [00] (MSB) Application Header
14 15 16
5-78
3GPP2 A.S0008-C v2.0 5.1.4.1 A18-FTCH Packet 7 6 5 4 3 2 1 0 (LSB) } Air-Interface Application Header (MSB) Application Layer Payload = <any value> p Octet
(LSB)
1 2 3
5.1.4.2
A18-RTCH Packet
This message is sent from the target AN to the source AN to forward a reverse traffic channel packet from a specific AT received by a specific RT(s) belonging to the target AN. Information Element Message Type III AT-ID Leg Number RTCH Packet Control Information CRC Pass Fail RL Application Layer Packet Section Reference 5.2.3.3 5.2.3.4 5.2.3.27 5.2.3.21 5.2.3.24 5.2.3.19 Element Direction Target Source Target Source Target Source Target Source Target Source Target Source Oa O O
b
Type M C R R R C
Oc
d e
4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
a. The target AN shall set the value of this IE to the value of AT-ID in the A17-Allocate Request message. The target AN may omit this IE if the AT-ID Required Flag is set to 0 in the corresponding AN Data Endpoint ID IE in the A17-Allocate Request message. b. This IE contains the leg number that represents the sector sending the A18-RTCH Packet message. The leg number is communicated to the target AN by the source AN in the corresponding A17Allocate Request message. c. This IE contains control information to be used by the source AN to discard duplicate reverse traffic channel packets received from different sectors when the AT is in soft handoff. This IE also contains control information that provides the source AN with an estimation of round trip delay to assist new sectors with the acquisition of the ATs reverse traffic channel. Finally, for Subtype 2 Physical Layer Protocol as defined in [10], this IE contains the sub-packet number and interlace number for the packet decoded and the status of packets being decoded on the other two interlaces 55. d. This IE indicates to the source AN whether or not the sector successfully decoded the ATs airinterface reverse traffic channel packet. e. This IE contains a MAC Layer packet as defined in [10]. If the CRC Pass Fail IE indicates that the ATs air-interface reverse traffic channel was not successfully decoded, this IE is omitted.
55 For example, for an ATs RLP flow that is configured to send NAKs [20], [10], the source AN may use the this information to determine how long to delay sending an RLP NAK upon detecting a hole in the RLP sequence space. Conversely, an RLP flow configured not to send NAKs may use the information to determine how long to delay sending data to the upper layer protocols upon detecting a hole in the RLP sequence space.
5-79
3GPP2 A.S0008-C v2.0

1
The following table shows the bitmap layout for the A18-RTCH Packet message. 5.1.4.2 A18-RTCH Packet 7 6 5 4 3 2 1 0 Octet 1 1 2 3 4 5 6 (LSB) Leg Number: A17 Element Identifier = [1FH] Length = [01H] Leg Number = [00H-FFH] (MSB) RTCH Packet Control Information: A17 Element Identifier = [18H] Length = [03H, variable] Timestamp (LSB) Round Trip Delay Time (RTDT) Estimation Parameter Physical Layer Subtype 2 Information {0, 1: This Interlace Number This Subpacket ID Other Interlace Information {2: Other Interlace Number Other Interlace Status Flag (MSB) } Other Interlace Information } Physical Layer Subtype 2 Information CRC Pass Fail: A17 Element Identifier = [1BH] Length = [01H] Reserved = [0000 000] (MSB) (MSB) RL Application Layer Packet: A17 Element Identifier = [15H] Length = [variable] Application Layer Payload = <any value> Flag 1 2 3 1 2 3 4 Other Interlace Timestamp (LSB) 8 9 10 11 6 7 7 1 2 3 1 2 3 4 5 Message Type III = [11H] Length = [05H] Reserved = [0000] (MSB) ATI Type = [0010 (UATI32)] AT-ID
(LSB) 5-80
3GPP2 A.S0008-C v2.0

1
5.1.5 5.1.5.1
A19 Message Definitions A19-Acquisition Status
2 3 4
This message is sent from the target AN to the source AN to indicate that a specific sector belonging to the target AN has either acquired or lost the ATs reverse traffic channel. Information Element Message Type III AT-ID Correlation ID Leg Number AT Acquisition Status Section Reference 5.2.3.3 5.2.3.4 5.2.3.9 5.2.3.27 5.2.3.16 Element Direction Target Source Target Source Target Source Target Source Target Source O O O O
a b c
Type M C C R R
5 6 7 8 9 10 11 12 13 14 15
a. The target AN shall set the value of this IE to the value of the AT-ID IE of the A17-Allocate Request message. The target AN may omit this IE if the AT-ID Required Flag is set to 0 in the corresponding AN Control Endpoint ID IE in the A17-Allocate Request message. b. If this IE is included in this message, its value shall be returned in the Correlation ID in the corresponding A19-Acquisition Status Ack message. c. This IE contains the leg number that represents the sector that has either acquired or lost the ATs reverse traffic channel. The leg number is communicated to the target AN by the source AN in the corresponding A17-Allocate Request message. d. This IE indicates to the source AN whether the sector has acquired or lost the ATs reverse traffic channel. The following table shows the bitmap layout for the A19-Acquisition Status message. 5.1.5.1 A19-Acquisition Status 7 6 5 4 3 2 1 0 Octet 1 1 2 3 4 5 6 (LSB) (MSB) Correlation ID: A17 Element Identifier = [0BH]] Length = [04H] Correlation Value = <any value> 7 1 2 3 4 5 (LSB) Leg Number: A17 Element Identifier = [1FH] Length = [01H] Leg Number = [00H-FFH] 5-81 6 1 2 3 Message Type III = [12H] Length = [05H] Reserved = [0000] (MSB) ATI Type = [0010 (UATI32)] AT-ID
3GPP2 A.S0008-C v2.0 5.1.5.1 A19-Acquisition Status 7 6 5 4 3 2 1 0 Octet 1 2 3 AT Acquisition Status: A17 Element Identifier = [12H] Length = [01H] Status = [01H (AT acquired) 02H (AT lost)]
1 2 3
5.1.5.2
A19-Acquisition Status Ack
This message is sent from the source AN to the target AN to acknowledge the receipt an A19-Acquisition Status message from the target AN. Information Element Message Type III AT-ID Correlation ID Leg Number Section Reference 5.2.3.3 5.2.3.4 5.2.3.9 5.2.3.27 Element Direction Source Target Source Target Source Target Source Target Oa O
a
Type M C C R
Oc
4 5 6 7 8 9 10 11
a. The target AN shall set the value of this IE to the value of the AT-ID IE of the A19-Acquisition Status message to which it is responding. The target AN may omit this IE if the AT-ID Required Flag is set to 0 in the corresponding RT Control Endpoint ID IE in the A17-Allocate Response message. b. This IE shall be included if it was also included in the corresponding A19-Acquisition Status message and shall be set to the value received in that message. c. This IE contains the leg number that represents the sector to which the source AN is sending the A19Acquisition Status Ack message. The leg number is communicated to the source AN by the target AN in the corresponding A17-Allocate Response message. The following table shows the bitmap layout for the A19-Acquisition Status Ack message. 5.1.5.2 A19-Acquisition Status Ack 7 6 5 4 3 2 1 0 Octet 1 1 2 3 4 5 6 (LSB) (MSB) Correlation ID: A17 Element Identifier = [0BH] Length = [04H] Correlation Value = <any value> 7 1 2 3 4 5 5-82 Message Type III = [13H] Length = [05H] Reserved = [0000] (MSB) ATI Type = [0010 (UATI32)] AT-ID
12
3GPP2 A.S0008-C v2.0 5.1.5.2 A19-Acquisition Status Ack 7 6 5 4 3 2 1 0 (LSB) Leg Number: A17 Element Identifier = [1FH] Length = [01H] Leg Number = [00H-FFH]
1 2 3
Octet 6 1 2 3
5.1.5.3
A19-Serving RT Changed
This message is sent from the target AN to the source AN to provide an early indication that a specific RT has detected that the AT has chosen another sector as the serving RT. Information Element Message Type III AT-ID Correlation ID Leg Number Sector Information Queue ID Information FTCH Packet Served Status Section Reference 5.2.3.3 5.2.3.4 5.2.3.9 5.2.3.27 5.2.3.8 5.2.3.14 5.2.3.15 Element Direction Target Source Target Source Target Source Target Source Target Source Target Source Target Source O O O O
a
Type M C C R C R R Ob
c d e f
4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22
a. The target AN shall set the value of this IE to the value of the AT-ID IE of the A17-Allocate Request message. The target AN may omit this IE if the AT-ID Required Flag is set to 0 in the corresponding AN Control Endpoint ID IE in the A17-Allocate Request message. b. If this IE is included in this message, its value shall be returned in the Correlation ID IE in the corresponding A19-Serving RT Changed Ack message. c. This IE contains the leg number that represents the sector sending the A19-Serving RT Changed message. The leg number is communicated to the target AN by the source AN in the corresponding A17-Allocate Request message. d. This IE is included when the sector knows which sector the AT has chosen as the serving RT. 56 If this IE is included, it contains the Pilot PN and Channel of the sector that the AT has chosen as the serving RT. e. This IE contains flow multiplexing information for the FTCH Packet Served Status IE. Refer to the description of this IE in the A18-FTCH Packet message for more details (section 5.1.4.1). f. This IE indicates to the source AN the Packet ID of the last FL Application Layer Packet IE that has been transmitted to the AT, where the FL Application Layer Packet IE is contained in the corresponding A18-FTCH Packet message (section 5.1.4.1) received by the sector. It also indicates to the source AN if the entire Application Layer Payload identified by the Packet ID has been transmitted to the AT or if leading octets of the Application Layer Payload identified by the Packet ID have been transmitted to the AT and, if so, which leading octets.
56
5-83
3GPP2 A.S0008-C v2.0

1
The following table shows the bitmap layout for the A19-Serving RT Changed message. 5.1.5.3 A19-Serving RT Changed 7 6 5 4 3 2 1 0 Octet 1 1 2 3 4 5 6 (LSB) (MSB) Correlation ID: A17 Element Identifier = [0BH] Length = [04H] Correlation Value = <any value> 7 1 2 3 4 5 (LSB) Leg Number: A17 Element Identifier = [1FH] Length = [01H] Leg Number = [00H-FFH] Sector Information {0, 1: (MSB) (MSB) Sector Information: A17 Element Identifier = [08H] Length = [05H] Pilot PN (LSB) Channel (LSB) } Sector Information Queue ID Information and FTCH Packet Served Status {1+: Queue ID Information: A17 Element Identifier = [10H] Length = [02H] Stream ID = [00, 01, 10, 11] Route (MSB) Substream ID = [000 0000 111 1111] FTCH Packet Served Status: A17 Element Identifier = [11H] Length = [04H] Last Served FTCH Packet ID (LSB) 5-84 1 2 3 4 1 2 3 4 1 2 3 4 5 6 7 6 1 2 3 Message Type III = [14H] Length = [05H] Reserved = [0000] (MSB) ATI Type = [0010 (UATI32)] AT-ID
3GPP2 A.S0008-C v2.0 5.1.5.3 A19-Serving RT Changed 7 (MSB) 6 5 4 3 Offset (LSB) } Queue ID Information and FTCH Packet Served Status
1 2 3
Octet 5 6
5.1.5.4
A19-Serving RT Changed Ack
This message is sent from the source AN to the target AN to acknowledge the receipt an A19-Serving RT Changed message from the target AN. Information Element Message Type III AT-ID Correlation ID Leg Number Section Reference 5.2.3.3 5.2.3.4 5.2.3.9 5.2.3.27 Element Direction Source Target Source Target Source Target Source Target Oa O
b
Type M C C R
Oc
4 5 6 7 8 9 10 11 12
a. The source AN shall set the value of this IE to the value of the AT-ID IE of the A19-Serving RT Changed message to which it is responding. The source AN may omit this IE if the AT-ID Required Flag is set to 0 in the corresponding RT Control Endpoint ID IE in the A17-Allocate Response message. b. This IE shall be included if it was also included in the A19-Serving RT Changed message and shall be set to the value received in that message. c. This IE contains the leg number that represents the sector to which the source AN is sending the A19Serving RT Changed Ack message. The leg number is communicated to the source AN by the target AN in the corresponding A17-Allocate Response message. The following table shows the bitmap layout for the A19-Serving RT Changed Ack message. 5.1.5.4 A19-Serving RT Changed Ack 7 6 5 4 3 2 1 0 Octet 1 1 2 3 4 5 6 (LSB) (MSB) Correlation ID: A17 Element Identifier = [0BH] Length = [04H] Correlation Value = <any value> 7 1 2 3 4 5 5-85 Message Type III = [15H] Length = [05H] Reserved = [0000] (MSB) ATI Type = [0010 (UATI32)] AT-ID
13
3GPP2 A.S0008-C v2.0 5.1.5.4 A19-Serving RT Changed Ack 7 6 5 4 3 2 1 0 (LSB) Leg Number: A17 Element Identifier = [1FH] Length = [01H] Leg Number = [00H-FFH]
1 2 3
Octet 6 1 2 3
5.1.5.5
A19-Forward Desired
This message is sent from the target AN to the source AN to indicate that a specific sector has detected that the AT has chosen it as the serving RT. Information Element Message Type III AT-ID Correlation ID Leg Number Section Reference 5.2.3.3 5.2.3.4 5.2.3.9 5.2.3.27 Element Direction Target Source Target Source Target Source Target Source O
a
Type M C C R Ob O
c
4 5 6 7 8 9 10 11
a. The target AN shall set the value of this IE to the value of the AT-ID IE of the A17-Allocate Request message. The target AN may omit this IE if the AT-ID Required Flag is set to 0 in the corresponding AN Control Endpoint ID IE in the A17-Allocate Request message. b. If this IE is included in this message, its value shall be returned in the Correlation ID IE in the corresponding A19-Forward Desired Ack message. c. This IE contains the leg number that represents the sector sending the A19-Forward Desired message. The leg number is communicated to the target AN by the source AN in the corresponding A17Allocate Request message The following table shows the bitmap layout for the A19-Forward Desired message. 5.1.5.5 A19-Forward Desired 7 6 5 4 3 2 1 0 Octet 1 1 2 3 4 5 6 (LSB) (MSB) Correlation ID: A17 Element Identifier = [0BH] Length = [04H] Correlation Value = <any value> 7 1 2 3 4 5 (LSB) 5-86 6 Message Type III = [16H] Length = [05H] Reserved = [0000] (MSB) ATI Type = [0010 (UATI32)] AT-ID
12
3GPP2 A.S0008-C v2.0 5.1.5.5 A19-Forward Desired 7 6 5 4 3 2 1 0 Octet 1 2 3 Leg Number: A17 Element Identifier = [1FH] Length = [01H] Leg Number = [00H-FFH]
1 2 3
5.1.5.6
A19-Forward Desired Ack
This message is sent from the source AN to the target AN to acknowledge the receipt an A19-Forward Desired message from the target AN. Information Element Message Type III AT-ID Correlation ID Leg Number Section Reference 5.2.3.3 5.2.3.4 5.2.3.9 5.2.3.27 Element Direction Source Target Source Target Source Target Source Target O O O
a a c
Type M C C R
4 5 6 7 8 9 10 11
a. The source AN shall set the value of this IE to the value of the AT-ID IE of the A19-Forward Desired message to which it is responding. The source AN may omit this IE if the AT-ID Required Flag is set to 0 in the corresponding RT Control Endpoint ID IE in the A17-Allocate Response message. b. This IE shall be included if it was also included in the corresponding A19-Forward Desired message and shall be set to the value received in that message. c. This IE contains the leg number that represents the sector to which the source AN is sending the A19Forward Desired Ack message. The leg number is communicated to the source AN by the target AN in the corresponding A17-Allocate Response message. The following table shows the bitmap layout for the A19-Forward Desired Ack message. 5.1.5.6 A19-Forward Desired Ack 7 6 5 4 3 2 1 0 Octet 1 1 2 3 4 5 6 (LSB) (MSB) Correlation ID: A17 Element Identifier = [0BH] Length = [04H] Correlation Value = <any value> 7 1 2 3 4 5 (LSB) 5-87 6 Message Type III = [17H] Length = [05H] Reserved = [0000] (MSB) ATI Type = [0010 (UATI32)] AT-ID
12
3GPP2 A.S0008-C v2.0 5.1.5.6 A19-Forward Desired Ack 7 6 5 4 3 2 1 0 Octet 1 2 3 Leg Number: A17 Element Identifier = [1FH] Length = [01H] Leg Number = [00H-FFH]
1 2 3
5.1.5.7
A19-Forward Stopped
This message is sent from the target AN to the source AN to indicate that a specific sector has detected that the AT has chosen another sector as the serving RT. Information Element Message Type III AT-ID Correlation ID Leg Number Queue ID Information FTCH Packet Served Status Section Reference 5.2.3.3 5.2.3.4 5.2.3.9 5.2.3.27 5.2.3.14 5.2.3.15 Element Direction Target Source Target Source Target Source Target Source Target Source Target Source Oa O O
b
Type M C C R R R
Oc
d e
4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
a. The target AN shall set the value of this IE to the value of the AT-ID IE of the A17-Allocate Request message. The target AN may omit this IE if the AT-ID Required Flag is set to 0 in the corresponding AN Data Endpoint ID IE in the A17-Allocate Request message. b. If this IE is included in this message, its value shall be returned in the Correlation ID IE in the corresponding A19-Forward Stopped Ack message. c. This IE contains the leg number that represents the sector sending the A19-Forward Stopped message. The leg number is communicated to the target AN by the source AN in the corresponding A17Allocate Request message. d. This IE contains flow multiplexing information for the FTCH Packet Served Status IE. e. This IE indicates to the source AN the Packet ID of the last FL Application Layer Packet IE that has been transmitted to the AT, where the FL Application Layer Packet IE is contained in the corresponding A18-FTCH Packet message (section 5.1.4.1) received by the sector. It also indicates to the source AN if the entire FL Application Layer Packet IE identified by the Packet ID has been transmitted to the AT or if leading octets of the Application Layer Payload identified by the Packet ID have been transmitted to the AT and, if so, which leading octets. The following table shows the bitmap layout for the A19-Forward Stopped message. 5.1.5.7 A19-Forward Stopped 7 6 5 4 3 2 1 0 Octet 1 1 2 3 4 5 6 5-88 Message Type III = [18H] Length = [05H] Reserved = [0000] (MSB) ATI Type = [0010 (UATI32)] AT-ID
19
3GPP2 A.S0008-C v2.0 5.1.5.7 A19-Forward Stopped 7 6 (MSB) 5 4 3 2 1 0 (LSB) Correlation ID: A17 Element Identifier = [0BH] Length = [04H] Correlation Value = <any value> Octet 7 1 2 3 4 5 (LSB) Leg Number: A17 Element Identifier = [1FH] Length = [01H] Leg Number = [00H-FFH] Queue ID Information and FTCH Packet Served Status {1+: Queue ID Information: A17 Element Identifier = [10H] Length = [02H] Stream ID = [00, 01, 10, 11] Route (MSB) (MSB) Substream ID = [000 0000 111 1111] FTCH Packet Served Status: A17 Element Identifier = [11H] Length = [04H] Last Served FTCH Packet ID (LSB) Offset (LSB) } Queue ID Information and FTCH Packet Served Status
1 2 3
6 1 2 3 1 2 3 4 1 2 3 4 5 6
5.1.5.8
A19-Forward Stopped Ack
This message is sent from the source AN to the target AN to acknowledge the receipt an A19-Forward Stopped message from the target AN. Information Element Message Type III AT-ID Correlation ID Leg Number Section Reference 5.2.3.3 5.2.3.4 5.2.3.9 5.2.3.27 Element Direction Source Target Source Target Source Target Source Target Oa O
b
Type M C C R
Oc
4 5 6 7 8
a. The source AN shall set the value of this IE to the value of the AT-ID IE of the A19-Forward Stopped message to which it is responding. The source AN may omit this IE if the AT-ID Required Flag is set to 0 in the corresponding RT Control Endpoint ID IE in the A17-Allocate Response message. b. This IE shall be included if it was also included in the A19-Forward Stopped message and shall be set to the value received in that message.
5-89
3GPP2 A.S0008-C v2.0

1 2 3
c. This IE contains the leg number that represents the sector to which the source AN is sending the A19Forward Stopped Ack message. The leg number is communicated to the source AN by the target AN in the corresponding A17-Allocate Response message. The following table shows the bitmap layout for the A19-Forward Stopped Ack message. 5.1.5.8 A19-Forward Stopped Ack 7 6 5 4 3 2 1 0 Octet 1 1 2 3 4 5 6 (LSB) (MSB) Correlation ID: A17 Element Identifier = [0BH] Length = [04H] Correlation Value = <any value> 7 1 2 3 4 5 (LSB) Leg Number: A17 Element Identifier = [1FH] Length = [01H] Leg Number = [00H-FFH] 6 1 2 3 Message Type III = [19H] Length = [05H] Reserved = [0000] (MSB) ATI Type = [0010 (UATI32)] AT-ID
5 6 7
5.1.5.9
A19-Flush
This message is sent from the source AN to the target AN to clear the contents of a specified scheduling queue at a specific RT belonging to the target AN. Information Element Message Type III AT-ID Correlation ID Leg Number Queue ID Information Section Reference 5.2.3.3 5.2.3.4 5.2.3.9 5.2.3.27 5.2.3.14 Element Direction Source Target Source Target Source Target Source Target Source Target O O
a
Type M C C R C Ob
c
Od
8 9 10 11 12 13 14 15
a. The source AN shall set the value of this IE to the value of the AT-ID IE of the A17-Allocate Request message. The source AN may omit this IE if the AT-ID Required Flag is set to 0 in the corresponding RT Control Endpoint ID IE in the A17-Allocate Response message. b. If this IE is included in this message, its value shall be returned in the Correlation ID IE in the corresponding A19-Flush Ack message. c. This IE contains the leg number that represents the sector to which the source AN is sending the A19Flush message. The leg number is communicated to the source AN by the target AN in the corresponding A17-Allocate Response message. 5-90
3GPP2 A.S0008-C v2.0

1 2 3
d. This IE contains flow multiplexing information that indicates which queues should have their contents cleared. This IE is included only if specific queues are to have their contents cleared. Otherwise, this IE is omitted and all queues are to have their contents cleared. The following table shows the bitmap layout for the A19-Flush message. 5.1.5.9 A19-Flush 7 6 5 4 3 2 1 0 Octet 1 1 2 3 4 5 6 (LSB) (MSB) Correlation ID: A17 Element Identifier = [0BH] Length = [04H] Correlation Value = <any value> 7 1 2 3 4 5 (LSB) Leg Number: A17 Element Identifier = [1FH] Length = [01H] Leg Number = [00H-FFH] Queue ID Information {0, 1+: Queue ID Information: A17 Element Identifier = [10H] Length = [02H] Stream ID = [00, 01, 10, 11] Route } Queue ID Information Substream ID = [000 0000 111 1111] 1 2 3 4 6 1 2 3 Message Type III = [1AH] Length = [05H] Reserved = [0000] (MSB) ATI Type = [0010 (UATI32)] AT-ID
5 6 7
5.1.5.10
A19-Flush Ack
This message is sent from the target AN to the source AN to acknowledge the receipt an A19-Flush message from the source AN. Information Element Message Type III AT-ID Correlation ID Leg Number Section Reference 5.2.3.3 5.2.3.4 5.2.3.9 5.2.3.27 5-91 Element Direction Target Source Target Source Target Source Target Source Oa O
b
Type M C C R
Oc
3GPP2 A.S0008-C v2.0

1 2 3 4 5 6 7 8
a. The target AN shall set the value of this IE to the value of the AT-ID IE of the A19-Flush message to which it is responding. The target AN may omit this IE if the AT-ID Required Flag is set to 0 in the corresponding AN Control Endpoint ID IE in the A17-Allocate Request message. b. This IE shall be included if it was also included in the corresponding A19-Flush message and shall be set to the value received in that message. c. This IE contains the leg number that represents the sector sending the A19-Flush Ack message. The leg number is communicated to the target AN by the source AN in the corresponding A17-Allocate Request message. The following table shows the bitmap layout for the A19-Flush Ack message. 5.1.5.10 7 6 5 4 A19-Flush Ack 3 2 1 0 Octet 1 1 2 3 4 5 6 (LSB) (MSB) Correlation ID: A17 Element Identifier = [0BH] Length = [04H] Correlation Value = <any value> 7 1 2 3 4 5 (LSB) Leg Number: A17 Element Identifier = [1FH] Length = [01H] Leg Number = [00H-FFH] 6 1 2 3
Message Type III = [1BH] Length = [05H]
10 11 12 13
5.1.5.11
A19-Purge
This message is sent from the target AN to the source AN to indicate that it has served forward traffic channel packets up to a specific Packet ID for a specific AT, where the packets belong to a specific queue. This is done so that the source AN can clear the contents of a buffer for a specific queue. Information Element Message Type III AT-ID Correlation ID Leg Number Queue ID Information Last Packet ID Served Section Reference 5.2.3.3 5.2.3.4 5.2.3.9 5.2.3.27 5.2.3.14 5.2.3.22 5-92 Element Direction Target Source Target Source Target Source Target Source Target Source Target Source O O O
a
Type M C C R R R Ob
c
Od
e
3GPP2 A.S0008-C v2.0

1 2 3 4 5 6 7 8 9 10 11 12
a. The target AN shall set the value of this IE to the value of the AT-ID IE of the A17-Allocate Request message. The target AN may omit this IE if the AT-ID Required Flag is set to 0 in the corresponding AN Control Endpoint ID IE in the A17-Allocate Request message. b. If this IE is included in this message, its value shall be returned in the Correlation ID IE in the corresponding A19-Purge Ack message. c. This IE contains the leg number that represents the sector sending the A19-Purge message. The leg number is communicated to the target AN by the source AN in the corresponding A17-Allocate Request message. d. This IE contains flow multiplexing information to indicate to the source AN which queues can have the contents of their buffers cleared. e. This IE indicates the Packet ID and Data Transmission Group of the last FL Application Layer Packet IE served by the sector. The following table shows the bitmap layout for the A19-Purge message. 5.1.5.11 7 6 5 4 3 A19-Purge 2 1 0 Octet 1 1 2 3 4 5 6 (LSB) (MSB) Correlation ID: A17 Element Identifier = [0BH] Length = [04H] Correlation Value = <any value> 7 1 2 3 4 5 (LSB) Leg Number: A17 Element Identifier = [1FH] Length = [01H] Leg Number = [00H-FFH] Queue ID Information and Last Packet ID Served {1+ Queue ID Information: A17 Element Identifier = [10H] Length = [02H] Stream ID = [00, 01, 10, 11] Route (MSB) Substream ID = [000 0000 111 1111] Last Packet ID Served: A17 Element Identifier = [19H] Length = [04H] Data Transmission Group (DTG) Tag 5-93 1 2 3 4 1 2 3 6 1 2 3
13
Message Type III = [1CH] Length = [05H]
3GPP2 A.S0008-C v2.0 5.1.5.11 7 (MSB) 6 5 4 3 Packet ID (LSB) } Queue ID Information and Last Packet ID Served
1 2 3
A19-Purge 2 1 0 (LSB) Octet 4 5 6
5.1.5.12
A19-Purge Ack
This message is sent from the source AN to the target AN to acknowledge the receipt an A19-Purge message from the target AN. Information Element Message Type III AT-ID Correlation ID Leg Number Section Reference 5.2.3.3 5.2.3.4 5.2.3.9 5.2.3.27 Element Direction Source Target Source Target Source Target Source Target O O
a
Type M C C R Ob
c
4 5 6 7 8 9 10 11
a. The source AN shall set the value of this IE to the value of the AT-ID IE of the A19-Purge message to which it is responding. The source AN may omit this IE if the AT-ID Required Flag is set to 0 in the corresponding RT Control Endpoint ID IE in the A17-Allocate Response message. b. This IE shall be included if it was also included in the corresponding A19-Purge message and shall be set to the value received in that message. c. This IE contains the leg number that represents the sector to which the source AN is sending the A19Purge Ack message. The leg number is communicated to the source AN by the target AN in the corresponding A17-Allocate Response message. The following table shows the bitmap layout for the A19-Purge Ack message. 5.1.5.12 7 6 5 4 A19-Purge Ack 3 2 1 0 Octet 1 1 2 3 4 5 6 (LSB) (MSB) Correlation ID: A17 Element Identifier = [0BH] Length = [04H] Correlation Value = <any value> 7 1 2 3 4 5 5-94
12
Message Type III = [1DH] Length = [05H]
3GPP2 A.S0008-C v2.0 5.1.5.12 7 6 5 4 A19-Purge Ack 3 2 1 0 (LSB) Leg Number: A17 Element Identifier = [1FH] Length = [01H] Leg Number = [00H-FFH]
1
Octet 6 1 2 3
5.1.6 5.1.6.1
A21 Message Definitions A21-1x Air Interface Signaling
3 4 5 6
This message is sent between the IWS and the HRPD AN and includes the 1x air interface message to be sent to/received from the MS/AT via CSNA. Information Element A21 Message Type Correlation ID Mobile Identity (MN ID) A21 1x Message Transmission Control 1x LAC Encapsulated PDU Pilot List Authentication Challenge Parameter (RAND) A21 Mobile Subscription Information Section Reference 5.2.4.3 5.2.4.7 5.2.4.8 5.2.4.10 5.2.4.4 5.2.4.6 5.2.4.9 5.2.4.14 Element Direction IWS HRPD AN IWS HRPD AN IWS HRPD AN IWS HRPD AN IWS HRPD AN IWS HRPD AN IWS HRPD AN IWS HRPD AN O O
a
Type M R R C R C C C
Ob Oc Od O
e
Of
7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25
a. This IE shall contain the IMSI of the AT if the AT has an IMSI and the IMSI is available. Otherwise, it shall contain the MEID/ESN of the AT if it is available. Otherwise, the HRPD AN shall set this IE to indicate an identity type of IMSI and shall include ten BCD digits set to the value 0H. In the case that the HRPD AN sends an IMSI with all digits set to 0H in an A21-Air Interface Signaling message and receives a Mobile Identity value obtained from the 1x LAC Encapsulated PDU in the corresponding A21-Ack message, the HRPD AN shall store the received Mobile Identity value and continue to use it in reference to all A21 interface signaling for that MS/AT. b. This IE contains information about the encapsulated 1x air interface message received from or to be transmitted over the Circuit Services Notification Application [9] If the AckRequired field of this IE is set to 1, and this message is being sent from the IWS to the HRPD AN, then the HRPD AN shall wait to receive the HRPD air interface acknowledgement before replying to this message with an A21-Ack message; otherwise, the HRPD AN shall send the A21-Ack message in response to this message as soon as this message has been successfully received. c. This IE contains a 1x forward link air interface message to be sent to the mobile over CSNA when this message is sent in the IWS to HRPD AN direction, and a 1x reverse link air interface message received from the mobile via CSNA when this message is sent in the HRPD AN to IWS direction. Multiple instances of this IE may be included, where each instance of this IE contains one 1x LAC encapsulated PDU. For example, General Page Message and Feature Notification message can be included respectively. 5-95
3GPP2 A.S0008-C v2.0

1 2 3 4 5 6 7 8
d. This IE is included if the 1x message is an Origination Message or a Registration Message. The first sector listed shall be the reference pilot. Refer to [10]. e. This IE is included if the 1x LAC Encapsulated PDU is associated with the 1x r-csch. This IE shall contain the RAND value most recently sent to the AT. f. This IE shall contain all band class and band subclass information of the MS/AT. This IE is included if the 1x LAC Encapsulated PDU is an Origination Message or a Registration Message and may be included for other 1x LAC Encapsulated PDUs.
The following table shows the bitmap layout for the A21-1x Air Interface Signaling message. 5.1.6.1 A21-1x Air Interface Signaling 7 6 (MSB) 5 4 3 2 1 0 Octet 1 1 2 3 4 5 (LSB) Mobile Identity (MN ID): A21 Element Identifier = [05H] Length = [05H-08H] (10-15 digits) Identity Digit 1 = [0H-FH] Odd/even Indicator = [1,0] Type of Identity = [001 (MEID Hex Digits), 101 (ESN bit format) 57, 110 (IMSI BCD Digits)] Identity Digit 2 = [0H-FH] Identity Digit N = [0H-FH] Identity Digit N+2 = [0H-FH] 6 1 2 3 A21 Message Type = [01H] Length = [04H] Correlation Value = <any value>
Correlation: A21 Element Identifier = [04H]
Identity Digit 3 = [0H-FH] Identity Digit N+1 = [0H-FH] = [1111] (if even number of digits)
4 n n+1 1 2 3
A21 1x Message Transmission Control: A21 Element Identifier = [06H] Length = [02H] Reserved = [0000] Paging Message = [1,0] Simul Xmit with Next = [1,0] AckReq uired = [1,0] 3G1XLo gicalCha nnel = [1,0]
ProtocolRevision = <any value> 1x LAC PDUs {1+: 1x LAC Encapsulated PDU: A21 Element Identifier = [01H] Length = <variable>
4 1 2
57 The ESN is not separated into digits, and occupies octets 4-7 with the most significant bit in octet 4 bit 7. Identity Digit 1 in octet 3 is unused and coded as 0000.
5-96
3GPP2 A.S0008-C v2.0 5.1.6.1 A21-1x Air Interface Signaling 7 (MSB) 6 5 4 3 2 1 0 Octet 3 4 (LSB) } 1x LAC PDUs Pilot List: A21 Element Identifier = [03H] Length = <variable> Number of Pilots = [01H-10H] Pilot Entry { Number of Pilots: Channel Record Length = <variable> (MSB) Channel Record = <any value> (LSB) Reserved = [00000] Cell ID Info = [000 No cell ID, Act. 1x pilot 001 1x cell ID, Act. 1x pilot 010 1x cell ID, Est. 1x pilot 011 1x cell ID, HRPD pilot 100 HRPD sector ID, HRPD pilot ] j j+1 k k+1 1 2 3 n 1x LAC PDU = <any value>
IF (Cell ID Info = 001, 010, 011) 1x Cell Identifier { 1: (MSB) MSCID = <any value> (LSB) (MSB) }1x Cell Identifier IF (Cell ID Info = 100), HRPD Sector Identifier { 1: HRPD Sector ID Length = <any value> (MSB) HRPD Sector ID = <any value> (LSB) } HRPD Sector Identifier Referen ce Pilot = [0-1] (MSB) Pilot PN Information = <any value> m k+2 k+3 k+n Cell = [001H-FFFH] Sector = [0H-FH] (0H = Omni) (LSB) k+2 k+3 k+4 k+5 k+6
(LSB)
m+1
5-97
3GPP2 A.S0008-C v2.0 5.1.6.1 A21-1x Air Interface Signaling 7 Reserve d = [0] 6 Pilot One Way Delay Included = [0-1] 5 4 3 2 1 0 Octet m+2 Pilot Strength = [000000-111111]
(MSB) } Pilot Entry
Pilot One Way Delay = <any value> (LSB) Authentication Challenge Parameter (RAND): A21 Element Identifier = [06H] Length = [05H] Reserved = [0000] Random Number Type = [0001] (RAND) RAND = <any value>
m+3 m+4 1 2 3 4 5 6 (LSB) 7 1 2 3 4 5
(MSB)
A21 Mobile Subscription Information: Length = <variable>
A21 Element Identifier = [0BH]
Record: {1: Record Identifier = [00H] Record Length = <variable> All Band Classes Included = [0,1] All Band Subclasses Included = [0,1] SC7 = [0,1] Current Band Subclass = <variable>
Band Class = <variable> Reserved = [000] Band Subclass Length = <variable>
6 7
SC6 = [0,1] SCn-1 = [0,1]
SC5 = [0,1] SCn-2 = [0,1]
SC4 = [0,1] SCn-3 = [0,1]
SC3 = [0,1] SCn-4 = [0,1]
SC2 = [0,1] SCn-5 = [0,1]
SC1 = [0,1] SCn-6 = [0,1]
SC0 = [0,1] SCn-7 = [0,1]
i j k k+1
SCn = [0,1]
Band Class n = <variable> All Band Subclasses Included = [0,1] Reserved = [000] Band Subclass Length = <variable>
5-98
3GPP2 A.S0008-C v2.0 5.1.6.1 A21-1x Air Interface Signaling 7 SC7 = [0,1] 6 SC6 = [0,1] SCn-1 = [0,1] 5 SC5 = [0,1] SCn-2 = [0,1] 4 SC4 = [0,1] SCn = [0,1] } Record
1
3 SC3 = [0,1] SCn-4 = [0,1]
2 SC2 = [0,1] SCn-5 = [0,1]
1 SC1 = [0,1] SCn-6 = [0,1]
0 SC0 = [0,1] SCn-7 = [0,1]
Octet k+2 m
SCn-3 = [0,1]
2 3 4
5.1.6.2
A21-Ack
The A21-Ack message is sent to acknowledge successful receipt of some A21 messages. Information Element A21 Message Type Correlation ID Mobile Identity (MN ID) A21 Cause Section Reference 5.2.4.3 5.2.4.7 5.2.4.8 5.2.4.11 Element Direction IWS HRPD AN IWS HRPD AN IWS HRPD AN IWS HRPD AN O O
a
Type M R C C Oa
b
5 6 7 8 9 10 11 12 13 14 15 16 17 18
a. If this IE was received in the A21 message being acknowledged, then this IE shall be included and contain the value received in that message. If the A21 message being acknowledged contained a Mobile Identity value of IMSI with all digits set to 0H, then the value placed in this IE is a Mobile Identity value obtained from the 1x LAC Encapsulated PDU encapsulated in the A21 message being acknowledged, otherwise, it shall contain the Mobile Identity value contained in the A21 message being acknowledged. In the case that the HRPD AN sends an IMSI with all digits set to 0H in an A21-Air Interface Signaling message and receives a Mobile Identity value obtained from the 1x LAC Encapsulated PDU in the corresponding A21-Ack message, the HRPD AN shall store the received Mobile Identity value and continue to use it in reference to all A21 interface signaling for that MS/AT. b. This IE is included when a problem processing the A21 message being acknowledged has occurred and shall be set to a value that describes the problem encountered. The following table shows the bitmap layout for the A21-Ack message. 5.1.6.2 A21-Ack 7 6 (MSB) 5 4 3 2 1 0 Octet 1 1 2 3 4 5 (LSB) Mobile Identity (MN ID): A21 Element Identifier = [05H] 5-99 6 1 A21 Message Type = [02H] Length = [04H] Correlation Value = <any value>
3GPP2 A.S0008-C v2.0 5.1.6.2 A21-Ack 7 6 5 4 3 2 1 0 Octet 2 3 Length = [05H-08H] (10-15 digits) Identity Digit 1 = [0H-FH] Odd/even Type of Identity Indicator = [001 (MEID Hex Digits), = [1,0] 101 (ESN bit format) 58, 110 (IMSI BCD Digits)] Identity Digit 2 = [0H-FH] Identity Digit N = [0H-FH] Identity Digit N+2 = [0H-FH] A21 Element Identifier = [08H] Length = [01H] (MSB) A21 Cause Value = [00H = Unknown mobile, 01H = Unknown cell identifier(s), 02H = Tunneling of 1x messages not available, 03H = Resources not available, 04H = A21 context for this MS/AT may be released, 05H = Airlink lost, 06H = Abort Handoff from HRPD to 1x, 07H = Unspecified, 08H = Rejection, 09H = Already Paging] (LSB)
Identity Digit 3 = [0H-FH] Identity Digit N+1 = [0H-FH] = [1111] (if even number of digits) A21 Cause:
4 n n+1 1 2 3
2 3 4 5 6 7
5.1.6.3
A21-1x Parameters
This message is sent from the IWS to the HRPD AN to provide the HRPD AN with the 1x overhead parameter values to be transmitted in the CSNA 3G1XParameters message. Refer to [9]. This message also carries the RAND value from the IWS to the HRPD AN when the IWS has been configured to provide the RAND value. Information Element A21 Message Type Correlation ID Authentication Challenge Parameter (RAND) A21 1x Parameters Section Reference 5.2.4.3 5.2.4.7 5.2.4.9 5.2.4.5 Element Direction IWS HRPD AN IWS HRPD AN IWS HRPD AN IWS HRPD AN O O
a b
Type M R C C
Oc
5-100
3GPP2 A.S0008-C v2.0

1 2 3 4 5 6 7 8 9 10
a. When the A21-1x Parameters message is sent in response to an A21-1x Parameters Request message, the value contained in this IE shall be the same as the value contained in the Correlation ID IE of the A21-1x Parameters Request message. b. This IE is included when the IWS provides the RAND value to the HRPD AN. This IE, when included, shall always contain a Random Number Type of 0001. c. This IE is included when the IWS provides 1x overhead channel parameters to the HRPD AN. This field may contain all fields of the 3G1X Parameters message specified in [9] following the 3G1XParametersSignature field. The following table shows the bitmap layout for the A21-1x Parameters message. 5.1.6.3 A21-1x Parameters 7 6 (MSB) 5 4 3 2 1 0 Octet 1 1 2 3 4 5 (LSB) Authentication Challenge Parameter (RAND): A21 Element Identifier = [06H] Length = [05H] Reserved = [0000] (MSB) Random Number Type = [0001] (RAND) RAND = <any value> 6 1 2 3 4 5 6 (LSB) (MSB) A21 1x Parameters: A21 Element Identifier = [02H] Length = [01H FFH] 3G1X Parameters = <any value> (LSB) 7 1 2 3 k A21 Message Type = [03H] Length = [04H] Correlation Value = <any value>
11
12 13 14 15
5.1.6.4
A21-Event Notification
This message is sent from the IWS to the HRPD AN or from the HRPD AN to the IWS to notify the receiver that a particular event has occurred relative to a specific MS/AT. Information Element A21 Message Type Correlation ID Section Reference 5.2.4.3 5.2.4.7 5-101 Element Direction IWS HRPD AN IWS HRPD AN O Type M R
3GPP2 A.S0008-C v2.0 Information Element Mobile Identity (MN ID) A21 Event
1 2
Element Direction IWS HRPD AN IWS HRPD AN
Type O O R R
The following table shows the bitmap layout for the A21-Event Notification message. 5.1.6.4 A21-Event Notification 7 6 (MSB) 5 4 3 2 1 0 Octet 1 1 2 3 4 5 (LSB) Mobile Identity (MN ID): A21 Element Identifier = [05H] Length = [05H-08H] (10-15 digits) Identity Digit 1 = [0H-FH] Odd/even Type of Identity Indicator = [001 (MEID Hex Digits), = [1,0] 101 (ESN bit format) 59, 110 (IMSI BCD Digits)] Identity Digit 2 = [0H-FH] Identity Digit N = [0H-FH] Identity Digit N+2 = [0H-FH] A21 Element Identifier = [09H] Length = [01H] 6 1 2 3 A21 Message Type = [04H] Length = [04H] Correlation Value = <any value>
Identity Digit 3 = [0H-FH] Identity Digit N+1 = [0H-FH] = [1111] (if even number of digits) A21 Event:
4 n n+1 1 2
5-102
3GPP2 A.S0008-C v2.0 5.1.6.4 A21-Event Notification 7 (MSB) 6 5 4 3 2 1 0 (LSB) Octet 3 Event = 00H (MS/AT present in 1x), 01H (MS/AT present in HRPD/Cancel Handoff), 02H (1x Power Down), 03H (HRPD Power Down/Connection Closed), 04H (Handoff Rejected, 05H (1x Registration), 06H (Transmission of All 1x LAC Encapsulated PDUs disabled), 07H (Transmission of 1x LAC Encapsulated PDU(s) enabled), 08H (MS/AT no longer present in this AN/PCF), 09H (MS/AT no longer present in this 1x BS), 0AH (MS/AT Not Acquired), 0BH (Redirection)] Additional Event Info = <any value> (LSB) } Additional Event Info
1 2 3 4
IF (Event = 07H) Additional Event Info { 1: (MSB) 4 m
5.1.6.5
A21-1x Parameters Request
This message is sent from the HRPD AN to the IWS to request the 1x overhead parameter values to be transmitted in the CSNA 3G1XParameters message. Refer to [9]. Information Element A21 Message Type Correlation ID Section Reference 5.2.4.3 5.2.4.7 Element Direction HRPD AN IWS HRPD AN IWS O Type M R
5 6
The following table shows the bitmap layout for the A21-1x Parameters Request message. 5.1.6.5 A21-1x Parameters Request 7 6 (MSB) 5 4 3 2 1 0 Octet 1 1 2 3 4 5 (LSB) 6 A21 Message Type = [05H] Length = [04H] Correlation Value = <any value>
5-103
3GPP2 A.S0008-C v2.0

1 2 3
5.1.6.6
A21-Service Request
This message is sent from the HRPD AN to the IWS to request that a page be sent to an MS/AT. Information Element A21 Message Type Correlation ID Mobile Identity (MN ID) Service Option Section Reference 5.2.4.3 5.2.4.7 5.2.4.8 5.2.4.13 Element Direction HRPD AN IWS HRPD AN IWS HRPD AN IWS HRPD AN IWS O O Oa Type M R R R
4 5 6 7
a. This element indicates the service option requested by the HRPD AN. The following table shows the bitmap layout for the A21-Service Request message. 5.1.6.6 A21-Service Request 7 6 (MSB) 5 4 3 2 1 0 Octet 1 1 2 3 4 5 (LSB) Mobile Identity (MN ID): A21 Element Identifier = [05H] Length = [06H-08H] (10-15 digits) Identity Digit 1 = [0H-FH] Odd/even Indicator = [1,0] Type of Identity = [001 (MEID Hex Digits), 101 (ESN bit format) 60, 110 (IMSI BCD Digits)] Identity Digit 2 = [0H-FH] Identity Digit N = [0H-FH] Identity Digit N+2 = [0H-FH] A21 Element Identifier = [0AH] 6 1 2 3 A21 Message Type = [06H] Length = [04H] Correlation Value = <any value>
Identity Digit 3 = [0H-FH] Identity Digit N+1 = [0H-FH] = [1111] (if even number of digits) Service Option:
4 n n+1 1 2
Length = [02H]
5-104
3GPP2 A.S0008-C v2.0 5.1.6.6 A21-Service Request 7 (MSB) 6 5 4 3 2 1 0 Octet 3 Service Option = [00 3BH (HRPD Packet Data), 59 xxH (HRPD Packet Data with ReservationLabel) ] where xx = [00-FFH] and contains the ReservationLabel (LSB)
1
2 3 4 5
5.1.6.7
A21-Service Response
This message is sent from the IWS to the HRPD AN to acknowledge a request that a page be sent to an MS/AT or if the MS/AT could not be found. Information Element A21 Message Type Correlation ID Mobile Identity (MN ID) A21 Cause Section Reference 5.2.4.3 5.2.4.7 5.2.4.8 5.2.4.11 Element Direction IWS HRPD AN IWS HRPD AN IWS HRPD AN IWS HRPD AN O O Oa Type M R R C
6 7 8 9
a. This element shall only be included if the IWS does not grant the HRPD ANs service request. The following table shows the bitmap layout for the A21-Service Response message. 5.1.6.7 A21-Service Response 7 6 (MSB) 5 4 3 2 1 0 Octet 1 1 2 3 4 5 (LSB) Mobile Identity (MN ID): A21 Element Identifier = [05H] 6 1 A21 Message Type = [07H] Length = [04H] Correlation Value = <any value>
5-105
3GPP2 A.S0008-C v2.0 5.1.6.7 A21-Service Response 7 6 5 4 3 Odd/even Indicator = [1,0] 2 1 0 Octet 2 3 Length = [06H-08H] (10-15 digits) Identity Digit 1 = [0H-FH] Type of Identity = [001 (MEID Hex Digits), 101 (ESN bit format) 61, 110 (IMSI BCD Digits)] Identity Digit 2 = [0H-FH] Identity Digit N = [0H-FH] Identity Digit N+2 = [0H-FH] A21 Element Identifier = [08H] A21 Cause Value = [00H = Unknown mobile, 01H = Unknown cell identifier(s), 02H = Tunneling of 1x messages not available, 03H = Resources not available, 04H = A21 context for this MS/AT may be released, 05H = Airlink lost, 06H = Abort Handoff from HRPD to 1x, 07H = Unspecified, 08H = Rejection, 09H = Already Paging]
1
Identity Digit 3 = [0H-FH] Identity Digit N+1 = [0H-FH] = [1111] (if even number of digits) A21 Cause:
4 n n+1 1 2 3
Length = [01H]
2 3 4 5
5.1.6.8
A21-Radio Update Request
This message is sent from the IWS to the HRPD AN to request current radio information, e.g., current power strength measurements, for a particular MS/AT that is handing off from HRPD to 1x. Information Element A21 Message Type Correlation ID Mobile Identity (MN ID) Pilot List Section Reference 5.2.4.3 5.2.4.7 5.2.4.8 5.2.4.6 Element Direction IWS HRPD AN IWS HRPD AN IWS HRPD AN IWS HRPD AN O O O
a
Type M R R C
6 7 8
a. This IE is included if the 1x system wants the HRPD AN to measure specific pilots.
5-106
3GPP2 A.S0008-C v2.0

1
The following table shows the bitmap layout for the A21-Radio Update Request message. 5.1.6.8 A21-Radio Update Request 7 6 (MSB) 5 4 3 2 1 0 Octet 1 1 2 3 4 5 (LSB) Mobile Identity (MN ID): A21 Element Identifier = [05H] Length = [06H-08H] (10-15 digits) Identity Digit 1 = [0H-FH] Odd/even Type of Identity Indicator = [001 (MEID Hex Digits), = [1,0] 101 (ESN bit format) 62, 110 (IMSI BCD Digits)] Identity Digit 2 = [0H-FH] Identity Digit N = [0H-FH] Identity Digit N+2 = [0H-FH] 6 1 2 3 A21 Message Type = [08H] Length = [04H] Correlation Value = <any value>
4 n n+1 1 2 3 j j+1 (LSB) k k+1
Pilot List: A21 Element Identifier = [03H] Length = <variable> Number of Pilots = [01H-10H]
Pilot Entry { Number of Pilots: Channel Record Length = <variable> (MSB) Channel Record = <any value> Reserved = [00000] Cell ID Info = [000 No cell ID, Act. 1x pilot 001 1x cell ID, Act. 1x pilot 100 HRPD sector ID, HRPD pilot 101 HRPD sector ID only, 110 HRPD pilot only, 111 1x Cell ID only ]
IF (Cell ID Info = 001, 111) 1x Cell Identifier { 1:
5-107
3GPP2 A.S0008-C v2.0 5.1.6.8 A21-Radio Update Request 7 (MSB) 6 5 4 3 2 1 0 Octet k+2 k+3 (LSB) (MSB) }1x Cell Identifier IF (Cell ID Info = 100, 101), HRPD Sector Identifier { 1: HRPD Sector ID Length = <any value> (MSB) HRPD Sector ID = <any value> (LSB) } HRPD Sector Identifier IF (Cell ID Info = 000, 001, 100, 110), Pilot PN { 1: Referen ce Pilot = [0-1] Reserve d = [0] (MSB) Pilot PN Information = <any value> m k+2 k+3 k+n Cell = [001H-FFFH] Sector = [0H-FH] (0H = Omni) (LSB) k+4 k+5 k+6 MSCID = <any value>
(LSB) Pilot One Way Delay Included = [0] Pilot Strength = [000000]
m+1 m+2
} Pilot PN } Pilot Entry

1
2 3 4 5
5.1.6.9
A21-Radio Update Response
This message is sent from the HRPD AN to the IWS to provide current radio information, e.g., current power strength measurements, for a particular MS/AT that is handing off from HRPD to 1x. Information Element A21 Message Type Correlation ID Mobile Identity (MN ID) Pilot List Section Reference 5.2.4.3 5.2.4.7 5.2.4.8 5.2.4.6 Element Direction IWS HRPD AN IWS HRPD AN IWS HRPD AN IWS HRPD AN O Oa O
b
Type M R R R
6 7 8
a. This IE shall be set to the value contained in the Mobile Identity IE sent in the corresponding A21Radio Request Update message. 5-108
3GPP2 A.S0008-C v2.0

1 2 3 4
b. The first sector listed shall be the reference pilot. Refer to [10]. This IE is included if at least one pilot is being reported. The following table shows the bitmap layout for the A21-Radio Update Response message. 5.1.6.9 A21-Radio Update Response 7 6 (MSB) 5 4 3 2 1 0 Octet 1 1 2 3 4 5 (LSB) Mobile Identity (MN ID): A21 Element Identifier = [05H] Length = [06H-08H] (10-15 digits) Identity Digit 1 = [0H-FH] Odd/even Indicator = [1,0] Type of Identity = [001 (MEID Hex Digits), 101 (ESN bit format) 63, 110 (IMSI BCD Digits)] Identity Digit 2 = [0H-FH] Identity Digit N = [0H-FH] Identity Digit N+2 = [0H-FH] 6 1 2 3 A21 Message Type = [09H] Length = [04H] Correlation Value = <any value>
Correlation: A21 Element Identifier = [04H]
4 n n+1 1 2 3 j j+1 (LSB) k
Pilot List: A21 Element Identifier = [03H] Length = <variable> Number of Pilots = [01H-10H]
Pilot Entry { Number of Pilots: Channel Record Length = <variable> (MSB) Channel Record = <any value>
5-109
3GPP2 A.S0008-C v2.0 5.1.6.9 A21-Radio Update Response 7 6 5 Reserved = [00000] 4 3 2 1 0 Octet k+1 Cell ID Info = [000 No cell ID, Act. 1x pilot 001 1x cell ID, Act. 1x pilot 010 1x cell ID, Est. 1x pilot 011 1x cell ID, HRPD pilot 100 HRPD sector ID, HRPD pilot 101 HRPD sector ID only, 110 HRPD pilot only, 111 1x Cell ID only ]
IF (Cell ID Info = 001, 010, 011, 111) 1x Cell Identifier { 1: (MSB) MSCID = <any value> (LSB) (MSB) }1x Cell Identifier IF (Cell ID Info = 100,101), HRPD Sector Identifier { 1: HRPD Sector ID Length = <any value> (MSB) HRPD Sector ID = <any value> (LSB) } HRPD Sector Identifier Referen ce Pilot = [0-1] Reserve d = [0] (MSB) Pilot PN Information = <any value> m k+2 k+3 k+n Cell = [001H-FFFH] Sector = [0H-FH] (0H = Omni) (LSB) k+2 k+3 k+4 k+5 k+6
(LSB) Pilot One Way Delay Included = [0-1] Pilot Strength = [000000-111111]
m+1 m+2
(MSB) } Pilot Entry

1
Pilot One Way Delay = <any value> (LSB)
m+3 m+4
5-110
3GPP2 A.S0008-C v2.0
1 2
5.2
Information Element Definitions
5.2.1 5.2.1.1
A13 Information Element Definitions A13 Information Element Identifiers
4 5 6 7
The following table lists all the IEs that make up the messages defined in section 5.1. The table includes the Information Element Identifier (IEI) coding which distinguishes one IE from another. The table also includes a section reference indicating where the IE coding can be found. Element Name UATI 128 Security Layer Packet Sector ID Cause Mobile Identity (MN ID) PDSN IP Address Access Network Identifiers Session State Information Record Extended Session State Information Record Forward QoS Information Reverse QoS Information Subscriber QoS Profile Hardware ID Forward QoS Update Information Reverse QoS Update Information AT-ID Correlation ID Paging Control Information Paging Cause AT Designated Frequency A13 Vendor-Specific Information ADDS User Part A13 1x LAC Encapsulated PDU A13 1x Message Transmission Control Data Transfer IEI (Hex) 01H 02H 03H 04H 05H 06H 07H 08H 09H 0AH 0BH 0CH 0DH 0EH 0FH 10H 11H 12H 13H 14H 15H 16H 17H 18H 19H Reference 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 5.2.1.11 5.2.1.12 5.2.1.13 5.2.1.14 5.2.1.15 5.2.1.18 5.2.1.16 5.2.1.17 5.2.1.19 5.2.1.20 5.2.1.21 5.2.1.22 5.2.1.23 5.2.1.24 5.2.1.25 5.2.1.26 5.2.1.27 5.2.1.28
9 10 11
5.2.1.2
A13 Cross Reference of IEs with Messages
The following table provides a cross reference between the IEs and the messages defined in this specification.
5-111
3GPP2 A.S0008-C v2.0 Table 5.2.1.2-1 Information Element A13 1x LAC Encapsulated PDU A13 1x Message Transmission Control A13 Message Type Cross Reference of IEs with Messages Ref. 5.2.1.26 5.2.1.27 5.2.1.3 IEI 17H 18H Used in These Messages A13-Paging Request A13-1x Air Interface Signaling A13-Paging Request Ref. 5.1.1.7 5.1.1.13 5.1.1.7 5.1.1.1 5.1.1.2 5.1.1.3 5.1.1.4 5.1.1.5 5.1.1.6 5.1.1.7 5.1.1.8 5.1.1.9 5.1.1.10 5.1.1.11 5.1.1.12 5.1.1.13 5.1.1.14 5.1.1.1 5.1.1.2 5.1.1.2 5.1.1.7 5.1.1.7 5.1.1.7 5.1.1.8 5.1.1.9 5.1.1.10 5.1.1.11 5.1.1.13 5.1.1.14 5.1.1.4 5.1.1.6 5.1.1.12 5.1.1.7 5.1.1.8 5.1.1.9 5.1.1.10
none A13-Session Information Request A13-Session Information Response A13-Session Information Confirm A13-Session Information Reject A13-Resource Release Request A13- Resource Release Response A13-Paging Request A13-Paging Request Ack A13-Paging Delivered A13-Paging Delivered Ack A13-Keep Alive Request A13-Keep Alive Response A13-1x Air Interface Signaling A13-1x Air Interface Signaling Ack
A13 Vendor-Specific Information Access Network Identifiers ADDS User Part AT Designated Frequency AT-ID
5.2.1.24 5.2.1.10 5.2.1.25 5.2.1.23 5.2.1.19
15H 07H 16H 14H 10H
A13-Session Information Request A13-Session Information Response A13-Session Information Response A13-Paging Request A13-Paging Request A13-Paging Request A13-Paging Request Ack A13-Paging Delivered A13-Paging Delivered Ack A13-Keep Alive Request A13-1x Air Interface Signaling A13-1x Air Interface Signaling Ack
Cause
5.2.1.7
04H
A13-Session Information Reject A13-Resource Release Response A13-Keep Alive Response
Correlation ID
5.2.1.20
11H
A13-Paging Request A13-Paging Request Ack A13-Paging Delivered A13-Paging Delivered Ack
5-112
3GPP2 A.S0008-C v2.0 Table 5.2.1.2-1 Information Element Cross Reference of IEs with Messages Ref. IEI Used in These Messages A13-1x Air Interface Signaling A13-1x Air Interface Signaling Ack Data Transfer Extended SSIR Forward QoS Information Forward QoS Update Information Hardware ID 5.2.1.28 5.2.1.12 5.2.1.13 5.2.1.16 5.2.1.18 19H 09H A13-Session Information Request A13-Session Information Response A13-Session Information Response 0AH A13-Session Information Response 0EH A13-Session Information Response 0DH A13-Resource Release Request A13-Session Information Request A13-Keep Alive Request Mobile Identity (MN ID) Paging Cause Paging Control Information PDSN IP Address Reverse QoS Information Reverse QoS Update Information Sector ID Security Layer Packet Session State Information Record Subscribed QoS Profile UATI 128 5.2.1.8 5.2.1.22 5.2.1.21 5.2.1.9 5.2.1.14 5.2.1.17 5.2.1.6 5.2.1.5 5.2.1.11 5.2.1.15 5.2.1.4 05H 13H 12H 06H 0FH 03H 02H 08H A13-Session Information Response A13-Keep Alive Request A13-Paging Request Ack A13-Paging Request A13-Session Information Response A13-Session Information Response A13-Session Information Request A13-Resource Release Request A13-Session Information Request A13-Resource Release Request A13-Session Information Response A13-Paging Request 0CH A13-Session Information Response 01H A13-Session Information Request A13-Session Information Response A13-Session Information Confirm A13-Session Information Reject A13-Resource Release Request A13-Resource Release Response A13-Paging Request A13-Paging Request Ack A13-Paging Delivered A13-Paging Delivered Ack A13-Keep Alive Request A13-Keep Alive Response A13-1x Air Interface Signaling 5-113 Ref. 5.1.1.13 5.1.1.14 5.1.1.1 5.1.1.2 5.1.1.2 5.1.1.2 5.1.1.2 5.1.1.5 5.1.1.1 5.1.1.11 5.1.1.2 5.1.1.11 5.1.1.8 5.1.1.7 5.1.1.2 5.1.1.2 5.1.1.2 5.1.1.1 5.1.1.5 5.1.1.1 5.1.1.5 5.1.1.2 5.1.1.7 5.1.1.2 5.1.1.1 5.1.1.2 5.1.1.3 5.1.1.4 5.1.1.5 5.1.1.6 5.1.1.7 5.1.1.8 5.1.1.9 5.1.1.10 5.1.1.11 5.1.1.12 5.1.1.13
0BH A13-Session Information Response
3GPP2 A.S0008-C v2.0 Table 5.2.1.2-1 Information Element Cross Reference of IEs with Messages Ref. IEI Used in These Messages A13-1x Air Interface Signaling Ack
1
Ref. 5.1.1.14
2 3
5.2.1.3
A13 Message Type
The A13 Message Type IE is used to indicate the type of message on the A13 interface. A13 Message Name A13-Session Information Request A13-Session Information Confirm A13-Session Information Reject A13-Session Information Response A13-Resource Release Request A13-Resource Release Response A13-Paging Request A13-Paging Request Ack A13-Keep Alive Request A13-Keep Alive Response A13-Paging Delivered A13-Paging Delivered Ack A13-1x Air Interface Signaling A13-1x Air Interface Signaling Ack A13 Message Type 01H 02H 03H 04H 05H 06H 07H 08H 09H 0AH 0BH 0CH 0DH 0EH Section Reference 5.1.1.1 5.1.1.3 5.1.1.4 5.1.1.2 5.1.1.5 5.1.1.6 5.1.1.7 5.1.1.8 5.1.1.11 5.1.1.12 5.1.1.9 5.1.1.10 5.1.1.13 5.1.1.14
5 6
5.2.1.4
Unicast Access Terminal Identifier (UATI 128)
This IE is set to the terminal identifier associated with the AT. 5.2.1.4 Unicast Access Terminal Identifier (UATI 128) 7 6 5 4 Length (MSB) UATI 3 2 1 0 Octet 1 2 3 4 A13 Element Identifier = [01H]
(LSB)
7
18
Length UATI
This field contains the number of octets in this IE following this field as a binary number. This is set to the 128-bit terminal identifier associated with the AT and is determined by the target AN. Refer to section 2.5.
8 9
10
5-114
3GPP2 A.S0008-C v2.0

1 2
5.2.1.5
Security Layer Packet
This IE is set to the security layer packet received from the AT. 5.2.1.5 Security Layer Packet 7 6 5 4 Length (MSB) Security Layer Packet 3 2 1 0 Octet 1 2 3 4 A13 Element Identifier = [02H]
(LSB)
3 4 5 6
Length
This field contains the number of octets in this IE following this field as a binary number.
Security Layer Packet This is set to the security layer packet received from the AT.
7 8 9
5.2.1.6
Sector ID
The AN shall set this field to the address of the sector on which the access from the AT was received. The Sector ID is used with the Security Layer Packet to authenticate the session information request. 5.2.1.6 Sector ID 7 6 5 4 Length (MSB) Sector ID 3 2 1 0 Octet 1 2 3 4 A13 Element Identifier = [03H]
(LSB)
10 11 12
18
Length Sector ID
This field contains the number of octets in this IE following this field as a binary number. This is set to the 128-bit address of the sector.
13 14
5.2.1.7
Cause 5.2.1.7 Cause
This IE is used to indicate the reason for occurrence of a particular event and is coded as follows. 7 6 5 4 Length (MSB) Cause Value (LSB) 3 2 1 0 Octet 1 2 3
A13 Element Identifier = [04H]
5-115
3GPP2 A.S0008-C v2.0

1 2
Length Cause Value
This field contains the number of octets in this IE following this field as a binary number. This field is set to the range of values as follows: Hex Values 01 02 03 04 05 06 07 08 09 Meaning Protocol Subtype Not Recognized Protocol Subtype Attribute(s) Not Recognized Protocol Subtype Attribute(s) Missing Requested Session Not Found Requested Session Not Authentic Requested prior session released Requested prior session not found Requested prior session not authentic Requested session is not in handoff
4 5
5.2.1.8
Mobile Identity (MN ID) 5.2.1.8 Mobile Identity (MN ID)
This IE is used to provide the ATs Mobile Node Identification (MN ID). 7 6 5 4 Length
Identity Digit 1 Odd/even Indicator Type of Identity
Octet 1 2
3
Identity Digit 3
Identity Digit 2
Identity Digit N+1
Identity Digit N Identity Digit N+2
n n+1
6 7 8 9
Length Type of Identity Table 5.2.1.8-1 Binary Values 000 110 Odd/Even Indicator (octet 3; bit 3) Identity Digits (octet 3 etc.)
This field contains the number of octets in this IE following this field as a binary number. This field is defined as follows: Mobile Identity - Type of Identity Coding Mobile Identity Meaning No Identity Code IMSI All other values are reserved. This field is set to 0 for an even number of digits and to 1 for an odd number of identity digits. The IMSI Identity Digit 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.
10 11 12 13 14 15
5-116
3GPP2 A.S0008-C v2.0

1 2
5.2.1.9
PDSN IP Address
This IE is used to provide the PDSN address. 5.2.1.9 PDSN IP Address 7 6 5 4 Length (MSB) PDSN IP Address 3 2 1 0 Octet 1 2 3 4 5 (LSB) 6 A13 Element Identifier = [06H]
3 4 5 6 7
Length
This field contains the number of octets in this IE following this field as a binary number. If the PDSN IP Address is not available, the length field shall be set to 00H. This field is set to the IPv4 address of a PDSN.
PDSN IP Address
8 9 10 11
5.2.1.10
Access Network Identifiers
This IE uniquely identifies the PCF and 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. 5.2.1.10 7 6 5 4 Access Network Identifiers 3 2 1 0 Octet 1 2 3 4 (LSB) (MSB) NID (LSB) PZID 5 6 7 8
A13 Element Identifier = [07H] Type = 01H Length

Reserved
(MSB)
SID
12 13 14 15 16 17 18 19 20
Type Length SID NID PZID
This field identifies the ANID Sub Type (01H). This field contains the number of octets in this IE following this field as a binary number. This two octet field is coded to a value that uniquely identifies the cellular or PCS system. This two octet field is coded to a value that uniquely identifies the network within a cellular or PCS system. This one octet field is coded to a value that uniquely identifies the PCF coverage Area within a particular SID/NID area. The combined SID/NID/PZID triplet is unique to a PCF. 5-117
3GPP2 A.S0008-C v2.0

1
2 3 4
5.2.1.11
Session State Information Record
This IE is used to send HRPD Session Information for one [protocol type, protocol subtype] pair for the main HRPD personality (i.e., the personality with Personality Index = 0) as specified in [10]. If the ATs HRPD session does not support personalities, then this IE is used to send HRPD Session Information for one [protocol type, protocol subtype] pair of the HRPD session as specified in [10]. 5.2.1.11 7 (MSB) (MSB) 6 5 4 Length (LSB) Session State Information Record Session State Information Record 3 2 1 0 Octet 1 2 3 4
5 6
(LSB)
7 8 9 10 11 12
Length Session State Information Record
This field contains the number of octets in this IE following this field as a binary number. This field contains the air interface protocol attributes and associated public data for one [protocol type, protocol subtype] pair. The format is as specified in [10].
13 14 15
5.2.1.12
Extended Session State Information Record
This IE is used to send HRPD Session Information for one [protocol type, protocol subtype] pair of an HRPD personality that is not the main personality, as specified in [10]. 5.2.1.12 7 (MSB) Reserved (MSB) 6 5 Extended Session State Information Record 4 Length (LSB) Personality Index Session State Information Record 3 2 1 0 Octet 1 2 3 4 5 A13 Element Identifier = [09H]
(LSB)
16 17 18 19
Length Personality Index
This field contains the number of octets in this IE following this field as a binary number. This field identifies the applicable HRPD personality of which this SSIR is a part. Refer to [10].
5-118
3GPP2 A.S0008-C v2.0

1 2 3 4
This field contains the air interface protocol attributes and associated public data for one [protocol type, protocol subtype] pair. The format is as specified in [10].
5.2.1.13
Forward QoS Information
This IE provides mappings of forward IP flow(s) to service connection. 5.2.1.13 7 6 5 4 Length Forward QoS Information Entry 1 Forward QoS Information Entry 2 Forward QoS Information 3 2 1 0 Octet 1 2 variable variable
A13 Element Identifier = [0AH]
Forward QoS Information Entry n

7 8 9 10 11 12
variable
Length Forward QoS Information Entry
This field contains the number of octets in this IE following this field as a binary number. Each Forward QoS Information Entry specifies all of the forward IP flow(s) that are associated with a given service connection. Each entry is coded as follows. Forward QoS Information Entry 4 SR_ID Reserved Forward Flow Count Forward Flow Entry 1 Forward Flow Entry 2 3 2 1 0 Octet j j+1 j+2 variable variable Entry Length
5.2.1.13 7 6 5
Forward Flow Entry n

13 14 15 16 17 18 19 20 21 22 23
variable
Entry Length SR_ID Forward Flow Count Forward Flow Entry i
This field contains the number of octets in this entry following the Entry Length field as a binary number. This field identifies the service connection. This field indicates the number of Forward Flow Entry fields contained in this Forward QoS Information Entry. This set of fields (Forward Flow Entry 1, 2 ... n) contains the forward flow ID(s) associated with the service connection identified by the SR_ID field. Each Forward Flow Entry is coded as follows.
5-119
3GPP2 A.S0008-C v2.0 5.2.1.13 7 6 5 4 Forward Flow Entry 3 2 1 0 Octet k k+1
Entry Length Forward Flow ID i

1 2 3 4 5
Entry Length Forward Flow ID i 5.2.1.14 Reverse QoS Information
This field contains the number of octets in this entry following the Entry Length field as a binary number. This field contains the flow ID of a given forward IP flow. Refer to [8] for detailed information.
This IE provides mappings of reverse IP flow(s) to service connection. 5.2.1.14 7 6 5 4 Length Reverse QoS Information Entry 1 Reverse QoS Information Entry 2 Reverse QoS Information 3 2 1 0 Octet 1 2 variable variable
Reverse QoS Information Entry n

8 9 10 11 12 13 14
variable
Length Reverse QoS Information Entry
This field contains the number of octets in this IE following this field as a binary number. Each Reverse QoS Information Entry specifies all of the reverse IP flow(s) that are associated with a given service connection. Each entry is coded as follows. Reverse QoS Information Entry 4 SR_ID Reserved Reverse Flow Count Reverse Flow Entry 1 Reverse Flow Entry 2 3 2 1 0 Octet j j+1 j+2 variable variable Entry Length
5.2.1.14 7 6 5
Reverse Flow Entry n

15 16 17 18
variable
Entry Length SR_ID
This field contains the number of octets in this entry following the Entry Length field as a binary number. This field identifies the service connection. 5-120
3GPP2 A.S0008-C v2.0

1 2 3 4 5 6 7
Reverse Flow Count Reverse Flow Entry i
This field indicates the number of Reverse Flow Entry fields contained in this Reverse QoS Information Entry. This set of fields (Reverse Flow Entry 1, 2 ... n) contains the reverse flow ID(s) associated with the service connection identified by the SR_ID field. Each Reverse Flow Entry is coded as follows. 5.2.1.14 Reverse Flow Entry 3 2 1 0 Octet k k+1
Entry Length Reverse Flow ID i

8 9 10 11 12 13
This field contains the number of octets in this entry following the Entry Length field as a binary number. This field contains the flow ID of a given reverse IP flow. Refer to [8] for detailed information.
14
5.2.1.15
15
This IE is used to provide Subscriber QoS Profile. 5.2.1.15 7 6 5 4 Length Subscriber QoS Profile Subscriber QoS Profile 3 2 1 0 Octet 1 2 variable
A13 Element Identifier = [0CH]
16 17 18 19 20
Length Subscriber QoS Profile 5.2.1.16
This field contains the number of octets in this IE following this field as a binary number. This field contains Subscriber QoS Profile formatted as RADIUS attributes. Refer to [8] for detailed information.
21 22 23
Forward QoS Update Information
This IE is used to convey the PDSN updated QoS to use for a given personality when the PDSN updated the QoS for one or more forward IP Flows. 5.2.1.16 Forward QoS Update Information 7 6 5 4 Length Reserved Forward Flow Count Forward Flow Entry { Forward Flow Count : Forward Flow ID 5-121 i+1 Personality Index 3 2 1 0 Octet 1 2 3 4 A13 Element Identifier = [0EH]
3GPP2 A.S0008-C v2.0 5.2.1.16 7 (MSB) 6 Forward QoS Update Information 1 0 Octet i+2 i+3 (LSB) } Forward Flow Entry
1 2 3 4 5 6 7 8 9 10 11 12 13
5 4 3 2 Forward Updated QoS Sub-BLOB Length Forward Updated QoS Sub-BLOB
Length Personality Index Forward Flow Count Forward Flow ID
This field contains the number of octets in this IE following this field as a binary number This field identifies the applicable HRPD personality for the information contained in this IE. Refer to [10]. This field indicates the number of Flow ID Entry contained in this IE. This field contains the flow ID of a given forward IP flow. Refer to [8] for detailed information. This field contains the number of octets in the Forward Updated QoS Sub-BLOB field as a binary number.
Forward Updated QoS Sub-BLOB Length
Forward Updated QoS Sub-BLOB 5.2.1.17
This field contains the Updated QoS Sub-BLOB for this flow. Refer to [8] for detailed information.
14 15 16
Reverse QoS Update Information
This IE is used to convey the PDSN updated QoS to use for a given personality when the PDSN updated the QoS for one or more reverse IP Flows. 5.2.1.17 Reverse QoS Update Information 7 6 5 4 Length Reserved Reverse Flow Count Reverse Flow Entry { Reverse Flow Count : Reverse Flow ID Reverse Updated QoS Sub-BLOB Length (MSB) Reverse Updated QoS Sub-BLOB (LSB) } Reverse Flow Entry Personality Index 3 2 1 0 Octet 1 2 3 4 j+1 j+2 j+3 k A13 Element Identifier = [0FH]
17 18 19 20
Length Personality Index
This field contains the number of octets in this IE following this field as a binary number This field identifies the applicable HRPD personality for the information contained in this IE. Refer to [10]. 5-122
3GPP2 A.S0008-C v2.0

1 2 3 4 5 6 7 8 9
Reverse Flow Count Reverse Flow ID
This field indicates the number of Flow ID Entry contained in this IE. This field contains the flow ID of a given reverse IP flow. Refer to [8] for detailed information. This field contains the number of octets in the Reverse Updated QoS Sub-BLOB field as a binary number.
Reverse Updated QoS Sub-BLOB Length
Reverse Updated QoS Sub-BLOB 5.2.1.18 Hardware ID
10 11
This IE is used to provide the Hardware ID. 5.2.1.18 7 6 5 4 3
Hardware ID 2 1 0 Octet 1 2 3 4 5 (LSB) 6 7
A13 Element Identifier = [0DH] Length = [variable] Hardware ID Length = [variable] (MSB) Hardware ID Type
(MSB)
Hardware ID Value (LSB)
n Length Hardware ID Length This field contains the number of octets in this IE following this field as a binary number If Hardware ID Type is not set to FFFFFFH, the AT shall set this field to the length in octets of the Hardware ID Value field. Otherwise, the AT shall set this field to 00H. The AT shall set this field according to [10]. The AT shall set this field to the unique ID (specified by Hardware ID Type. Refer to [10]) that has been assigned to the AT by the manufacturer.
12 13 14 15 16 17 18 19 20
Hardware ID Type Hardware ID Value
21 22
5.2.1.19
AT-ID AT-ID 2 1 0 Octet 1 2 ATI Type AT identifier 3 variable
This IE is used to provide the identifier for the AT. 5.2.1.19 7 6 5 4 Length Reserved 3
5-123
3GPP2 A.S0008-C v2.0

1 2 3
Length ATI Type Binary Values 0000 0001 0010 0011 0100 (all others)
This field contains the number of octets in this IE following this field as a binary number. Access Terminal Identifier types associated with the AT are as follows. ATI Type Meaning Reserved (for Broadcast ATI (BATI)) Reserved (for Multicast ATI (MATI)) Unicast ATI 32 (UATI 32) Reserved (for Random ATI (RATI)) Reserved (for Unicast ATI 128 (UATI128)) (reserved) AT identifier Length (bits) N/A N/A 32 N/A N/A
4 5
For UATI32 (Type 0010), the AT identifier field is encoded as follows. 7 (MSB) (MSB) 6 5 4 3 UATI024 (LSB) 2 1 0 (LSB) Octet 4 5 6 7
UATIColorCode
6 7 8
UATIColorCode UATI024
This field contains the UATIColorCode for the AT. Refer to [10]. This field contains the UATI024 for the AT. Refer to [10].
9 10
5.2.1.20
Correlation ID
This IE is set to the correlation identifier associated with the AT. 5.2.1.20 Correlation ID 7 6 5 4 Length (MSB) Correlation Value 3 2 1 0 Octet 1 2 3 4 5 (LSB) 6 A13 Element Identifier = [11H]
11 12 13 14 15
Length Correlation Value
This field contains the number of octets in this IE following this field as a binary number. This field contains a value that allows an entity to correlate a request-response pair of messages. The value is a manufacturer concern.
16 17
5.2.1.21
Paging Control Information
This IE is sent to convey control information for a paging request. 5-124
3GPP2 A.S0008-C v2.0 5.2.1.21 7 6 5 4 Length Paging Control Information Entry #1 Paging Control Information Entry #n
1 2 3 4 5
Paging Control Information 3 2 1 0 Octet 1 2 variable variable variable
Length Paging Control Information Entry
This field contains the number of octets in this IE following this field as a binary number. This field contains control information for which the source AN/PCF requests the target AN/PCF to page. Paging Control Information Entry 4 3 2 1 0 Octet 1 2 variable
5.2.1.21-1 7 6 5
Paging Control Information Type Paging Control Information Length Paging Control Information Value
6 7 8
When the Paging Control Information Type is set to 01H (Message Transmission Time), the Paging Control Information Entry field is coded as follows. 5.2.1.21-2 Paging Control Information (Message Transmission Time) 7 6 5 4 3 2 1 0 Octet 1 2 3 4 (LSB) Reserved (MSB) Tc 5 6 7 8 9 (LSB) 10 Paging Control Information Type = [01H (Message Transmission Time)] Paging Control Information Length Message Priority (MSB) System Time for Packet Transmission
9 10 11 12 13 14 15 16 17
Paging Control Information Type Paging Control Information Length Message Priority
This field indicates the type of paging control information. This field shall be set to 01H (Message Transmission Time). This field contains the number of octets for the fields following this field. This field contains a suggested Message Priority for the target AN to use to transmit the page message. This field is an 8 bit binary number between 0 and 255 where the lower values indicate higher priorities. This value is given as a guideline for the target AN. 5-125
3GPP2 A.S0008-C v2.0

1 2 3 4 5 6 7 8 9 10
System Time for Packet Transmission
This field contains the 16 LSBs of CDMA System Time in Slots [10] of when the page message is to be transmitted in the source AN. This value is given as a guideline for the target AN. If the target ANs/PCFs can transmit the page over-the-air in the same slot, then the chance that the AT will miss the page is reduced. This field contains the Tc value of the source AN. This value is used to calculate the paging cycle [10].
Tc
When the Paging Control Information Type is set to 02H (Registration Location Information), the Paging Control Information Entry field is coded as follows. 5.2.1.21-3 Paging Control Information (Registration Location Information) 7 6 5 4 3 2 1 0 Octet 1 2 3 4 (LSB) (MSB) Paging Longitude (LSB) (MSB) (LSB) Paging Radius Reserved Reserved Reserved 5 6 7 8 9 10 Paging Control Information Type = [02H (Registration Location Information)] Paging Control Information Length (MSB) Paging Latitude
11 12 13 14 15 16 17 18 19 20 21 22 23 24
Paging Control Information Type Paging Control Information Length Paging Latitude
This field indicates the type of paging control information. This field shall be set to 02H (Registration Location Information). This field contains the number of octets for the fields following this field. This field contains the Latitude value of the center point of the requested paging area; e.g., of the sector where the AT last registered (as specified in [10]). This field contains the Longitude value of the center point of the requested paging area; e.g., of the sector where the AT last registered (as specified in [10]). This field contains the radius of the paging area (i.e., RouteUpdateRadiusOverhead value) of the sector where the AT last registered (as specified in [10]).
Paging Longitude
Paging Radius
25 26
5.2.1.22
Paging Cause
This IE carries the cause value indicating the result of the message processing. 5.2.1.22 Paging Cause 7 6 5 4 Length 5-126 3 2 1 0 Octet 1 2 A13 Element Identifier = [13H]
3GPP2 A.S0008-C v2.0 5.2.1.22 7 (MSB)

1 2 3 4
Paging Cause 3 2 1 0 (LSB) Octet 3
Cause Value
Length Cause Value
This field contains the number of octets in this IE following this field as a binary number. This field is set to indicate the result of the message processing. Hex Values 00 01 02 03 Cause Value Meaning Page transmission time unknown or not in specified slot Page transmission in specified slot Paging request rejected no reason specified Paging request accepted for a subset of sectors All other values are reserved
6 7
5.2.1.23
AT Designated Frequency
This IE indicates the band class and frequency that is reported as designated frequency from the AT. 5.2.1.23 AT Designated Frequency 7 6 5 4 Length Band Class CDMA Channel CDMA System Time (MSB) (LSB) 3 2 1 0 Octet 1 2 3 4 5 6 7 8 9 A13 Element Identifier = [14H]
8 9 10 11 12 13 14
Length Band Class CDMA Channel CDMA System Time
This field indicates the number of octets in this IE following the Length field. This field shall be set to Band Class. This field shall be set to the CDMA channel number in the specified Band Class corresponding to the CDMA frequency assignment for the designated frequency. This field shall be set to the CDMA system time at which the AN received the BCMCS Registration message, in units of 80 ms. For detail, refer to [10].
15 16
5.2.1.24
A13 Vendor-Specific Information
This IE may be used to send vendor-specific information to another AN.
5-127
3GPP2 A.S0008-C v2.0 5.2.1.24 7 6 5 4 Length (MSB) Vendor-Specific Information A13 Vendor-Specific Information 3 2 1 0 Octet 1 2 3
(LSB)
1 2 3 4 5 6
Length Vendor-Specific Information
This field contains the number of octets in this IE following this field as a binary number. This field contains vendor-specific information. This information shall be placed in octets 3-n in 8-bit ASCII format. This field should begin with the vendors company name.
7 8
5.2.1.25
ADDS User Part
This IE contains the application data message. 5.2.1.25 ADDS User Part 7 6 5 4 Length Reserved Data Burst Type Application Data Message 3 2 1 0 Octet 1 2 3 4-n A13 Element Identifier = [16H]
9 10 11 12 13 14
Length Data Burst Type Application Data Message
This field contains the number of octets in this IE following this field as a binary number. This field contains Data Burst Type defined in [18]. This field has variable length and is encoded as follows: For Short Data Burst, the Application Data Message is the SDB as specified in [22].
15 16
5.2.1.26
A13 1x LAC Encapsulated PDU
This IE contains a 1x LAC Encapsulated packet to be transferred over the HRPD air interface. 5.2.1.26 A13 1x LAC Encapsulated PDU 7 6 5 4 Length LAC Encapsulated PDU 3 2 1 0 Octet 1 2 variable A13 Element Identifier = [17H]
17 18 19 20
Length LAC Encapsulated PDU
This field contains the number of octets in this IE following this field as a binary number. This field contains a 1x LAC Encapsulated packet payload to be sent over the HRPD air interface. For a detailed description, refer to [10].
5-128
3GPP2 A.S0008-C v2.0

1 2 3
5.2.1.27
A13 1x Message Transmission Control
This IE contains information about the 1x LAC Encapsulated PDU received from or to be transmitted over 3G1X Circuit Services Notification Application [9]. 5.2.1.27 A13 1x Message Transmission Control 7 6 5 4 Length Reserved Ack Required 3G1X Logical Channel 3 2 1 0 Octet 1 2 3 A13 Element Identifier = [18H]
ProtocolRevision
4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24
Length AckRequired
This field contains the number of octets in this IE following this field as a binary number. The HRPD AN shall set this field to be identical to the value of the AckRequired field received in the 3G1XServices message. The PCF shall set this field to the desired value of the AckRequired field in the 3G1XServices message of 3G1X Circuit Services Notification Application that the HRPD AN shall use to transmit the 1x LAC Encapsulated PDU. Refer to [9]. The HRPD AN shall set this field to be identical to the value of the 3G1XLogicalChannel field received in the 3G1XServices message. The PCF shall set this field to the desired value of the 3G1XLogicalChannel field in the 3G1XServices message of 3G1X Circuit Services Notification Application that the HRPD AN shall use to transmit the 1x LAC Encapsulated PDU. Refer to [9]. The HRPD AN shall set this field to be identical to the value of the ProtocolRevision field received in the 3G1XServices message. The PCF shall set this field to the desired value of the ProtocolRevision field in the 3G1XServices message of 3G1X Circuit Services Notification Application that the HRPD AN shall use to transmit the 1x LAC Encapsulated PDU. Refer to [9].
3G1XLogicalChannel
ProtocolRevision
25 26 27 28
5.2.1.28
Data Transfer
When sent by the target AN, this IE identifies that the sending AN is capable of data transfer during an A13 session transfer. When sent by the source AN, this IE indicates that the sending AN has buffered data to send. 5.2.1.28 7 6 5 4 Length Data Transfer Type Data Transfer Value Data Transfer 3 2 1 0 Octet 1 2 3 variable
29 30
Length
This field contains the number of octets in this IE following this field as a binary number. 5-129
3GPP2 A.S0008-C v2.0

1 2 3
Data Transfer Type
This field identifies the type of data transfer. Allowable values are defined as follows. Table 5.2.1.28-1 Hex Values 01H 02H Data Transfer Types
Data Transfer Type Meaning
Target information Source information All other values are reserved. This field is set according to the Type field.
4 5 6 7
Data Transfer Value
When the Data Transfer Type is set to 01H, the Data Transfer Value includes the upper 24 bits of the GRE key of the target AN, to be used for data transfer during A13 session transfer and is coded as follows. 7 (MSB) 6 5 4 3 2 1 0 Octet 4 5 (LSB) Address Type Target IP Address 6 7 variable
A24 Connection ID
8 9 10 11 12 13
A24 Connection ID
This field contains the 24 bit A24 connection identifier used as the upper 24 bits of the GRE key for data transfer between the source and target AN. This field indicates the type and format of the IP Address that follows. Table 5.2.1.28-2 Hex Values 01H 02H Target IP Address Type
Address Type
Target IP Address Meaning
Internet Protocol IPv4 Internet Protocol IPv6 All other values are reserved.
14 15 16
Target IP Address 7 (MSB) 6 5
This field is used to indicate the IP address of the target AN and is coded as follows for Address Type 01H. 4 3 2 1 0 Octet 8 9 10 (LSB) 11
Target IPv4 Address
17 18 19
Target IPv4 Address
This field contains the 32 bit IPv4 address of the target AN.
The Target IP Address field is coded as follows for Address Type 02H.
5-130
3GPP2 A.S0008-C v2.0 7 (MSB) 6 5 4 (LSB)

1 2 3 4
Octet 8 23
Target IPv6 Address
Target IPv6 Address
This field contains the 128 bit IPv6 address of the target AN.
When the Data Transfer Type is set to 02H, the Data Transfer Value provides a list of RLP_IDs and is coded as follows. 7 6 5 4 3 RLP Count RLP_ID #1 RLP_ID #2 ... RLP_ID #n 2 1 0 Octet 4 5 6 ... n
5 6 7 8 9
RLP Count RLP_ID
This field indicates the number of RLP_ID fields following the RLP Count field. This field indicates the RLP_ID for which the source AN transfers data over the A24 interface.
10
5.2.2 5.2.2.1
11 12 13 14
The following table lists all the IEs that make up the messages defined in section 5.1. The table includes the Information Element Identifier (IEI) coding which distinguishes one IE from another. The table also includes a section reference indicating where the IE coding can be found. Element Name Mobile Identity (MN ID) Access Network Identifiers Session State Information Record Proposed Session State Information Record Extended Session State Information Record Source PDSN Address Reserved Encapsulated Message Session Transfer Information Session Transfer Abort Cause AT-ID ConfirmedUATI Identifier (Hex) 01H 02H 03H 04H 05H 06H 07H 08H 09H 0AH 0BH 0CH 0DH 5-131 Reference 5.2.2.4 5.2.2.5 5.2.2.10 5.2.2.11 5.2.2.12 5.2.2.7 N/A 5.2.2.6 5.2.2.8 5.2.2.9 5.2.2.13 5.2.2.14
3GPP2 A.S0008-C v2.0 Element Name AssignedUATI LCM_UATI SLP-D Parameters SLP-F Parameters Forward QoS Information Reverse QoS Information Subscriber QoS Profile Forward QoS Update Information Reverse QoS Update Information Session Transfer Reject Cause Correlation ID Session Transfer Complete Parameters Sequence Number Fixed Rate Mode Serving Sector Information FL Signal Tunnel Parameter Sector Endpoint Information SLP Reset Message SEQ Info Assigning SC IP Address Timers RTD Information Serving Sector ID Target Sector ID
1
Identifier (Hex) 0EH 0FH 10H 11H 12H 13H 14H 15H 16H 17H 18H 19H 1AH 1BH 1CH 1DH 1EH 1FH 20H 21H 22H 23H 24H
Reference 5.2.2.15 5.2.2.16 5.2.2.17 5.2.2.18 5.2.2.19 5.2.2.20 5.2.2.21 5.2.2.22 5.2.2.23 5.2.2.24 5.2.2.25 5.2.2.26 5.2.2.27 5.2.2.28 5.2.2.29 5.2.2.30 5.2.2.31 5.2.2.32 5.2.2.33 5.2.2.34 5.2.2.35 5.2.2.36 5.2.2.37
2 3 4
5.2.2.2
The following table provides a cross reference between the IEs and the messages defined in this specification. Table 5.2.2.2-1 Information Element A16 Message Type A16 Cross Reference of IEs with Messages Ref. 5.2.2.3 IEI Used in These Messages A16-Session Transfer Response A16-Session Transfer Complete A16-Session Release Indication A16-Session Release Indication Ack A16-Session Transfer Abort A16 -Session Transfer Abort Ack A16-Session Transfer Reject A16-FL Signal Tunnel 5-132 Ref. 5.1.2.1 5.1.2.2 5.1.2.3 5.1.2.4 5.1.2.5 5.1.2.6 5.1.2.7 5.1.2.8 5.1.2.9
none A16-Session Transfer Request
3GPP2 A.S0008-C v2.0 Table 5.2.2.2-1 Information Element A16 Cross Reference of IEs with Messages Ref. IEI Used in These Messages A16-FL Signal Tunnel Ack A16-RL Signal Tunnel A16-RL Signal Tunnel Ack A16-Attributes Update A16-Attributes Update Ack Access Network Identifiers AssignedUATI Assigning SC IP Address AT-ID 5.2.2.5 5.2.2.15 5.2.2.33 5.2.2.13 02H 20H A16-Session Transfer Request A16-Session Transfer Request A16-Session Transfer Response A16-Session Transfer Complete A16-Session Release Indication A16-Session Release Indication Ack A16-Session Transfer Abort A16 -Session Transfer Abort Ack A16-Session Transfer Reject A16-FL Signal Tunnel A16-FL Signal Tunnel Ack A16-RL Signal Tunnel A16-RL Signal Tunnel Ack A16-Attributes Update A16-Attributes Update Ack ConfirmedUATI Correlation ID 5.2.2.14 5.2.2.25 0DH A16-Session Transfer Complete 18H A16-Session Transfer Request A16-Session Transfer Response A16-Session Transfer Complete A16-Session Release Indication A16-Session Release Indication Ack A16-Session Transfer Abort A16 -Session Transfer Abort Ack A16-Session Transfer Reject Encapsulated Message 5.2.2.6 09H A16-Session Transfer Request A16-FL Signal Tunnel A16-RL Signal Tunnel Extended Session State Information 5.2.2.12 Record 05H A16-Session Transfer Request A16-Session Transfer Response 5-133 0EH A16-Session Transfer Complete 0CH A16-Session Transfer Request Ref. 5.1.2.10 5.1.2.11 5.1.2.12 5.1.2.13 5.1.2.14 5.1.2.1 5.1.2.3 5.1.2.1 5.1.2.1 5.1.2.2 5.1.2.3 5.1.2.4 5.1.2.6 5.1.2.6 5.1.2.7 5.1.2.8 5.1.2.9 5.1.2.10 5.1.2.11 5.1.2.12 5.1.2.13 5.1.2.14 5.1.2.3 5.1.2.1 5.1.2.2 5.1.2.3 5.1.2.4 5.1.2.6 5.1.2.6 5.1.2.7 5.1.2.8 5.1.2.1 5.1.2.9 5.1.2.11 5.1.2.1 5.1.2.2
3GPP2 A.S0008-C v2.0 Table 5.2.2.2-1 Information Element A16 Cross Reference of IEs with Messages Ref. IEI Used in These Messages A16-Session Transfer Complete A16-Attributes Update Fixed Rate Mode FL Signal Tunnel Parameter Forward QoS Information Forward QoS Update Information LCM UATI Mobile Identity (MN ID) 5.2.2.28 5.2.2.30 5.2.2.19 5.2.2.22 5.2.2.16 5.2.2.4 1BH A16-Session Transfer Complete 1DH A16-FL Signal Tunnel 12H 15H 0FH 01H 04H A16-Session Transfer Request A16-Session Transfer Request A16-Session Transfer Complete A16-Session Transfer Request A16-Session Transfer Response A16-Attributes Update Reverse QoS Information Reverse QoS Update Information RTD Information Sector Endpoint Information Sequence Number 5.2.2.20 5.2.2.23 5.2.2.35 5.2.2.31 5.2.2.27 13H 16H 22H A16-Session Transfer Request A16-Session Transfer Request A16-Session Transfer Request A16-Attributes Update 1AH A16-FL Signal Tunnel A16-FL Signal Tunnel Ack A16-RL Signal Tunnel A16-RL Signal Tunnel Ack A16-Attributes Update A16-Attributes Update Ack Serving Sector ID Serving Sector Information 5.2.2.36 5.2.2.29 23H A16-Session Transfer Request A16-Session Transfer Complete A16-Attributes Update Session Transfer Abort Cause Session Transfer Complete Parameters Session Transfer Reject Cause Session Transfer Information Session State Information Record 5.2.2.9 5.2.2.26 5.2.2.24 5.2.2.8 5.2.2.10 0BH A16-Session Transfer Abort 19H 17H 03H A16-Session Transfer Complete A16-Session Transfer Reject A16-Session Transfer Request A16-Session Transfer Complete A16-Attributes Update SLP-D Parameters SLP-F Parameters SLP Reset Message SEQ Info Source PDSN Address 5.2.2.17 5.2.2.18 5.2.2.32 5.2.2.7 10H 11H 1FH 06H A16-Session Transfer Complete A16-Session Transfer Complete A16-Session Transfer Complete A16-Session Transfer Request 1CH A16-Session Transfer Request Ref. 5.1.2.3 5.1.2.13 5.1.2.3 5.1.2.9 5.1.2.1 5.1.2.1 5.1.2.3 5.1.2.1 5.1.2.2 5.1.2.13 5.1.2.1 5.1.2.1 5.1.2.1 5.1.2.1 5.1.2.13 5.1.2.9 5.1.2.10 5.1.2.11 5.1.2.12 5.1.2.13 5.1.2.14 5.1.2.1 5.1.2.1 5.1.2.3 5.1.2.13 5.1.2.6 5.1.2.3 5.1.2.8 5.1.2.2 5.1.2.1 5.1.2.3 5.1.2.13 5.1.2.3 5.1.2.3 5.1.2.3 5.1.2.1
Proposed Session State Information 5.2.2.11 Record
1EH A16-Session Transfer Request
0AH A16-Session Transfer Response
5-134
3GPP2 A.S0008-C v2.0 Table 5.2.2.2-1 Information Element Subscriber QoS Profile Target Sector ID Timers
1
A16 Cross Reference of IEs with Messages Ref. 5.2.2.21 5.2.2.37 5.2.2.34 IEI 14H 24H 21H Used in These Messages A16-Session Transfer Request A16-Session Transfer Request A16-Session Transfer Request Ref. 5.1.2.1 5.1.2.1 5.1.2.1
2 3
5.2.2.3
A16 Message Type
The A16 Message Type IE is used to indicate the type of message on the A16 interface. A16 Message Name A16-Session Transfer Request A16-Session Transfer Response A16-Session Transfer Complete A16-Session Release Indication A16-Session Release Indication Ack A16-Session Transfer Abort A16-Session Transfer Abort Ack A16-Session Transfer Reject A16-FL Signal Tunnel A16-FL Signal Tunnel Ack A16-RL Signal Tunnel A16-RL Signal Tunnel Ack A16-Attributes Update A16-Attributes Update Ack A16 Message Type 01H 02H 03H 04H 05H 06H 07H 08H 09H 0AH 0BH 0CH 0DH 0EH Section Reference 5.1.2.1 5.1.2.2 5.1.2.3 5.1.2.4 5.1.2.5 5.1.2.6 5.1.2.7 5.1.2.8 5.1.2.9 5.1.2.10 5.1.2.11 5.1.2.12 5.1.2.13 5.1.2.14
5 6
5.2.2.4
This IE is used to provide the ATs Mobile Node Identification (MN ID). 7 6 5 4 Length Identity Digit 1 Identity Digit 3 Odd/even Indicator Type of Identity Identity Digit 2 3 2 1 0 Octet 1 2 3 4
Identity Digit N+1
Identity Digit N Identity Digit N+2
n n+1
7 8
Length
3GPP2 A.S0008-C v2.0

1 2
Type of Identity Table 5.2.2.4-1 Binary Values 000 110 Odd/Even Indicator (octet 3; bit 3) Identity Digits (octet 3 etc.)
This field is defined as follows: Mobile Identity - Type of Identity Coding Mobile Identity Meaning No Identity Code IMSI All other values are reserved. This field is set to 0 for an even number of digits and to 1 for an odd number of identity digits. The IMSI Identity Digit 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.
3 4 5 6 7
8 9 10 11
5.2.2.5
Access Network Identifiers
This IE uniquely identifies the PCF and 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. 5.2.2.5 Access Network Identifiers 7 6 5 4 3 2 1 0 Octet 1 2 3 SID (LSB) (MSB) PZID NID (LSB) 4 5 6 7 8 A16 Element Identifier = [02H] Type = 01H Length Reserve d (MSB)
12 13 14 15 16 17 18 19 20
Type Length SID NID PZID
This field identifies the ANID Sub Type (01H). This field contains the number of octets in this IE following this field as a binary number. This two octet field is coded to a value that uniquely identifies the cellular or PCS system. This two octet field is coded to a value that uniquely identifies the network within a cellular or PCS system. This one octet field is coded to a value that uniquely identifies the PCF coverage Area within a particular SID/NID area. The combined SID/NID/PZID triplet is unique to a PCF. Encapsulated Message
21 22 23
5.2.2.6
This IE is set to the air-interface message to be transmitted to the AT or the received message from the AT.
5-136
3GPP2 A.S0008-C v2.0 5.2.2.6 Encapsulated Message 7 6 5 4 Length (MSB) Protocol Type and Subtype (LSB) (MSB) Encapsulated Message 3 2 1 0 Octet 1 2 3 4 5 6 A16 Element Identifier = [09H]
(LSB)
1 2 3 4 5 6
Length Protocol Type and Subtype Encapsulated Message 5.2.2.7
This field contains the number of octets in this IE following this field as a binary number. This field contains the Protocol Type and Subtype as specified in [10] of the encapsulated message. This field is set to an air-interface message as specified in [10] received from the AT.
7 8
Source PDSN Address
This IE is used to provide the PDSN address to which the source PCF is connected. 5.2.2.7 Source PDSN Address 7 6 5 4 Length (MSB) PDSN IP Address 3 2 1 0 Octet 1 2 3 4 5 (LSB) 6 A16 Element Identifier = [06H]
9 10 11
Length
This field contains the number of octets in this IE following this field as a binary number. If the PDSN IP Address is not available, the length field shall be set to 00H. This field is set to the IPv4 address of the A11 interface of a PDSN.
12
PDSN IP Address 5.2.2.8
13 14 15
Session Transfer Information
This IE carries the information from the target AN to the source AN associated with the session transfer request. 5.2.2.8 Session Transfer Information 7 6 5 4 Length 5-137 3 2 1 0 Octet 1 2 A16 Element Identifier = [0AH]
3GPP2 A.S0008-C v2.0 5.2.2.8 Session Transfer Information 7 6 5 4 Reserved 3 2 1 0 SLP Reset Required Octet 3
1 2
Length SLP Reset Required 5.2.2.9
This field contains the number of octets in this IE following this field as a binary number. This field is set to 1 if the target AN cannot accept SLP states from the source AN. This field is set to 0 otherwise.
3 4
5 6
Session Transfer Abort Cause
This IE carries the cause that the session transfer is aborted. 5.2.2.9 Session Transfer Abort Cause 7 6 5 4 Length (MSB) Abort Cause Value (LSB) 3 2 1 0 Octet 1 2 3 A16 Element Identifier = [0BH]
7 8
Length Abort Cause Value
This field contains the number of octets in this IE following this field as a binary number. This field is set to indicate the reason that the session transfer is aborted:
10
Hex Values 00 01 02 03
Cause Value Meaning No reason specified Timeout Connection Release AT lost All other values are reserved
11 12 13
5.2.2.10
This IE is used to send HRPD Session Information for one [protocol type, protocol subtype] pair for the main HRPD personality (i.e., the personality with Personality Index = 0) as specified in [10]. If the ATs HRPD session does not support personalities, then this IE is used to send HRPD Session Information for one [protocol type, protocol subtype] pair of the HRPD session as specified in [10]. 5.2.2.10 7 (MSB) 6 5 4 Length (LSB) 5-138 Session State Information Record 3 2 1 0 Octet 1 2 3
14 15
3GPP2 A.S0008-C v2.0 5.2.2.10 7 (MSB) 6 5 4 Session State Information Record 3 2 1 0 Octet 4
(LSB)
1 2
Length Session State Information Record
This field contains the number of octets in this IE following this field as a binary number. This field contains the air interface protocol attributes and associated public data for one [protocol type, protocol subtype] pair. The format is as specified in [10].
3 4 5
6 7 8
5.2.2.11
Proposed Session State Information Record
This IE is used to send HRPD proposed Session Information for one [Protocol Type, Protocol Subtype] pair as specified in [10] between the source AN and the target AN. 5.2.2.11 7 (MSB) (MSB) 6 5 Proposed Session State Information Record 4 3 Length (LSB) Proposed Session State Information Record (SSIR) 2 1 0 Octet 1 2 3 4 A16 Element Identifier = [04H]
(LSB)
9 10
Length Proposed SSIR
This field contains the number of octets in this IE following this field as a binary number. This field contains the proposed air interface protocol attributes and associated public data for one [Protocol Type, Protocol Subtype] pair. The format is identical to the Session State Information Record as specified in [10].
11 12 13
14 15 16 17
5.2.2.12
Extended Session State Information Record
This IE is used to send HRPD Session Information for one [protocol type, protocol subtype] pair for HRPD personalities that are not the main personality as specified in [10] between the source AN and the target AN. 5.2.2.12 7 (MSB) Reserved (MSB) 6 5 Extended Session State Information Record 4 3 Length (LSB) Personality Index Session State Information Record 5-139 2 1 0 Octet 1 2 3 4 5 A16 Element Identifier = [05H]
3GPP2 A.S0008-C v2.0 5.2.2.12 7 6 5 Extended Session State Information Record 4 3 2 1 0 (LSB)
1 2 3 4 5 6 7
Octet
Length Personality Index Session State Information Record
This field contains the number of octets in this IE following this field as a binary number. This field indicates the HRPD personality applicable to the Session State Information Record. This field contains the air interface protocol attributes and associated public data for one [protocol type, protocol subtype] pair. The format is specified in [10].
8 9 10
5.2.2.13
AT-ID
This IE is used to identify the AT session in the A16 interface. 5.2.2.13 7 6 5 4 Length Reserved AT identifier ATI Type 3 AT-ID 2 1 0 Octet 1 2 3 variable
11 12 13
Length ATI Type Binary Values 0000 0001 0010 0011 0100 (all others)
This field contains the number of octets in this IE following this field as a binary number. Access Terminal identifier types associated with the AT are as follows. ATI Type Meaning Reserved (for Broadcast ATI (BATI)) Reserved (for Multicast ATI (MATI)) Unicast ATI 32 (UATI 32) Reserved (for Random ATI (RATI)) Reserved (for Unicast ATI 128 (UATI128)) (reserved) AT identifier Length (bits) N/A N/A 32 N/A N/A
14 15
For UATI32 (Type 0010), the AT identifier field is encoded as follows. 7 (MSB) (MSB) 6 5 4 3 UATI024 (LSB) 5-140 2 1 0 (LSB) Octet 4 5 6 7
UATIColorCode
3GPP2 A.S0008-C v2.0

1
UATIColorCode UATI024 5.2.2.14
This field contains the UATIColorCode for the AT. Refer to [10]. This field contains the UATI024 for the AT. Refer to [10].
3 4 5
ConfirmedUATI
This IE is used to identify the last confirmed UATI which the AT has accessed the AN. 5.2.2.14 7 6 5 4 Length (MSB) ConfirmedUATI ConfirmedUATI 3 2 1 0 Octet 1 2 3 4
A16 Element Identifier = [0DH]
(LSB)
6
18
7 8
Length ConfirmedUATI 5.2.2.15
This field contains the number of octets in this IE following this field as a binary number. This field shall be set to the last UATI which the AT has accessed the AN.
10 11 12 13
AssignedUATI
This IE is used to identify the last UATI that the AN has assigned to the AT but has not received confirmation that the AT has received it. 5.2.2.15 7 6 5 4 Length (MSB) AssignedUATI AssignedUATI 3 2 1 0 Octet 1 2 3 4
A16 Element Identifier = [0EH]
(LSB)
14 15
18
Length
This field contains the number of octets in this IE following this field as a binary number. This field shall be set to the last UATI that the AN has assigned to the AT but has not received confirmation that the AT has received it.
16 17
AssignedUATI 5.2.2.16
18 19 20 21
LCM_UATI
This IE is used to identify the last UATI that the Reverse Traffic Channel Long Code Mask (refer to [10]) is built upon.
5-141
3GPP2 A.S0008-C v2.0 5.2.2.16 7 6 5 4 Length (MSB) LCM_UATI LCM_UATI 3 2 1 0 Octet 1 2 3 4
A16 Element Identifier = [0FH]
(LSB)
1
18
2 3
Length
This field contains the number of octets in this IE following this field as a binary number. This field shall be set to the UATI value that is used to build the Reverse Traffic Channel Long Code Mask.
4 5
LCM_UATI 5.2.2.17
6 7 8
SLP-D Parameters
This IE is used to identify parameters for the SLP-D protocol (refer to [10], [20]) at the AN. 5.2.2.17 7 6 5 4 Length Reserved (MSB) SLPD_VS (MSB) NumXmitted (MSB) (MSB) Time2Rexmit SPLD_SequenceNumber SLPD_PayloadLength SLPD_Payload (LSB) RxVector SLPD_OutstandingCount (LSB) SLPD_VN (LSB) SLP-D Parameters 3 2 1 0 Octet 1 2 3 4 5 1 2 3 4 5
If (SLPD_OutstandingCount > 0) { SLPD_OutstandingCount
(LSB) } (SLPD_OutstandingCount > 0)

9 10 11 12 13
Length SLPD_VN RxVector
This field contains the number of octets in this IE following this field as a binary number. This field shall be set to the current value of V(N) in the SLP-D protocol. The ith bit of this field should be set to Rx[i] parameter of SLP-D receiver. The MSB is the bit i=7 and the LSB is the bit i=0.
5-142
3GPP2 A.S0008-C v2.0

1 2 3 4 5 6 7 8 9 10 11 12 13 14
SLPD_OutstandingCount
This field shall be set to the number of SLP-D packets that either have not been sent to the AT yet, or have been sent fewer than NSLPAttempt number of times, but have not received an acknowledgement. This field shall be set to the current value of V(S) in the SLP-D protocol. This field shall be set to the time elapsed since the last transmission of the SLP-D packet. The unit of this field is 2 ms. This field shall be set to the SLP-D SequenceNumber associated with the outstanding SLP-D packet. This field shall be set to the number of times that this SLP-D packet has been transmitted. The sender shall set this field to zero to indicate that the corresponding SLP-D packet has not been sent to the AT. This field shall be set to the length of the outstanding SLP-D packet (i.e., the next field). This field shall be set to the payload of the outstanding SLP-D packet.
SLPD_VS Time2Rexmit SLPD_SequenceNumber NumXmitted
SLPD_PayloadLength SLPD_Payload 5.2.2.18 SLP-F Parameters
15 16 17
This IE is used to identify parameters for the SLP-F protocol (refer to [10], [20]) at the AN. 5.2.2.18 7 6 5 4 Length Reserved SLPF_ Sync SLPF_VS LastSequenceNumber SLPF_BufferLength SLPF_Buffer (LSB) SLP-F Parameters 3 2 1 0 Octet 1 2 3 4 3 1 2
Reserved (MSB) (MSB) SLPF_Buffer { SLPF_BufferLength
(LSB) } SLPF_Buffer
18 19
Length
This field contains the number of octets in this IE following this field as a binary number. This field shall be set to the current value of V(S) in the SLP-F protocol. This field shall be set to the current value of the Sync variable associated with the SLP-F protocol.
20
SLPF_VS SLPF_Sync
21 22
23 24
LastSequenceNumber This field shall be set to the SequenceNumber of the last SLP-F packet whose payload was written to the re-assembly buffer. SLPF_BufferLength This field shall be set to the length of the SLP-F re-assembly buffer in octets. 5-143
25
3GPP2 A.S0008-C v2.0

1 2
SLPF_Buffer
This field shall be set to the SLP-F re-assembly buffer.
3 4
5.2.2.19
Forward QoS Information
This IE provides mappings of forward IP flow(s) to service connection. 5.2.2.19 Forward QoS Information 7 6 5 4 Length Forward QoS Information Entry 1 Forward QoS Information Entry 2 3 2 1 0 Octet 1 2 variable variable A16 Element Identifier = [12H]

5 6 7 8 9 10
variable
Length Forward QoS Information Entry
This field contains the number of octets in this IE following this field as a binary number. Each Forward QoS Information Entry specifies all of the forward IP flow(s) that are associated with a given service connection. Each entry is coded as follows. Forward QoS Information Entry 4 SR_ID Reserved Forward Flow Count Forward Flow Entry 1 Forward Flow Entry 2 3 2 1 0 Octet j j+1 j+2 variable variable Entry Length
5.2.2.19 7 6 5

11 12 13 14 15 16 17 18 19 20
variable
Entry Length SR_ID Forward Flow Count Forward Flow Entry i
This field contains the number of octets in this entry following the Entry Length field as a binary number. This field identifies the service connection. This field indicates the number of Forward Flow Entry fields contained in this Forward QoS Information Entry. This set of fields contains the forward flow ID(s) associated with the service connection identified by the SR_ID field. Each Forward Flow Entry is coded as follows. 5.2.2.19 Forward Flow Entry 3 2 1 0 Octet k
Entry Length 5-144
3GPP2 A.S0008-C v2.0 5.2.2.19 7 6 5 4 Forward Flow Entry 3 2 1 0 Octet k+1
Forward Flow ID i
1 2 3 4 5
Entry Length Forward Flow ID i 5.2.2.20 Reverse QoS Information
This field contains the number of octets in this entry following the Entry Length field as a binary number. This field contains the flow ID of a given forward IP flow. Refer to [8] for detailed information.
6 7
This IE provides mappings of reverse IP flow(s) to service connection. 5.2.2.20 Reverse QoS Information 7 6 5 4 Length Reverse QoS Information Entry 1 Reverse QoS Information Entry 2 3 2 1 0 Octet 1 2 variable variable A16 Element Identifier = [13H]

8 9 10 11 12 13
variable
Length Reverse QoS Information Entry
This field contains the number of octets in this IE following this field as a binary number. Each Reverse QoS Information Entry specifies all of the reverse IP flow(s) that are associated with a given service connection. Each entry is coded as follows. Reverse QoS Information Entry 4 SR_ID Reserved Reverse Flow Count Reverse Flow Entry 1 Reverse Flow Entry 2 3 2 1 0 Octet j j+1 j+2 variable variable Entry Length
5.2.2.20 7 6 5

14 15 16 17 18 19
variable
Entry Length SR_ID Reverse Flow Count
This field contains the number of octets in this entry following the Entry Length field as a binary number. This field identifies the service connection. This field indicates the number of Reverse Flow Entry fields contained in this Reverse QoS Information Entry.
5-145
3GPP2 A.S0008-C v2.0

1 2 3 4
Reverse Flow Entry i
This set of fields contains the reverse flow ID(s) associated with the service connection identified by the SR_ID field. Each Reverse Flow Entry is coded as follows. 5.2.2.20 Reverse Flow Entry 3 2 1 0 Octet k k+1

5 6 7 8 9 10
This field contains the number of octets in this entry following the Entry Length field as a binary number. This field contains the flow ID of a given reverse IP flow. Refer to [8] for detailed information.
11 12
5.2.2.21
This IE is used to provide Subscriber QoS Profile. 5.2.2.21 Subscriber QoS Profile 7 6 5 4 Length Subscriber QoS Profile 3 2 1 0 Octet 1 2 variable A16 Element Identifier = [14H]
13 14 15 16 17
Length Subscriber QoS Profile 5.2.2.22
This field contains the number of octets in this IE following this field as a binary number. This field contains Subscriber QoS Profile formatted as RADIUS attributes. Refer to [8] for detailed information.
18 19 20
Forward QoS Update Information
This IE is used to convey the PDSN updated QoS to use for a given personality when the PDSN updated the QoS for one or more forward IP Flows. 5.2.2.22 Forward QoS Update Information 7 6 5 4 Length Reserved Forward Flow Count Forward Flow Entry { Forward Flow Count : Forward Flow ID Forward Updated QoS Sub-BLOB Length (MSB) Forward Updated QoS Sub-BLOB 5-146 i+1 i+2 i+3 Personality Index 3 2 1 0 Octet 1 2 3 4 A16 Element Identifier = [15H]
3GPP2 A.S0008-C v2.0 5.2.2.22 7 6 5 4 Forward QoS Update Information 3 2 1 0 (LSB) } Forward Flow Entry
1 2 3 4 5 6 7 8 9 10 11 12 13
Octet j
Length Personality Index Forward Flow Count Forward Flow ID
This field contains the number of octets in this IE following this field as a binary number. This field identifies the applicable HRPD personality for the information contained in this IE. Refer to [10]. This field indicates the number of Flow ID Entry contained in this IE. This field contains the flow ID of a given forward IP flow. Refer to [8] for detailed information. This field contains the number of octets in the Forward Updated QoS Sub-BLOB field as a binary number.
Forward Updated QoS Sub-BLOB Length
Forward Updated QoS Sub-BLOB 5.2.2.23
14 15 16
Reverse QoS Update Information
This IE is used to convey the PDSN updated QoS to use for a given personality when the PDSN updated the QoS for one or more reverse IP Flows. 5.2.2.23 7 6 5 4 Length Reserved Reverse Flow Count Reverse Flow Entry { Reverse Flow Count : Reverse Flow ID Reverse Updated QoS Sub-BLOB Length (MSB) Reverse Updated QoS Sub-BLOB (LSB) } Reverse Flow Entry Personality Index Reverse QoS Update Information 3 2 1 0 Octet 1 2 3 4 j+1 j+2 j+3 k
17 18 19 20 21 22 23 24
Length Personality Index Reverse Flow Count Reverse Flow ID
This field contains the number of octets in this IE following this field as a binary number. This field identifies the applicable HRPD personality for the information contained in this IE. Refer to [10]. This field indicates the number of Flow ID Entry contained in this IE. This field contains the flow ID of a given reverse IP flow. Refer to [8] for detailed information. 5-147
3GPP2 A.S0008-C v2.0

1 2 3 4
Reverse Updated QoS Sub-BLOB Length This field contains the number of octets in the Reverse Updated QoS Sub-BLOB field as a binary number. Reverse Updated QoS Sub-BLOB 5.2.2.24 This field contains the Updated QoS Sub-BLOB for this flow. Refer to [8] for detailed information.
5 6
Session Transfer Reject Cause
This IE carries the cause that the target AN rejects the session transfer request from the source AN. 5.2.2.24 7 6 5 4 Length (MSB) Cause Value (LSB) Session Transfer Reject Cause 3 2 1 0 Octet 1 2 3
7 8
Length Cause Value
This field contains the number of octets in this IE following this field as a binary number. This field is set to indicate the reason that the session transfer is rejected.
10
Hex Values 00H 01H
Cause Value Meaning No reason specified. The target AN cannot support some Session State Information Records and/or Extended Session State Information Records. Insufficient radio resources in the target AN to support the session. Insufficient network resources in the target AN to support the session. Equipment failure. Make before break is not supported. All other values are reserved
02H 03H 04H 05H
11 12 13
5.2.2.25
Correlation ID
This IE is set to the correlation identifier associated with the AT. 5.2.2.25 7 6 5 4 Length (MSB) Correlation Value Correlation ID 3 2 1 0 Octet 1 2 3 4 5 (LSB) 5-148 6
3GPP2 A.S0008-C v2.0

1 2 3 4 5
This field contains the number of octets in this IE following this field as a binary number. This field contains a value that allows an entity to correlate a request-response pair of messages. The value is a manufacturer concern.
6 7
5.2.2.26
Session Transfer Complete Parameters
This IE carries the information necessary for make-before-break HRPD session transfer. 5.2.2.26 7 6 5 Session Transfer Complete Parameters 4 Length (MSB) (MSB) Timestamp (LSB) Sequence Number (LSB) 3 2 1 0 Octet 1 2 3 4 5
8 9
Length Timestamp
This field contains the number of octets in this IE following this field as a binary number. This field contains a 16 bit binary number that identifies the first slot of the last signaling message that the source AN has processed from the AT. This is equal to System Time in units of a slot. This field shall be set to the sequence number of the last A16-FL Signal Tunnel message that the source AN has processed. This field shall be set to zero if the source AN has not processed any A16-FL Signal Tunnel messages.
10 11 12
13 14 15
Sequence Number
16 17
5.2.2.27
Sequence Number
This IE carries the sequence number for the encapsulated message exchange between ANs. 5.2.2.27 7 6 5 4 Length (MSB) Sequence Number (LSB) Sequence Number 3 2 1 0 Octet 1 2 3
18 19 20 21 22 23 24 25 26 27 28
Length Sequence Number
This field contains the number of octets in this IE following this field as a binary number. For A16-FL Signal Tunnel and A16-RL Signal Tunnel messages, this field shall be set to the sequence number associated with the AT signaling message encapsulated along with this element. The sequence number in A16-FL Signal Tunnel message is used by the source AN to inform the target AN of the last forward-link signaling message that the source AN has transmitted on behalf of the target AN. For A16-FL Signal Tunnel Ack and A16-RL Signal Tunnel Ack messages, this field shall be set to the sequence number of the message to which this IE responds. 5-149
3GPP2 A.S0008-C v2.0

1 2 3
5.2.2.28
Fixed Rate Mode
This IE is used to identify parameters in the Fixed Rate State of the Forward Traffic Channel MAC [10]. 5.2.2.28 7 6 5 4 Length Pilot PN (low part) Pilot PN (high part) (MSB) Reserved Fixed Rate Mode 3 2 1 0 Octet 1 2 3 4
Channel (LSB)
5 6 7 8 9 (LSB) 10
(MSB) (MSB)
DRC Value EndTime
(LSB)
4 5 6 7 8
Length Pilot PN
This field contains the number of octets in this IE following this field as a binary number. This field contains the PilotPN of a sector (as specified in [10]) in the Active Set from which the AT wants to receive packets on the Forward Traffic Channel. This field is a 9 bit binary number. This field contains the Channel of a sector (as specified in [10]) in the Active Set from which the AT wants to receive packets on the Forward Traffic Channel. This field is a 24 bit binary number. The field shall be set to the DRCValue associated with the rate at which the AT wants to receive packets on the Forward Traffic Channel. The field shall be set to the least significant 16 bits of the system time in units of slots until which (inclusive) the AT requests to remain in the Fixed Rate State. Serving Sector Information
9 10 11
Channel
12 13
DRC Value
14 15
EndTime 5.2.2.29
16 17 18
This IE is used to identify the current serving sector in the Active Set. 5.2.2.29 7 6 5 4 Length Pilot PN (low part) Serving Sector Information 3 2 1 0 Octet 1 2 3
5-150
3GPP2 A.S0008-C v2.0 5.2.2.29 7 Pilot PN (high part) (MSB) 6 5 4 Serving Sector Information 3 Reserved 2 1 0 Octet 4
Channel (LSB)
5 6 7
1 2 3 4
Length Pilot PN Channel 5.2.2.30
This field contains the number of octets in this IE following this field as a binary number. This field contains the PilotPN of a sector as specified in [10]. This field is a 9 bit binary number. This field contains the Channel of a sector as specified in [10]. This field is a 24 bit binary number. FL Signal Tunnel Parameter
5 6
7 8
This IE carries the parameter necessary for A16-FL Signal Tunnel message. 5.2.2.30 7 6 5 4 Length Reserved Reliable Flag FL Signal Tunnel Parameter 3 2 1 0 Octet 1 2 3
9 10 11 12 13 14
Length Reliable Flag
This field contains the number of octets in this IE following this field as a binary number. If this field is set to 1, then the encapsulated message in the A16-FL Signal Tunnel message is transmitted reliably. Otherwise, the message is transmitted using best-effort service.
15 16
5.2.2.31
Sector Endpoint Information
This IE carries the IP address and UDP port associated with a sector. 5.2.2.31 7 6 5 4 Length Pilot PN (low part) Pilot PN (high part) Reserved Sector Endpoint Information 3 2 1 0 Octet 1 2 3 4
5-151
3GPP2 A.S0008-C v2.0 5.2.2.31 7 (MSB) 6 5 4 Sector Endpoint Information 3 Channel (LSB) (MSB) (MSB) UDP Port (LSB) IPv4 Address 2 1 0 Octet 5 6 7 8 9 10 11 12 (LSB)
1 2 3 4 5 6 7 8 9
13
Length Pilot PN Channel UDP Port IPv4 Address
This field contains the number of octets in this IE following this field as a binary number. This field contains the Pilot PN of a sector as specified in [10]. This field is a 9 bit binary number. This field contains the Channel of a sector as specified in [10]. This field is a 24 bit binary number. This field contains the UDP port number as determined by the AN. This field contains the IPv4 address as determined by the AN.
10 11 12 13
5.2.2.32
SLP Reset Message SEQ Info
This IE is set to the latest MessageSequence info in the SLP Reset Message provided by the source AN before the A16-Session Transfer Complete message is sent. 5.2.2.32 7 6 5 4 Length (MSB) SLP Reset Message SEQ Info (LSB) SLP Reset Message SEQ Info 3 2 1 0 Octet 1 2 3
14 15 16 17 18 19 20
Length
This field contains the number of octets in this IE following this field as a binary number. This field contains the current MessageSequence value for the SLP Reset Message in the source AN when the A16-Session Transfer Complete message is sent to the target AN.
SLP Reset Message SEQ Info
21 22
5.2.2.33
Assigning SC IP Address
This IE is used to provide the IP address of the AN that assigned LCM_UATI.
5-152
3GPP2 A.S0008-C v2.0 5.2.2.33 7 6 5 4 Length (MSB) Assigning SC IP Address Assigning SC IP Address 3 2 1 0 Octet 1 2 3 4 5 (LSB)
1 2 3
Length Assigning SC IP Address 5.2.2.34 Timers
This field contains the number of octets in this IE following this field as a binary number. This field is set to the IPv4 address of an AN that assigned LCM_UATI.
4 5
This IE is used to provide timer information. 5.2.2.34 7 6 5 4 Length Timer 1 Timer 2 3
Timers 2 1 0 Octet 1 2 variable variable
Timer N
6 7 8
variable
Length Timer 7 6
This field contains the number of octets in this IE following this field as a binary number. This field contains timer information and is coded as follows. 5 4 3 2 1 0 Octet 1 2 variable
Timer Type Timer Length Timer Value

9 10
When the Timer Type is set to 01H (Tsclose), the Timer Value field is coded as follows. 7 6 5 4 3 2 1 0 Octet Timer Type = [01H] Timer Length = [05H] (MSB) Starting Time 1 2 3 4 5 6 5-153
3GPP2 A.S0008-C v2.0 7 6 5 4 3 2 1 0 (LSB)

1 2 3 4 5 6 7
Octet 7 8
Timer Type Timer Length Starting Time
This field indicates the type of timer information. This field shall be set to 01H (Tsclose). This field contains the number of octets for the fields representing sector. This field shall be set to 05H. This field shall be set to the CDMA system time at which the AN started the timer Tsclose-13, in units of 80 ms.
8 9 10
5.2.2.35
RTD Information
This IE is set to the round trip delay for the ATs reference pilot. 5.2.2.35 7 6 5 4 Length Reference Pilot PN (low part) Refere nce Pilot PN (high part) Reserved RTD Information 3 2 1 0 Octet 1 2 3 4
Round Trip Delay

11 12 13 14 15 16 17
Length Reference Pilot PN Round Trip Delay
This field contains the number of octets in this IE following this field as a binary number. This field is set to the ATs time reference (the reference pilot), relative to the zero offset pilot PN sequence in units of 64 PN chips. Refer to [10]. This field contains the round trip delay from the AT to the sector associated with the Reference Pilot PN in units of 4 PN chips.
18 19 20
5.2.2.36
Serving Sector ID
The AN shall set this field to the identifier of the serving sector for the AT. 5.2.2.36 7 6 5 4 Length Serving Sector ID 3 2 1 0 Octet 1 2
5-154
3GPP2 A.S0008-C v2.0 5.2.2.36 7 6 5 4 Reserved Serving Sector ID 3 2 1 0 Sector ID Same as OTA Octet 3
(MSB)
Serving Sector ID
4 5
(LSB)
1 2 3 4 5 6 7 8 9 10 11
19
Length Sector ID Same as OTA
This field contains the number of octets in this IE following this field as a binary number. This field is set to 1 if the value in the Serving Sector ID field is the same as the over-the-air SectorID corresponding to the serving sector. This field is set to 0 if the value in the Serving Sector ID field was assigned by other means
Serving Sector ID
This field is set to the 128-bit identifier of the serving sector. If Sector ID Same as OTA= 1, then the value is coded per [10]. If Sector ID Same as OTA = 0, then the value is assigned by other means and should be unique within the serving system.
12 13 14
5.2.2.37
Target Sector ID
The AN shall set this field to the identifier of the target sector for the AT. 5.2.2.37 7 6 5 4 Length Reserved Sector ID Same as OTA Target Sector ID 3 2 1 0 Octet 1 2 3
(MSB)
Target Sector ID
4 5
(LSB)
15 16 17 18 19 20 21 22
19
Length Sector ID Same as OTA
This field contains the number of octets in this IE following this field as a binary number. This field is set to 1 if the value in the Target Sector ID field is the same as the over-the-air SectorID corresponding to the target sector. This field is set to 0 if the value in the Target Sector ID field was assigned by other means.
Target Sector ID
This field is set to the 128-bit identifier of the target sector. If Sector ID Same as OTA= 1, then the value is coded per [10]. If Sector ID Same as OTA = 0, 5-155
3GPP2 A.S0008-C v2.0

1 2 3
then the value is assigned by other means and should be unique within the target system.
5.2.3 5.2.3.1
A17, A18, and A19 Information Element Definitions A17, A18 and A19 Information Element Identifiers
5 6 7 8 9 10
The following table lists all the IEs that make up the messages defined in section 5.1.3, 5.1.4, and 5.1.5. The table includes the Information Element Identifier (IEI) coding which distinguishes one IE from another. The table also includes a section reference indicating where the IE coding can be found. Note: The A17, A18 and A19 interfaces share a common set of IEIs and are identified by the first interface listed, A17. Element Name Current Session State Information Record Proposed Session State Information Record Alternative Session State Information Record Sector Information Correlation ID AT Acquired Flag RTCH Power Control Setpoint Deallocation Timer Power Ramp-Up Bias Queue ID Information FTCH Packet Served Status AT Acquisition Status CC Packet Control Information Air-Interface Signaling Header RL Application Layer Packet FL Application Layer Packet RTCH Packet Control Information Last Packet ID Served Rapid Commit CRC Pass Fail AN A17 IPv4 Address Neighbor Information Leg Number AT-ID AN Leg Information Leg-Sector Association RT Leg Information Requested Sector Information Identifier (Hex) 02H 03H 04H 08H 0BH 0CH 0DH 0EH 0FH 10H 11H 12H 13H 14H 15H 16H 18H 19H 1AH 1BH 1CH 1DH 1FH 21H 22H 23H 24H 25H 5-156 Interfaces A17 A17 A17 A17 A17 A17 A17 A17 A17 A17 A17 A17 A17 A17 A17 A17 A17 A17 A17 A17 A17 A17 A17 A17 A17 A17 A17 A17 Reference 5.2.3.5 5.2.3.6 5.2.3.7 5.2.3.8 5.2.3.9 5.2.3.10 5.2.3.11 5.2.3.12 5.2.3.13 5.2.3.14 5.2.3.15 5.2.3.16 5.2.3.17 5.2.3.18 5.2.3.19 5.2.3.20 5.2.3.21 5.2.3.22 5.2.3.23 5.2.3.24 5.2.3.25 5.2.3.26 5.2.3.27 5.2.3.4 5.2.3.28 5.2.3.29 5.2.3.30 5.2.3.31
3GPP2 A.S0008-C v2.0 Element Name A17 Cause

1 2 3
Identifier (Hex) 26H
Interfaces A17
Reference 5.2.3.32
5.2.3.2
A17, A18, and A19 Cross Reference of IEs with Messages
The following table provides a cross reference between the IEs and the messages defined in this specification. Table 5.2.3.2-1 Information Element A17 Cause A17, A18, and A19 Cross Reference of IEs with Messages Ref. 5.2.3.32 IEI 26H Used in These Messages A17-Modify Response A17 Target Modify Response A17-Target Deallocate Request Alternative Session State Information Record AN A17 IPv4 Address AN Leg Information AT-ID 5.2.3.7 5.2.3.25 5.2.3.28 5.2.3.4 04H A17-Set Attributes Ref. 5.1.3.6 5.1.3.8 5.1.3.11 5.1.3.3 5.1.3.14 5.1.3.1 5.1.3.17 5.1.3.1 5.1.3.2 5.1.3.3 5.1.3.4 5.1.3.5 5.1.3.6 5.1.3.7 5.1.3.8 5.1.3.9 5.1.3.10 5.1.3.11 5.1.3.12 5.1.3.13 5.1.3.17 5.1.3.18 5.1.3.19 5.1.3.20 5.1.4.1 5.1.4.2 5.1.5.1 5.1.5.2
1CH A17-Neighbor Information Request 22H 21H A17-Allocate Request A17-Slave Attach Request A17-Allocate Request A17-Allocate Response A17-Set Attributes A17-Set Attributes Ack A17-Modify Request A17-Modify Response A17-Target Modify Request A17 Target Modify Response A17-Deallocate Request A17-Deallocate Ack A17-Target Deallocate Request A17-Target Deallocate Ack A17-CC Packet A17-Slave Attach Request A17-Slave Attach Response A17-Slave Detach Request A17-Slave Detach Ack A18-FTCH Packet A18-RTCH Packet A19-Acquisition Status A19-Acquisition Status Ack 5-157
3GPP2 A.S0008-C v2.0 Table 5.2.3.2-1 Information Element A17, A18, and A19 Cross Reference of IEs with Messages Ref. IEI Used in These Messages A19-Serving RT Changed A19-Serving RT Changed Ack A19-Forward Desired A19-Forward Desired Ack A19-Forward Stopped A19-Forward Stopped Ack A19-Flush A19-Flush Ack A19-Purge A19-Purge Ack AT Acquired Flag AT Acquisition Status CC Packet Control Information Correlation ID 5.2.3.10 5.2.3.16 5.2.3.17 5.2.3.9 0CH A17-Set Attributes 12H 13H A19-Acquisition Status A17-CC Packet A17-Allocate Response A17-Set Attributes A17-Set Attributes Ack A17-Modify Request A17-Modify Response A17-Target Modify Request A17 Target Modify Response A17-Deallocate Request A17-Deallocate Ack A17-Target Deallocate Request A17-Target Deallocate Ack A17-Neighbor Information Request Ref. 5.1.5.3 5.1.5.4 5.1.5.5 5.1.5.6 5.1.5.7 5.1.5.8 5.1.5.9 5.1.5.10 5.1.5.11 5.1.5.12 5.1.3.3 5.1.5.1 5.1.3.13 5.1.3.1 5.1.3.2 5.1.3.3 5.1.3.4 5.1.3.5 5.1.3.6 5.1.3.7 5.1.3.8 5.1.3.9 5.1.3.10 5.1.3.11 5.1.3.12 5.1.3.14
0BH A17-Allocate Request
A17-Neighbor Information Notification 5.1.3.15 A17-Neighbor Information Notification 5.1.3.16 Ack A17-Slave Attach Request A17-Slave Attach Response A17-Slave Detach Request A17-Slave Detach Ack A18-FTCH Packet A18-RTCH Packet 5-158 5.1.3.17 5.1.3.18 5.1.3.19 5.1.3.20 5.1.4.1 5.1.4.2
3GPP2 A.S0008-C v2.0 Table 5.2.3.2-1 Information Element A17, A18, and A19 Cross Reference of IEs with Messages Ref. IEI Used in These Messages A19-Acquisition Status A19-Acquisition Status Ack A19-Serving RT Changed A19-Serving RT Changed Ack A19-Forward Desired A19-Forward Desired Ack A19-Forward Stopped A19-Forward Stopped Ack A19-Flush A19-Flush Ack A19-Purge A19-Purge Ack CRC Pass Fail Current Session State Information Record Deallocation Timer FL Application Layer Packet 5.2.3.24 5.2.3.5 1BH A18-RTCH Packet 02H A17-Allocate Request A17-Set Attributes 5.2.3.12 5.2.3.20 0EH A17-Deallocate Request 16H A17-CC Packet A18-FTCH Packet A18-RTCH Packet FTCH Packet Served Status Last Packet ID Served Leg Number 5.2.3.15 5.2.3.22 5.2.3.27 11H 19H 1FH A19-Serving RT Changed A19-Forward Stopped A19-Purge A17-Deallocate Request A17-Target Deallocate Request A17-CC Packet A17-Slave Detach Request A18-FTCH Packet A18-RTCH Packet A19-Acquisition Status A19-Acquisition Status Ack A19-Serving RT Changed A19-Serving RT Changed Ack A19-Forward Desired Ref. 5.1.5.1 5.1.5.2 5.1.5.3 5.1.5.4 5.1.5.5 5.1.5.6 5.1.5.7 5.1.5.8 5.1.5.9 5.1.5.10 5.1.5.11 5.1.5.12 5.1.4.2 5.1.3.1 5.1.3.3 5.1.3.9 5.1.3.13 5.1.4.1 5.1.4.2 5.1.5.3 5.1.5.7 5.1.5.11 5.1.3.9 5.1.3.11 5.1.3.13 5.1.3.19 5.1.4.1 5.1.4.2 5.1.5.1 5.1.5.2 5.1.5.3 5.1.5.4 5.1.5.5
5-159
3GPP2 A.S0008-C v2.0 Table 5.2.3.2-1 Information Element A17, A18, and A19 Cross Reference of IEs with Messages Ref. IEI Used in These Messages A19-Forward Desired Ack A19-Forward Stopped A19-Forward Stopped Ack A19-Flush A19-Flush Ack A19-Purge A19-Purge Ack Leg-Sector Association Message Type III 5.2.3.29 5.2.3.3 23H A17-Allocate Request A17-Slave Attach Request none A17-Allocate Request A17-Allocate Response A17-Set Attributes A17-Set Attributes Ack A17-Modify Request A17-Modify Response A17-Target Modify Request A17 Target Modify Response A17-Deallocate Request A17-Deallocate Ack A17-Target Deallocate Request A17-Target Deallocate Ack A17-CC Packet A17-Neighbor Information Request Ref. 5.1.5.6 5.1.5.7 5.1.5.8 5.1.5.9 5.1.5.10 5.1.5.11 5.1.5.12 5.1.3.1 5.1.3.17 5.1.3.1 5.1.3.2 5.1.3.3 5.1.3.4 5.1.3.5 5.1.3.6 5.1.3.7 5.1.3.8 5.1.3.9 5.1.3.10 5.1.3.11 5.1.3.12 5.1.3.13 5.1.3.14
A17-Neighbor Information Notification 5.1.3.15 A17-Neighbor Information Notification 5.1.3.16 Ack A17-Slave Attach Request A17-Slave Attach Response A17-Slave Detach Request A17-Slave Detach Ack A18-FTCH Packet A18-RTCH Packet A19-Acquisition Status A19-Acquisition Status Ack 5-160 5.1.3.17 5.1.3.18 5.1.3.19 5.1.3.20 5.1.4.1 5.1.4.2 5.1.5.1 5.1.5.2
3GPP2 A.S0008-C v2.0 Table 5.2.3.2-1 Information Element A17, A18, and A19 Cross Reference of IEs with Messages Ref. IEI Used in These Messages A19-Serving RT Changed A19-Serving RT Changed Ack A19-Forward Desired A19-Forward Desired Ack A19-Forward Stopped A19-Forward Stopped Ack A19-Flush A19-Flush Ack A19-Purge A19-Purge Ack Neighbor Information Power Ramp-Up Bias Proposed Session State Information Record 5.2.3.26 5.2.3.13 5.2.3.6 0FH 03H A17-Set Attributes A17-Allocate Request A17-Allocate Response A17-Modify Request A17-Modify Response A17-Target Modify Request A17 Target Modify Response Queue ID Information 5.2.3.14 10H A19-Serving RT Changed A19-Forward Stopped A19-Flush A19-Purge Rapid Commit Requested Sector Information RT Leg Information RTCH Packet Control Information RTCH Power Control Setpoint Sector Information
1
Ref. 5.1.5.3 5.1.5.4 5.1.5.5 5.1.5.6 5.1.5.7 5.1.5.8 5.1.5.9 5.1.5.10 5.1.5.11 5.1.5.12 5.1.3.3 5.1.3.1 5.1.3.2 5.1.3.5 5.1.3.6 5.1.3.7 5.1.3.8 5.1.5.3 5.1.5.7 5.1.5.9 5.1.5.11 5.1.3.5 5.1.3.14 5.1.3.2 5.1.3.18 5.1.4.2 5.1.3.3 5.1.5.3
1DH A17-Neighbor Information Notification 5.1.3.15
5.2.3.23 5.2.3.31 5.2.3.30 5.2.3.21 5.2.3.11 5.2.3.8
1AH A17-Modify Request 25H 24H 18H 08H A17-Neighbor Information Request A17-Allocate Response A17-Slave Attach Response A18-RTCH Packet A19-Serving RT Changed 0DH A17-Set Attributes
2 3
5.2.3.3
Message Type III
The Message Type III IE is used to indicate the type of message on the A17, A18, and A19 interfaces.
5-161
3GPP2 A.S0008-C v2.0 Message Name A17-Allocate Request A17-Allocate Response A17-Set Attributes A17-Set Attributes Ack A17-Modify Request A17-Modify Response A17-Target Modify Request A17-Target Modify Response A17-Deallocate Request A17-Deallocate Ack A17-Target Deallocate Request A17-Target Deallocate Ack A17-CC Packet A18-FTCH Packet A18-RTCH Packet A19-Acquisition Status A19-Acquisition Status Ack A19-Serving RT Changed A19-Serving RT Changed Ack A19-Forward Desired A19-Forward Desired Ack A19-Forward Stopped A19-Forward Stopped Ack A19-Flush A19-Flush Ack A19-Purge A19-Purge Ack A17-Neighbor Information Request A17-Neighbor Information Notification A17-Neighbor Information Notification Ack A17-Slave Attach Request A17-Slave Attach Response A17-Slave Detach Request A17-Slave Detach Ack
1 2 3 4
Message Type III Value 01H 02H 03H 04H 05H 06H 07H 08H 09H 0AH 0BH 0CH 0DH 10H 11H 12H 13H 14H 15H 16H 17H 18H 19H 1AH 1BH 1CH 1DH 1EH 1FH 20H 21H 22H 23H 24H
Interface A17 A17 A17 A17 A17 A17 A17 A17 A17 A17 A17 A17 A17 A18 A18 A19 A19 A19 A19 A19 A19 A19 A19 A19 A19 A19 A19 A17 A17 A17 A17 A17 A17 A17
Reference 5.1.3.1 5.1.3.2 5.1.3.3 5.1.3.4 5.1.3.5 5.1.3.6 5.1.3.7 5.1.3.8 5.1.3.9 5.1.3.10 5.1.3.11 5.1.3.12 5.1.3.13 5.1.4.1 5.1.4.2 5.1.5.1 5.1.5.2 5.1.5.3 5.1.5.4 5.1.5.5 5.1.5.6 5.1.5.7 5.1.5.8 5.1.5.9 5.1.5.10 5.1.5.11 5.1.5.12 5.1.3.14 5.1.3.15 5.1.3.16 5.1.3.17 5.1.3.18 5.1.3.19 5.1.3.20
5.2.3.4
AT-ID
This IE is used to identify a specific AT session address in support of soft/softer handoff for a specific AT. This IE, when present in a message, shall immediately follow the Message Type field of that message.
5-162
3GPP2 A.S0008-C v2.0 5.2.3.4 AT-ID 7 6 5 4 Length Reserved AT identifier

1 2 3
Octet 1 2
A17 Element Identifier = [21H] ATI Type
3 variable
Length ATI Type
This field contains the number of octets in this IE following this field as a binary number. Access Terminal identifier types associated with the AT are as follows. ATI Type Meaning Reserved (for Broadcast ATI (BATI)) Reserved (for Multicast ATI (MATI)) Unicast ATI 32 (UATI 32) Reserved (for Random ATI (RATI)) Reserved (for Unicast ATI 128 (UATI128)) (reserved) AT identifier Length (bits) N/A N/A 32 N/A N/A
Binary Values 0000 0001 0010 0011 0100 (all others)

4 5
For UATI32 (Type 0010), the AT identifier field is encoded as follows. 7 (MSB) (MSB) 6 5 4 3 UATI024 (LSB) 2 1 0 (LSB) Octet 4 5 6 7
UATIColorCode
UATIColorCode UATI024 5.2.3.5
This field contains the UATIColorCode for the AT. Refer to [10].
This field contains the UATI024 for the AT. Refer to [10]. Current Session State Information Record
8 9 10
This IE is used to send HRPD Session Information for one [Protocol Type, Protocol Subtype] pair as specified in [10] between the source AN and target AN. 5.2.3.5 Current Session State Information Record 7 (MSB) (MSB) 6 5 4 3 Length (LSB) Session State Information Record (SSIR) 2 1 0 Octet 1 2 3 4 A17 Element Identifier = [02H]
5-163
3GPP2 A.S0008-C v2.0 5.2.3.5 Current Session State Information Record 7 6 5 4 3 2 1 0 (LSB)
1 2 3 4 5 6
Octet n
Length SSIR
This field contains the number of octets in this IE following this field as a binary number. This field contains the air interface protocol attributes and associated public data for one [Protocol Type, Protocol Subtype] pair for the current personality. If the SSIR for the current personality includes hard link to the main personality, this IE shall include the Session State Information Record of the main personality instead of including hard link. The format is as specified in [10]. Proposed Session State Information Record
7 8 9
5.2.3.6
This IE is used to send HRPD proposed Session Information 64 for one [Protocol Type, Protocol Subtype] pair as specified in [10] between the source AN and target AN. 5.2.3.6 Proposed Session State Information Record 7 (MSB) (MSB) 6 5 4 3 Length (LSB) Proposed Session State Information Record (SSIR) 2 1 0 Octet 1 2 3 4 A17 Element Identifier = [03H]
(LSB)
10 11 12 13 14 15 16
Length Proposed SSIR
This field contains the number of octets in this IE following this field as a binary number. This field contains the proposed air interface protocol attributes and associated public data for one [Protocol Type, Protocol Subtype] pair. The format is as specified in [10]. The Proposed Session State Information Record need not include all attributes/parameter records defined by the [Protocol Type, Protocol Subtype] pair.
17 18 19
5.2.3.7
Alternative Session State Information Record
This IE is used to send HRPD alterative Session Information 65 for one [Protocol Type, Protocol Subtype] pair as specified in [10] between the source AN and target AN.
64 When the Proposed Session State Information Record is included in an A17-Allocate Request message and Default RouteUpdate protocol [10] is in use, it contains the RouteUpdate Parameter Record [10] with fields that need to be filled in by the target AN (either MACIndex field or MACIndexLSB and MACIndexMSB fields [10] as appropriate in an A17Allocate Response message). When the Proposed Session State Information Records are included in an A17-Modify Request or A17-Target Modify Request, they comprise attributes/parameter records that the source AN or target AN are proposing for an ATs session with no fields that need to be filled in by either AN. The Proposed Session State Information Record need not include all attributes/parameter records defined by the [Protocol Type, Protocol Subtype] pair. 65 If Default RouteUpdate protocol [10] is in use, the Alternative Session State Information Records are included in an A17Set Attributes message containing old and new session attributes/parameter records because the DRCLength parameter [10] being used by an AT is not known until the traffic channels are updated.
5-164
3GPP2 A.S0008-C v2.0 5.2.3.7 Alternative Session State Information Record 7 (MSB) (MSB) 6 5 4 3 Length (LSB) Alternative Session State Information Record (SSIR) 2 1 0 Octet 1 2 3 4 A17 Element Identifier = [04H]
(LSB)
1 2 3 4 5
Length Alternative SSIR
This field contains the number of octets in this IE following this field as a binary number. This field contains the alternative air interface protocol attributes and associated public data for one [Protocol Type, Protocol Subtype] pair. The format is as specified in [10].
6 7
5.2.3.8
Sector Information 5.2.3.8 Sector Information
This IE contains the Pilot PN and Channel of a sector as specified in [10]. 7 6 5 4 Length (MSB) (MSB) Pilot PN (LSB) Channel (LSB) 3 2 1 0 Octet 1 2 3 4 5 6 7
A17/A18/A19 Element Identifier = [08H]
8 9 10 11 12
Length Pilot PN Channel 5.2.3.9
This field contains the number of octets in this IE following this field as a binary number. This field contains the Pilot PN of a sector as specified in[10]. This field is a 9 bit binary number. This field contains the Channel of a sector as specified in[10]. This field is a 24 bit binary number. Correlation ID
13 14
This IE is used to correlate request and response messages. 5.2.3.9 Correlation ID 7 6 5 4 Length (MSB) Correlation Value 3 2 1 0 Octet 1 2 3 4 5 5-165 A17 Element Identifier = [0BH]
3GPP2 A.S0008-C v2.0 5.2.3.9 Correlation ID 7 Length Correlation Value 6 5 4 3 2 1 0 (LSB)

1 2 3 4 5
Octet 6
This field contains the number of octets in this IE following this field as a binary number. This field contains a 4 bytes binary number that is used to correlate request and response messages.
6 7 8
5.2.3.10
AT Acquired Flag
This IE is used to indicate to the target RTs that the ATs reverse traffic channel has been acquired by the AN. 5.2.3.10 7 6 5 4 Length AT Acquired Flag 3 2 1 0 Octet 1 2
9 10
Length 5.2.3.11
This field contains the number of octets in this IE following this field as a binary number. This field shall be set to 00H. RTCH Power Control Setpoint 5.2.3.11 RTCH Power Control Setpoint 4 Length 3 2 1 0 Octet 1 2 3
11 12
This IE is used to indicate the reverse traffic channel power control setpoint to be used by target RTs. 7 6 5
A17 Element Identifier = [0DH] Reserved

13 14 15 16 17 18
RTCH Power Control Setpoint
Length RTCH Power Control Setpoint
This field contains the number of octets in this IE following this field as a binary number. The target RTs use this to power control the AT via power control decisions sent on the forward link so that the received pilot Eo/Nt matches this value [10]. This field is set to the range of values as follows (with a step size of 0.125 dB): Hex Values 00 01 02 03 04 RTCH Power Control Setpoint Meaning -12.125 dB -12.250 dB -12.375 dB -12.500 dB -12.625 dB
7E
-27.875 dB 5-166
3GPP2 A.S0008-C v2.0 Hex Values 7F

1 2
RTCH Power Control Setpoint Meaning -28.000 dB
5.2.3.12
Deallocation Timer 5.2.3.12 Deallocation Timer 3 Length 2 1 0 Octet 1 2 3 (LSB) 4
This IE is used to indicate when resources at a target RT shall be deallocated. 7 6 5 4
A17 Element Identifier = [0EH] (MSB) Deallocation Timer
3 4 5 6 7 8
Length Deallocation Timer
This field contains the number of octets in this IE following this field as a binary number. This field contains a 16 bit binary number that indicates the amount of time that shall elapse after an RT receives an A17-Set Attributes message instructing it to deallocate resources for a specific AT before it can actually deallocate the resources 66. This is in units of milliseconds.
9 10 11
5.2.3.13
Power Ramp-Up Bias
This IE is used to indicate a reverse power control command upward bias 67 to be used by target RTs in the ATs Active Set for reverse power control during AT connection setup. 5.2.3.13 7 6 5 4 Length Power Ramp-Up Bias Power Ramp-Up Bias 3 2 1 0 Octet 1 2 3
12 13 14 15 16
Length Power Ramp-Up Bias
This field contains the number of octets in this IE following this field as a binary number. This field indicates the reverse power control command upward bias probability to be used by RTs in the ATs Active Set during AT connection setup. This field is set to the range of values as follows (with a step size of 0.025): Hex Values 00 01 Power Ramp-Up Bias Meaning 0.000 0.025
66
For example, if Deallocation Timer = x milliseconds, then each RT belonging to the target AN that is part of the ATs Active Set whose resources are being deallocated is required to set the ForwardTrafficValid field associated with the ATs MACIndex to zero for x milliseconds via the QuickConfig message as defined in [10].
67 For example, this helps the target RTs achieve a certain power ramp-up bias during connection setup by having them send power up and down commands pseudo-randomly with a bias towards the up command, where the power up and down commands are sent on the Reverse Power Control Channel (RPC) as defined in [10].
5-167
3GPP2 A.S0008-C v2.0 Hex Values 02 03 04 Power Ramp-Up Bias Meaning 0.050 0.075 0.100
27 28 All other values

1 2
0.975 1.000 Reserved
5.2.3.14
Queue ID Information 5.2.3.14 Queue ID Information 4 Length Stream ID 3 2 1 0 Octet 1 2 3 4
This IE contains queue identity information regarding forward traffic channel packets. 7 6 5
Route
3 4 5 6
Substream ID
Length Stream ID
This field contains the number of octets in this IE following this field as a binary number. This field is set to the range of values as follows:
Hex Values 00 68 01 69 10 11
7 8
Stream ID Meaning Stream 0 Stream 1 Stream 2 Stream 3
Route
For the Enhanced Multi-Flow Packet Application RLP as defined in [20], this field indicates which route the target RT is to use as follows:
68
If the Stream ID field equals 00, then the Substream ID field is set to 00H and ignored by the target RT. The Stream ID field contains information that is used by the target RT to construct the header of the Stream Layer packet as defined in [10] when contained in an A18-FTCH Packet message or is used to identify a specific flow when contained in A19 messages. If the Stream ID field equals 01, 10, or 11 and the Stream is assigned to the Default Packet Application as defined in [10] then the Substream ID field is set to 00H and ignored by the target RT. The Stream ID field is used by the target RT to construct the header of the Stream Layer packet as defined in [10] when contained in an A18-FTCH Packet message or is used to identify a specific flow when contain in A19 messages. If the Stream is assigned to the Multi-Flow Packet Application as defined in [10] or Enhanced Multi-Flow Packet Application as defined in [20], then the Substream ID field contains the RLP Flow identifier or the Link Flow identifier, respectively. The Stream ID field is again used by the target RT as specified above.
69
5-168
3GPP2 A.S0008-C v2.0 Binary Values 0 1

1 2 3
Route Meaning Route A as defined in [20]. Route B as defined in [20].
For the Default Packet Application RLP and Multi-Flow Packet Application RLP as defined in [10] this field is set to 0 and the target RT shall ignore this field. Substream ID This field is set to the range of values as follows: Hex Values 00 01 02 03 Substream ID Meaning Substream 0 Substream 1 Substream 2 Substream 3
FE FF
4 5 6
Substream 254 No substreams
5.2.3.15
FTCH Packet Served Status
This IE is used to indicate the last packet served in a Data Transmission Group by a specific serving RT. This allows the source AN to determine where to begin multicasting packets to all of the RTs. 5.2.3.15 7 6 5 4 Length (MSB) (MSB) Last Served FTCH Packet ID (LSB) Offset (LSB) FTCH Packet Served Status 3 2 1 0 Octet 1 2 3 4 5 6
7 8 9 10 11 12 13 14 15 16
Length Last Served FTCH Packet ID
This field contains the number of octets in this IE following this field as a binary number. This field contains a 16 bit binary number that identifies the last packet in a Data Transmission Group received by the serving RT and transmitted to the AT. This field contains a 16 bit binary number that identifies the number of leading octets from the last served FTCH packet that have already been transmitted by the target RT to the AT. If all of the octets from the last served FTCH packet have already been transmitted by the target RT to the AT, then this field shall be set to 0000H. AT Acquisition Status
Offset
17 18 19
5.2.3.16
This IE is used to indicate if the reverse traffic channel for a specific AT has been acquired by a specific RT.
5-169
3GPP2 A.S0008-C v2.0 5.2.3.16 7 6 5 4 Length Status

1 2
AT Acquisition Status 3 2 1 0 Octet 1 2 3
Length Status
This field contains the number of octets in this IE following this field as a binary number. This field is set to the range of values as follows: Hex Values 01 02 Status Meaning AT acquired AT lost
3 4 5 6
5.2.3.17
CC Packet Control Information
This IE contains information regarding the control channel packet. This IE is used to indicate the message priority of the Common Control (CC) packet, the type of control channel capsule on which the CC packet shall be transmitted, and when to transmit the CC packet. 5.2.3.17 7 6 5 4 Length Message Priority CC Capsule Type System Time for Packet Transmission CC Packet Control Information 3 2 1 0 Octet 1 2 3 4 5
7 8 9 10 11 12 13 14
Length Message Priority
This field contains the number of octets in this IE following this field as a binary number. This field contains the Message Priority as specified in [10]. This field is an 8 bit binary number between 0 and 255 where the lower values indicate higher priorities. This field indicates the type of control channel capsule on which the CC packet shall be transmitted. This field is set to the range of values as follows: Hex Values 01 02 03 04 CC Capsule Type Meaning Asynchronous Next immediate synchronous Synchronous after time T Sub-synchronous after time T
CC Capsule Type
15 16
System Time for Packet Transmission 5.2.3.18
This field indicates the System Time when the CC Packet should be transmitted (not accounting for CC offset) in units of a slot.
17 18
Air-Interface Signaling Header
This IE is used to indicate the SLP-D header information as defined in [10]. 5-170
3GPP2 A.S0008-C v2.0 5.2.3.18 7 6 5 4 Length Reserved Signaling Header (MSB) Air-Interface Signaling Header 3 2 1 0 Octet 1 2 3 4
(LSB)
1 2 3
Length Signaling Header 5.2.3.19
This field contains the number of octets in this IE following this field as a binary number. This field contains the SLP-D header information as specified in [10].
4 5 6
RL Application Layer Packet
This IE contains a reverse link application layer packet that is sent by the target AN to the source AN (in a specific A18 message) after having been received from a specific AT via a reverse traffic channel. 5.2.3.19 7 (MSB) (MSB) 6 5 4 RL Application Layer Packet 3 Length (LSB) Application Layer Payload 2 1 0 Octet 1 2 3 4
(LSB)
7 8 9 10 11 12
Length Application Layer Payload
This field contains the number of octets in this IE following this field as a binary number. This field contains the application layer payload. If the Stream ID field of the Queue ID IE equals 00, this field contains actual signaling information. If the Stream ID field of the Queue ID IE equals 01, 10, or 11, this field contains actual data information 70.
13 14 15 16
5.2.3.20
FL Application Layer Packet
This IE contains a forward link application layer packet that is sent by the source AN to the target AN (in a specific A17 or A18 message) to be transmitted to a specific AT via a forward traffic channel or control channel.
70
For example, if the Stream ID field equals 00, this element contains the upper layer signaling information that the RT will encapsulate in an SLP-D packet as defined in [10]. If the Stream ID field equals 00, 10, or 11 then this element contains either the upper layer data information that the RT will encapsulate in an RLP packet as defined in [20], [10] (e.g., when it is included in the A18-FTCH Packet message) or the MAC Layer packet (when it is included in the A18-RTCH Packet message).
5-171
3GPP2 A.S0008-C v2.0 5.2.3.20 7 (MSB) 6 5 4 FL Application Layer Packet 3 Length (LSB) Stream ID Route Substream ID FTCH Control Information Air-Interface Header (MSB) Application Layer Payload 2 1 0 Octet 1 2 3 4 5 variable variable n
(LSB)
1 2 3
Length Stream ID 00 71 01 72 10 11 Route Binary Values 0 1
This field contains the number of octets in this IE following this field as a binary number. This field is set to the range of values as follows: Binary Values Stream ID Meaning Stream 0 Stream 1 Stream 2 Stream 3 For the Enhanced Multi-Flow Packet Application RLP as defined in [20], this field indicates which route the target RT is to use as follows: Route Meaning Route A as defined in [20]. Route B as defined in [20].
4 5
71
If the Stream ID field equals 00, then the Substream ID field is set to 00H and ignored by the target RT. The Stream ID field contains information that is used by the target RT to construct the header of the Stream Layer packet as defined in [10] when contained in an A18-FTCH Packet message or is used to identify a specific flow when contained in A19 messages. If the Stream ID field equals 01, 10, or 11 and the Stream is assigned to the Default Packet Application as defined in [10] then the Substream ID field is set to 00H and ignored by the target RT. The Stream ID field is used by the target RT to construct the header of the Stream Layer packet as defined in [10] when contained in an A18-FTCH Packet message or is used to identify a specific flow when contain in A19 messages. If the Stream is assigned to the Multi-Flow Packet Application as defined in [10] or Enhanced Multi-Flow Packet Application as defined in [20], then the Substream ID field contains the RLP Flow identifier or the Link Flow identifier, respectively. The Stream ID field is again used by the target RT as specified above.
72
5-172
3GPP2 A.S0008-C v2.0

1 2 3 4
For the Default Packet Application RLP and Multi-Flow Packet Application RLP as defined in [10] this field is set to 0 and the target RT shall ignore this field. Substream ID Hex Values 00 01 02 03 This field is set to the range of values as follows: Substream ID Meaning Substream 0 Substream 1 Substream 2 Substream 3
7F
5 6 7 8 9 10 11 12
Substream 127 This field contains information regarding the forward traffic channel packet. This field is used to indicate the Data Transmission Group and the first packet of a Data Transmission Group for a specific queue at an RT. This allows the RT to infer if packets have not arrived in order from the source AN and to wait for any packets that are delayed. It also allows duplicate packet detection to be performed. This field is included when the Stream ID field includes the value other than 00. This field is coded as follows. FTCH Control Information 4 3 Packet ID (LSB) Data Transmission Group (DTG) Tag (LSB) DTG First Packet ID (LSB) Offset (LSB) 2 1 0 Octet 1 2 3 4 5 6 7 8
FTCH Control Information
5.2.3.20-1 7 (MSB) (MSB) (MSB) (MSB) 6 5
13 14 15 16 17 18 19 20 21 22 23 24 25 26
Packet ID DTG Tag DTG First Packet ID Offset
This field contains a 16 bit binary number that identifies the packet. This field contains a 16 bit binary number that identifies the Data Transmission Group. This field contains a 16 bit binary number that identifies the first packet in a Data Transmission Group. This field contains a 16 bit binary number that identifies the number of leading octets that have already been transmitted by the target RT to the AT. If all of the octets from the forward link packet have already been transmitted by the target RT to the AT, then this field shall be set to 0000H. This field is used to indicate the air-interface header information associated with the Application Layer Payload field. This field is coded based on the value of the stream ID field. If the stream ID field is set to 00, then this field is used to indicate the Air-Interface Signaling Header 5-173
Air-interface Header
3GPP2 A.S0008-C v2.0

1 2
(e.g., SLP-D header information as defined in [10]) and is coded as follows. 5.2.3.20-2 7 6 5 4 Length Reserved Signaling Header (MSB) Air-Interface Signaling Header 3 2 1 0 Octet 1 2 3
(LSB)
3 4 5 6 7 8 9
Length Signaling Header Application Layer Payload
This field contains the number of octets in this Air-Interface Signaling Header field following this field as a binary number. This field contains the SLP-D header information as specified in [10]. If stream ID is set to 01, 10 or 11, then this field is used to indicate the Air-Interface Application Header (e.g., Packet Application header as defined in [20], [10]) and is coded as follows. Air-Interface Application Header 4 Length 3 2 Application Header 1 0 Octet 1 2 3
5.2.3.20-3 7 6 5 (MSB)
Reserved = [00]
(LSB)
10 11 12 13 14 15 16
Length Application Header Application Layer Payload
This field contains the number of octets in this IE following this field as a binary number. This field contains the RLP header information as specified in [20], [10]. This field contains the application layer payload. If the Stream ID field equals 00, this field contains signaling information. If the Stream ID field equals 01, 10, or 11, this field contains data information 73.
17 18 19 20
5.2.3.21
RTCH Packet Control Information
This IE contains information regarding the reverse traffic channel packet. This IE allows the source AN to discard duplicate reverse traffic channel packets received from different RTs when the AT is in soft/softer handoff. It also allows the source AN to assist new RTs that belong to the target AN with the acquisition
73
For example, if the Stream ID field equals 00, this element contains the upper layer signaling information that the RT will encapsulate in an SLP-D packet as defined in [10]. If the Stream ID field equals 00, 10, or 11 then this element contains either the upper layer data information that the RT will encapsulate in an RLP packet as defined in [20], [10] (e.g., when it is included in the A18-FTCH Packet message) or the MAC Layer packet (when it is included in the A18-RTCH Packet message).
5-174
3GPP2 A.S0008-C v2.0

1 2 3 4
of the AT. Also, for Subtype 2 Physical Layer as specified in [10], this IE is used to indicate the subpacket information and interlace number for the packet decoded by the RT and the status of packets in the process of being decoded by the RT on the other two interlaces so that the source AN can determine when to pass the packet to the upper layer 74. 5.2.3.21 7 6 5 RTCH Packet Control Information 4 Length (MSB) Timestamp (LSB) Round Trip Delay Time (RTDT) Estimation Parameter This Interlace Number This Subpacket ID Other Interlace Number Other Interlace Status Flag (MSB) Other Interlace Timestamp (LSB) 3 2 1 0 Octet 1 2 3 4 5 6 7 8 9 10 11
5 6 7 8 9 10 11 12 13 14 15 16
Length Timestamp
This field contains the number of octets in this IE following this field as a binary number. This field contains a 16 bit binary number that identifies the time that the AT transmitted the packet via the reverse traffic channel. This is equal to System Time in units of a slot. This field indicates the round trip delay from the reference pilot to the AT back to the RT. The offset is in units of 4 PN chips. This allows the source AN to assist new RTs that belong to the target AN with the acquisition of the AT. This field is coded the same as the RTDT Estimation Parameter IE. This field indicates the interlace upon which the packet decoded by the RT was received. This field is set to the range of values as follows: Hex Values 00 01 02 This Interlace Number Meaning Interlace 0 Interlace 1 Interlace 2
RTDT Estimation Parameter
This Interlace Number
17 18
This Subpacket ID
This field indicates the sub-packet index upon which the packet was decoded by the RT. This field is set to the range of values as follows:
74 For example, for an ATs RLP flow that is configured to send NAKs [20], [10], the source AN may use this information to determine how long to delay sending an RLP NAK upon detecting a hole in the RLP sequence space. Conversely, an RLP flow configured not to send NAKs may use the information to determine how long to delay sending data to the upper layer protocols upon detecting a hole in the RLP sequence space.
5-175
3GPP2 A.S0008-C v2.0 Hex Values 00 01 02 03

1 2 3 4 5
This Subpacket ID Meaning Sub-packet identifier 0 Sub-packet identifier 1 Sub-packet identifier 2 Sub-packet identifier 3
Other Interlace Number
This field indicates the interlace upon which packets are currently being transmitted by the AT. This field is coded the same as the This Interlace Number field. This field indicates if the status of the interlace is known. The field is set to the range of values as follows: Hex Values 00 Other Interlace Status Flag Meaning RT does not know if the AT is currently in the process of transmitting a packet on this interlace. The Other Interlace Timestamp field is undefined. The RT knows that the AT is currently in the process of transmitting a packet on this interlace and the Other Interlace Timestamp field represents the System Time of the first sub-packet.
Other Interlace Status Flag
01
6 7 8
Other Interlace Timestamp
This field contains a 16 bit binary number that identifies the time that the AT transmitted the packet via the reverse traffic channel. This field is coded the same as the Timestamp field.
9 10 11
5.2.3.22
Last Packet ID Served
This IE is used to indicate the Packet ID and Data Transmission Group of the last FTCH packet served by an RT that was sent to the RT from the AN. 5.2.3.22 7 6 5 4 Length (MSB) (MSB) Data Transmission Group (DTG) Tag (LSB) Packet ID (LSB) Last Packet ID Served 3 2 1 0 Octet 1 2 3 4 5 6
12 13 14
Length DTG Tag Packet ID
This field contains the number of octets in this IE following this field as a binary number. This field contains a 16 bit binary number that identifies the Data Transmission Group. This field contains a 16 bit binary number that identifies the packet
5-176
3GPP2 A.S0008-C v2.0

1 2 3 4
5.2.3.23
Rapid Commit
This IE is used to indicate to the target AN whether or not it should wait until it receives an A17-Set Attributes message containing Session State Information Record IEs before modifying resources (after the target AN has sent an A17-Modify Response message to the source AN). 5.2.3.23 7 6 5 4 Length Reserved Flag Rapid Commit 3 2 1 0 Octet 1 2 3
5 6
Length Flag
This field contains the number of octets in this IE following this field as a binary number. This field is set to the range of values as follows: Binary Values 0 Flag Meaning Target AN shall not wait until receiving A17-Set Attributes message from source AN containing Session State Information Record IEs before modifying resources. Target AN shall wait until receiving A17-Set Attributes message from source AN containing Session State Information Record IEs before modifying resources.
7 8 9
5.2.3.24
CRC Pass Fail
This IE is used to indicates to the source AN whether or not the target RT successfully decoded the ATs air-interface reverse traffic channel packet. 5.2.3.24 7 6 5 4 Length Reserved Flag CRC Pass Fail 3 2 1 0 Octet 1 2 3
10 11
Length Flag
This field contains the number of octets in this IE following this field as a binary number. This field is set to the range of values as follows: Binary Values 0 1 Flag Meaning CRC pass. CRC fail.
12 13 14
5.2.3.25
AN A17 IPv4 Address
This IE is used to identify a specific AN IPv4 address to be used as the destination IP address in an IP packet on the A17 interface.
5-177
3GPP2 A.S0008-C v2.0 5.2.3.25 7 6 5 4 Length (MSB) IPv4 Address AN A17 IPv4 Address 3 2 1 0 Octet 1 2 3 4 5 LSB)
1 2 3 4 5
Length IPv4 Address
This field contains the number of octets in this IE following this field as a binary number. This field contains the IPv4 address to be used by the target AN as the destination IP address in an IP packet that carries an unsolicited A17-Neighbor List Notification messages on the A17 interface.
6 7
5.2.3.26
Neighbor Information 5.2.3.26 Neighbor Information 4 3 Length (LSB) Sector Information Number of Neighbors Neighbor Information Entry #1 Neighbor Information Entry #2 2 1 0 Octet 1 2 3 variable n variable variable
This IE contains a list of neighbor target RTs. 7 (MSB) 6 5
Neighbor Information Entry #n Neighbor Parameter

8 9
variable variable
Length Sector Information
This field contains the number of octets in this IE following this field as a binary number. This field contains sector information for which the source AN requests neighbor information. 5.2.3.26-1 Sector Information 3 2 1 0 Octet 1 2 variable 5 4
10 11
Sector Information Type Sector Information Length Sector Information Value

12 13
When the Sector Information Type is set to 01H (Pilot PN and Channel), the Sector Information field is coded as follows. 5-178
3GPP2 A.S0008-C v2.0 5.2.3.26-2 7 6 5 Sector Information (Pilot PN and Channel) 4 3 2 1 0 Octet 1 2 3 (LSB) (MSB) Channel (LSB)
1 2
Sector Information Type = [01H (Pilot PN and Channel)] Sector Information Length (MSB) Pilot PN
4 5 6 7
Sector Information Type Sector Information Length Pilot PN Channel Number of Neighbors Neighbor Information Entry
This field indicates the type of sector information. This field shall be set to 01H (Pilot PN and Channel). This field contains the number of octets for the fields representing sector. This field shall be set to 05H. This field contains the Pilot PN of a sector as specified in [10] as 9 bit binary number. This field contains the Channel of a sector as specified in [10] as 24 bit binary number. This field contains the number of neighbor target RTs in the neighbor list. This field contains neighbor information of the sector specified by the Sector Information. This field is coded as follows. Neighbor Information Entry 4 3 2 1 0 Octet 1 variable n n+1 n+2 LSB) n+3 n+4 n+5 n+6 (LSB) n+7 n+8 (LSB) n+9 Entry Length Neighbor Sector Information
3 4
5 6
7 8
9 10
11 12
5.2.3.26-3 7 6 5
(MSB)
AN A17 IPv4 Address
(MSB)
AN A16 IPv4 Address
(MSB)
RT Identifier
13 14
Entry Length
This field contains the number of octets in this entry following this field as a binary number. 5-179
3GPP2 A.S0008-C v2.0

1 2
Neighbor Sector Information
This field contains neighbor sector information of the sector specified by the Sector Information. This field is coded as follows. Neighbor Sector Information 4 3 2 1 0 Octet 1 2 variable
5.2.3.26-4 7 6 5

3
4 5
When the Sector Information Type is set to 01H (Pilot PN and Channel), the Neighbor Sector Information field is coded as follows. 5.2.3.26-5 7 6 5 Neighbor Sector Information (Pilot PN and Channel) 4 3 2 1 0 Octet 1 2 3 (LSB) (MSB) Channel (LSB) 4 5 6 7
6 7
Sector Information Type Sector Information Length Pilot PN Channel AN A17 IPv4 Address AN A16 IPv4 Address RT Identifier
This field indicates the type of sector information. This field shall be set to 01H (Pilot PN and Channel). This field contains the number of octets for the fields representing sector. This field shall be set to 05H. This field contains the Pilot PN of a sector as specified in [10]. This field is a 9 bit binary number. This field contains the Channel of a sector as specified in [10]. This field is a 24 bit binary number. This field contains the IPv4 address to be used by the source AN as the destination IP address of the A17 interface at the target AN. This field contains the IPv4 address to be used by the source AN as the destination IP address of the A16 interface at the target AN. This field contains the identification of the RT. This value shall be unique in an AN and it identifies which sectors belong to which RT. This information may be used when the AN sends an A17-Allocate Request message to the target AN. This field contains parameters in TLV format associated with the neighbor sector. This field is coded as follows.
8 9
10 11
12 13
14 15
16 17
18 19 20 21
22 23
Neighbor Parameter
5-180
3GPP2 A.S0008-C v2.0 5.2.3.26-6 7 6 5 4 Neighbor Parameter 3 2 1 0 Octet 1 2 variable
Parameter Type Parameter Length Parameter Value

1 2
When the Parameter Type is set to 01H (Cookie), the Parameter field is coded as follows. 5.2.3.26-7 7 6 5 4 Neighbor Parameter (Cookie) 3 2 1 0 Octet 1 2 3 (LSB) 4
Parameter Type = [01H(Cookie)] Parameter Length (MSB) Cookie
3 4
Parameter Type Parameter Length Cookie
This field represents the type of parameter. This field is set to 01H to represent that this field includes Cookie parameter. This field contains the number of octets in the Neighbor Parameter following this field as a binary number. This field shall be set to 02H. This field contains a 16 bit binary number that uniquely identifies the neighbor information in the AN associated with an RT. This value shall be changed to a unique value per the lifetime of the AN every time the neighbor information associated with the sector has changed.
5 6
7 8 9 10 11
12 13
5.2.3.27
Leg Number 5.2.3.27 Leg Number 3 Length Leg Number 2 1 0 Octet 1 2 3
This IE is used to represent an RT in A17/A18/A19 messages. 7 6 5 4
14 15 16 17 18
Length Leg Number
This field contains the number of octets in this IE following this field as a binary number. This field contains an 8-bit binary number that represents an RT in an AN. In the target AN, both <RT A18 Data Endpoint ID, Leg Number> and <RT A19 Control Endpoint ID, Leg Number> shall be unique. In the source AN, both <AN A18 Data Endpoint ID, Leg Number> and <AN A19 Control Endpoint ID, Leg Number> shall be unique.
19 20
5.2.3.28
AN Leg Information
This IE is used to identify a specific source AN addresses for A18 and A19 endpoints for a leg.
5-181
3GPP2 A.S0008-C v2.0 5.2.3.28 7 6 5 4 Length Leg Number AN A19 Control Endpoint AN A18 Data Endpoint
1 2
AN Leg Information 3 2 1 0 Octet 1 2 3 variable variable
Length Leg Number AN A19 Control Endpoint
This field contains the number of octets in this IE following this field as a binary number. This field contains a value representing one or more sectors in the active set belonging to the same RT. This field contains a specific source AN address on A19 interface in support of soft/softer handoff for a specific AT. The source AN address is used for the transport of signaling between the source AN and the target AN (or more specifically, the target RT). This field is coded as follows. 5.2.3.28-1 AN A19 Control Endpoint 4 3 Endpoint Type 2 1 0 Octet 1
3 4
5 6 7 8 9
7
AT-ID Required Flag
(MSB) (MSB)
UDP Port (LSB) IPv4 Address
2 3 4 5 6 (LSB) 7
10 11
AT-ID Required Flag Endpoint Type UDP Port IPv4 Address AN A18 Data Endpoint
This field indicates whether AT-ID IE shall be included when A19 messages are sent to this endpoint. This field indicates the type of endpoint. This field shall be set to 01H (UDP/IPv4). This field contains the UDP port number as determined by the AN. This field contains the IPv4 address as determined by the AN. This field contains a specific source AN address on A18 interface in support of soft/softer handoff for a specific AT. The source AN address is used for the transport of data between the source AN and the target AN (or more specifically, the target RT). This field is coded as follows.
12 13
14
15
16 17 18 19
5-182
3GPP2 A.S0008-C v2.0 5.2.3.28-2 7

AT-ID Required Flag
AN A18 Data Endpoint 3 Endpoint Type 2 1 0 Octet 1
(MSB) (MSB)
2 3 4 5 6 (LSB) 7
1 2
AT-ID Required Flag Endpoint Type UDP Port IPv4 Address 5.2.3.29
This field indicates whether AT-ID IE shall be included when A18 messages are sent to this endpoint. This field indicates the type of endpoint. This field shall be set to 01H (UDP/IPv4). This field contains the UDP port number as determined by the AN. This field contains the IPv4 address as determined by the AN.
3 4
7 8
Leg-Sector Association 5.2.3.29 Leg-Sector Association 4 Length Leg Number Sector Information Count Sector Information #1 Sector Parameter #1 Sector Information #2 Sector Parameter #2 3 2 1 0 Octet 1 2 3 4 variable variable variable variable
This IE contains sector information associated with the leg and related parameters. 7 6 5
Sector Information #n Sector Parameter #n

9 10
variable variable
Length Leg Number
This field contains the number of octets in this IE following this field as a binary number. This field contains the leg number correlated with sectors represented by Sector Information fields in this IE.
11 12
5-183
3GPP2 A.S0008-C v2.0

1 2
Sector Information Count Sector Information
This field contains the number of occurrences of a pair of Sector Information and Sector Parameter that follow this field. This field contains sector information associated with the leg. This field is coded as follows. 5.2.3.29-1 Sector Information 3 2 1 0 Octet 1 2 variable
3 4 5

6 7
When the Sector Information Type is set to 01H (Pilot PN and Channel), the Sector Information field is coded as follows. 5.2.3.29-2 7 6 5 Sector Information (Pilot PN and Channel) 4 3 2 1 0 Octet 1 2 3 (LSB) (MSB) Channel (LSB) 4 5 6 7
8 9
Sector Information Type Sector Information Length Pilot PN Channel Sector Parameter
This field indicates the type of sector information. This field shall be set to 01H (Pilot PN and Channel). This field contains the number of octets for the fields representing sector. This field shall be set to 05H. This field contains the Pilot PN of a sector as specified in [10] as 9 bit binary number. This field contains the Channel of a sector as specified in [10] as 24 bit binary number. This field contains parameters in TLV format associated with the sector. This field is coded as follows. 5.2.3.29-3 Sector Parameter 3 2 1 0 Octet 1 2 variable 5 4
10 11
12 13
14 15
16 17

18
5-184
3GPP2 A.S0008-C v2.0

1
When the Parameter Type is set to 01H (RTDT Estimation), the Parameter field is coded as follows. 5.2.3.29-4 7 6 5 Sector Parameter (RTDT Estimation) 4 3 2 1 0 Octet 1 2 3
Parameter Type = [01H(RTDT Estimation)] Parameter Length Round Trip Delay Time (RTDT) Estimation Parameter
2 3
Parameter Type Parameter Length RTDT Estimation Parameter
This field represents the type of parameter. This field is set to 01H to represent that this field includes RTDT Estimation parameter. This field contains the number of octets in the Sector Parameter following this field as a binary number. This field shall be set to 01H. This field indicates the round trip delay from the reference pilot to the AT back to the RT. The offset is in units of 4 PN chips. This allows the source AN to assist new RTs that belong to the target AN with the acquisition of the AT. This field is set to the range of values as follows (with a step size of 4 PN chips): Hex Values 00 01 02 03 RTDT Estimation Parameter Meaning 0 PN chips 4 PN chips 8 PN chips 12 PN chips
4 5
6 7 8 9 10
FE FF
11 12
1016 PN chips 1020 PN chips
5.2.3.30
RT Leg Information 5.2.3.30 RT Leg Information 3 Length Leg Number RT A19 Control Endpoint RT A18 Data Endpoint RT Parameter #1 RT Parameter #2 2 1 0 Octet 1 2 3 variable variable variable variable
This IE is used to identify a specific target AN addresses for A18 and A19 endpoints for a leg. 7 6 5 4
RT Parameter #n
13 14
variable
Length
3GPP2 A.S0008-C v2.0

1 2
Leg Number RT A19 Control Endpoint
This field contains a value representing one or more sectors in the active set belonging to the same RT. This field contains a specific target AN address on A19 interface in support of soft/softer handoff for a specific AT. The target AN address is used for the transport of signaling between the source AN and the target AN (or more specifically, the target RT). This field is coded as follows. 5.2.3.30-1 RT A19 Control Endpoint 4 3 Endpoint Type 2 1 0 Octet 1
3 4 5 6
7
AT-ID Required Flag
(MSB) (MSB)
2 3 4 5 6 (LSB) 7
7 8
AT-ID Required Flag Endpoint Type UDP Port IPv4 Address RT A18 Data Endpoint
This field indicates whether AT-ID IE shall be included when A19 messages are sent to this endpoint. This field indicates the type of endpoint. This field shall be set to 01H (UDP/IPv4). This field contains the UDP port number as determined by the AN. This field contains the IPv4 address as determined by the AN. This field contains a specific target AN address on A18 interface in support of soft/softer handoff for a specific AT. The target AN address is used for the transport of data between the source AN and the target AN (or more specifically, the target RT). This field is coded as follows. 5.2.3.30-2 RT A18 Data Endpoint 3 Endpoint Type 2 1 0 Octet 1 5 4
9 10
11
12
13 14 15 16
7
AT-ID Required Flag
(MSB) (MSB)
2 3 4 5 6 (LSB) 7
17 18
AT-ID Required Flag
This field indicates whether AT-ID IE shall be included when A18 messages are sent to this endpoint. 5-186
3GPP2 A.S0008-C v2.0

1 2
Endpoint Type UDP Port IPv4 Address RT Parameter
This field indicates the type of endpoint. This field shall be set to 01H (UDP/IPv4). This field contains the UDP port number as determined by the AN. This field contains the IPv4 address as determined by the AN. This field contains parameters in TLV format associated with the RT. This field is coded as follows. 5.2.3.30-3 RT Parameter 3 2 1 0 Octet 1 2 variable 6 5 4
5 6

7 8
When the Parameter Type is set to 01H (RT Buffer Size), the Parameter field is coded as follows. 5.2.3.30-4 7 6 5 4 RT Parameter (RT Buffer Size) 3 2 1 0 Octet 1 2 3 (LSB) 4
Parameter Type = [01H(RT Buffer Size)] Parameter Length (MSB) Buffer Size
9 10
Parameter Type Parameter Length Buffer Size
This field represents the type of parameter. This field is set to 01H to represent that this field includes RT Buffer Size parameter. This field contains the number of octets in the RT Parameter following field as a binary number. This field shall be set to 02H. This field contains a 16-bit binary number that represents the amount of data (in units of 1024 bits) that an AN can buffer before transmission on the forward traffic channel for an AT.
11 12
13 14 15
16 17
5.2.3.31
Requested Sector Information 5.2.3.31 Requested Sector Information 4 Length Sector Information Parameter Information 3 2 1 0 Octet 1 2 variable variable
This IE contains sector information and related parameters. 7 6 5
18 19
Length
3GPP2 A.S0008-C v2.0

1 2
Sector Information
This field contains sector information for which the AN requests the neighbor information. This field is coded as follows. 5.2.3.31-1 Sector Information 3 2 1 0 Octet 1 2 variable 5 4

3
4 5
When the Sector Information Type is set to 01H (Pilot PN and Channel), the Sector Information field is coded as follows. 5.2.3.31-2 7 6 5 Sector Information (Pilot PN and Channel) 4 3 2 1 0 Octet 1 2 3 (LSB) (MSB) Channel (LSB) 4 5 6 7
6 7
Sector Information Type Sector Information Length Pilot PN Channel Parameter Information
This field indicates the type of sector information. This field shall be set to 01H (Pilot PN and Channel). This field contains the number of octets for the fields representing sector. This field shall be set to 05H. This field contains the Pilot PN of a sector as specified in [10] as 9 bit binary number. This field contains the Channel of a sector as specified in [10] as 24 bit binary number. This field contains parameters in TLV format associated with the neighbor sector. This field is coded as follows. 5.2.3.31-3 Parameter Information 3 2 1 0 Octet 1 2 variable 5 4
8 9
10 11
12 13
14 15

16
5-188
3GPP2 A.S0008-C v2.0

1
When the Parameter Type is set to 01H (Cookie), the Parameter field is coded as follows. 5.2.3.31-4 7 6 5 4 Parameter Information (Cookie) 3 2 1 0 Octet 1 2 3 (LSB) 4
Parameter Type = [01H(Cookie)] Parameter Length (MSB) Cookie
2 3
Parameter Type Parameter Length Cookie
This field represents the type of parameter. This field is set to 01H to represent that this field includes Cookie parameter. This field contains the number of octets in the Neighbor Parameter following this field as a binary number. This field shall be set to 02H. This field contains a 16 bit binary number that uniquely identifies the neighbor information in the AN associated with an RT. This value shall be changed to a unique value per the lifetime of the AN every time the neighbor information associated with the sector has changed.
4 5
6 7 8 9
10 11
5.2.3.32
A17 Cause
This IE carries the cause value indicating the result of the message processing. 5.2.3.32 7 6 5 4 Length (MSB) Cause Value (LSB) 3 A17 Cause 2 1 0 Octet 1 2 3
12 13
Length Cause Value
This field contains the number of octets in this IE following this field as a binary number. This field is set to indicate the result of the message processing.
14
15
Hex Values 00 01 02 03 04 05 06 07
Cause Value Meaning Successful operation Counter proposal Reject No reason specified Reject Radio resource unavailable Reject Network resource unavailable No reason specified Air link lost Equipment failure All other values are reserved
16
5-189
3GPP2 A.S0008-C v2.0

1
5.2.4 5.2.4.1
2 3 4 5 6
The following table lists all the IEs that make up the messages defined in section 5.1.6. The table includes the Information Element Identifier (IEI) coding which distinguishes one IE from another. The table also includes a section reference indicating where the IE coding can be found. Element Name 1x LAC Encapsulated PDU A21 1x Parameters Pilot List Correlation ID Mobile Identity (MN ID) Authentication Challenge Parameter (RAND) A21 1x Message Transmission Control A21 Cause A21 Event Service Option A21 Mobile Subscription Information IEI (Hex) 01H 02H 03H 04H 05H 06H 07H 08H 09H 0AH 0BH Reference 5.2.4.4 5.2.4.5 5.2.4.6 5.2.4.7 5.2.4.8 5.2.4.9 5.2.4.10 5.2.4.11 5.2.4.12 5.2.4.13 5.2.4.14
8 9 10 11
5.2.4.2
The following table provides a cross reference between the IEs and the messages defined in this specification. Table 5.2.4.2-1 Information Element 1x LAC Encapsulated PDU A21 1x Message Transmission Control A21 1x Parameters A21 Cause A21 Event A21 Message Type A21 Cross Reference of IEs with Messages Ref. 5.2.4.4 5.2.4.10 5.2.4.5 5.2.4.11 5.2.4.12 5.2.4.3 IEI 01H 07H 02H 08H 09H Used in These Messages A21-1x Air Interface Signaling A21-1x Air Interface Signaling A21-1x Parameters A21-Ack A21-Service Response A21-Event Notification A21-Ack A21-1x Parameters A21-Event Notification A21-1x Parameters Request A21-Service Request A21-Service Response 5-190 none A21-1x Air Interface Signaling Ref. 5.1.6.1 5.1.6.1 5.1.6.3 5.1.6.2 5.1.6.7 5.1.6.4 5.1.6.1 5.1.6.2 5.1.6.3 5.1.6.4 5.1.6.5 5.1.6.6 5.1.6.7
3GPP2 A.S0008-C v2.0 Table 5.2.4.2-1 Information Element A21 Cross Reference of IEs with Messages Ref. IEI Used in These Messages A21-Radio Update Request A21-Radio Update Response A21 Mobile Subscription Information 5.2.4.14 0BH A21-1x Air Interface Signaling 06H A21-1x Air Interface Signaling A21-1x Parameters Correlation ID 5.2.4.7 04H A21-1x Air Interface Signaling A21-Ack A21-1x Parameters A21-Event Notification A21-1x Parameters Request A21-Service Request A21-Service Response A21-Radio Update Request A21-Radio Update Response Mobile Identity (MN ID) 5.2.4.8 05H A21-1x Air Interface Signaling A21-Ack A21-Event Notification A21-Service Request A21-Service Response A21-Radio Update Request A21-Radio Update Response Pilot List 5.2.4.6 03H A21-1x Air Interface Signaling A21-Radio Update Request A21-Radio Update Response Service Option
1
Ref. 5.1.6.8 5.1.6.9 5.1.6.1 5.1.6.1 5.1.6.3 5.1.6.1 5.1.6.2 5.1.6.3 5.1.6.4 5.1.6.5 5.1.6.6 5.1.6.7 5.1.6.8 5.1.6.9 5.1.6.1 5.1.6.2 5.1.6.4 5.1.6.6 5.1.6.7 5.1.6.8 5.1.6.9 5.1.6.1 5.1.6.8 5.1.6.9 5.1.6.6
Authentication Challenge Parameter 5.2.4.9 (RAND)
5.2.4.13
0AH A21-Service Request
2 3
5.2.4.3
A21 Message Type
The A21 Message Type IE is used to indicate the type of message on the A21 interface. A21 Message Name A21-1x Air Interface Signaling A21-Ack A21-1x Parameters A21-Event Notification A21-1x Parameters Request A21-Service Request 5-191 A21 Message Type 01H 02H 03H 04H 05H 06H Section Reference 5.1.6.1 5.1.6.2 5.1.6.3 5.1.6.4 5.1.6.5 5.1.6.6
3GPP2 A.S0008-C v2.0 A21 Message Name A21-Service Response A21-Radio Update Request A21-Radio Update Response
1
A21 Message Type 07H 08H 09H
Section Reference 5.1.6.7 5.1.6.8 5.1.6.9
2 3
5.2.4.4
1x LAC Encapsulated PDU 5.2.4.4 1x LAC Encapsulated PDU
This IE contains the 1x signaling message to be transported across the A21 interface. 7 6 5 4 Length (MSB) 1x LAC Encapsulated PDU (LSB) 3 2 1 0 Octet 1 2 3 4 n
A21 Element Identifier: = [01H]
4 5 6 7
Length 1x LAC Encapsulated PDU 5.2.4.5 A21 1x Parameters
This field contains the number of octets in this IE following this field as a binary number. This field contains the 1x LAC Encapsulated PDU being carried transparently between the IWS and the HRPD AN.
8 9
This IE contains the 1x overhead parameter values to be sent to the MS/AT via the CSNA protocol. 5.2.4.5 A21 1x Parameters 7 6 5 4 Length (MSB) 3G1X Parameters (LSB) 3 2 1 0 Octet 1 2 3 k A21 Element Identifier: = [02H]
10 11 12 13 14
Length 3G1X Parameters
This field contains the number of octets in this IE following this field as a binary number. This field contains the set of 1x overhead parameter values encoded as specified in [9]. This field shall contain all fields of the 3G1X Parameters message specified in [9] following the 3G1XParametersSignature field.
15 16
5.2.4.6
Pilot List 5.2.4.6 Pilot List
This IE contains pilot measurements sent between the HRPD AN and the IWS. 7 6 5 4 3 2 1 0 Octet 1
Pilot List: A21 Element Identifier = [03H] 5-192
3GPP2 A.S0008-C v2.0 5.2.4.6 Pilot List 7 6 5 4 Length Number of Pilots Pilot Entry { Number of Pilots: Channel Record Length (MSB) Channel Record (LSB) Reserved IF (Cell ID Info = 001, 010, 011, 111),1x Cell Identifier { 1: (MSB) MSCID (LSB) (MSB) } 1x Cell Identifier IF (Cell ID Info = 100, 101, 110), HRPD Sector Identifier { 1: HRPD Sector ID Length (MSB) HRPD Sector ID (LSB) } HRPD Sector Identifier Reference Pilot (MSB) Pilot PN Information (LSB) Reserved Pilot One Way Delay Included (MSB) } Pilot Entry
1 2 3 4 5 6 7 8
Octet 2 3 j j+1 k k+1 k+2 k+3 k+4 k+5 k+6
Cell ID Info
1x Cell Sector (LSB)
k+2 k+3 k+n m m+1 m+2
Pilot Strength
Pilot One Way Delay (LSB)
m+3 m+4
Length Number of Pilots
This field contains the number of octets in this IE following this field as a binary number. This field indicates the number of pilots represented by this IE including the reference pilot. The Channel Record, Cell Identifier, Pilot PN Phase and Pilot Strength are indicated for each pilot. This field contains the numbers of octets in the Channel Record field as a binary number.
Channel Record Length
5-193
3GPP2 A.S0008-C v2.0

1 2 3 4 5
Channel Record
This field contains a channel record as defined in [10]. The information contained in a channel record include the system type, band class, and channel number. field is included for each pilot that is reported. This field is coded as follows: Value 000 001 010 011 100 Meaning A Cell Identifier field is not included for this pilot. The pilot is an actual 1x pilot. A 1x Cell Identifier field is included for this pilot. The pilot is an actual 1x pilot. A 1x Cell Identifier field is included for this pilot. The pilot is an estimated 1x pilot. A 1x Cell Identifier field is included for this pilot. The pilot is an actual HRPD pilot. An HRPD Sector Identifier field is included for this pilot. The pilot is an actual HRPD pilot. Only an HRPD Sector Identifier field is included. Only an actual HRPD pilot is included. Only a 1x Cell Identifier is included. Reserved
Cell ID Info
101 110 111 All other values

6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28
1x Cell Identifier
If the Cell ID Info field indicates that a 1x cell identifier is included, then this record is included, and contains a 1x Cell Identifier of Cell Identifier Discriminator type 07H with the octets coded per Section 4.2.17 [14]; otherwise, this record is not present. If the Cell ID Info field indicates that an HRPD sector identifier is included, then this record is included, and contains an HRPD sector identifier length, and the HRPD sector identifier; otherwise this record is not present. The sector identifier length indicates the number of octets following the sector identifier length field that contain the HRPD sector identifier. The HRPD sector identifier field is coded per [10]. This field indicates whether the following Pilot PN Information field contains the Reference Pilot PN. The reference pilot shall always be an HRPD pilot. If the Reference Pilot field is set to 1, the 9 LSBs of this field contain the Reference Pilot PN [10] and the remaining bits shall be set to 000000. If the Reference Pilot field is set to 0, this field contains the Pilot PN Phase of the pilot [10]. The HRPD AN will report last pilot strength measurement obtained from the Route Update for this Pilot. This field is included for each pilot reported. 5-194
HRPD Sector Identifier
Reference Pilot
Pilot PN Information
Pilot Strength Pilot One Way Delay Included
3GPP2 A.S0008-C v2.0

1 2 3 4 5 6 7
This field shall be set to 1 when including the Pilot One Way Delay. The Pilot One Way Delay shall be included for the following conditions, but is not constrained to only these conditions. Value 0 1 the reported pilot is an HRPD pilot, or the reported pilot is an estimated 1x pilot. Pilot One Way Delay Included Meaning Pilot One Way Delay is not included for this pilot. Pilot One Way Delay is included for this pilot.
8 9
Pilot One Way Delay 5.2.4.7 Correlation ID
This field contains an estimate of the one-way delay from AT to cell site in units of 100 ns.
10 11
This IE contains the value used to correlate messages transported across the A21 interface. 5.2.4.7 Correlation ID 7 6 5 4 Length (MSB) Correlation Value 3 2 1 0 Octet 1 2 3 4 5 (LSB) 6 A21 Element Identifier: = [04H]
12 13 14 15 16 17
This field contains the number of octets in this IE following this field as a binary number. This field contains the value used to correlate messages transported across the A21 interface. The same value included in the A21-1x Air Interface Signaling message shall be included in the corresponding A21-Ack message when the A21Ack message is sent.
18 19
5.2.4.8
This IE is used to provide the ATs Mobile Node Identification (MN ID). 7 6 5 4 Length
Identity Digit 1 Odd/even Indicator Type of Identity
Octet 1 2
3
Identity Digit 3
Identity Digit 2
Identity Digit N+1 5-195
Identity Digit N
3GPP2 A.S0008-C v2.0 5.2.4.8 Mobile Identity (MN ID) 7 6 5 4 3 2 1 0 Octet n+1 Identity Digit N+2
1 2 3 4
Length Type of Identity Table 5.2.4.8-1 Binary Values 000 001 101 110 Odd/Even Indicator (octet 3; bit 3) Identity Digits (octet 3 etc.)
This field contains the number of octets in this IE following this field as a binary number. This field is defined as follows. Mobile Identity - Type of Identity Coding Mobile Identity Meaning No Identity Code MEID ESN IMSI All other values are reserved. This field is set to 0 for an even number of digits and to 1 for an odd number of identity digits. The MEID Identity Digit fields are coded using 14 hexadecimal digits. The Odd/Even Indicator is set to 0 and bits 4 to 7 of the last octet shall be filled with an end mark coded as 1111. The IMSI Identity Digit 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. The ESN is not separated into digits, and occupies octets 4-7 with the most significant bit in octet 4 bit 7. Identity Digit 1 in octet 3 is unused and coded as 0000. Note: ESN may be the true ESN, UIM_ID or the pseudo ESN (derived from the MEID or received in a Status Response Message from the MS).
5 6 7 8 9 10 11 12 13 14 15 16 17 18
19 20
5.2.4.9
Authentication Challenge Parameter (RAND) 5.2.4.9 Authentication Challenge Parameter (RAND)
This IE provides a non-predictable number which is used for authentication. 7 6 5 4 Length Reserved (MSB) Random Number Type RAND Value 3 2 1 0 Octet 1 2 3 4 5 6 (LSB) 7
21 22
Length
This field indicates the number of octets in this element following the Length field. 5-196
3GPP2 A.S0008-C v2.0

1 2
Random Number Type: Table 5.2.4.9-1 Authentication Challenge Parameter - Random Number Type Random Number Type RAND All other values reserved. Random Number Length 32 bits
Random Number Type Value 0001 RAND Value
3 4 5 6
This field contains a non-predictable number that is used for authentication. Bit 7 of the lowest numbered octet is the most significant bit, while bit 0 of the highest numbered octet is the least significant bit.
7 8 9
5.2.4.10
A21 1x Message Transmission Control
This IE contains information about the encapsulated 1x air interface message received from or to be transmitted over 3G1X Circuit Services Notification Application [9]. 5.2.4.10 7 6 5 A21 1x Message Transmission Control 4 Length Reserved Paging Message Simul Xmit with Next AckReq uired 3G1XL ogicalC hannel 3 2 1 0 Octet 1 2 3
A21 Element Identifier: = [07H]
ProtocolRevision
10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32
Length Paging Message
This field contains the number of octets in this IE following this field as a binary number. This field shall be set to 1 if this A21 message contains a 1x paging message; otherwise it shall be set to 0.
Simul Xmit with Next This field shall be set to 1 if this A21 message contains a 1x message that is intended to be transmitted simultaneously with the next 1x message contained in this same A21 message; otherwise it shall be set to 0. AckRequired The HRPD AN shall set this field to be identical to the value of the AckRequired field received in the 3G1XServices message. The IWS shall set this field to the desired value of the AckRequired field in the 3G1XServices message of 3G1X Circuit Services Notification Application that the HRPD AN shall use to transmit the 1x LAC Encapsulated PDU IE. Refer to [9].
3G1XLogicalChannel The HRPD AN shall set this field to be identical to the value of the 3G1XLogicalChannel field received in the 3G1XServices message. The IWS shall set this field to the desired value of the 3G1XLogicalChannel field in the 3G1XServices message of 3G1X Circuit Services Notification Application that the HRPD AN shall use to transmit the 1x LAC Encapsulated PDU IE. Refer to [9]. ProtocolRevision The HRPD AN shall set this field to be identical to the value of the ProtocolRevision field received in the 3G1XServices message. The IWS shall set this field to the desired value of the ProtocolRevision field in the 3G1XServices message of 3G1X Circuit Services Notification Application that the HRPD AN shall use to transmit the 1x LAC Encapsulated PDU IE. Refer to [9]. 5-197
3GPP2 A.S0008-C v2.0

1 2 3
5.2.4.11
A21 Cause
This IE contains the value used to indicate a particular problem with the processing of the A21 message being acknowledged. 5.2.4.11 7 6 5 4 Length (MSB) A21 Cause Value (LSB) 3 A21 Cause 2 1 0 Octet 1 2 3
4 5 6 7
Length A21 Cause Value Value 00H 01H 02H
This field contains the number of octets in this element following this field as a binary number. This field indicates a particular problem with the processing of the A21 message being acknowledged. This field is coded as follows: A21 Cause Value Meaning Unknown mobile Unknown cell identifier(s) Tunneling available of 1x messages not Transmission of 1x n/a LAC Encapsulated PDU disabled (CSNA is not available) n/a Request rejected due to resource shortage HRPD -> 1x MS/AT not during page found n/a 1x -> HRPD Additional Meaning per Direction
03H 04H 05H 06H
Resources not available A21 context for this MS/AT may be released Airlink lost Abort Handoff from HRPD to 1x
Airlink lost before n/a UHDM delivered Handoff abort due to Handoff rejection due to unspecified reason unspecified reason (e.g. Handoffs are administrativelydisabled at 1x) Use if nothing else fits Use if nothing else fits
07H 08H 09H 0AH All other values

8
Unspecified Rejection Already Paging Reserved for backwards compatibility Reserved
9 10
5.2.4.12
A21 Event
This IE contains the value used to indicate the event that has occurred.
5-198
3GPP2 A.S0008-C v2.0 5.2.4.12 7 6 5 4 Length Event (MSB) Additional Event Info 3 A21 Event 2 1 0 Octet 1 2 3 4
(LSB)
1 2 3 4 5
Length Event
This field contains the number of octets in this element following this field as a binary number. This field contains the value used to indicate the event that has occurred. The meaning of the event values are as follows: Table 5.2.4.12-1 Event Values HRPD -> 1x n/a 1x -> HRPD ITHHO has been successfully completed n/a Additional Meaning per Direction
Hex Value 00H
Event Meaning MS/AT present in 1x
01H
MS/AT present Handoff
in
HRPD/Cancel Handoff abort due to unspecified reason (Includes VoIP release before UHDM) n/a
02H
1x Power Down
MS/AT has done a power down while on 1x. The HRPD system can delete any context it may have been saving
03H
HRPD Closed
Power
Down/Connection Handoff aborted due n/a to connection closed. The 1x system can delete any context it may have been saving n/a 1x system rejected HHO (e.g. SO rejected or resources unavailable) n/a n/a n/a n/a
04H
Handoff Rejected
05H 06H 07H 08H
1x Registration Transmission of All 1x Encapsulated PDUs Disabled
n/a LAC n/a
Transmission of 1x LAC Encapsulated n/a PDU(s) Enabled MS/AT no longer present in this n/a AN/PCF 5-199
3GPP2 A.S0008-C v2.0 Hex Value 09H 0AH Event Meaning MS/AT no longer present in this 1x n/a BS MS/AT Not Acquired n/a HRPD -> 1x n/a MS not seen on 1x channel (reverse TCH acquiring unsuccessful) 1x -> HRPD
Additional Meaning per Direction
0BH
Redirection
Inter-AN active n/a handoff occurred. Use the source IP address of the message containing this event value as the new A21 interface IP address.
All other values

1 2 3 4 5
Reserved
Additional Event Info
If the length field contains a value greater than 1, then the remaining octets of this IE shall contain an Additional Event Info field. Refer to Table 5.2.4.12-2. Table 5.2.4.12-2 Hex Value 00H 06H 07H Additional Event Info Values Event Meaning This field shall not be included. This field shall contain the variable length AllowedForwardLinkMessages negotiated by the HRPD AN and the AT. For the coding of AllowedForwardLinkMessages, refer to [9]. This field shall not be included.
All other values

6 7
When the Event field is set to 07H, the Additional Event Info field shall be coded as follows: 7 (MSB) 6 5 4 (LSB) 3 2 1 0 Octet 1 n
AllowedForwardLinkMessages
8 9 10 11 12 13
The ability by the HRPD AN to indicate to the IWS whether transmission of LAC Encapsulated PDUs is enabled/disabled allows the IWS to reduce unnecessary messaging across the A21 interface by not sending 1x LAC Encapsulated PDUs to the HRPD AN that cannot be sent to the MS/AT. Note: Additional fill bits shall be added to the least significant bit positions as needed to complete an integral number of octets.
5-200
3GPP2 A.S0008-C v2.0

1 2 3
5.2.4.13
Service Option
This element contains the value used to indicate to the Service Option for the A21-Service Request. 5.2.4.13 7 6 5 4 Length (MSB) Length Service Option Service Option (LSB) Service Option 3 2 1 0 Octet 1 2 3 4
4 5 6 7 8
This field contains the number of octets in this element following this field as a binary number. This field contains the value used to indicate the service option being requested. The allowed service option values are as follows: Table 5.2.4.13-1 Hex Value 00 3BH 59 xxH Service Option Values Event Meaning HRPD Packet Data HRPD Packet Data with ReservationLabel where xx = [00-FFH] and contains the ReservationLabel
9 10 11 12
5.2.4.14
A21 Mobile Subscription Information
This IE includes mobile subscription information records and may be sent from the AN to the IWS, or the IWS to the AN. 5.2.4.14 7 6 5 A21 Mobile Subscription Information 4 Length Record Identifier - 1 Record Length - 1 (MSB) Record Identifier - 2 Record Length - 2 (MSB) Record Content 2 (LSB) Record Identifier - n 5-201 Record Content - 1 (LSB) 3 2 1 0 Octet 1 2 3 4 5 j j+1 j+2 j+3 k m+1 A21 Element Identifier
3GPP2 A.S0008-C v2.0 5.2.4.14 7 (MSB) 6 5 A21 Mobile Subscription Information 4 3 Record Content - n (LSB)
1 2 3 4 5 6
Octet m+2 m+3 n
Record Length - n
Length Record Identifier
This field contains the number of octets in this element following the Length field. This field identifies the included record type. The field is coded as shown in Table 5.2.4.14-1. Table 5.2.4.14-1 Hex Values 00H Record Identifier Values
Meaning Band Class/Band Subclass Record All other values reserved
7 8 9 10 11 12
Record Length Record Content
This field indicates the number of octets in the immediately following Record Content field. The coding of this field is determined by the Record Identifier field and is coded as follows: Band Class/Band Subclass Record (Record Identifier = 00H) 5 4 3 2 1 0 Octet 5
Table 5.2.4.14-2 7 All Band Classes Included All Band Subclasses Included SC7 SCn SC6 SCn-1 6
Current Band Subclass
Band Class 1 Reserved Band Class 1 Subclass Length
6 7
SC5 SCn-2
SC4 SCn-3
SC3 SCn-4
SC2 SCn-5
SC1 SCn-6
SC0 SCn-7
i j k
Band Class n All Band Subclasses Included SC7 SC6 Reserved Band Class n Subclass Length
k+1
SC5
SC4
SC3
SC2
SC1
SC0
k+2
5-202
3GPP2 A.S0008-C v2.0 Table 5.2.4.14-2 7 SCn

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
Band Class/Band Subclass Record (Record Identifier = 00H) 5 SCn-2 4 SCn-3 3 SCn-4 2 SCn-5 1 SCn-6 0 SCn-7 Octet m
6 SCn-1
All Band Classes Included This field indicates whether the band class values included represents all of the mobiles band class capabilities or just a subset of supported band classes. The field is set to 1 when all of the MS/ATs band class capabilities have been included. Otherwise, the field is set to 0. Current Band Subclass This field specifies the current band subclass in use or the last known band subclass for the MS/AT and is encoded as specified in [21]. The Current Band Subclass field is associated with the current or last known band class specified in the first Band Class field in this record. If band subclasses are not defined for the current band class, this field is set to 0. Band Class This field specifies the band classes supported by the MS/AT and is encoded as specified in [21]. At least one instance of this field shall be included; where, the first instance corresponds to the current band class or last known band class for the mobile. Additional Band Class fields indicate additional band classes supported by the mobile. This field indicates whether all of the mobiles band subclass capabilities are included in this record for the associated band class or just a subset of band subclasses. The field is set to 1 when all of the MS/ATs band subclass capabilities have been included for the associated band class. Otherwise, the field is set to 0. Band Subclass Length This field indicates the number of band subclass octets that follow the SC Length field. This field indicates whether any band subclasses are supported for the previous band class entry field. At least one instance of this field is included. If no band subclasses are supported for the associated band class, this field is set to 0. SCn The SCn fields represent the band subclasses supported by the MS/AT. The SCn field is set to 1 if the associated band subclass (e.g., SC3 = band subclass 3) is supported by the MS/AT. The field is set to 0 if the associated band subclass is not supported by the MS/AT, the subclass capability is unknown or the band subclass is undefined for the corresponding band class.
All Band Subclasses Included
5-203
3GPP2 A.S0008-C v2.0
1 2
5.3
Timer Definitions
This section describes the timers associated with the HRPD IOS specification. Timer Name Default Value (seconds) 1 1 5 1 0.5 1 1.0 1.0 1.0 1.0 1.0 0.1 0.1 0.5 0.5 0.5 0.5 0.5 0.5 1.0 Refer to 5.3.1.22 0.1 0.1 0.1 0.1 1 1 5 1 Range of Values (seconds) 0.1 - 60.0 0.1 - 60.0 0.1 - 60.0 0.1 - 60.0 0.1 - 60.0 0.1 - 60.0 0.1 - 5.0 0.1 - 5.0 0.1 - 5.0 0.1 - 5.0 0.1 - 5.0 0 - 1.0 0 - 1.0 0 - 5.0 0 - 5.0 0 - 5.0 0 - 5.0 0 - 5.0 0 - 5.0 0 - 5.0 0 - 20.0 0 - 1.0 0 - 1.0 0 - 1.0 0 - 1.0 0.1 - 60.0 0.1 - 60.0 0.1 - 60.0 0.1 1.0 Granularity (seconds) 0.1 0.1 0.1 0.1 0.1 0.1 0.1 0.1 0.1 0.1 0.1 0.01 0.01 0.01 0.01 0.01 0.01 0.01 0.01 0.01 0.01 0.01 0.01 0.01 0.01 0.1 0.1 0.1 0.1 Section Reference 5.3.1.1 5.3.1.2 5.3.1.3 5.3.1.4 5.3.1.5 5.3.1.7 5.3.1.8 5.3.1.9 5.3.1.10 5.3.1.11 5.3.1.12 5.3.1.13 5.3.1.14 5.3.1.15 5.3.1.16 5.3.1.17 5.3.1.18 5.3.1.19 5.3.1.20 5.3.1.21 5.3.1.22 5.3.1.23 5.3.1.24 5.3.1.25 5.3.1.26 5.3.1.27 5.3.1.28 5.3.1.29 5.3.1.30 Classification A13 interface A13 interface A9 interface A13 interface A13 interface A13 interface A13 interface A16 interface A16 interface A16 interface A16 interface A16 interface A16 interface A16 interface A17 interface A17 interface A17 interface A17 interface A17 interface A17 interface A17 interface A17 interface A19 interface A19 interface A19 interface A19 interface A21 interface A21 interface A21 interface A21 interface
TA13req TA13res Tnet conn TA13rel Tpreq-13 TSClose-13 TKeepAlive-13 Tstreq-16 Tstcomp-16 Tstack-16 Tstrel-16 Tstabrt-16 Tsigtunnel-16 Tattribupd-16 Tneighbor-17 Tallocreq-17 Tsetattrib-17 Tdeallocreq-17 Ttgtdeallocreq-17 Tmodreq-17 Ttgtmodreq-17 Twaitacq-17 Tacqstatus-19 TservRTch-19 Tflush-19 Tpurge-19 Tack-21 Tparamreq-21 Tpage-21 Tradioreq-21
3
Refer to 5.3.1.6
5-204
3GPP2 A.S0008-C v2.0

1
5.3.1 5.3.1.1
Timer Descriptions Timer TA13req
2 3 4 5
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. 5.3.1.2 Timer TA13res
6 7 8
This AN timer is started when the source AN sends an A13-Session Information Response message to the target AN and is stopped when the A13-Session Information Confirm message is received. 5.3.1.3 Timer Tnet_conn
9 10 11
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. 5.3.1.4 Timer TA13rel
12 13 14
This AN timer is started when the target AN sends an A13-Resource Release Request message to the source AN and is stopped when the A13-Resource Release Response message is received. 5.3.1.5 Timer Tpreq-13
15 16 17 18 19 20 21
This AN timer is started when the source AN sends an A13-Paging Request message to the target AN and is stopped when the A13-Paging Request Ack message is received. This timer is also started when the target AN sends an A13-Paging Delivered message to the source AN and is stopped when the A13Paging Delivered Ack message is received. This timer is also started when the target AN sends an A13-1x Air Interface Signaling message to the source AN and is stopped when the A13-1x Air Interface Signaling Ack message is received. 5.3.1.6 Timer TSClose-13
22 23 24 25 26 27 28
This assigning AN timer is started when the assigning AN completes session transfer while the AT is active and is stopped when the assigning AN receives an A13-Resource Release Request message or when the assigning AN receives session information via A16-Session Transfer Complete message. This assigning AN timer is restarted when it receives an A13-Keep Alive Request message. The assigning AN releases the HRPD session when this timer expires. The timer value should be TSMPClose timer specified in [10]. 5.3.1.7 Timer TKeepAlive-13
29 30 31
This AN timer is started when the serving AN sends an A13-Keep Alive Request message to the AN that assigned LCM_UATI and is stopped when the A13-Keep Alive Response message is received. 5.3.1.8 Timer Tstreq-16
32 33 34 35
The timer is started when the source AN sends an A16-Session Transfer Request message to the target AN and is stopped when the A16-Session Transfer Response, A16-Session Transfer Reject or the A16Session Transfer Abort message is received. 5.3.1.9 Timer Tstcomp-16
36 37 38 39
The timer is started when the target AN sends an A16-Session Transfer Response message to the source AN and is stopped when the A16-Session Transfer Complete message or the A16-Session Transfer Abort message are received.
5-205
3GPP2 A.S0008-C v2.0

1 2 3 4
5.3.1.10
Timer Tstack-16
The timer is started when the source AN sends an A16-Session Transfer Complete message to the target AN and is stopped when the A16-Session Release Indication message, the A16-Session Transfer Response or the A16-Session Transfer Abort message are received. 5.3.1.11 Timer Tstrel-16
5 6 7 8
The timer is started when the target AN sends an A16-Session Release Indication message to the source AN and is stopped when the A16-Session Release Indication Ack message or the A16-Session Transfer Abort message are received. 5.3.1.12 Timer Tstabrt-16
9 10 11 12
The timer is started when an AN sends an A16-Session Transfer Abort message to the other AN and is stopped when the A16-Session Transfer Abort Ack message or the A16-Session Transfer Abort message is received. 5.3.1.13 Timer Tsigtunnel-16
13 14 15 16 17
The timer is started when the slave AN sends an A16-FL Signal Tunnel message to the master AN and is stopped when the A16-FL Signal Tunnel Ack message is received. This timer is also started when the master AN sends an A16-RL Signal Tunnel message to the slave AN and is stopped when the A16-RL Signal Tunnel Ack message is received. 5.3.1.14 Timer Tattribupd-16
18 19 20 21
The timer is started when the master AN sends an A16-Attributes Update message to the slave AN and is stopped when the A16-Attributes Update Ack message is received.
22 23 24 25 26 27
5.3.1.15
Timer Tneighbor-17
This AN timer is started when the source AN sends an A17-Neighbor Information Request message to the target AN and is stopped when the A17-Neighbor Information Notification message is received. Alternatively, this AN timer is started when the target AN sends an unsolicited A17-Neighbor Information Notification message to the source AN and is stopped when the A17-Neighbor Information Notification Ack message is received. 5.3.1.16 Timer Tallocreq-17
28 29 30 31 32
This AN timer is started when the source AN sends an A17-Allocate Request message to the target AN and is stopped when the A17-Allocate Response message is received. Alternatively, this AN timer is started when the slave AN sends an A17-Slave Attach Request message to the master AN and is stopped when the A17-Slave Attach Response message is received. 5.3.1.17 Timer Tsetattrib-17
33 34 35
This AN timer is started when the source AN sends an A17-Set Attributes message to the target AN and is stopped when the A17-Set Attributes Ack message is received. 5.3.1.18 Timer Tdeallocreq-17
36 37 38 39 40
This AN timer is started when the source AN sends an A17-Deallocate Request message to the target AN and is stopped when the A17-Deallocate Ack message is received. Alternatively, this AN timer is started when the slave AN sends an A17-Slave Detach Request message to the master AN and is stopped when the A17-Slave Detach Ack message is received.
5-206
3GPP2 A.S0008-C v2.0

1 2 3
5.3.1.19
Timer Ttgtdeallocreq-17
This AN timer is started when the target AN sends an A17-Target Deallocate Request message to the source AN and is stopped when the A17-Target Deallocate Ack message is received. 5.3.1.20 Timer Tmodreq-17
4 5 6
This AN timer is started when the source AN sends an A17-Modify Request message to the target AN and is stopped when the A17-Modify Response message is received. 5.3.1.21 Timer Ttgtmodreq-17
7 8 9
This AN timer is started when the target AN sends an A17-Target Modify Request message to the source AN and is stopped when the A17-Target Modify Response message is received. 5.3.1.22 Timer Twaitacq-17
10 11 12 13 14
This AN timer is started when the target AN sends an A17-Allocate Response message to the source AN and is stopped when the A17-Set Attribute message is received indicating that the AT is acquired during the AT connection setup procedure. The period of this timer is the air interface timer 75 specified in [10] + 2 seconds. 5.3.1.23 Timer Tacqstatus-19
15 16 17
This AN timer is started when the target AN sends an A19-Acquisition Status message to the source AN and is stopped when the A19-Acquisition Ack message is received. 5.3.1.24 Timer Tservrtch-19
18 19 20 21 22 23 24
This AN timer is started when the target AN sends an A19-Serving RT Changed message to the source AN and is stopped when the A19-Serving RT Changed Ack message is received. This timer is started when the target AN sends an A19-Forward Desired message to the source AN and is stopped when the A19-Forward Desired Ack message is received. This timer is started when the target AN sends an A19Forward Stopped message to the source AN and is stopped when the A19-Forward Stopped Ack message is received. 5.3.1.25 Timer Tflush-19
25 26 27
This timer is started when the source AN sends an A19-Flush message to the target AN and is stopped when the A19-Flush Ack message is received. 5.3.1.26 Timer Tpurge-19
28 29 30
This timer is started when the target AN sends an A19-Purge message to the source AN and is stopped when the A19-Purge Ack message is received. 5.3.1.27 Timer Tack-21
31 32 33 34
This timer is started when the HRPD AN/IWS sends an A21-1x Air Interface Signaling message, an A211x Parameters message, or an A21-Event Notification message to the HRPD AN/IWS and is stopped when the corresponding A21-Ack message is received from the HRPD AN/IWS.
75 When the RTCMAC subtype 3 is configured for the AT, the timer TRTCMPANSetup is used as air interface timer.
5-207
3GPP2 A.S0008-C v2.0

1 2 3
5.3.1.28
Timer Tparamreq-21
This timer is started when the HRPD AN sends an A21-1x Parameters Request message to the IWS and is stopped when the A21-1x Parameters message is received from the IWS. 5.3.1.29 Timer Tpage-21
4 5 6
This timer is started when the HRPD AN sends an A21-Service Request message to the 1x BS and is stopped when the A21-Service Response message is received from the 1x BS. 5.3.1.30 Timer Tradioreq-21
7 8 9 10 11
This IWS timer is started when the IWS sends an A21-Radio Update Request message to the HRPD AN and is stopped when the A21-Radio Update Response message is received.
5-208
3GPP2 A.S0008-C v2.0
1 2 3 4
Annex A
Transport Change Text (Normative)
Note: Annex A, contains specific Transport text from [12] with all HRPD related changes identified through the use of underscores (additions) and strikeouts (deletions). Use of an ellipsis () indicates that the base document is unchanged. All references in the following sections of this annex pertain to [12].
...
2.4.4 Transport Network IP Quality of Service (QoS) Framework To ensure that the transport network provides the necessary performance characteristics, the end nodes and transport network interfaces which require transport QoS shall support the Differentiated Services (DiffServ) framework as specified in [33], with the following clarifications: The A1p/A2p, A3/A7, A8/A9 and A10/A11 network portions of the RAN transport network may be over-provisioned in comparison to the air interface (BS to MS) capacity, and the A1p/A2p, A3/A7, A8/A9 and A10/A11 network traffic loads, or both. In case a RAN transport network is overprovisioned, the QoS framework in this section is not applicable to that transport network. Transport nodes (e.g., interior routers) shall support the following: o o o o o Per packet classification according to the Type of Service (TOS)/Differentiated Services Code Point (DSCP) field in the IPv4 header One or more queuing disciplines to meet the interfaces delay/jitter requirements. Policing disciplines to meet the traffic flow requirements. Per packet marking of a DSCP via the IPv4 TOS octet according to the prescribed DSCP value (refer to section 2.6.2). Four or more traffic classes as defined by the relevant interface. The parameters of each class include mandatory and optional traffic types, service delay, and packet loss rate.
6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24
Edge transport nodes (e.g., border routers) shall support the following: End host nodes (e.g., BS, PCF, PDSNs) shall support the following when required:
25
...
A-1
3GPP2 A.S0008-C v2.0 2.6.1.1 1x SDB/HRPD DoS Indicator If the packet is tagged by the PDSN as being suitable for 1x SDB or HRPD Data Over Signaling (DoS) transmission, it is identified by an attribute defined as follows:
0 E = [0,1] SDI/DoS = 1 1 2 3 4 Type = 000 0001 Length = 02H Reserved Reserved
4 5 6 7
1 2 3
Octet 1 2 3 4
Type Length SDI/DoS
000 0001 Short Data Indication 02H 0 Reserved 1 packet suitable for 1x SDB or HRPD DoS transmission
...
2.6.1.3 IP Flow Discriminator If the BS has specified use of IP flow discrimination for a given forward A8 connection, the PCF shall include this attribute in all GRE frames for the specified forward A8 connection. If the PCF has specified use of IP flow discrimination for a given forward A10 connection, the PDSN shall include this attribute in all GRE frames for the specified forward A10 connection.
0 E = [0,1] 1 2 3 4 5 6 7 Octet 1 2 3 4
9 10 11 12 13 14
Type = 000 0011 Length = 02H Flow ID = [00H - FFH] Reserved
15 16 17 18
Type: Length: Flow ID:
3 IP Flow Discriminator 02H This field contains the flow ID. Refer to [8] for detailed information.
19 20 21
2.6.1.4 Segmentation Indication If the packet is segmented, sequence numbers shall be required and the overall User Traffic length is identified by an attribute defined as follows:
0 E = [0,1] Value = 00-10 1 2 3 4 5 6 7 Octet 1 2 3 4 Type = 000 0100 Length = 02H Reserved Reserved
22
Type:
04H - Segmentation Indication A-2
3GPP2 A.S0008-C v2.0

1 2 3 4 5 6 7
Length: Value:
02H The segmentation indication Value is coded as shown below. 00 - Packet started 01 - Packet continued 10 - Packet ended Other reserved
8 9 10 11 12
2.6.1.5 Buffered Data Information If the source AN has buffered data to send to the target AN, it includes the Buffered Data Information GRE attribute to allow the target AN to map packets to the correct RLP flow and to indicate whether or not the packet is the last packet. GRE sequencing should be used if it is necessary to ensure that the information is not received out of order. 0 E = [0,1] Buff Ind 1 2 3 4 5 6 7 Octet 1 2 3 4
Type = 000 0101 Length = 02H Reserved Reserved
13 14 15 16 17 18 19 20
E Type: Length: Buff Ind
The E bit is set to 1 for the last attribute in the attribute list. It is set to 0 for all other attributes. 05H - Buffered Data Information 02H The buffer indicator is set to indicate that the last packet of user traffic has been sent on the A24 interface and is coded as follows. 0 - Packet is not the last packet. 1 - Packet is the last packet.
21
...
2.6.2 Relationship of GRE tunnel to Quality of Service The users IP traffic associated with the packet data service is tunneled across the RAN using GRE/IP transport. The inner IP packet is the packet transmitted between the user (e.g. Mobile Station (MS)) and its correspondent node (e.g. Internet server). The outer IP packet transports (or tunnels) a portion of the inner packet between the RAN components (i.e. BS, PCF, PDSN). Thus, the inner and outer packets may have inner and outer DSCP values whose usage is described as follows. If the RAN supports QoS on the A8/A9 and A10/A11 interfaces, the RAN shall have a local RAN transport network QoS policy which indicates which outer DSCP values can be used by the PDSN, PCF and BS for traffic. These DSCP values shall be made available to the PDSN (e.g. via OAM&P functions) to enable QoS for the RAN transport network. When QoS is required for GRE tunnels across the A8/A10 transport network, the IOS shall implement Diffserv as described in section 2.4.4 to support intra-network QoS requirements. In addition, the BS, PCF and PDSN shall follow specific mapping rules as follows:
22 23 24 25 26 27 28 29 30 31 32 33 34 35
A-3
3GPP2 A.S0008-C v2.0

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
1. The PDSN shall mark packets in the GRE tunnel packets (outer DSCP value) in the forward direction according to the network operators choice from the following options. a. the policy in use by the RAN transport network (refer to section 2.4.4) connecting the PDSN to the PCF. This policy is local and specifies the DSCP values for use on each GRE tunnel (i.e. service instance) instantiated on the PDSN. a. Mark packets autonomously. If the RAN supports IP flow based (subscriber) QoS functionality, then the PDSN may take into account the subscriber QoS profile and the granted QoS for the IP flow when marking packets. b. Use the inner DSCP value to determine the outer DSCP value. c. Set the DSCP value of each forward GRE packet to the value specified by the PCF for that IP flow. For this option to apply, the PCF shall inform the PDSN of the DSCP value that the PDSN shall use to mark forward GRE packets. If GRE sequencing is used, then the PCF shall specify the same DSCP value for all IP flows in the same A10 connection. In all cases the markings selected by the PCF and PDSN shall comply with the local transport QoS policy in use by the RAN transport network (refer to section 2.4.4) connecting the PDSN to the PCF 2. The PCF and BS shall mark the GRE tunnel packets (outer DSCP value) according to the network operators choice from the following options. a. The PCF and BS shall use the local QoS policy (refer to section 2.4.4) to set the outer DSCP value of the packets in the GRE tunnels (i.e. service instance). Since the PCF and BS are not required to inspect the encapsulated IP packets to derive the inner DSCP value, the PCF and BS may mark all GRE packets in the same service instance (SI) with the same DSCP value. The PCF and BS may also set the DSCP value of all GRE packets associated with the same user to the same value if this is the local policy. a. Mark packets autonomously. If the RAN supports IP flow based (subscriber) QoS functionality, then the PCF and BS may take into account the subscriber QoS profile and the granted QoS for the IP flow when marking packets. b. In the forward direction at the PCF, set the DSCP value of each forward GRE packet to the value used on the corresponding GRE packets on the A10 interface. c. In the forward direction at the PCF, set the DSCP value of each forward GRE packet to the value specified by the BS for that IP flow. For this option to apply, the BS shall inform the PCF of the DSCP value that the PCF shall use to mark forward GRE packets. If GRE sequencing is used, then the BS shall specify the same DSCP value for all IP flows in the same A8 connection. In all cases the markings selected by the BS and PCF shall comply with the local transport QoS policy in use by the RAN transport network (refer to section 2.4.4) connecting the PCF to the AN 3. The BS may use the outer DSCP value for RAN QoS functions (e.g. RLP frame prioritization). However, in cdma2000 systems without user quality of service functionality, the BS is not required to differentiate between packets in the same SI or between users.
38
...
2.6.3 GRE Protocol Usage for 1x VoIP SOs GRE encapsulation is used to transport Voice over Internet Protocol (VoIP) frames. Like the A8/A10 connections for ordinary packet data, the GRE Key field is used to demultiplex these connections in the BS, PCF and PDSN. The GRE frame shall be encapsulated in an IP packet sent between the PCF and PDSN on the A10 interface. The GRE frame shall be encapsulated in an IP packet sent between the BS and PCF on the A8 interface. 1x VoIP SOs 60 and 61 define their own format for the GRE payload and may make use of the GRE sequence number or may require the sequence number to be absent. Refer to the SO specification [18] for more details. A-4
39 40 41 42 43 44 45 46
3GPP2 A.S0008-C v2.0
...
3.1.3.4.5 SCCP Transfer of DTAP and BSMAP Messages The DTAP and BSMAP messages on the A1 interface are contained in the user data field of the exchanged SCCP frames. Table 3.1.3.4.5-1 below summarizes the use of the User Data Field in SCCP frames. Table 3.1.3.4.5-1
SCCP Frame Connection Oriented Protocol Class 2 SCCP Connection Request (CR) SCCP Connection Confirm (CC) SCCP Connection Refused (CREF) SCCP Released (RLSD) SCCP Release Complete (RLC) SCCP Data Transfer 1 (DT1) Connectionless Protocol Class 0 SCCP Unit Data (UDT) Mandatory Optional Optional Optional Optional Not Applicable Mandatory
2 3 4 5 6
Use of the User Data Field in SCCP Frames

User Data Field (BSMAP/DTAP)
7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
For connection oriented transactions, a connection is requested, obtained or refused using the following SCCP messages (protocol class 2): SCCP Connection Request (CR) SCCP Connection Confirm (CC) SCCP Connection Refused (CREF) SCCP Released (RLSD) and SCCP Release Complete (RLC) messages are used to break a connection. The use of the User Data Field in SCCP frames in the various establishment and release cases is described in section 3.1.3.4.1, Connection Establishment and section 3.1.3.4.2, Connection Release. For connection oriented (protocol class 2) transactions, once the signaling connection is confirmed between the MSC and the BS, all A1 interface messages are transported in the SCCP Data Transfer 1 (DT1) message until the connection is to be dropped. For Connectionless (protocol class 0) transactions, where there is no SCCP connection, A1 interface messages are transported in the SCCP Unit Data (UDT) message. Table 3.1.3.4.5-2 below indicates which SCCP messages shall be used to transport each of the application messages on the A1 interface. All A1 messages exchanged between an MSC and an HRPD AN are sent in SCCP UDT messages.
24
...
3.2.2.6.4 SUA Transfer of DTAP and BSMAP Messages The DTAP and BSMAP messages on the A1p interface are contained in the user data field of the exchanged SUA frames. Table 3.2.2.6.4-1 below summarizes the use of the User Data Field in SUA frames. Table 3.2.2.6.4-1
SUA Frame
25 26 27 28 29
Use of the User Data Field in SUA Frames

User Data Field
A-5
3GPP2 A.S0008-C v2.0

(BSMAP/DTAP) Connection Oriented Protocol Class 2 SUA Connection Request (CORE) SUA Connection Acknowledge (COAK) SUA Connection Refused (COREF) SUA Release Request (RELRE) SUA Release Complete (RELCO) SUA Connection Oriented Data Transfer (CODT) Connectionless Protocol Class 0 SUA Connectionless (CLDT)
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
Optional Optional Optional Optional Not Applicable Mandatory
Data
Transfer
Mandatory
For connection oriented transactions, a connection is requested, obtained or refused using the following SUA messages (protocol class 2): SUA Connection Request (CORE) SUA Connection Acknowledge (COAK) SUA Connection Refused (COREF) SUA Release Request (RELRE) and SUA Release Complete (RELCO) messages are used to break a connection. The use of the User Data Field in SUA frames in the various establishment and release cases is described in section 3.2.2.6.1 and section 3.2.2.6.2. For connection oriented (protocol class 2) transactions, once the signaling connection is confirmed between the MSCe and the BS, all A1p interface messages are transported in the SUA Connection Oriented Data Transfer (CODT) message until the connection is to be dropped. For Connectionless (protocol class 0) transactions, where there is no SUA connection, A1p interface messages are transported in the SUA Connectionless Data Transfer (CLDT) message. Table 3.2.2.6.4-2 below indicates which SUA messages shall be used to transport each of the application messages on the A1p interface. All A1p messages exchanged between an MSC and an HRPD AN are sent in SUA CLDT messages.
18
...
3.4 A8 and A9 Interfaces
19
20
...
3.4.3 Use of GRE For general use of GRE, refer to section 2.6. The BS shall set the Key field in the GRE header to the value in the Key field in the A8 Traffic ID element in the A9-Connect-A8 message received from the PCF indicating that the PCF accepts the A8 connection. The PCF shall set the Key field in the GRE header to the value in the Key field in the A8 Traffic ID element in the A9-Setup-A8 message received from the BS requesting the establishment of the A8 connection. Refer to [16] for details on these A9 messages. On the A8 interface, valid attributes (refer to section 2.6.1) that may be included in the GRE frames when the Protocol Type field is set to "3GPP2 Packet" include: no attributes have been defined (refer to section 2.6.1) that may be included in the GRE frames when the Protocol Type field is set to 3GPP2 Packet. A-6
21 22 23 24 25 26 27 28 29 30
3GPP2 A.S0008-C v2.0

1 2
IP Flow Discriminator Segmentation Indication
...
3.5 A10 and A11 Interface
...
3.5.2 Use of GRE For general use of GRE, refer to section 2.6. The PCF shall set the Key field in the GRE header to the value in the Key field in the Session Specific Extension in the A11-Registration Reply message received from the PDSN indicating that the PDSN accepts the A10 connection. The PDSN shall set the Key field in the GRE header to the value in the Key field in the Session Specific Extension in the A11-Registration Request message received from the PCF requesting the establishment of the A10 connection. Refer to [17] for details on these A11 messages. On the A10 interface, valid attributes (refer to section 2.6.1) that may be included in the GRE frames when the Protocol Type field is set to 3GPP2 Packet include: Short Data Indicator Flow Control Indication IP Flow Discriminator Segmentation Indication
6 7 8 9 10 11 12 13 14 15 16 17 18
A-7
3GPP2 A.S0008-C v2.0

1 2 3 4 5
A-8
3GPP2 A.S0008-C v2.0
1 2 3 4 5 6 7 8 9 10 11 12 13 14
Annex B
A1/A1p Interface (BS - MSC) Interface Change Text (Normative)
Note: Annex B contains specific A1 messaging text from [14] with all HRPD related changes identified through the use of underscores (additions) and strikeouts (deletions). Use of an ellipsis () indicates that the base document is unchanged. In this section, A1 messages are used by both the A1 and A1p interfaces except where indicated. In this section, BS is used to refer to either a 1x BS or an HRPD AN except where indicated. Note: Refer to section 2 for a cross reference of 1x and HRPD terminology. When the A1/A1p interface is used between an HRPD AN and a 1x MSC, the Mobile Identity (IMSI) is determined as follows: If the HRPD AN uses the access authentication feature, the Mobile Identity (IMSI) shall be set to the MN ID value returned by the AN-AAA (e.g., IMSI) following successful access authentication. Otherwise, the HRPD AN shall set the Mobile Identity (IMSI) 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 beyond the scope of this specification.
15
...
1.2.1 3GPP2 and TIA / EIA
16
17
...
[43] 3GPP2: C.S0024-B v2.0, cdma2000 High Rate Packet Data Air Interface Specification, March 2007.
18 19
20
...
2.1.2 Connection Management (CM) Service Request In 1x systems, wWhen the MSs originating access attempt is received by the BS, the BS constructs the CM Service Request DTAP message, places it in the Complete Layer 3 Information message, and sends the message to the MSC. In the case of HRPD VoIP handoff to 1x circuit voice call, the CM Service Request DTAP message is sent to the MSC to indicate call origination from the HRPD AN. The IWS1xBS or the standalone IWS shall construct the CM Service Request DTAP message using the CM Service Type value of 1001 as defined in Annex B of this document.
21 22 23 24 25 26 27
28
...
2.1.4 Paging Request This BSMAP message is sent from the MSC to the BS to initiate a mobile terminated call setup scenario. This message may also be sent for location purposes. 2.1.4.1 Successful Operation The MSC determines that an MS in its serving area needs to be paged and initiates the paging procedure. It starts timer T3113, sends the Paging Request message to the BS, and waits for the Complete Layer 3 information containing a Paging Response message. In 1x systems, if the BS is not utilizing direct channel assignment, and if the Paging Request message does not contain a Page Indicator IE, or if the Paging Request message contains a Page Indicator IE but the VPI field is set to 0, then when the BS receives the Paging Request message from the MSC, it determines from which cell(s) to broadcast the page request. The page messages are distributed to the B-1
29 30 31
32 33 34 35 36 37 38 39
3GPP2 A.S0008-C v2.0

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
appropriate cell(s), which broadcast the page message over their paging channels. Where necessary, the page message is inserted into the computed paging channel slot. If the A2p Bearer Format-Specific Parameters IE is included in the received Paging Request message and contains a list of bearer format parameters, then the BS is to attempt to page the MS using the service option associated with the first bearer format in the list that is supported by the BS. In 1x systems, if the BS and MS support direct channel assignment, and if the Paging Request message does not contain a Page Indicator IE, or if the Paging Request message contains a Page Indicator IE but the VPI field is set to 0, then when the BS receives a Paging Request from the MSC, it may page the MS as described above and simultaneously signal to the MS to prepare to receive an Extended Channel Assignment Message 76. The BS then immediately assigns a traffic channel to the MS without waiting for a response to the Page Message. Alternatively, the BS sends an extended channel assignment message to the MS in place of the page message. In 1x systems, if the BS receives a Paging Request message which contains a Page Indicator IE and the VPI field is set to 1, the BS shall prepare to receive a Page Response message from the MS. When paging for HRPD service, the MSC uses SO69 to specify that the MS is required to send a page response prior to the MS tuning to the HRPD system. Otherwise, the MSC uses SO59. Optionally, the MSC also indicates a ReservationLabel [43] by using HRPD service option 59RRH or 69RRH where RR is the hexadecimal value assigned to the ReservationLabel (e.g., 5910H indicates ReservationLabel 10H). 2.1.4.2 Failure Operation If a Complete Layer 3 Information message containing a Paging Response message has not been received by the MSC before timer T3113 expires, the MSC may repeat the Paging Request message and restart timer T3113 a configurable number of times.
19 20 21 22
23
...
2.1.7 Assignment Request In 1x system, tThis BSMAP message is sent from the MSC to the BS to request assignment of radio resources or to the IWS-AN to perform HPRD VoIP call handoff to 1x circuit voice call. In the case of HRPD VoIP handoff to 1x circuit voice call, the MSC sends this message to the IWS-AN or the standalone IWS without setting up the A2 bearer for the voice call. 2.1.7.1 Successful Operation After sending this message to the BS or the IWS-AN, the MSC starts timer T10 and waits for the Assignment Complete message from the BS or the IWS-AN. In the 1x system, tThe BS stops timer T303 or T20 upon receipt of the Assignment Request message, selects a traffic channel, sends the channel assignment message to the MS (unless the MS is already on a traffic channel), and waits for the confirmation from the MS that the MS reached the assigned traffic channel. In the HRPD system, the IWS-AN stops timer T303 or T20 upon receipt of the Assignment Request message, and sends the Assignment Complete message to the MSC and does not establish A2/A2p bearer. 2.1.7.2 Failure Operation If the MSC fails to receive an Assignment Complete message, or an Assignment Failure message before the expiration of timer T10, then it shall initiate call clearing.
24 25 26 27 28
29 30 31 32 33 34 35 36 37
38 39 40
76 This may be Channel Assignment Message or Extended Channel Assignment Message.
B-2
3GPP2 A.S0008-C v2.0

1 2 3 4 5 6 7 8 9
2.1.8
Assignment Complete
This BSMAP message indicates that the requested assignment has been completed correctly. The sending of the Assignment Complete message also indicates to the MSC that it is now responsible for providing in-band treatment of the call if required and if the bearer path has been successfully setup. In the 1x system, if the BS has not received the bearer formats and address to be used, the BS sends this message to the MSCe to indicate that the MS and BS have successfully negotiated the traffic channel and service and waits for the bearer format and transport address to be sent from the MSCe. In the case of HRPD VoIP handoff to 1x circuit voice call, the IWS-AN sends this message to the MSC to indicate 1x inter-BSC handoff will begin. 2.1.8.1 Successful Operation In the 1x system, wWhen the MS and BS have successfully negotiated the traffic channel and service, the BS sends this message to the MSC. If the BS sent the A2p bearer parameters in the CM Service Request or Paging Response message but has not received the bearer format and transport address to be used, the BS starts timer Txxp and waits for the Bearer Update Request message. If the BS is communicating with an MSCe and did not send the A2p bearer parameters in the CM Service Request or Paging Response message, the BS shall include the A2p bearer parameters in this message, start timer Txxp and wait for the Bearer Update Request message. In the HRPD system, when the IWS-AN has received the Assignment Request message, it sends the Assignment Complete message to the MSC immediately without any other actions. When the MSC receives this message, it stops timer T10 and starts timer T301 (unless the Assignment Complete message is received as part of a mobile originated call or a packet data call) and waits for the Connect or Flash With Information message from the BS. Note that for mobile originated calls and network-initiated reactivation of packet data calls, the MSC considers the call to be stable and in the conversation state after receiving the Assignment Complete message and upon successful setup of the bearer path if needed. In all other cases the MSC considers the call to be stable and in the conversation state after receiving the Connect message. 2.1.8.2 Failure Operation None.
10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26
27 28
29
...
2.1.17 BS Service Request This BSMAP message is sent from the BS to the MSC to begin a BS initiated call setup. In HRPD systems, this message is used to initiate an HRPD page in the 1x system. It is also used to initiate an ADDS Page or ADDS Deliver procedure to deliver a Short Data Burst (SDB) to an MS. For SDBs, the message is used to transport the data to the MSC for delivery to an MS. 2.1.17.1 Successful Operation To initiate a call setup, the BS sends a BS Service Request message to the MSC containing the identity of the MS to be paged. In HRPD systems, when the AN/PCF receives data from the PDSN, based on vendor specific procedures (e.g., stored information indicating that the MS/AT has registered with the 1x system), it sends a BS Service Request message to the MSC containing HRPD service option 59, to reactivate the packet data session in the HRPD system. Optionally, the AN/PCF also indicates a ReservationLabel [43] by using HRPD service option 59RRH where RR is the hexadecimal value assigned to the ReservationLabel (e.g., 5910H indicates ReservationLabel 10H). When the 1x BS/PCF receives data from the PDSN destined for an MS with a dormant packet data service instance, the BS may deliver the data as an SDB to the MSC, by sending a BS Service Request message including the application data to be sent to the MS. The 1x BS or HRPD AN starts timer T311 and awaits the reception B-3
30 31 32 33 34
35 36 37 38 39 40 41 42 43 44 45
3GPP2 A.S0008-C v2.0

1 2 3
of the BS Service Response message. The MSC delivers the SDB using the ADDS Page message if the MS is idle, or the ADDS Deliver message if the MS is on a traffic channel, e.g., the user is engaged in a voice call. 2.1.17.2 Failure Operation If a BS Service Response message is not received at the BS before the expiration of timer T311 the BS may resend the BS Service Request message and restart timer T311 a configurable number of times. For SDB delivery to an MS, if the BS times out waiting for a BS Service Response message from the MSC, the BS shall not resend the BS Service Request message, and shall discard the data.
4 5 6 7 8
...
2.3.23 Event Notification In 1x systems, this message may be sent from the MSC to the BS prior to SCCP link establishment to indicate a change in call processing. In HRPD systems, this BSMAP message may be sent from the MSC to the HRPD AN to notify that AN about a 1x event (e.g., registration or power down) associated with an MS/AT which had requested Cross Notification Services. 2.3.23.1 Successful Operation In 1x systems, if the MSC determines that a change to call processing is required, and an SCCP link has not yet been established for the call, the MSC sends an Event Notification message to the BS that is currently processing the call. The MSC starts timer Tevent when it sends this message. Upon receipt of the Event Notification message, the BS takes the appropriate steps to change the call processing, depending on the information received in the message. In HRPD systems, when the MSC detects a 1x event (e.g., registration or power down) associated with an MS/AT for which it is supporting Cross Notification Services, the MSC sends this message to the corresponding HRPD AN. 2.3.23.2 Failure Operation If an Event Notification Ack message is not received prior to expiration of timer Tevent, then the MSC may resend the Event Notification message and restart timer Tevent a configurable number of times. 2.3.24 Event Notification Ack This message is sent from the BS to the MSC in response to receiving an Event Notification message. 2.3.24.1 Successful Operation If the BS receives an Event Notification message from the MSC, it shall send an Event Notification Ack message to the MSC. Upon receipt of this message, the MSC stops timer Tevent. 2.3.24.2 Failure Operation None.
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
...
2.4.7 Handoff Required Reject This BSMAP message is sent from the MSC to the source BS to deny the request contained in a Handoff Required message. B-4
36 37 38
3GPP2 A.S0008-C v2.0

1 2 3 4 5 6 7 8 9 10 11
2.4.7.1 Successful Operation If the source BS requested a response by including the Response Request element in the Handoff Required message, and the handoff cannot be accomplished, a Handoff Required Reject message may be sent to the source BS indicating that the handoff cannot be accomplished at this time. In the 1x system, iIf a Handoff Required Reject message is received, then the source BS shall stop timer T7 and a new handoff procedure may be initiated if the condition of the call connection warrants immediate action (e.g., emergency handoff). Such a procedure is implemented at the discretion of the manufacturer and system operator. In the HRPD system, if a Handoff Required Reject message is received, then the IWS/AN shall stop timer T7 and a call clearing procedure may be initiated to send a Clear Request message to the MSC. Such a procedure is implemented at the discretion of the manufacturer and system operator. 2.4.7.2 Failure Operation None.
12 13
14
...
2.5 Facility Management Message Procedures
15
16
...
2.5.5 Reset Circuit In the 1x system, tThis BSMAP message is sent by either the BS or the circuit-switched MSC to request that one or more circuits be idled (reset). In the HRPD system, this BSMAP message can be sent only by the circuit-switched MSC to the IWS/AN.
17 18 19 20
21
...
2.5.5.2 Reset Circuit (at the circuit-switched MSC) If the circuit-switched MSC detects that one or more circuits have to be idled due to abnormal SCCP connection release or OAM&P intervention, it sends a Reset Circuit message to the BS indicating the circuits which the BS is to idle and the cause of the circuit reset. 2.5.5.2.1 Successful Operation
22 23 24 25
26 27 28 29 30 31 32 33 34 35 36 37 38
The circuit-switched MSC starts timer T12 when it sends this message. Timer T12 shall be set to a large enough value to allow sufficient time for the BS to reset all circuits indicated in this message. In the 1x system, wWhen the BS receives a Reset Circuit message, it shall respond with a Reset Circuit Acknowledge message in the case that all of the circuit(s) can be idled and none of the circuits are blocked. If all of the circuits are blocked at the BS at reception of the Reset Circuit message, one or more Block messages is returned to the circuit-switched MSC instead of the Reset Circuit Acknowledge message. If some of the circuits are blocked at the BS at reception of the Reset Circuit message, one or more Block messages is returned to the circuit-switched MSC indicating those blocked circuits. The circuit-switched MSC responds with a Block Acknowledge message to any Block message it receives if it successfully blocks all of the circuits specified in the Block message. In the HRPD system, when the IWS-AN receives a Reset Circuit message, it shall respond with a Reset Circuit Acknowledge message to the circuit-switched MSC immediately without any actions.
B-5
3GPP2 A.S0008-C v2.0

1 2 3 4 5 6
2.5.5.2.2
Failure Operation
If the circuit-switched MSC does not receive the Reset Circuit Acknowledge message or a Block message before the expiration of timer T12, the Reset Circuit message is sent a second and final time. If the Reset Circuit Acknowledge message is never received or recognized by the circuit-switched MSC, then the situation (i.e., possibly incompatible device states between the BS and circuit-switched MSC) shall be resolved internally in the circuit-switched MSC or by OAM&P procedures.
...
2.7.1 Rejection The Rejection message is used by the BS to indicate to the MSC that the MS has indicated rejection of a command/message. This is coded as a BSMAP message when triggered by a Mobile Station Reject Order on the access channel and a DTAP message otherwise. In HRPD systems, the Rejection message is used by the IWS-AN to indicate to the MSC that the MS/AT has rejected a tunneled incoming 1x Page Request Message, and by the MSC to indicate to the IWS-AN that a 1x data burst of type 7 has received a negative response from the MS/AT. The Rejection message may also be triggered by the receipt of an A21-Air Interface Signaling message in an IWS-1xBS that contains a 1x air interface message indicating that a page has been rejected by the MS/AT. 2.7.1.1 Successful Operation In 1x and HRPD systems, wWhen the BS receives a rejection indication (e.g., a Mobile Station Reject Order) it shall send the Rejection message to the MSC only in the cases listed below. No response is expected from the MSC. The Rejection message shall only be used in conjunction with a Mobile Station Reject Order received as a response to an ADDS Page or ADDS Deliver operation (i.e., Data Burst). In HRPD systems when the IWS-AN receives a rejection of a tunneled incoming 1x Page Request Message (e.g., the user does not accept the incoming call and the MS/AT tunnels a 1x Release Order to the AN), the IWS-AN shall send the Rejection message to the MSC. In an IWS-1xBS, when an A21-Air Interface Signaling message is received that contains a 1x air interface message indicating that a page has been rejected by the MS/AT, the IWS-1xBS shall send a Rejection message to the MSC. 2.7.1.2 Failure Operation None.
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
...
3.1.4 Paging Request This BSMAP message is sent from MSC to BS and contains sufficient information to allow the paging to be transmitted by the correct cells, in the correct format at the correct time.
Information Element Message Type Mobile Identity (IMSI/ESN) Tag Cell Identifier List Section Reference 4.2.4 4.2.13 4.2.46 4.2.18 Element Direction MSC -> BS MSC -> BS MSC -> BS MSC -> BS M Ma Oh O
b
33 34 35
Type
C C
B-6
3GPP2 A.S0008-C v2.0

Information Element Slot Cycle Index Service Option IS-2000 Mobile Capabilities Protocol Revision MS Designated Frequency A2p Bearer Format-Specific Parameters Page Indicator Mobile Identity (MEID) Mobile Subscription Information MS Information Records
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
Section Reference 4.2.14 4.2.49 4.2.53 4.2.79 4.2.88 4.2.90 4.2.93 4.2.13 4.2.91 4.2.55
Element Direction MSC -> BS MSC -> BS MSC -> BS MSC -> BS MSC -> BS MSCe -> BS MSC -> BS MSC -> BS MSC -> BS MSC -> BS Oc,f O O O O O O O
d,k e,f,i g
Type C R C C C C C C C C
f, e j n l m o
a. This element shall be set to ESN when the BS and MS are operating in DS-41 mode and IMSI otherwise 77. b. This element is only required for a multi-cell BS. More than one cell identifier element may be included to allow the paging request of several cells within a BS on receipt of a single paging request message from the MSC. When absent, paging request at all cells controlled by the BS is assumed. This IE may be ignored by the HRPD AN. c. This element is included where slotted paging is performed on the paging channels. It is used by the BS to compute the correct paging channel slot on each paging channel. If this element is absent, then it is assumed that the MS is operating in non-slotted mode. This IE may be ignored by the HRPD AN. d. The MSC may decide to page the MS with the preferred service option selected from the subscribed service option record. e. This element is only included when the MSC has previously been given this information by a BS. This IE may be ignored by the HRPD AN. f. These elements shall not be included by the MSC when the BS and MS are operating in DS-41 mode. g. This element contains the MSs MOB_P_REV of the current band class and shall be included if the value is greater than or equal to 7. h. If this element is present in the message, the value shall be saved at the BS to be included in the corresponding Paging Response message. i. j. If the MSC does not have the information required to correctly populate a field in this IE, it shall code the field to zero. The MSCe may include this element to indicate the preferred service options for paging. The first entry in the bearer format list of this information element should be consistent with the Service Option IE. If it is not consistent, then the Service Option IE shall take precedence.
k. The following service options are not permissible when this message is sent from an MSCe: "003E (Wideband Speech Codec), 0004H (Async Data Rate Set 1), 000CH (Async Data Rate Set 2), 0005H (G3 Fax Rate Set 1), 000DH (G3 Fax Rate Set 2), 0025H (ISDN Interworking Service), 0039H (32 kbps Circuit Switched Video Conferencing) and 003AH (64 kbps Circuit Switched Video Conferencing). When sent to an HRPD AN, the only valid service options are: 8000H (13K speech),
77
In DS-41 mode, ESN is used because an IMSI may not be available, e.g., emergency calls to an MS without a subscriber identity module.
B-7
3GPP2 A.S0008-C v2.0

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
0011H (13K high rate voice service), 0003H (EVRC), and 003EH (Wideband Speech Codec). When sent to a 1x BS to page for HRPD service, the valid service options are: 003BH (HRPD Packet Data; page response not required), 5900H-59FFH (HRPD Packet Data; page response not required), 0045H (HRPD Packet Data; page response required), and 6900H-69FFH (HRPD Packet Data; page response required). Note: SO 003BH may be used to indicate that the request is for the main service option for HRPD packet data or AltPPP service. l. This IE is included if the MEID is available at the MSC. m. If available at the MSC, the MSC shall include a Band Class/Band Subclass Record within this element to report the last known band class and band subclass (if applicable) as well as any other band classes and band subclasses supported by the MS. n. This IE is included to provide paging details to the BS (e.g., Virtual Page Indicator field identifies whether the 1x BS shall be prepared to receive a Page Response Message from the MS/AT). This IE may be ignored by the HRPD AN. o. This IE may be included if the necessary information is available at the MSC. The following table shows the bitmap layout for the Paging Request message.
3.1.4 7 6 5 BSMAP Header: 4 Paging Request 3 2 1 0 Octet 1 2 1 1 2 3 Message Discrimination = [00H]
16
Length Indicator (LI) = <variable> Message Type = [52H] Mobile Identity (IMSI/ESN): A1 Element Identifier = [0DH] Type of Identity = [101 (ESN),110 (IMSI)] Length = [05H-08H] (10-15 digits) Identity Digit 1 = [0H-9H] (BCD) Odd/even Indicator = [1,0] ESN = <any value>
IF(Type of Identity = 101), Identity {1: (MSB) 4 5 6 (LSB) } OR IF (Type of Identity = 110), Identity {1: Identity Digit 3 = [0H-9H] (BCD) Identity Digit 2 = [0H-9H] (BCD) 4 7
Identity Digit N+1 = [0H-9H] (BCD) = [1111] (if even number of digits), Identity Digit N+3 = [0H-9H] (BCD) (if odd number of digits) } Type of Identity (MSB) Tag: A1 Element Identifier = [33H] Tag Value = <any value> Identity Digit N = [0H-9H] (BCD) Identity Digit N+2 = [0H-9H] (BCD)
n n+1
1 2 3 4
B-8
3GPP2 A.S0008-C v2.0

3.1.4 7 6 5 4 Paging Request 3 2 1 0 (LSB) Cell Identifier List: A1 Element Identifier = [1AH] Length = <variable> Cell Identification Discriminator = [02H,05H] IF (Discriminator = 02H), Cell Identification {1+: (MSB) Cell = [001H-FFFH] Sector = [0H-FH] (0H = Omni) } OR IF (Discriminator = 05H), Cell Identification {1+: (MSB) } Cell Identification (MSB) Slot Cycle Index: A1 Element Identifier = [35H] Slot Cycle Index = [000-111] Service Option 1 2 1 2 Reserved = [00000] LAC = [0001H-FFFFH] (LSB) j j+1 (LSB) j j+1 Octet 5 1 2 3
Service Option: A1 Element Identifier = [03H]
B-9
3GPP2 A.S0008-C v2.0

3.1.4 7 6 5 4 Paging Request 3 2 1 0 (LSB) Octet 3
to a 1x BS = [8000H (13K speech), 0011H (13K high rate voice service), 0003H (EVRC), 003EH (Wideband Speech Codec), 801FH (13K Markov), 0009H (13K Loopback), 0004H (Async Data Rate Set 1), 000CH (Async Data Rate Set 2), 0005H (G3 Fax Rate Set 1), 000DH (G3 Fax Rate Set 2), 0006H (SMS Rate Set 1), 000EH (SMS Rate Set 2), 0021H (3G High Speed Packet Data), 0012H (OTAPA Rate Set 1), 0013H (OTAPA Rate Set 2), 0025H (ISDN Interworking Service), 0020H (TDSO), 0036H (IS-2000 Markov), 0037H (IS-2000 Loopback), 0023H (PDS Rate Set 1), 0024H (PDS Rate Set 2), 0038H (SMV), 0039H (32 kbps Circuit Switched Video Conferencing), 003AH (64 kbps Circuit Switched Video Conferencing) 003BH (HRPD Packet Data; page response not required), 0045H (HRPD Packet Data; page response required),] 5900H-59FFH (HRPD Packet Data; page response not required) 6900H-69FFH (HRPD Packet Data; page response required)] to an HRPD AN = [8000H (13K speech), 0011H (13K high rate voice service), 0003H (EVRC), 003EH (Wideband Speech Codec)] IS-2000 Mobile Capabilities: A1 Element Identifier = [11H] Length = <variable> REV_ ERAM DCCH FOR_ PDCH PDCH Supported Supported Supported Supported = = [0,1] = [0,1] [0,1] = [0, 1] FCH Supported = [0,1]
1 2 3
OTD Enhanced QPCH Supporte RC CFG Supported d Supported = [0,1] = [0,1] = [0,1]
FCH Information: Bit-Exact Length Octet Count = [00H to FFH]
B-10
3GPP2 A.S0008-C v2.0

3.1.4 7 Reserved = [0] 6 5 4 Geo Location Type = <any value> (Ignored) Paging Request 3 Geo Location Included = <any value> (Ignored) 2 1 0 Octet 5 FCH Information: Bit-Exact Length Fill Bits = [000 to 111]
(MSB) FCH Information Content = <any value> Seventh Fill Bit if needed = [0 (if used as a fill bit)] Sixth Fill Bit if needed = [0 (if used as a fill bit)] Fifth Fill Bit if needed = [0 (if used as a fill bit)] Fourth Fill Bit if needed = [0 (if used as a fill bit)] Third Fill Bit if needed = [0 (if used as a fill bit)] Second Fill Bit if needed = [0 (if used as a fill bit)] First Fill Bit if needed = [0 (if used as a fill bit)]
DCCH Information: Bit-Exact Length Octet Count = [00H to FFH] Reserved = [0000 0] (MSB) DCCH Information Content = <any value> Seventh Fill Bit if needed = [0 (if used as a fill bit)] Sixth Fill Bit if needed = [0 (if used as a fill bit)] Fifth Fill Bit if needed = [0 (if used as a fill bit)] Fourth Fill Bit if needed = [0 (if used as a fill bit)] Third Fill Bit if needed = [0 (if used as a fill bit)] Second Fill Bit if needed = [0 (if used as a fill bit)] First Fill Bit if needed = [0 (if used as a fill bit)] DCCH Information: Bit-Exact Length Fill Bits = [000 to 111]
k+1 k+2
k+3
FOR_PDCH Information: Bit-Exact Length Octet Count = [00H-FFH] Reserved = [0000 0] (MSB) FOR_PDCH Information Content = <any value> Seventh Fill Bit if needed = [0 (if used as a fill bit)] Sixth Fill Bit if needed = [0 (if used as a fill bit)] Fifth Fill Bit if needed = [0 (if used as a fill bit)] Fourth Fill Bit if needed = [0 (if used as a fill bit)] Third Fill Bit if needed = [0 (if used as a fill bit)] Second Fill Bit if needed = [0 (if used as a fill bit)] First Fill Bit if needed = [0 (if used as a fill bit)] FOR_PDCH Information: Bit-Exact Length Fill Bits = [000 to 111]
m+1 m+2
m+3
B-11
3GPP2 A.S0008-C v2.0

3.1.4 7 6 5 4 Paging Request 3 2 1 0 Octet n+1 n+2
REV_PDCH Information: Bit-Exact Length Octet Count = [00H-FFH] Reserved = [0000 0] (MSB) REV_PDCH Information Content = <any value> Seventh Fill Bit if needed = [0 (if used as a fill bit)] Sixth Fill Bit if needed = [0 (if used as a fill bit)] Fifth Fill Bit if needed = [0 (if used as a fill bit)] Fourth Fill Bit if needed = [0 (if used as a fill bit)] Third Fill Bit if needed = [0 (if used as a fill bit)] Second Fill Bit if needed = [0 (if used as a fill bit)] First Fill Bit if needed = [0 (if used as a fill bit)] REV_PDCH Information: Bit-Exact Length Fill Bits = [000 to 111]
n+3
Protocol Revision:
1 2 3 1 2 3 4 1 2 3
Length = [01H] MOB_P_REV = [07H-FFH] MS Designated Frequency: A1 Element Identifier = [73H] CDMA channel (high part) = [000 111] Length = [05H] Band Class = [00000 11111] CDMA channel (low part) = [00H FFH] A2p Bearer Format-Specific Parameters: A1p Element Identifier = [46H] Length = <variable> Number of Bearer Formats = <variable> Bearer Format Parameters {1+: Bearer Format Length = <variable> Ext = [0,1] Bearer Format Tag Type = [001-100] Bearer Format ID = [0000 0111] Bearer Addr Flag= [0, 1] Bearer IP Address Type= [00 = IPv4]
m m+1 m+2
RTP Payload Type = [00H = (PCMU), 08H = (PCMA), 0CH = (13K Vocoder), 60H - 7FH (dynamically assigned = EVRC), 60H - 7FH (dynamically assigned = EVRC0), 60H - 7FH (dynamically assigned = SMV), 60H - 7FH (dynamically assigned = SMV0), 60H - 7FH (dynamically assigned = telephone-event)] (MSB) Bearer IP Address = <any value>
(LSB)
B-12
3GPP2 A.S0008-C v2.0

3.1.4 7 (MSB) 6 5 4 Paging Request 3 2 1 0 Octet j+1 (LSB) Extension Length = [0001] } Bearer Format Parameters Page Indicator: A1 Element Identifier = [7BH] Length = [01H] Reserved = [0000 000] Mobile Identity (MEID): A1 Element Identifier = [0DH] Length = [08H] MEID Hex Digit 1 = [0H-FH] Odd/Even Indicator = 0 Type of Identity = [001] (MEID) VPI = [0,1] 1 2 3 1 2 3 Extension ID = [0000] Extension Parameters = <any value> j+2 k k+1
Bearer UDP Port= <any value>
MEID Hex Digit 3 = [0H-FH] MEID Hex Digit 5 = [0H-FH] MEID Hex Digit 7 = [0H-FH] MEID Hex Digit 9 = [0H-FH] MEID Hex Digit 11 = [0H-FH] MEID Hex Digit 13 = [0H-FH] Fill = [FH] Record: {1: Mobile Subscription Information:
MEID Hex Digit 2 = [0H-FH] MEID Hex Digit 4 = [0H-FH] MEID Hex Digit 6 = [0H-FH] MEID Hex Digit 8 = [0H-FH] MEID Hex Digit 10 = [0H-FH] MEID Hex Digit 12 = [0H-FH] MEID Hex Digit 14 = [0H-FH] A1 Element Identifier = [7DH] Length = <variable>
4 5 6 7 8 9 10 1 2 1 2 3
Record Identifier = [00H] Record Length = <variable> All Band Classes Included = [0,1] All Band Subclasses Included = [0,1] SC7 = [0,1] SC6 = [0,1] Current Band Subclass = <variable>
Band Class = <variable> Reserved = [000] Band Subclass Length = <variable>
4 5
SC5 = [0,1]
SC4 = [0,1]
SC3 = [0,1]
SC2 = [0,1]
SC1 = [0,1]
SC0 = [0,1]
SCn = [0,1] SCn-1 = [0,1] SCn-2 = [0,1] SCn-3 = [0,1] SCn-4 = [0,1] SCn-5 = [0,1] SCn-6 = [0,1] SCn-7 = [0,1]
Band Class n = <variable>
B-13
3GPP2 A.S0008-C v2.0

3.1.4 7 All Band Subclasses Included = [0,1] SC7 = [0,1] SC6 = [0,1] 6 5 Reserved = [000] 4 Paging Request 3 2 1 0 Octet k+1 Band Subclass Length = <variable>
SC5 = [0,1]
SC4 = [0,1]
SC3 = [0,1]
SC2 = [0,1]
SC1 = [0,1]
SC0 = [0,1]
k+2
SCn = [0,1] } Record MS Information Records: A1 Element Identifier = [15H] SCn-1 = [0,1] SCn-2 = [0,1] SCn-3 = [0,1] SCn-4 = [0,1] SCn-5 = [0,1] SCn-6 = [0,1] SCn-7 = [0,1]
1 2 j j+1 j+2
Length = [01H-FFH] Information Record: {1+: Information Record Type = [00H-FFH] Information Record Length = <variable> (MSB) Information Record Content
(LSB) } Information Record

1
...
3.1.8 Assignment Complete This BSMAP message is sent from the BS to the MSC and indicates that the requested assignment has been completed.
Information Element Message Type Channel Number Encryption Information Service Option Service Option Connection Identifier (SOCI) A2p Bearer Session-Level Parameters A2p Bearer Format-Specific Parameters Mobile Identity (MEID) Section Reference 4.2.4 4.2.5 4.2.10 4.2.49 4.2.73 4.2.89 4.2.90 4.2.13 Element Direction BS -> MSC BS -> MSC BS -> MSC BS -> MSC BS -> MSC BS -> MSCe BS -> MSCe BS -> MSC M Mc Oa O O O
b d e, g
2 3 4
Type
C R C C C C
O O
f, g h
5 6 7 8 9 10 11
a. This element is present when either Voice Privacy (VP) or Signaling Message Encryption (SME) parameters were provided by the MSC in the Privacy Mode Command or Assignment Request message. It contains the algorithm information which indicates the current settings of VP and SME. No keys (encryption parameters) are included in this message. b. If the service option value included in the Assignment Request message was 8000H, 0011H, 0038H, 0003H, or 003E (13K speech, 13K high rate speech, SMV, EVRC, or Wideband Speech Codec), then the only allowable values that may be sent on this message are those same five service options. B-14
3GPP2 A.S0008-C v2.0

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
If the service option value included in the Assignment Request message indicated a fax call, then the only allowable values that may be sent on this message are fax service options. If the service option value included in the Assignment Request message indicated a data call, then the only allowable values that may be sent on this message are data service options. If the service option value included in the Assignment Request message indicated a Circuit Switched Video Conferencing data call, then the only allowable values that may be sent in this message are Circuit Switched Video Conferencing data service options. If the service option value included in the Assignment Request message indicated an SMS call, then the only allowable values that may be sent on this message are SMS service options. If the service option value included in the Assignment Request message indicated either Markov or loopback procedures, then the only allowable values that may be sent on this message are values that indicate Markov or loopback procedures. If the service option value included in the Assignment Request message indicated an OTAPA call, then the only allowable values that may be sent on this message are OTAPA service options. If the service option value included in the Assignment Request message indicated a PDS call, then the only allowable values that may be sent on this message are values that indicate PDS service options. If any of the above rules are violated, the MSC may initiate failure handling. c. If this element is not correctly present, call failure handling may be initiated by the MSC. In the case of HRPD VoIP handoff to 1x circuit voice call, the IWS-AN shall set the value of this element to 0, and the MSC ignores this field. d. This element is required if concurrent services are supported. e. If an A2p connection is required, the BS may send this element to indicate the session-level parameters to be used for this call. If this IE was previously included in the CM Service Request message or the Paging Response message, then it shall not be included in the Assignment Complete message. If this IE was not previously included in the CM Service Request message, or in the Paging Response message, then it shall be included in the Assignment Complete message. f. The BS may send this element to indicate the bearer format or formats that are supported for this call. If this IE was previously included in the CM Service Request message or the Paging Response message, then it shall not be included in the Assignment Complete message. If this IE was not previously included in the CM Service Request message, or in the Paging Response message, then it shall be included in the Assignment Complete message. g. The BS shall include both the A2p Bearer Session-Level Parameters IE and the A2p Bearer FormatSpecific Parameters IE or neither one. The following table shows the bitmap layout for the Assignment Complete message.
3.1.8 7 6 5 BSMAP Header: (reserved) ARFCN Low Part(LSB) 4 Assignment Complete 3 2 1 0 Octet 1 2 1 1 2 3 Message Discrimination = [00H] Message Type = [02H] ARFCN High Part (MSB)
36
Length Indicator (LI) = <variable> Channel Number: A1 Element Identifier = [23H]
B-15
3GPP2 A.S0008-C v2.0

3.1.8 7 6 5 4 Encryption Information: Assignment Complete 3 2 1 0 Octet 1 2 Status = [0,1] Available = [0,1] j A1 Element Identifier = [0AH]
Length = [02H,04H] Encryption Info {1..2: ext = [1] Encryption Parameter Identifier = [0 0001 (SME), 0 0100 (Private Longcode), 0 0101 (Datakey (ORYX)), 0 0110 (Initial RAND)] Encryption Parameter Length = [00H] } Encryption Info (MSB) Service Option: A1 Element Identifier = [03H] Service Option = [8000H (13K speech), 0011H (13K high rate voice service), 0003H (EVRC), 003EH (Wideband Speech Codec), 801FH (13K Markov), 0009H (13K Loopback), 0004H (Async Data Rate Set 1), 0005H (G3 Fax Rate Set 1), 000CH (Async Data Rate Set 2), 000DH (G3 Fax Rate Set 2), 0006H (SMS Rate Set 1), 000EH (SMS Rate Set 2), 0021H (3G High Speed Packet Data), 0012H (OTAPA Rate Set 1), 0013H (OTAPA Rate Set 2), 0025H (ISDN Interworking Service), 0020H (TDSO), 0036H (IS-2000 Markov), 0037H (IS-2000 Loopback), 0023H (PDS Rate Set 1), 0024H (PDS Rate Set 2), 0038H (SMV), 0039H (32 kbps Circuit Switched Video Conferencing), 003AH (64 kbps Circuit Switched Video Conferencing)] Length = [01H] Reserved = [0000 0] Service Option Connection Identifier = [001 - 110] (LSB)
j+1 1 2 3
Service Option Connection Identifier (SOCI): A1 Element Identifier = [1EH]
1 2 3 1 2
A2p Bearer Session-Level Parameters: A1p Element Identifier [45H] Length = <variable>
B-16
3GPP2 A.S0008-C v2.0

3.1.8 7 6 5 4 Reserved = [00] Assignment Complete 3 2 1 0 Session Addr Flag = [0,1] Octet 3 Session IP Address Type = [00 = IPv4]
Max Frames = [000 to 101]
(MSB)
Session IP Address = <any value>
(LSB) (MSB) Session UDP Port = <any value> (LSB) A2p Bearer Format-Specific Parameters: A1p Element Identifier = [46H] Length = <variable> Number of Bearer Formats = <variable> Bearer Format Parameters {1+: Bearer Format Length = <variable> Ext = [0,1] Bearer Format Tag Type = [001-100] Bearer Format ID = [0000 0111] Bearer Addr Flag= [0, 1] Bearer IP Address Type= [00 = IPv4]
j j+1 j+2 1 2 3
m m+1 m+2
RTP Payload Type = [00H = (PCMU), 08H = (PCMA), 0CH = (13K Vocoder), 60H - 7FH (dynamically assigned = EVRC), 60H - 7FH (dynamically assigned = EVRC0), 60H - 7FH (dynamically assigned = SMV), 60H - 7FH (dynamically assigned = SMV0), 60H - 7FH (dynamically assigned = telephone-event)] (MSB) Bearer IP Address = <any value>
(LSB) (MSB) Bearer UDP Port= <any value> (LSB) Extension Length = [0001] } Bearer Format Parameters
1
j j+1 j+2 k k+1
Extension ID = [0000]
Extension Parameters = <any value>
...
3.1.17 BS Service Request This BSMAP message is sent from the BS to the MSC to request a BS initiated mobile terminated call setup. This message is also used for mobile terminated SDB delivery. This message may also be used to notify the MSC that the AN/PCF has received data from the PDSN for a specific MS/AT.
2 3 4 5
B-17
3GPP2 A.S0008-C v2.0

Information Element Message Type Mobile Identity (IMSI) Mobile Identity (ESN) Service Option Tag ADDS User Part Service Reference Identifier (SR_ID) Mobile Identity (MEID)
1 2 3 4 5 6 7 8 9 10 11 12 13
Section Reference 4.2.4 4.2.13 4.2.13 4.2.49 4.2.46 4.2.50 4.2.86 4.2.13
Element Direction BS -> MSC BS -> MSC BS -> MSC BS -> MSC BS -> MSC BS -> MSC BS -> MSC BS -> MSC M M Oa O O O
b c d e
Type
C R C C C C
O O
a. This IE is included if the necessary information is available at the BS. This IE is included if the ESN is available at the BS. ESN containing a pseudo ESN is not required to be sent if the MEID is sent. b. This element indicates the service option requested by the BS. c. If this element is present in the message, the value shall be saved at the MSC to be included in a BS Service Response message. d. This element is included if this message is used for mobile terminated SDB delivery. The Application Data Message field is included and contains the SDB received from the PCF. For HRPD, this IE may be included if containing a data burst of type 7. Note: SO 003BH may be used to indicate that the request is for the main service option for HRPD packet data or AltPPP service. e. This element is passed to the MSC when the network reactivates a packet data service instance and the SR_ID is available at the BS. The element identifies the reactivated service instance. f. This IE is included if the MEID is available at the BS.
14
The following table shows the bitmap layout for the BS Service Request message.
3.1.17 7 6 5 4 BS Service Request 3 2 1 0 Octet 1 2 1 1 2 Type of Identity = [110] (IMSI) 3
BSMAP Header: Message Discrimination = [00H] Length Indicator (LI) = <variable> Message Type = [09H]
Mobile Identity (IMSI): A1 Element Identifier = [0DH] Length = [06H-08H] (10-15 digits) Odd/even Indicator = [1,0]
Identity Digit N+1 = [0H-9H] (BCD) = [1111] (if even number of digits), Identity Digit N+3 = [0H-9H] (BCD) (if odd number of digits) Length = [05H] Identity Digit N = [0H-9H] (BCD) Identity Digit N+2 = [0H-9H] (BCD)
n n+1
Mobile Identity (ESN): A1 Element Identifier = [0DH]
1 2
B-18
3GPP2 A.S0008-C v2.0

3.1.17 7 6 5 4 Identity Digit 1 = [0000] BS Service Request 3 Odd/even Indicator = [0] ESN = <any value> 2 1 Type of Identity = [101] (ESN) 0 Octet 3
(MSB)
4 5 6 (LSB) 7 1 2
(MSB)
Service Option: A1 Element Identifier = [03H]
Service Option = [00 21H (3G High Speed Packet Data] for 1x systems [00 3BH (HRPD Packet Data), 59 00H-59 FFH] for HRPD systems (LSB) Tag: A1 Element Identifier = [33H] Tag Value = <any value>
3 1 2 3 4
(MSB)
(LSB) Reserved ADDS User Part: A1 Element Identifier = [3DH] Length = <variable> Data Burst Type = [000110] (SDB), 000111 (HRPD Packet Data Service Notification)] Application Data Message = <any value>
5 1 2 3
(MSB)
(LSB) Service Reference Identifier (SR_ID): A1 Element Identifier = [71H] Length = [01H] SR_ID = [01H-1FH] Reserved = [0000 0] SR_ID = [001 110] Length = [08H] MEID Hex Digit 1 = [0H-FH] Odd/Even Indicator = 0 Type of Identity = [001] (MEID)
n 1 2 3 3 1 2 3
Mobile Identity (MEID): A1 Element Identifier = [0DH]
MEID Hex Digit 3 = [0H-FH] MEID Hex Digit 5 = [0H-FH] MEID Hex Digit 7 = [0H-FH] MEID Hex Digit 9 = [0H-FH] MEID Hex Digit 11 = [0H-FH] MEID Hex Digit 13 = [0H-FH]
4 5 6 7 8 9
B-19
3GPP2 A.S0008-C v2.0

3.1.17 7 6 5 Fill = [FH]
1
BS Service Request 3 2 1 0 Octet 10 MEID Hex Digit 14 = [0H-FH]
...
3.3.7 Location Updating Request This DTAP message is sent by the BS to the MSC to request an update to the MSs location area (registration) when the MS moves to a new location from its previous location.
Information Element Protocol Discriminator Reserved Octet Message Type Mobile Identity (IMSI) Classmark Information Type 2 Registration Type Mobile Identity (ESN) Slot Cycle Index Authentication Response Parameter (AUTHR) Authentication Confirmation Parameter (RANDC) Authentication Parameter COUNT Authentication Challenge Parameter (RAND) Authentication Event User Zone ID IS-2000 Mobile Capabilities Return Cause MS Designated Frequency Mobile Identity (MEID) Mobile Subscription Information Section Reference 4.2.31 4.2.32 4.2.4 4.2.13 4.2.12 4.2.45 4.2.13 4.2.14 4.2.36 4.2.33 4.2.37 4.2.35 4.2.61 4.2.26 4.2.53 4.2.83 4.2.88 4.2.13 4.2.91 Element Direction BS -> MSC BS -> MSC BS -> MSC BS -> MSC BS -> MSC BS -> MSC BS -> MSC BS -> MSC BS -> MSC BS -> MSC BS -> MSC BS -> MSC BS -> MSC BS -> MSC BS -> MSC BS -> MSC BS -> MSC BS -> MSC BS -> MSC Mi M M Ma, i, m Ob, i, k O O
i c d, l e
2 3 4
Type
R R C C C C C C C C C C C C C
O O O O O O O O
f o g h o j, l, p n l, rc c q
5 6 7 8 9 10 11 12 13 14 15 16 17
a. This element contains an IMSI. b. If an MS is capable of supporting multiple band classes, and this information is available at the BS, it shall be indicated in the Band Class Entry field as shown in section 4.2.12. c. This IE is present if the information is received from the MS. d. The slot cycle index is included when provided by the MS. e. This element contains the authentication response signature (AUTHR) received from an authentication capable MS when broadcast authentication is active. f. This element contains the RANDC received from the MS. RANDC shall be included whenever it is received from the MS and authentication is enabled.
g. This element is included when broadcast authentication is performed, and contains the random number (RAND) value used when the BS is responsible for RAND assignment and can correlate this parameter with the RAND used by the MS in its authentication computation. B-20
3GPP2 A.S0008-C v2.0

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24
h. This element is present when an authentication enabled BS does not receive the authentication parameters (AUTHR, RANDC and COUNT) from the MS, or when a RAND/RANDC mismatch has occurred. i. j. If any of these elements are not correctly present, call failure handling may be initiated by the MSC. This element is only included when the MS operates at revision level 6 or greater as defined by [1]~[6].
k. When the BS is operating in DS-41 mode, only the following fields in the Classmark Type 2 IE shall be considered valid by the MSC: MOB_P_REV, NAR_AN_CAP, Mobile Term, PSI (PACA Supported Indicator), SCM Length, Count of Band Class Entries, Band Class Entry Length, Band Class n, Band Class n Air Interfaces Supported, Band Class n MOB_P_REV. l. These elements shall not be included by the BS when the BS and MS are operating in DS-41 mode. m. Because this IE is sent as a mandatory IE in a DTAP message, the IE identifier is not included. n. This element is included if the MS re-sends the Registration Message with Return Cause to the BS because it failed to be redirected to the desired system. This IE shall not be included in HRPD messages. o. This IE is included if the necessary information was received from the MS. p. If the BS does not have the information required to correctly populate a field in this IE, it shall code the field to zero. q. If an MS is capable of supporting multiple band classes and at least one band class has band subclasses defined, the BS shall include the MSs band class and band subclass capabilities in this element as shown in section 4.2.91 if this information is available at the BS. When included, the band class and band subclass information in this IE shall take precedence over any band class information included in the Classmark Information Type 2 IE. r. This IE shall not be included in HRPD messages.
25
...
3.3.23 Event Notification In 1x systems, this message may be sent from the MSC to a BS to indicate that the BS should change the call processing for a particular mobile, before and SCCP link has been established between the MSC and the BS for the call. In HRPD systems, this BSMAP message is sent from the MSC to the AN to notify the HRPD AN about a 1x event associated with an AT which had requested Cross Notification Services.
Information Element Message Type Mobile Identity (IMSI) Event Section Reference 4.2.4 4.2.13 4.2.92 Element Direction MSC -> BS MSC -> BS MSC -> BS Type M M M
26 27 28 29 30
31
The following table shows the bitmap layout for the Event Notification message.
3.3.23 7 6 5 BSMAP Header: 4 Event Notification 3 2 1 0 Octet 1 2 1 1 Message Discrimination = [00H] Message Type = [04H]
Length Indicator (LI) = <variable> Mobile Identity (IMSI): A1 Element Identifier = [0DH]
B-21
3GPP2 A.S0008-C v2.0

3.3.23 7 6 5 4 Event Notification 3 Odd/even Indicator = [1,0] 2 1 Type of Identity = [110] (IMSI) 0 Octet 2 3
Length = [06H-08H] (10-15 digits) Identity Digit 1 = [0H-9H] (BCD)
Identity Digit N+1 = [0H-9H] (BCD) = [1111] (if even number of digits), Identity Digit N+3 = [0H-9H] (BCD) (if odd number of digits) Identity Digit N = [0H-9H] (BCD) Identity Digit N+2 = [0H-9H] (BCD)
n n+1
Event: A1 Element Identifier = [7EH] Length = [01H] Event Identifier = [ 01H (1x Registration) 02H (1x Power Down]
1 2 3
2 3 4
3.3.24 Event Notification Ack This message is sent from the BS to the MSC upon receipt of an Event Notification message.
Information Element Message Type Mobile Identity (IMSI) Section Reference 4.2.4 4.2.13 Element Direction BS -> MSC BS -> MSC Type M M
The following table shows the bitmap layout for the Event Notification Ack message.
3.3.24 7 6 5 4 BSMAP Header: Event Notification Ack 3 2 1 0 Octet 1 2 1 1 2 Type of Identity = [110] (IMSI) 3 Message Discrimination = [00H] Message Type = [06H]
Length Indicator (LI) = <variable> 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 N+1 = [0H-9H] (BCD) = [1111] (if even number of digits), Identity Digit N+3 = [0H-9H] (BCD) (if odd number of digits) Identity Digit N = [0H-9H] (BCD) Identity Digit N+2 = [0H-9H] (BCD)
n n+1
B-22
3GPP2 A.S0008-C v2.0

1
2 3
...
3.6.1 ADDS Page This BSMAP message is sent from the MSC to the BS to request delivery of an application data message on the paging channel.
Information Element Message Type Mobile Identity (IMSI/Broadcast Address) ADDS User Part Tag Cell Identifier List Slot Cycle Index IS-2000 Mobile Capabilities Protocol Revision MS Designated Frequency Mobile Subscription Information Section Reference 4.2.4 4.2.13 4.2.50 4.2.46 4.2.18 4.2.14 4.2.53 4.2.79 4.2.88 4.2.91 Element Direction MSC -> BS MSC -> BS MSC -> BS MSC -> BS MSC -> BS MSC -> BS MSC -> BS MSC -> BS MSC -> BS MSC -> BS M Ma Mb Oc O O O O O O
d e,f
4 5 6
Type
C C C C C C C
f, h g
f, i j
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
a. When sent to a 1x BS, tThis element contains an IMSI or Broadcast Address; when sent to an HRPD AN, this IE contains an IMSI. b. This element contains the application data information to be sent to the mobile user, encoded using the syntax appropriate for the current radio channel and service type. When this message is used to deliver an SDB to the MS, the Application Data Message field is included and contains the SDB. c. If this element is present in this message, the value shall be saved at the BS to be included if an ADDS Page Ack message is sent in response to this message. d. The cell identifiers indicate the cells and location areas in which the BS is to attempt delivery of the message. When the Cell Identifier IE is absent, the BS shall attempt delivery in all cells controlled by the BS. This IE may be ignored by the AN. e. This element is included when slotted paging is performed on cdma2000 paging channels. It is used by the BS to compute the correct paging channel slot on each paging channel. In cdma2000 systems, if this element is absent, then it is assumed that the MS is operating in non-slotted mode. Note: For SMS Broadcast, the presence or absence of this element does not indicate the slotted/non-slotted operating mode of the MS. This IE may be ignored by the AN. f. This element shall not be included when the BS and MS are operating in DS-41 mode. g. This element contains the MSs MOB_P_REV of the current band class and shall be included if the value is greater than or equal to 7. h. If the MSC does not have the information required to correctly populate a field in this IE, it shall code the field to zero. This IE may be ignored by the AN. i. j. This element is included when the MSC has the information available. If available at the MSC, the MSC shall include a Band Class/Band Subclass Record within this element to report the last known band class and band subclass (if applicable) as well as any other band classes and band subclasses supported by the MS. B-23
3GPP2 A.S0008-C v2.0
...
3.6.2 ADDS Page Ack This BSMAP message is sent from the BS to the MSC to indicate that the BS received a Layer 2 Ack from the MS indicating that the point-to-point application data message was successfully delivered, or that the BS received the ADDS Page message to send an SMS broadcast message, or that the ADDS message was too long for delivery on the Paging channel, or that an internal BS failure has occurred with respect to the ability to complete an ADDS Page activity.
Information Element Message Type Mobile Identity (IMSI/Broadcast Address) Tag Mobile Identity (ESN) Cause Cell Identifier Mobile Identity (MEID) Section Reference 4.2.4 4.2.13 4.2.46 4.2.13 4.2.16 4.2.17 4.2.13 Element Direction BS -> MSC BS -> MSC BS -> MSC BS -> MSC BS -> MSC BS -> MSC BS -> MSC M Ma Oe O O
b
2 3 4 5 6 7
Type
R C C C C
c d
O O
8 9 10 11 12 13 14 15 16 17 18 19 20
a. When sent to a 1x BS, tThis element contains an IMSI or Broadcast Address; when sent to an HRPD AN, this IE contains an IMSI. b. This IE is included if the ESN is available at the BS. ESN containing a pseudo ESN is not required to be sent if the MEID is sent. This IE shall not be included in HRPD messages.
c. This element is used to indicate an error situation. In particular, this element can be used to carry information to the MSC that the ADDS User Part element contained in the ADDS Page message is too long to be carried on the paging channel. d. This element identifies the cell where the air interface acknowledgement was received corresponding to the paging channel message sent as a result of an ADDS Page message. This element is not included for SMS Broadcast. This IE shall not be included in HRPD messages. e. This IE contains the same value received in the ADDS Page message. f. This IE is included if the MEID is available at the BS.
21 22
...
3.6.3 ADDS Transfer This BSMAP message is sent from the BS to the MSC whenever an application data message is received from the MS on the access channel. It is also sent from the BS to the MSC to transfer authentication parameters when an MS originates a Short Data Burst, requests CCPD mode, or requests alternate dormant mode handoff from the network.
Information Element Message Type Mobile Identity (IMSI) ADDS User Part Section Reference 4.2.4 4.2.13 4.2.50 Element Direction BS -> MSC BS -> MSC BS -> MSC M M Ma Type
23 24 25 26 27
B-24
3GPP2 A.S0008-C v2.0

Information Element Mobile Identity (ESN) Authentication Response Parameter AUTHR Authentication Confirmation Parameter RANDC Authentication Parameter COUNT Authentication Challenge Parameter RAND Authentication Event Cell Identifier CDMA Serving One Way Delay Authentication Data Tag Classmark Information Type 2 Slot Cycle Index Service Option User Zone ID IS-2000 Mobile Capabilities Mobile Identity (MEID) Mobile Subscription Information
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
Section Reference 4.2.13 4.2.36 4.2.33 4.2.37 4.2.35 4.2.61 4.2.17 4.2.57 4.2.62 4.2.46 4.2.12 4.2.14 4.2.49 4.2.26 4.2.53 4.2.13 4.2.91
Element Direction BS -> MSC BS -> MSC BS -> MSC BS -> MSC BS -> MSC BS -> MSC BS -> MSC BS -> MSC BS -> MSC BS -> MSC BS -> MSC BS -> MSC BS -> MSC BS -> MSC BS -> MSC BS -> MSC BS -> MSC Ob O
c d e
Type C C C C C C R C C C C C C C C C C
O O O
f g h i j k l, m,q l,n,o l,q l l,o,p,r s t
O O O O O O O O
a. This element contains the application data information that was received from the MS. When this message is used to transfer authentication parameters to the MSC after the BS has received a SDB or a request for CCPD mode from the MS, the Data Burst Type field is set to SDB (000110) and the Application Data Message field is not included. When this message is used to transfer authentication parameters to the MSC after the BS has received a request for alternate dormant mode handoff from the MS, the Data Burst Type field is set to Asynchronous Data Services (000001) and the Application Data Message field is not included. b. This IE is included if the ESN is available at the BS. ESN containing a pseudo ESN is not required to be sent if the MEID is sent. This IE shall not be included in HRPD messages. c. This element is included when broadcast authentication is performed and contains the Authentication Response Parameter, AUTHR, as computed by the MS. d. This element contains the RANDC received from the MS. RANDC shall be included whenever it is received from the MS and authentication is enabled. e. This element is included when broadcast authentication is performed and contains the MSs call history count for authentication operations. f. This element is included when broadcast authentication is performed and contains the random number (RAND) value used when the BS is responsible for RAND assignment and can correlate this parameter with the RAND used by the MS in its authentication computation.
g. This element is present when an authentication enabled BS does not receive the authentication parameters (AUTHR, RANDC and COUNT) from the MS, or when a RAND/RANDC mismatch has occurred. h. This element identifies the cell where the application data (e.g., SMS-MO) was received from the MS. Discriminator type 0000 0010 (Cell ID) may be used in the ADDS Transfer message. For more information, refer to section 4.2.17. In HRPD messages the cell identifier discriminator type shall be set to a valid value and the cell id may be set to any value. B-25
3GPP2 A.S0008-C v2.0

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
i. j.
This element is included if the data burst type is set to 05H (PDS), if applicable to the geo-location technology, and if this technology is supported at the base station. This element is included if the BS determines that authentication should be applied.
k. These elements are required when the ADDS user part element data burst type field is set to SDB for Short Data Burst or Asynchronous Data Services for dormant handoff, and shall be returned in the ADDS Transfer Ack message. This IE shall not be included in HRPD messages. l. This element is included if the message is triggered by an Origination Message from the MS. This IE shall not be included in HRPD messages.
m. When the BS is operating in DS-41 mode, only the following fields in the Classmark Type 2 IE shall be considered valid by the MSC: MOB_P_REV, NAR_AN_CAP, Mobile Term, PSI (PACA Supported Indicator), SCM Length, Count of Band Class Entries, Band Class Entry Length, Band Class n, Band Class n Air Interfaces Supported, Band Class n MS Protocol Level. n. This element applies only to MSs operating in slotted mode (discontinuous reception). It contains an index value used in paging channel slot computation. The Slot Cycle Index shall be stored by the MSC, and returned to the BS for call termination to the MS to ensure that the Paging Message is broadcast in the paging channel slots monitored by the MS. o. These elements shall not be included by the BS when the BS and MS are operating in DS-41 mode. p. This element is only included when the MS operates at revision level 6 or greater as defined by [1]~[6]. q. If any of these elements are not correctly present in case of dormant handoff, failure handling may be initiated by the MSC. r. s. t. If the BS does not have the information required to correctly populate a field in this IE, it shall code the field to zero. This IE is included if the MEID is available at the BS. If an MS is capable of multiple band classes and at least one band class has band subclasses defined, the BS shall include the MSs band class and band subclass capabilities in this element as shown in section 4.2.91 if this information is available at the BS. When included, the band class and band subclass information in this IE shall take precedence over any band class information included in the Classmark Information Type 2 IE.
30
...
3.6.5 ADDS Deliver This DTAP message is sent from the MSC to the BS to request delivery of an application data message to an MS on a traffic channel. This message can also be sent from the BS to the MSC to deliver an application data message received on the traffic channel.
Information Element Protocol Discriminator Reserved Octet Message Type ADDS User Part Tag CDMA Serving One Way Delay Section Reference 4.2.31 4.2.32 4.2.4 4.2.50 4.2.46 4.2.57 Element Direction MSC <-> BS MSC <-> BS MSC <-> BS MSC <-> BS MSC -> BS BS->MSC O M M M Ma,d Ob
c
31 32 33 34
Type
C C
35 36
a. This element contains the application data information that was received from or is to be delivered to the MS. This element may contain an SDB in the MSC-to-BS direction only. When this message is B-26
3GPP2 A.S0008-C v2.0

1 2 3 4 5 6 7 8
used to deliver an SDB to the MS, the Application Data Message field is included and contains the SDB. This IE may also be included in a 1x system for notifying an MS/AT about data awaiting delivery on the HRPD system. b. If this element is used in this message, it shall be returned to the MSC in the ADDS Deliver Ack. c. This element is included if the Data Burst Type field of the ADDS User Part IE is set to 000101 (PDS), if applicable to the geo-location technology, and if this technology is supported at the base station. d. Because this IE is sent as a mandatory IE in a DTAP message, the IE identifier is not included. The following table shows the bitmap layout for the ADDS Deliver message.
3.6.5 7 6 5 4 ADDS Deliver 3 2 1 0 Octet 1 2 3 1 1 1 1 2
DTAP Header: Message Discrimination = [01H] Data Link Connection Identifier (DLCI) = [00H] Length Indicator (LI) = <variable>
Reserved = [0000] Reserved = [00]
Protocol Discriminator = [0011]
Reserved Octet = [00H] Message Type = [53H] Length = <variable>
ADDS User Part:
Data Burst Type = [[000011] (SMS), [000100] (OTASP), [000101] (PDS), [000110] (SDB), [000111] (HRPD Packet Data Service Notification)] Application Data Message = <any value>
(MSB)
(LSB) (MSB) Tag: A1 Element Identifier = [33H] Tag Value = <any value>
n 1 2 3 4 (LSB) 5 1 2 3 j (LSB) j+1 j j+1 (LSB) j+2
CDMA Serving One Way Delay: A1 Element Identifier = [0CH] Length = [08H, 0BH] Cell Identification Discriminator = [02H,07H]
IF (Discriminator = 02H), Cell Identification {1: (MSB) Cell = [001H-FFFH] Sector = [0H-FH] (0H = Omni) } OR IF (Discriminator = 07H), Cell Identification {1: (MSB) MSCID = <any value>
B-27
3GPP2 A.S0008-C v2.0

3.6.5 7 (MSB) } Cell Identification (MSB) CDMA Serving One Way Delay = [0000H-FFFFH] (LSB) Reserved = [0000 00] (MSB) Resolution = [00, 01, 10] (LSB)
1
ADDS Deliver 3 2 1 0 (LSB) Octet j+3 j+4 k k+1 k+2 k+3 k+4
Cell = [001H-FFFH] Sector = [0H-FH] (0H = Omni)
CDMA Serving One Way Delay Time Stamp = [00 00H FF FFH]
...
3.7.1 Rejection In 1x system, tThe Rejection message is used by the BS to indicate to the MSC that the MS has indicated rejection of a command/message. In HRPD systems, the Rejection message is used by the IWS-AN to indicate to the MSC that the MS/AT has indicated rejection of an incoming call, or by the MSC to indicate to the IWS-AN that a 1x data burst of type 7 has received a negative response from the MS/AT. This is coded as a BSMAP message when triggered by a Mobile Station Reject Order on the access channel and a DTAP message otherwise. This message shall not be used in DS-41 systems. Information Element Protocol Discriminator Reserved Octet Message Type Mobile Identity (IMSI) Mobile Identity (ESN) IS-2000 Cause Value Service Option Connection Identifier (SOCI) Mobile Identity (MEID) Cause Section Reference 4.2.31 4.2.32 4.2.4 4.2.13 4.2.13 4.2.60 4.2.73 4.2.13 4.2.16 Element Direction BS <-> MSC BS <-> MSC BS <-> MSC BS <-> MSC BS <-> MSC BS <-> MSC BS <-> MSC BS <-> MSC BS <-> MSC Type Ma Ma M Ob O O O O O
c d e f g
2 3 4 5 6 7 8 9
R C R C C C
10 11 12 13 14 15 16 17 18
a. These elements are not used in BSMAP messages and shall be included in a DTAP message. b. This element is not used in DTAP messages and shall be included in a BSMAP message. c. This IE is included if the ESN is available at the BS. ESN containing a pseudo ESN is not required to be sent if the MEID is sent. d. This element contains the cause indication sent by the MS in a Mobile Station Reject Order. This IE shall not be included in HRPD messages. e. This element is required if concurrent services are supported. This is only included when the message is sent as DTAP. f. This IE is included if the MEID is available at the BS.
B-28
3GPP2 A.S0008-C v2.0

1 2 3 4
g. This IE is included in HRPD messages when the MS/AT sends a Release Order to the HRPD AN indicating that the user has chosen not to accept the call. When the Rejection message is sent as a BSMAP message, the following format applies.
3.7.1 7 6 5 BSMAP Header: 4 Rejection 3 2 1 0 Octet 1 2 1 1 2 Type of Identity = [110] (IMSI) 3
Message Discrimination = [00H] Message Type = [56H]
Length Indicator (LI) = [06H, 09H] 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 N+1 = [0H-9H] (BCD) = [1111] (if even number of digits), Identity Digit N+3 = [0H-9H] (BCD) (if odd number of digits) Identity Digit N = [0H-9H] (BCD) Identity Digit N+2 = [0H-9H] (BCD)
4 n n+1
Mobile Identity (ESN): A1 Element Identifier = [0DH] Length = [05H] Odd/even Indicator = [0] ESN = <any value> Type of Identity = [101] (ESN)
1 2 3
Identity Digit 1 = [0000]
(MSB)
4 5 6 (LSB) 7 1 2 3 1 2 Type of Identity = [001] (MEID) 3
IS-2000 Cause Value:
Length = [01H] IS-2000 Cause Information = <any value> Mobile Identity (MEID): A7 Element Identifier = [0DH] Length = [08H] MEID Hex Digit 1 = [0H-FH] Odd/Even Indicator = 0
4 5 6 7 8 9
B-29
3GPP2 A.S0008-C v2.0

3.7.1 7 6 ext = [0] 5 Fill = [FH] Length = [01H] Cause Value = [1FH (1x service rejected)] 4 Rejection 3 2 1 0 Octet 10 1 2 3 MEID Hex Digit 14 = [0H-FH] Cause: A1 Element Identifier = [04H]
When the Rejection message is sent as a DTAP message, the following format applies.
3.7.1 7 6 5 4 Rejection 3 2 1 0 Octet 1 2 3 1 1 1 1 2 3 1 2 Service Option Connection Identifier = [001 - 110] Length = [01H] ext = [0] Cause Value = [1FH (1x service rejected)] 3 1 2 3
DTAP Header: Message Discrimination = [01H] Data Link Connection Identifier (DLCI) = [00H] Length Indicator (LI) = [06H]
Reserved = [0000]
Protocol Discriminator = [0011]
Reserved Octet = [00H] Message Type = [56H] A1 Element Identifier = [62H] Length = [01H]
IS-2000 Cause Value:
IS-2000 Cause Information = <any value> Service Option Connection Identifier (SOCI): A1 Element Identifier = [1EH] Length = [01H] Reserved = [0000 0]
Cause: A1 Element Identifier = [04H]
3 4
...
4.1.2 Information Element Identifiers
5 6 7 8 9 10
The following table contains a list of all IEs that make up the messages defined in section 3.0. The table is sorted by the IE Identifier (IEI) coding which distinguishes one IE from another. The table also includes a reference to the section where the element coding can be found. A listing of IEs, sorted by name, is included in Table 4.1.5-1, which also specifies the messages in which each IE is used.
B-30
3GPP2 A.S0008-C v2.0 Table 4.1.2-1

Element Name (unused available element identifier values) Page Indicator Anchor P-P Address Mobile Subscription Information Event (unused available element identifier values) Type 1 Information Elements
1
A1 Information Element Identifiers Sorted by Identifier Value

IEI (Hex) 74H 7AH 7BH 7CH 7DH 7EH 7FH 4.2.93 4.2.80 4.2.91 4.2.92 Reference .
...
4.1.5 Cross Reference of Information Elements With Messages The following table provides a cross reference between the IEs defined in this specification and the messages defined herein.
4.1.5 Information Element A2p Bearer Session-Level Parameters Cross Reference of Information Elements With Messages Reference 4.2.89 IEI 45H Used in These Messages Additional Service Request Assignment Complete Assignment Request Bearer Update Request Bearer Update Required Bearer Update Response CM Service Request Handoff Request Handoff Request Acknowledge Paging Response A2p Bearer Format-Specific Parameters 4.2.90 46H Additional Service Notification Additional Service Request Assignment Complete Assignment Request Bearer Update Request Bearer Update Required Bearer Update Response CM Service Request Handoff Request Reference 3.1.20 3.1.8 3.1.7 3.1.21 3.1.23 3.1.22 3.1.2 3.4.2 3.4.3 3.1.5 3.1.19 3.1.20 3.1.8 3.1.7 3.1.21 3.1.23 3.1.22 3.1.2 3.4.2
2 3 4
B-31
3GPP2 A.S0008-C v2.0

4.1.5 Information Element Cross Reference of Information Elements With Messages Reference IEI Used in These Messages Handoff Request Acknowledge Paging Request Paging Response Access Network Identifiers ADDS User Part 4.2.70 4.2.50 20H Handoff Request Handoff Required 3DH ADDS Deliver ADDS Page ADDS Transfer BS Service Request AMPS Hard Handoff Parameters Anchor PDSN Address Anchor P-P Address Authentication Challenge Parameter (RAND/RANDU/RANDBS/RANDS SD) 4.2.75 4.2.78 4.2.80 4.2.35 25H 30H Handoff Command Handoff Request Handoff Required 7CH Handoff Request Handoff Required 41H ADDS Transfer Authentication Request Base Station Challenge CM Service Request Location Updating Request PACA Update Paging Response SSD Update Request Authentication Confirmation Parameter (RANDC) 4.2.33 28H ADDS Transfer CM Service Request Location Updating Request PACA Update Paging Response Authentication Data Authentication Event 4.2.62 4.2.61 59H ADDS Transfer CM Service Request 4AH ADDS Transfer CM Service Request Location Updating Request PACA Update Paging Response Authentication Parameter COUNT 4.2.37 40H ADDS Transfer CM Service Request Location Updating Request PACA Update Reference 3.4.3 3.1.4 3.1.5 3.4.2 3.4.1 3.6.5 3.6.1 3.6.3 3.1.17 3.4.4 3.4.2 3.4.1 3.4.2 3.4.1 3.6.3 3.3.1 3.3.5 3.1.2 3.3.7 3.2.7 3.1.5 3.3.3 3.6.3 3.1.2 3.3.7 3.2.7 3.1.5 3.6.3 3.1.2 3.6.3 3.1.2 3.3.7 3.2.7 3.1.5 3.6.3 3.1.2 3.3.7 3.2.7
B-32
3GPP2 A.S0008-C v2.0

4.1.5 Information Element Authentication Response Parameter (AUTHR/AUTHU/AUTHBS) Cross Reference of Information Elements With Messages Reference 4.2.36 IEI 42H Used in These Messages Paging Response ADDS Transfer Authentication Response Base Station Response CM Service Request Location Updating Request PACA Update Paging Response Band Class Called Party ASCII Number 4.2.76 4.2.59 37H Handoff Off p Performed CM Service Request CM Service Request Continuation Called Party BCD Number 4.2.40 5EH Additional Service Request CM Service Request 5BH Additional Service Request Reference 3.1.5 3.6.3 3.3.2 Challenge 3.3.6 3.1.2 3.3.7 3.2.7 3.1.5 3.4.9 3.1.20 3.1.2 3.1.3 3.1.20 3.1.2
CM Service Request Contin- 3.1.3 uation Flash with Information Cause 4.2.16 04H ADDS Deliver Ack ADDS Page Ack ADDS Transfer Ack Assignment Failure Bearer Update Response Bearer Update Required Block BS Service Response Clear Command Clear Request Handoff Command Handoff Failure Handoff Performed Handoff Request Acknowledge Handoff Required Handoff Required Reject Location Updating Accept PACA Command Ack PACA Update Ack Radio Measurements for Position Response Rejection 3.2.1 3.6.6 3.6.2 3.6.4 3.1.9 3.1.22 3.1.23 3.5.1 3.1.18 3.1.14 3.1.13 3.4.4 3.4.8 3.4.9 3.4.3 3.4.1 3.4.7 3.3.8 3.2.6 3.2.8 3.2.10 3.7.1
B-33
3GPP2 A.S0008-C v2.0

4.1.5 Information Element Cross Reference of Information Elements With Messages Reference IEI Used in These Messages Reset Reset Circuit Service Release Transcoder Control Acknowledge Cause Layer 3 4.2.42 08H Clear Command Clear Request Service Release SSD Update Response CDMA Serving One Way Delay 4.2.57 0CH ADDS Deliver ADDS Transfer CM Service Request Handoff Request Handoff Required Paging Response Radio Measurements for Position Response Cell Identifier 4.2.17 05H ADDS Page Ack ADDS Transfer Cell Identifier List 4.2.18 1AH ADDS Page Authentication Request Feature Notification Handoff Command Handoff Performed Handoff Request Handoff Request Acknowledge Handoff Required Paging Request Registration Request Status Request User Zone Reject Channel Number Channel Type Circuit Group 4.2.5 4.2.6 4.2.66 23H Assignment Complete Handoff Performed 0BH Assignment Request Handoff Request 19H Block Reset Circuit Unblock Circuit Identity Code 4.2.19 01H Additional Service Request Reference 3.5.7 3.5.5 3.1.11 3.5.10 3.1.14 3.1.13 3.1.11 3.3.4 3.6.5 3.6.3 3.1.2 3.4.2 3.4.1 3.1.5 3.2.10 3.6.2 3.6.3 3.6.1 3.3.1 3.2.3 3.4.4 3.4.9 3.4.2 3.4.3 3.4.1 3.1.4 3.3.19 3.3.14 3.3.18 3.1.8 43.4.9 3.1.7 3.4.2 3.5.1 3.5.5 3.5.3 3.1.20
Complete Layer 3 Information 3.1.1
B-34
3GPP2 A.S0008-C v2.0

4.1.5 Information Element Cross Reference of Information Elements With Messages Reference IEI Used in These Messages Assignment Request Block Block Acknowledge CM Service Request Paging Response Reset Circuit Reset Circuit Acknowledge Unblock Unblock Acknowledge Circuit Identity Code Extension Classmark Information Type 2 4.2.20 4.2.12 24H 12H Handoff Request ADDS Transfer CM Service Request Handoff Request Handoff Required Location Updating Request Paging Response CM Service Type Data Link Connection Identifier (DLCI) 4.2.39 4.2.2 9XH none
a
Reference 3.1.7 3.5.1 3.5.2 3.1.2 3.1.5 3.5.5 3.5.6 3.5.3 3.5.4 3.4.2 3.6.3 3.1.2 3.4.2 3.4.1 3.3.7 3.1.5 3.1.2 3.1.20 3.6.5 3.6.6 3.1.16 3.3.1 3.3.2 3.3.5 3.3.6 3.1.10 3.2.1 3.2.2 3.3.8 3.3.9 3.3.11 3.3.10 3.1.6 3.7.1 3.8.1 3.1.11 3.1.12 3.3.3 3.3.4
CM Service Request Additional Service Request ADDS Deliver ADDS Deliver Ack Alert with Information Authentication Request Authentication Response Base Station Challenge Base Station Challenge Response Connect Flash with Information Flash with Information Ack Location Updating Accept Location Updating Reject Parameter Update Confirm Parameter Update Request Progress Rejection Service Redirection Service Release Service Release Complete SSD Update Request SSD Update Response
B-35
3GPP2 A.S0008-C v2.0

4.1.5 Information Element Cross Reference of Information Elements With Messages Reference IEI Used in These Messages Status Request Status Response User Zone Reject User Zone Update User Zone Update Request Downlink Radio Environment Downlink Radio Environment List Encryption Information 4.2.22 4.2.65 4.2.10 29H Handoff Request Handoff Required 2BH Radio Measurements for Position Response 0AH Assignment Complete Assignment Request Handoff Request Handoff Required Privacy Mode Command Privacy Mode Complete Event Extended Handoff Direction Parameters 4.2.92 4.2.56 7EH Event Notification 10H Handoff Command Handoff Request Acknowledge Geographic Location Handoff Power Level Hard Handoff Parameters 4.2.64 4.2.25 4.2.47 2CH Radio Measurements for Position Response 26H 16H Handoff Command Handoff Command Handoff Request Acknowledge Information Record Requested IS-2000 Cause Value IS-2000 Channel Identity 4.2.77 4.2.60 4.2.27 2EH Status Request 62H 09H Rejection Handoff Command Handoff Request Handoff Request Acknowledge Handoff Required IS-2000 Channel Identity 3X 4.2.23 27H Handoff Command Handoff Request Handoff Request Acknowledge Handoff Required IS-2000 Mobile Capabilities 4.2.53 11H ADDS Page ADDS Transfer Authentication Request CM Service Request Reference 3.3.14 3.3.15 3.3.18 3.3.17 3.3.16 3.4.2 3.4.1 3.2.10 3.1.8 3.1.7 3.4.2 3.4.1 3.3.12 3.3.13 3.3.23 3.4.4 3.4.3 3.2.10 3.4.4 3.4.4 3.4.3 3.3.14 3.7.1 3.4.4 3.4.2 3.4.3 3.4.1 3.4.4 3.4.2 3.4.3 3.4.1 3.6.1 3.6.3 3.3.1 3.1.2
B-36
3GPP2 A.S0008-C v2.0

4.1.5 Information Element Cross Reference of Information Elements With Messages Reference IEI Used in These Messages Feature Notification Handoff Request Handoff Required Location Updating Request Paging Request Paging Response Registration Request Status Request User Zone Reject IS-2000 Non-Negotiable Service Configuration Record 4.2.52 0FH Handoff Command Handoff Request Handoff Request Acknowledge Handoff Required IS-2000 Redirection Record IS-2000 Service Configuration Record 4.2.82 4.2.51 67H Service Redirection 0EH Handoff Command Handoff Request Handoff Request Acknowledge Handoff Required IS-95 Channel Identity 4.2.9 22H Handoff Command Handoff Request Handoff Request Acknowledge Handoff Required Layer 3 Information Message Type 4.2.30 4.2.4 17H none
b
Reference 3.2.3 3.4.2 3.4.1 3.3.7 3.1.4 3.1.5 3.3.19 3.3.14 3.3.18 3.4.4 3.4.2 3.4.3 3.4.1 3.8.1 3.4.4 3.4.2 3.4.3 3.4.1 3.4.45 3.4.2 3.4.3 3.4.1 3.1.19 3.1.20 3.6.5 3.6.6 3.6.1 3.6.2 3.6.3 3.6.4 3.1.16 3.1.8 3.1.9 3.1.7 3.3.1
Complete Layer 3 Information 3.1.1 Additional Service Notification Additional Service Request ADDS Deliver ADDS Deliver Ack ADDS Page ADDS Page Ack ADDS Transfer ADDS Transfer Ack Alert with Information Assignment Complete Assignment Failure Assignment Request Authentication Request
B-37
3GPP2 A.S0008-C v2.0

4.1.5 Information Element Cross Reference of Information Elements With Messages Reference IEI Used in These Messages Authentication Response Base Station Challenge Base Station Challenge Response Block Block Acknowledge BS Authentication Request BS Authentication Request Ack BS Service Request BS Service Response Clear Command Clear Complete Clear Request CM Service Request CM Service Request Continuation Connect Event Notification Event Notification Ack Feature Notification Feature Notification Ack Flash with Information Flash with Information Ack Handoff Command Handoff Commenced Handoff Complete Handoff Failure Handoff Performed Handoff Request Handoff Request Acknowledge Handoff Required Handoff Required Reject Location Updating Accept Location Updating Reject Location Updating Request PACA Command PACA Command Ack PACA Update Reference 3.3.2 3.3.5 3.3.6 3.5.1 3.5.2 3.3.21 3.3.22 3.1.17 3.1.18 3.1.14 3.1.15 3.1.13 3.1.2 3.1.3
Complete Layer 3 Information 3.1.1 3.1.10 3.3.23 3.3.24 3.2.3 3.2.4 3.2.1 3.2.2 3.4.4 3.4.5 3.4.6 3.4.8 3.4.9 3.4.2 3.4.3 3.4.1 3.4.7 3.3.8 3.3.9 3.3.7 3.2.5 3.2.6 3.2.7
B-38
3GPP2 A.S0008-C v2.0

4.1.5 Information Element Cross Reference of Information Elements With Messages Reference IEI Used in These Messages PACA Update Ack Paging Request Paging Response Parameter Update Confirm Parameter Update Request Privacy Mode Command Privacy Mode Complete Progress Radio Measurements for Position Request Radio Measurements for Position Response Registration Request Rejection Reset Reset Acknowledge Reset Circuit Reset Circuit Acknowledge Service Redirection Service Release Service Release Complete SSD Update Request SSD Update Response Status Request Status Response Transcoder Control Acknowledge Transcoder Control Request Unblock Unblock Acknowledge User Zone Reject User Zone Update User Zone Update Request Mobile Identity 4.2.13 0DH Additional Service Notification ADDS Page ADDS Page Ack ADDS Transfer ADDS Transfer Ack Authentication Request Authentication Response Reference 3.2.8 3.1.4 3.1.5 3.3.11 3.3.10 3.3.12 3.3.13 3.1.6 3.2.9 3.2.10 3.3.19 3.7.1 3.5.7 3.5.8 3.5.5 3.5.6 3.8.1 3.1.11 3.1.12 3.3.3 3.3.4 3.3.14 3.3.15 3.5.109 3.5.98 3.5.3 3.5.4 3.3.18 3.3.17 3.3.16 3.1.19 3.6.1 3.6.2 3.6.3 3.6.4 3.3.1 3.3.2
B-39
3GPP2 A.S0008-C v2.0

4.1.5 Information Element Cross Reference of Information Elements With Messages Reference IEI Used in These Messages BS Authentication Request BS Authentication Request Ack BS Service Request BS Service Response CM Service Request Event Notification Event Notification Ack Feature Notification Feature Notification Ack Handoff Request Handoff Required Location Updating Request PACA Update PACA Update Ack Paging Request Paging Response Registration Request Rejection Service Redirection Status Request Status Response User Zone Reject MS Designated Frequency 4.2.88 73H ADDS Page Authentication Request Feature Notification Location Updating Request Paging Request PACA Update Location Updating Accept Location Updating Reject Registration Request Status Request User Zone Reject MS Information Records 4.2.55 15H Alert with Information Assignment Request CM Service Request Continuation Feature Notification Flash With Information Paging Request Reference 3.3.21 3.3.22 3.1.17 3.1.18 3.1.2 3.3.23 3.3.24 3.2.3 3.2.4 3.4.2 3.4.1 3.3.7 3.2.7 3.2.8 3.1.4 3.1.5 3.3.19 3.7.1 3.8.1 3.3.14 3.3.15 3.3.18 3.6.1 3.3.1 3.2.3 3.3.8 3.1.4 3.2.7 3.3.8 3.3.9 3.3.19 3.3.14 3.3.18 3.1.16 3.1.7 3.1.3 3.2.3 3.2.1 3.1.4
B-40
3GPP2 A.S0008-C v2.0

4.1.5 Information Element Cross Reference of Information Elements With Messages Reference IEI Used in These Messages Progress Status Response MS Measured Channel Identity Origination Continuation Indicator PACA Order PACA Reorigination Indicator PACA Timestamp Packet Session Parameters Page Indicator Power Down Indicator Priority 4.2.29 4.2.81 4.2.68 4.2.69 4.2.67 4.2.85 4.2.93 4.2.44 4.2.15 64H Handoff Request Handoff Required A0H CM Service Request 5FH 60H PACA Update CM Service Request PACA Command 70H Handoff Request Handoff Required 7BH Paging Request A2H Clear Complete 06H Assignment Request PACA Command PACA Update PACA Update Ack Protocol Discriminator 4.2.31 none
b
Reference 3.1.6 3.3.15 3.4.2 3.4.1 3.1.2 3.2.7 3.1.2 3.1.7 3.2.5 3.4.2 3.4.1 3.1.4 3.1.15 3.1.7 3.2.5 3.2.7 3.2.8 3.1.20 3.6.5 3.6.6 3.1.16 3.3.1 3.3.2 3.3.5 3.3.6 3.1.2 3.1.3 3.1.10 3.2.1 3.2.2 3.3.8 3.3.9 3.3.7 3.1.5 3.3.11 3.3.10 3.1.6 3.7.1 3.8.1
4EH Assignment Request
Additional Service Request ADDS Deliver ADDS Deliver Ack Alert with Information Authentication Request Authentication Response Base Station Challenge Base Station Challenge Response CM Service Request CM Service Request Continuation Connect Flash with Information Flash with Information Ack Location Updating Accept Location Updating Reject Location Updating Request Paging Response Parameter Update Confirm Parameter Update Request Progress Rejection Service Redirection
B-41
3GPP2 A.S0008-C v2.0

4.1.5 Information Element Cross Reference of Information Elements With Messages Reference IEI Used in These Messages Service Release Service Release Complete SSD Update Request SSD Update Response Status Request Status Response User Zone Reject User Zone Update User Zone Update Request Protocol Revision 4.2.79 3BH ADDS Page Authentication Request Feature Notification Location Updating Accept Location Updating Reject Paging Request Registration Request Service Redirection Status Request User Zone Reject Protocol Type PSMM Count Public Long Code Mask Identifier 4.2.54 4.2.63 4.2.87 18H Handoff Request Handoff Required 2DH Radio Measurements for Position Request 72H Handoff Required Handoff Request Handoff Request Acknowledge Handoff Command Quality of Service Parameters 4.2.41 07H Assignment Request Handoff Request Handoff Required Radio Environment and Resources Registration Type Reject Cause Reserved Octet 4.2.58 4.2.45 4.2.34 4.2.32 1DH CM Service Request Paging Response 1FH 44H none
b
Reference 3.1.11 3.1.12 3.3.3 3.3.4 3.3.14 3.3.15 3.3.18 3.3.17 3.3.16 3.6.1 3.3.1 3.2.3 3.3.8 3.3.9 3.1.4 3.3.19 3.8.1 3.3.14 3.3.18 3.4.2 3.4.1 3.2.9 3.4.1 3.4.2 3.4.3 3.4.4 3.1.7 3.4.2 3.4.1 3.1.2 3.1.5 3.3.7 3.3.9 3.1.20 3.6.5 3.6.6 3.1.16 3.3.1 3.3.2
Location Updating Request Location Updating Reject Additional Service Request ADDS Deliver ADDS Deliver Ack Alert with Information Authentication Request Authentication Response
B-42
3GPP2 A.S0008-C v2.0

4.1.5 Information Element Cross Reference of Information Elements With Messages Reference IEI Used in These Messages Base Station Challenge Base Station Challenge Response CM Service Request CM Service Request Continuation Connect Flash with Information Flash with Information Ack Location Updating Accept Location Updating Reject Location Updating Request Paging Response Parameter Update Confirm Parameter Update Request Progress Rejection Service Redirection Service Release Service Release Complete SSD Update Request SSD Update Response Status Request Status Response User Zone Reject User Zone Update User Zone Update Request Response Request Return Cause RF Channel Identity Service Option 4.2.28 4.2.83 4.2.7 4.2.49 1BH Handoff Required 68H 21H 03H CM Service Request Location Updating Request Handoff Command Additional Service Notification Additional Service Request ADDS Transfer Assignment Complete Assignment Request BS Service Request CM Service Request Handoff Complete Handoff Request Reference 3.3.5 3.3.6 3.1.2 3.1.3 3.1.10 3.2.1 3.2.2 3.3.8 3.3.9 3.3.7 3.1.5 3.3.11 3.3.10 3.1.6 3.7.1 3.8.1 3.1.11 3.1.12 3.3.3 3.3.4 3.3.14 3.3.15 3.3.18 3.3.17 3.3.16 3.4.1 3.1.2 3.3.7 3.4.4 3.1.19 3.1.20 3.6.3 3.1.8 3.1.7 3.1.17 3.1.2 3.4.6 3.4.2
B-43
3GPP2 A.S0008-C v2.0

4.1.5 Information Element Cross Reference of Information Elements With Messages Reference IEI Used in These Messages Handoff Required Paging Request Paging Response Service Option Connection Identifier 4.2.73 (SOCI) 1EH Additional Service Request Alert with Information Assignment Complete Assignment Failure Assignment Request CM Service Request Connect Flash with Information Flash with Information Ack Paging Response Progress Rejection Service Release Service Release Complete Service Option List 4.2.74 2AH Handoff Command Handoff Request Handoff Request Acknowledge Handoff Required Service Redirection Info 4.2.84 69H 71H 32H 34H Service Redirection Assignment Request BS Service Request SID Signal 4.2.8 4.2.38 Handoff Command Assignment Request Feature Notification Flash with Information Progress Slot Cycle Index 4.2.14 35H ADDS Page ADDS Transfer Authentication Request CM Service Request Feature Notification Handoff Request Handoff Required Location Updating Request Paging Request Paging Response Service Reference Identifier (SR_ID) 4.2.86 Reference 3.4.1 3.1.4 3.1.5 3.1.20 3.1.16 3.1.8 3.1.9 3.1.7 3.1.2 3.1.10 3.2.1 3.2.2 3.1.5 3.1.6 3.7.1 3.1.11 3.1.12 3.4.45 3.4.2 3.4.3 3.4.1 3.8.1 3.1.7 3.1.17 3.4.4 3.1.7 3.2.3 3.2.1 3.1.6 3.6.1 3.6.3 3.3.1 3.1.2 3.2.3 3.4.2 3.4.1 3.3.7 3.1.4 3.1.5
B-44
3GPP2 A.S0008-C v2.0

4.1.5 Information Element Cross Reference of Information Elements With Messages Reference IEI Used in These Messages Registration Request Status Request User Zone Reject Software Version Source PDSN Address Source RNC to Target RNC Transparent Container Special Service Call Indicator Tag 4.2.48 4.2.24 4.2.71 31H 14H 39H Reset Reset Acknowledge Handoff Request Handoff Required Handoff Request Handoff Required 4.2.21 4.2.46 5AH Additional Service Request CM Service Request 33H ADDS Deliver ADDS Deliver Ack ADDS Page ADDS Page Ack ADDS Transfer ADDS Transfer Ack Authentication Request Authentication Response BS Service Request BS Service Response Feature Notification Feature Notification Ack Flash with Information Flash with Information Ack Paging Request Paging Response Target RNC to Source RNC Transparent Container 4.2.72 3AH Handoff Command Handoff Request Acknowledge Transcoder Mode User Zone ID 4.2.43 4.2.26 36H 02H Transcoder Control Request ADDS Transfer CM Service Request Paging Response Location Updating Request User Zone Reject User Zone Update User Zone Update Request Voice Privacy Request 4.2.11 A1H Additional Service Request Reference 3.3.19 3.3.14 3.3.18 3.5.7 3.5.8 3.4.2 3.4.1 3.4.2 3.4.1 3.1.20 3.1.2 3.6.5 3.6.6 3.6.1 3.6.2 3.6.3 3.6.4 3.3.1 3.3.2 3.1.17 3.1.18 3.2.3 3.2.4 3.2.1 3.2.2 3.1.4 3.1.5 3.4.4 3.4.3 3.5.9 3.6.3 3.1.2 3.1.5 3.3.7 3.3.18 3.3.17 3.3.16 3.1.20
B-45
3GPP2 A.S0008-C v2.0

4.1.5 Information Element Cross Reference of Information Elements With Messages Reference IEI Used in These Messages CM Service Request Paging Response Privacy Mode Complete
1 2
Reference 3.1.2 3.1.5 3.3.13
a. This is a type 1 IE (refer to section 4.1.3). The X in the IEI column is data. b. This is a type 3 IE (refer to section 4.1.3) that is contained as a mandatory IE in a DTAP message.
...
4.2.4 Message Type
4.2.4 7 6 5 4 Message Type 3 2 1 0 Octet 1
4 5
The Message Type is used to identify a message. IE Format:
Message Type
6 7 8 9 10
Message Type: This octet is coded as shown in Table 4.2.4-1. BSMAP messages are used to perform functions at the MSC or BS while DTAP messages carry information primarily used by the MS. For details, refer to [12].
Table 4.2.4-1
BSMAP Message Name Additional Service Notification ADDS Page ADDS Page Ack ADDS Transfer ADDS Transfer Ack Assignment Complete Assignment Failure Assignment Request Authentication Request Authentication Response Base Station Challenge Bearer Update Request Bearer Update Required Bearer Update Response Base Station Challenge Response Block
BSMAP Messages
Message Type Value 69H 65H 66H 67H 68H 02H 03H 01H 45H 46H 48H 58H 5AH 59H 49H 40H Message Category Call Processing Supplementary Services Supplementary Services Supplementary Services Supplementary Services Call Processing Call Processing Call Processing Mobility Management Mobility Management Mobility Management Call Processing Call Processing Call Processing Mobility Management Facilities Management Section Reference 3.1.19 3.6.1 3.6.2 3.6.3 3.6.4 3.1.8 3.1.9 3.1.7 3.3.1 3.3.2 3.3.5 3.1.21 3.1.23 3.1.22 3.3.6 3.5.1
B-46
3GPP2 A.S0008-C v2.0 Table 4.2.4-1

BSMAP Message Name Block Acknowledge Event Notification Event Notification Ack BS Service Request BS Service Response Clear Command Clear Complete Clear Request Complete Layer 3 Information Feature Notification Feature Notification Ack Handoff Command Handoff Commenced Handoff Complete Handoff Failure Handoff Performed Handoff Request Handoff Request Acknowledge Handoff Required Handoff Required Reject PACA Command PACA Command Ack PACA Update PACA Update Ack Paging Request Privacy Mode Command Privacy Mode Complete Radio Measurements for Position Request
BSMAP Messages
Message Type Value 41H 04H 06H 09H 0AH 20H 21H 22H 57H 60H 61H 13H 15H 14H 16H 17H 10H 12H 11H 1AH 6CH 6DH 6EH 6FH 52H 53H 55H 23H Message Category Facilities Management Mobility Management Mobility Management Call Processing Call Processing Call Processing Call Processing Call Processing Call Processing Supplementary Services Supplementary Services Radio Resource Mgmt. Radio Resource Mgmt. Radio Resource Mgmt. Radio Resource Mgmt. Radio Resource Mgmt. Radio Resource Mgmt. Radio Resource Mgmt. Radio Resource Mgmt. Radio Resource Mgmt. Supplementary Services Supplementary Services Supplementary Services Supplementary Services Call Processing Call Processing Call Processing Supplementary Services Section Reference 3.5.2 3.3.23 3.3.24 3.1.17 3.1.18 3.1.14 3.1.15 3.1.13 3.1.1 3.2.3 3.2.4 3.4.4 3.4.5 3.4.6 3.4.8 3.4.9 3.4.2 3.4.3 3.4.1 3.4.7 3.2.5 3.2.6 3.2.7 3.2.8 3.1.4 3.3.12 3.3.13 3.2.9
B-47
3GPP2 A.S0008-C v2.0 Table 4.2.4-1

BSMAP Message Name Radio Measurements for Position Response Rejection Registration Request Reset Reset Acknowledge Reset Circuit Reset Circuit Acknowledge Status Request Status Response Transcoder Control Acknowledge Transcoder Control Request Unblock Unblock Acknowledge User Zone Reject BS Authentication Request BS Authentication Request Ack
1
BSMAP Messages
Message Type Value 25H 56H 05H 30H 31H 34H 35H 6AH 6BH 39H 38H 42H 43H 0BH 07H 08H Message Category Supplementary Services Call Processing Mobility Management Facilities Management Facilities Management Facilities Management Facilities Management Mobility Management Mobility Management Facilities Management Facilities Management Facilities Management Facilities Management Mobility Management Mobility Management Mobility Management Section Reference 3.2.10 3.7.1 3.3.19 3.5.7 3.5.8 3.5.5 3.5.6 3.3.14 3.3.15 3.5.10 3.5.9 3.5.3 3.5.4 3.3.18 3.3.21 3.3.22
...
4.2.16 Cause This element is used to indicate the reason for occurrence of a particular event and is coded as shown below.
4.2.16 7 6 5 4 Length 0/1 Cause Value 3 Cause 2 1 0 Octet 1 2 3
2 3 4
A1 Element Identifier
5 6 7 8 9 10 11 12 13 14
A Cause IE exists for multiple interfaces. The cause values defined in this document are specific to the A1 or A1p interfaces. Length: This field is defined as the number of octets following the Length field. Cause Value: The cause value field is a single octet field if the extension bit (bit 7) is set to 0. If bit 7 of octet 3 is set to 1 then the cause Value is a two octet field. If the value of the first octet of the cause field is 1XXX 0000 then the second octet is reserved for national applications, where XXX indicates the Cause Class as indicated in the table below.
B-48
3GPP2 A.S0008-C v2.0

1
Table 4.2.16-1 Cause Class Values

Binary Values 000 001 010 011 100 101 110 111 Meaning Normal event Normal event Resource unavailable Service or option not available Service or option not implemented Invalid message (e.g., parameter out of range) Protocol error Interworking
Table 4.2.16-2 6 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 5 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 4 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 3 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 0 0 0 0 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 1 2 0 0 0 0 1 1 1 1 0 0 0 0 1 1 1 1 0 0 1 1 0 0 0 0 1 1 1 0 0 0 0 1 1 1 1 0 1 0 Hex Value Cause
Cause Values
Normal Event Class (000 xxxx and 001 xxxx) 0 0 00 Radio interface message failure 0 1 01 Radio interface failure 1 0 02 Uplink quality 1 1 03 Uplink strength 0 0 04 Downlink quality 0 1 05 Downlink strength 1 0 06 Distance 1 1 07 OAM&P intervention 0 0 08 MS busy 0 1 09 Call processing 1 0 0A Reversion to old channel 1 1 0B Handoff successful 0 0 0C No response from MS 0 1 0D Timer expired 1 0 0E Better cell (power budget) 1 1 0F Interference 0 0 10 Packet call going dormant 0 1 11 Service option not available 0 1 15 Short data burst authentication failure 1 1 17 Time critical relocation/handoff 0 0 18 Network optimization 0 1 19 Power down from dormant state 1 0 1A Authentication failure 1 1 1B Inter-BS soft handoff drop target 0 1 1D Intra-BS soft handoff drop target 1 0 1E Autonomous Registration by the Network 1 1 1F 1x service rejected Resource Unavailable Class (010 xxxx) 0 0 20 Equipment failure 0 1 21 No radio resource available 1 0 22 Requested terrestrial resource unavailable 1 1 23 A2p RTP Payload Type not available 0 0 24 A2p Bearer Format Address Type not available 0 1 25 BS not equipped 1 0 26 MS not equipped (or incapable) 1 1 27 2G only sector 0 0 28 2G only carrier
B-49
3GPP2 A.S0008-C v2.0

Table 4.2.16-2 6 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 5 1 1 1 1 1 1 1 1 1 1 1 0 0 1 1 1 1 1 1 1 4 0 0 0 0 0 0 1 1 1 1 1 0 1 0 1 3 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 2 0 0 0 1 1 1 0 0 0 0 1 1 0 0 0 Cause Values
1 0 1 1 1 0 1 1 0 1 1 0 1 1 1 All other values
1 0 Hex Value Cause 0 1 29 PACA call queued 1 0 2A PCF resources are not available 1 1 2B Alternate signaling type reject 0 0 2C A2p Resource not available 0 1 2D PACA queue overflow 1 0 2E PACA cancel request rejected Service or Option Not Available Class (011 xxxx) 0 0 30 Requested transcoding/rate adaptation unavailable 0 1 31 Lower priority radio resources not available 1 0 32 PCF resources are not available 1 1 33 TFO control request failed 0 0 34 MS rejected order Service or Option Not Implemented Class (100 xxxx) 0 1 45 PDS-related capability not available or not supported) Invalid Message Class (101 xxxx) 0 0 50 Terrestrial circuit already allocated Protocol Error (110 xxxx) 0 0 60 Protocol error between BS and MSC Interworking (111 xxxx) 0 1 71 ADDS message too long for delivery on the paging channel 1 1 77 PPP session closed by the MS 0 0 78 Do not notify MS 0 1 79 PCF (or PDSN) resources are not available 1 0 7B Concurrent authentication 1 1 7F Handoff procedure time-out Reserved for future use.
...
4.2.39 CM Service Type This element specifies the type of service requested from the network. The CM Service Type IE is coded as shown below. It is a type 1 IE.
4.2.39 7 1 6 5 A1 Element Identifier 4 CM Service Type 3 2 1 0 Octet 1 Service Type
2 3 4
5 6 7
Service Type: This field is coded as shown in Table 4.2.39-1. Table 4.2.39-1 CM Service Types
Binary Values 0001 0010 0100 1000 Meaning Mobile originating call establishment Emergency call establishment Short Message transfer Supplementary service activation
B-50
3GPP2 A.S0008-C v2.0

Binary Values 1001 Meaning Mobile originating call establishment via 3GPP2 Packet Data System All other values reserved
1
...
4.2.49 Service Option This element indicates the service option requested by the MS, or by the network. It is coded as follows:
4.2.49 7 (MSB) 6 5 4 Service Option 3 Service Option (LSB) 2 1 0 Octet 1 2 3
2 3
4 5
Service Option:
For signaling type TIA/EIA/IS-2000, the Service Option field in octets 2 and 3 is coded as defined in [24].
6 7
The service options supported are given in Table 4.2.49-1. Table 4.2.49-1 Service Option Values
Service Option Value (hex) 8000H 0011H 0003H 801FH 0004H 0005H 0007H
a
Description 13K speech 13K high rate voice service EVRC 13K Markov Asynchronous Data rate set 1 Group 3 Fax rate set 1 Packet Data Service: Internet or ISO Protocol Stack (Revision 0) Position Determination Service (PDS) Rate Set 1 Position Determination Service (PDS) Rate Set 2 13K loopback Selectable Mode Vocoder (SMV) Asynchronous Data rate set 2 Group 3 Fax rate set 2 SMS rate set 1 SMS rate set 2 Packet Data Service: Internet or ISO Protocol Stack (14.4 kbps) OTAPA Rate Set 1 OTAPA Rate Set 2 IS-2000 Test Data IS-2000 Markov IS-2000 Loopback High Speed Packet Data Service: Internet or ISO Protocol Stack (RS1 forward, RS1 reverse)
0023H 0024H 0009H 0038H 000CH 000DH 0006H 000EH 000FH

a
0012H 0013H 0020H 0036H 0037H 0016H

a
B-51
3GPP2 A.S0008-C v2.0

Service Option Value (hex) 0017H
a
Description High Speed Packet Data Service: Internet or ISO Protocol Stack (RS1 forward, RS2 reverse) High Speed Packet Data Service: Internet or ISO Protocol Stack (RS2 forward, RS1 reverse) High Speed Packet Data Service: Internet or ISO Protocol Stack (RS2 forward, RS2 reverse) (3G High Speed Packet Data) (ISDN Interworking Service (64 kbps)) (32 kbps Circuit Switched Video Conferencing) (64 kbps Circuit Switched Video Conferencing) HRPD Packet Data; page response not required Link-Layer Assisted Header Removal Link-Layer Assisted Robust Header Compression Wideband Speech Codec HRPD Packet Data; page response required Packet Data Service: Internet or ISO Protocol Stack, Revision 1 (9.6 or 14.4 kbps) HRPD Packet Data; page response not required HRPD Packet Data; page response required
0018Ha 0019Ha 0021H 0025H 0039H 003AH 003BH 003CH

b b
003DH
003EH 0045H 1007H

a
5900H-59FFH 6900H-69FFH
1 2 3 4 5
a. These values are only used to indicate intergeneration handoff (refer to [13]). Any other use of these values is outside the scope of this version of the standard. b. This value can only be assigned to auxiliary services instances (e.g. when an SO33 has been allocated).
...
4.2.86 Service Reference Identifier (SR_ID) This IE contains the SR_ID for a service instance. The purpose of the SR_ID is to distinguish between multiple service instances within one MS.
4.2.86 7 6 5 Service Reference Identifier (SR_ID) 4 Length SR_ID Reserved SR_ID 3 2 1 0 Octet 1 2 3 3 A1 Element Identifier
7 8 9
10 11 12 13 14
Length Reserved SR_ID
This field indicates the number of octets in this IE following the Length field. These bits are coded as 00000. This field contains the SR_ID of a service instance. Refer to [3]. Up to six service instances are supported.
15
...
B-52
3GPP2 A.S0008-C v2.0

1
2 3
4.2.92 Event The IE is included by the MSC to indicate an event associated with the MS/AT.
4.2.92 7 6 5 4 Length Event Identifier 3 Event 2 1 0 Octet 1 2 3
4 5
Length
This field indicates the number of octets in this IE following the Length field.
Event Identifier This field is coded as follow:

Binary Values Event Identifier Meaning 0000 0001 0000 0010 1x Registration 1x Power Down
All other values are reserved

6 7
4.2.93 Page Indicator This IE provides paging details to the BS. It is coded as follows:
4.2.93 7 6 5 4 Length Reserved VPI Page Indicator 3 2 1 0 Octet 1 2 3
8 9 10
Length VPI
This field indicates the number of octets in this IE following the Length field. When the field is set to 1, the 1x BS shall be prepared to receive a Page Response Message from the MS/AT. Otherwise this field is set to 0.
11
...
5.1 Timer Values
Table 5.1-1 Timer Name ... Tevent ... 55 0 255 1 5.2.1.21 Call Processing Default Value (seconds) Timer Values and Ranges Sorted by Name Range of Values (seconds) Granularity (seconds) Section Reference Classification
12 13
14
...
B-53
3GPP2 A.S0008-C v2.0

1 2 3 4 5 6
5.2.1.21 Tevent This MSC timer is started when an Event Notification message is sent and is stopped when an Event Notification Ack message is received.
B-54
3GPP2 A.S0008-C v2.0
1 2 3 4 5
Annex C
A8-A9 (AN - PCF) Interface Change Text (Normative)
Note: Annex C, contains specific A9 messaging text from [16] with all HRPD related changes identified through the use of underscores (additions) and strikeouts (deletions). Use of an ellipsis () indicates that the base document is unchanged. Note: Fast handoff as defined in this Annex C applies only to 1x systems.
...
1.2 References
...
1.2.1 3GPP2
10
...
[8] X.S0011-D v1.0, Wireless IP Network Standard, March 2006[8] 3GPP2: X.S0011-C, Wireless IP Network Standard, six parts, September 2003.
11 12
13
...
[10] 3GPP2: C.S0024-B v2.0, cdma2000 High Rate Packet Data Air Interface Specification, March 2007.
14 15
16
...
[22] 1.2.2 C.S0063-A v1.0, cdma2000 High Rate Packet Data Supplemental Services, April 2006. Other
17
18
19
...
[23] [24] Internet Assigned Numbers Authority: RObust Header Compression (ROHC) Profile Identifiers, http://www.iana.org/assignments/rohc-pro-ids. IETF: RFC 3095, RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed, July 2001.
20 21
22 23
24 25
...
2.0 Message Procedures
Note: When the procedures between 1x and HRPD systems differ, the HRPD procedures are identified separately within this specification. Hard handoff procedures are not applicable to HRPD.
26 27 28
29 30
2.1
A8/A9 Interface Setup Procedures
This section contains the messages used to set up an A8 connection. C-1
3GPP2 A.S0008-C v2.0

1 2 3 4
2.1.1
A9-Setup-A8
This message is sent from the BS to the PCF to request the establishment of an A8 connection for a packet data service instance (PDSI) activation, hard or dormant handoff of a PDSI, or to initiate CCPD mode setup. 2.1.1.1 Successful Operation In 1x systems, Wwhen the BS receives a request for a PDSI activation from the MS (e.g., origination message with DRS bit set to 1) or when the BS receives a request for re-activation of a PDSI from the PCF (e.g., A9-BS Service Request) or MSC (e.g., Paging Request), and the MS has responded to a page (if not already on a traffic channel), it initiates service negotiation to put the PDSI onto radio traffic channels, sends an A9-Setup-A8 message indicating normal call setup (i.e., the Handoff Indicator field of the A9-Setup-A8 message is set to 0), and starts timer TA8-setup. If no other PDSI is active, the BS shall wait until the MSC has authorized the activation of the packet data session (e.g., the BS receives an Assignment Request message) before sending the A9-Setup-A8 message. In an HRPD system, the PCF stops timer Tnet_conn if running. In HRPD systems, when the AN establishes the first A8 connection, the AN sends an A9-Setup-A8 message to the PCF with SO=59 (3BH) or SO=71 (47H) and SR_ID 1, and starts timer TA8-setup. The A8 connection for SR_ID 1 is defined as the main service instance and carries forward and reverse flows with Flow ID FFH. Note that other IP Flows may be carried over the main A8 connection. The MN ID 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 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. In HRPD systems, when the AN determines that additional A8 connections are required (e.g., when a new link flow is established), the AN sends an A9-Setup-A8 message including the Additional A8 Traffic ID IE, to the PCF, and starts timer TA8-setup. These connections may have SO=64 (40H) or SO=67 (43H). In HRPD systems with PDSN-based ROHC on SO67, the AN indicates whether to create a forward and/or reverse ROHC channel for each SO67 auxiliary A8 connection when it is established. The AN includes each channels negotiated ROHC channel parameter values in the A9-Setup-A8 message that establishes the A8 connection. In HRPD systems, when the BS supports the GRE extension and determines that a GRE extension for the IP flow discriminator is required, the BS sets the Use IP Flow Discriminator to 1 in the A9-Setup-A8 message for each A8 connection that requires the flow discriminator GRE extension. In HRPD systems, if the AN receives an HRPD Emergency Indicator with the connection establishment or flow configuration request, the AN sets the Emergency Services indicator to 1 in the A9-Setup-A8 message sent to the PCF. In HRPD systems, when the AN receives an A13-Session Information Request message that contains a Data Transfer IE with an A24 Connection ID (i.e., with a request to transfer buffered data), the AN may send an A9-Setup-A8 message with the Buffer Transfer indicator set to 1 to the PCF to establish the A8 connection. When the MS performs a hard handoff during packet data services, the target BS sends an A9-Setup-A8 message to the PCF to establish an A8 connection upon receipt of the Handoff Request message from the MSC and starts timer TA8-setup. In this case, the BS sets the Handoff Indicator field of the A9-Setup-A8 message to 1 and the Data Ready Indicator to 1. When the BS receives a request for a dormant handoff from the MS (e.g., origination message with DRS bit set to 0 or including PREV_PZID, PREV_SID, or PREV_NID) or upon completion of the UATI assignment procedures in HRPD systems, the BS sends the A9-Setup-A8 message to the PCF and starts timer TA8-setup. In this case, the BS sets the Handoff Indicator to 0. If no other PDSI is active, the BS C-2
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 48
3GPP2 A.S0008-C v2.0

1 2 3 4 5 6 7 8
shall wait until the MSC has accepted the dormant handoff request (e.g., the BS receives an Assignment Request or ADDS Transfer Ack message) before sending the A9-Setup-A8 message. To indicate that CCPD Mode will be used for the PDSI associated with the A8 connection being established, the BS sets the CCPD Mode bit to 1. The BS shall wait until the MSC has accepted the service request (e.g., the BS receives an ADDS Transfer Ack message) before sending the A9-Setup-A8 message. If the MS supports short data bursts and the BS allows short data bursts to be sent for the PDSI, the BS shall set the SDB/DoS Supported field in the message to 1. Otherwise this field shall be set to 0. 2.1.1.2 Failure Operation If the BS fails to receive an A9-Connect-A8 message or an A9-Release-A8 Complete message in response to an A9-Setup-A8 message before the expiration of timer TA8-setup, the BS may resend the A9Setup-A8 message to the PCF and restart timer TA8-setup a configurable number of times. If the BS fails to receive an A9-Connect-A8 message or an A9-Release-A8 Complete message before timer TA8-setup expires after a configurable number of tries or the BS does not resend the A9-Setup-A8 message, the BS shall initiate release of the MS or service negotiation to remove the PDSI from the traffic channel (if required). In HRPD systems, if the AN fails to receive an A9-Connect-A8 message or an A9-Release-A8 Complete message in response to the A9-Setup-A8 message for setting up additional A8 connections before timer TA8-setup expires after a configurable number of times or the AN does not resend the A9-Setup-A8 message, the AN may initiate release of the AT or session configuration to remove the link flow corresponding to the A8 connections (if required). 2.1.2 A9-Connect-A8
9 10 11 12 13 14 15 16 17 18 19 20 21
22 23
This A9 message is used to respond to an A9-Setup-A8 message. 2.1.2.1 Successful Operation The PCF sends an A9-Connect-A8 message to the BS in response to an A9-Setup-A8 message. If establishment of an A10 connection is needed (e.g., during normal call setup), this message shall be sent after the connection establishment is successful. If the Handoff Indicator field of the A9-Setup-A8 message is set to 1, the PCF starts timer Twaitho9 after sending the first A9-Connect-A8 message. The PCF stops timer Twaitho9 upon receipt of the A9-AL (Air Link) Connected or the A9-Release-A8 messages. Upon receiving the A9-Connect-A8 message, the BS stops the timer TA8-setup. In HRPD systems, if the A9-Connect-A8 message establishes the main A8 connection, then the PCF includes the Subscriber QoS Profile, if applicable. In HRPD systems, when the PCF receives an A9-Setup-A8 message including the Additional A8 Traffic ID IE, the PCF shall send an A9-Connect-A8 message for successful operation. If A10 connection establishment is needed, the message shall be sent after connection establishment is successful. The A9Connect-A8 message shall include connection information for the same number of A8 connections as in the corresponding A9-Setup-A8 message if both PCF and PDSN support all the required new service connection. Otherwise, the A9-Connect-A8 message includes information on all A8 connections corresponding to the all A10 connections supported by the PCF/PDSN and Cause value Partial Connections. Upon receiving the A9-Connect-A8 message, the AN shall stop timer TA8-setup. In HRPD systems that support PDSN-based ROHC on SO67, the A9-Connect-A8 message for the main A8 connection includes the PDSNs ROHC configuration parameter values received from the PDSN. The AN stores these values and takes them into account when establishing new ROHC channels between the AT and the PDSN. In addition, the AN takes the MaxCID and LargeCIDs parameter values into account in determining the maximum number of compressed IP flows allowed for the reverse ROHC channel.
24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45
C-3
3GPP2 A.S0008-C v2.0

1 2 3
2.1.2.2 Failure Operation If the timer Twaitho9 expires, the PCF should initiate clearing of the A8 connection by sending an A9Disconnect-A8 message to the BS. The PCF starts timer Tdiscon9. 2.1.3 A9-BS Service Request
4 5
This A9 interface message is sent from the PCF to the BS to begin a network initiated call setup. 2.1.3.1 Successful Operation To initiate the reactivation of a dormant service instance, the PCF sends an A9-BS Service Request message to the BS. The PCF starts timer Tbsreq9 and awaits the reception of the A9-BS Service Response message. 2.1.3.2 Failure Operation If an A9-BS Service Response message is not received at the PCF before the expiration of timer Tbsreq9, then the PCF may resend the A9-BS Service Request message and restart timer Tbsreq9 a configurable number of times. 2.1.4 A9-BS Service Response
6 7 8 9
10 11 12 13
14 15
This A9 interface message is sent from the BS to the PCF in response to an A9-BS Service Request. 2.1.4.1 Successful Operation The BS 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. In HRPD systems, 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. 2.1.4.2 Failure Operation None.
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
2.2
A8/A9 Interface Clearing Procedures
Procedures for clearing the A8 connection are described in this section. A8 connection clearing is initiated whenever the PDSI state changes from active to dormant or null. Clearing the A8 connection does not necessarily correspond to clearing of the traffic channel or the packet data service session. A8 connection(s) clearing occurs: In 1x systems, wWhen a packet data inactivity timer in the BS expires for a PDSI; and in HRPD systems, when a packet data inactivity timer in the AN expires for a packet data session or the AN detects air link lost condition. If it is the only active PDSI for the MS, the BS requests the MSC to clear the service, sends an A9-Release-A8 message to the PCF and starts timer Trel9. Otherwise, if it is not the only active PDSI, the BS sends an A9-Release-A8 message to the PCF and starts timer Trel9. For either case, the PCF responds with an A9-Release-A8 Complete message and the BS stops timer Trel9. The two scenarios are illustrated by the BS Initiated PDSI Release to Dormant State when no other PDSI is active and the BS Initiated PDSI Release to Dormant State when other PDSIs are active in [13]. The HRPD system call flow scenario is illustrated in the IOS HRPD specification section 3.4.2, Connection Release on HRPD Network - Initiated by the AN. When the BS receives a Release Order requesting the transition to dormant of a PDSI or connection release procedures for HRPD systems, the BS performs the same procedures as in the BS initiated scenarios. The two scenarios are illustrated by the MS Initiated PDSI Release to Dormant State when no other PDSI is active and the MS Initiated PDSI Release to Dormant State when other C-4
3GPP2 A.S0008-C v2.0

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24
PDSIs are active in [13]. The HRPD system call flow scenario is illustrated in the IOS HRPD specification section 3.4.1, Connection Release on HRPD Network - Initiated by the AT. In 1x systems, wWhen the MS releases the packet data session and the BS receives a Release Order, the BS requests the MSC to clear the service, sends an A9-Release-A8 message to the PCF with a cause value set to normal release if only one A8 connection is active and starts timer Trel9. If this is not the only active PDSI, the cause value is set to packet data session release and sent for only one of the A8 connections. The PCF responds with an A9-Release-A8 Complete message. The BS stops timer Trel9. The Active MS Power Down and MS Initiated Call Release to Null State scenarios are shown in [13]. In HRPD systems, when the AT or AN release the HRPD session and the A8 connection is already established, the AN sends an A9-Release-A8 message to the PCF with a cause value set to Normal call release or Authentication failure (when the re-authentication of AT failure at AN AAA). The HRPD system call flow scenario is illustrated in the IOS HRPD specification, section 3.5.1, HRPD Session Release - Initiated by the AT or AN (A8 Connections Exists), or section 3.5.3, HRPD Session Release Re-authentication of AT failure (A8 Connections Exist). In 1x systems, wWhen the A10 connection is released by the PDSN. When the PCF detects that an A10 connection is released, the PCF sends an A9-Disconnect-A8 message to the BS and starts timer Tdiscon9. The BS initiates 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. If this is the last PDSI, the BS clears any terrestrial resources and releases the air resources. Otherwise if this is not for the last PDSI, the BS renegotiates the traffic channel. The two scenarios are illustrated by the PDSN Initiated Release of an active PDSI - Packet data session becomes dormant or inactive and the PDSN Initiated Release of an active PDSI - Packet data session remains active in [13]. A9-Release-A8
25 26 27
2.2.1
This A9 interface message is sent from the BS to the PCF to request the release of the associated dedicated resource. 2.2.1.1 Successful Operation When the BS needs to release an A8 connection, it sends an A9-Release-A8 message to the PCF. In HRPD systems, the AN sends an A9-Release-A8 message without the Additional A8 Traffic ID IE and with a cause value other than Partial connection release when the AN releases all A8 connections for the AT. In HRPD systems, the AN sends an A9-Release-A8 message with the cause value Partial connection release, including the Additional A8 Traffic ID IE to the PCF when the AN decides to release at least one but not all A8 connections for an AT. A8 connections to be released are not included in the message. The IP Flow=FFH shall not be released by the A9-Release-A8 message with the cause value Partial connection release. When the PCF receives an A9-Release-A8 message with a cause value other than Partial connection release, the PCF releases all A8 connections for the AT. When the BS releases an A8 connection for the case where the MS has powered down, the BS sends an A9-Release-A8 message to the PCF with the cause value Packet Data Session Release included. This message triggers the PCF to release all A10 connections associated with the MS. When the BS releases an A8 connection for the case where a service instance is transitioning to the Dormant State, the BS sends an A9-Release-A8 message to the PCF with the Cause value Packet data call going dormant included. This message does not trigger the PCF to release any A10 connections. The BS starts timer Trel9 and waits for the A9-Release-A8 Complete message from the PCF. When the PCF receives the A9-Release-A8 message, it stops timer Tdiscon9, Taldak, or Twaitho9 if active and performs the appropriate procedure to release the associated dedicated resources. C-5
28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47
3GPP2 A.S0008-C v2.0

1 2 3 4 5 6
2.2.1.2 Failure Operation If an A9-Release-A8 Complete message is not received from the PCF before timer Trel9 expires, the BS may resend the A9-Release-A8 message to the PCF and restart timer Trel9 a configurable number of times. If the A9-Release-A8 Complete message is not received from the PCF, the BS shall cease further supervision of this PDSI, release the dedicated resources associated with this PDSI, and release the A8 connection. 2.2.3 A9-Release-A8 Complete
7 8
No changes from A.S0016-C. 2.2.4 A9-Disconnect-A8
9 10 11
This A9 interface message is sent from the PCF to the BS to request the release of the associated dedicated resource. 2.2.4.1 Successful Operation In 1x System, wWhen the PCF needs to release an A8 connection, it sends an A9-Disconnect-A8 message to the BS. The PCF starts timer Tdiscon9. In HRPD systems, the PCF sends an A9-Disconnect-A8 message when the PCF releases all A8 connections for the AT. 2.2.4.2 Failure Operation If an A9-Release-A8 message is not received from the BS before timer Tdiscon9 expires, the PCF may resend the A9-Disconnect-A8 message to the BS and restart timer Tdiscon9 a configurable number of times. If the A9-Release-A8 message is not received from the BS, the PCF shall cease further supervision of this A8 connection, send the A9-Release-A8 Complete message, and release the resources associated with the A8 connection.
12 13 14 15
16 17 18 19 20 21
22 23
2.3
A8/A9 Interface Handoff Procedures
This section contains the messages used during handoff procedures. 2.3.1 A9-Air Link (AL) Connected
24 25 26 27 28 29 30 31 32 33 34
In 1x systems, this This message is sent from the target BS to the PCF after the MS performs hard handoff. This message notifies the PCF that the handoff is successfully completed (i.e. that the air link has been established between the MS and the target BS) and that the PCF can send packets on the established A8 connection. The message may also be sent from the source BS to the PCF in the case of handoff with return on failure. In this situation, the message notifies the PCF that the MS has reestablished the air link with the source BS, and the PCF can resume sending packets to the source BS. In HRPD systems, the A9-AL Connected message is sent from the AN managing the active air link to the PCF when it determines that data flow stopped by the A9-AL Disconnected message from the PCF should be resumed. This message is employed 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. 2.3.1.1 Successful Operation In 1x systems, after After the MS performs hard handoff including the case of return on failure, the BS managing the active air link sends the A9-AL Connected message to the PCF. In the case of handoff with return on failure the PCF stops timer Taldak upon receipt of this message. 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 BS managing the active air link, stops the timers Twaitho9 for all established A8 connections, and starts timer Talc9. The A9-AL Connected message triggers the PCF to establish A10 connections for all established A8 connections if needed (inter-PCF handoff). If the PCF is unable to C-6
35 36 37 38 39 40 41 42
3GPP2 A.S0008-C v2.0

1 2 3 4 5 6 7 8 9
establish an A10 connection, it sends an A9-Disconnect-A8 message to the BS for the corresponding A8 connection. If the PCF supports fast handoff, and the A10 connections have already been established if needed for all A8 connections, when the PCF receives the A9-AL Connected message it starts to forward the data from the PDSN to the BS on all A8 connections. In HRPD systems, after the AN determines that data flow stopped by the A9-AL Disconnected message from the PCF should be resumed, 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. 2.3.1.2 Failure Operation If timer Talc9 expires, the BS may resend the A9-AL-Connected message and restart timer Talc9 a configurable number of times. If the A9-AL-Connected message is not resent or resending of this message also results in failure, the BS shall initiate release of the packet data session. If timer Twaitho9 expires, the PCF shall send an A9-Disconnect-A8 message for the associated A8 connection to the BS. The PCF shall start timer Tdiscon9. 2.3.2 A9-Air Link (AL) Connected Ack
10 11 12 13 14 15
16 17
No changes from A.S0016-C. 2.3.3 A9-Air Link (AL) Disconnected
18 19 20 21 22
When the MS performs hard handoff or the AN determines that data flow from the PCF should be stopped for all A8 connections, the A9-AL Disconnected message is sent from the source BS to the source PCF. This message is sent to notify the source PCF that the air link is temporarily disconnected. An A9-AL Disconnected Ack message is expected in response. 2.3.3.1 Successful Operation When the source BS receives the Handoff Command message which instructs it to perform hard handoff or when the AN determines that data flow from the PCF should be stopped in the HRPD system for all A8 connections, the source BS shall send an A9-AL Disconnected message to the PCF and start timer Tald9. Upon receipt of an A9-AL Disconnected message from the source BS, the PCF shall stop transmitting packet data to the BS for all PDSIs and start buffering packets from the PDSN. 2.3.3.2 Failure Operation If timer Tald9 expires, the BS may resend the A9-AL Disconnected message and restart timer Tald9 a configurable number of times. 2.3.4 A9-Air Link (AL) Disconnected Ack
23 24 25 26 27 28 29
30 31 32
33 34
No changes from A.S0016-C.
35 36
2.4
A8/A9 Interface Maintenance Procedures
This section describes the A9 version control messages. 2.4.1 A9-Version Info
37 38
C-7
3GPP2 A.S0008-C v2.0

1 2
2.4.2
A9-Version Info Ack
3 4 5
2.5
A9 Session Update Procedures
This section contains message procedures for passing update information over the A9 interface. The A8 connection may or may not be established prior to sending an update on the A9 interface. 2.5.1 A9-Update-A8
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
The A9-Update-A8 message is sent from the PCF to the BS to update the BS with new or updated parameters for a PDSI or packet data session. The packet data session shall be active when this message is sent to the BS. The A9-Update-A8 message is sent from the BS to the PCF to convey accounting information to the PCF if the A8 connection is established before traffic channel establishment (in which case the PCF resumes data transmission on the A8 connection only after it receives the A9-Update-A8 message) or while a PDSI is active following accounting parameter changes which need to be conveyed to the PDSN indirectly via the PCF. In HRPD systems, the A9-Update-A8 message is sent from the AN to the PCF to convey IP flow-toservice connection mapping information when the IP flow-to-service connection mapping does not require establishment of new A8 connections or release of existing A8 connections. This message may be sent when the AT is in the Active or Dormant State. In HRPD systems, the A9-Update-A8 message is also sent from the source AN to the source PCF with the Handoff Indicator set to 1 to indicate that a handoff is in progress. In HRPD systems, the A9-Update-A8 message is sent from the PCF to the AN to convey the Subscriber QoS Profile upon receiving it from the PDSN. The packet data session may be active or dormant when this message is sent to the AN. In HRPD systems, this message is also used to update the QoS for one or more specific IP flows. If there is a Flow Profile ID with the value of 0x0000 in the U_QoS_SUB_BLOB for an IP flow, then the AN shall inform the AT that the requested QoS_SUB_BLOB has been added but is invalid for this AN and the AT should not activate the corresponding IP flow. Otherwise upon receipt of the updated QoS, the AN shall change the granted QoS for the corresponding IP flow to the first acceptable Flow Profile ID in the list, irrespective of the contents of the subscriber QoS Profile. A Flow Profile ID shall be considered acceptable if it is supported by the AN, if it matches one of the Flow Profile IDs requested by the AT, and if the call is not in inter-PCF handoff. The AN shall store the updated QoS information received from the PCF together with the personality index in use at the time the update was received. Whenever the specified personality index is in use, the AN shall use the stored QoS update to grant the QoS irrespective of the contents of the subscriber QoS Profile. All updated QoS information stored in the AN for a given IP flow is cleared when the corresponding IP flow is set to null (refer to [10]) 78, regardless of the personality in use. Updated QoS information received from the PDSN (via the PCF) supersedes stored updated QoS information previously received from the PDSN or from another AN (via A13 or A16). In HRPD systems, this message is also used to release an IP flow by setting the FlowProfile ID value to 0x0000 in the Forward/Reverse Updated QoS Sub-BLOB for the IP flow that the PDSN wants to release. The PDSN should not use this procedure for flow ID FFH and FEH. In HRPD systems, this message is also used convey the Emergency Services indication from the BS to the PCF.
78 i.e., ProfileType = NULL in ReservationKKQoSRequestFwd or ReservationKKQoSRequestRev.
C-8
3GPP2 A.S0008-C v2.0

1 2 3 4 5 6 7 8 9
The BS may send an A9-Update-A8 message to the PCF to indicate if short data bursts may be sent to the MS. The PCF may send an A9-Update-A8 message to the BS if the MSs SDB capability is cached at the PCF so the BS does not need to query the MS for its SDB capability. The BS may also send the A9Update-A8 message to the PCF to indicate a successful Short Data Burst delivery to the MS if the PCF was not informed previously that the SDB was delivered successfully to the MS. The A9-Update-A8 message is also 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 an MS undergoing dormant handoff. The BS can also use this message to inform the PCF that a dormant MS has powered down. In these two cases, the PCF initiates the release of all A10 connections associated with the MS. 2.5.1.1 Successful Operation If the A9-Update-A8 message is sent from the PCF to the BS to update packet data session parameters or to convey the subscriber QoS profile, the PCF includes the Cause element set to Session parameter update upon reception of any new or updated session parameters or the subscriber QoS profile from the PDSN. After sending the message to the BS, the PCF starts timer Tupd9 and waits for an A9-Update-A8 Ack message from the BS. If the A9-Update-A8 message includes updated QoS and the BS does not have sufficient resources available, then the BS may reject the A9-Update-A8 message by sending an A9-Update-A8 Ack message with cause value BS resources are not available. If the A9-Update-A8 message includes updated QoS and the BS only has resources available to comply with the updated QoS for some of the specified flows, the BS may respond by sending an A9-Update-A8 Ack message with cause value Partial QoS updated. The BS informs the PCF of which QoS updates were accepted and which were rejected using the IP flow mapping update procedure. If the message is sent from the BS to the PCF to pass accounting or authentication information, the BS shall set the Cause field to the appropriate value (1CH or 1EH), start timer Tupd9, and wait for an A9Update-A8 Ack message from the PCF. If the message is sent from the BS to the PCF or from the PCF to the BS to indicate if short data bursts may be sent to the MS, the sending entity shall set the SDB/DoS Supported bit to 1, set the Cause field to Capability update (1BH), start timer Tupd9 and wait for an A9-Update-A8 Ack message from the receiving entity. In HRPD systems, the A9-Update-A8 message includes the subscriber QoS profile. If the message is sent from the PCF to the BS to covey the subscriber QoS profile, the PCF indicates the Cause field set to Session Parameter Update, start timer Tupd9, and wait for an A9-Update-A8 Ack message from the PCF. In HRPD systems, if the AN receives an HRPD Emergency Indicator with the flow configuration request, the AN sets the Emergency Services indicator to 1 in the A9-Update-A8 message sent to the PCF. If the message is sent from the BS to the PCF to indicate a successful short data burst delivery to the MS, the BS shall set the Cause field to SDB successfully delivered (17H), start Tupd9 and wait for an A9Update-A8 Ack message from the PCF. 2.5.1.2 Failure Operation When the message is sent from the PCF to the BS to update parameters for a PDSI, if Tupd9 expires, the PCF may resend the A9-Update-A8 message to the BS and restart timer Tupd9 a configurable number of times. If the A9-Update-A8-Ack message is not received from the BS, the session update procedure is considered failed and the PCF notifies the PDSN. In the event of a failure, if an A8 connection was active prior to the session update procedure, it shall remain connected. When the message is sent from the BS to the PCF to pass accounting or authentication information, if an A9-Update-A8 Ack message is not received from the PCF before timer Tupd9 expires, the BS may resend the A9-Update-A8 message and restart timer Tupd9 a configurable number of times. If the C-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
3GPP2 A.S0008-C v2.0

1 2
acknowledgment is not received from the PCF, the BS ceases sending this message, and commences PDSI clearing. 2.5.2 A9-Update-A8 Ack
3 4 5
6 7
2.6
A8/A9 Interface Data Delivery Procedures
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
2.6.1
A9-Short Data Delivery
This A9 interface message is sent from the BS to the PCF when it receives a short data burst from the MS. In HRPD systems, the AT does not send DoS messages unless the AN enables reverse link DoS for that IP flow. Data received from the AT in a DoS message as specified in [10] does not contain a Flow ID, but the A9-Short Data Delivery message carrying the data should be given expedited treatment through the RAN transport network to the PDSN. Data associated with a given IP flow that is received from the AT in a DoS message containing a Flow ID as specified in [22] should be given the same treatment as regular packets of that IP flow. If short data bursts are supported for the PDSI, this message may also be sent from the PCF to the BS when there is a small amount of packet data to be sent from the PDSN to an MS, and the PCF determines that a short data burst should be used to transmit this data. When used in the PCF to BS direction, the PCF retains a copy of the data sent in the message. The message also contains a count of the number of additional bytes of data remaining at the PCF for the PDSI. This information may be used by the BS, for example in determining whether short data bursts for 1x systems and DoS for HRPD systems could be used to deliver the data to the MS. In 1x systems, Tthis message is used when the MSs PDSI is dormant. The data is encapsulated in the ADDS user part element in SDB format as specified in [18]. In HRPD systems, the data is encapsulated in DoS format as specified in [10] or [22]. In HRPD systems, the message also includes the Flow ID of the IP Flow which constitutes the payload of the ADDS user part IE in two cases: when sent in the PCF to AN direction, and when sent in the AN to PCF direction and the Flow ID was received from the AT. When used in the PCF to BS direction, the PCF retains a copy of the data sent in the message. The message also contains a count of the number of additional bytes of data remaining at the PCF for the PDSI. This information may be used by the BS, for example in determining whether short data bursts could be used to deliver the data to the MS. 2.6.1.1 Successful Operation The BS sends the A9-Short Data Delivery message to the PCF after receiving a short data burst from the MS and after optionally authenticating the MS. Upon receipt of this message by the PCF, the packet data is sent to the PDSN on the A10 connection associated with service instance indicated in the A9-Short Data Delivery. The PCF sends the A9-Short Data Delivery message to the BS when it determines that there is a small amount of data to be sent to a dormant PDSI at the MS or if the packet data service is operating in CCPD Mode. The PCF shall send this message only if short data bursts are supported for the PDSI. The PCF starts timer Tsdd9 and waits for an A9-Short Data Ack message from the BS. In 1x systems if the BS decides that the data can be sent to the MS as a Short Data Burst, an A9-Short Data Ack message is sent to the PCF with a successful cause value. In HRPD systems, if the AN decides that the data can be sent in C-10
35 36 37 38 39 40 41 42 43 44 45
3GPP2 A.S0008-C v2.0

1 2 3 4 5 6
DoS format, it attempts to deliver the packet via DoS messages. The result of the DoS messaging is conveyed from the AN to the PCF via an A9-Short Data Ack message. If the BS does not initiate the ADDS Page procedure to deliver the SDB, the BS may alternatively send the A9-Short Data Ack message to the PCF, with the cause value indicating if the data was successfully delivered, after the data has been sent to the MS. The BS may also reject the PCFs request for a short data burst delivery via the A9-Short Data Ack message. 2.6.1.2 Failure Operation If timer Tsdd9 expires before the PCF receives an A9-Short Data Ack or an A9-Update A8 message from the BS, the buffered data at the PCF is discarded. 2.6.2 A9-Short Data Ack
7 8 9
10 11 12 13 14 15
In 1x systems, Tthis message is sent from the BS to the PCF to acknowledge the receipt of the A9-Short Data Delivery message from the PCF. It also indicates to the PCF whether the data received is to be sent to the MS as a short data burst or alternatively whether the data was successfully delivered to the MS. In HRPD systems, the A9-Short Data Ack message is used to indicate to the PCF the result of DoS messaging i.e., whether or not the DoS message was successfully delivered. 2.6.2.1 Successful Operation If the BS decides to send the data received from the PCF to the MS as a short data burst, it shall indicate this to the PCF in the A9-Short Data Ack message. Upon receiving this indication, the PCF stops timer Tsdd9 and discards its copy of the buffered data. Note that acceptance of the data is independent of the mechanism the BS chooses to send the data to the MS over the air interface. The BS may send this data directly to the MS via a short data burst, or it may forward the data to the MSC using the BS Service Request/Response procedure. If the BS is unsuccessful in delivering the data to the MS on its own, it may choose to send the data to the MSC for delivery to the MS via the ADDS Page procedure. This procedure is not used in HRPD systems. If the BS decides against delivering the data to the MS as an SDB/DoS, it shall respond to the PCF with an A9-Short Data Ack message with a reject indication. Upon reception of this message, the PCF shall stop timer Tsdd9 and then initiate re-activation of the 1x PDSI or HRPD packet data session from the dormant state by sending an A9-BS Service Request message to the BS. Refer to [13] for more details. The BS may also try to send the SDB/DoS data to the mobile before sending the A9-Short-Data Ack message to the PCF. In this case, the A9-Short-Data Ack message contains a cause value indicating if the data was successfully delivered. If the SDB/DoS data was successfully delivered to the MS, the PCF proceeds to flush the data from its buffer. If the data could not be delivered to the MS, the PCF may initiate a re-activation of the packet data session to deliver the packet data. 2.6.2.2 Failure Operation None.
16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33
34 35
36
...
3.1.1 A9-Setup-A8 This message is sent from the BS to the PCF to request the establishment of an A8 connection. In HRPD systems, this message shall be used when performing any additions, deletions, remappings, and/or changes in granted QoS of IP flows that require establishment of an A8 connection.
Information Element A9 Message Type Call Connection Reference Section Element Direction Reference 4.2.13 4.2.10 BS -> PCF BS -> PCF M O R Type
37 38 39 40
C-11
3GPP2 A.S0008-C v2.0

Information Element Correlation ID Mobile Identity (IMSI) Mobile Identity (ESN) CON_REF Quality of Service Parameters A9 Cell Identifier A8 Traffic ID Service Option A9 Indicators User Zone ID IS-2000 Service Configuration Record Access Network Identifiers PDSN Address Anchor PDSN Address Anchor P-P Address SR_ID Mobile Identity (MEID) Additional A8 Traffic ID Forward QoS Information Reverse QoS Information
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22
Section Element Direction Reference 4.2.11 4.2.2 4.2.2 4.2.14 4.2.7 4.2.15 4.2.16 4.2.8 4.2.17 4.2.6 4.2.20 4.2.19 4.2.5 4.2.22 4.2.12 4.2.4 4.2.2 4.2.32 4.2.34 4.2.35 BS -> PCF BS -> PCF BS -> PCF BS -> PCF BS -> PCF BS -> PCF BS -> PCF BS -> PCF BS -> PCF BS -> PCF BS -> PCF BS -> PCF BS -> PCF BS -> PCF BS -> PCF BS -> PCF BS -> PCF BS -> PCF BS -> PCF BS -> PCF Oa O O O
k b l c
Type C R C R C R R
o
O O O O O O O O O O O O O O O
R R C C C C C C CR C C C C
d e
f g h i j b m,p n,p n,p
a. If this element is included in this message, its value shall be returned in the corresponding element in the A9-Connect-A8 or A9-Release-A8 Complete message sent in response to this message. b. If an additional occurrence of the Mobile Identity information element (in addition to the Mobile Identity Type, IMSI) is included, it shall contain the indicated Mobile Identity Type of the MS/AT. Inclusion of ESN, MEID or both in this message is a network operator decision. c. This information element is included if QoS 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 IE shall not be included in HRPD messages. d. The User Zone ID is included if received from the MS. This IE shall not be included in HRPD messages. e. This information element may be omitted if the BS does not possess this information at the time the message is created. This IE shall not be included in HRPD messages. f. The Previous Access Network Identifiers are included if received from the MS or the MSC. g. This is the A11 interface IP address of the source PDSN. In 1x systems, tThis element is only present if the BS received this information from the source BS as part of a hard or fast handoff request. In HRPD systems, if this IE is included in the A13-Session Information Response message or in the A16-Session Transfer Request message, then this IE is included and contains the value received in that message. h. This is the A11 interface IP address of the anchor PDSN. This element is only present if the BS received this information from the source BS as part of a fast handoff request. This IE shall not be included in HRPD messages. C-12
3GPP2 A.S0008-C v2.0

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
i.
This is the P-P interface IP address of the anchor PDSN. This element is only present if the BS received this information from the source BS as part of a fast handoff request. This IE shall not be included in HRPD messages. This element specifies the SR_ID of the service instance in the Service Option element. In HRPD systems, the SR_ID shall be set to 01H (the main service connection). If this element is included in this message, the PCF should not stop data transmission over A8 connections indicated by this IE. Multiple instances of this IE may be included in the message. In HRPD systems, the IS-2000 CON_REF field of this IE shall be set to 00H for padding.
j.
k. In HRPD systems, this IE shall be set to the MN ID, associated with the A10 connection. l. m. In HRPD systems, this IE shall include all auxiliary A8 connections (existing connections to keep as well as new connections to establish) associated with the AT. A8 connections to be released shall be omitted. n. In HRPD systems, this IE shall include the IP flow-to-service connection mapping for all IP flows in the specified direction (existing IP flows to keep as well as new IP flows to establish) associated with the AT. IP flows to be released shall be omitted. Existing IP flows may be remapped to a different A8 connection and may have a change in granted QoS. o. In HRPD systems, this is the service option of the main service connection. p. This IE is included if the information is available at the BS. The following table shows the bitmap layout for the A9-Setup-A8 message.
3.1.1 7 (MSB) (MSB) (MSB) 6 5 4 A9-Setup-A8 3 2 1 0 Octet 1 1 2 3 (LSB) Generating Entity ID = <any value> (LSB) Call Connection Reference = <any value> 4 5 6 7 8 9 (LSB) (MSB) Correlation ID: A9 Element Identifier = [13H] Length = [04H] Correlation Value = <any value> 10 1 2 3 4 5 (LSB) Mobile Identity (IMSI): A9 Element Identifier = [0DH] Length = [06H-08H] (10-15 digits) Identity Digit 1 = [0H-9H] (BCD) Odd/even Indicator = [1,0] Type of Identity = [110] (IMSI) 6 1 2 3
19
A9 Message Type = [01H] A9 Element Identifier = [3FH] Length = [08H] Market ID = <any value>
Call Connection Reference:
C-13
3GPP2 A.S0008-C v2.0

3.1.1 7 6 5 4 Identity Digit 3 = [0H-9H] (BCD) A9-Setup-A8 3 2 1 0 Octet 4 Identity Digit 2 = [0H-9H] (BCD)
Identity Digit N+1 = [0H-9H] (BCD) Identity Digit N+3 = [0H-9H] (BCD) (if odd number of digits) = [1111] (if even number of digits) Identity Digit N = [0H-9H] (BCD) Identity Digit N+2 = [0H-9H] (BCD)
n n+1
1 2 3
(MSB)
4 5 6 (LSB) 7 1 2 3 1 2 3 1 2 3 4 5 (LSB) 6 7 8 1 2 3 4 (LSB) 5 6 7 8 (LSB) 9
CON_REF:
Length = [01H] IS-2000 CON_REF = [00H FFH] Quality of Service Parameters: Reserved = [0000] A9 Cell Identifier: A9 Element Identifier = [07H] Non-Assured Mode Packet Priority = [0000 1101] A9 Element Identifier = [06H] Length = [06H] Cell Identification Discriminator = [07H] (MSB) MSCID = <any value> Length = [01H]
(MSB) A8 Traffic ID:
Cell = [001H-FFFH] (LSB) Length = [0CH] A8 transport protocol stack = [01H] (GRE/IP) Sector = [0H-FH] (0H = Omni) A9 Element Identifier = [08H]
(MSB) (MSB)
Protocol Type = [88 81H] (Unstructured byte stream) Key = <any value>
C-14
3GPP2 A.S0008-C v2.0

3.1.1 7 (MSB) 6 5 4 A9-Setup-A8 3 2 1 0 Octet 10 11 12 13 (LSB) (MSB) Service Option: A9 Element Identifier = [03H] Service Option (LSB) 14 1 2 3
Address Type = [01H] (IPv4) IP Address = <any value>
= [00 21H (3G High Speed Packet Data), 00 3CH (Link Layer Assisted Header Removal) 00 3DH (Link Layer Assisted RObust Header Compression)] for 1x systems = [00 3BH (HRPD Main Service Connection), 00 47H (AltPPP operation)] for HRPD systems QoS Mode = [0, 1] A9 Indicators: A9 Element Identifier = [05H] Length = [0102H] Packet GRE SDB/DoS Boundary Segment. Supported = [0,1] Supported = Supported [0] = [0,1] (ignored) Reserved =0 (MSB) Reserved =0 Reserved =0 CCPD Mode = [0,1] Emergency Data Services Ready Reserved = Indicator [0,1] = [0,1] Reserved Reserved =0 =0
1 2 Handoff Indicator = [0, 1] 3
Reserved =0
Reserved =0
Buffer Transfer = [0, 1]
User Zone ID:
A9 Element Identifier = [02H] UZID = <any value> (LSB)
1 2 3 4 1 2 3 4
Length = [02H]
IS-2000 Service Configuration Record: Reserved = [0000 0]
A9 Element Identifier = [0EH] Bit-Exact Length Fill Bits = [000 111]
Bit-Exact Length Octet Count = <variable>
(MSB) IS-2000 Service Configuration Record Content = <any value> Seventh Fill Bit if needed = [0 (if used as a fill bit)]
Reserved = [0]
First Fill Bit if needed = [0 (if used as a fill bit)] k
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)]
Access Network Identifiers: (MSB)
A9 Element Identifier = [20H] SID = <any value> (LSB)
1 2 3 4 5
Length = [05H]
(MSB)
NID = <any value>
C-15
3GPP2 A.S0008-C v2.0

3.1.1 7 6 5 4 A9-Setup-A8 3 2 1 0 (LSB) PZID = <any value> (MSB) PDSN Address: A9 Element Identifier = [14H] Length = [04H] PDSN Address = <any value> Octet 6 7 1 2 3 4 5 (LSB) (MSB) Anchor PDSN Address: A9 Element Identifier = [30H] Length = [04H] Anchor PDSN Address = <any value> 6 1 2 3 4 5 (LSB) (MSB) Anchor P-P Address: A9 Element Identifier = [40H] Length = [04H] Serving P-P IP Address = <any value> 6 1 2 3 4 5 (LSB) SR_ID: A9 Element Identifier = [0BH] Length = [01H] SR_ID = [01H 1FH] Reserved = [0000 0] Length = [08H] MEID Hex Digit 1 = [0H-FH] Odd/Even Indicator = 0 Type of Identity = [001] (MEID) IS-2000 SR_ID = [001 - 110] Mobile Identity (MEID): A9 Element Identifier = [0DH] 6 1 2 3 3 1 2 3
MEID Hex Digit 3 = [0H-FH] MEID Hex Digit 5 = [0H-FH] MEID Hex Digit 7 = [0H-FH] MEID Hex Digit 9 = [0H-FH] MEID Hex Digit 11 = [0H-FH] MEID Hex Digit 13 = [0H-FH] Fill = [FH] Additional A8 Traffic ID:
MEID Hex Digit 2 = [0H-FH] MEID Hex Digit 4 = [0H-FH] MEID Hex Digit 6 = [0H-FH] MEID Hex Digit 8 = [0H-FH] MEID Hex Digit 10 = [0H-FH] MEID Hex Digit 12 = [0H-FH] MEID Hex Digit 14 = [0H-FH] A9 Element Identifier = [92H] Length = [variable]
4 5 6 7 8 9 10 1 2
A8 Traffic ID Entry { 1-30 :
C-16
3GPP2 A.S0008-C v2.0

3.1.1 7 6 5 4 A9-Setup-A8 3 2 1 0 Octet n n+1 n+2
Entry Length = [0FH] SR_ID = [02H-1FH] (MSB) Service Option = [00 40H (HRPD Auxiliary Service Connection with higher layer framing for packet synchronization), 00 43H (HRPD Auxiliary Service Connection without higher layer framing for packet synchronization)] (LSB) A8 transport protocol stack = [01H] (GRE/IP) (MSB) (MSB) Protocol Type = [88 81H] (Unstructured byte stream) (LSB) Key = <any value>
n+3 n+4 n+5 n+6 n+7 n+8 n+9
(LSB) Address Type = [01H] (IPv4) (MSB) IP Address = <any value>
n+10 n+11 n+12 n+13 n+14
(LSB) Forward ROHC Info{1: Forward ROHC Info Length = <variable> (MSB) (MSB) LargeCIDs = [0,1] Forward Profile { Forward ProfileCount: (MSB) } Forward Profile } Forward ROHC Info Reverse ROHC Info{1: Reverse ROHC Info Length = <variable> (MSB) (MSB) Reverse MaxCID = <any value> (LSB) Reverse MRRU = <any value> (LSB) Forward Profile = <any value encoded as specified in [23]> (LSB) Forward MaxCID = <any value> (LSB) Forward MRRU = <any value> (LSB) Reserved = [000 0000] Forward ProfileCount = <any value>
n+15 p p+1 p+2 p+3 p+4 p+5 p+6 q q+1
p p+1 p+2 p+3 p+4
C-17
3GPP2 A.S0008-C v2.0

3.1.1 7 Reverse LargeCI Ds = [0,1] Reverse Profile { Reverse ProfileCount: (MSB) } Reverse Profile } Reverse ROHC Info } A8 Traffic ID Entry Forward QoS Information: A9 Element Identifier = [8EH] Length = [variable] Forward QoS Information Entry { 1-31: Entry Length = [variable] SR_ID = [01H-1FH]
Use IP Flow Discrimination = [0,1]
A9-Setup-A8 3 2 1 0 Octet p+5
Reserved = [000 0000]
Reverse ProfileCount = <any value> Reverse Profile = <any value encoded as specified in [23]> (LSB)
p+6 q q+1
1 2 j j+1 j+2
DSCP Included = [0,1]
Reserved = [00 0000]
Reserved = [000] Forward Flow Entry { Forward Flow Count :
Forward Flow Count = [1 31] Entry Length = [variable] Forward Flow ID = [00H FFH]
j+3 k k+1 Flow State = [0, 1] k+2
Reserved = [0]
DSCP = [00H 3FH]
Forward Requested QoS Length = [variable] (MSB) Forward Requested QoS = <any value>
k+3 k+4
(LSB) Forward Granted QoS Length = [variable] (MSB) Forward Granted QoS = <any value>
m m+1 m+2
(LSB) } Forward Flow Entry } Forward QoS Information Entry Reverse QoS Information: A9 Element Identifier = [8FH] Length = [variable] Reverse QoS Information Entry { 1-31: Entry Length = [variable] SR_ID = [01H-1FH]
1 2 j j+1
C-18
3GPP2 A.S0008-C v2.0

3.1.1 7 6 Reserved = [000] Reverse Flow Entry { Reverse Flow Count : Entry Length = [variable] Reverse Flow ID = [00H FFH] Reserved = [0000 000] Flow State = [0, 1] k k+1 k+2 5 4 A9-Setup-A8 3 2 1 0 Octet j+2 Reverse Flow Count = [1 31]
Reverse Requested QoS Length = [variable] (MSB) Reverse Requested QoS = <any value>
k+3 k+4
(LSB) Reverse Granted QoS Length = [variable] (MSB) Reverse Granted QoS = <any value>
m m+1 m+2
(LSB) } Reverse Flow Entry } Reverse QoS Information Entry

1
2 3
3.1.2
A9-Connect-A8
This message is sent from the PCF to the BS to complete the setup of the A8 connection.
Information Element A9 Message Type Call Connection Reference Correlation ID Mobile Identity (IMSI) Mobile Identity (ESN) CON_REF A8 Traffic ID Cause PDSN Address Anchor PDSN Address Anchor P-P Address SR_ID Service Instance Info Mobile Identity (MEID) Additional A8 Traffic ID A9 Indicators Subscriber QoS Profile Section Element Direction Reference 4.2.13 4.2.10 4.2.11 4.2.2 4.2.2 4.2.14 4.2.16 4.2.3 4.2.5 4.2.22 4.2.12 4.2.4 4.2.25 4.2.2 4.2.32 4.2.17 4.2.36 PCF -> BS PCF -> BS PCF -> BS PCF -> BS PCF -> BS PCF -> BS PCF -> BS PCF -> BS PCF -> BS PCF -> BS PCF -> BS PCF -> BS PCF -> BS PCF -> BS PCF -> BS PCF -> BS PCF -> BS M O O
a h b i
Type
R C R C R R R
c d e
O O O O O O O O O O O O
C C C CR C C C C C
f g b j k l
C-19
3GPP2 A.S0008-C v2.0

Information Element ROHC Configuration Parameters
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
Section Element Direction Reference 4.2.33 PCF -> BS Om
Type C
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. If an additional occurrence of the Mobile Identity information element (in addition to the Mobile Identity Type, IMSI) is included, it shall contain the indicated Mobile Identity Type of the MS. Inclusion of ESN, MEID or both in this message is a network operator decision. c. This is the A11 interface IP address of the target PDSN that terminates the A10 connection corresponding to the just-established A8 connection. If an A10 connection has been established, this element is included in this message and saved by the BS, and included in the Handoff Required message in the event of a hard handoff. d. This is the A11 interface IP address of the anchor PDSN. This element shall be included if the Anchor P-P Address is included. During a fast handoff, it shall contain the same value as the Anchor PDSN Address received in the A9-Setup-A8 message; otherwise it shall be set to the same value as the PDSN Address. It is saved by the BS and included in the Handoff Required message in the event of a fast handoff. During a fast handoff, inclusion of this field indicates acceptance of the fast handoff. This IE shall not be included in HRPD messages. e. This is the IP address for establishing P-P connections to the serving PDSN. This element shall be included if fast handoff is supported and if the value was received from the PDSN. It is saved by the BS and included in the Handoff Required message in the event of a fast handoff. During a fast handoff, inclusion of this field indicates acceptance of the fast handoff. This IE shall not be included in HRPD messages. f. In 1x systems, tThis element specifies the SR_ID of the connected service instance. In HRPD systems, the SR_ID shall be set to 01H (the main service connection). If this element is included in this message, the PCF should not stop data transmission over A8 connections indicated by this IE. Multiple instances of this IE may be included in the message.
g. This element identifies all service instances for which the PCF has an A10 connection, excluding the service instance identified by the SR_ID information element. This element shall be included on transition of the packet data session to the Active State, i.e., when the first A8 connection of a packet data session is being established, but not during handoff (i.e., the Handoff Indicator in the A9-SetupA8 message was set to 1). This IE shall not be included for HRPD messages. h. This IE shall be set to the MN ID, associated with the A10 connection, in HRPD messages. i. j. The IS-2000 CON_REF field of this IE shall be set to 00H for padding, in HRPD messages. This IE shall be included if it was included in the corresponding A9-Setup-A8 message. The number of A8 connections included in this IE shall be same as the number of connections included in the Additional A8 Traffic ID IE in the corresponding A9-Setup-A8 message if PCF can support all the additional connections. This IE is included if this information is available.
k. This IE shall be included if PCF has enabled packet boundary indications. l. m. This IE is included if this information is received from the PDSN. It conveys the ROHC configuration parameters supported by the PDSN when using ROHC on SO67 with header compression at the PDSN.
C-20
3GPP2 A.S0008-C v2.0

1
The following table shows the bitmap layout for the A9-Connect-A8 message.
3.1.2 7 (MSB) (MSB) (MSB) 6 5 4 A9-Connect-A8 3 2 1 0 Octet 1 1 2 3 (LSB) Generating Entity ID = <any value> (LSB) Call Connection Reference = <any value> 4 5 6 7 8 9 (LSB) (MSB) Correlation ID: A9 Element Identifier = [13H] Length = [04H] Correlation Value = <any value> 10 1 2 3 4 5 (LSB) Mobile Identity (IMSI): A9 Element Identifier = [0DH] Length = [06H-08H] (10-15 digits) Identity Digit 1 = [0H-9H] (BCD) Odd/even Indicator = [1,0] Type of Identity = [110] (IMSI) 6 1 2 3
n n+1
1 2 3
(MSB)
4 5 6 (LSB) 7 1 2
CON_REF:
Length = [01H]
C-21
3GPP2 A.S0008-C v2.0

3.1.2 7 6 5 4 A9-Connect-A8 3 2 1 0 Octet 3 1 2 3 4 (LSB) (MSB) Key = <any value> 5 6 7 8 (LSB) Address Type = [01H] (IPv4) (MSB) IP Address = <any value> 9 10 11 12 13 (LSB) ext = [0] Cause: A9 Element Identifier = [04H] Length = [01H] Cause Value = [13H (Successful operation), 7AH (Data ready to send), 03H (Partial connection establishment)] (MSB) PDSN Address: A9 Element Identifier = [14H] Length = [04H] PDSN Address = <any value> 14 1 2 3
IS-2000 CON_REF = [00H FFH] A8 Traffic ID: A9 Element Identifier = [08H] Length = [0CH] A8 transport protocol stack = [01H] (GRE/IP) (MSB) Protocol Type = [88 81H] (Unstructured byte stream)
1 2 3 4 5 (LSB) 6 1 2 3 4 5 (LSB) 6 1 2 3 4 5 (LSB) 6
(MSB)
Anchor PDSN Address: A9 Element Identifier = [30H] Length = [04H] Anchor PDSN Address = <any value>
(MSB)
Anchor P-P Address:
Length = [04H] Anchor P-P Address = <any value>
C-22
3GPP2 A.S0008-C v2.0

3.1.2 7 6 5 4 A9-Connect-A8 3 2 1 0 Octet 1 2 3 IS-2000 SR_ID = [001 - 011] A9 Element Identifier = [41H] SR_ID-3 = [0,1] SR_ID-2 = [0,1] SR_ID-1 = [0,1] 3 1 2 3 4
SR_ID: A9 Element Identifier = [0BH] Length = [01H] SR_ID = [01H 1FH]
Reserved = [0000 0] Service Instance Info: Reserved=[0000 0] (MSB) Length = [00-0FH]
Service Option 1 = [0021H (3G High Speed Packet Data) 003CH (Link Layer Assisted Header Removal) 003DH (Link Layer Assisted Robust Header Compression (LLA-ROHC))] (LSB)
(MSB) Service Option n = [0021H (3G High Speed Packet Data) 003CH (Link Layer Assisted Header Removal) 003DH (Link Layer Assisted Robust Header Compression (LLA-ROHC))] (LSB) Mobile Identity (MEID): A9 Element Identifier = [0DH] Length = [08H] MEID Hex Digit 1 = [0H-FH] Odd/Even Indicator = 0 Type of Identity = [001] (MEID)
2n+2
2n+3 1 2 3
4 5 6 7 8 9 10 1 2 n n+1 n+2
A8 Traffic ID Entry { 1-30 : Entry Length = [0FH] SR_ID = [02H-1FH] (MSB) Service Option = [00 40H (HRPD Auxiliary Service Connection with higher layer framing for packet synchronization), 00 43H (HRPD Auxiliary Service Connection without higher layer framing for packet synchronization) ] (LSB)
n+3
C-23
3GPP2 A.S0008-C v2.0

3.1.2 7 (MSB) (MSB) 6 5 4 A9-Connect-A8 3 2 1 0 Octet n+4 n+5 (LSB) Key = <any value> n+6 n+7 n+8 n+9 (LSB) Address Type = [01H] (IPv4) (MSB) IP Address = <any value> n+10 n+11 n+12 n+13 n+14 (LSB) } A8 Traffic ID Entry A9 Indicators: A9 Element Identifier = [05H] CCPD Mode = [0] (ignored) Reserved Data Handoff = [0] Ready Indicator = [0] (ignored) Indicator = [0] (ignored) (ignored) 1 2 3 Length = [01H] QoS Packet SDB/DoS GRE Mode = Boundary Segment Supported [0] Supported Supported = [0] = [0,1] (ignored) (ignored) = [0] (ignored) (MSB) n+15
A8 transport protocol stack = [01H] (GRE/IP) Protocol Type = [88 81H] (Unstructured byte stream)
Subscriber QoS Profile: A9 Element Identifier = [90H] Length = [variable] Subscriber QoS Profile = <any value>
1 2 3 4
(LSB) (MSB) (MSB) LargeCI Ds = [0,1] Profile {ProfileCount: (MSB) } Profile Profile = <any value encoded as specified in [23]> (LSB) ROHC Configuration Parameters: A9 Element Identifier = [93H] Length = <variable> MaxCID = <any value> (LSB) MRRU = <any value> (LSB) Reserved = [000 0000]
n 1 2 3 4 5 6 7
ProfileCount = <any value>
8 n n+1
C-24
3GPP2 A.S0008-C v2.0

1 2
3 4 5
3.1.3
A9-BS Service Request
This message is sent from the PCF to the BS to request re-activation of a dormant PDSI. In HRPD systems, this message requests re-activation of all service connections for the packet data session.
Information Element A9 Message Type Correlation ID Mobile Identity (IMSI) Mobile Identity (ESN) Service Option Data Count SR_ID Mobile Identity (MEID) A9 Indicators Section Element Direction Reference 4.2.13 4.2.11 4.2.2 4.2.2 4.2.8 4.2.18 4.2.4 4.2.2 4.2.17 PCF -> BS PCF -> BS PCF -> BS PCF -> BS PCF -> BS PCF -> BS PCF -> BS PCF -> BS PCF -> BS M Oa O O O O O
e b
Type
C R C R C CR C C
f c d b g
6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
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. If an additional occurrence of the Mobile Identity information element (in addition to the Mobile Identity Type, IMSI) is included, it shall contain the indicated Mobile Identity Type of the MS. Inclusion of ESN, MEID or both 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. In 1x systems, tThis element specifies the SR_ID of the service instance in the Service Option element. In HRPD systems, the SR_ID shall be set to 01H (the main service connection). If this element is included in this message, the PCF should not stop data transmission over A8 connections indicated by this IE. Multiple instances of this IE may be included in the message. e. In HRPD systems, this IE shall be set to the MN ID associated with the A10 connection. f. In 1x systems, this IE specifies the service option value of the PDSI to be re-activated. In HRPD systems, this is the service option of the main service connection.
g. This IE shall be included if PCF has enabled HRPD Indicators. The following table shows the bitmap layout for the A9-BS Service Request message.
3.1.3 7 6 (MSB) 5 4 A9-BS Service Request 3 2 1 0 Octet 1 1 2 3 4 5
22
A9 Message Type = [06H] Length = [04H] Correlation Value = <any value>
C-25
3GPP2 A.S0008-C v2.0

3.1.3 7 6 5 4 A9-BS Service Request 3 2 1 0 (LSB) Mobile Identity (IMSI): A9 Element Identifier = [0DH] Length = [06H-08H] (10-15 digits) Identity Digit 1 = [0H-9H] (BCD) Odd/even Indicator = [1,0] Type of Identity = [110] (IMSI) Octet 6 1 2 3
n n+1
1 2 3
(MSB)
4 5 6 (LSB) 7 1 2 (LSB) 3
(MSB)
Service Option: A9 Element Identifier = [03H] Service Option
= [00 21H (3G High Speed Packet Data)] for 1x systems = [00 3BH (HRPD Main Service Connection), 00 47H (AltPPP operation)] for HRPD systems Data Count: A9 Element Identifier = [09H] Length = [02H] Count = <any value>
1 2 3 4 1 2 3
SR_ID: A9 Element Identifier = [0BH] Length = [01H] SR_ID = [01H 1FH] Reserved = [0000 0] Length = [08H] MEID Hex Digit 1 = [0H-FH] Odd/Even Indicator = 0 Type of Identity = [001] (MEID) IS-2000 SR_ID = [001 - 011] Mobile Identity (MEID): A9 Element Identifier = [0DH]
3 1 2 3
MEID Hex Digit 3 = [0H-FH] MEID Hex Digit 5 = [0H-FH]
MEID Hex Digit 2 = [0H-FH] MEID Hex Digit 4 = [0H-FH]
4 5
C-26
3GPP2 A.S0008-C v2.0

3.1.3 7 6 5 4 MEID Hex Digit 7 = [0H-FH] MEID Hex Digit 9 = [0H-FH] MEID Hex Digit 11 = [0H-FH] MEID Hex Digit 13 = [0H-FH] Fill = [FH] A9-BS Service Request 3 2 1 0 Octet 6 7 8 9 10 1 2 3 MEID Hex Digit 6 = [0H-FH] MEID Hex Digit 8 = [0H-FH] MEID Hex Digit 10 = [0H-FH] MEID Hex Digit 12 = [0H-FH] MEID Hex Digit 14 = [0H-FH] Length = [01H] GRE SDB/DoS CCPD Emergency Data Ready Handoff QoS Mode Packet Boundary Segment. Supported = Mode = [0] Services = Indicator = Indicator = = [0] [0] (ignored) [0] [0] [0] (ignored) Supported Supported (ignored) (ignored) (ignored) (ignored) = [0] = [0] (ignored) (ignored)
1
A9 Indicators: A9 Element Identifier = [05H]
2 3 4
3.1.4
A9-BS Service Response
This message is sent from the BS to the PCF to acknowledge the receipt and processing of the A9-BS Service Request message.
Information Element A9 Message Type Correlation ID Cause SR_ID Section Element Direction Reference 4.2.13 4.2.11 4.2.3 4.2.4 BS -> PCF BS -> PCF BS -> PCF BS -> PCF M Oa O O
b c
Type
C C CR
5 6 7 8 9 10 11
a. This element shall only be included if it was also included in the A9-BS Service Request message. This element shall be set to the value received in that message. b. This element shall only be included if the BS does not grant the A9-BS Service Request. c. This element indicates the SR_ID of the service instance that was set up. If this element is included in this message, the PCF should not stop data transmission over A8 connections indicated by this IE. Multiple instances of this IE may be included in the message. The following table shows the bitmap layout for the A9-BS Service Response message.
3.1.4 7 6 (MSB) 5 4 A9-BS Service Response 3 2 1 0 Octet 1 1 2 3 4 5 (LSB) 6
12
A9 Message Type = [07H] Length = [04H] Correlation Value = <any value>
C-27
3GPP2 A.S0008-C v2.0

3.1.4 7 6 ext = [0] 5 4 A9-BS Service Response 3 2 1 0 Octet 1 2 3
Cause: A9 Element Identifier = [04H] Length = [01H] Cause Value = [08H (MS busy), 11H (Service option not available)]
1 2 3
Reserved = [0000 0]
1
IS-2000 SR_ID = [001 - 011]
...
3.2.1 A9-Release-A8 This message is sent from the BS to the PCF to release an A8 connection. In HRPD systems, this message shall be used when performing any additions, deletions, remappings, and/or changes in granted QoS of IP flows that require release of one or more A8 connections but no A8 connection establishment. (For A8 connection release with A8 connection establishment, refer to section 3.1.1.).
Information Element A9 Message Type Call Connection Reference Correlation ID Mobile Identity (IMSI) Mobile Identity (ESN) CON_REF A8 Traffic ID Cause Active Connection Time in Seconds SR_ID Mobile Identity (MEID) Additional A8 Traffic ID Forward QoS Information Reverse QoS Information Section Element Direction Reference 4.2.13 4.2.10 4.2.11 4.2.2 4.2.2 4.2.14 4.2.16 4.2.3 4.2.1 4.2.4 4.2.2 4.2.32 4.2.34 4.2.35 BS -> PCF BS -> PCF BS -> PCF BS -> PCF BS -> PCF BS -> PCF BS -> PCF BS -> PCF BS -> PCF BS -> PCF BS -> PCF BS -> PCF BS -> PCF BS -> PCF M O O O O O O O O O O O O O
a f b g h c d e,h b i j j
2 3 4 5 6
Type
R C R C R R R R CR C C C C
7 8 9 10 11 12 13 14 15
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. If an additional occurrence of the Mobile Identity information element (in addition to the Mobile Identity Type, IMSI) is included, it shall contain the indicated Mobile Identity Type of the MS. Inclusion of ESN, MEID or both in this message is a network operator decision. c. The cause value Normal Call Release indicates that the PDSI has been released and therefore the A10 resources associated with this service instance should be dropped. If the cause value indicates Packet C-28
3GPP2 A.S0008-C v2.0

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22
Data Session Release, all services have been released by the MS and therefore all A10 connections associated with the MS shall be released. If the cause value indicates a hard handoff failure, the PCF shall not release any A10 connection associated with the packet data session (intra-PCF hard handoff failure). In HRPD systems, any cause value other than Partial connection release indicates that all A8 connections associated with the AT shall be released. d. This element shall be included to indicate the active connection time for a traffic channel. For HRPD systems, this IE indicates the current value of the active connection time for the traffic channel at the time this message is sent. e. In 1x systems, tThis element specifies the SR_ID of the service instance to be released. f. This IE shall be set to the MN ID, associated with the A10 connection, in HRPD messages. g. The IS-2000 CON_REF field of this IE shall be set to 00H for padding, in HRPD messages. h. In HRPD systems, the SR_ID shall be set to 01H (the main service connection). If this element is included in this message, the PCF should not stop data transmission over A8 connections indicated by this IE. Multiple instances of this IE may be included in the message. i. In HRPD systems, this IE shall be included if the Cause value is set to Partial connection release. It specifies all auxiliary A8 connections to keep. A8 connections to be released shall be omitted. This IE shall be omitted when releasing all A8 connections for the AT. In HRPD systems, this IE shall include the IP flow-to-service connection mapping for all IP flows in the specified direction (IP flows to keep) associated with the AT. IP flows to be released shall be omitted. Existing IP flows may be remapped to a different A8 connection and may have a change in granted QoS.
j.
23
The following table shows the bitmap layout for the A9-Release-A8 message.
3.2.1 7 (MSB) (MSB) (MSB) 6 5 4 A9-Release-A8 3 2 1 0 Octet 1 1 2 3 (LSB) Generating Entity ID = <any value> (LSB) Call Connection Reference = <any value> 4 5 6 7 8 9 (LSB) (MSB) Correlation ID: A9 Element Identifier = [13H] Length = [04H] Correlation Value = <any value> 10 1 2 3 4 5 (LSB) Mobile Identity (IMSI): A9 Element Identifier = [0DH] 6 1
C-29
3GPP2 A.S0008-C v2.0

3.2.1 7 6 5 4 A9-Release-A8 3 Odd/even Indicator = [1,0] 2 1 Type of Identity = [110] (IMSI) 0 Octet 2 3
Length = [06H-08H] (10-15 digits) Identity Digit 1 = [0H-9H] (BCD)
n n+1
1 2 3
(MSB)
4 5 6 (LSB) 7 1 2 3 1 2 3 4 (LSB) 5 6 7 8 (LSB) 9 10 11 12 13 (LSB) 14 1 2
CON_REF:
Length = [01H] IS-2000 CON_REF = [00H FFH] A8 Traffic ID: A9 Element Identifier = [08H] Length = [0CH] A8 transport protocol stack = [01H] (GRE/IP) (MSB) (MSB) Protocol Type = [88 81H] (Unstructured byte stream) Key = <any value>
Address Type = [01H] (IPv4) (MSB) IP Address = <any value>
Cause: A9 Element Identifier = [04H] Length = [01H]
C-30
3GPP2 A.S0008-C v2.0

3.2.1 7 ext = [0] 6 5 4 A9-Release-A8 3 2 1 0 Octet 3
Cause Value = [01H (Partial connection release), 0BH (Handoff successful), 0FH (Packet data session release), 10H (Packet call going dormant), 14H (Normal call release), 1AH (Authentication failure), 1DH (Hard handoff failure), 1FH (Air link lost), 20H (Equipment failure)] Active Connection Time in Seconds: Length = [04H] A9 Element Identifier = [0AH]
(MSB)
1 2 3 4 5
Active Connection Time = [00 00 00 00H FF FF FF FFH]
(LSB) SR_ID: A9 Element Identifier = [0BH] Length = [01H] SR_ID = [01H 1FH] Reserved = [0000 0] Length = [08H] MEID Hex Digit 1 = [0H-FH] Odd/Even Indicator = 0 Type of Identity = [001] (MEID) IS-2000 SR_ID = [001 - 011] Mobile Identity (MEID): A9 Element Identifier = [0DH]
6 1 2 3 3 1 2 3
4 5 6 7 8 9 10 1 2 n n+1 n+2
A8 Traffic ID Entry { 1-30 : Entry Length = [0FH] SR_ID = [02H-1FH] (MSB) Service Option = 40H (HRPD Auxiliary Service Connection with higher layer framing for packet synchronization), 00 43H (HRPD Auxiliary Service Connection without higher layer framing for packet synchronization) ]
C-31
3GPP2 A.S0008-C v2.0

3.2.1 7 6 5 4 A9-Release-A8 3 2 1 0 (LSB) A8 transport protocol stack = [01H] (GRE/IP) (MSB) (MSB) Protocol Type = [88 81H] (Unstructured byte stream) (LSB) Key = <any value> Octet n+3 n+4 n+5 n+6 n+7 n+8 n+9 (LSB) Address Type = [01H] (IPv4) (MSB) IP Address = <any value> n+10 n+11 n+12 n+13 n+14 (LSB) } A8 Traffic ID Entry Forward QoS Information: A9 Element Identifier = [8EH] Length = [variable] Forward QoS Information Entry { 1-31: Entry Length = [variable] SR_ID = [01H-1FH] Use IP DSCP Flow Included Discrimina- = [0,1] tion = [0,1] Reserved = [000] Forward Flow Entry { Forward Flow Count : Entry Length = [variable] Forward Flow ID = [00H FFH] Reserved = [0] DSCP = [00H 3FH] Flow State = [0, 1] k k+1 k+2 Reserved = [00 0000] j j+1 j+2 1 2 n+15
Forward Flow Count = [1 31]
j+3
k+3 k+4
m m+1 m+2
(LSB) } Forward Flow Entry } Forward QoS Information Entry
C-32
3GPP2 A.S0008-C v2.0

3.2.1 7 6 5 4 A9-Release-A8 3 2 1 0 Octet 1 2 j j+1 j+2 k k+1 Flow State = [0, 1] k+2
Reverse QoS Information: A9 Element Identifier = [8FH] Length = [variable]
Reverse QoS Information Entry { 1-31: Entry Length = [variable] SR_ID = [01H-1FH] Reserved = [000] Reverse Flow Entry { Reverse Flow Count : Entry Length = [variable] Reverse Flow ID = [00H FFH] Reserved = [0000 000] Reverse Flow Count = [1 31]
k+3 k+4
(LSB) Reverse Granted QoS Length = [variable] (MSB) Reverse Granted QoS = <any value>
m m+1 m+2
(LSB) } Reverse Flow Entry } Reverse QoS Information Entry

1
...
3.2.2 A9-Release-A8 Complete This message is sent from the PCF to the BS either to acknowledge the release of an A8 connection or to indicate that an A8 does not need to be or cannot be set up.
Information Element A9 Message Type Call Connection Reference Correlation ID Cause A9 PDSN Code SR_ID Section Element Direction Reference 4.2.13 4.2.10 4.2.11 4.2.3 4.2.23 4.2.4 PCF -> BS PCF -> BS PCF -> BS PCF -> BS PCF -> BS PCF -> BS M O O O O
a b
3 4 5
Type
R C C C CR
Oc
d
6 7
a. This element shall only be included if it was also included in the A9-Release-A8 message. This element shall be set to the value received in that message.
C-33
3GPP2 A.S0008-C v2.0

1 2 3 4 5 6 7 8 9
b. This information element is present in the case where an A8 connection is not established during a setup request. The element contains a release cause. c. This information element may be present if a code is received from the PDSN. If this element is present the Cause element shall be coded to PCF (or PDSN) resources unavailable or Packet call going dormant. d. In 1x systems, tThis element indicates the SR_ID of the service instance that was released. In HRPD systems, the SR_ID shall be set to 01H (the main service connection). If this element is included in this message, the PCF should not stop data transmission over A8 connections indicated by this IE. Multiple instances of this IE may be included in the message. The following table shows the bitmap layout for the A9-Release-A8 Complete message.
3.2.2 7 (MSB) (MSB) (MSB) 6 5 4 A9-Release-A8 Complete 3 2 1 0 Octet 1 1 2 3 (LSB) Generating Entity ID = <any value> (LSB) Call Connection Reference = <any value> 4 5 6 7 8 9 (LSB) (MSB) Correlation ID: A9 Element Identifier = [13H] Length = [04H] Correlation Value = <any value> 10 1 2 3 4 5 (LSB) ext = [0] Cause: A9 Element Identifier = [04H] Length = [01H] Cause Value = [01H (Partial connection release), 10H (Packet call going dormant), 07H (OAM&P intervention), 1AH (Authentication failure), 20H (Equipment failure), 23H (Authentication required), 24H (Session unreachable), 2AH 32H (PCF resources are not available), 60H (State mismatch), 79H (PDSN resources are not available)] A9 PDSN Code: A9 Element Identifier = [0CH] Length = [01H] 6 1 2 3
10
1 2
C-34
3GPP2 A.S0008-C v2.0

3.2.2 7 6 5 4 A9-Release-A8 Complete 3 2 1 0 Octet 3
PDSN Code = [00H (Registration Accepted), 80H (Registration Denied reason unspecified) 81H (Registration Denied administratively prohibited) 82H (Registration Denied insufficient resources) 83H (Registration Denied mobile node failed authentication) 85H (Registration Denied identification mismatch) 86H (Registration Denied poorly formed request) 88H (Registration Denied unknown PDSN address) 89H (Registration Denied requested reverse tunnel unavailable) 8AH (Registration Denied reverse tunnel is mandatory and T bit not set) 8DH (Registration Denied unsupported vendor ID or unable to interpret data in the CVSE)] SR_ID: A9 Element Identifier = [0BH] Length = [01H] SR_ID = [01H 1FH] Reserved = [0000 0]
1
1 2 3
IS-2000 SR_ID = [001 - 011]
2 3
3.2.3
A9-Disconnect-A8
This message is sent from the PCF to the BS to request the release of an A8 connection.
Information Element A9 Message Type Call Connection Reference Correlation ID Mobile Identity (IMSI) Mobile Identity (ESN) CON_REF A8 Traffic ID Cause A9 PDSN Code SR_ID Mobile Identity (MEID) Section Element Direction Reference 4.2.13 4.2.10 4.2.11 4.2.2 4.2.2 4.2.14 4.2.16 4.2.3 4.2.23 4.2.4 4.2.2 PCF -> BS PCF -> BS PCF -> BS PCF -> BS PCF -> BS PCF -> BS PCF -> BS PCF -> BS PCF -> BS PCF -> BS PCF -> BS M O O
a e b
Type
R C R C R R R
c
O O
O O O O
C CR C
Od O
b
4 5 6 7 8 9 10 11
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. b. If an additional occurrence of the Mobile Identity information element (in addition to the Mobile Identity Type, IMSI) is included, it shall contain the indicated Mobile Identity Type of the MS. Inclusion of ESN, MEID or both in this message is a network operator decision. c. This information element may be present if a release code is received from the PDSN. If this element is present, the Cause element shall be coded to PCF (or PDSN) resources unavailable. C-35
3GPP2 A.S0008-C v2.0

1 2 3 4 5 6
d. In 1x systems, tThis element specifies the SR_ID of the service instance to be disconnected. In HRPD systems, the SR_ID shall be set to 01H (the main service connection). If this element is included in this message, the PCF should not stop data transmission over A8 connections indicated by this IE. Multiple instances of this IE may be included in the message. e. This IE shall be set to the MN ID, associated with the A10 connection, in HRPD messages. f. The IS-2000 CON_REF field of this IE shall be set to 00H for padding, in HRPD messages.
The following table shows the bitmap layout for the A9-Disconnect-A8 message.
3.2.3 7 (MSB) (MSB) (MSB) 6 5 4 A9-Disconnect-A8 3 2 1 0 Octet 1 1 2 3 (LSB) Generating Entity ID = <any value> (LSB) Call Connection Reference = <any value> 4 5 6 7 8 9 (LSB) (MSB) Correlation ID: A9 Element Identifier = [13H] Length = [04H] Correlation Value = <any value> 10 1 2 3 4 5 (LSB) Mobile Identity (IMSI): A9 Element Identifier = [0DH] Length = [06H-08H] (10-15 digits) Identity Digit 1 = [0H-9H] (BCD) Odd/even Indicator = [1,0] Type of Identity = [110] (IMSI) 6 1 2 3
n n+1
Mobile Identity (ESN): A9 Element Identifier = [0DH] Length = [05H] Odd/even Indicator = [0] Type of Identity = [101] (ESN)
1 2 3
C-36
3GPP2 A.S0008-C v2.0

3.2.3 7 (MSB) 6 5 4 A9-Disconnect-A8 3 ESN = <any value> 2 1 0 Octet 4 5 6 (LSB) CON_REF: A9 Element Identifier = [01H] Length = [01H] IS-2000 CON_REF = [00H FFH] A8 Traffic ID: A9 Element Identifier = [08H] Length = [0CH] A8 transport protocol stack = [01H] (GRE/IP) (MSB) (MSB) Protocol Type = [88 81H] (Unstructured byte stream) (LSB) Key = <any value> 7 1 2 3 1 2 3 4 5 6 7 8 (LSB) Address Type = [01H] (IPv4) (MSB) IP Address = <any value> 9 10 11 12 13 (LSB) ext = [0] Cause: A9 Element Identifier = [04H] Length = [01H] Cause Value = [ 14H (Normal call release), 20H (Equipment failure), 07H (OAM&P intervention), 32H2AH (PCF resources are not available), 79H (PCF PDSN) resources are not available)] A9 PDSN Code: A9 Element Identifier = [0CH] Length = [01H] [C1H C2H C3H C4H C5H C6H C7H C8H CAH PDSN Code = (Connection Release - reason unspecified), (Connection Release - PPP time-out ), (Connection Release - registration time-out), (Connection Release - PDSN error), (Connection Release - inter-PCF handoff), (Connection Release - inter-PDSN handoff), (Connection Release - PDSN OAM&P intervention), (Connection Release - accounting error ) (Connection Release user (NAI) authentication failure)] SR_ID: A9 Element Identifier = [0BH] 14 1 2 3
1 2 3
C-37
3GPP2 A.S0008-C v2.0

3.2.3 7 6 5 4 A9-Disconnect-A8 3 2 1 0 Octet 2 3 IS-2000 SR_ID = [001 - 011] Length = [08H] MEID Hex Digit 1 = [0H-FH] Odd/Even Indicator = 0 Type of Identity = [001] (MEID) 3 1 2 3
Length = [01H] SR_ID = [01H 1FH] Reserved = [0000 0] Mobile Identity (MEID): A9 Element Identifier = [0DH]
MEID Hex Digit 3 = [0H-FH] MEID Hex Digit 5 = [0H-FH] MEID Hex Digit 7 = [0H-FH] MEID Hex Digit 9 = [0H-FH] MEID Hex Digit 11 = [0H-FH] MEID Hex Digit 13 = [0H-FH] Fill = [FH]
1
MEID Hex Digit 2 = [0H-FH] MEID Hex Digit 4 = [0H-FH] MEID Hex Digit 6 = [0H-FH] MEID Hex Digit 8 = [0H-FH] MEID Hex Digit 10 = [0H-FH] MEID Hex Digit 12 = [0H-FH] MEID Hex Digit 14 = [0H-FH]
4 5 6 7 8 9 10
...
3.3 A8/A9 Interface Handoff Messages
...
3.3.1 A9-AL (Air Link) Connected This message is sent from the BS to the PCF to indicate that a traffic channel has been established to the MS during hard or fast handoff or in HRPD systems when the AN determines that data flow stopped by the A9-AL Disconnected message from the PCF should resume.
Information Element A9 Message Type Call Connection Reference Correlation ID A8 Traffic ID PDSN Address IS-2000 Service Configuration Record Service Option User Zone ID Quality of Service Parameters Access Network Identifiers Section Element Direction Reference 4.2.13 4.2.10 4.2.11 4.2.16 4.2.5 4.2.20 4.2.8 4.2.6 4.2.7 4.2.19 BS -> PCF BS -> PCF BS -> PCF BS -> PCF BS -> PCF BS -> PCF BS -> PCF BS -> PCF BS -> PCF BS -> PCF M O O O O O O O
b,c f i g h c,d a
4 5 6 7
Type
R C R C R R C R C
O O
8 9 10 11
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. This is the IP address for the A11 interface of the source PDSN. C-38
3GPP2 A.S0008-C v2.0

1 2 3 4 5 6 7 8 9 10 11 12
c. This element shall be omitted if this message is sent as part of a fast handoff because the corresponding A10 connection has already been established. Otherwise, this element shall be included. d. The Access Network Identifiers are those of the source PCF communicated by the source BS via the MSC (Handoff Required, Handoff Requested messages), in 1x systems. e. This information element is included if available to the BS. f. The Bit-Exact Length - Octet Count field and the Bit-Exact Length - Fill Bits field of this IE shall set to 0, in HRPD messages.
g. The UZID field of this IE shall be set to 00H for padding, in HRPD messages. h. The Non-Assured Mode Packet Priority field of this IE shall set to 0H for padding, in HRPD messages. i. In 1x systems, this IE specifies the service option value of the PDSI to be re-activated.
13
The following table shows the bitmap layout for the A9-AL Connected message.
3.3.1 7 (MSB) (MSB) (MSB) 6 5 4 A9-AL (Air Link) Connected 3 2 1 0 Octet 1 1 2 3 (LSB) Generating Entity ID = <any value> (LSB) Call Connection Reference = <any value> 4 5 6 7 8 9 (LSB) (MSB) Correlation ID: A9 Element Identifier = [13H] Length = [04H] Correlation Value = <any value> 10 1 2 3 4 5 (LSB) A8 Traffic ID: A9 Element Identifier = [08H] Length = [0CH] A8 transport protocol stack = [01H] (GRE/IP) (MSB) (MSB) Protocol Type = [88 81H] (Unstructured byte stream) (LSB) Key = <any value> 6 1 2 3 4 5 6 7 8 (LSB) 9
C-39
3GPP2 A.S0008-C v2.0

3.3.1 7 (MSB) 6 5 4 A9-AL (Air Link) Connected 3 2 1 0 Octet 10 11 12 13 (LSB) (MSB) PDSN Address: A9 Element Identifier = [14H] Length = [04H] PDSN Address = <any value> 14 1 2 3 4 5 (LSB) IS-2000 Service Configuration Record: A9 Element Identifier = [0EH] Bit-Exact Length Octet Count = [00H to FFH] Reserved = [0000 0] (MSB) IS-2000 Service Configuration Record Content = <any value> Seventh Fill Bit if needed = [0 (if used as a fill bit)] (MSB) 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)] Bit-Exact Length Fill Bits = [000 to 111] 6 1 2 3 4
Address Type = [01H] (IPv4) IP Address = <any value>
Service Option: A9 Element Identifier = [03H] Service Option (LSB)
1 2 3
= [00 21H (3G High Speed Packet Data), 00 3CH (Link Layer Assisted Header Removal), 00 3DH (Link Layer Assisted RObust Header Compression)] for 1x systems; = [00 3BH (HRPD Main Service Connection), 00 47H (AltPPP operation)] for HRPD systems (MSB) User Zone ID: A9 Element Identifier = [02H] Length = [02H] UZID = <any value>
1 2 3 (LSB) 4 1 2 3 1 2
Quality of Service Parameters: Reserved = [0000]
Length = [01H] Non-Assured Mode Packet Priority = [0000 1101] Length = [05H]
Access Network Identifiers: A9 Element Identifier = [20H]
C-40
3GPP2 A.S0008-C v2.0

3.3.1 7
Reserved = [0]
A9-AL (Air Link) Connected 4 3 2 1 0 Octet 3 (LSB) 4 5 (LSB) 6 7 SID = <any value>
6 (MSB)
(MSB)
NID = <any value> PZID = <any value>
2 3 4 5
3.3.2
A9-AL (Air Link) Connected Ack
This message is sent from the PCF to the BS to acknowledge reception of an A9-AL Connected message. In the case of inter-PCF hard handoff without fast handoff, this message is sent after establishment of the A10 connection.
Information Element A9 Message Type Call Connection Reference Correlation ID PDSN Address Anchor PDSN Address Anchor P-P Address Section Reference 4.2.13 4.2.10 4.2.11 4.2.5 4.2.22 4.2.12 Element Direction PCF -> BS PCF -> BS PCF -> BS PCF -> BS PCF -> BS PCF -> BS M O O O O O
a b c d
Type
R C C C C
6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
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. b. This is the IP address of the A11 interface of the target PDSN. It shall be included in this message unless the information was sent previously in an A9-Connect-A8 message. It is saved by the BS, and included in the Handoff Required message in the event of a hard handoff. c. This is the IP address for the A11 interface of the anchor PDSN. This element shall be included if the Anchor P-P Address is included. If included, it shall be set to the same value as the PDSN Address. It is saved by the BS and included in the Handoff Required message in the event of a fast handoff. This IE shall not be included in HRPD messages. d. This is the IP address for establishing P-P connections to the anchor PDSN. This element shall be included if fast handoff is supported and if the value was received from the PDSN, unless the information was sent previously in an A9-Connect-A8 message. It is saved by the BS and included in the Handoff Required message in the event of a fast handoff. This IE shall not be included in HRPD messages.
21
The following table shows the bitmap layout for the A9-AL Connected Ack message
3.3.2 7 (MSB) 6 5 A9-AL (Air Link) Connected Ack 4 3 2 1 0 Octet 1 1 2 3 A9 Message Type = [09H] A9 Element Identifier = [3FH] Length = [08H] Market ID = <any value>
C-41
3GPP2 A.S0008-C v2.0

3.3.2 7 (MSB) (MSB) 6 5 A9-AL (Air Link) Connected Ack 4 3 2 1 0 (LSB) Generating Entity ID = <any value> (LSB) Call Connection Reference = <any value> Octet 4 5 6 7 8 9 (LSB) (MSB) Correlation ID: A9 Element Identifier = [13H] Length = [04H] Correlation Value = <any value> 10 1 2 3 4 5 (LSB) (MSB) PDSN Address: A9 Element Identifier = [14H] Length = [04H] PDSN Address = <any value> 6 1 2 3 4 5 (LSB) (MSB) Anchor PDSN Address: A9 Element Identifier = [30H] Length = [04H] Anchor PDSN Address = <any value> 6 1 2 3 4 5 (LSB) (MSB) Anchor P-P Address: A9 Element Identifier = [40H] Length = [04H] Serving P-P IP Address = <any value> 6 1 2 3 4 5 (LSB)
1
2 3 4
3.3.3
A9-AL Disconnected
This message is sent from the BS to the PCF to indicate that the traffic channel has been released following a hard handoff.
Information Element A9 Message Type Section Element Direction Reference 4.2.13 BS -> PCF M Type
C-42
3GPP2 A.S0008-C v2.0

Information Element Call Connection Reference Correlation ID A8 Traffic ID SR_ID
1 2 3 4 5
Section Element Direction Reference 4.2.10 4.2.11 4.2.16 4.2.4 BS -> PCF BS -> PCF BS -> PCF BS -> PCF O O O O
b a
Type R C R C
a. If this element is included in this message, its value shall be returned in the corresponding element in the A9-AL Disconnected Ack message sent in response to this message. b. If this element is included in this message, the PCF should not stop data transmission over A8 connections indicated by this IE. Multiple instances of this IE may be included in the message. The following table shows the bitmap layout for the A9-AL Disconnected message.
3.3.3 7 (MSB) (MSB) (MSB) 6 5 4 A9-AL Disconnected 3 2 1 0 Octet 1 1 2 3 (LSB) Generating Entity ID = <any value> (LSB) Call Connection Reference = <any value> 4 5 6 7 8 9 (LSB) (MSB) Correlation ID: A9 Element Identifier = [13H] Length = [04H] Correlation Value = <any value> 10 1 2 3 4 5 (LSB) A8 Traffic ID: A9 Element Identifier = [08H] Length = [0CH] A8 transport protocol stack = [01H] (GRE/IP) (MSB) (MSB) Protocol Type = [88 81H] (Unstructured byte stream) (LSB) Key = <any value> 6 1 2 3 4 5 6 7 8 (LSB) Address Type = [01H] (IPv4) 9 10
A9 Message Type = [0AH] A9 Element Identifier = [3FH] Length = [08H] Market ID = <any value>
C-43
3GPP2 A.S0008-C v2.0

3.3.3 7 (MSB) 6 5 4 A9-AL Disconnected 3 2 1 0 Octet 11 12 13 (LSB) SR_ID: A9 Element Identifier = [0BH] Length = [01H] SR_ID = [01H 1FH]
1
IP Address = <any value>
14 1 2 3
...
3.5 A9 Session Update Procedures
2 3
4 5 6 7 8 9 10 11
3.5.1
A9-Update-A8
This message is sent from the BS to the PCF to indicate a change to the session airlink parameters, whether SDBs may be sent to an MS, whether an SDB was successfully delivered to an MS, or to indicate an authentication failure. This message is also sent from the PCF to the BS to transfer new or updated packet data session parameters to the BS. In HRPD systems, this message shall be used when performing any additions, deletions, remappings, changes in granted QoS, and/or changes in flow state of IP flows, provided no A8 connections are established and no existing A8 connections are released. In HRPD systems, this message is also used to support QoS update by the PDSN.
Information Element A9 Message Type Call Connection Reference Correlation ID Mobile Identity (IMSI) Mobile Identity (ESN) IS-2000 Service Configuration Record Service Option User Zone ID Quality of Service Parameters Cause RN-PDIT SR_ID Mobile Identity (MEID) A9 Indicators PDSN Address Anchor PDSN Address Anchor P-P Address Forward QoS Information Section Reference 4.2.13 4.2.10 4.2.11 4.2.2 4.2.2 4.2.20 4.2.8 4.2.6 4.2.7 4.2.3 4.2.24 4.2.4 4.2.2 4.2.17 4.2.5 4.2.22 4.2.12 4.2.34 Element Direction BS <-> PCF BS <-> PCF BS <-> PCF BS <-> PCF BS -> PCF BS -> PCF BS -> PCF BS -> PCF BS -> PCF BS <-> PCF BS <- PCF BS <-> PCF BS -> PCF BS <-> PCF PCF -> BS PCF -> BS PCF -> BS BS -> PCF M O O O O O O O O
d e a i b c,j c,l c,j c,j
Type
R C R C C C C C R C C R C C C C C C
O O
Ob O
f g h,j h,j k
O O O O
C-44
3GPP2 A.S0008-C v2.0

Information Element Reverse QoS Information Subscriber QoS Profile Forward QoS Update Information Reverse QoS Update Information
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
Section Reference 4.2.35 4.2.36 4.2.38 4.2.39
Element Direction BS -> PCF PCF -> BS PCF -> BS PCF -> BS Ok O O O
h
Type C C C C
m,n m,n
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. If an additional occurrence of the Mobile Identity information element (in addition to the Mobile Identity Type, IMSI) is included, it shall contain the indicated Mobile Identity Type of the MS. Inclusion of ESN, MEID or both in this message is a network operator decision. c. These elements are required when the message is sent from the BS to the PCF unless the message is used to indicate Dormant Power down or Authentication Failure. d. This element is included in the message when the PDSN has sent the parameter to the PCF. e. In 1x systems, tThis element specifies the SR_ID of the service instance in the Service Option element. In HRPD systems, the SR_ID shall be set to 01H (the main service connection). If this element is included in this message, the PCF should not stop data transmission over A8 connections indicated by this IE. Multiple instances of this IE may be included in the message. f. This element is included when used to indicate if the PDSI supports Short Data bursts. In HRPD systems, this element may also be used to provide Emergency Services indication from the BS to the PCF.
g. This element contains the A11 IP address of the PDSN terminating the A10 connection. This element is included when A10 connections were established with a new PDSN during an active packet data session. h. These IEs are included if this information is received from the PDSN. i. j. This IE shall be set to the MN ID, retrieved from AN-AAA, in HRPD messages. This IE shall not be included in HRPD messages.
k. In HRPD systems, this IE shall include the IP flow-to-service connection mapping for all IP flows in the specified direction (existing IP flows to keep as well as new IP flows to establish) associated with the AT. IP flows to be released shall be omitted. Existing IP flows may be remapped to a different A8 connection and may have a change in granted QoS. l. In HRPD systems, this IE shall contain information for the main service connection. m. In HRPD systems, this IE is used when the PDSN updates QoS for one or more IP flows in the specified direction. If there is a Flow Profile ID with the value 0x0000 in the U_QoS_SUB_BLOB for an IP flow, then the AN shall inform the AT that the requested QoS_SUB_BLOB has been added but is invalid for this AN and the AT should not activate the corresponding IP flow. Otherwise upon receipt of the updated QoS, the AN shall change the granted QoS for the corresponding IP flow to the first acceptable Flow Profile ID in the list, irrespective of the contents of the subscriber QoS Profile. A Flow Profile ID shall be considered acceptable if it is supported by the AN, if it matches one of the Flow Profile IDs requested by the AT, and if the call is not in inter-PCF handoff. The target AN shall store the updated QoS lists received from the PCF and use them to grant the QoS irrespective of the contents of the subscriber QoS Profile. n. In HRPD systems, this IE is used to release one or more IP flows in the specified direction. The PCF shall set the FlowProfile ID value to 0x0000 in the Forward/Reverse Updated QoS Sub-BLOB for the IP flow to be released. The PDSN should not use this procedure for flow ID FFH and FEH. C-45
3GPP2 A.S0008-C v2.0

1
The following table shows the bitmap layout for the A9-Update-A8 message.
3.5.1 7 (MSB) (MSB) (MSB) 6 5 4 A9-Update-A8 3 2 1 0 Octet 1 1 2 3 (LSB) Generating Entity ID = <any value> (LSB) Call Connection Reference = <any value> 4 5 6 7 8 9 (LSB) (MSB) Correlation ID: A9 Element Identifier = [13H] Length = [04H] Correlation Value = <any value> 10 1 2 3 4 5 (LSB) Mobile Identity (IMSI): A9 Element Identifier = [0DH] Length = [06H-08H] (10-15 digits) Identity Digit 1 = [0H-9H] (BCD) Odd/even Indicator = [1,0] Type of Identity = [110] (IMSI) 6 1 2 2
A9 Message Type = [0EH] A9 Element Identifier = [3FH] Length = [08H] Market ID = <any value>
n n+1
1 2 3
(MSB)
4 5 6 (LSB) 7 1 2
IS-2000 Service Configuration Record:
Bit-Exact Length Octet Count = <variable>
C-46
3GPP2 A.S0008-C v2.0

3.5.1 7 6 5 Reserved = [0000 0] (MSB) 4 A9-Update-A8 3 2 1 0 Octet 3 4 Bit-Exact Length Fill Bits = [000 111]
IS-2000 Service Configuration Record Content = <any value>
Seventh Fill Bit if needed = [0 (if used as a fill bit)] Sixth Fill Bit if needed = [0 (if used as a fill bit)] Fifth Fill Bit if needed = [0 (if used as a fill bit)] Fourth Fill Bit if needed = [0 (if used as a fill bit)] Third Fill Bit if needed = [0 (if used as a fill bit)] Second Fill Bit if needed = [0 (if used as a fill bit)] First Fill Bit if needed = [0 (if used as a fill bit)] k
(MSB)
Service Option: A9 Element Identifier = [03H] Service Option (LSB)
1 2 3
= [00 21H (3G High Speed Packet Data ) 00 3CH (Link Layer Assisted Header Removal) 00 3DH (Link Layer Assisted RObust Header Compression)] for 1x systems; = [00 3BH (HRPD Main Service Connection), 00 47H (AltPPP operation)] for HRPD systems (MSB) User Zone ID: A9 Element Identifier = [02H] UZID = <any value> Length = [02H]
1 2 3 (LSB) 4 1 2 3 1 2 3
Quality of Service Parameters: Reserved = [0000]
Length = [01H] Non-Assured Mode Packet Priority = [0000 1101] Cause: A9 Element Identifier = [04H] Length = [01H] Ext= [0] Cause Value = [17H (SDB successfully delivered), 19H (Power down from dormant state), 1AH (Authentication failure), 1BH (Capability update), 1CH (Update accounting: late traffic channel setup), 1EH (Update accounting: parameter change), 2EH (QoS update), 7BH (Session parameter update)] RN-PDIT: A9 Element Identifier = [0FH] Length = [01H] RN-PDIT = [01H-FFH] SR_ID: A9 Element Identifier = [0BH] Length = [01H] SR_ID = [01H 1FH]
1 2 3 1 2 3
C-47
3GPP2 A.S0008-C v2.0

3.5.1 7 6 5 Reserved = [0000 0] Length = [08H] MEID Hex Digit 1 = [0H-FH] Odd/Even Indicator = 0 Type of Identity = [001] (MEID) 4 A9-Update-A8 3 2 1 0 Octet 3 1 2 3 IS-2000 SR_ID = [001 - 011]
MEID Hex Digit 3 = [0H-FH] MEID Hex Digit 5 = [0H-FH] MEID Hex Digit 7 = [0H-FH] MEID Hex Digit 9 = [0H-FH] MEID Hex Digit 11 = [0H-FH] MEID Hex Digit 13 = [0H-FH] Fill = [FH] A9 Indicators:
MEID Hex Digit 2 = [0H-FH] MEID Hex Digit 4 = [0H-FH] MEID Hex Digit 6 = [0H-FH] MEID Hex Digit 8 = [0H-FH] MEID Hex Digit 10 = [0H-FH] MEID Hex Digit 12 = [0H-FH] MEID Hex Digit 14 = [0H-FH] A9 Element Identifier = [05H] Data CCPD Emergency Mode = Services Ready Reserved = Indicator [0,1] [0,1] = [0,1] (Ignored) (Ignored) Handoff Indicator = [0,1] (Ignored) Length = [01H]
4 5 6 7 8 9 10 1 2 3
GRE QoS Mode Packet = [0, 1] Boundary Segment. (ignored) Supported Supported [0,1] = [0,1] (ignored) (ignored) (MSB)
SDB/DoS Supported = [0,1]
PDSN Address: A9 Element Identifier = [14H] Length = [04H] PDSN Address = <any value>
1 2 3 4 5 6
(MSB)
Anchor PDSN Address: A9 Element Identifier = [30H] Length = [04H] Anchor PDSN Address = <any value>
1 2 3 4 5 (LSB) 6 1 2 3 4 5 (LSB) 6 1 2
(MSB)
Anchor P-P Address:
Length = [04H] Serving P-P IP Address = <any value>
Forward QoS Information: A9 Element Identifier = [8EH] Length = [variable]
C-48
3GPP2 A.S0008-C v2.0

3.5.1 7 6 5 4 Forward QoS Information Entry { 1-31: Entry Length = [variable] SR_ID = [01H-1FH] Use IP Flow Discrimination = [0,1] DSCP Included= [0,1] Reserved = [00 0000] j j+1 j+2 A9-Update-A8 3 2 1 0 Octet
Reserved = [000] Forward Flow Entry { Forward Flow Count :
Forward Flow Count = [1 31] Entry Length = [variable] Forward Flow ID = [00H FFH]
j+3 k k+1 Flow State = [0, 1] k+2
Reserved
DSCP = [00H 3FH]
k+3 k+4
m m+1 m+2
(LSB) } Forward Flow Entry } Forward QoS Information Entry Reverse QoS Information: A9 Element Identifier = [8FH] Length = [variable] Reverse QoS Information Entry { 1-31: Entry Length = [variable] SR_ID = [01H-1FH] Reserved = [000] Reverse Flow Entry {Reverse Flow Count : Entry Length = [variable] Reverse Flow ID = [00H FFH] Reserved = [0000 000] Flow State = [0, 1] Reverse Flow Count = [1 31]
1 2 j j+1 j+2 k k+1 k+2
k+3 k+4
(LSB)
C-49
3GPP2 A.S0008-C v2.0

3.5.1 7 (MSB) 6 A9-Update-A8 1 0 Octet m+1 m+2
5 4 3 2 Reverse Granted QoS Length = [variable] Reverse Granted QoS = <any value>
(LSB) } Reverse Flow Entry } Reverse QoS Information Entry (MSB) Subscriber QoS Profile: A9 Element Identifier = [90H] Length = [variable] Subscriber QoS Profile = <any value>
1 2 3 4
(LSB) Forward QoS Update Information: A9 Element Identifier = [94H] Length = [variable] Forward Flow Count = [01H-FFH] Forward Flow Entry { Forward Flow Count : Forward Flow ID = [00H FFH] Forward Updated QoS Sub-BLOB Length = [variable] (MSB) Forward Updated QoS Sub-BLOB = <any value>
n 1 2 3 j j+1 j+2
(LSB) } Forward Flow Entry Reverse QoS Update Information: A9 Element Identifier = [95H] Length = [variable] Reverse Flow Count = [01H-FFH] Reverse Flow Entry {Reverse Flow Count : Reverse Flow ID = [00H FFH] Reverse Updated QoS Sub-BLOB Length = [variable] (MSB) Reverse Updated QoS Sub-BLOB = <any value>
k 1 2 3 k k+1 k+2
(LSB) } Reverse Flow Entry

1
2 3 4 5
3.5.2
A9-Update-A8 Ack
This message is sent from the PCF to the BS to acknowledge a change to the session airlink parameters. This message is also sent from the BS to the PCF to acknowledge the processing of any new or updated session parameters. In HRPD systems, this message is also used to acknowledge the QoS update.
C-50
3GPP2 A.S0008-C v2.0

Information Element A9 Message Type Call Connection Reference Correlation ID Cause
1 2 3 4 5
Section Element Direction Reference 4.2.13 4.2.10 4.2.11 4.2.3 BS<->PCF BS<->PCF BS<->PCF BS -> PCF M O O O
a b
Type
R C C
a. This element shall only be included if it was also included in the A9-Update-A8 message. This element shall be set to the value received in that message. b. The Cause element shall be included when the message is sent by the BS to the PCF to indicate if the updated session parameter(s) or the QoS update was accepted by the BS. The following table shows the bitmap layout for the A9-Update-A8 Ack message.
3.5.2 7 (MSB) (MSB) (MSB) 6 5 4 A9-Update-A8 Ack 3 2 1 0 Octet 1 1 2 3 (LSB) Generating Entity ID = <any value> (LSB) Call Connection Reference = <any value> 4 5 6 7 8 9 (LSB) (MSB) Correlation ID: A9 Element Identifier = [13H] Length = [04H] Correlation Value = <any value> 10 1 2 3 4 5 (LSB) Ext= [0] Cause: A9 Element Identifier = [04H] Length = [01H] Cause Value = [13H (Successful operation), 36H (Session parameter/option not supported at BS), 2BH (BS resources are not available), 2CH (Partial QoS updated)] 6 1 2 3
A9 Message Type = [0FH] A9 Element Identifier = [3FH] Length = [08H] Market ID = <any value>
...
C-51
3GPP2 A.S0008-C v2.0

1 2
3.6
A8/A9 Interface Data Delivery Messages
3 4 5
3.6.1
A9-Short Data Delivery
This message is sent from the BS to the PCF when a short data burst is received from an MS. It may be sent from the PCF to the BS when a small amount of data is received for a dormant PDSI.
Information Element A9 Message Type Correlation ID Mobile Identity (IMSI) Mobile Identity (ESN) SR_ID Data Count ADDS User Part A9 Indicators Mobile Identity (MEID) Flow ID Section Reference 4.2.13 4.2.11 4.2.2 4.2.2 4.2.4 4.2.18 4.2.9 4.2.17 4.2.2 4.2.37 Element Direction PCF <-> BS PCF -> BS PCF <-> BS PCF <-> BS PCF <-> BS PCF -> BS PCF <-> BS PCF -> BS PCF <-> BS PCF <-> BS M Oa O O O O O O O
b g c d e b
Type
C R C CR C R C C C
6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
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. If an additional occurrence of the Mobile Identity information element (in addition to the Mobile Identity Type, IMSI) is included, it shall contain the indicated Mobile Identity Type of the MS. Inclusion of ESN, MEID or both 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 MS. d. This element contains the packet data received from the PDSN or an MS in a SDB format as specified in [18]. e. This information element is included when the PDSI is operating in CCPD Mode. f. This IE is included when the PCF has the information available from the corresponding GRE packet received across the A10 interface. This IE is also included when the BS has the information available from the corresponding air interface message.
g. In 1x systems, this IE specifies the SR_ID of the service instance in the Service Option element. In HRPD systems, the SR_ID shall be set to 01H (the main service connection). If this element is included in this message, the PCF should not stop data transmission over A8 connections indicated by this IE. Multiple instances of this IE may be included in the message. The following table shows the bitmap layout for the A9-Short Data Delivery message.
3.6.1 7 6 (MSB) 5 4 A9-Short Data Delivery 3 2 1 0 Octet 1 1 2 3
24
A9 Message Type = [0CH] Length = [04H] Correlation Value = <any value>
Correlation ID: A8/A9 Element Identifier = [13H]
C-52
3GPP2 A.S0008-C v2.0

3.6.1 7 6 5 4 A9-Short Data Delivery 3 2 1 0 Octet 4 5 (LSB) Mobile Identity (IMSI): A9 Element Identifier = [0DH] Length = [06H-08H] (10-15 digits) Identity Digit 1 = [0H-9H] (BCD) Odd/even Indicator = [1,0] Type of Identity = [110] (IMSI) 6 1 2 3
n n+1
Mobile Identity (ESN): A9 Element Identifier = [0DH] Length = [05H] Odd/even Indicator = [0] Type of Identity = [101] (ESN)
1 2 3
(MSB)
ESN = <any value>
4 5 6 (LSB) 7 1 2 3 IS-2000 SR_ID = [001 - 011] 3 1 2 3 4
Reserved = [0000 0] Data Count: Length = [02H] Count = <any value>
Reserved = [00] ADDS User Part: A9 Element Identifier = [3DH] Data Burst Type = [00H (DoS), 06H (Short Data Burst)] Application Data Message = <any value> Length = <variable>
1 2 3
(MSB)
(LSB) A9 Indicators: A9 Element Identifier = [05H]
n 1
C-53
3GPP2 A.S0008-C v2.0

3.6.1 7 6 5 4 A9-Short Data Delivery 3 2 1 0 Octet 2 Reserved Data Ready Handoff = [0] Indicator Indicator = [0,1] = [0, 1] (ignored) (ignored) 3
Length = [01H] GRE QoS Mode Packet SDB /DoS CCPD = [0, 1] Boundary Segment. Supported Mode Supported Supported = [1] = [1] (ignored) [0,1] = [0,1] (ignored) (ignored) (ignored) Length = [08H] MEID Hex Digit 1 = [0H-FH] Odd/Even Indicator = 0 Type of Identity = [001] (MEID)
1 2 3
MEID Hex Digit 3 = [0H-FH] MEID Hex Digit 5 = [0H-FH] MEID Hex Digit 7 = [0H-FH] MEID Hex Digit 9 = [0H-FH] MEID Hex Digit 11 = [0H-FH] MEID Hex Digit 13 = [0H-FH] Fill = [FH]
MEID Hex Digit 2 = [0H-FH] MEID Hex Digit 4 = [0H-FH] MEID Hex Digit 6 = [0H-FH] MEID Hex Digit 8 = [0H-FH] MEID Hex Digit 10 = [0H-FH] MEID Hex Digit 12 = [0H-FH] MEID Hex Digit 14 = [0H-FH]
4 5 6 7 8 9 10 1 2 3
Flow ID: A9 Element Identifier = [91H] Length = [01H] Flow ID = [00H-FFH]
...
4.1.2 Information Element Identifiers The following table contains a list of all information elements that make up the messages defined in section 3.0. The table is sorted by the Information Element Identifier (IEI) coding which distinguishes one information element from another. The table also includes a reference to the section where the element coding can be found. A listing of information elements, sorted by name, is included in Table 4.1.4-1, which also specifies the messages in which each information element is used. Table 4.1.2-1
CON_REF User Zone ID Service Option Cause A9 Indicators A9 Cell Identifier Quality of Service Parameters A8 Traffic ID
3 4 5 6 7 8 9 10
A9 Information Element Identifiers Sorted by Identifier Value

Identifier 01H 02H 03H 04H 05H 06H 07H 08H Reference 4.2.14 4.2.6 4.2.8 4.2.3 4.2.17 4.2.15 4.2.7 4.2.16
Element Name
C-54
3GPP2 A.S0008-C v2.0

Element Name Data Count Active Connection Time in Seconds SR_ID A9 PDSN Code Mobile Identity IS-2000 Service Configuration Record RN-PDIT Correlation ID PDSN Address Access Network Identifiers Anchor PDSN Address Software Version ADDS User Part Call Connection Reference Anchor P-P Address Service Instance Info Forward QoS Information Reverse QoS Information Subscriber QoS Profile Flow ID Additional A8 Traffic ID ROHC Configuration Parameters Forward QoS Update Information Reverse QoS Update Information
1
Identifier 09H 0AH 0BH 0CH 0DH 0EH 0FH 13H 14H 20H 30H 31H 3DH 3FH 40H 41H 8EH 8FH 90H 91H 92H 93H 94H 95H
Reference 4.2.18 4.2.1 4.2.4 4.2.23 4.2.2 4.2.20 4.2.24 4.2.11 4.2.5 4.2.19 4.2.22 4.2.21 4.2.9 4.2.10 4.2.12 4.2.25 4.2.34 4.2.35 4.2.36 4.2.37 4.2.32 4.2.33 4.2.38 4.2.39
...
4.1.4 Cross Reference of Information Elements With Messages The following table provides a cross reference between the elements defined in this specification and the messages defined herein. Table 4.1.4-1
Information Element A8 Traffic ID
2 3 4
Cross Reference of Information Elements with Messages

Reference 4.2.16 IEI 08H Used in These Messages A9-Setup-A8 A9-AL Connected A9-AL Disconnected A9-Connect-A8 A9-Disconnect-A8 A9-Release-A8 Reference 3.1.1 3.3.1 3.3.3 3.1.2 3.2.3 3.2.4 3.1.1 3.1.2 3.1.1
A9 Cell Identifier A9 Indicators
4.2.15 4.2.17
06H 05H
A9-Setup-A8 A9-Connect-A8 A9-Setup-A8
C-55
3GPP2 A.S0008-C v2.0 Table 4.1.4-1

Information Element

Reference IEI Used in These Messages A9-BS Service Request A9-Short Data Delivery A9-Update-A8 Reference 3.1.3 3.6.1 3.5.1 3.1.1 3.3.1 3.3.2 3.3.3 3.3.4 3.1.3 3.1.4 3.1.2 3.2.3 3.2.1 3.2.2 3.6.1 3.6.2 3.5.1 3.5.2 3.4.1 3.4.2 3.2.3 3.2.2 3.1.1 3.3.1 3.2.1 3.1.1 3.1.2 3.2.1 3.6.1 3.1.1 3.1.2 3.3.2 3.5.1 3.1.1 3.1.2 3.3.2 3.5.1 3.3.1 3.3.2 3.3.3
A9 Message Type
4.2.13
None
A9-Setup-A8 A9-AL Connected A9-AL Connected Ack A9-AL Disconnected A9-AL Disconnected Ack A9-BS Service Request A9-BS Service Response A9-Connect-A8 A9-Disconnect-A8 A9-Release-A8 A9-Release-A8 Complete A9-Short Data Delivery A9-Short Data Delivery Ack A9-Update-A8 A9-Update-A8 Ack A9-Version Info A9-Version Info Ack
A9 PDSN Code Access Network Identifier Active Connection Time in Seconds Additional A8 Traffic ID
4.2.23 4.2.19 4.2.1 4.2.32
0CH 20H 0AH 92H
A9-Disconnect-A8 A9-Release-A8 Complete A9-Setup-A8 A9-AL Connected A9-Release-A8 A9-Setup-A8 A9-Connect-A8 A9-Release-A8
ADDS User Part Anchor P-P Address
4.2.9 4.2.12
3DH 40H
A9-Short Data Delivery A9-Setup-A8 A9-Connect-A8 A9-AL Connected Ack A9-Update-A8
Anchor PDSN Address
4.2.22
30H
A9-Setup-A8 A9-Connect-A8 A9-AL Connected Ack A9-Update-A8
Call Connection Reference
4.2.10
3FH
A9-AL Connected A9-AL Connected Ack A9-AL Disconnected
C-56
3GPP2 A.S0008-C v2.0 Table 4.1.4-1

Information Element

Reference IEI Used in These Messages A9-AL Disconnected Ack A9-Connect-A8 A9-Disconnect-A8 A9-Setup-A8 A9-Release-A8 A9-Release-A8 Complete A9-Update-A8 A9-Update-A8 Ack Reference 3.3.4 3.1.2 3.2.3 3.1.1 3.2.1 3.2.2 3.5.1 3.5.2 3.1.2 3.2.3 3.2.1 3.2.2 3.1.4 3.6.2 3.5.1 3.5.2 3.4.1 3.1.1 3.1.2 3.2.3 3.2.1 3.3.4 3.6.1 3.6.2 3.1.1 3.1.2 3.2.3 3.2.1 3.2.2 3.1.3 3.6.1 3.6.1 3.1.1 3.2.1 3.5.1 3.5.1 3.1.1 3.3.1 3.5.1 3.1.1
Cause
4.2.3
04H
A9-Connect-A8 A9-Disconnect-A8 A9-Release-A8 A9-Release-A8 Complete A9-BS Service Response A9-Short Data Ack A9-Update-A8 A9-Update-A8 Ack A9-Version Info
CON_REF
4.2.14
01H
A9-Setup-A8 A9-Connect-A8 A9-Disconnect-A8 A9-Release-A8
Correlation ID
4.2.11
13H
A9-AL Disconnected Ack A9-Short Data Delivery A9-Short Data Delivery Ack A9-Setup-A8 A9-Connect-A8 A9-Disconnect-A8 A9-Release-A8 A9-Release-A8 Complete
Data Count Flow ID Forward QoS Information
4.2.18 4.2.37 4.2.34
09H 91H 8EH
A9-BS Service Request A9-Short Data Delivery A9-Short Data Delivery A9-Setup-A8 A9-Release-A8 A9-Update-A8
Forward QoS Update Information IS-2000 Service Configuration Record
4.2.38 4.2.20
94H 0EH
A9-Update-A8 A9-Setup-A8 A9-AL Connected A9-Update-A8
Mobile Identity
4.2.2
0DH
A9-Setup-A8
C-57
3GPP2 A.S0008-C v2.0 Table 4.1.4-1

Information Element

Reference IEI Used in These Messages A9-Connect A8 A9-Disconnect-A8 A9-Release-A8 A9-BS Service Request A9-Short Data Delivery A9-Short Data Delivery Ack A9-Update-A8 Reference 3.1.2 3.2.3 3.2.1 3.1.3 3.6.1 3.6.2 3.5.1 3.1.1 3.1.2 3.3.1 3.3.2 3.1.1 3.3.1 3.5.1 3.1.1 3.2.1 3.5.1 3.5.1 3.5.1 3.1.2 3.1.2 3.1.3 3.1.1 3.3.1 3.5.1 3.4.1 3.4.2 3.1.1 3.1.2 3.2.3 3.2.1 3.2.2 3.1.3 3.1.4 3.6.1 3.5.1 3.3.3 3.1.2 3.5.1 3.1.1
PDSN Address
4.2.5
14H
A9-Setup-A8 A9-Connect-A8 A9-AL Connected A9-AL Connected Ack
Quality of Service Parameters
4.2.7
07H
A9-Setup-A8 A9-AL Connected A9-Update-A8
Reverse QoS Information
4.2.35
8FH
A9-Setup-A8 A9-Release-A8 A9-Update-A8
Reverse QoS Update Information RN-PDIT ROHC Configuration Parameters Service Instance Info Service Option
4.2.39 4.2.24 4.2.33 4.2.25 4.2.8
95H 0FH 93H 41H 03H
A9-Update-A8 A9-Update-A8 A9-Connect-A8 A9-Connect-A8 A9-BS Service Request A9-Setup-A8 A9-AL Connected A9-Update-A8
Software Version SR_ID
4.2.21 4.2.4
31H 0BH
A9-Version Info A9-Version Info Ack A9-Setup-A8 A9-Connect-A8 A9-Disconnect-A8 A9-Release-A8 A9-Release-A8 Complete A9-BS Service Request A9-BS Service Response A9-Short Data Delivery A9-Update-A8 A9-AL Disconnected
Subscriber QoS Profile User Zone ID
4.2.36 4.2.6
90H 02H
A9-Connect-A8 A9-Update-A8 A9-Setup-A8
C-58
3GPP2 A.S0008-C v2.0 Table 4.1.4-1

Information Element

Reference IEI Used in These Messages A9-AL Connected A9-Update-A8 Reference 3.3.1 3.5.1
...
4.2.3 Cause This element is used to indicate the reason for occurrence of a particular event and is coded as shown below.
4.2.3 7 6 5 4 Length 0/1 Cause Value 3 Cause 2 1 0 Octet 1 2 3
3 4 5
6 7 8 9 10 11
Length: Cause Value:
This field indicates the number of octets in this element following the Length field. This field is a single octet field if the extension bit (bit 7) is set to 0. If bit 7 of octet 3 is set to 1 then the cause value is a two octet field. If the value of the first octet of the cause field is 1XXX 0000 then the second octet is reserved for national applications, where XXX indicates the Cause Class as indicated in the table below. Table 4.2.3-1
Binary Values 000 001 010 011 100 101 110 111 Meaning Normal event Normal event Resource unavailable Service or option not available Service or option not implemented Invalid message (e.g., parameter out of range) Protocol error Interworking
Cause Class
12 13
Table 4.2.3-2
6 0 0 0 0 0 0 0 0 5 0 0 0 0 0 0 0 0 4 0 0 0 0 0 0 0 1 3 0 0 0 0 1 1 1 0 2 0 0 0 1 0 0 1 0 1 0 Hex Value
Cause Values
Cause
Normal Event Class (000 xxxx and 001 xxxx) 0 1 01 Partial connection release 1 0 02 Multi-connection required 1 1 03 Partial connection establishment 1 1 07 OAM&P intervention 0 0 08 MS busy 1 1 0B Handoff successful 1 1 0F Packet data session release 0 0 10 Packet call going dormant
C-59
3GPP2 A.S0008-C v2.0

6 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 5 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 4 1 1 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 1 1 3 0 0 0 0 0 1 1 1 1 1 1 1 1 0 0 1 1 1 1 0 0 0 2 0 0 1 1 1 0 0 0 0 1 1 1 1 0 1 0 0 1 1 0 0 1 0 Hex Value Cause 1 11 Service option not available 1 13 Successful operation 0 14 Normal call release 0 16 Initiate re-activation of packet data call 1 17 SDB successfully delivered 0 18 SDB couldnt be delivered 1 19 Power down from dormant state 0 1A Authentication failure 1 1B Capability update 0 1C Update Accounting: late traffic channel setup 1 1D Hard handoff failure 0 1E Update Accounting: parameter change 1 1F Air link lost 1 23 Authentication required 0 24 Session unreachable 0 2A PCF resources are not available 1 2B BS resources are not available 0 2C Partial QoS updated 0 2E QoS update Resource Unavailable Class (010 xxxx) 0 0 20 Equipment failure Service or Option Not Available Class (011 xxxx) 1 0 32 PCF resources are not available 1 0 36 Session parameter/option not supported at BS Service or Option Not Implemented Class (100 xxxx) Invalid Message Class (101 xxxx) Protocol Error (110 xxxx) 0 0 60 State mismatch Interworking (111 xxxx) 0 1 79 PDSN resources are not available 1 0 7A Data ready to send 1 1 7B Session parameter update Reserved for future use. 1 0 1 0 1 1 0 0 1 1 0 0 1 1 1 0 1 1 0 1
1 1 1 1
1 1 1 1
1 1 0 1 1 0 1 1 0 All other values
1 2
4.2.4
SR_ID
This information element identifies the service reference identifier for a particular service instance.
4.2.4 7 6 5 4 Length SR_ID Reserved IS-2000 SR_ID 3 SR_ID 2 1 0 Octet 1 2 3 3
3 4 5 6 7
Length: IS-2000 SR_ID:
This field indicates the number of octets in this element following the Length field. This field is used to uniquely identify a PDSI in the MS. This field contains the Session Reference Identifier value (sr_id) as defined in [3].
...
C-60
3GPP2 A.S0008-C v2.0

1 2
4.2.8
Service Option
This element indicates the service option requested by the MS, or by the network. It is coded as follows:
4.2.8 7 (MSB) 6 5 4 Service Option 3 Service Option (LSB) 2 1 0 Octet 1 2 3
3 4 5
The service options supported are given in Table 4.2.8-1. Table 4.2.8-1
Service Option Value (hex) 0021H 003BH 003CH 003DH 0047H Description 3G High Speed Packet Data HRPD Main Service Connection Link Layer Assisted Header Removal Link-Layer Assisted Robust Header Compression (LLA-ROHC) HRPD AltPPP operation
Service Option Values
7 8
4.2.9
ADDS User Part
This element contains the application data message.

4.2.9 7 6 5 4 Length Reserved Data Burst Type Application Data Message ADDS User Part 3 2 1 0 Octet 1 2 3 4-n
9 10 11 12 13 14 15 16 17 18
The Length field is defined as the number of octets following the Length field and has a value greater than zero. The Data Burst Type field is coded as follows: For CDMA1x Short Data Burst: the 6-bit Data Burst Type defined in [18] is contained in bits 5 through 0, with bits 6 and 7 set to zero. For HRPD DoS, this field is not used and set to zero. The Application Data Message field has variable length and is encoded as follows: For Short Data Burst, the Application Data Message is the SDB as specified in [18]. For HRPD DoS, the Application Data Message is a complete higher layer packet and encoded as specified in [10] or [22].
19
...
C-61
3GPP2 A.S0008-C v2.0

1 2
4.2.17 A9 Indicators This information element indicates properties of the A8 connection and of the MS.
4.2.17 7 6 5 4 Length QoS Packet GRE SDB/DoS ModeRes Boundary Segment. Supported erved Supported Supported Reserved Reserved Reserved Reserved CCPD Mode Reserved Emergency Data ServicesRes Ready erved Indicator Reserved Reserved Handoff Indicator Buffer Transfer A9 Indicators 3 2 1 0 Octet 1 2 3
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
Length: Handoff Indicator:
This field indicates the number of octets in this element following the Length field. This field indicates whether or not a handoff was performed. Refer to [13]. When this IE is included in the A9-Setup-A8 message, the following conditions hold: The field is set to 0 to indicate normal call setup The field is set to 1 to indicate that a hard handoff is to be performed, and that is not necessary to establish the A10 connection immediately The field is set to 0 for dormant handoffs The field is set to 0 for fast handoffs, because an A10 connection needs to be set up immediately
When this IE is included in the A9-Short Data Delivery message, this field is ignored. When this IE is included in the A9-Update-A8 message, this field is ignored. Data Ready Indicator: This field indicates whether there is data ready to be sent from the MS to the network. It reflects the value of the DRS bit of the air interface. If this field is set to 0, it indicates that data is not ready to be sent and the A9-Setup-A8 message is reporting a mobility event. Otherwise (set to 1) it indicates that data is ready to be sent. This field indicates whether emergency services are used. If emergency services are used, the field is set to 1. Otherwise, the field is set to 0. This field indicates that an MS has requested CCPD Mode. The PCF is not required to allocate an A8 connection when this bit is set. Any signaling or data exchanged between the PCF and BS is sent over the A9 signaling channel. This field indicates if Short Data Bursts can be sent for the PDSI. For HRPD, this field indicates whether Data Over Signaling messages can be sent for the connection. Table 4.2.17-1 A9 Indicators SDB/DoS Supported
Values 0 Meaning Short Data Bursts/Data Over Signaling not supported for the PDSI/connection
Emergency Services: CCPD Mode:
SDB/DoS Supported:
C-62
3GPP2 A.S0008-C v2.0

Values 1 Meaning Short Data Bursts/Data Over Signaling supported for the PDSI/connection
1 2 3 4 5 6 7 8 9 10 11
GRE Segmentation Supported: This field is set to 1 if the AN is capable of receiving the GRE segmentation attribute in the GRE header for the corresponding A8 connection, for packets fragmented over one or more GRE frames. Packet Boundary Supported: This field is set to 1 if the PCF guarantees IP packet boundaries. The PCF guarantees packet boundaries either by encapsulating one packet in one GRE frame or by supplying GRE segmentation indication in the GRE frame (if supported by the AN) for the corresponding A8 connection. This field indicates whether the IP flow based QoS is available over the air for the current personality of the AT. Table 4.2.17-2 QoS Mode Values
QoS Mode 0 1 Description The air interface protocol currently in use does not support IP flow based QoS. The air interface protocol currently in use supports IP flow based QoS.
QoS Mode:
12 13 14 15 16 17
Buffer Transfer:
This field is set to 1 to indicate that the A8 set up being requested is for the transfer of buffered data during an A13 session transfer. In this case accounting information does not need to be sent to the PDSN and the source PCF may send an in-band flow control Xoff signal to the PDSN to stop data transmission from the PDSN, if the flow control feature is activated. Otherwise this field is set to 0
18
...
4.2.32 Additional A8 Traffic ID This IE identifies the connection used by the MS/AT for packet data service.
4.2.32 7 6 5 4 Length A8 Traffic ID Entry 1 A8 Traffic ID Entry 2 Additional A8 Traffic ID 3 2 1 0 Octet 1 2 variable variable
19 20
A8 Traffic ID Entry n
21 22 23 24
variable
Length: A8 Traffic ID Entry:

7 6 5
This field indicates the number of octets in this IE following the Length field. This field contains A8 Traffic ID for auxiliary connection. This field is coded as follows.
4 3 2 1 0 Octet 1 Entry Length
C-63
3GPP2 A.S0008-C v2.0

7 (MSB) 6 5 4 SR_ID Service Option (LSB) A8 transport protocol stack (MSB) (MSB) Protocol Type (LSB) Key 3 2 1 0 Octet 2 3 4 5 6 7 8 9 10 (LSB) Address Type (MSB) IP Address 11 12 13
(LSB) Forward ROHC Info Length (MSB) (MSB) Forward LargeCIDs Forward Profile {Forward ProfileCount: (MSB) }Forward Profile Reverse ROHC Info Length (MSB) (MSB) Reverse LargeCIDs Reverse Profile { Reverse ProfileCount: (MSB) } Reverse Profile
1 2
k n n+1 (LSB) n+2 n+3 (LSB) Reserved n+4 n+5 n+6 p (LSB) p+1 n n+1 (LSB) n+2 n+3 (LSB) Reserved n+4 n+5 n+6 p (LSB) p+1
Forward MaxCID Forward MRRU
Forward ProfileCount Forward Profile
Reverse MaxCID Reverse MRRU
Reverse ProfileCount Reverse Profile
Entry Length:
This field contains the number of octets in this entry following the Entry Length field as a binary number. C-64
3GPP2 A.S0008-C v2.0

1 2 3 4 5
SR_ID: Service Option:
This field identifies the service connection associated with the A8 connection. This field indicates the service option for the A8 connection associated with the value in the SR_ID field. Table 4.2.32-1 Additional A8 Traffic ID - Service Option Values
Service Option Value (hex) 00 40H 00 43H Description HRPD Auxiliary Service Connection with higher layer framing for packet synchronization HRPD Auxiliary Service Connection without higher layer framing for packet synchronization
6 7 8
A8 transport protocol stack:
This field is used to identify the A8 transport protocol stack to be used for the A8 connection.
Table 4.2.32-2 Additional A8 Traffic ID - A8 Transport Protocol Stack

Values 01H All Others Meaning GRE/IP Reserved
9 10 11 12 13 14 15 16 17 18
Protocol Type:
This field is used to indicate the protocol type to be tunneled across the A8 interface, and contains the same value that is used in the Protocol Type field in the GRE header on the associated A8 connection. This field is set to 0x88 81H (Unstructured Byte Stream). This is a four octet field. This field is used to indicate the A8 connection identification, and contains the same value that is used in the Key field in the GRE header on the associated A8 connection. This field indicates the type and format of the IP Address that follows. Table 4.2.32-3 A8 Traffic ID - Address Type
Value 01H 02H Address Type Internet Protocol IPv4 Internet Protocol IPv6 All other values reserved Length of IP Address 4 octets variable
Key:
Address Type:
19 20 21 22 23 24 25 26 27 28 29 30 31
IP Address:
This field has a variable length that is dependent on the Type field. This field is used to indicate the IP address of the A8 bearer port on the sending entity. That is, when the BS sends the A9-Setup-A8 message containing this IE, this field contains the IP address at the BS where the A8 user traffic connection terminates. ROHC parameters may be omitted in a specific message. Refer to the individual message bitmaps for inclusion or exclusion.
Forward ROHC Info Length:
This field is used to indicate whether to create a forward ROHC channel on the A8 connection being created. If the Service Option for this entry is 43H and this A8 connection has a forward ROHC channel (compressor at PDSN, decompressor at AT), then this field indicates the number of octets following this field that carry ROHC configuration parameters C-65
3GPP2 A.S0008-C v2.0

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
(Forward MaxCID, Forward MRRU, Forward LargeCIDs, Forward ProfileCount, and Forward Profile fields). Otherwise it is set to 0. Forward MaxCID: Forward MRRU: Forward LargeCIDs: Forward ProfileCount: This field contains the MAX_CID parameter for this ROHC channel as defined in [24]. This field contains the MRRU (Maximum reconstructed reception unit) parameter for this ROHC channel as defined in [24]. This field contains the LARGE_CIDS parameter for this ROHC channel as defined in [24]. This field contains the number of ROHC Profiles supported by the decompressor, which corresponds to the number of Profiles contained in this IE, as a binary number. This field indicates a ROHC profile supported by the decompressor. IANA ROHC profile identifier definitions can be found at [23]. This field is used to indicate whether to create a reverse ROHC channel on the A8 connection being created. If the Service Option for this entry is 43H and this A8 connection has a reverse ROHC channel (compressor at AT, decompressor at PDSN), then this field indicates the number of octets following this field that carry ROHC configuration parameters (Reverse MaxCID, Reverse MRRU, Reverse LargeCIDs, Reverse ProfileCount, and Reverse Profile fields). Otherwise it is set to 0. This field contains the MAX_CID parameter for this ROHC channel as defined in [24]. This field contains the MRRU (Maximum reconstructed reception unit) parameter for this ROHC channel as defined in [24]. This field contains the LARGE_CIDS parameter for this ROHC channel as defined in [24]. This field contains the number of ROHC Profiles supported by the decompressor, which corresponds to the number of Profiles contained in this IE, as a binary number. This field indicates a ROHC profile supported by the decompressor. IANA ROHC profile identifier definitions can be found at [23].
Forward Profile: Reverse ROHC Info Length:
Reverse MaxCID: Reverse MRRU: Reverse LargeCIDs: Reverse ProfileCount:
Reverse Profile:
32 33 34
4.2.33 ROHC Configuration Parameters This IE is used to provide the ROHC configuration parameters values supported by the PDSN when ROHC on SO67 is supported with ROHC in the PDSN.
0 1 2 3 Length (MSB) (MSB) LargeCIDs Profile {ProfileCount: MaxCID (LSB) MRRU (LSB) Reserved ProfileCount 4 5 6 7 Octet 1 2 3 4 5 6 7 8 A9 Element Identifier
C-66
3GPP2 A.S0008-C v2.0

0 (MSB) } Profile
1 2 3 4 5 6 7 8 9 10 11 12 13 14
4 Profile
7 (LSB)
Octet n n+1
Length: MaxCID: MRRU: LargeCIDs: ProfileCount:
This field indicates the number of octets in this IE following the Length field. This field contains the MAX_CID supported by the PDSN as defined in [24]. This field contains the MRRU (Maximum reconstructed reception unit) supported by the PDSN as defined in [24]. This field contains the LARGE_CIDS supported by the PDSN as defined in [24]. This field contains the number of ROHC Profiles supported by the PDSN, which corresponds to the number of Profiles contained in this IE, as a binary number. This field indicates a ROHC profile supported by the PDSN IANA ROHC profile identifier definitions can be found at [23]. Forward QoS Information
Profile: 4.2.34
15 16
This IE provides mappings of forward IP flow(s) to service connection.

4.2.34 7 6 5 4 Length Forward QoS Information Entry 1 Forward QoS Information Entry 2 Forward QoS Information 3 2 1 0 Octet 1 2 variable variable

17 18 19 20 21
variable
Length: Forward QoS Information Entry:
This field indicates the number of octets in this IE following the Length field. Each Forward QoS Information Entry specifies all of the forward IP flow(s) that are associated with a given service connection. Each entry is coded as follows.
4 SR_ID 3 2 1 0 Octet j j+1 Reserved j+2 Entry Length
Use IP Flow Discrimination
DSCP Included
Reserved
Forward Flow Count Forward Flow Entry 1
j+3 variable
C-67
3GPP2 A.S0008-C v2.0

7 6 5 4 3 2 1 0 Octet variable
Forward Flow Entry 2

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
variable
Entry Length: SR_ID: DSCP Included:
This field contains the number of octets in this entry following the Entry Length field as a binary number. This field identifies the service connection. This field indicates whether DSCP values are included in this IE. If option 2c in section 2.6.2 of [12] is used, then the value shall be set to 1. Otherwise, the value shall be set to 0 and all DSCP fields in this IE shall be ignored. This field indicates if the PCF shall include GRE extension for IP flow discrimination. If this field is set to '0', the PCF shall not include the GRE extension for IP flow discrimination in the bearer packets for the A8 connection identified in the SR_ID field of this Forward Flow Entry. Otherwise (set to '1') it indicates that the Flow ID shall be included. This field indicates the number of Forward Flow Entry contained in this Forward QoS Information Entry. This set of fields (Forward Flow Entry 1, 2 ... n) contains the forward flow IDs associated with the service connection identified by the SR_ID field. Each Forward Flow Entry is coded as follows.
5 4 3 2 1 0 Octet k k+1 Flow State k+2 k+3 k+4 Entry Length Forward Flow ID i
Use IP Flow Discrimination:
Forward Flow Count: Forward Flow Entry i:
Reserved (MSB)
DSCP Forward Requested QoS Length i Forward Requested QoS i
(LSB) Forward Granted QoS Length i (MSB) Forward Granted QoS i
m m+1 m+2
(LSB)
20 21 22 23 24 25 26 27 28
Entry Length: Forward Flow ID i: Flow State:
This field contains the number of octets in this entry following the Entry Length field as a binary number. This field contains the flow ID of a given forward flow. Refer to [8] for detailed information. This field indicates the IP flow state of the flow identified in the Forward Flow ID i field. This field is set to '0' if it is deactivated. This field is set to '1' if it is activated. If DSCP Included = 1, then this field contains the DSCP value of the flow identified in the corresponding Forward Flow ID C-68
DSCP:
3GPP2 A.S0008-C v2.0

1 2 3 4 5 6 7 8 9 10 11
field. Otherwise, this field shall be set to 00 0000 and shall be ignored. Forward Requested QoS Length i: Forward Requested QoS i: This field indicates the number of octets in the Forward Requested QoS i field. For HRPD systems, this field contains the requested QoS Sub BLOB for this flow received from the AT. The format is as specified in [8]. This field indicates the number of octets in the Forward Granted QoS i field. For HRPD systems, this field contains the granted QoS Sub BLOB for this flow. The format is as specified in [8].
Forward Granted QoS Length i: Forward Granted QoS i: 4.2.35 Reverse QoS Information
12 13
This IE provides mappings of reverse IP flow(s) to service connection.

4.2.35 7 6 5 4 Length Reverse QoS Information Entry 1 Reverse QoS Information Entry 2 Reverse QoS Information 3 2 1 0 Octet 1 2 variable variable

14 15 16 17 18
variable
Length: Reverse QoS Information Entry:
This field indicates the number of octets in this IE following the Length field. Each Reverse QoS Information Entry specifies all of the reverse IP flow(s) that are associated with a given service connection. Each entry is coded as follows.
4 SR_ID Reserved Reverse Flow Count Reverse Flow Entry 1 Reverse Flow Entry 2 3 2 1 0 Octet j j+1 j+2 variable variable Entry Length

19 20 21 22 23 24 25
variable
Entry Length: SR_ID: Reverse Flow Count: Reverse Flow Entry i:
This field contains the number of octets in this entry following the Entry Length field as a binary number. This field identifies the service connection. This field indicates the number of Reverse Flow Entry contained in this Reverse QoS Information Entry. This set of fields (Reverse Flow Entry 1, 2 ... n) contains the reverse flow IDs associated with the service connection C-69
3GPP2 A.S0008-C v2.0

1 2 3
identified by the SR_ID field. Each Reverse Flow Entry is coded as follows.
Octet k k+1
Entry Length Reverse Flow ID i Reserved Reverse Requested QoS Length i (MSB) Reverse Requested QoS i Flow State
k+2 k+3 k+4
(LSB) Reverse Granted QoS Length i (MSB) Reverse Granted QoS i
m m+1 m+2
(LSB)
4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
Entry Length: Reverse Flow ID i: Flow State
This field contains the number of octets in this entry following the Entry Length field as a binary number. This field contains the flow ID of a given reverse IP flow. Refer to [8] for detailed information. This field indicates the IP flow state of the flow identified in the Reverse Flow ID i field. This field is set to '0' if it is deactivated. This field is set to '1' if it is activated. This field indicates the number of octets in the Reverse Requested QoS i field. For HRPD systems, this field contains the requested QoS Sub BLOB for this flow received from the AT. The format is as specified in [8]. This field indicates the number of octets in the Reverse Granted QoS i field. For HRPD systems, this field contains the granted QoS Sub BLOB for this flow. The format is as specified in [8].
Reverse Requested QoS Length i: Reverse Requested QoS i:
Reverse Granted QoS Length i: Reverse Granted QoS i: 4.2.36 Subscriber QoS Profile
20 21 22
This IE is used to provide the Subscriber QoS Profile.

4.2.36 7 6 5 4 Length Subscriber QoS Profile Subscriber QoS Profile 3 2 1 0 Octet 1 2 variable
23 24
Length:
This field indicates the number of octets in this IE following the Length field. C-70
3GPP2 A.S0008-C v2.0

1 2
Subscriber QoS Profile: 4.2.37 Flow ID
This field contains Subscriber QoS Profile. Refer to [8] for detailed information.
3 4 5
This IE is used to identify an individual IP Flow.

4.2.37 7 6 5 4 Length Flow ID Flow ID 3 2 1 0 Octet 1 2 3
6 7 8
Length: Flow ID:
This field indicates the number of octets in this IE following the Length field. This field identifies an individual IP Flow.
4.2.38 Forward QoS Update Information This IE is used when the PDSN updates the QoS for one or more forward IP Flows.
4.2.38 7 6 5 Forward QoS Update Information 4 Length Forward Flow Count Forward Flow Entry { Forward Flow Count : Forward Flow ID Forward Updated QoS Sub-BLOB Length (MSB) Forward Updated QoS Sub-BLOB p+1 p+2 p+3 3 2 1 0 Octet 1 2 3
10
(LSB) } Forward Flow Entry

11 12 13 14 15 16 17 18 19 20 21
Length Forward Flow Count: Forward Flow ID: Forward Updated QoS Sub-BLOB Length: Forward Updated QoS Sub-BLOB:
This field indicates the number of octets in this IE following the Length field This field indicates the number of Flow ID Entry contained in this IE. This field contains the flow ID of a given forward IP flow. Refer to [8] for detailed information. This field contains the number of octets in the Forward Updated QoS Sub-BLOB field as a binary number. This field contains the Updated QoS Sub-BLOB for this flow. Refer to [8] for detailed information.
C-71
3GPP2 A.S0008-C v2.0

1
4.2.39 Reverse QoS Update Information This IE is used when the PDSN updates the QoS for one or more reverse IP Flows.
4.2.39 7 6 5 Reverse QoS Update Information 4 Length Reverse Flow Count Reverse Flow Entry { Reverse Flow Count : Reverse Flow ID Reverse Updated QoS Sub-BLOB Length (MSB) Reverse Updated QoS Sub-BLOB 3 2 1 0 Octet 1 2 3 p+1 p+2 p+3

3 4 5 6 7 8 9 10 11 12 13 14
Length Reverse Flow Count: Reverse Flow ID: Reverse Updated QoS Sub-BLOB Length: Reverse Updated QoS Sub-BLOB:
This field indicates the number of octets in this IE following the Length field This field indicates the number of Flow ID Entry contained in this IE. This field contains the flow ID of a given reverse IP flow. Refer to [8] for detailed information. This field contains the number of octets in the Reverse Updated QoS Sub-BLOB field as a binary number. This field contains the Updated QoS Sub-BLOB for this flow. Refer to [8] for detailed information.
C-72
3GPP2 A.S0008-C v2.0
1 2 3 4 5
Annex D
A10-A11 (AN/PCF - PDSN) Interface Change Text (Normative)
Note: Annex D, contains specific A11 messaging text from [17] with all HRPD related changes identified through the use of underscores (additions) and strikeouts (deletions). Use of an ellipsis () indicates that the base document is unchanged. Note: Fast handoff as defined in this Annex D applies only to 1x systems.
...
1.2 References
...
1.2.1 [1~7] [8] [8] [9] [10] 3GPP2 Reserved. X.S0011-D v1.0, Wireless IP Network Standard, March 2006. 3GPP2 X.S0011-C, Wireless IP Network Standard, six parts, September 2003. Reserved. 3GPP2: C.S0024-B v2.0, cdma2000 High Rate Packet Data Air Interface Specification, March 2007.
10
11
12
13
14 15
16
...
1.2.2 Other
17
18
...
[27] [28] Internet Assigned Numbers Authority: RObust Header Compression (ROHC) Profile Identifiers, http://www.iana.org/assignments/rohc-pro-ids. IETF: RFC 3095, RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed, July 2001.
19 20
21 22
23
...
2.0 Message Procedures
This section describes message procedures for the A10/A11 interface. In the following sections, the term valid is used for messages that pass authentication and whose Identification information element is valid (refer to section 4.2.7).
24 25 26 27
28 29 30 31
2.1
A10 Connection Establishment, Refresh and Release Procedures
This section describes message procedures to establish, refresh or release an A10 connection. 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.
D-1
3GPP2 A.S0008-C v2.0

1 2 3 4
2.1.1
A11-Registration Request
This message is sent from the PCF to the PDSN to initiate establishment, refresh or release of an A10 connection. In addition, accounting information pertaining to an A10 connection may be included in any A11-Registration Request message for that connection. Refer to section 2.3 for further details. 2.1.1.1 Successful Establishment Operation When the PCF receives an A9-Setup-A8 message from a BS, the PCF shall initiate setup of an A10 connection as indicated below unless it has an existing A10 connection for the identified user and SR_ID. If the A9-Setup-A8 message does not contain a handoff indication, then the PCF shall initiate setup of the A10 connection upon receiving the A9-Setup-A8 message. In a fast handoff or HRPD hard handoff situation, the (target) PCF shall initiate setup of the A10 connection upon receiving the A9-Setup-A8 message. In all other handoff situations, the (target) PCF shall initiate setup of the A10 connection when the (target) BS captures the MS (i.e., upon receiving an A9-AL Connected message from the BS). The PCF initiates setup of an A10 connection by sending an A11-Registration Request message to the selected PDSN (refer to PDSN Selection Algorithm in [13]) with a non-zero Lifetime value. After sending this message, the PCF shall start timer Tregreq. The A11-Registration Request message is structured as specified in section 3.1. If the connection setup request is accepted, the PDSN creates a binding record for the A10 connection by creating an association between the PDSN Session Identifier (PDSN SID) and the MN ID IMSI, the MN Session Reference ID and PCF Addresses. In the case of HRPD, the MN-SR_ID is not received from the AT during origination and the AN/PCF shall set this to the default value of 1. If both the PCF and the PDSN support a Session Identifier Version higher than 0, the PDSN may choose any PDSN SID, otherwise the PDSN SID shall be identical to the PCF Session Identifier (PCF SID). In the case of multiple A10 connections for an MS, each A10 connection has its own binding record and Lifetime timer. The MN ID that is used by the PCF on A11 messages contains the same value as the Mobile Identity (IMSI) received in the A9-Setup A8 message. The PCF and the PDSN shall use the PCF IP Address (sent in the A11-Registration Request message) and the PDSN IP Address (returned in the A11-Registration Reply message) as the A10 connection endpoints 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 MSs IMSI address MN ID and MN Session Reference ID with the A10 connection. When establishing a new A10 connection, the PCF shall include the ANID NVSE with the Current Access Network Identifiers (CANID) as specified in [13]. If the PCF received the ANID from the BS, it shall populate it in the PANID field of the ANID NVSE sent in the A11-Registration Request message. In HRPD systems, if the network supports access authentication on the A12 interface, then prior to establishing the main A10 connection, access authentication on the A12 interface should be performed. In HRPD systems, the first A10 connection to be established for a packet data session shall have SO59 (3BH) or SO71 (47H) and is by definition the main connection. Auxiliary A10 connections may be SO64 (40H) HRPD Accounting Records Identifier or SO67 (43H) HRPD Packet Data IP Service where Higher Layer Protocol is IP or ROHC. In HRPD systems with PDSN-based ROHC on SO67, the AN indicates whether to create a forward and/or reverse ROHC channel for each SO67 auxiliary A10 connection when it is established. The AN/PCF includes each channels negotiated ROHC channel parameter values in the A11-Registration Request message that establishes the auxiliary A10 connection. If a service such as PDSN-based ROHC on SO67 requires a feedback loop, the AN/PCF shall assign the services feedback loop to the same A10 connection (i.e., same SR_ID value in each direction) as the forward flow to which it refers. D-2
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
3GPP2 A.S0008-C v2.0

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
In HRPD systems, when establishing auxiliary A10 connection(s), the PCF shall include information for all A10 connection(s) of the AT (including IP flow mapping information) in the A11-Registration Request message. The PCF may specify that the PDSN shall include the GRE extension for IP flow discrimination in all bearer packets for a given forward A10 connection. The A10 connection with SR_ID 1 is defined to be the main A10 connection. At a minimum, forward and reverse Flow IDs FFH are mapped to the main A10 connection. In HRPD systems, if the PCF receives an Emergency Services indication in an A9-Setup-A8 or an A9Update-A8 message, the PCF sets the Emergency Services indicator to 1 in the A11-Registration Request message, sent to the PDSN. If the PCF is able to determine that the setup of the A10 connection is due to a dormant handoff or an inter-PCF hard handoff (e.g., the A9-Setup-A8 message included the Access Network Identifiers (ANID) IE or the Data Ready Indicator field in the A9 Indicators IE was set to 0), the PCF shall include the Mobility Event Indicator (MEI) CVSE in the A11-Registration Request message. The PCF may provide the PDSN with an indication of PCF enabled features for the A10 connection (e.g. short data indication). In a fast handoff, the (target) PCF shall set the flag bit S to 1, include the Anchor P-P Address and set the Lifetime value to Tpresetup in the A11-Registration Request message. In other cases the PCF shall set the Lifetime to Trp. In HRPD systems, the QoS Mode Session Parameter shall be included in an NVSE when this message is sent for setting up the main A10 connection, to indicate QoS mode. If the PDSN does not receive the QoS Mode, then the PDSN shall assume the QoS Mode is set to 0. 2.1.1.2 Successful Refresh Operation All A11-Registration Request messages with a non-zero Lifetime value sent for an existing A10 connection have the effect of requesting a refresh of that A10 connection. When sending an A11Registration Request message for an already existing A10 connection, the PCF shall use the same Key value (refer to the Session Specific Extension in section 4.2.12). If the A9-Setup-A8 message does not contain a handoff indication, then the PCF shall send an A11Registration Request message to the PDSN upon receiving the A9-Setup-A8 message. In a fast handoff, the (target) PCF shall send an A11-Registration Request message to the PDSN upon receiving the A9-Setup-A8 message. In all other handoff situations, the (target) PCF shall send an A11-Registration Request message to the PDSN to initiate setup of the A10 connection when the (target) BS captures the MS (i.e., upon receiving an A9-AL Connected message from the BS). If the PCF is able to determine that an inter-PCF hard handoff has occurred (e.g., the A9-Setup-A8 message included the Access Network Identifiers (ANID) IE or the Data Ready Indicator field in the A9 Indicators IE is set to 0), the PCF shall include the MEI CVSE and the ANID NVSE in the A11Registration Request message. In a fast handoff case the Lifetime value shall be set to Tpresetup; in all other cases the Lifetime value shall be set to Trp. If the PCF set the Lifetime value to Tpresetup in the A11-Registration Request message (i.e., in the case of a fast handoff), then the PCF shall not refresh the A10 connection unless it is notified that the MS has successfully accessed the target BS. At that time, the PCF refreshes the A10 connection with the PDSN by sending an A11-Registration Request message with Lifetime value set to Trp. If the PCF set the Lifetime value to Trp, then the PCF periodically refreshes the A10 connection with the PDSN by sending an A11-Registration Request message with a non-zero Lifetime value before the A10 connection registration Lifetime timer expires. After sending this message, the PCF shall start timer Tregreq. In HRPD systems, the PCF shall include information for all A10 connections of the AT in the A11Registration Request message for refresh operation. D-3
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 48
3GPP2 A.S0008-C v2.0

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
2.1.1.3 Successful Release Operation The PCF may initiate release of the A10 connection by sending an A11-Registration Request message to the PDSN with Lifetime field set to zero. The PCF shall include accounting related and other information in the A11-Registration Request message. After receiving this message, the PDSN shall remove the binding record for the A10 connection and save the accounting related and other information for further processing. The PDSN shall send an A11-Registration Reply message to the PCF with the Lifetime parameter set to 0; refer to section 2.1.2.3. In HRPD systems, the PCF sends an A11-Registration Request message to the PDSN with the Lifetime value set to zero when the PCF releases all A10 connections for the AT. In HRPD systems, the PCF sends an A11-Registration Request message to release A10 connections that are no longer to be used. The message includes a non-zero Lifetime value and Additional Session Information for the A10 connections that are to be used after the release procedure. Information on A10 connections to be released shall not be included in the A11-Registration Request message. Release of the main A10 connection results in the release of all A10 connections for the HRPD session. If the PCF sends an A11-Registration Request message to release the main A10 connection, an NVSE containing the Additional Session Information Application Type is not included in the message. 2.1.1.4 Failure Operation Failure detection at the PDSN: If the A11-Registration Request message is invalid, the PDSN shall send an A11-Registration Reply message indicating authentication failure (Code value 83H) or identification mismatch (Code value 85H) and shall then discard the A11-Registration Request message; refer to section 2.1.2. If the PDSN indicates identification mismatch (Code value 85H) in the A11-Registration Reply message, the PDSN shall also include its own time in the 32 high-order bits of the Identification information element of this message to allow the PCF to avoid identification mismatch for subsequent A11-Registration Request messages. If the Lifetime timer for an A10 connection expires before the PDSN has received a valid A11Registration Request message from the PCF, then the PDSN shall delete the binding record for the A10 connection. Failure detection at the PCF: If the PCF does not receive a valid A11-Registration Reply message from the PDSN before timer Tregreq expires, the PCF may retransmit the A11-Registration Request message with a new timestamp in the Identification information element and restart timer Tregreq. A connection establishment or refresh is considered to have failed if no valid A11-Registration Reply message is received after a configurable number of A11-Registration Request message retransmissions. For a connection refresh or release, on failure to receive a valid A11-Registration Reply message in response to a configurable number of A11-Registration Request message retransmissions, the PCF removes the binding record for the A10 connection. 2.1.2 A11-Registration Reply
17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35
36 37 38
The PDSN sends this message to the PCF to acknowledge receipt of an A11-Registration Request message. 2.1.2.1 Successful Establishment Operation Upon receipt of an A11-Registration Request message with a nonzero Lifetime value, the PDSN shall respond with an A11-Registration Reply message containing the appropriate value in the Code IE. For a valid A11-Registration Request message, if the PDSN accepts establishment of the A10 connection, it shall send a Registration Accepted indication (Code value 00H) and a non-zero Lifetime parameter value in the message. The value of the Lifetime parameter in the A11-Registration Reply message shall be less or equal to the value of the Lifetime parameter received in the A11-Registration Request message. Upon receiving the A11-Registration Reply message, the PCF shall perform authentication and identification checks. After the message passes the checks, the PCF shall stop timer Tregreq and start the Lifetime timer initialized to the value of the returned Lifetime parameter. D-4
39 40 41 42 43 44 45 46 47 48
3GPP2 A.S0008-C v2.0

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
In HRPD systems, if the A11-Registration Reply message establishes the main A10 connection, then the PDSN includes the Subscriber QoS Profile, if applicable (e.g., during dormant handoff). In HRPD systems, when the PDSN receives an A11-Registration Request message including Additional Session Information with a non-zero Lifetime value, the PDSN establishes the corresponding A10 connection(s) that the PDSN can support to setup and do not already exist with that PCF. If the PDSN has data to send to the PCF when it receives an A11-Registration Request message, the PDSN shall include a Data Available Indication as a CVSE in the A11-Registration Reply message. If the PDSN accepts a fast handoff request, the A11-Registration Reply message shall include an NVSE containing the Anchor P-P Address value copied from the corresponding A11-Registration Request message. If the PDSN supports fast handoff and becomes the anchor PDSN, the PDSN shall include its Anchor P-P Address in an NVSE in the A11-Registration Reply message. If the selected PDSN does not accept establishment of the A10 connection, it shall return an A11Registration Reply message with a reject result code in the Code IE. Upon receipt of this message, the PCF shall stop timer Tregreq. In HRPD system, if the selected PDSN does not accept establishment of any auxiliary A10 connection(s) in an A11-Registration Request message, it shall return an A11-Registration Reply message with a reject result code in the Code IE. Upon receipt of this message, the PCF shall stop timer Tregreq. However, if the selected PDSN can accept parts of auxiliary A10 connection(s) in an A11-Registration Request message, it shall return an A11-Registration Reply message with a code value Partial Connection Establishment in the Code IE. 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 A11Registration Reply message. The address of the alternate proposed PDSN shall be returned in the Home Agent field of the A11-Registration Reply message. Upon receipt of this message, the PCF shall stop timer Tregreq. 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 it shall use internal algorithms to select a new PDSN. If the PCF receives a valid A11-Registration Reply message before timer Tregreq expires that indicates identification mismatch (Code value 85H), the PCF may adjust the clock that it uses for communication with the PDSN, retransmit the A11-Registration Request message with a newly generated Identification IE, and restart timer Tregreq. On receipt of a valid 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 with the same or another PDSN; refer to PDSN Selection Algorithm in [13]. The PDSN may provide the PCF with an indication of PDSN enabled features for the A10 connection (e.g. flow control). 2.1.2.2 Successful Refresh Operation Upon receipt of a valid A11-Registration Request message with a nonzero Lifetime value, the PDSN shall respond with an A11-Registration Reply message with an accept indication (Code value 00H), including a Lifetime parameter value less or equal to the value of the received Lifetime parameter and restart the Lifetime timer initialized to the value of the returned Lifetime parameter. Upon receipt of this message, the PCF shall stop timer Tregreq and start the Lifetime timer initialized to the value of the returned Lifetime parameter. If the PCF receives a valid A11-Registration Reply message before timer Tregreq expires that indicates identification mismatch (Code value 85H), the PCF may adjust the clock that it uses for communication with the PDSN, retransmit the A11-Registration Request message with a newly generated Identification IE and restart timer Tregreq. D-5
38 39 40 41 42 43 44 45 46 47 48
3GPP2 A.S0008-C v2.0

1 2 3 4
On receipt of a valid A11-Registration Reply message that contains a Code other than Registration accept (00H) or Identification mismatch (85H), the PCF may resend the message with a newly generated Identification IE based on the clock it uses for communication with the PDSN; otherwise the PCF shall initiate release of the A10 connections to this PDSN. 2.1.2.3 Successful Release Operation Upon receipt of a valid A11-Registration Request message with Lifetime field set to zero, the PDSN shall respond with an A11-Registration Reply message with an accept indication. Upon receipt of this message, the PCF shall remove the binding record for the A10 connection and stops timer Tregreq. In HRPD systems, upon receipt of a valid A11-Registration Request message with the Lifetime value set to zero, the PDSN shall release all A10 connections for the AT. In HRPD systems, when the PDSN receives an A11-Registration Request message including Additional Session Information with a non-zero Lifetime value, the PDSN releases the A10 connections that are not referred to in the Additional Session Information. If the PCF receives a valid A11-Registration Reply message before timer Tregreq expires that indicates identification mismatch (Code value 85H), the PCF may adjust the clock that it uses for communication with the PDSN, retransmit the A11-Registration Request message with a newly generated Identification IE and restart timer Tregreq. On receipt of a valid A11-Registration Reply message that contains a Code other than Registration accept (00H) or Identification mismatch (85H), the PCF may resend the message with a newly generated Identification IE based on the clock it uses for communication with the PDSN; otherwise the PCF shall initiate release of the A10 connections to this PDSN. 2.1.2.4 Failure Operation Failure detection at the PCF: If the A11-Registration Reply message is invalid, the PCF shall discard the message. Failure detection at the PDSN: None. 2.1.3 A11-Registration Update
5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
22 23 24 25
26 27 28
In 1x systems, tThe PDSN sends this message to the PCF to initiate release of an A10 connection. In HRPD systems, the PDSN sends this message to release all A10 connections associated with an AT. 2.1.3.1 Successful Operation The PDSN may initiate release of an A10 connection by sending an A11-Registration Update message to the PCF to initiate release of one A10 connection in 1x systems or all A10 connections associated with an AT in HRPD systems. The Home Agent field in the A11-Registration Update message is the PDSN Address and the Home Address is set to zero. The PCF Session Identifier and other session specific information are sent within the Session Specific extension. After sending this message, the PDSN starts timer Tregupd. In HRPD systems, when a main A10 connection is established for an AT, an A11-Registration Update message shall be sent to release the old main A10 connection. Refer to [8] for the inter-PDSN case when a new A10 is established and an old A10 exists under a different PDSN. 2.1.3.2 Failure Operation Failure detection at the PCF: If the A11-Registration Update message is invalid, the PCF shall keep the binding for the A10 connection(s) and shall not update its Lifetime timer. The PCF shall send an A11Registration Acknowledge message indicating identification mismatch (Status value 85H) or authentication failure (Status value 83H); refer to section 2.1.4.
29 30 31 32 33 34 35 36 37 38
39 40 41 42 43
D-6
3GPP2 A.S0008-C v2.0

1 2 3 4 5 6 7 8 9 10
Failure detection at the PDSN: If the PDSN does not receive a valid A11-Registration Acknowledge message or an A11-Registration Request message (with the Lifetime parameter set to 0 and accounting related information included) before timer Tregupd expires, the PDSN may retransmit the A11Registration Update message with a new timestamp in the Identification information element and restart timer Tregreq a configurable number of times. If the PDSN has not received a valid A11-Registration Acknowledge message with an update accepted status indication (Status value 00H) or an A11-Registration Request message (with Lifetime parameter set to 0 and accounting related information included) after a configurable number of retransmissions, the PDSN shall remove the binding record for the A10 connection.
11 12
2.1.4
A11-Registration Acknowledge
13 14 15
2.2
A10-Connection Update Procedures
The PDSN initiates the update of new or additional packet data session parameters on an existing A10 connection with the messages described in this section. 2.2.1 A11-Session Update
16 17 18
The A11-Session Update message is sent from the PDSN to the PCF to add, change, or update session parameters for an A10 connection. It is also sent to update the PCF with the Anchor P-P Address. In HRPD systems, the A11-Session Update message is sent to deliver a new or updated Subscriber QoS Profile to the PCF after establishment of the main A10 connection. In HRPD systems, this message may also be used by the PDSN to update the QoS for one or more specific IP flows. If there is a Flow Profile ID with the value 0x0000 in the U_QoS_SUB_BLOB for an IP flow, then the AN shall inform the AT that the requested QoS_SUB_BLOB has been added but is invalid for this AN and the AT should not activate the corresponding IP flow. Otherwise upon receipt of the updated QoS, the AN shall change the granted QoS for the corresponding IP flow to the first acceptable Flow Profile ID in the list, irrespective of the contents of the subscriber QoS Profile. A Flow Profile ID shall be considered acceptable if it is supported by the AN, if it matches one of the Flow Profile IDs requested by the AT, and if the call is not in inter-PCF handoff. The AN shall store the updated QoS information received from the PDSN together with the personality index in use at the time the update was received. Whenever the specified personality index is in use, the AN shall use the stored QoS update to grant the QoS irrespective of the contents of the subscriber QoS Profile. All updated QoS information stored in the AN for a given IP flow is cleared when the corresponding IP flow is set to null (refer to [10]) 79, regardless of the personality in use. Updated QoS information received from the PDSN (via the PCF) supersedes stored updated QoS information previously received from the PDSN or from another AN (via A13 or A16). In HRPD systems, this message is also used to release one or more IP flows by setting the FlowProfile ID value to 0x0000 in the Forward/Reverse Updated QoS Sub-BLOB for the IP flow that the PDSN wants to release. The PDSN should not use this procedure for flow ID FFH and FEH.
19 20
21 22 23 24 25 26 27 28 29 30 31 32 33
34 35
36 37 38
79 i.e., ProfileType = NULL in ReservationKKQoSRequestFwd or ReservationKKQoSRequestRev.
D-7
3GPP2 A.S0008-C v2.0

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
2.2.1.1 Successful Operation The PDSN may update session parameters of an A10 connection, or the Anchor P-P Address, or the Subscriber QoS Profile, or update the QoS of specific flows by sending an A11-Session Update to the PCF. The Home Agent field in A11-Session Update message is the PDSN Address and the Home Address is set to zero. The PCF Session Identifier and other session specific information are sent within the Session Specific Extension. The A11-Session Update message includes the session parameter(s), or the Anchor P-P Address, the Subscriber QoS Profile, and/or QoS Update Information in NVSE(s). In HRPD systems, the A11-Session Update message includes the subscriber QoS profile and/or QoS Update Information. For session parameter(s), the PCF shall update its session parameters or relay the parameters to the BS according to the specified behavior for the particular parameter. The PCF shall relay the Anchor P-P Address to the BS. For the Subscriber QoS Profile, the PCF shall update its Subscriber QoS Profile if the packet data session is dormant or relay the parameters to the AN if the packet data session is active. If the A11-Session Update message includes updated QoS for one or more IP flows and the RAN does not have sufficient resources available to comply with the updated QoS for all of the specified flows, then the PCF may reject the A11-Session Update message by sending an A11-Session Update Ack message with the Status IE set to Update Denied insufficient resources. If the A11-Session Update message includes updated QoS and the RAN only has resources available to comply with the updated QoS for some of the specified flows, the PCF may respond by sending an A11Session Update Ack message with the Status IE set to Partial QoS updated. The PCF informs the PDSN of which QoS updates were accepted and which were rejected using the IP flow mapping update procedure. After sending the A11-Session Update message, the PDSN shall start timer Tsesupd. 2.2.1.2 Failure Operation Failure detection at the PCF: If the A11-Session Update message is invalid, the PCF shall not update any session parameters. The PCF shall send an A11-Session Update Acknowledge message indicating identification mismatch (Status value 85H) or authentication failure (Status value 83H); refer to section 2.2.2. Failure detection at the PDSN: If the PDSN does not receive a valid A11-Session Update Acknowledge message before timer Tsesupd expires, the PDSN may retransmit the A11-Session Update message with a new timestamp in the Identification information element a configurable number of times to the PCF. If the PDSN has not received an A11-Session Update Acknowledge with an accept indication (Status value 00H) after a configurable number of retransmissions, the PDSN shall consider the update failed and shall maintain the A10 connection. 2.2.2 A11-Session Update Acknowledge
24 25 26 27 28 29 30 31 32 33 34
35 36
37
2.3 A10 Packet Accounting Procedures

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 Tables 2.34-1 and 2.3-2 below. The occurrence of these predefined triggers is fully specified in [8]. The A10 connection binding record at the PDSN and the PCF may also be updated appropriately depending on the setting of the Lifetime field.
38 39 40 41 42 43 44
D-8
3GPP2 A.S0008-C v2.0

1 2
Table 2.3-1
Accounting Records Generated by the PCF in 1x and HRPD systems without IP Flow Based Accounting Accounting Records Generated by the PCF
Airlink Record Type (Y1) Y1=1 Y1=2 Y1=3 Y1=4

3 4 5
Connection Setup: Setup of A10 connection initiated Active Start: A10 connection is associated with the traffic channel(s) or new parameters are set. Active Stop: A10 connection is disassociated from the traffic channel(s) or parameter settings are no longer valid. A forward or reverse short data burst (SDB) was exchanged with the MS. This record is not used in the HRPD system.
Table 2.3-2 Accounting Records Generated by the PCF in HRPD Systems with IP Flow Based Accounting Airlink Record Type (Y1) Y1=1 Y1=2 Accounting Records Generated by the PCF
Connection Setup: Setup of A10 connection initiated Active Start: For IP flows with ID FFH, when the main A10 connection is associated with the traffic channel; or new parameters are set. For all other IP flows, when both of the following become true for that IP flow: o the IP flow is in the active state, and o its associated link flow is associated with the traffic channel; or when new parameters are set. Active Stop: For IP flows with ID FFH, when the main A10 connection is disassociated from the traffic channel, or parameter settings are no longer valid. For all other IP flows, when the IP flow is in the active state and its associated link flow is associated with the traffic channel, and then one or more of the following occurs: o the traffic channel is released, o the IP flow is deactivated or removed, o its link flow is disassociated with the traffic channel; or when parameter settings are no longer valid.
Y1=3
D-9
3GPP2 A.S0008-C v2.0

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
In addition, the PCF generates an Active Stop (Y1=3) accounting record followed by an Active Start (Y1=2) accounting record when certain parameters change value. Refer to section 2.3.7 for details. For successful operation, the PDSN saves the accounting related and other information for further processing, and responds with an A11-Registration Reply message containing an accept indication. The Airlink Record information is transferred from the PCF to the PDSN, as RADIUS protocol encoded attributes, in the Application Data field of a CVSE element. If the PDSN receives an unexpected airlink record it may reject the A11-Registration Request message and the A11-Registration Reply message shall contain the code 86H (Registration Denied poorly formed request). If the PDSN does not receive an accounting parameter that is expected, the PDSN may reject the A11-Registration Request message, and the associated A11-Registration Reply message shall contain either: code 8DH (Registration Denied unsupported Vendor ID or unable to interpret Application Type or Application Sub Type in the CVSE sent by the PCF to the PDSN), or code 86H (Registration Denied poorly formed request). If the PDSN receives a RADIUS attribute that is not expected in a CVSE, the PDSN shall ignore that attribute and process the remainder of the CVSE to the extent possible. Refer to section 4.2.13 for further details. 2.3.1 A10 Connection Setup Airlink Record
17 18 19 20 21 22 23
The A10 Connection Setup Airlink record shall be included in the A11-Registration Request message at the time of establishment of a new A10 connection. It is also included in the A11-Registration Request message if an A10 connection is pre-setup during fast handoff. In HRPD systems, if a single A11-Registration Request message is used to establish multiple A10 connections, an A10 Connection Setup Airlink record is included for each of the A10 connections to be established. 2.3.2 Active-Start Airlink Record
24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47
The Active-Start Airlink record shall be included in the A11-Registration Request message under the following circumstances: 1. For 1x systems Wwhen a traffic channel is assigned to a packet data service instance: during initial service instance setup when the service instance becomes associated with the air interface, on transition from dormant to active state or during handoff or for an HRPD 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 A11-Registration Request message (assuming that all the parameters required in the Active-Start Airlink record are made available at the PCF at the time the message is sent). 2. Following an Active-Stop Airlink record when any of the parameters specified in section 2.3.7 are changed. The Active Start Airlink Record shall contain the new set of parameters. 3. For IP flows with ID FFH in HRPD systems, when an HRPD connection is established: during initial session setup when the main A10 connection is associated with the air interface, on transition from dormant to active state, or during handoff. For IP flows with ID FFH in HRPD systems, accounting is bidirectional: one Active-Start Airlink record applies to both forward and reverse IP flows with ID FFH. This record does not include Granted QoS Parameters. 4. For IP flows with ID other than FFH in HRPD systems, when transitioning to a state where the IP flow is in the active state and its associated link flow is associated with the traffic channel. For IP flows with ID other than FFH in HRPD systems, accounting is unidirectional: separate Active-Start Airlink records are generated per {IP flow, Direction} pair. This record shall include Granted QoS Parameters. In HRPD systems, the Active-Start Airlink record may follow the A10 connection Setup Airlink record in the same A11-Registration Request message (assuming that all the parameters required in the Active-Start D-10
3GPP2 A.S0008-C v2.0

1 2
Airlink record are made available at the PCF at the time the message is sent). The PCF shall not send an IP flow active start before sending connection setup for the A10 connection carrying that IP flow. 2.3.3 Active-Stop Airlink Record
3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
The Active Stop Airlink Record shall be included in the A11-Registration Request message under the following circumstances: 1. In 1x systems, Wwhen the traffic channel is disassociated from the packet data service instance: during service instance release, on transition from active state to dormant, or during handoff. 2. When any of the parameters specified in section 2.3.7 are changed. 3. For IP flows in HRPD systems, when the HRPD connection (traffic channel) is released. 4. For IP flows with ID FFH in HRPD systems, when an HRPD connection is released. For IP flows with ID FFH in HRPD systems, accounting is bidirectional: one Active-Stop Airlink record applies to both forward and reverse IP flows with ID FFH. This record does not include Flow ID Parameter and Flow Status. 5. For IP flows with ID other than FFH in HRPD systems, when the IP flow is removed or transitions to the deactivated state while its associated link flow is associated with the traffic channel, during handoff, or when the IP flows associated link flow is disassociated with the traffic channel while the IP flow is in the activated state. For IP flows with ID other than FFH in HRPD systems, accounting is unidirectional: separate Active-Stop Airlink records are generated per {IP flow, Direction} pair. For inter-PCF handoff, the source PCF shall send an Active-Stop Airlink record for each activated IP flow to the PDSN, and the target PCF shall send Active-Start Airlink records for each activated IP flow to the PDSN. In the case of (2), the Active Stop Airlink Record shall be sent and followed by an Active Start Airlink Record that shall contain the new set of parameters.
24
3.0
3.1
25 26
Message Formats
A11-Registration Request
27 28 29 30 31 32 33 34 35 36 37 38 39 40
This A11 interface message is sent from the PCF to the PDSN to: establish one or more an A10 connection (and identify the associated service option value and MN Session Reference ID/SR_ID); periodically re-register an all A10 connection(s) for the MS/AT; clear one or more an A10 connection(s); pass accounting related information per the triggers listed in Table 2.3-1 and Table 2.3-2;. perform any additions, deletions, remappings, and/or changes in granted QoS of IP flows in HRPD systems. The A11-Registration Request messages may contain additional information to: indicate that all packet data service instances have gone dormant; pass fast handoff related information;. indicate support of features such as Short Data Indication
D-11
3GPP2 A.S0008-C v2.0 Information Element A11 Message Type Flags Lifetime Home Address Home Agent Care-of-Address Identification Session Specific Extension Critical Vendor/Organization Specific Extension Normal Vendor/Organization Specific Extension Mobile-Home Authentication Extension
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
Section Element Reference Direction 4.2.1 4.2.2 4.2.3 4.2.4 4.2.5 4.2.6 4.2.7 4.2.12 4.2.13 4.2.14 4.2.10 PCF -> PDSN M PCF -> PDSN O PCF -> PDSN O PCF -> PDSN O PCF -> PDSN O PCF -> PDSN O PCF -> PDSN O PCF -> PDSN O PCF -> PDSN O PCF -> PDSN O
i l h
Type
R R R R R R R C C R
a,e
PCF -> PDSN O
a,b,c,d,f,g,j,k,m,n,o
a. One or more instances of this element may be included. b During a fast handoff, this element is used to provide the Anchor P-P Address to the target PDSN when the PCF supports fast handoff. If an Anchor P-P Address is included in the message and the PDSN supports fast handoff, then the PDSN shall process the fast handoff request, and disregard the ANID values.
c. If this message contains the Active Stop Airlink Record for the last service instance going dormant (i.e., all packet data service instances for the user are dormant) in the CVSE, then an instance of this element containing the All Dormant Indicator shall be included in this message. d. This element shall be included when this message is sent for A10 connection setup and the PCF is capable of supporting multiple service instances. In 1x systems, Application Type = Service Option It contains the Service Option value received from the BS for the PDSI. In HRPD systems, Application Type = Service Option contains the SO value for the main service instance. The main service instance is defined to have SR_ID=1. e. During a handoff, this element is used to provide the MEI. f. During a handoff, this element is used to provide the ANIDs. g. This element may indicate the features that the PCF has enabled e.g., Short Data Indication. h. For HRPD systems, Lifetime applies to all A10 connections set up by this message when this message is sent. If the lifetime field is set to 0, all A10 connections associated with the HRPD session are released. i. j. In 1x systems, this IE contains information for the main service instance. In HRPD systems, this IE contains information for the main service connection. If the PCF supports ANIDs, then this IE shall be included to convey the Access Network Identifiers to the PDSN.
k. For HRPD systems, this IE may be used to set up auxiliary A10 connections. When setting up auxiliary A10 connections, this IE is also used to send information for all existing A10 connections. l. This IE contains the IPv4 address of the PCF that terminates the main A10 connection (identified in the Session Specific Extension IE). Note that this address may be different from the source IP address of this message.
m. For HRPD, this IE may be included to specify IP flows associated with the A10 connections and to convey QoS information for those IP flows (Flow State, Requested QoS, and Granted QoS). Each instance of this IE with QoS Information application type contains QoS information for IP flows D-12
3GPP2 A.S0008-C v2.0

1 2 3 4 5 6 7 8
associated with one direction of one A10 connection. Multiple instances of the QoS Information application type NVSE are used for transmission of QoS Information in both directions of an A10 connection and for multiple A10 connections (i.e., multiple SR_IDs) in the same A11-Registration Request message. n. For HRPD systems, this IE is used to provide QoS information. o. This IE shall be included when this message is sent for setting up the main A10 connection to convey the QoS mode Session Parameter. If the PDSN does not receive the QoS Mode, then the PDSN shall assume the QoS Mode is set to 0. The following table shows the bitmap layout for the A11-Registration Request message.
3.1 0 1 2 A11-Registration Request 3 4 5 6 7 Octet 1 1 1 (LSB) (MSB) Home Address = [00 00 00 00H] 2 1 2 3 (LSB) (MSB) Home Agent = <any value> 4 1 2 3 (LSB) (MSB) Care-of-Address = <any value> 4 1 2 3 (LSB) (MSB) Identification = <any value> 4 1 2 3 4 5 6 7 (LSB) Session Specific Extension: = [27H] Length = [13H15H] (MSB) (MSB) Protocol Type = [88 81H] (LSB) Key = <any value> 8 1 2 3 4 5 6
A11 Message Type = [01H] Flags = [0AH, 8AH] (MSB) Lifetime = [00 00H to FF FEH]
D-13
3GPP2 A.S0008-C v2.0

3.1 0 1 2 A11-Registration Request 3 4 5 6 7 (LSB) Reserved = [00H] Session ID Ver = [00 (Version 0), 01 (Version 1)] MN Session Reference Id = [00 01H - 00 06H], in 1x systems [00 01H] in HRPD systems Reserved = [0000 00] (LSB) (MSB) MSID Type = [00 06H] (IMSI) (LSB) MSID Length = [06-08H] (10-15 digits) Identity Digit 1 = [0H-9H] (BCD) Identity Digit 3 = [0H-9H] (BCD) Odd/Even Indicator = [0000, 0001] Identity Digit 2 = [0H-9H] (BCD) Octet 7 8 9 10 11 12 13 14 15 16 17
(MSB)
If (Odd/Even Indicator = 0000 (even)) {Identity Digit N+1 = [FH] (BCD)} Else If (Odd/Even Indicator = 0001 (odd)) {Identity Digit N+1 = [0H-9H] (BCD)}
Critical Vendor/Organization Specific Extension: Type = [26H] Reserved = [0000 0000] (MSB) (MSB) Length = <variable> (LSB) 3GPP2 Vendor ID = 00 00 15 9FH
1 2 3 4 5 6 7 (LSB) 8 9 10 11
Application Type = [01H, 02H] IF (Application Type = 01H (Accounting) {1: Application Sub Type = [01H] (MSB) Application Data (contains accounting information)
(LSB) } Application Type = 01H; ELSE IF (Application Type = 02H (Mobility Event Indicator)) {1: Application Sub Type = [01H] } Application Type = 02H Normal Vendor/Organization Specific Extension: Type = [86H] Length = <variable> (MSB) (MSB) Reserved = [00 00H] (LSB) 3GPP2 Vendor ID = [00 00 15 9FH] 1 2 3 4 5 m k
D-14
3GPP2 A.S0008-C v2.0

3.1 0 1 2 A11-Registration Request 3 4 5 6 7 Octet 6 7 (LSB) Application Type = [04H-06H, 08H, 09H, 0B-0DH, 0FH, 10H] (Access Network Identifiers, PDSN Identifier, Indicators, Session Parameter, Service Option, PCF Enabled Features, Additional Session Information, QoS Information, Information, HRPD Indicators) IF (Application Type = 04H (Access Network Identifiers)) {1: Application Sub Type = [01H] (MSB) Application Data = <any value> (contains PANID and CANID) 10 11 8 9
(LSB) } Application Type = 04H, ELSE IF (Application Type = 05H (PDSN Identifier)) {1: Application Sub Type = [01H (Anchor P-P Address)] (MSB) Application Data (contains an IPv4 address) 10 11 12 13 (LSB) } Application Type = 05H; ELSE IF (Application Type = 06H (Indicators)) {1 Application Sub Type = [01H (All Dormant Indicator)] (MSB) Application Data = [00 00H] (LSB) } Application Type = 06H; ELSE IF (Application Type = 08H (Session Parameter)) {1: Application Sub Type = [03H (QoS Mode)] Application Data = [00H-01H] } Application Type = 06H08H; ELSE IF (Application Type = 09H (Service Option)) {1: Application Sub Type = [01H] (MSB) Application Data = (contains Service Option) for 1x systems [00 3BH (HRPD PPP Main Service Instance), 00 47H (AltPPP operation)] for HRPD systems (LSB) } Application Type = 09H; ELSE IF (Application Type = 0BH (PCF Enabled Features)){1 Application Sub Type = [01H (Short Data Indication Supported = 01H), 02H (GRE Segment Enabled)] } Application Type = 0BH; ELSE IF (Application Type = 0CH (Additional Session Information)) {1: Application Sub Type = [01H] GRE Key Information Entry { 1-30: Entry Length = [0DH] SR_ID = [02H-1FH] n n+1 10 10 10 11 10 11 10 11 12 14 20
12
D-15
3GPP2 A.S0008-C v2.0

3.1 0 (MSB) 1 2 A11-Registration Request 3 4 5 6 7 Octet n+2
Service Option = [ 00 40H (HRPD Auxiliary Service Connection with higher layer framing for packet synchronization), 00 43H (HRPD Auxiliary Service Connection without higher layer framing for packet synchronization) ] (LSB) Protocol Type = [88 81H] (LSB) Key = <any value>
n+3 n+4 n+5 n+6 n+7 n+8
(MSB) (MSB)
(LSB) (MSB) Source IP Address = <any value>
n+9 n+10 n+11 n+12
(LSB) Forward ROHC Info{1: Forward ROHC Info Length = <variable> (MSB) (MSB) LargeCIDs = [0,1] Forward Profile { Forward ProfileCount: (MSB) } Forward Profile } Forward ROHC Info Reverse ROHC Info{1: Reverse ROHC Info Length = <variable> (MSB) (MSB) Reverse LargeCIDs = [0,1] Reverse Profile { Reverse ProfileCount: Reverse MaxCID = <any value> (LSB) Reverse MRRU = <any value> (LSB) Reserved = [000 0000] Forward Profile = <any value encoded as specified in [27]> (LSB) Forward MaxCID = <any value> (LSB) Forward MRRU = <any value> (LSB) Reserved = [000 0000] Forward ProfileCount = <any value>
n+13 p p+1 p+2 p+3 p+4 p+5 p+6 q q+1
p p+1 p+2 p+3 p+4 p+5
Reverse ProfileCount = <any value>
p+6
D-16
3GPP2 A.S0008-C v2.0

3.1 0 (MSB) } Reverse Profile } Reverse ROHC Info } GRE Key Information Entry } Application Type = 0CH; ELSE IF (Application Type = 0DH (QoS Information)){1: Application Sub Type = [01H - 02H] IF (Application Sub Type = 01H (Forward QoS Information)){1: SR_ID = [01H-1FH] Use IP Flow Discrimination = [0,1] DSCP Included = [0,1] Reserved = [00 0000] 11 12 10 1 2 A11-Registration Request 3 4 5 6 7 (LSB) Octet q q+1
Reverse Profile = <any value encoded as specified in [27]>
Reserved = [000]
Forward Flow Count = [1 31] Forward Flow Entry { Forward Flow Count : Entry Length = [variable] Forward Flow ID = [00H - FFH]
13 n n+1 Flow State = [0, 1] n+2
Reserved
DSCP
n+3 n+4
p p+1 p+2
} Application Sub Type = 01H; ELSE IF (Application Sub Type = 02H (Reverse QoS Information)){1: SR_ID = [01H-1FH] Reserved = [000] Reverse Flow Count = [1 31] Reverse Flow Entry { Reverse Flow Count : Entry Length = [variable] Reverse Flow ID = [00H - FFH] Reserved = [0000 000] Flow State = [0, 1] n n+1 n+2 11 12
n+3 n+4
D-17
3GPP2 A.S0008-C v2.0

3.1 0 1 2 A11-Registration Request 3 4 5 6 7 (LSB) Reverse Granted QoS Length = [variable] (MSB) Reverse Granted QoS = <any value> Octet p p+1 p+2
(LSB) } Reverse Flow Entry } Application Sub Type = 02H } Application Type = 0DH; ELSE IF (Application Type = 0FH (Information)){1: Application Sub Type = [01H] IF (Application Sub Type = 01H (Cause){1: Cause Value = [01H (Packet data session release), 02H (Air link lost)] } Application Sub Type = 01H } Application Type = 0FH; ELSE IF (Application Type = 10H (HRPD Indicators)) {1: Application Sub Type = [01H (Emergency Services)] Emergency Services = [0, 1] Reserved
r r+1
10 11
} Application Sub Type = 01H } Application Type = 10H Mobile-Home Authentication Extension: Type = [20H] Length = [14H] (MSB) SPI = [00 00 01 00H to FF FF FF FFH] 1 2 3 4 5 (LSB) (MSB) Authenticator = <any value > (keyed-MD-5 authentication) 6 7 8 9
(LSB)
1 2 3
22
3.2
A11-Registration Reply
This A11 interface message is sent from the PDSN to the PCF in response to an A11-Registration Request message.
Information Element A11 Message Type Code Section Element Direction Reference 4.2.1 4.2.8 PDSN -> PCF PDSN -> PCF M M Type
D-18
3GPP2 A.S0008-C v2.0

Information Element Lifetime Home Address Home Agent Identification Session Specific Extension Critical Vendor/Organization Specific Extension Normal Vendor/Organization Specific Extension Mobile-Home Authentication Extension
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
Section Element Direction Reference 4.2.3 4.2.4 4.2.5 4.2.7 4.2.12 4.2.13 4.2.14 4.2.10 PDSN -> PCF PDSN -> PCF PDSN -> PCF PDSN -> PCF PDSN -> PCF PDSN -> PCF PDSN -> PCF PDSN -> PCF M M Ma M Mi Ob O
Type
C C R
c,d,e,f,g,
h,j,k,l,m
a. This element can also be used to identify the IPv4 address of an alternative PDSN. b. This element is included if the PDSN has data available. c. This element is used by the anchor PDSN to provide an Anchor P-P Address when the PDSN supports fast handoff. d. One or more instances of this element may be included. e. During a fast handoff, the target PDSN includes the Anchor P-P Address to indicate that the fast handoff request was accepted. f. This element is used to send a Radio Network Packet Data Inactivity Timer (RN-PDIT) to the PCF when supported.
g. When an Always-on Indicator is present at the PDSN, the PDSN shall include the NVSE with an Always-on indicator. h. This element is used by the PDSN to indicate that flow control is enabled for the packet data service instance. i. j. In 1x systems, this IE contains information for the main service instance. In HRPD systems, this IE contains information for the main service connection. If this message is sent to establish the main A10 connection during dormant handoff in an HRPD system, the PDSN shall include the NVSE with the saved Subscriber QoS Profile, if any.
k. This IE contains information (in the Additional Session Information application type) for auxiliary A10 connection(s) requested in the corresponding A11-Registration Request message. l. In HRPD systems with QoS, this element is included by the PDSN when this message is sent to establish the main A10 connection. It provides the PDSN ROHC channel parameter values when ROHC on SO67 is supported with ROHC in the PDSN.
m. This IE may be used to indicate that the PDSN supports receiving the GRE segmentation attribute in A10 GRE frames. The following table shows the bitmap layout for the A11-Registration Reply message.
3.2 0 1 2 3 A11-Registration Reply 4 5 6 7 Octet 1
26
A11 Message Type = [03H]
D-19
3GPP2 A.S0008-C v2.0

3.2 0 [00H 02H 80H 81H 82H 83H 85H 86H 88H 89H 8AH 8BH 8CH 8DH 1 2 3 A11-Registration Reply 4 5 6 7 Octet 1
Code = (Registration Accepted), (Registration Accepted, but partial connection establishment), (Registration Denied reason unspecified), (Registration Denied administratively prohibited), (Registration Denied insufficient resources), (Registration Denied PCF failed authentication), (Registration Denied identification mismatch), (Registration Denied poorly formed request), (Registration Denied unknown PDSN address), (Registration Denied requested reverse tunnel unavailable), (Registration Denied reverse tunnel is mandatory and T bit not set), (Registration Denied service option not supported), (Registration Denied no CID available), (Registration Denied unsupported vendor ID or unable to interpret Application Type or Application Sub Type in the CVSE sent by the PCF to the PDSN.), 8EH (Registration Denied - nonexistent A10 or IP flow)] Lifetime = [00 00H to FF FEH] (LSB) Home Address = [00 00 00 00H]
(MSB) (MSB)
1 2 1 2 3 (LSB) 4 1 2 3 (LSB) 4 1 2 3 4 5 6 7 (LSB) 8 1 2 3 (LSB) 4 5 6 7
(MSB)
Home Agent = <any value>
(MSB)
Identification = <any value>
Session Specific Extension: Type = [27H] Length = [13H 15H] (MSB) (MSB) Protocol Type = [88 81H] Key = <any value>
D-20
3GPP2 A.S0008-C v2.0

3.2 0 1 2 3 A11-Registration Reply 4 5 6 7 (LSB) Reserved = [00H] Reserved = [0000 00] (MSB) Session ID Ver = [00 (Version 0), 01 (Version 1)] Octet 8 9 10 11 (LSB) (MSB) MSID Type = [00 06H] (IMSI) (LSB) MSID Length = [06-08H] (10-15 digits) Identity Digit 1 = [0H - 9H] (BCD) Identity Digit 3 = [0H - 9H] (BCD) Odd/Even Indicator = [0000, 0001] Identity Digit 2 = [0H - 9H] (BCD) 12 13 14 15 16 17
MN Session Reference Id = [00 01H - 00 06H], in 1x systems [00 01H] in HRPD systems
If (Odd/Even Indicator = 0000 (even)) {Identity Digit N+1 = [FH] (BCD)} Else If (Odd/Even Indicator = 0001 (odd)) {Identity Digit N+1 = [0H - 9H] (BCD)}
Identity Digit N = [0H - 9H] (BCD)
21-23
Critical Vendor/Organization Specific Extension: Type = [26H] Reserved = [0000 0000] (MSB) (MSB) Length = [00 06H] (LSB) 3GPP2 Vendor ID = [00 00 15 9FH]
1 2 3 4 5 6 7 (LSB) 8 9 10 1 2 3 4 5 6 7 (LSB) 8 9
Application Type = [03H] (Data Availability Indicator) Application Sub Type = [01H] Normal Vendor/Organization Specific Extension: Type = [86H] Length = <variable> Reserved = [00 00H] (MSB) 3GPP2 Vendor ID = [00 00 15 9FH]
Application Type = [05H (PDSN Identifier, 08H (Session Parameter), 0AH (PDSN Enabled Features), 0CH (Additional Session Information), 0DH (QoS Information), 0EH (Header Compression)] IF (Application Type = 05H (PDSN Identifier)){1
D-21
3GPP2 A.S0008-C v2.0

3.2 0 (MSB) 1 2 3 A11-Registration Reply 4 5 6 7 Octet 10 11 12 13 (LSB) } Application Type = 05H; ELSE IF (Application Type = 08H (Session Parameter)){1 Application Sub Type = [01H (RN-PDIT), 02H (Always-on)] IF (Application Sub Type = 01H (RN-PDIT)) {1 (MSB) Application Data = [01H FFH] (LSB) 11 } Application Sub Type =01H, } Application Type = 08H; ELSE IF (Application Type = 0AH (PDSN Enabled Features)){1: Application Sub Type = [ 01H (Flow Control Enabled), 10 02H (Packet Boundary Enabled), 03H (GRE Segmentation Enabled)] } Application Type = 0AH; ELSE IF (Application Type = 0CH (Additional Session Information)) {1: Application Sub Type = [01H] GRE Key Information Entry { 1 - 30: Entry Length = [0DH] SR_ID = [02H-1FH] (MSB) Service Option = [00 40H (HRPD Auxiliary Service Connection with higher layer framing for packet synchronization), 00 43H (HRPD Auxiliary Service Connection without higher layer framing for packet synchronization)] (LSB) (MSB) (MSB) Protocol Type = [88 81H] (LSB) Key = <any value> n n+1 n+2 10 10 14
Application Sub Type = [01H (Anchor P-P Address)] Application Data (contains an IPv4 address)>
n+3 n+4 n+5 n+6 n+7 n+8
(LSB) (MSB) Source IP Address = <any value>
n+9 n+10 n+11 n+12
(LSB) } GRE Key Information Entry } Application Type = 0CH; ELSE IF (Application Type = 0DH (QoS Information)) {1: Application Sub Type = [03H (Subscriber QoS Profile)] (MSB) Subscriber QoS Profile = <any value>
n+13
10 11 12 13
D-22
3GPP2 A.S0008-C v2.0

3.2 0 1 2 3 A11-Registration Reply 4 5 6 7 Octet
(LSB) } Application Type = 0DH; ELSE IF (Application Type = 0EH (Header Compression) {1: Application Sub Type = [01H (ROHC Configuration Parameters)] (MSB) (MSB) LargeCI Ds = [0,1] MaxCID = <any value> (LSB) MRRU = <any value> (LSB) Reserved = [000 0000]
n 10 11 12 13 14 15
ProfileCount = <any value> Profile {ProfileCount: (MSB) Profile = <any value encoded as specified in [27]> (LSB) } Profile } Application Type = 0EH Mobile-Home Authentication Extension: Type = [20H] Length = [14H] (MSB) SPI = [00 00 01 00H to FF FF FF FFH]
16 n n+1
1 2 3 4 5 (LSB) 6 7 8 9
(MSB)
Authenticator = <any value > (keyed-MD-5 authentication)
(LSB)
1
22
2 3
3.3
Section Element Direction Reference 4.2.1 None 4.2.4 4.2.5 4.2.7 4.2.12 PDSN -> PCF PDSN -> PCF PDSN -> PCF PDSN -> PCF PDSN -> PCF PDSN -> PCF M Ma M M M Mc Type
This A11 interface message is sent from the PDSN to the PCF to release an A10 connections.
Information Element A11 Message Type Reserved <3 octets> Home Address Home Agent Identification Session Specific Extension
D-23
3GPP2 A.S0008-C v2.0

Information Element Normal Vendor/Organization Specific Extension Registration Update Authentication Extension
1 2 3 4
Section Element Direction Reference 4.2.14 4.2.11 PDSN -> PCF PDSN -> PCF Ob M
Type C
a. This field is set to zero by the PDSN and ignored by the PCF. b. This element is used by the PDSN to provide a PDSN code to the PCF. c. For HRPD, the MN Session Reference Id field in this IE shall be set to 1. The following table shows the bitmap layout for the A11-Registration Update message.
3.3 0 1 2 3 A11-Registration Update 4 5 6 7 Octet 1 1 2 3 (MSB) Home Address = [00 00 00 00H] 1 2 3 (LSB) (MSB) Home Agent = <any value> 4 1 2 3 (LSB) (MSB) Identification = <any value> 4 1 2 3 4 5 6 7 (LSB) Session Specific Extension: Type = [27H] Length = [13H 15H] (MSB) (MSB) Protocol Type = [88 81H] (LSB) Key = <any value> 8 1 2 3 4 5 6 7 (LSB) Reserved = [00H] 8 9
Message Type = [14H] Reserved = [00 00 00H]
D-24
3GPP2 A.S0008-C v2.0

3.3 0 1 2 3 A11-Registration Update 4 5 6 7 Session ID Ver = [00 (Version 0), 01 (Version 1)] Octet 10
Reserved = [0000 00]
(MSB)
MN Session Reference Id = [00 01H-00 06H], in 1x systems [00 01H] in HRPD systems (LSB) MSID Type = [00 06H] (IMSI) (LSB) MSID Length = [06-08H] (10-15 digits)
11 12 13 14 15 16 17
(MSB)
Identity Digit 1 = [0H-9H] (BCD) Identity Digit 3 = [0H-9H] (BCD)
Odd/Even Indicator = [0000, 0001] Identity Digit 2 = [0H-9H] (BCD)
If (Odd/Even Indicator = 0000 (even)) {Identity Digit N+1 = [FH] (BCD)} ELSE (If Odd/Even Indicator = 0001 (odd)) {Identity Digit N+1 = [0H-9H] (BCD)}
Normal Vendor/Organization Specific Extension: Type = [86H] Length = <variable> (MSB) (MSB) Reserved = [00 00H] (LSB) 3GPP2 Vendor ID = 00 00 15 9FH
1 2 3 4 5 6 7
(LSB) Application Type = [07H (PDSN CODE)] Application Sub Type = [01H] Application Data = [C1H-C8H, CAH] Registration Update Authentication Extension: Type = [28H] Length = [14H] (MSB) SPI = [00 00 01 00H to FF FF FF FFH]
8 9 10 11 1 2 3 4 5
(LSB) (MSB) Authenticator = <any value > (keyed-MD-5 authentication)
6 7 8 9
(LSB)
1
22
D-25
3GPP2 A.S0008-C v2.0

1 2 3
3.4
A11-Registration Acknowledge
This A11 interface message is sent from the PCF to the PDSN in response to an A11-Registration Update message.
Information Element A11 Message Type Reserved <2 octets> Status Home Address Care-of-Address Identification Session Specific Extension Registration Update Authentication Extension Section Element Direction Reference 4.2.1 None 4.2.9 4.2.4 4.2.6 4.2.7 4.2.12 4.2.11 PCF -> PDSN PCF -> PDSN PCF -> PDSN PCF -> PDSN PCF -> PDSN PCF -> PDSN PCF -> PDSN PCF -> PDSN M Ma M M M M Mb M Type
4 5 6 7
a. This field is set to zero by the PCF and ignored by the PDSN. b. For HRPD, the MN Session Reference Id field in this IE shall be set to 1. The following table shows the bitmap layout for the A11-Registration Acknowledge message.
3.4 0 1 2 A11-Registration Acknowledge 3 4 5 6 7 Octet 1 1 2 [00H 80H 83H 85H 86H (MSB) Status = (Update Accepted) (Update Denied reason unspecified) (Update Denied sending node failed authentication) (Update Denied identification mismatch) (Update Denied poorly formed registration update)] Home Address = [00 00 00 00H] 1
Message Type = [15H] Reserved = [00 00H]
1 2 3 (LSB) 4 1 2 3 (LSB) 4 1 2 3 4 5
(MSB)
Care-of-Address = <any value>
(MSB)
D-26
3GPP2 A.S0008-C v2.0

3.4 0 1 2 A11-Registration Acknowledge 3 4 5 6 7 Octet 6 7 (LSB) Session Specific Extension: Type = [27H] Length = [13H 15H] (MSB) (MSB) Protocol Type = [88 81H] (LSB) Key = <any value> 8 1 2 3 4 5 6 7 (LSB) Reserved = [00H] Reserved = [0000 00] Session ID Ver = [00 (Version 0), 01 (Version 1)] 8 9 10
(MSB)
MN Session Reference Id = [00 01H 00 06H], in 1x systems [00 01H] in HRPD systems (LSB) MSID Type = [00 06H] (IMSI) (LSB) MSID Length = [06-08H] (10-15 digits)
11 12 13 14 15 16 17
(MSB)
If (Odd/Even Indicator = 0000 (even)) {Identity Digit N+1 = [FH] (BCD)} Else If (Odd/Even Indicator = 0001 (odd)) {Identity Digit N+1 = [0H-9H] (BCD)}
Registration Update Authentication Extension: Type = [28H] Length = [14H] (MSB) SPI = [00 00 01 00H to FF FF FF FFH]
1 2 3 4 5 (LSB) 6 7 8 9
(MSB)
(LSB)
1
22
D-27
3GPP2 A.S0008-C v2.0

1 2 3 4 5
3.5
A11-Session Update
This A11 interface message is sent from the PDSN to the PCF to add new or update parameters of an A10 connection. It is also sent to update the PCF with the Anchor P-P Address. In HRPD systems with QoS, this message is sent to convey or update the subscriber QoS profile after establishment of the main A10 connection. In HRPD systems with QoS, this message may also be used for QoS update by the PDSN.
Information Element A11 Message Type Reserved <3 octets> Home Address Home Agent Identification Session Specific Extension Normal Vendor/Organization Specific Extension Registration Update Authentication Extension Section Element Direction Reference 4.2.1 None 4.2.4 4.2.5 4.2.7 4.2.12 4.2.14 4.2.11 PDSN -> PCF PDSN -> PCF PDSN -> PCF PDSN -> PCF PDSN -> PCF PDSN -> PCF PDSN ->PCF PDSN -> PCF M Ma M M M Me Ob,c,d,f, C
g,h
Type
6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28
a. This field is set to zero by the PDSN and ignored by the PCF. b. This element is used by the PDSN to provide an RN-PDIT value to the PCF. c. When an Always-on Indicator is present at the PDSN, the PDSN shall include the NVSE with an Always-on indicator d. This element is included by the PDSN to update the PCF with an Anchor P-P Address for fast handoff. e. For HRPD systems the MN Session Reference ID field of this IE shall be set to 00 01H. f. In HRPD systems, this IE is used when the PDSN updates QoS for one or more IP flows in the specified direction. If there is a Flow Profile ID with the value 0x0000 in the U_QoS_SUB_BLOB for an IP flow, then the AN shall inform the AT that the requested QoS_SUB_BLOB has been added but is invalid for this AN and the AT should not activate the corresponding IP flow. Otherwise upon receipt of the updated QoS, the AN shall change the granted QoS for the corresponding IP flow to the first acceptable Flow Profile ID in the list, irrespective of the contents of the subscriber QoS Profile. A Flow Profile ID shall be considered acceptable if it is supported by the AN, if it matches one of the Flow Profile IDs requested by the AT, and if the call is not in inter-PCF handoff. The target AN shall store the updated QoS lists received from the PDSN and use them to grant the QoS irrespective of the contents of the subscriber QoS Profile.
g. In HRPD systems, this IE is used to release for one or more IP flows in the specified direction. The PDSN shall set the FlowProfile ID value to 0x0000 in the Forward/Reverse Updated QoS SubBLOB for the IP flow to be released. The PDSN should not use this procedure for flow ID FFH and FEH. h. One or more instances of this element may be included. The following table shows the bitmap layout for the A11-Session Update message.
3.5 0 1 2 3 A11-Session Update 4 5 6 7 Octet 1
29
Message Type = [16H]
D-28
3GPP2 A.S0008-C v2.0

3.5 0 (MSB) 1 2 3 A11-Session Update 4 5 6 7 Octet 1 2 (LSB) (MSB) Home Address = [00 00 00 00H] 3 1 2 3 (LSB) (MSB) Home Agent = <any value> 4 1 2 3 (LSB) (MSB) Identification = <any value> 4 1 2 3 4 5 6 7 (LSB) Session Specific Extension: Type = [27H] Length = [13H 15H] (MSB) (MSB) Protocol Type = [88 81H] (LSB) Key = <any value> 8 1 2 3 4 5 6 7 (LSB) Reserved = [00H] Reserved = [0000 00] Session ID Ver = [00 (Version 0), 01 (Version 1)] 8 9 10
Reserved = [00 00 00H]
(MSB)
MN Session Reference Id = [00 01H - 00 06H], in 1x systems [00 01H] in HRPD systems (LSB) MSID Type = [00 06H] (IMSI) (LSB) MSID Length = [06-08H] (10-15 digits)
11 12 13 14 15 16 17
(MSB)
D-29
3GPP2 A.S0008-C v2.0

3.5 0 1 2 3 A11-Session Update 4 5 6 7 Octet
If (Odd/Even Indicator = 0000 (even)) {Identity Digit N+1 = [FH] (BCD)} ELSE (If Odd/Even Indicator = 0001 (odd)) {Identity Digit N+1 = [0H-9H] (BCD)}
Normal Vendor/Organization Specific Extension: Type = [86H] Length = <any value> (MSB) (MSB) Reserved = [00 00H] (LSB) 3GPP2 Vendor ID = [00 00 15 9FH]
1 2 3 4 5 6 7 (LSB) 8 9
Application Type = [05H (PDSN Identifier), 08H (Session Parameter), 0DH (QoS Information)] IF (Application Type = 05H (PDSN Identifier)){1: Application Sub Type = [01H (Anchor P-P Address)] (MSB) Application Data = (contains an IPv4 address)
10 11 12 13 (LSB) 14 10 (LSB) 11
} Application Type = 05H; ELSE IF (Application Type = 08H (Session Parameter)) {1: Application Sub Type = [01H (RN-PDIT), 02H (Always-on)]] IF (Application Sub Type = 01H (RN-PDIT)) {1 (MSB) Application Data = [01HFFH] } Application Sub Type =01H, } Application Type = 08H; ELSE IF (Application Type = 0DH (QoS Information)) {1: Application Sub Type = [03H (Subscriber QoS Profile), FEH (Forward QoS Update Information), FFH (Reverse QoS Update Information)] IF (Application Sub Type = 03H (Subscriber QoS Profile)) {1 (MSB) Subscriber QoS Profile = <any value> 11 12 13 10
(LSB)
} Application Sub Type = 03H}; ELSE IF (Application Sub Type = FEH (Forward QoS Update Information)) {1 Forward Flow Count = [01H - FFH] Forward Flow Entry { Forward Flow Count : Forward Flow ID = [00H - FFH] p 11
D-30
3GPP2 A.S0008-C v2.0

3.5 0 (MSB) 1 A11-Session Update 6 7 Octet p+1 p+2
2 3 4 5 Forward Updated QoS Sub-BLOB Length = [variable]
Forward Updated QoS Sub-BLOB = <any value>
} Application Sub Type = FEH}; ELSE IF (Application Sub Type = FFH (Reverse QoS Update Information)) {1 Reverse Flow Count = [01H - FFH] Reverse Flow Entry { Reverse Flow Count : Reverse Flow ID = [00H - FFH] Reverse Updated QoS Sub-BLOB Length = [variable] (MSB) Reverse Updated QoS Sub-BLOB = <any value> p p+1 p+2 11
(LSB) } Reverse Flow Entry } Application Sub Type = FFH ; } Application Type = 0DH Registration Update Authentication Extension: Type = [28H] Length = [14H] (MSB) SPI = [00 00 01 00H to FF FF FF FFH]
1 2 3 4 5 (LSB) 6 7 8 9
(MSB)
(LSB)
1
22
2 3 4
3.6
A11-Session Update Acknowledge
This A11 interface message is sent from the PCF to the PDSN in response to an A11-Session Update message.
Information Element A11 Message Type Reserved <2 octets> Status Home Address Section Element Direction Reference 4.2.1 None 4.2.9 4.2.4 PCF -> PDSN PCF -> PDSN PCF -> PDSN PCF -> PDSN M Ma M M Type
D-31
3GPP2 A.S0008-C v2.0

Information Element Care-of-Address Identification Session Specific Extension Registration Update Authentication Extension
1
Section Element Direction Reference 4.2.6 4.2.7 4.2.12 4.2.11 PCF -> PDSN PCF -> PDSN PCF -> PDSN PCF -> PDSN M M M M
Type
a. This field is set to zero by the PCF and ignored by the PDSN. The following table shows the bitmap layout for the A11-Session Update Acknowledge message.
3.6 0 1 2 A11-Session Update Acknowledge 3 4 5 6 7 Octet 1 1 2 Status = [00H (Update Accepted) 01H (Partial QoS updated) 80H (Update Denied reason unspecified) 83H (Update Denied sending node failed authentication) 85H (Update Denied identification mismatch) 86H (Update Denied poorly formed registration update) C9H (Update Denied session parameters not updated) FDH (Update Denied QoS profileID not supported) FEH (Update Denied insufficient resources) FFH (Update Denied handoff in progress)] (MSB) Home Address = [00 00 00 00H] 1 Message Type = [17H] Reserved = [00 00H]
1 2 3 (LSB) 4 1 2 3 (LSB) 4 1 2 3 4 5 6 7 (LSB) 8 1 2
(MSB)
Care-of-Address = <any value>
(MSB)
Session Specific Extension: Type = [27H] Length = [13H 15H]
D-32
3GPP2 A.S0008-C v2.0

3.6 0 (MSB) (MSB) 1 2 A11-Session Update Acknowledge 3 4 5 6 7 (LSB) Key = <any value> Octet 3 4 5 6 7 (LSB) Reserved = [00H] Reserved = [0000 00] Session ID Ver = [00 (Version 0), 01 (Version 1)] 8 9 10 Protocol Type = [88 81H]
(MSB)
MN Session Reference Id = [00 01H 00 06H], in 1x systems [00 01H] in HRPD systems (LSB) MSID Type = [00 06H] (IMSI) (LSB) MSID Length = [06-08H] (10-15 digits)
11 12 13 14 15 16 17 k
(MSB)
Identity Digit 1 = [0H-9H] (BCD) Identity Digit 3 = [0H-9H] (BCD) If (Odd/Even Indicator = 0000 (even)) {Identity Digit N+1 = [FH] (BCD)} Else If (Odd/Even Indicator = 0001 (odd)) {Identity Digit N+1 = [0H-9H] (BCD)}
Odd/Even Indicator = [0000, 0001] Identity Digit 2 = [0H-9H] (BCD) Identity Digit N = [0H-9H] (BCD)
Registration Update Authentication Extension: Type = [28H] Length = [14H] (MSB) SPI = [00 00 01 00H to FF FF FF FFH]
1 2 3 4 5 (LSB) 6 7 8 9
(MSB)
(LSB)
1
22
4.2.6 Care-of-Address This element identifies the IPv4 address of the PCF that terminates the main A10 connection. Note that this address may be different from the source IP address of the message containing this IE. The structure of the element conforms to [21] and is shown below.
2 3 4 5
D-33
3GPP2 A.S0008-C v2.0

4.2.6 0 (MSB) 1 2 3 Care-of-Address 4 Care-of-Address 5 6 7 Octet 1 2 3 (LSB)
1
4.2.8 Code This element identifies the result of processing an A11-Registration Request message. The element includes codes from [21] and is shown below. The supported Code values are listed in Table 4.2.8-1. Table 4.2.8-1
Hex Value 00H 02H 09H 80H 81H 82H 83H 85H 86H 88H 89H 8AH 8BH 8CH 8DH 8EH Decimal Value 0 2 9 128 129 130 131 133 134 136 137 138 139 140 141 142 Code Registration Accepted Registration Accepted, but partial connection establishment Reserved Registration Denied reason unspecified Registration Denied administratively prohibited Registration Denied insufficient resources Registration Denied PCF failed authentication Registration Denied identification mismatch Registration Denied poorly formed request Registration Denied unknown PDSN address Registration Denied requested reverse tunnel unavailable Registration Denied reverse tunnel is mandatory and T bit not set Registration Denied service option not supported Registration Denied no CID available Registration Denied unsupported Vendor ID or unable to interpret Application Type or Application Sub Type in the CVSE sent by the PCF to the PDSN Registration Denied - nonexistent A10 or IP flow All other values reserved
2 3 4 5 6
A11 Code Values
4.2.9
Status
9 10
This element identifies the result of processing an A11-Registration Update message or an A11-Session Update message.
4.2.9 0 1 2 3 Status 4 Status 5 6 7 Octet 1
11
The supported Status values are listed in Table 4.2.9-1.
D-34
3GPP2 A.S0008-C v2.0

1
Table 4.2.9-1
Hex Value 0 01H 80H 83H 85H 86H C9H FDH FEH FFH Decimal Value 0 1 128 131 133 134 193 253 254 255 A11 Status
A11 Status Values
Update Accepted Partial QoS updated Update Denied reason unspecified Update Denied sending node failed authentication Update Denied identification mismatch Update Denied poorly formed Registration Update Update Denied Session parameters not updated Update Denied QoS profileID not supported Update Denied insufficient resources Update Denied handoff in progress All other values reserved
4.2.13 Critical Vendor/Organization Specific Extension (CVSE) This element may be present in the A11-Registration Request message to convey 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. The coding format of the CVSE defined herein conforms to [26]. 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. This element reflects Application Type and Application Sub-Types supported in IOS v4.0. New Application Type or Application Sub-Types shall be added to the Normal Vendor/Organization Specific Extension (NVSE) (refer to section 4.2.14). When used to convey 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 [8]. Each application type 01H (Accounting) CVSE contains one and only one airlink record as specified by Tables 4.2.13-2 through 4.2.13-5, and shall include all the parameters listed in the corresponding table unless otherwise specified. For transmission of multiple airlink records in the same A11-Registration Request message, multiple instances of accounting type CVSEs are used.
4.2.13 0 1 Critical Vendor/Organization Specific Extension (CVSE) 2 3 Reserved (MSB) (MSB) Length (LSB) 3GPP2 Vendor ID 4 5 6 7 Octet 1 2 3 4 5 6 7 (LSB) Application Type Application Sub Type (MSB) Application Data 8 9 10 11 A11 Element Identifier (Type)
3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
D-35
3GPP2 A.S0008-C v2.0

4.2.13 0 1 Critical Vendor/Organization Specific Extension (CVSE) 2 3 4 5 6 7 Octet 12

(LSB)
1 2 3 4 5 6 7 8 9 10 11
Note that the Application Type and the Application Sub Type together correspond to the Vendor- CVSEType as defined in [26]. Type: Length: 3GPP2 Vendor ID: Application Type: 26H This field indicates the number of octets in this element following the Length field. 00 00 15 9FH This field indicates the type of application to which the extension relates. The supported values are listed in Table 4.2.13-1.
Application Sub Type: This one octet field indicates the Application sub-type within the Application Type. The supported values are listed in Table 4.2.13-1. Table 4.2.13-1 Application Type and Sub Type
Application Type Name Accounting Value 01H Application Sub Type Name RADIUS DIAMETER Value 01H 02H A11-Registration Request Not used 3.1 Used in Message Reference
All other values are reserved Mobility Event Indicator 02H Mobility 01H A11-Registration Request 3.1
All other values are reserved Data Available Indicator 03H Data Ready to Send 01H A11-Registration Reply 3.2
All other values are reserved All other values are reserved
12 13 14 15 16 17 18 19 20 21 22 23
Application Data:
For Application Type 01H (Accounting), this field contains all the accounting parameters contained in one airlink record conveyed from the PCF to the PDSN as specified in [8]. In this version of this standard, only Application Sub Type = RADIUS is used. Each of the accounting parameters is structured in the format of RADIUS attributes specified in [23] and [24]. Refer to the following text for more details. For Application Type 02H (Mobility Event Indicator), this field is zero bytes in length. For Application Type 03H (Data Available Indicator), this field is zero bytes in length.
For Application Type 01H (Accounting), all 3GPP2 specific Accounting Parameters are coded using RADIUS Vendor-Specific-Attribute format as follows:
1 2 3 4 Type 5 6 7 8 Octet 1
D-36
3GPP2 A.S0008-C v2.0

1 (MSB) 2 3 4 Length 3GPP2 Vendor-Id 5 6 7 8 Octet 2 3 4 5 (LSB) Vendor-Type Vendor-Length (MSB) Vendor-Value (variable number of octets) 6 7 8 9 10
(LSB)
1 2 3 4 5 6 7 8 9 10 11
Type: Length:
1AH 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.} 00 00 15 9FH Sub-Type value from the Airlink Record tables below. Vendor-Type (1 octet) + Vendor-Length (1 octet) + Payload Length (in octets) from the Airlink Record tables below. Payload of the accounting parameter.
Vendor ID: Vendor Type: Vendor-Length: Vendor-Value:
For Application Type 01H (Accounting) all RADIUS specific Airlink Record Parameters are coded as follows:
1 2 3 4 Type Length (MSB) Value (variable number of octets) 5 6 7 8 Octet 1 2 3 4
(LSB)
12 13 14 15 16 17 18
Type: Length: Value:
Type value from the Airlink Record tables below. Type (1 octet) + Length (1 octet) + Payload Length (in octets) from the Airlink Record tables below. Payload of the accounting parameter.
Tables of Fields that may be present in Airlink RecordsAirlink Record Fields Tables: Table 4.2.13-2 A10 Connection Setup Airlink Record (Connection Setup)
Parameter Airlink Record Type = 1 (Setup) Type 26 SubType 40 Max. Payload Length (octet) 4 Format Integer
D-37
3GPP2 A.S0008-C v2.0

Parameter A10 Connection ID Airlink Sequence number MSID ESN
f f
Type 26 26 31 26 26 26
g
SubType 41 42 N/A 52 116 9 10 108
Max. Payload Length (octet) 4 4 15 15 14 4 12 37
Format Integer String String

a
Integer
b d e
MEID
String String
Serving PCF BSID (SID+NID+Cell Identifier) Subnet

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
Ip-addr
c
26 26
String
a. For the main A10 connection, tThis parameter shall be set to the same value as the Key field in the Session Specific Extension information element sent in the A11-Registration Request message. For an auxiliary A10 connection, this parameter shall be set to the same value as the Key field of the corresponding entry in the Additional Session Information NVSE sent in the A11-Registration Request message. b. Each digit is encoded an ASCII character. c. The string is the result of the concatenation of SID+NID+ Cell Identifier (Type 2), where each item is encoded using four hexadecimal uppercase ASCII characters. d. The string consists of the 8-bit ASCII encoding of the uppercase hexadecimal representation of the ESN. e. The string consists of the 8-bit ASCII encoding of the uppercase representation of the Mobile Equipment Identifier. If the network operator uses MEID, this parameter is included if the MEID is available at the RAN at the time of A10 connection establishment. f. Inclusion of ESN, MEID or both parameters in this record is a network operator decision. Table 4.2.13-3 Active Start Airlink Record
Parameter Airlink record type = 2 (START) A10 Connection ID Airlink Sequence number MEID BSID (SID+NID+Cell Identifier) Subnet
h g e,g h
g. Either BSID or Subnet or both shall be included.
Type 26 26 26 26 26 26 26 26 26 26 26
e,g
SubType 40 41 42 116 10 108 11 12 13 16 17
Max. Payload Length (octet) 4 4 4 14 12 37 4 4 4 4 4
Format Integer Integer Integer String

d
String String Integer Integer Integer

a b b
User Zone
Forward FCH Mux Option Reverse FCH Mux Option Service Option
Integer Integer
Forward Traffic Type (Primary, e,g Secondary)
D-38
3GPP2 A.S0008-C v2.0

Parameter Reverse Traffic Type (Primary, e,g Secondary) FCH Frame Size (0/5/20ms) Forward FCH RC Reverse FCH RC
e,g e,g e,g e,g
Type 26 26 26 26 26 26
e,g
SubType 18 19 20 21 50 83 84 85 86 87 114 39 132
Max. Payload Length (octet) 4 4 4 4 4 4 4 4 4 4 4 4 variable
Format Integer Integer Integer Integer

c
b b c
DCCH Frame Size (0/5/20 ms) Forward PDCH RC

e,g
Integer Integer Integer Integer Integer Integer Integer
b b b b b b
Forward DCCH Mux Option Reverse DCCH Mux Option Forward DCCH RC Reverse DCCH RC Reverse PDCH RC Airlink Priority
e e,g e,g
26 26 26 26 26 26 26
e,g
e,g
Integer Integer
f
Granted QoS Parameters

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
a. This parameter shall either be set to 00 00 00 00H or not be included if the PCF does not have the information available. b. This parameter shall not be included if the corresponding physical channel type is not part of the current channel configuration. This note is only applicable to 1x systems. c. This parameter shall be set to zero if the corresponding physical channel type is not part of the current channel configuration. This note is only applicable to 1x systems. d. If the network operator uses MEID, this parameter is may be included if the MEID is available at the RAN. The string consists of the 8-bit ASCII encoding of the uppercase representation of the Mobile Equipment Identifier. Refer to [8]. e. In 1x systems, if the PCF has not received this information from the AN, the PCF shall set this field to a default value of 0. f. This parameter may be included if received from the PCF, except that this parameter shall not be included for Flow ID FFH.
g. This parameter need not be included in HRPD systems. If it is included, the PCF shall set this field to a default value of 0. h. Either BSID or Subnet or both shall be included. Table 4.2.13-4 Active Stop Airlink Record
Parameter Airlink record type = 3 (STOP) A10 Connection ID Airlink Sequence number MEID Type 26 26 26 26 SubType 40 41 42 116 Max. Payload Length (octet) 4 4 4 14 Format Integer Integer Integer String
a
D-39
3GPP2 A.S0008-C v2.0

Parameter Active Connection Time or Flow Activated Time in Seconds Flow ID Parameter Flow Status
1 2 3 4 5 6 7
Type 26 26 26
SubType 49 144 145
Max. Payload Length (octet) 4 2 4
Format Integer Integer Integer
a. If the network operator uses MEID, this parameter is may be included if the MEID is available at the RAN. The string consists of the 8-bit ASCII encoding of the uppercase representation of the Mobile Equipment Identifier. b. This parameter may be included if received from the PCF, except that this parameter shall not be included for Flow ID FFH. Table 4.2.13-5 SDB Airlink Record (1x systems)
Parameter Airlink record type = 4 (SDB) A10 Connection ID Airlink Sequence number Mobile Orig./Term. Indicator SDB Octet Count Type 26 26 26 26 26 SubType 40 41 42 45 31/32
a
Max. Payload Length (octet) 4 4 4 4 4
Format Integer Integer Integer Integer Integer
a. Subtype 31 is for terminating SDB octet count, and subtype 32 is for originating SDB octet count. An example coding of the Active Stop Airlink Record within the CVSE element is illustrated below:
0 1 2 3 Reserved (MSB) (MSB) Length = 36H (LSB) 3GPP2 Vendor ID = 00 00 15 9FH 4 5 6 7 Octet 1 2 3 4 5 6 7 (LSB) Application Type = 01H Application Sub Type = 01H Parameter Name: Airlink Record Type = 3 (Active Stop) Type = 1AH Length = 0CH (MSB) 3GPP2 Vendor-Id = 00 00 15 9FH 11 12 13 14 15 (LSB) Vendor-Type = 28H 16 17 8 9 10 A11 Element Identifier = 26H
D-40
3GPP2 A.S0008-C v2.0

0 MSB 1 2 3 4 5 6 7 Octet 18 19 20 21 (LSB) Parameter Name: A10 Connection ID Type = 1AH Length = 0CH (MSB) 3GPP2 Vendor-Id = 00 00 15 9FH 23 24 25 26 27 (LSB) Vendor-Type = 29H Vendor-Length = 06H (MSB) Vendor-Value = PCF Session Identifier 28 29 30 31 32 33 (LSB) Parameter Name: Airlink Sequence Number Type = 1AH Length = 0CH (MSB) 3GPP2 Vendor-Id = 00 00 15 9FH 35 36 37 38 39 (LSB) Vendor-Type = 2AH Vendor-Length = 06H (MSB) Vendor-Value = Sequence Number 40 41 42 43 44 45 (LSB) Parameter Name: Active Connection Time Type = 1AH Length = 0CH (MSB) 3GPP2 Vendor-Id = 00 00 15 9FH 47 48 49 50 51 (LSB) Vendor Type = 31H Length = 06H 52 53 54 46 34 22
Vendor-Length = 06H Vendor-Value = 3 (Active Stop)
D-41
3GPP2 A.S0008-C v2.0

0 (MSB) 1 2 3 4 5 6 7 Octet 55 56 57 (LSB)
1
Value = Active Connection Time (in seconds)
58
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
4.2.14 Normal Vendor/Organization Specific Extension (NVSE) This element may be included in the A11-Registration Request, A11-Registration Reply, A11Registration Update, and A11-Session Update messages to convey information between the PCF and the PDSN. Any new Application Types or Application Sub-Types supported after IOS v4.0 shall be added to this element. The coding format of the NVSE defined herein conforms to [26]. This element may be included in the A11-Registration Request message to convey the Previous and Current Access Network Identifiers (PANID, CANID) to the PDSN. This element may be included in A11-Registration Reply, A11-Registration Request, or A11-Session Update messages to convey the Anchor PDSN Address for fast handoff when the PCF establishes an A10 connection. When sent by the PCF, the Anchor P-P Address is the address received in the fast handoff request from the source BS/PCF. When sent by the PDSN, the Anchor P-P Address value is copied from the corresponding A11-Registration Request if the PDSN accepts a fast handoff request. It is the PDSNs own P-P address if the PDSN supports fast handoff and becomes the anchor PDSN. If the receiver does not recognize the NVSE Vendor-ID or the NVSE Application Type or Application Sub Type, it shall ignore the NVSE and process the remainder of the message to the extent possible. This element may be included in the A11-Registration Request message to send the All Dormant Indicator for the case of an MS in fast handoff. The serving PCF shall send the All Dormant Indicator to its supporting PDSN when all service instances for the MS become dormant. The PCF shall send this indication in the same message as the Active Stop Airlink Record for the last service instance that becomes dormant. This element may be included in the A11-Registration Update message to indicate the reason the PDSN initiated the release of the packet data session. This element may be included in the A11-Registration Reply or A11-Session Update messages to change the value of a session parameter. This element may be included in the A11-Registration Request message to indicate the service option of a service instance. This element may be included in the A11-Session Update message to indicate a PDSN Identifier. This element may be included in the A11-Registration Request message to indicate the features enables by the PCF. This element may be included in the A11-Registration Reply message to indicate the features enabled by the PDSN. For HRPD, this IE may be included in the A11-Registration Request message to indicate SO, SR_ID, Key, Protocol Type for auxiliary A10 connection(s). For HRPD, this IE may be included in the A11-Registration Reply message to indicate SR_ID and Key for auxiliary A10 connection(s). For HRPD, this IE may be included in the A11-Registration Request message to convey QoS information (IP Flow ID, Flow State, Requested QoS, and Granted QoS). Each instance of the NVSE IE with QoS Information application type contains QoS information for IP flows associated with one direction of one A10 connection. For transmission of QoS Information in both directions of an A10 connection or for D-42
3GPP2 A.S0008-C v2.0

1 2 3 4 5
multiple A10 connections (i.e., multiple SR_IDs) in the same A11-Registration Request, multiple instances of the QoS Information application type NVSE are used. For HRPD, this IE may be included in the A11-Session Update message to convey updated QoS information.
4.2.14 0 1 Normal Vendor/Organization Specific Extension (NVSE) 2 3 Length (MSB) (MSB) Reserved (LSB) 3GPP2 Vendor ID 4 5 6 7 Octet 1 2 3 4 5 6 7 (LSB) Application Type Application Sub Type (MSB) Application Data 8 9 10 11 12 A11 Element Identifier (Type)

(LSB)
6 7 8 9 10 11 12 13 14 15 16
Note that the Application Type and the Application Sub Type together correspond to the Vendor- NVSEType as defined in [26]. Type: Length: 3GPP2 Vendor ID: Application Type: Application Sub Type: 86H This field indicates the number of octets in this element following the Length field. 00 00 15 9FH. This field indicates the type of application to which the extension relates. The supported values are listed in Table 4.2.14-1. This one octet field indicates the Application sub-type within the Application Type. The supported values are listed in Table 4.2.14-1. Table 4.2.14-1 Application Sub Type
Application Type Name Access Network Identifiers (ANID) PDSN Identifier Value 04H Application Sub Type Name ANID Value 01H A11-Registration Request 3.1 Used in Message Reference
All other values are reserved 05H Anchor P-P Address 01H A11-Registration Request A11-Registration Reply A11-Session Update 3.1 3.2 3.5
D-43
3GPP2 A.S0008-C v2.0

Application Type Name Indicators Value 06H Application Sub Type Name All Dormant Indicator Value 01H A11-Registration Request 3.1 Used in Message Reference
All other values are reserved PDSN Code 07H PDSN CODE 01H A11-Registration Update 3.3
All other values are reserved Session Parameter 08H RN-PDIT Always-On QoS Mode 01H 02H 03H A11-Registration Reply A11-Session Update A11-Registration Reply A11-Session Update A11-Registration Request 3.2 3.5 3.2 3.5 3.1
All other values are reserved Service Option 09H Service Option Value 01H A11-Registration Request 3.1
All other values are reserved PDSN Enabled Features 0AH Flow Control Enabled Packet Boundary Enabled GRE Segmentation Enabled PCF Enabled Features 0BH Short Data Indication Supported GRE Segmentation Enabled Additional Session Information 0CH Additional Session Information 01H 02H 03H A11-Registration Reply A11-Registration Reply A11-Registration Reply 3.2 3.2 3.2
All other values are reserved 01H 02H A11-Registration Request A11-Registration Request 3.1 3.1
All other values are reserved 01H A11-Registration Request A11-Registration Reply A11-Registration Request A11-Registration Request A11-Registration Reply A11-Session Update A11-Session Update A11-Session Update 3.1 3.2 3.1 3.1 3.2 3.5 3.5 3.5
All other values are reserved QoS Information 0DH Forward QoS Information Reverse QoS Information Subscriber QoS Profile Forward QoS Update Information Reverse QoS Update Information Header Compression 0EH ROHC Configuration Parameters 01H 02H 03H FEH FFH
All other values are reserved 01H A11-Registration Reply 3.2
D-44
3GPP2 A.S0008-C v2.0

Application Type Name Information Value 0FH Application Sub Type Name Cause Code Value 01H A11-Registration Request 3.1 Used in Message Reference
All other values are reserved HRPD Indicators 10H Emergency Services 01H A11-Registration Request 3.1
All other values are reserved All other values are reserved
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
Application Data:
For Application Type 04H (Access Network Identifiers), this field contains the PANID of the source PCF in the PANID field (octets 11-15) and the ANID of the target PCF in the CANID field (octets 16-20). The PANID and CANID fields are formatted as specified for the Access Network Identifiers element (refer to [16]) from octet 3-7. If PANID information is not available, it shall be coded as all zeros. The CANID field shall be populated with the PCFs own ANID. For Application Type 05H (PDSN Identifier), this field contains an IPv4 address in octets 11-14. This is the Anchor P-P Address. The Anchor P-P Address is the P-P interface address (refer to [8]) of the anchor PDSN. For Application Type 06H (Indicators), this field contains the All Dormant Indicator in octets 11-12. A value of 00 00H indicates that all MS packet data service instances are dormant. All other values are reserved. For Application Type 07H (PDSN CODE), the field contains a PDSN Code indicating the reason the packet data connection is being released by the PDSN. The PDSN Code values and their meanings are listed in Table 4.2.14-2. Table 4.2.14-2 PDSN Code Values
Hex Value C1H C2H C3H C4H C5H C6H C7H C8H CAH
20 21 22 23 24 25 26 27 28 29
Decimal Value 193 194 195 196 197 198 199 200 202
PDSN Code Connection Release - reason unspecified Connection Release - PPP time-out Connection Release - registration time-out Connection Release - PDSN error Connection Release - inter-PCF handoff Connection Release - inter-PDSN handoff Connection Release - PDSN OAM&P intervention Connection Release - accounting error Connection Release - user (NAI) failed authentication All other values reserved
For Application Type 08H (Session Parameter) and Application SubType 01H, the Application Data field contains the Radio Network Packet Data Inactivity Timer (RN-PDIT) value in seconds. This field is one octet in length and has range 01HFFH, corresponding to timer values 1 255 seconds. For Application Sub Type 02H (Always-on indicator), the Application Data is zero bytes in length. For Application Type 08H (Session Parameter) and Application SubType 03H (QoS Mode), the Application data field is one octet in length and indicates whether IP flow based QoS is available for the current personality of the AT. The application data field is coded as follows: D-45
3GPP2 A.S0008-C v2.0

1
0 (MSB)
2 3
4 QoS Mode
7 (LSB)
Octet 1
QoS Mode: Table 4.2.14-3 QoS Mode Values

QoS Mode 00H 01H Description The AT and the AN apply air interface protocol that IP flow based QoS is unavailable. The AT and the AN apply air interface protocol that IP flow based QoS is available.
4 5 6 7 8
For Application Type 09H (Service Option), this field contains the Service Option value for the service instance associated with the A10 connection for 1x. It contains the Service Option value for the main service connection for HRPD. For Application Type 09H, the Application Data field is coded as follows:
0 (MSB) 1 2 3 4 Service Option (LSB) 5 6 7 Octet 1 2
10 11
Service Option: Table 4.2.14-43 1x Service Option Values

Service Option Value (hex) 0021H 003CH 003DH Description 3G High Speed Packet Data Link Layer Assisted Header Removal Link Layer Assisted RObust Header Compression
12
Table 4.2.14-5 HRPD Service Option Values for Main Service Instance
Service Option Value (hex) 003BH 0047H Description HRPD PPP Main Service Instance HRPD AltPPP operation
13 14 15 16 17 18 19 20 21 22
For Application Type 0AH (PDSN Enabled Features) and Application Sub-Type 01H (Flow Control Enabled), the Application Data field is zero bytes in length. This Application Sub-Type is included if the PDSN enables flow control for the corresponding A10 connection. For Application Type 0AH (PDSN Enabled Features) and Application Sub-Type 02H (Packet Boundary Enabled), the Application Data field is zero bytes in length. This Application Sub-Type is included if the PDSN guarantees packet boundaries either by encapsulating one packet in one GRE frame or by supplying GRE segmentation indication in the GRE frame (if supported by the RAN) for the corresponding A10 connection.
D-46
3GPP2 A.S0008-C v2.0

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
For Application Type 0AH (PDSN Enabled Features) and Application Sub-Type 03H (GRE Segmentation Enabled), the Application Data field is zero bytes in length. This Application Sub-Type shall be included if the PDSN is capable of receiving the GRE segmentation attribute in the GRE header for the corresponding A10 connection, for packets fragmented over one or more GRE frames. For Application Type 0BH (PCF Enabled Features) and Application Sub-Type 01H (Short Data Indication Supported), the Application Data field is zero bytes in length. This Application Sub-Type is included by the PCF in the A11-Registration Request message to request Short Data Indications via the GRE header. For Application Type 0BH (PCF Enabled Features) and Application Sub-Type 02H (GRE Segmentation Enabled), the Application Data field is zero bytes in length. This Application Sub-Type shall be included if the PCF is capable of receiving the GRE segmentation attribute in the GRE header for the corresponding A10 connection, for packets fragmented over one or more GRE frames. For Application Type 0CH (Additional Session Information) and Application Sub-Type 01H (Additional Session Information), the Application Data field is coded as follows:
0 1 2 3 4 5 6 7 Octet 1 2 3 (LSB) (MSB) (MSB) Protocol Type (LSB) Key 4 5 6 7 8 9 (LSB) (MSB) Source IP Address 10 11 12 13 (LSB) Forward ROHC Info{0 (if sent by PDSN), 1 (if sent by PCF): Forward ROHC Info Length (MSB) (MSB) Forward LargeCIDs Forward MaxCID (LSB) Forward MRRU (LSB) Reserved Forward ProfileCount n n+1 n+2 n+3 n+4 n+5 n+6 14 GRE Key Information Entry { 1-30: Entry Length SR_ID (MSB) Service Option
18 19
D-47
3GPP2 A.S0008-C v2.0

0 (MSB) }Forward Profile } Forward ROHC Info Reverse ROHC Info{0 (if sent by PDSN), 1 (if sent by PCF): Reverse ROHC Info Length (MSB) (MSB) Reverse LargeCIDs Reverse Profile { Reverse ProfileCount: (MSB) } Reverse Profile } Reverse ROHC Info } GRE Key Information Entry
1 2 3 4 5 6 7
4 Forward Profile
Octet p
Forward Profile {Forward ProfileCount: (LSB) p+1
n n+1 (LSB) n+2 n+3 (LSB) n+4 n+5 n+6 p (LSB) p+1
Reverse MaxCID Reverse MRRU Reserved Reverse ProfileCount Reverse Profile
Entry Length: SR_ID: Service Option:
This field contains the number of octets in this entry following the Entry Length field as a binary number. This field contains the identifier of the service connection associated with this A10 connection. This field contains the service option for the A10 connection associated with the value in the SR_ID field.
Table 4.2.14-6 HRPD - Additional Session Info Service Option Values

Service Option Value (hex) 0040H 0043H Description HRPD Accounting Records Identifier HRPD Packet Data IP Service where Higher Layer Protocol is IP or ROHC
8 9 10 11 12 13 14 15 16 17 18
Protocol Type:
This field is used to indicate the protocol type to be tunneled across the A10 interface, and contains the same value that is used in the Protocol Type field in the GRE header on the associated A10 connection when the packet doesnt include GRE attributes. This field is set to 0x88 81H (Unstructured Byte Stream). This is a four octet field. This field is used to indicate the A10 connection identification, and contains the same value that is used in the Key field in the GRE header on the associated A10 connection. This field identifies the IPv4 address of the PCF that terminates the A10 connection identified in this entry. Note that this address may be different from the source IP address of other A10 connections (including D-48
Key:
Source IP Address:
3GPP2 A.S0008-C v2.0

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
the main A10 connection) and different from the source IP address of the message containing this IE. The remaining fields in this application type only apply in the PCF to PDSN direction and are omitted when this NVSE is sent from the PDSN to the PCF. Forward ROHC Info Length: This field is used to indicate whether to create a forward ROHC channel on the A10 connection being created. If the Service Option for this entry is 43H and this A10 connection has a forward ROHC channel (compressor at PDSN, decompressor at AT), then this field indicates the number of octets following this field that carry ROHC configuration parameters (Forward MaxCID, Forward MRRU, Forward LargeCIDs, Forward ProfileCount, and Forward Profile fields). Otherwise it is set to 0. This field contains the MAX_CID parameter for this ROHC channel as defined in [28]. This field contains the MRRU (Maximum reconstructed reception unit) parameter for this ROHC channel as defined in [28]. This field contains the LARGE_CIDS parameter for this ROHC channel as defined in [28]. This field contains the number of ROHC Profiles supported by the decompressor, which corresponds to the number of Profiles contained in this IE, as a binary number. This field indicates a ROHC profile supported by the decompressor IANA ROHC profile identifier definitions can be found at [27]. This field is used to indicate whether to create a reverse ROHC channel on the A10 connection being created. If the Service Option for this entry is 43H and this A10 connection has a reverse ROHC channel (compressor at AT, decompressor at PDSN), then this field indicates the number of octets following this field that carry ROHC configuration parameters (Reverse MaxCID, Reverse MRRU, Reverse LargeCIDs, Reverse ProfileCount, and Reverse Profile fields). Otherwise it is set to 0. This field contains the MAX_CID parameter for this ROHC channel as defined in [28]. This field contains the MRRU parameter for this ROHC channel as defined in [28]. This field contains the LARGE_CIDS parameter for this ROHC channel as defined in [28]. This field contains the number of ROHC Profiles supported by the decompressor, which corresponds to the number of Profiles contained in this IE, as a binary number. This field indicates a ROHC profile supported by the decompressor IANA ROHC profile identifier definitions can be found at [27].
Forward MaxCID: Forward MRRU: Forward LargeCIDs: Forward ProfileCount:
Forward Profile: Reverse ROHC Info Length:
Reverse MaxCID: Reverse MRRU: Reverse LargeCIDs: Reverse ProfileCount:
Reverse Profile:
43 44 45
For Application Type 0DH (QoS Information) and Application Sub-Type 01H (Forward QoS Information), the Application Data field specifies all of the forward IP flow(s) that are associated with a given service connection. It is coded as follows.
0 1 2 3 SR_ID 4 5 6 7 Octet 11
D-49
3GPP2 A.S0008-C v2.0

0 1 2 3 4 Reserved 5 6 7 Octet 12
Use IP DSCP Flow Included Discrimination Reserved Forward Flow Entry {Forward Flow Count : Entry Length
Forward Flow Count
13 n n+1 Flow State n+2 n+3 n+4
Forward Flow ID Reserved DSCP Forward Requested QoS Length (MSB) Forward Requested QoS
(LSB) Forward Granted QoS Length (MSB) Forward Granted QoS
p p+1 p+2
(LSB) }Forward Flow Entry

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
SR_ID: Use IP Flow Discrimination:
This field identifies the service connection. This field indicates if the PDSN shall include GRE extension for IP flow discrimination. If this field is set to '0', the PDSN shall not include the GRE extension for IP flow discrimination in the bearer packets for the A10 connection identified in the SR_ID field of this Forward Flow Entry. Otherwise (set to '1') it indicates that the GRE extension for IP flow discrimination shall be included. This field indicates whether DSCP values are included in this IE. If option 1c in section 2.6.2 of the transport document is used, then the value shall be set to 1. Otherwise, the value shall be set to 0 and all DSCP fields in this IE shall be ignored. This field indicates the number of Flow ID Entry contained in this Forward QoS Information Entry. This field contains the number of octets in this entry following the Entry Length field as a binary number. This field contains the flow ID of a given forward IP flow. Refer to [8] for detailed information. If DSCP Included = 1, then this field contains the DSCP value of the flow identified in the corresponding Forward Flow ID field. Otherwise, this field shall be set to 00 0000 and shall be ignored.
DSCP Included:
Forward Flow Count: Entry Length: Forward Flow ID: DSCP:
D-50
3GPP2 A.S0008-C v2.0

1 2 3 4 5 6 7 8 9 10 11 12
Flow State:
This field indicates the IP flow state of the flow identified in the corresponding Flow ID field. This field is set to '0' if it is deactivated. This field is set to '1' if it is activated. This field contains the number of octets in the Forward Requested QoS field as a binary number. For HRPD systems, this field contains the requested QoS Sub BLOB for this flow received from the AT. The format is as specified in [8]. This field contains the number of octets in the Forward Granted QoS field as a binary number. For HRPD systems, this field contains the granted QoS Sub BLOB for this flow. The format is as specified in [8].
Forward Requested QoS Length: Forward Requested QoS:
Forward Granted QoS Length: Forward Granted QoS:
13 14 15
For Application Type 0DH (QoS Information) and Application Sub-Type 02H (Reverse QoS Information), the Application Data field specifies all of the reverse IP flow(s) that are associated with a given service connection. It is coded as follows:
0 1 Reserved Reverse Flow Entry { Reverse Flow Count : Entry Length Reverse Flow ID Reserved Reverse Requested QoS Length (MSB) Reverse Requested QoS Flow State n n+1 n+2 n+3 n+4 2 3 SR_ID Reverse Flow Count 4 5 6 7 Octet 11 12
(LSB) Reverse Granted QoS Length (MSB) Reverse Granted QoS
p p+1 p+2
(LSB) }Reverse Flow Entry

16 17 18 19 20 21 22 23 24 25 26
SR_ID: Reverse Flow Count: Entry Length: Reverse Flow ID: Flow State: Reverse Requested QoS Length:
This field identifies the service connection. This field indicates the number of Flow ID Entry contained in this Reverse QoS Information Entry. This field contains the number of octets in this entry following the Entry Length field as a binary number. This field contains the flow ID of a given reverse IP flow. Refer to [8] for detailed information. This field indicates the IP flow state. This field is set to '0' if it is deactivated. This field is set to '1' if it is activated. This field contains the number of octets in the Reverse Requested QoS field as a binary number. D-51
3GPP2 A.S0008-C v2.0

1 2 3 4 5 6 7
Reverse Requested QoS:
For HRPD systems, this field contains the requested QoS Sub BLOB for this flow received from the AT. The format is as specified in [8]. This field contains the number of octets in the Reverse Granted QoS field as a binary number. For HRPD systems, this field contains the granted QoS Sub BLOB for this flow. The format is as specified in [8].
Reverse Granted QoS Length: Reverse Granted QoS:
8 9
For Application Type 0DH (QoS Information) and Application Sub-Type 03H (Subscriber QoS Profile), the Application Data field is coded as follows:
0 (MSB) 1 2 3 4 5 6 7 Octet 1 2 3 Subscriber QoS Profile
(LSB)
10 11 12 13 14 15
Subscriber QoS Profile:
This field contains the Subscriber QoS Profile information sent from the PDSN to the RAN. This field is coded as a list of VSAs specified in [8] and each VSA includes Type, Length, VendorID, Vendor-Type, Vendor Length. Refer to [8] for detailed information.
16 17
For Application Type 0DH (QoS Information) and Application Sub-Type FEH (Forward QoS Update Information) , the Application Data field is coded as follows:
0 1 2 3 4 5 6 7 Octet 1 p+1 p+2 p+3 Forward Flow Count Forward Flow Entry { Forward Flow Count : Forward Flow ID Forward Updated QoS Sub-BLOB Length (MSB) Forward Updated QoS Sub-BLOB

18 19 20 21 22 23 24 25 26 27
Forward Flow Count: Forward Flow ID: Forward Updated QoS Sub-BLOB Length: Forward Updated QoS Sub-BLOB:
This field indicates the number of Flow ID Entry contained in this Forward QoS Information Entry. This field contains the flow ID of a given forward IP flow. Refer to [8] for detailed information. This field contains the number of octets in the Forward Updated QoS Sub-BLOB field as a binary number. This field contains the Updated QoS Sub-BLOB for this flow. Refer to [8] for detailed information. D-52
3GPP2 A.S0008-C v2.0

1 2
For Application Type 0DH (QoS Information) and Application Sub-Type FFH (Reverse QoS Update Information) , the Application Data field is coded as follows:
0 1 2 3 4 5 6 7 Octet 1 p+1 p+2 p+3 Reverse Flow Count Reverse Flow Entry { Reverse Flow Count : Reverse Flow ID Reverse Updated QoS Sub-BLOB Length (MSB) Reverse Updated QoS Sub-BLOB

3 4 5 6 7 8 9 10 11 12
Reverse Flow Count: Reverse Flow ID: Reverse Updated QoS Sub-BLOB Length: Reverse Updated QoS Sub-BLOB:
This field indicates the number of Flow ID Entry contained in this Reverse QoS Information Entry. This field contains the flow ID of a given reverse IP flow. Refer to [8] for detailed information. This field contains the number of octets in the Reverse Updated QoS Sub-BLOB field as a binary number. This field contains the Updated QoS Sub-BLOB for this flow. Refer to [8] for detailed information.
13 14 15
For Application Type 0EH (Header Compression) and Application Sub-Type 01H (ROHC Configuration Parameters), the Application Data field carries the ROHC channel parameter values associated with the PDSN if using ROHC on SO67 at the PDSN. The Application Data field is coded as follows:
0 (MSB) (MSB) LargeCIDs Profile {ProfileCount: (MSB) } Profile Profile (LSB) n n+1 1 2 3 4 MaxCID (LSB) MRRU (LSB) Reserved ProfileCount 5 6 7 Octet 1 2 3 4 5 6
16 17 18 19 20 21 22
MaxCID: MRRU: LargeCIDs:
This field contains MAX_CID supported by the PDSN as defined in [28]. This field contains the MRRU supported by the PDSN as defined in [28]. This field contains the LARGE_CIDS supported by the PDSN as defined in [28]. D-53
3GPP2 A.S0008-C v2.0

1 2 3 4 5 6 7
ProfileCount:
This field contains the number of ROHC Profiles supported by the PDSN, which corresponds to the number of Profiles contained in this IE, as a binary number. This field indicates a ROHC profile supported by the PDSN IANA ROHC profile identifier definitions can be found at [27].
Profile:
For Application Type 0FH (Information) and Application Sub-Type 01H (Cause Code), the Application Data field carries the received information from the PCF. The Application Data field is coded as follows:
7 6 5 4 3 2 1 0 Octet 1
Cause Value
8 9 10
Cause Value:
This field is a single octet field as indicated in the table below. Table 4.2.14-7 Cause Values
Values 01H 02H Meaning Packet data session release Air link lost
11 12 13 14
For Application Type 10H (HRPD Indicators), and Application Sub-Type 01H (Emergency Services) the Application Data field carries the indication of whether emergency services are used. The Application Data field is coded as follows:
0 Emergency Services 1 2 3 4 Reserved 5 6 7 Octet 1
15 16 17 18 19 20
Emergency Services:
This field indicates whether emergency services are used. If emergency services are used, the field is set to 1. Otherwise, the field is set to 0.
D-54
3GPP2 A.S0008-C v2.0
1 2 3 4 5
Annex E
A12 RADIUS Attributes (Normative)
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-ID of 5535 (159FH) is used to indicate 3GPP2. Note that all integers are in network byte order. 1 Type Length Vendor-Value 2 Vendor-ID Vendor-Type Vendor-Length 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 Vendor-ID (cont) Figure Annex E-1
3GPP2 RADIUS Attribute Format
7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
HRPD Access Authentication: Indicates whether the Access Request is in the context of access authentication. This optionally appears in an Access-Request message, on the A12 interface. Type = 26 (1AH) Length = 12 (0CH) Vendor-ID = 5535 (0000 159FH) Vendor-Type = 60 (3CH) Vendor-Length = 6 (06H) Vendor-Value = 1 (0000 0001H) - HRPD Access Authentication AT Hardware Identifier: Indicates the AT hardware identifier type and the AT hardware identifier value in the context of AT authentication. This information provides the hardware identity of the AT, which is obtained via air-interface signaling. The hardware identity type is based on the encoding specified in the IOS for Mobile Identity. If the AN requests the AT hardware identity, then this VSA is present in an Access-Request message, over the A12 interface. 1 Type Vendor-ID (cont) Sub-Type (=1) Vendor-value Length Length Vendor-ID Vendor-Type Vendor-Length Vendor-Value (=AT hardware identifier type) Length 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Sub-Type (=2) .. Vendor-Value (=AT hardware identifier value) . Vendor-Value (=AT hardware identifier value) Figure Annex E-2 Type: 26 (1AH) Length = Variable, greater than 8 E-1
22
AT Hardware Identifier
23 24
3GPP2 A.S0008-C v2.0

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
Vendor ID: 5535 (0000 159FH) Vendor-Type = 61 (3DH) Vendor-Length = Variable, greater than 2 Sub-Type = 1 (01H) Length = 6 (06H) Vendor-Value = AT hardware identifier type (AT Type of Identity Coding; e.g., ESN, MEID) as specified in [16]. Expressed as a 32-bit unsigned integer with MSB first (e.g., 00 00 00 01H for MEID). Sub-Type = 2 (02H) Length = N+2, where N is the AT hardware identifier length in octets as specified in [10]. Expressed as a binary value (e.g., 09H for MEID). Vendor-Value = AT hardware identifier value as specified in [10]
E-2

A.S0008-C v2.0 090106

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

A.S0008-C v2.0 090106

Uploaded by

Copyright:

Available Formats

3GPP2 A.S0008-C v2.

0 Date: January 2009

COPYRIGHT 2009, 3GPP2

3GPP2 A.S0008-C v2.0

3GPP2 A.S0008-C v2.0

AN-AAA Support .........................................................................................................................2-4

3GPP2 A.S0008-C v2.0

2.5 2.5.1 2.5.2

3GPP2 A.S0008-C v2.0

3GPP2 A.S0008-C v2.0

3GPP2 A.S0008-C v2.0

3GPP2 A.S0008-C v2.0

A18 Message Procedures............................................................................................................2-31

A19 Message Procedures............................................................................................................2-33

3GPP2 A.S0008-C v2.0

3GPP2 A.S0008-C v2.0

3GPP2 A.S0008-C v2.0

3.9.2.4 3.9.3 3.9.4 3.9.5 3.9.6 3.9.7 3.10

3.10.1 AT Originated DoS .....................................................................................................................3-31

3.10.2 AT Terminated DoS....................................................................................................................3-33

3.12.6 Data Flow during Make-before-break Session Transfer.............................................................3-64

3GPP2 A.S0008-C v2.0

Hard Handoff Negotiation Procedures with Example of Air-interface Signaling ......................3-66

3GPP2 A.S0008-C v2.0

4.5.2.1 4.5.2.2 4.5.2.3 4.5.2.4 4.5.3

3GPP2 A.S0008-C v2.0

4.6.2 4.6.3 4.7 4.7.1 4.7.2 5 5.1 5.1.1

3GPP2 A.S0008-C v2.0

A17 Message Definitions............................................................................................................5-46

A18 Message Definitions............................................................................................................5-76

A19 Message Definitions............................................................................................................5-81

3GPP2 A.S0008-C v2.0

A21 Message Definitions............................................................................................................5-95

3GPP2 A.S0008-C v2.0

A16 Information Element Definitions ......................................................................................5-131

3GPP2 A.S0008-C v2.0

A17, A18, and A19 Information Element Definitions..............................................................5-156

A21 Information Element Definitions ......................................................................................5-190

3GPP2 A.S0008-C v2.0

3GPP2 A.S0008-C v2.0

3GPP2 A.S0008-C v2.0

3GPP2 A.S0008-C v2.0

Figure 3.10.1.2-1 Figure 3.10.2.1-1 Figure 3.10.2.2-1

3GPP2 A.S0008-C v2.0

Figure 3.14.7.1-1 Figure 3.14.7.2-1

3GPP2 A.S0008-C v2.0

3GPP2 A.S0008-C v2.0

3GPP2 A.S0008-C v2.0

3GPP2 A.S0008-C v2.0

(This page intentionally left blank)

3GPP2 A.S0008-C v2.0

3GPP2 A.S0008-C v2.0

3GPP2 A.S0008-C v2.0

3GPP2 A.S0008-C v2.0

[25] [26] [27] [28] [29] [30] [31] [32] [33]

1.2.2 [34] [35] [36]

3GPP2 A.S0008-C v2.0 TCA TCH UATI VoIP VPI VSA

Access Stream Access Network

AN-AAA AN-Based ROHC cdma2000 1x Circuit-Switched MSC

Connected State Session Transfer

3GPP2 A.S0008-C v2.0

Flow ID Flow Profile ID Forward ROHC Channel