3GPP2 A.S0022-0 v1.

0 Date: March 2009

1 2 3 4

Interoperability Specification (IOS) for Evolved High Rate Packet Data (eHRPD) Radio Access Network Interfaces and Interworking with Enhanced Universal Terrestrial Radio Access Network (E-UTRAN) 3GPP2 Publication Version

5 6 7

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.S0022-0 v1.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

Table of Contents
Foreword ..................................................................................................................................................... vii 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.4.1 1.4.2 1.5 1.6 1.7 1.8 1.9 1.10 1.11 1.12 Introduction...................................................................................................................................1-1 Overview.......................................................................................................................................1-1 Purpose..........................................................................................................................................1-1 Scope.............................................................................................................................................1-1 Document Convention ..................................................................................................................1-1 References.....................................................................................................................................1-1 Normative References...................................................................................................................1-2 Informative References.................................................................................................................1-3 Terminology..................................................................................................................................1-3 Acronyms......................................................................................................................................1-3 Definitions ....................................................................................................................................1-5 HRPD IOS Architecture Reference Model...................................................................................1-9 eHRPD IOS Interfaces................................................................................................................1-10 eHRPD IOS Network Entities ....................................................................................................1-12 HRPD Micro-Mobility and Macro-Mobility Concepts ..............................................................1-14 Compatibility with IOS Standards ..............................................................................................1-14 Compatibility with 3GPP Standards ...........................................................................................1-14 Message Body, Coding, Ordering, and Interpretation of Elements ............................................1-15 Forward Compatibility Guidelines .............................................................................................1-15 Message Processing Guidelines ..................................................................................................1-15 Message Definition Guidelines...................................................................................................1-15 eHRPD IOS Assumptions...........................................................................................................1-15

1.12.1 IOS Assumptions ........................................................................................................................1-15 1.12.2 QoS Assumptions .......................................................................................................................1-16 1.13 State Definition ...........................................................................................................................1-17 1.13.1 Packet Data Session State ...........................................................................................................1-17 1.13.2 IP Flow State...............................................................................................................................1-17 1.14 Feature Descriptions ...................................................................................................................1-17 1.14.1.1 1.14.1.2 1.14.1.3 1.14.1.4 1.14.1.5 Generic Key Exchange (GKE) ............................................................................1-18 Idle Handoff of Legacy Mode from eHRPD to HRPD .......................................1-18 Idle Handoff of Legacy Mode from HRPD to eHRPD .......................................1-18 Idle Handoff with Personality Switch from Evolved Mode on eHRPD to Legacy Mode on HRPD ......................................................................................1-18 Active Handoff of Legacy Mode from eHRPD to HRPD...................................1-19 i 1.14.1 Explicitly Supported Features.....................................................................................................1-17

3GPP2 A.S0022-0 v1.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.14.1.6 1.14.1.7 1.14.1.8 1.14.1.9 1.14.1.10 1.14.1.11 1.14.2.1

Active Handoff of Legacy Mode from HRPD to eHRPD...................................1-19 Active Handoff from E-UTRAN to eHRPD .......................................................1-19 Active Handoff from eHRPD to E-UTRAN .......................................................1-19 Idle Handoff from E-UTRAN to eHRPD............................................................1-19 Idle Handoff from eHRPD to E-UTRAN............................................................1-19 Standalone eHRPD..............................................................................................1-19 Active and Idle Handoff Between E-UTRAN and eHRPD for Dual Transmitter eATs.................................................................................................1-19 HSGW Selection Algorithm................................................................................1-19

1.14.2 Transparently Supported Features ..............................................................................................1-19

1.14.3 HSGW Selection.........................................................................................................................1-19 1.14.3.1 2 2.1 2.2 2.3 2.4 2.5 2.5.1 HRPD IOS Interfaces....................................................................................................................2-1 A1/A1p (IWS - MSC) Interface....................................................................................................2-1 A8-A9 (AN - PCF) Interface ........................................................................................................2-1 A10-A11 (PCF - PDSN/HSGW) Interface ...................................................................................2-1 A12 (AN/PCF - AN-AAA) Interface............................................................................................2-1 A13 (AN/PCF AN/PCF) Interface.............................................................................................2-1 A13-Session Information Request ................................................................................................2-1 2.5.1.1 2.5.1.2 2.5.2 2.5.2.1 2.5.2.2 2.6 2.7 2.8 2.8.1 Successful Operation .............................................................................................2-1 Failure Operation...................................................................................................2-2 Successful Operation .............................................................................................2-2 Failure Operation...................................................................................................2-3

A13-Session Information Response..............................................................................................2-2

A14 (AN - PCF) Interface.............................................................................................................2-3 A15 (AN - AN) Interface ..............................................................................................................2-3 A16 (AN - AN) Interface ..............................................................................................................2-3 A16 Message Definitions..............................................................................................................2-3 2.8.1.1 2.8.1.1.1 2.8.1.1.2 2.8.1.2 2.8.1.2.1 2.8.1.2.2 A16-Session Transfer Request ..............................................................................2-4 Successful Operation .............................................................................................2-4 Failure Operation...................................................................................................2-4 A16-Session Transfer Response............................................................................2-4 Successful Operation .............................................................................................2-4 Failure Operation...................................................................................................2-4

2.9 2.10 2.11 2.12

A17, A18, and A19 Interface........................................................................................................2-5 A20 (AN - PCF) Interface.............................................................................................................2-5 A21 (AN IWS) Interface............................................................................................................2-5 A24 AN/PCF-AN/PCF (IP Tunneling) Interface..........................................................................2-5 ii

3GPP2 A.S0022-0 v1.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.13 3 3.1 3.2 3.2.1

S101 (MME eAN) Interface ......................................................................................................2-5 E-UTRAN-eHRPD IOS Call Flows .............................................................................................3-1 Supported Call Flows for eHRPD Operation................................................................................3-1 E-UTRAN to eHRPD Handoff Call Flows...................................................................................3-2 E-UTRAN to eHRPD Pre-Registration Call Flows ......................................................................3-2 3.2.1.1 3.2.1.1.1 3.2.1.1.2 E-UTRAN to eHRPD Active Handoff Pre-Registration ....................................3-2 E-UTRAN to eHRPD Active Handoff Pre-Registration SC/MM at eAN Case...........................................................................................................3-2 E-UTRAN to eHRPD Active Handoff Pre-Registration SC/MM at ePCF Case .........................................................................................................3-4 E-UTRAN to eHRPD Active Handoff Preparation and Execution A8 Connected..............................................................................................................3-6 E-UTRAN to eHRPD Active Handoff Preparation and Execution A8 Disconnected .........................................................................................................3-8 Idle Handoff from E-UTRAN to eHRPD (Same eAN/ePCF).............................3-11 Idle Handoff from E-UTRAN to eHRPD (Different eAN/ePCF) .......................3-12 Idle Handoff from E-UTRAN to eHRPD with Prior Session Removal ..............3-14

3.2.2

E-UTRAN to eHRPD Active Handoff .........................................................................................3-6 3.2.2.1 3.2.2.2

3.2.3

E-UTRAN to eHRPD Idle Handoff ............................................................................................3-11 3.2.3.1 3.2.3.2 3.2.3.3

3.3 3.3.1 4 4.1 4.1.1

eHRPD to E-UTRAN Handoff Call Flows.................................................................................3-15 eHRPD to E-UTRAN Idle Handoff Call Flow ...........................................................................3-16 Messages, Information Elements and Timer Definitions..............................................................4-1 Message Definitions......................................................................................................................4-1 A13 Message Definitions..............................................................................................................4-1 4.1.1.1 4.1.1.2 A13-Session Information Request.........................................................................4-1 A13-Session Information Response ......................................................................4-3

4.1.2 4.1.3 4.1.4

A14 Message Definitions..............................................................................................................4-7 A15 Message Definitions..............................................................................................................4-8 A16 Message Definitions..............................................................................................................4-8 4.1.4.1 4.1.4.2 A16-Session Transfer Request ..............................................................................4-8 A16-Session Transfer Response..........................................................................4-15

4.1.5 4.1.6 4.1.7 4.1.8 4.2 4.2.1

A17 Message Definitions............................................................................................................4-17 A18 Message Definitions............................................................................................................4-17 A19 Message Definitions............................................................................................................4-17 A21 Message Definitions............................................................................................................4-17 Information Element Definitions ................................................................................................4-17 A13 Information Element Definitions ........................................................................................4-17 4.2.1.1 A13 Information Element Identifiers ..................................................................4-17 iii

3GPP2 A.S0022-0 v1.0

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

4.2.1.2 4.2.1.3 4.2.1.4 4.2.2 4.2.3 4.2.4

A13 Cross Reference of IEs with Messages........................................................4-18 Source HSGW H1 IPv4 Address.........................................................................4-20 A13 eHRPD Indicators........................................................................................4-21

A14 Information Element Definitions ........................................................................................4-21 A15 Information Element Definitions ........................................................................................4-21 A16 Information Element Definitions ........................................................................................4-21 4.2.4.1 4.2.4.2 4.2.4.3 A16 Information Element Identifiers ..................................................................4-21 A16 Cross Reference of IEs with Messages........................................................4-23 Source HSGW H1 IPv4 Address.........................................................................4-25

4.2.5 4.2.6 4.3

A17, A18, and A19 Information Element Definitions................................................................4-25 A21 Information Element Definitions ........................................................................................4-26 Timer Definitions........................................................................................................................4-26 A8-A9 (AN - PCF) Interface Change Text (Normative)...................................... A-1 A10-A11 (AN/ePCF - PDSN) Interface Change Text (Normative)..................... B-1

Annex A Annex B

iv

3GPP2 A.S0022-0 v1.0

1 2 3 4 5 6 7 8 9 10 11 12 13 14

Table of Figures
Figure 1.4-1 Figure 1.4-2 E-UTRAN - eHRPD IOS Architecture Reference Model (SC/MM in the eAN) ............1-9 E-UTRAN - eHRPD IOS Architecture Reference Model (SC/MM in the ePCF).........1-10 E-UTRAN to eHRPD Pre-Registration SC/MM at eAN Case ........................3-3 E-UTRAN to eHRPD Pre-Registration SC/MM at ePCF Case.......................3-5

Figure 1.13.1-1 eHRPD Packet Data Session State Transitions..............................................................1-17 Figure 3.2.1.1.1-1 Figure 3.2.1.1.2-1

Figure 3.2.2.1-1 E-UTRAN to eHRPD Handoff A8 Connected .............................................................3-7 Figure 3.2.2.2-1 E-UTRAN to eHRPD Handoff A8 Disconnected.........................................................3-9 Figure 3.2.3.1-1 Idle Handoff from E-UTRAN to eHRPD (Same eAN/ePCF) .......................................3-11 Figure 3.2.3.2-1 Idle Handoff from E-UTRAN to eHRPD (Different eAN/ePCF) .................................3-12 Figure 3.2.3.3-1 Idle Handoff from E-UTRAN to eHRPD with Prior Session Removal.........................3-14 Figure 3.3.1-1 Non-Optimized eHRPD to E-UTRAN Idle Handoff.....................................................3-16

3GPP2 A.S0022-0 v1.0

1 2 3 4 5 6 7

Table of Tables
Table 3.1-1 Supported Call Flows for eHRPD....................................................................................3-1

Table 4.2.1.2-1 Cross Reference of IEs with Messages ..........................................................................4-18 Table 4.2.4.2-1 A16 Cross Reference of IEs with Messages ..................................................................4-23

vi

3GPP2 A.S0022-0 v1.0

1 2 3 4 5 6 7 8

Foreword
The foreword is informational and not part of this standard. The interface specifications defined in this document are based on A.S0008 [3] and A.S0009 [4]. This document describes the interface protocols and procedures to support the Evolved High Rate Packet Data (eHRPD) Interoperability Specification (IOS) features listed in section 1.1. Refer to section 1.6 for an explanation of this specifications reuse of High Rate Packet Data (HRPD) IOS transport requirements and interface definitions. Revision History Date March 2009 Publication A.S0022-0 v1.0 Description For features supported, refer to section 1.1.

vii

3GPP2 A.S0022-0 v1.0

1 2 3 4 5

(This page intentionally left blank)

viii

3GPP2 A.S0022-0 v1.0

1 2 3

Introduction

This document defines the access network aspects of eHRPD systems that interwork with Enhanced Universal Terrestrial Radio Access Network (E-UTRAN) and Evolved Packet Core (EPC) systems.

4 5 6 7 8

1.1

Overview

This document includes a description of the interface protocols and procedures to support the features and functions described in section 1.14. 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. In addition to the features and functions included in A.S0008 [3] and A.S0009 [4], this specification supports: Standalone eHRPD Active handoff from E-UTRAN to eHRPD Active handoff from eHRPD to E-UTRAN Idle handoff from E-UTRAN to eHRPD Idle handoff from eHRPD to E-UTRAN 1.1.1 Purpose

9 10 11 12 13 14 15

16 17 18

The purpose of this document is to provide a standard and call flows for the eHRPD IOS interfaces within the eHRPD Radio Access Network (RAN), and for interworking between E-UTRAN and eHRPD. 1.1.2 Scope

19

20 21 22 23 24

This document provides an interoperability specification for a RAN that supports eHRPD and handoff to and from E-UTRAN. The RAN architecture in this document logically locates the Session Control and Mobility Management (SC/MM) function in the Access Network (AN) for the architecture specified in A.S0008 [3] or in the Packet Control Function (PCF) for the architecture specified in A.S0009 [4]. This document contains message procedures and formats necessary to obtain this interoperability. 1.1.3 Document Convention

25 26 27 28 29 30 31 32 33 34

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 A.S0008 [3] and A.S0009 [4] an ellipsis () indicates that the base document is unchanged.

35 36 37 38 39

1.2

References

References are either normative or informative. A normative reference is used to include another document as a mandatory part of a 3rd Generation Partnership Project 2 (3GPP2) specification. Documents that provide additional non-essential information are included in the informative references section.

1-1

3GPP2 A.S0022-0 v1.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

1.2.1

Normative References

The following standards contain provisions which, through reference in this text, constitute provisions of this standard. At the time of publication, the editions indicated were valid. All standards are subject to revision, and parties to agreements based upon this document are encouraged to investigate the possibility of applying the most recent editions of the standards indicated. [1] [2] [3] 3GPP: TS 23.402, Architecture Enhancements for non-3GPP accesses (Release 8). 3GPP: TS 29.276, Optimized Handover Procedures and Protocols between E-UTRAN Access and cdma2000 HRPD Access Stage 3 (Release 8). 3GPP2: A.S0008-C v2.0, Interoperability Specification (IOS) for High Rate Packet Data (HRPD) Radio Access Network Interfaces with Session Control in the Access Network, January 2009. 3GPP2: A.S0009-C v2.0, Interoperability Specification (IOS) for High Rate Packet Data (HRPD) Radio Access Network Interfaces with Session Control in the Packet Control Function, January 2009. 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.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. 3GPP2: C.S0024-B v2.0, cdma2000 High Rate Packet Data Air Interface Specification, April 2007. 3GPP2: C.S0057-B v1.0, Band Class Specification for cdma2000 Spread Spectrum Systems, August 2006. 1-2

[4]

[5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19]

3GPP2 A.S0022-0 v1.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

[20] [21] [22] [23] [24] [25] [26] [27] [28] [29] [30] [31] [32] [33]

3GPP2: C.S0063-A v1.0, cdma2000 High Rate Packet Data Supplemental Services, April 2006. 3GPP2: C.S0067-0 v1.0, Generic Key Exchange Protocol for cdma2000 High Rate Packet Data Air Interface, November 2005. 3GPP2: C.S0075 v1.0, Interworking Specification for cdma2000 1x and High Rate Packet Data Systems, February 2006. 3GPP2: C.S0082-0 v1.0, Circuit Services Notification Application Specification for cdma2000 High Rate Packet Data, August 2006. 3GPP2: C.S0087-0 v1.0, E-UTRAN - HRPD and cdma2000 1x Connectivity and Interworking: Air Interface Aspects, January 2009. 3GPP2: X.S0011-D v2.0, Wireless IP Network Standard, November 2008. 3GPP2: X.S0057-0 v1.0, E-UTRAN - HRPD Connectivity and Interworking: Core Network Aspects, January 2009. IETF: RFC 1661, Point-to-Point Protocol, July 1994. IETF: RFC 1994, PPP Challenge Handshake Authentication Protocol (CHAP), August 1996. IETF: RFC 2865, Remote Authentication Dial In User Service (RADIUS), June 2000. IETF: RFC 2866, RADIUS Accounting, 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. Internet Assigned Numbers Authority: RObust Header Compression (ROHC) Profile Identifiers, http://www.iana.org/assignments/rohc-pro-ids.

25 26 27 28

1.2.2 [I-1]

Informative References IETF: RFC 3241, Robust Header Compression (ROHC) over PPP, April 2002.

29 30

1.3

Terminology

31

1.3.1 3GPP 3GPP2 AAA ADDS AN ANID APN

Acronyms 3rd Generation Partnership Project 3rd Generation Partnership Project 2 Authentication, Authorization and Accounting server Application Data Delivery Service Access Network Access Network Identifiers Access Point Name 1-3

3GPP2 A.S0022-0 v1.0

AT BLOB BS CANID CHAP CID CSNA CVSE DoS DRI eAN eAT eHRPD EPC ePCF EPS ESSIR E-UTRAN GKE GRE HRPD HSGW HSS IANA IE IMSI IOS IP IWS LCM LCP MAC MEI MEID MME MN ID MRRU MS MSC MSCe NAI NAS NID

Access Terminal BLock Of Bits Base Station Current Access Network Identifiers Challenge Handshake Authentication Protocol Context IDentifier Circuit Services Notification Application Critical Vendor/Organization Specific Extension Data Over Signaling Data Ready Indicator Evolved Access Network Evolved Access Terminal Evolved High Rate Packet Data Evolved Packet Core Evolved Packet Control Function Evolved Packet System Extended Session State Information Record Enhanced Universal Terrestrial Radio Access Network Generic Key Exchange Generic Routing Encapsulation High Rate Packet Data HRPD Serving Gateway Home Subscriber Server Internet Assigned Numbers Authority Information Element International Mobile Subscriber Identity Inter-Operability Specification Internet Protocol Interworking Solution Long Code Mask Link Control Protocol Medium Access Control Mobility Event Indicator Mobile Equipment Identity Mobility Management Entity Mobile Node Identification Maximum Reconstructed Reception Unit Mobile Station Mobile Switching Center Mobile Switching Center Emulation Network Access Identifier Non-access Stratum Network Identification 1-4

3GPP2 A.S0022-0 v1.0

NVSE P-GW PANID PCF PCRF PDN PDSI PDSN PMIP PMK PPP PZID QoS RADIUS RAN RFC RLP ROHC RT S-GW SAP SC/MM SDB SID SLP SSIR TCA TFT UATI VoIP VSA
1

Normal Vendor Specific Extension PDN GW (Packet Data Network Gateway) Previous Access Network Identifiers Packet Control Function Policy and Charging Rules Function Packet Data Network Packet Data Service Instance Packet Data Serving Node Proxy Mobile Internet Protocol Pairwise Master Key Point-to-Point Protocol Packet Zone Identification Quality of Service Remote Authentication Dial-In User Service Radio Access Network Request for Comment Radio Link Protocol RObust Header Compression Radio Transceiver Serving Gateway Signaling Adaptation Protocol Session Control / Mobility Management Short Data Burst System Identification Signaling Link Protocol Session State Information Record Traffic Channel Assignment Traffic Flow Template Unicast Access Terminal Identifier Voice over Internet Protocol Vendor Specific Attribute

2 3 4 5 6 7 8 9 10 11

1.3.2 1x

Definitions Refer to cdma2000 1x. A procedure in A.S0008 [3] in which the Access Terminal (AT) is authenticated by the AN-AAA (Authentication, Authorization and Accounting server). A stream to which a packet application bound to an access network is attached. Access stream is used for access authentication. RObust Header Compression (ROHC) where compression and decompression are performed in the AN. ROHC channels for AN-Based ROHC terminate in the AT and AN. 1-5

Access Authentication

Access Stream AN-Based ROHC

3GPP2 A.S0022-0 v1.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

cdma2000 1x

The version of cdma2000 defined by C.S0001~C.S0006 [12]~[17] and also supported by A.S0011~ A.S0017 [5]~[11]. 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.

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 or a virtual connection (refer to C.S0087 [24]). 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. For purposes of this document, an eHRPD system is a RAN -- Evolved Access Network (eAN) and Evolved Packet Control Function (ePCF) -- that supports evolved mode (C.S0087 [24]) operation in addition to legacy mode (C.S0087 [24] and C.S0063 [20]) operation. An eHRPD system may be standalone or may support interworking with E-UTRAN. Refer also to Evolved Access Network. EPC consists of the Packet Data Network (P-GW) and other entities as defined by 3GPP. The HRPD Serving Gateway (HSGW) connects the eHRPD RAN to the EPC. Evolved Packet System (EPS) consists of E-UTRAN and EPC. The E-UTRAN consists of a set of eNodeBs (refer to TS 23.402 [1]). For purposes of this document, the E-UTRAN is the network that supports Evolved Universal Terrestrial Radio Access. An identifier which, combined with a direction, uniquely identifies an Internet Protocol (IP) flow for an AT. An identifier of the service needs for an application flow. Refer to A.S0008 [3] and A.S0009 [4]. A unidirectional compressor/decompressor pair (refer to RFC 3095 [31]) that sends ROHC packets from Packet Data Serving Node (PDSN) or AN to AT. The compressor transforms original packets into ROHC packets. The Quality of Service (QoS) Sub BLOB (Block of Bits) containing the QoS granted for a given IP flow. Refer to X.S0057 [26] and C.S0087 [24]. 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. For purposes of this document, the term HRPD refers to legacy HRPD systems. It also refers to legacy mode HRPD operation (refer to C.S0024 [18] and C.S0063 [20]). Area that is serviced by one HRPD PCF. 1-6

eHRPD

EPC

EPS E-UTRAN

Flow ID Flow Profile ID Forward ROHC Channel

Granted QoS Sub BLOB Hard Handoff

HRPD

HRPD Packet Zone

3GPP2 A.S0022-0 v1.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

HRPD session

An HRPD session (in either legacy mode or evolved mode) 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 C.S0024 [18] and C.S0063 [20] for an HRPD session in legacy mode, and refer to C.S0087 [24] for an HRPD session in evolved mode. 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. If the AT is in Connected State, Long Code Mask (LCM)_ Unicast Access Terminal Identifier (UATI) is the UATI that the Reverse Traffic Channel Long Code Mask (refer to C.S0087 [24]) is built upon. This term is also used in this document to mean the last confirmed UATI with which the AT has accessed the AN, if the AT is in Idle State. Unidirectional data flow over the air interface. Refer to RLP (Radio Link Protocol) Flow. Refer to C.S0063 [20] or C.S0087 [24]. 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.

IP Flow

LCM_UATI

Link Flow

Make-before-break Session Transfer

Negotiated ROHC Parameter Values 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 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 A.S0011 [5] 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 X.S0057 [26] containing QoS attribute sets or QoS Profile IDs.

PDSN-Based ROHC QoS Sub BLOB

Requested QoS Sub BLOB The QoS Sub BLOB containing the QoS requested by an Mobile Station (MS)/AT for a given IP flow. Refer to X.S0057 [26] and C.S0087 [24]. Reservation Reservation Label Air interface resources needed to carry an IP flow. Refer to C.S0087 [24] or C.S0063 [20]. An identifier, which combined with a direction, uniquely identifies a reservation for an AT. Reservation labels are also used as Flow IDs. 1-7

3GPP2 A.S0022-0 v1.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

Reverse ROHC Channel

A unidirectional compressor/decompressor pair (refer to RFC 3095 [31]) 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 C.S0087 [24]. A protocol defined by IETF (refer to RFC 3095 [31], RFC 3241 [I-1]). Unless otherwise specified, ROHC in this document refers to ROHC on SO67. For example, negotiated ROHC parameter values do not apply to ROHC over Point-to-Point Protocol (PPP) (refer to RFC 3095 [31]). A unidirectional compressor/decompressor pair (refer to RFC 3095 [31]). 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 (Context Identifier), LARGE_CIDS, PROFILES, and Maximum Reconstructed Reception Unit (MRRU). The parameter FEEDBACK_FOR is not used in this document. Refer to RFC 3095 [31].

RLP Flow ROHC

ROHC Channel

ROHC Configuration Parameters

ROHC on SO67 Service Connection

The capability to associate ROHC channels with A8/A10 connections having service option 67. 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 1 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 C.S0087 [24]. The Radio Transceiver (RT) that contains the serving sector. Refer to C.S0087 [24]. 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

SR_ID

Identifier of a service connection. SR_ID 1 identifies the main service connection.

There are some situations where the SR_ID of the service connection may change; e.g., upon a failed inter-ePCF session transfer.

1-8

3GPP2 A.S0022-0 v1.0

1 2 3 4 5 6 7 8 9 10

Subnet

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 C.S0087 [24]. The set of QoS-related information sent from the PDSN that the RAN uses to authorize QoS requests for a given subscriber. Refer to X.S0057 [26]. A procedure in A.S0009 [4] in which the AT is authenticated by the ANAAA.

Subscriber QoS Profile Terminal Authentication

11 12 13 14 15 16 17 18

1.4

HRPD IOS Architecture Reference Model

The eHRPD IOS messaging and call flows are based on the Architecture Reference Model shown in Figure 1.4-1 (Session Control and Mobility Management in the evolved Access Network) and in Figure 1.4-2 (Session Control and Mobility Management in the evolved Packet Control Function). In the figures,, solid lines indicate signaling and bearer and dashed lines indicate only signaling. The eHRPD call flows include the E-UTRAN and other 3GPP access entities (S-GW, P-GW, HSS and PCRF). Refer to TS 23.402 [1] for the architecture model and descriptions of these network entities and associated interfaces.
IWS Function 1x BS
A1/A1p

A1/A1p

IWS Function

A21

A21

MME

MSC/MSCe

A1/A1p

IWS Function Source eAN SC/MM Function

A8 A9 A12

S101

A10

ePCF

A11

PDSN / HSGW

Air Interface

AT

A13 A16 A17

A18 A19

A24

AN AAA

SC/MM Function Target eAN

19 20

RT

Figure 1.4-1

E-UTRAN - eHRPD IOS Architecture Reference Model (SC/MM in the eAN)

21 22 23

Note: The Interworking Solution (IWS) Function in Figure 1.4-1 may be collocated at either the 1x Base Station (BS) or at the HRPD eAN, 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 eAN, and the A1/A1p 1-9

3GPP2 A.S0022-0 v1.0

1 2 3 4 5 6

interface is supported between the Mobile Switching Center (MSC) and the 1x BS. When the IWS function is part of the HRPD eAN, the A1/A1p interface between the MSC and the HRPD eAN exists, and the A21 interface is internal to the HRPD eAN. 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 eAN. Note: PDSN and HSGW functions may not be in the same physical entity.
IWS Function 1x BS
S101

A21 MME

A1/A1p

A1/A1p MSC/MSCe

IWS Function A1/A1p

A21

IWS Function Source ePCF SC/MM Function A10 A11 PDSN / HSGW

Source eAN Air Interface

A8 A9 A14 A20

AT

A15 A16 A17

A18A19

A13 A24 A12

AN AAA

Target eAN
7 8

RT

SC/MM Function Target ePCF

Figure 1.4-2

E-UTRAN - eHRPD IOS Architecture Reference Model (SC/MM in the ePCF)

9 10 11 12 13 14 15 16

Note: The IWS Function in Figure 1.4-2 may be collocated at either the 1x BS or at the HRPD ePCF, 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 ePCF, and the A1/A1p interface is supported between the MSC and the 1x BS. When the IWS function is part of the HRPD ePCF, the A1/A1p interface between the MSC and the HRPD ePCF exists, and the A21 interface is internal to the HRPD ePCF. 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 ePCF. Note: PDSN and HSGW functions may not be in the same physical entity. 1.4.1 A1 eHRPD IOS Interfaces 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. The A1 interface required for eHRPD is specified in A.S0008 [3] and A.S0009 [4]. 1-10

17 18 19 20 21 22

The interfaces defined in this specification are described as follows.

3GPP2 A.S0022-0 v1.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

A1p

The A1p interface carries signaling information between the call control and mobility management functions of the Mobile Switching Center Emulation (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. The A1p interface required for eHRPD is specified in A.S0008 [3] and A.S0009 [4]. The A8 interface carries user traffic between the Access Network and the PCF. For A8 descriptions, refer to section 2.2. The A8 interface required for standalone eHRPD and EPS - eHRPD interworking is specified in Annex A. The A9 interface carries signaling information between the AN and the PCF. For A9 descriptions, refer to section 2.2. The A9 interface required for standalone eHRPD and EPS - eHRPD interworking is specified in Annex A. The A10 interface carries user traffic between the PCF and the PDSN/HSGW. For A10 descriptions, refer to section 2.3. The A10 interface required for standalone eHRPD and EPS - eHRPD interworking is specified in Annex B. The A11 interface carries signaling information between the PCF and the PDSN/HSGW. For A11 descriptions, refer to section 2.3. The A11 interface required for standalone eHRPD and EPS - HRPD interworking is specified in Annex B. The A12 interface carries signaling information related to access authentication between the SC/MM function and the AN-AAA. For a description of the A12 interface, refer to section 2.4. For A.S0008 architecture, 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.S0009 architecture, the A13 interface is between the SC/MM function in the source PCF and the SC/MM function in the target PCF. For a description of the A13 interface, refer to section 2.5. For A.S0009 architecture, the A14 interface carries signaling information between the SC/MM function in the PCF and the AN. The A14 interface is not applicable to A.S0008 architecture. For a description of the A14 interface, refer to section 2.6. For A.S0009 architecture, the A15 interface carries signaling information between ANs when inter-AN paging is used. The A15 interface is not applicable to A.S0008 architecture. For a description of the A15 interface, refer to section 2.7. 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.8. The A17 interface carries signaling information between a source AN and a target AN to manage resources in support of inter-eAN 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.9. 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.9.

A8

A9

A10

A11

A12

A13

A14

A15

A16

A17

A18

1-11

3GPP2 A.S0022-0 v1.0

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

A19

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.9. For A.S0009 architecture, the A20 interface carries user traffic between the SC/MM function in the PCF and the AN. The A20 interface is not applicable to A.S0008 architecture. For a description of the A20 interface, refer to section 2.10. The A21 interface carries signaling information between the HRPD AN and the IWS. For a description of the A21 interface, refer to section 2.11. The A24 interface carries buffered user data from the source AN/PCF to the target AN/PCF for an AT, during A13 session transfer. The target AN/PCF interface endpoint is transmitted to the source AN/PCF in the A13-Session Information Request message. Refer to section 2.12. The S101 interface carries signaling information between the HRPD eAN and the Mobility Management Entity (MME). For a description of the S101 interface, refer to section 2.13. eHRPD IOS Network Entities A 1x Base Station (1x BS) operates on the cdma2000 1x air interface defined by C.S0001~C.S0006 [12]~[17] and also supports the 1x IOS specified in A.S0011~A.S0017 [5]~[11]. A logical entity in the RAN used for radio communications with the AT. An AN contains one or more RTs and is equivalent to a base station in 1x systems. AN in this specification refers to both legacy AN and evolved AN. Refer to the definition of Legacy Access Network and Evolved Access Network. 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 selfcontained data device such as a personal digital assistant. An AT is equivalent to a mobile station in 1x systems. The term AT applies to both an Evolved Access Terminal (eAT) and a legacy AT. An entity that performs access authentication functions for the RAN. Access Network that supports operations for EPS eHRPD RAN interworking specified in this specification, in addition to legacy access network capabilities. An eAT supports both evolved mode (refer to C.S0087 [24]) and legacy mode operation (refer to C.S0087 [24] and C.S0063 [20]). An eAT is referred to as a UE in TS 23.402 [1], TS 29.276 [2] and X.S0057 [26]. Packet Control Function that supports operations for EPS eHRPD RAN interworking specified in this specification, in addition to legacy packet control function capabilities.

A20

A21 A24

S101

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

1.4.2

1x Base Station

Access Network

Access Terminal

AN-AAA Evolved Access Network

Evolved Access Terminal

Evolved Packet Control Function

HRPD Serving Gateway IWS Function

The HSGW is the HRPD Serving Gateway that connects the evolved HRPD access network with the EPC as a trusted non-3GPP access network. 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 1-12

3GPP2 A.S0022-0 v1.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

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 an 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 Circuit Services Notification Application (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. Legacy Access Network An Access Network that complies to the specifications in A.S0008 [3] and/or A.S0009 [4] and does not support evolved mode operation in this specification. An AT that does not support evolved mode is referred to as a legacy AT. A Packet Control Function that complies to the specifications in A.S0008 [3] and/or A.S0009 [4] and does not support evolved mode operation in this specification. Mobile Station In 1x systems, the Mobile Station (MS) is an entity in the public cellular radio telecommunications service intended to be used while in motion or during halts at unspecified points. In this specification, the term MS may also refer to an AT where text that is applicable to 1x systems has been extended to apply to HRPD and/or eHRPD systems. 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 an MSCe. In situations where a statement applies to either the circuit-switched or packet-based MSC exclusively, the type of MSC is specifically identified (i.e., circuit-switched MSC or MSCe). Mobility Management Entity The MME is defined in TS 23.402 [1]. 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. An entity in the radio access network that manages the relay of packets between the AN and the PDSN/HSGW. PCF in this specification refers to both legacy PCF and evolved PCF. Refer to the definition of Legacy Packet Control Function and Evolved Packet Control Function.

Legacy Access Terminal

Legacy Packet Control Function

Mobile Switching Center

Packet Control Function

1-13

3GPP2 A.S0022-0 v1.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

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. PDSN in this specification refers to legacy PDSN that supports legacy HRPD session with AT or eAT. Radio Access Network 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 PDSN, and the interfaces between the AN and the MSC are considered parts of the RAN. Refer to section 1.4. An 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 C.S0087 [24]). SC/MM is logically located in the AN for the A.S0008 architecture or the PCF for the A.S0009 architecture 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: This function assigns a new UATI to an AT. Access Authentication for the A.S0008 architecture: 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 PPP procedures for access authentication. Terminal Authentication for the A.S0009 architecture: This function performs the terminal 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 terminal authentication. Mobility Management: This function manages the location of an AT.

RT

SC/MM Function:

32 33

1.5

HRPD Micro-Mobility and Macro-Mobility Concepts

Refer to A.S0008 [3] and A.S0009 [4].

34 35 36 37 38 39 40 41 42

1.6

Compatibility with IOS Standards

The E-UTRAN-eHRPD IOS architecture reference model in section 1.4 includes the following interfaces that also exist in the 1x architecture reference model (refer to A.S0011 [5]): A1/A1p, A8/A9, and A10/A11. To the extent 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 HRPD IOS version specified in A.S0008 [3] and A.S0009 [4] are used as the base documents for this specification. The changes required to A.S0008 [3] and A.S0009 [4] for eHRPD are shown in Annex A and Annex B.

43 44 45 46

1.7

Compatibility with 3GPP Standards

The E-UTRAN-eHRPD IOS architecture reference model includes the S101 interface. This interface is used to carry signaling information related to pre-registration, handoff preparation and execution between the HRPD and 3GPP networks. The transport requirements and interface definitions are specified in TS 1-14

3GPP2 A.S0022-0 v1.0

1 2 3 4

29.276 [2] for this interface. Transport and message encapsulation over S101 are specified in the Evolved 3GPP Packet Switched architecture reference model (refer to TS 23.402 [1]), while the E-UTRANeHRPD IOS contains the HRPD specific information exchanged with the AT when it is connected to the 3GPP network.

5 6

1.8

Message Body, Coding, Ordering, and Interpretation of Elements

Refer to A.S0008 [3] and A.S0009 [4].

7 8

1.9

Forward Compatibility Guidelines

Refer to A.S0008 [3] and A.S0009 [4].

9 10

1.10

Message Processing Guidelines

Refer to A.S0008 [3] and A.S0009 [4].

11 12

1.11

Message Definition Guidelines

Refer to A.S0008 [3] and A.S0009 [4].

13 14 15

1.12

eHRPD IOS Assumptions

For legacy mode operation, refer to A.S0008 [3] and A.S0009 [4]. For evolved mode operation, this section describes assumptions in this standard. 1.12.1 IOS Assumptions

16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39

The following assumptions are made regarding eAT, eAN, ePCF and HSGW behavior: 1. An evolved mode packet data session may transition from a serving E-UTRAN to a serving eHRPD system and from a serving eHRPD system to a serving E-UTRAN. A legacy mode packet data session may transition from a serving legacy HRPD system to a serving eHRPD system and from a serving eHRPD system to a serving legacy HRPD system, with the HRPD session transferred via the A13 interface in both cases. In addition, the eHRPD system may optionally support A13 session transfer with personality switch from evolved mode on eHRPD to legacy mode on HRPD. 2. An eHRPD system can support legacy ATs operating in legacy mode, eATs operating in evolved mode, and eATs operating in legacy mode. 3. For systems with SC/MM in the eAN, subnets do not span more than one HRPD packet zone. There may be more than one subnet within an HRPD packet zone and intra-ePCF handoffs may occur. 4. For the case of dormant inter-ePCF handoff, the target ePCF uses the HSGW address received from the source eAN/ePCF to send the A11-Registration Request message. Otherwise, the target ePCF uses the HSGW selection algorithm (if supported and if the International Mobile Subscriber Identity, IMSI, is available) or internal algorithms to select an HSGW. 5. Following a dormant handoff, the target eAN may send the Access Network Identifiers (ANID) to the target ePCF. If the eAT sends the System Identification (SID), Network Identification (NID), and Packet Zone Identification (PZID), then the ANID consists of a triplet containing the received values. If the eAT does not send the triplet, or the eAN chooses not to request this information from the eAT, then the target eAN may send the ANID received in the A13-Session Information Response message from the source eAN. If the target ePCF supports ANIDs, then it sets the Previous Access Network Identifiers (PANID) to the ANID received from the target eAN, and the Current Access Network Identifiers (CANID) to its own ANID in the A11 messages.

1-15

3GPP2 A.S0022-0 v1.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

6. For the instance of Packet Application terminated in the eAN, the eAT supports Challenge Handshake Authentication Protocol (CHAP) access authentication. In this case, the eAT sends a Network Access Identifier (NAI) of the form specified in RFC 1994 [28]. 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 access authentication is used, the eAN or ePCF always proposes CHAP as a PPP option in an initial Link Control Protocol (LCP) Configure-Request message during the PPP establishment. 9. The Mobile Node Identification (MN ID) that is used by the eAN and the ePCF in A9 and A11 messages is unique within the operators network, and is determined as follows: o If the eAN or ePCF uses the access authentication feature, the MN ID field is set to the MN ID value returned by the AN-AAA (e.g., IMSI) following successful access authentication. o Otherwise, the eAN or ePCF sets 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 eAT indicates it is ready to exchange data on the access stream, the eAT and the eAN initiate PPP procedures according to RFC 1661 [27]. 11. The eAT may support packet data service as specified in X.S0057 [26]. 12. If access authentication is used, the eAN may acquire the eAT hardware identifier via air-interface signaling, based on the network operator policies. For systems with SC/MM in the ePCF, the eAN may convey this AT hardware identifier information to the ePCF. Refer to A.S0009 [4]. 13. The eAN and eAT do not pass default attributes and attributes of hardlinked protocols over the air interface. Refer to C.S0087 [24]. 14. E-UTRAN-eHRPD interworking assumes that the eHRPD system has a way of obtaining the IMSI of the eAT. 15. For systems with SC/MM in the ePCF, Session information (UATI, authentication keys) for an active HRPD session shall be maintained in the SC/MM. This information may also be maintained in the eAN. 16. For systems with SC/MM in the ePCF, the SC/MM and the ePCF can communicate directly with each other. The interface between the ePCF and the SC/MM is considered beyond the scope of the standard. 17. For systems with SC/MM in the ePCF, one subnet (refer to C.S0087 [24]) shall not be covered by multiple ePCFs. 18. For systems with SC/MM in the ePCF, when inter-eAN paging is used, all eANs involved in the paging are connected to the same ePCF. 19. The eAN and ePCF do not store the S5/S8 Generic Routing Encapsulation (GRE) key, Access Point Name (APN) information or the Packet Data Network Gateway and (P-GW) IP Address. 20. The eAT may support E-UTRAN and eHRPD connectivity and interworking as specified in X.S0057 [26], TS 23.402 [1] and C.S0087 [24]. 21. The eAT and eAN may support Generic Key Exchange (GKE), refer to C.S0067 [21]. If GKE is used then the A9, A11, A13 and A16 interfaces are assumed to be secured because PMKs may be passed over those interfaces. 1.12.2 QoS Assumptions

42 43

Refer to A.S0008 [3] and A.S0009 [4].

1-16

3GPP2 A.S0022-0 v1.0

1 2 3

1.13

State Definition

For legacy mode operation, refer to A.S0008 [3] and A.S0009 [4]. For evolved mode operation, this section describes state definitions for the eHRPD system. 1.13.1 Packet Data Session State

4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

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, either an eHRPD connection exists between the eAT and the eAN over the eHRPD radio interface, or a virtual eHRPD connection over the S101 interface to the eAT exists. 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 eHRPD connection exists between the eAT and eAN over the eHRPD radio interface, no virtual eHRPD connection exists over the S101 interface, and no A8 connections exist between the eAN and the ePCF, however the PPP link between the eAT and the HSGW 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 eHRPD connection between the eAT and the eAN, no virtual eHRPD connection over the S101 interface, and no PPP link between the eAT and the HSGW. 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 and the eHRPD connection for the packet data session are released. Figure 1.13.1-1 shows the possible transitions between the states of a packet data session.
Active / Connected State Dormant State

Null / Inactive State

20 21

Figure 1.13.1-1 eHRPD Packet Data Session State Transitions 1.13.2 IP Flow State

22 23

Refer to A.S0008 [3] and A.S0009 [4].

24

1.14
1.14.1

Feature Descriptions
Explicitly Supported Features

25 26 27 28 29 30 31 32 33 34

Refer to A.S0008 [3] and A.S0009 [4] for features explicitly supported by eANs for legacy mode operation. Refer to A.S0008 [3] and A.S0009 [4] for the following features that are explicitly supported by eANs for evolved mode operation. Note that packet data session mobility between eHRPD and 1x is not supported for evolved mode operation. eAT Originates an HRPD Session (including Access Authentication) Re-authentication of an eAT eHRPD Data Delivery (both AT Terminated and AT Originated) eHRPD Connection Release 1-17

3GPP2 A.S0022-0 v1.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

HRPD Session Release eHRPD Packet Data Session Release Dormant Handoff of eHRPD eAT Between eANs Served by the Same HSGW Voice Call Delivery During Active eHRPD Data Session HRPD-1x cdma2000 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 ROHC on SO67 o AN-Based ROHC o HSGW-Based ROHC eHRPD Inter-eAN Connected State Session Transfer (hard handoff) eHRPD Inter-eAN Cross-Connectivity eHRPD Inter-eAN Session Transfer with Cross-Connectivity (including make-before-break) 1x Calling Party Number Presentation Reservation Label in HRPD Service Option When Paging on 1x Hard Handoff of a Voice over Internet Protocol (VoIP) Call from eHRPD to 1x Circuit Voice Call Prior Session Release QoS Update by the HSGW CSNA over A21 HSGW Initiated IP Flow Release Inter-eAN Paging When the AT is in Idle State Keep Alive over A13 Interface

The following subsections identify the features explicitly supported by standalone eHRPD systems for eHRPD HRPD interconnectivity and by eHRPD systems for E-UTRAN eHRPD interconnectivity. 1.14.1.1 Generic Key Exchange (GKE)

27 28 29

This feature supports Generic Key Exchange for security between the eAT and HSGW. This feature supports Generic Key Exchange for security between the eAT and HSGW. Refer to C.S0067 [21]. 1.14.1.2 Idle Handoff of Legacy Mode from eHRPD to HRPD

30 31 32

This feature supports idle handoff of an evolved or legacy AT in legacy mode from an eAN to a legacy HRPD AN. This may include prior session retrieval or prior session removal. 1.14.1.3 Idle Handoff of Legacy Mode from HRPD to eHRPD

33 34 35

This feature supports idle handoff of an evolved or legacy AT in legacy mode from a legacy HRPD AN to an eAN. This may include prior session retrieval or prior session removal. 1.14.1.4 Idle Handoff with Personality Switch from Evolved Mode on eHRPD to Legacy Mode on HRPD

36 37 38 39

This feature supports idle handoff of an eAT in evolved mode on an eHRPD system to legacy mode on a legacy HRPD system.

1-18

3GPP2 A.S0022-0 v1.0

1 2 3

1.14.1.5

Active Handoff of Legacy Mode from eHRPD to HRPD

This feature supports active handoff of an evolved or legacy AT in legacy mode on an eHRPD system to a legacy HRPD system. 1.14.1.6 Active Handoff of Legacy Mode from HRPD to eHRPD

4 5 6

This feature supports active handoff of an evolved or legacy AT in legacy mode on a legacy HRPD system to legacy mode on an eHRPD system. 1.14.1.7 Active Handoff from E-UTRAN to eHRPD

7 8 9

This feature supports handoff of an active eAT on the E-UTRAN air interface to an active call in evolved mode on the eHRPD air interface. 1.14.1.8 Active Handoff from eHRPD to E-UTRAN

10 11 12

This feature supports handoff of an active eAT in evolved mode on the eHRPD air interface to an active call on the E-UTRAN air interface. 1.14.1.9 Idle Handoff from E-UTRAN to eHRPD

13 14 15

This feature supports handoff of a dormant eAT on the E-UTRAN air interface to a dormant call in evolved mode on the eHRPD air interface. 1.14.1.10 Idle Handoff from eHRPD to E-UTRAN

16 17 18

This feature supports handoff of a dormant eAT in evolved mode on the eHRPD air interface to a dormant call on the E-UTRAN air interface. 1.14.1.11 Standalone eHRPD

19 20 21 22 23 24

This feature enables an eHRPD RAN to serve an eAT by interworking with the EPC. The standalone eHRPD system serves both legacy ATs and the eATs and is capable of selecting the appropriate gateway (PDSN or HSGW) based on the type of AT and mode of operation. The standalone eHRPD system supports interworking with legacy HRPD systems but it does not support interworking with the E-UTRAN. 1.14.2 1.14.2.1 Transparently Supported Features Active and Idle Handoff Between E-UTRAN and eHRPD for Dual Transmitter eATs

25

26 27 28 29

This specification transparently supports active and idle handoffs between E-UTRAN and eHRPD systems for dual transmitter eATs. The handoff messaging, procedures and call flows in this specification, while not restricted to single transmitter eATs, were developed assuming a single transmitter eAT. 1.14.3 HSGW Selection

30 31 32 33 34

An eAT indicates to an eAN that it is capable of operating in evolved mode (refer to C.S0087 [24]). When the eAT is operating in evolved mode as an eAT, the method described in section 1.14.3.1 shall be used for HSGW selection. When the AT is operating in legacy mode, the method described in A.S0013 [7] shall be used for PDSN selection. 1.14.3.1 HSGW Selection Algorithm

35 36 37 38

This section only applies to establishment of the first A10 bearer connection for a given eAT. Requests for additional A10 bearer connections (for additional PDSI (Packet Data Server Instance)) shall be sent to the HSGW currently supporting the existing A10 bearer connection(s). 1-19

3GPP2 A.S0022-0 v1.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

Each ePCF shall maintain a configuration table with IP addresses as follows. HSGW Number 0 1 N-1 IPv4 address r The HSGWs accessible from the ePCF shall be listed in ascending order of HSGW IP addresses. For two ePCFs to resolve the same IMSI to the same HSGW, the ePCFs need to have tables of equal lengths. In network configurations with full connectivity, the HSGW selection algorithm allows two ePCFs to resolve the same IMSI to the same HSGW. In network configurations with partial connectivity, tables of equal lengths can be achieved by adding dummy entries in the tables for HSGWs that exist in the network but are not accessible from the ePCF. The ePCF shall be capable of including dummy entries in the configuration table. Each dummy entry shall be placed in the position in the table that the HSGW entry would have had if the ePCF had had connectivity to that HSGW. The HSGW IP address for such dummy HSGW entries shall be set to all zeros. Finally, the entries shall be numbered from 0 to N-1 in ascending order, N being the total number of entries in the table. For initial HSGW assignment and for HSGW reselection, the ePCF shall determine which HSGW to use for a particular eAT by the following HSGW selection algorithm: HSGW No. = (truncated Mobile IMSI) modulo N, where (truncated Mobile IMSI) is defined to be the least significant 4 digits of the IMSI taken as a decimal value. The IP address of the selected HSGW shall be obtained by indexing at the HSGW Number entry in the configuration table. If the selected HSGW entry is a dummy, the ePCF shall select another HSGW by performing the following algorithm, up to N-1 times, until a non-dummy HSGW IP Address entry is found in the configuration table. HSGW No. = (HSGW No. +1 ) modulo N. After the ePCF has selected a non-dummy HSGW entry using the selection algorithm, the ePCF shall initiate establishment of the A10 connection with the selected HSGW. If the selected HSGW responds with code unknown PDSN address (88H) in the A11-Registration Reply, thereby proposing another HSGW, the ePCF may initiate establishment of the A10 connection with the proposed HSGW. If the selected HSGW does not reply to the registration request or replies with a code other than Registration accepted (00H), identification mismatch (85H), or unknown PDSN address (88H), the ePCF may select another HSGW among the other non-dummy entries. The ePCF may repeat this procedure until it successfully establishes an A10 connection. If the HSGW indicates identification mismatch (Code value 85H) in the A11-Registration Reply message, then retry A11-Registration Request as per procedures specified in section 2.1.1.4 in Annex B. HSGW IPv4 Address IPv4 address a IPv4 address b

1-20

3GPP2 A.S0022-0 v1.0

1 2

2
2.1

HRPD IOS Interfaces

A1/A1p (IWS - MSC) Interface

This section describes the RAN interfaces associated with this specification.

3 4

Refer to A.S0008 [3] and A.S0009 [4].

5 6 7

2.2

A8-A9 (AN - PCF) Interface

For legacy mode operation, refer to A.S0008 [3] and A.S0009 [4]. For evolved mode operation, refer to Annex A.

8 9 10

2.3

A10-A11 (PCF - PDSN/HSGW) Interface

For legacy mode operation, refer to A.S0008 [3] and A.S0009 [4]. For evolved mode operation, refer to Annex B.

11 12

2.4

A12 (AN/PCF - AN-AAA) Interface

Refer to A.S0008 [3] and A.S0009 [4].

13 14 15

2.5

A13 (AN/PCF AN/PCF) Interface

For legacy mode operation, refer to A.S0008 [3] and A.S0009 [4]. For evolved mode operation, refer to A.S0008 [3] and A.S0009 [4] except where overridden by this section. 2.5.1 A13-Session Information Request

16 17 18

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

19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38

When the target AN/PCF receives a packet from an AT that contains a UATI that is not in a subnet that is associated with the target AN/PCF, the target AN/PCF attempts to retrieve session related information from the source AN/PCF for the AT. The target AN/PCF sends an A13-Session Information Request message to the source AN/PCF to indicate the information requested. The target AN/PCF shall include the determined UATI, Security Layer Packet and Sector ID. The target AN/PCF then starts timer TA13req. The information content in the A13-Session Information Request message includes: UATI. This is the UATI received by the target AN/PCF using the UATI Color Code and UATI024 received from the AT, which allows the source AN/PCF 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/PCF 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/PCF shall set this field to the 128-bit identifier of the sector on which the UATI-Request message is received. Data Transfer. If the target AN/PCF is capable of receiving buffered data from the source AN/PCF, it may include the A24 Connection ID to be used for the tunneling of this data for the AT. The A24 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. 2-1

3GPP2 A.S0022-0 v1.0

1 2 3 4 5 6 7 8 9 10 11 12 13

If the target AN/PCF is an evolved AN/PCF (eAN/ePCF), it shall include the A13 eHRPD Indicators information element to indicate that it is an eAN/ePCF to the source AN/PCF.

If the source eAN/ePCF is supporting the AT in evolved mode (as an eAT), and the target AN/PCF is also an evolved AN/PCF (as determined by the A13 eHRPD Indicators Information Element (IE) in the A13Session Information Request), the source eAN/ePCF shall respond to this message by sending an A13Session Information Response message. If the source eAN/ePCF is supporting the AT in evolved mode (as an eAT), and the target AN/PCF is a legacy AN/PCF (as determined by the absence of the A13 eHRPD Indicators IE in the A13 Session Information Request), the source eAN/ePCF shall respond to this message by sending either an A13-Session Information Reject message with the cause indicating requested session not found to force the target AN/PCF to create a legacy HRPD session to a PDSN or an A13-Session Information Response message to send the Session State Information Record (SSIR) and Extended Session State Information Record (ESSIR) for all personalities 2 to the target AN/PCF. Refer to section 4.1.1.1, A13-Session Information Request, for the format and content of this message. 2.5.1.2 Failure Operation

14 15 16 17 18

If timer TA13req expires, the target AN/PCF may resend the A13-Session Information Request message to the source AN/PCF and restart timer TA13req a configurable number of times. If the A13-Session Information Response message is not received from the source AN/PCF, the target AN/PCF may begin a new session establishment with the AT. 2.5.2 A13-Session Information Response

19 20 21

The A13-Session Information Response message is used by the source AN/PCF to respond to the target AN/PCFs request to retrieve information about an AT. 2.5.2.1 Successful Operation

22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41

When the source AN/PCF 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/PCF request. After the source AN/PCF 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/PCF with the requested information and starts timer TA13res. The source AN/PCF includes SSIRs for the main personality and ESSIRs for all personalities other than the main personality in the A13-Session Information Response message. The target AN/PCF determines the current personality from the SessionConfigurationToken attribute of the main personality. For detailed information, refer to C.S0087 [24] . Upon receipt of the A13-Session Information Response message, the target AN/PCF stops timer TA13req. The information content in the A13-Session Information Response message includes: MN ID used by the source AN/PCF over the A11 interface. This allows the target AN/PCF 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/PCF to continue to use the air interface protocols previously negotiated between the AT and the source AN/PCF. PDSN address. For eHRPD, the PDSN IP Address IE contains the PDSN or HSGW IP address depending on whether the AT is operating legacy mode or evolved mode, respectively. This IPv4

E.g., if a legacy personality exists.

2-2

3GPP2 A.S0022-0 v1.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

address, when present, allows the target AN/PCF to reconnect (when possible) to the same PDSN or HSGW without executing a PDSN or HSGW re-selection algorithm. For the case of dormant interPCF handoff, the target PCF may use the PDSN or HSGW address received from the source AN/PCF (via the target AN in A.S0008 architectures) to send the A11-Registration Request message. Otherwise, the target PCF shall use the PDSN or HSGW selection algorithm (if supported) or internal algorithms to select a PDSN or HSGW. For eHRPD, if the eAT is operating in evolved mode and the target AN/PCF is a legacy AN/PCF (as indicated by the absence of the A13 eHRPD Indicators in the A13-Session Information Request message), then the source eAN/ePCF shall omit the PDSN IP Address IE. PANID. This information, if included, allows the target AN/PCF 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 legacy packet data session from a serving HRPD or eHRPD system to a serving 1x system and back to a serving HRPD or eHRPD system. Therefore, following a dormant handoff of a legacy packet data session, 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/PCF chooses not to request this information from the AT, then the target AN/PCF may use the PANID in the A13-Session Information Response message if included. Data Transfer. If the target AN/PCF indicated in the A13-Session Information Request message that it is capable of receiving buffered data from the source AN/PCF and the source AN/PCF will have data to send, the source AN/PCF 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/PCF may wait an implementation specific time after receiving the message before it stops expecting data, in the event that a buffer indicator is not received from the source AN/PCF in the Buffered Data Information GRE attribute. The target AN/PCF 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/PCF 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/PCF over A24 interface. Refer to section 4.1.1.2, A13-Session Information Response, for the format and content of this message. 2.5.2.2 Failure Operation

32 33

If timer TA13res expires, the source AN/PCF may re-send this message a configurable number of times.

34 35

2.6

A14 (AN - PCF) Interface

Refer to A.S0009 [4].

36 37

2.7

A15 (AN - AN) Interface

Refer to A.S0009 [4].

38 39 40

2.8

A16 (AN - AN) Interface

For legacy mode operation, refer to A.S0008 [3] and A.S0009 [4]. For evolved mode operation, refer to A.S0008 [3] and A.S0009 [4] except where overridden by this section. 2.8.1 A16 Message Definitions

41 42 43

Refer to A.S0008 [3] and A.S0009 [4]. The content of these references shall apply except as superseded by the following subsections. 2-3

3GPP2 A.S0022-0 v1.0

1 2 3

2.8.1.1

A16-Session Transfer Request

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.8.1.1.1 Successful Operation

4 5 6 7 8 9 10 11 12 13 14

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 message to the target AN and starts timer Tstreq16 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 4.1.4.1, A16-Session Transfer Request, for the format and content of this message. 2.8.1.1.2 Failure Operation

15 16 17 18 19 20

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.8.1.2 A16-Session Transfer Response

21 22 23

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.8.1.2.1 Successful Operation

24 25 26 27 28 29 30 31 32 33 34 35 36

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. If the A16-Session Transfer Request message included a ProtocolID indicating that this is an HRPD session for an eAT operating in evolved mode (refer to C.S0087 [24]), then the target eAN can know that the PDSN address provided is actually an HSGW address. 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 A16-Session Transfer Complete message. Upon receipt of the A16-Session Transfer Response message, the source AN stops timer Tstreq-16. Refer to section 4.1.4.2, A16-Session Transfer Response, for the format and content of this message. 2.8.1.2.2 Failure Operation

37 38 39 40 41

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-4

3GPP2 A.S0022-0 v1.0

1 2

2.9

A17, A18, and A19 Interface

Refer to A.S0008 [3] and A.S0009 [4].

3 4

2.10

A20 (AN - PCF) Interface

Refer to A.S0009 [4].

5 6

2.11

A21 (AN IWS) Interface

Refer to A.S0008 [3] and A.S0009 [4].

7 8

2.12

A24 AN/PCF-AN/PCF (IP Tunneling) Interface

Refer to A.S0008 [3] and A.S0009 [4].

9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29

2.13

S101 (MME eAN) Interface

If the eAN supports E-UTRAN interworking, the eAN shall support the S101 interface (refer to TS 29.276 [2]). The S101 interface supports procedures for Pre-Registration, Maintenance and Session Dormant and Active handoffs between MME and eHRPD networks. The S101 interface also supports the procedure of S101 redirection in the case of MME relocation procedure. The purpose of the pre-registration procedures is to minimize the service interruption time experienced at the eAT, by allowing the eAT to perform a session configuration or traffic allocation request (in the case of eHRPD) in the target access system before leaving the source access system. In cases where the eAT is connected to the E-UTRAN and conditions are such that a handoff to eHRPD may be required, the source system provides the eAT with sufficient information to perform preregistration with the target eHRPD access and core networks, over the S101 interface. If conditions subsequently warrant that a handoff should occur, the handoff signaling is also performed over the S101 interface. Once the eAT is ready to connect to the target system, it switches to the eHRPD access network. The S101 interface shall support the requirements described in TS 29.276 [2], Requirements for the S101 Reference Point. All S101 messages contain an S101 Session ID which serves to identify the eAT context at the E-UTRAN MME and the eHRPD eAN. The S101 Session ID is described in TS 29.276 [2], S101 Session Identifier. For the S101 interface specification, refer to TS 23.402 [1].

2-5

3GPP2 A.S0022-0 v1.0

1 2 3 4 5

(This page intentionally left blank)

2-6

3GPP2 A.S0022-0 v1.0

1 2 3 4 5 6 7 8 9

E-UTRAN-eHRPD IOS Call Flows

This section describes the call flows associated with eHRPD operation and handoff between the EUTRAN and an eHRPD system. Air interface messages and message sequences shown in the call 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. For the tunneled messaging shown in the call flows in this section, refer to TS 23.402 [1] for the S101 tunnel establishment procedures.

10 11 12 13 14 15 16 17 18 19 20 21 22 23

3.1

Supported Call Flows for eHRPD Operation

When an eAT is connected to the E-UTRAN and conditions are such that a handoff to eHRPD may be required, the eAT performs pre-registration with the target eHRPD system. The purpose of the preregistration procedures is to minimize the total service interruption time, by allowing the eAT to perform session configuration before leaving the E-UTRAN access system. The details of pre-registration are discussed in section 3.2. Since pre-registration may occur at any time prior to a E-UTRAN to eHRPD handoff, session maintenance may be required after pre-registration and before E-UTRAN to eHRPD handoff. For example, it may become necessary to modify the HRPD session configuration between the eAT and the eAN/ePCF as a result of moving under the coverage area of a new eAN/ePCF. However, not every call flow defined in A.S0008 [3], A.S0009 [4] can be executed during session maintenance. For example, call flows modifying the eHRPD Connection Layer are not executed. Table 3.1-1 identifies which call flows are allowed during session maintenance, which are allowed on eHRPD, and the IOS specifications in which they are referenced. Table 3.1-1 Call Flow1 Supported Call Flows for eHRPD Supported during HRPD Session Maintenance Yes Yes No Yes except for Connection Release due to Air Link Lost Yes Yes Yes Supported during eHRPD Yes Yes Yes Yes Reference

AT Originates HRPD Session Re-authentication Data Delivery Connection Release2

[3], [4] [3], [4] [3], [4] [3], [4]

HRPD Session Release Packet Data Session Release Initiated by the PDSN Dormant Handoff of HRPD AT between ANs Served by the Same PDSN Miscellaneous HRPD Session Call Flows Multiple Connection Procedures Support for Data Over Signaling Protocol

Yes Yes Yes

[3], [4] [3], [4] [3], [4]

Yes Session Information Update only Yes No

Yes

[3], [4]

Yes Yes

[3], [4] [3], [4]

3-1

3GPP2 A.S0022-0 v1.0

Call Flow1

Mobility Management

Connected State HRPD Session Transfer Call Flows Hard Handoff Negotiation Procedures with Example of Air Interface Signaling HRPD IOS Cross-Connectivity Call Flows E-UTRAN to eHRPD Handoff Call Flows
1 2 3 4 5 6

Supported during HRPD Session Maintenance Yes Prior Session Retrieval and Removal only No No

Supported during eHRPD Yes

Reference

[3], [4]

Yes Yes

[3], [4] [3], [4]

No Yes

Yes Yes

[3], [4] Section 3.2

Note 1: In Table 3.1-1, the term PDSN is from the A.S0008 [3] and A.S0009 [4] references. eHRPD terminology is not shown. Note 2: The Connection Release flows are triggered by the release of the virtual connection over the Signaling Adaptation Protocol (SAP) tunnel (refer to C.S0087 [24]).

7 8

3.2

E-UTRAN to eHRPD Handoff Call Flows

9 10 11 12 13 14

3.2.1

E-UTRAN to eHRPD Pre-Registration Call Flows

This section provides the call flows for E-UTRAN to eHRPD active handoff. Active handoff from EUTRAN involves three stages: pre-registration, preparation, and execution. The pre-registration stage precedes the preparation and execution, and is shown as a separate flow in the following subsections. Preparation and execution normally occur together, and are shown in a single flow in the following subsections. 3.2.1.1 E-UTRAN to eHRPD Active Handoff Pre-Registration

15 16

This section describes the pre-registration stage of handoff from E-UTRAN to eHRPD. 3.2.1.1.1 E-UTRAN to eHRPD Active Handoff Pre-Registration SC/MM at eAN Case

17 18 19

This section describes the pre-registration stage of handoff from E-UTRAN to eHRPD in the A.S0008 architecture.

3-2

3GPP2 A.S0022-0 v1.0

eAT

E-UTRAN

MME

eAN1/ ePCF1

eAN2/ ePCF2

HSGW

PCRF

ANAAA

0. eAT registered in MME for an ongoing data session 1. E-UTRAN indicates to the eAT that it should pre-register.

2. A communication path is established between the eAT and eHRPD. An S101 tunnel is used between MME and eAN1.

3. UATI-Request/Response (optional) 4. Session Configuration 5a. Device Level Authentication 5b. A12 Access-Request 5c. A12 Access-Accept 6a. A11-Registration-Request Tregreq 6b. A11-Registration-Reply 7a. Authenticate and establish IP service context between eAT and HSGW over default signaling flow. 7b. Authentication.

7c. Obtain policy info

8a. HRPD session maintenance with eAN1/ePCF1

8b. HRPD session maintenance with eAN2/ePCF2

8c. eAN2/ePCF2 performs A13 HO with eAN1/ePCF1

9. IP session maintenance with HSGW.

10. Update policy info
1 2

Figure 3.2.1.1.1-1

E-UTRAN to eHRPD Pre-Registration SC/MM at eAN Case

3 4 5 6

1. Assuming an existing radio connection on E-UTRAN (step 0), the E-UTRAN indicates to the eAT that it should begin pre-registration with the eHRPD system. Refer to TS 23.402 [1]. 2. A communication path is established between the eAT and eHRPD. The eAT, E-UTRAN, and MME support transparent eHRPD air interface signaling and PPP message transfer between the eAT and the 3-3

3GPP2 A.S0022-0 v1.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

MME. An S101 tunnel is used between the MME and the eAN. The MME then creates an S101 session with eAN1/ePCF1. 3. If the eAT does not have a UATI, or if the UATI needs to be changed, the eAT uses HRPD air interface signaling to request and receive a UATI value. 4. The eAT and eAN1/ePCF1 then configure the HRPD session using HRPD signaling tunneled via S101. Refer to C.S0087 [24]. 5. If device level authentication is required by the operator, the eAT and eAN1/ePCF1 establish a PPP connection and exchange CHAP signaling. eAN1/ePCF1 uses A12 signaling to perform the device level authentication as shown in steps 5b and 5c. 6. eAN1/ePCF1 and HSGW exchange A11 signaling messages to establish the main A10 connection. The A11-Registration Request message contains the Tunnel Mode indication with the value set to 1 specifying that the access is occurring through the S101 tunnel. Based upon this indication the HSGW does not perform binding establishment or update at the Packet Data Network Gateway (P-GW). If the eAT requests additional service connections after the main A10 connection is established, eAN1/ePCF1 may establish auxiliary A10 connections according to the request of the eAT. 7. Using the main A10 connection established in step 6, the eAT and HSGW exchange authentication signaling as described in X.S0057 [26]. The HSGW can obtain policy information related to the user from the Policy and Charging Rules Function (PCRF) as part of these procedures. Once authentication is complete, the eAT and HSGW exchange signaling to build the IP service context between themselves, including IP addresses, QoS information, Traffic Flow Templates (TFTs), etc. Refer to X.S0057 [26] for details. Steps 8-10 apply to session maintenance. 8. It may become necessary to modify the HRPD session configuration between the eAT and eAN1/ePCF1 (step 8a). Or to establish an HRPD session with eAN2/ePCF2 as a result of moving under the coverage area of a new eAN2/ePCF2 as shown in step 8b, for example. In which case, the new eAN2/ePCF2 will perform an A13 dormant handoff procedure with the old eAN1/ePCF1 as shown in step 8c. As part of the dormant handoff, the S101 tunnel is relocated to the new eAN2/ePCF2. The HRPD session maintenance is accomplished by HRPD signaling exchanges between the eAT and the eAN/ePCF via S101 tunneling. 9. If any bearer is added, modified, or deleted while the eAT is operating on E-UTRAN, similar changes are made in the IP service context between the eAT and the HSGW. This is accomplished by signaling those changes between the eAT and HSGW via S101 tunneling. 10. Depending on what IP session maintenance is done in step 9, the HSGW may need to update the PCRF. 3.2.1.1.2 E-UTRAN to eHRPD Active Handoff Pre-Registration SC/MM at ePCF Case

35 36 37

This section describes the pre-registration stage of handoff from E-UTRAN to eHRPD in the A.S0009 architecture.

3-4

3GPP2 A.S0022-0 v1.0

eAT

E-UTRAN

MME

eAN

ePCF

HSGW

PCRF

ANAAA

0. eAT registered in MME for an ongoing data session 1. E-UTRAN indicates to the eAT that it should pre-register.

2. A communication path is established between the eAT and eHRPD. An S101 tunnel is used between MME and the eAN.

3a. UATI-Request/Response (optional)

3b. A14 exchanges for UATI assignment

4a. Session Configuration

4b. A9-Setup-A8

TA8-setup

4c.A9-Release-A8 Complete 4d. A14-Session Info Update 4e. A14- Session info Update Ack 5b. A14 exchanges for term auth 6a. A9-Setup-A8

Tsu14

5a. Device Level Authentication

5c. A12 Access-Request 5d. A12 Access-Accept

6b. A11 RRQ 6c. A11 RRP

TA8-setup

Tregreq
6d. A9-Connect-A8

7a. Authenticate and establish IP service context between eAT and HSGW over default signaling flow.

7b. Authentication.

8a. HRPD Session Maintenance

7c. Obtain policy information

8b. Session Maintenance

9. IP Environment session maintenance with HSGW.

10. Update policy information
1 2

Figure 3.2.1.1.2-1

E-UTRAN to eHRPD Pre-Registration SC/MM at ePCF Case

3 4 5 6 7

1. Assuming an existing radio connection on E-UTRAN (step 0), the E-UTRAN indicates to the eAT that it should begin pre-registration with the eHRPD system. 2. A communication path is established between the eAT and eHRPD. The eAT, E-UTRAN, and MME support transparent eHRPD air interface signaling and PPP message transfer between the eAT and MME. An S101 tunnel is used between MME and the eAN. 3-5

3GPP2 A.S0022-0 v1.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

3. If the eAT does not have a UATI, or if the UATI needs to be changed, the eAT uses HRPD air interface signaling to request and receive a UATI value. This step includes the A14 signaling exchanges between eAN and ePCF to assign an UATI to the eAT by ePCF as detailed in A.S0009 [4]. 4. (step 4a) The eAT and the eAN then configure the HRPD session using HRPD signaling tunneled via S101. (step 4b) The eAN sends an A9-Setup-A8 message to the ePCF to establish the main A8 connection. (step 4c) The ePCF sends an A9-Release-A8 Complete message to the eAN containing session information and requesting terminal authentication. (step 4d) The eAN sends an A14-Session Information Update message to the ePCF to update the negotiated session information at the ePCF. (step 4e) The ePCF responds with an A14-Session Information Update Ack message. 5. If device level authentication is required by the operator, the eAT and eAN/ePCF establish a PPP connection and exchange CHAP signaling. The eAN and ePCF follow the A14 procedures specified in A.S0009 [4] for terminal authentication, as shown in step 5b. The ePCF uses A12 signaling to perform the device level authentication with the AN-AAA, as shown in steps 5c and 5d. 6. The eAN sends an A9-Setup-A8 message to establish the main A8 connection (step 6a), which triggers the ePCF and HSGW A11 signaling exchange messages to establish the main A10 connection (steps 6b and 6c). The A11-Registration Request message contains the Tunnel Mode indication with the value set to 1 specifying that the access is occurring through the S101 tunnel. Based upon this indication the HSGW does not perform binding establishment or update at the PGW. Upon successful establishment of the A10 connection, the ePCF sends an A9-Connected-A8 message to the eAN to complete the establishment of the A8 connection (step 6d). If the eAT requests additional service connections after the main A10 connection is established, eAN1/ePCF1 may establish auxiliary A10 connections according to the request of the eAT. 7. Using the main A10 connection established in steps 6b/c, the eAT and HSGW exchange authentication signaling as described in X.S0057 [26]. The HSGW can obtain policy information related to the user from the PCRF as part of these procedures. Once authentication is complete, the eAT and HSGW exchange signaling to build the IP service context between themselves, including IP addresses, QoS information, TFTs, etc. Refer to X.S0057 [26] for details. 8. It may become necessary to modify the HRPD session configuration between the eAT and the eAN/ePCF. This may be necessary as a result of moving under the coverage area of a new eAN, for example. This is accomplished by HRPD signaling exchanges between the eAT and the eAN via S101 tunneling and corresponding IOS signaling between eAN and ePCF and between ePCF and HSGW. 9. If any bearer is added, modified, or deleted while the eAT is operating on E-UTRAN, similar changes are made in the IP service context between the eAT and the HSGW. This is accomplished by signaling those changes between the eAT and HSGW via S101 tunneling. 10. Depending on what IP service context changes may be made in step 9, the HSGW may need to update the PCRF. 3.2.2 E-UTRAN to eHRPD Active Handoff

38 39

40 41 42 43 44

3.2.2.1

E-UTRAN to eHRPD Active Handoff Preparation and Execution A8 Connected

This section describes the preparation and execution stages of handoff from E-UTRAN to eHRPD. This scenario assumes that the handoff to eHRPD happens shortly after the pre-registration completion, however before the eHRPD packet data session transitions to dormant state. The call flow applies to both the A.S0008 and A.S0009 architectures.

3-6

3GPP2 A.S0022-0 v1.0

1 2

Figure 3.2.2.1-1

E-UTRAN to eHRPD Handoff A8 Connected

3 4 5 6 7

1. Assuming an existing active service on E-UTRAN with pre-registration already completed and S101 established (step 0), the E-UTRAN determines that the eAT should begin handoff to eHRPD. 2. The eAT sends a tunneled HRPD ConnectionRequest message to the eAN to request radio resources and a traffic channel assignment. As this message is relayed via the MME, the MME attaches the associated P-GW addresses and uplink GRE keys in the S101 Direct Transfer message.

3-7

3GPP2 A.S0022-0 v1.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

3. The eAN sends an A9-Update-A8 message to the ePCF containing the P-GW addresses and the uplink GRE keys that were received in step 2. It also requests the data forwarding address for the HSGW and a GRE key. The eAN starts timer Tupd9. 4. The ePCF sends an A11-Registration Request message to the HSGW containing the P-GW addresses, the Tunnel Mode indication with the value set to 1 and the uplink GRE keys. It also requests the data forwarding address for the HSGW and GRE keys. The ePCF starts timer Tregreq. 5. The HSGW replies with an A11-Registration Reply message. If data forwarding is supported, the data forwarding address for the HSGW and the GRE keys are included in the message. Upon receipt of this message, the ePCF stops timer Tregreq. 6. The ePCF sends an A9-Update-A8 Ack message to the eAN containing the data forwarding address for the HSGW and GRE keys, if provided in step 5. Upon receipt of this message, the eAN stops timer Tupd9. 7. The eAN allocates the necessary radio resources and sends a tunneled HRPD TrafficChannelAssignment (TCA) message to the eAT. IEs in the S101 message contain the data forwarding address for the HSGW and GRE keys, if provided in step 6. The TCA is sent via an S101 Direct Transfer message to the MME along with the GRE keys and IP address for tunneling downlink data from the Serving Gateway (S-GW) to the HSGW (step 7a), and is then relayed from the MME via the E-UTRAN to the eAT (step 7b). 8. If data forwarding is to be used, the E-UTRAN begins to forward data packets via the S-GW to the HSGW using the HSGW IP address and GRE keys. 9. The eAT acquires the eHRPD system. 10. The eAT sends an HRPD TrafficChannelComplete (TCC) message to the eAN. 11. Upon receiving the TCC, the eAN sends an A9-Update-A8 message containing a Handoff Execution indication set to 1 to the ePCF, and starts timer Tupd9. 12. The ePCF sends an A11-Registration Request message containing an Active Start Airlink Record to the HSGW and the tunnel mode indication with the value set to 0, and starts timer Tregreq. 13. The HSGW acknowledges with an A11-Registration Reply message. Upon receipt of this message, the ePCF stops timer Tregreq. 14. The ePCF acknowledges with an A9-Update-A8 Ack message. Upon receipt of this message, the eAN stops timer Tupd9. 15. The HSGW creates the Proxy Mobile Internet Protocol (PMIP) binding and completes any other necessary procedures. Refer to X.S0057 [26] for details. This step is triggered by step 12 and happens in parallel with step 13. 16. The eAN sends an S101 Notification Request message to indicate handoff completion to the MME. 17. The MME responds with an S101 Notification Response message to the eAN. 18. The E-UTRAN, MME, and S-GW release resources, including the PMIP tunnel from the S-GW to the P-GW. 3.2.2.2 E-UTRAN to eHRPD Active Handoff Preparation and Execution A8 Disconnected

38 39 40 41 42

This section describes the preparation and execution stages of handoff from E-UTRAN to eHRPD. This scenario assumes that the handoff to eHRPD happens after the pre-registration completion and the eHRPD packet data session transition to dormant state. The call flow applies to both the A.S0008 and A.S0009 architectures.

3-8

3GPP2 A.S0022-0 v1.0

eAT

E-UTRAN MME

S-GW

eAN

ePCF

HSGW

PCRF

P-GW

0. Existing active service on E-UTRAN. The eAT has completed pre-registration. S101 is established. 1. E-UTRAN indicates to the eAT that it should handoff to eHRPD.

2a. HRPD: ConnectionRequest

2b. S101 Direct Transfer (HRPD Conn Req, P-GW Addr(es), GRE keys)

3a. A9-Setup-A8

TA8-setup
3b. A9-Release-A8 Complete 3c. A9-SetupA8

TA8-setup

Tregreq
6. A9-Connect-A8

4. A11 RRQ 5. A11 RRP

7b. HRPD: Traffic Channel Assignment

7a. S101 Direct Transfer (HRPD Traffic Channel Assignment, HSGW S103 IP@, GRE Keys)

8. (optional) Data Forwarding

9. The eAT acquires the eHRPD radio. 10. HRPD: Traffic Channel Complete
11. A9-Update-A8 12. A11 RRQ (Active Start) 13. A11 RRP 14. A9-Update-A8 Ack 16. S101 Notification Request (Handover indicator) 17. S101 Notification Response

Tupd9

Tregreq

15. The HSGW creates the PMIP connection to the P-GW, may update policy information, and starts accounting operations.

18. E-UTRAN, S-GW, and MME releases resources.

1 2

Figure 3.2.2.2-1

E-UTRAN to eHRPD Handoff A8 Disconnected

3 4

1. Assuming an existing active service on E-UTRAN with pre-registration already completed and S101 established (step 0), the E-UTRAN determines that the eAT should begin handoff to eHRPD.

3-9

3GPP2 A.S0022-0 v1.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

2. The eAT sends a tunneled HRPD ConnectionRequest message to the eAN to request radio resources and a traffic channel assignment. As this message is relayed via the MME, the MME attaches the associated P-GW addresses and uplink GRE keys in the S101 Direct Transfer message. 3. Steps 3.a and 3.b only apply to the A.S0009 architecture. Step 3.c is common for both architectures. 3.a. The eAN sends an A9-Setup-A8 message to the ePCF with the Data Ready Indicator (DRI) set to 1, containing the P-GW addresses and the uplink GRE keys that were received in step 2. It also requests the data forwarding address for the HSGW and GRE keys. The Session Information Required field of the HRPD A9 Indicators IE in this message is set to 1 to get Session Information Record from the ePCF. The message includes the single connection information. The eAN starts timer TA8setup. 3.b. The ePCF determines that multiple A8 connections are required. The ePCF sends an A9-Release-A8 Complete message to the eAN with the SSIRs and the cause value set to Multi-connection required. Upon receipt of this message, the eAN stops timer TA8setup. 3.c. The eAN sends an A9-Setup-A8 message to the ePCF with the DRI set to 1 and including multiple GRE keys for the A8 tunnels establishment. The message also contains the P-GW addresses and the uplink GRE keys that were received in step 2. The eAN starts timer TA8setup. 4. The ePCF sends an A11-Registration Request message to the HSGW containing the P-GW addresses, the Tunnel Mode indication with the value set to 1 and the uplink GRE keys. It also requests the data forwarding address for the HSGW and GRE keys. The ePCF starts timer Tregreq. 5. The HSGW replies with an A11-Registration Reply message containing the data forwarding address for the HSGW and GRE keys. Upon receipt of this message, the ePCF stops timer Tregreq. 6. The ePCF sends an A9-Connect-A8 message to the eAN containing the data forwarding address for the HSGW and GRE keys. Upon receipt of this message, the eAN stops timer TA8setup. 7. Using the default A10 connection established during the pre-registration phase (refer to section 3.2.1.1), the eAN allocates the necessary radio resources and sends a tunneled HRPD TrafficChannelAssignment (TCA) message to the eAT. IEs in the S101 message contain the data forwarding address for the HSGW and GRE key, if provided in step 6. The TCA is sent via an S101 Direct Transfer message to the MME along with the GRE keys and IP address for tunneling downlink data from the S-GW to the HSGW (step 7a), and is then relayed from the MME via the E-UTRAN to the eAT (step 7b). 8. If data forwarding is to be used, the E-UTRAN begins to forward data packets via the S-GW to the HSGW using the HSGW IP address and GRE key. 9. The eAT acquires the eHRPD radio interface. 10. The eAT sends an HRPD TrafficChannelComplete (TCC) message to the eAN. 11. Upon receiving the TCC, the eAN sends an A9-Update-A8 message containing a Handoff Execution indication set to 1 to the ePCF, and starts timer Tupd9. 12. The ePCF sends an A11-Registration Request message containing an Active Start Airlink Record to the HSGW and the Tunnel Mode indication with the value set to 0, and starts timer Tregreq. 13. The HSGW acknowledges with an A11-Registration Reply message. Upon receipt of this message, the ePCF stops timer Tregreq. 14. The ePCF acknowledges with an A9-Update-A8 Ack message. Upon receipt of this message, the eAN stops timer Tupd9. 15. The HSGW creates the PMIP binding and completes any other necessary procedures. Refer to X.S0057 [26] for details. This step is triggered by step 12 and happens in parallel with step 13. 16. The eAN sends an S101 Notification Request message to indicate handoff completion to the MME. 3-10

3GPP2 A.S0022-0 v1.0

1 2 3 4

17. The MME responds with an S101 Notification Response message to the eAN. 18. The E-UTRAN, MME, and S-GW release resources, including the PMIP tunnel from the S-GW to the P-GW.

3.2.3 3.2.3.1

E-UTRAN to eHRPD Idle Handoff Idle Handoff from E-UTRAN to eHRPD (Same eAN/ePCF)

6 7 8

This procedure is used in the case the eAT has a dormant HRPD packet data session in the target eAN, either through the pre-registration procedure or previous eHRPD attachment.
eAT E-UTRAN MME eAN ePCF HSGW P-GW

1. eAT is idle in E-UTRAN 2. eAT decides to perform cell reselection 3. Air Interface signaling indicate eAT presence on eHRPD 4. A9-Setup-A8 5. A11-Reg Request (lifetime, Tunnel Mode = 0) TA8-setup Tregreq 7. A11-Registration Reply
9 10

6. PMIP Binding Update

8. A9-Release-A8 Complete

Figure 3.2.3.1-1

Idle Handoff from E-UTRAN to eHRPD (Same eAN/ePCF)

11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26

1. The eAT is attached to the E-UTRAN and is in idle state. The eAT has a dormant HRPD packet data session in the eAN, either through the pre-registration procedure or a previous eHRPD attachment. 2. Based on some trigger, the idle eAT decides to perform cell re-selection to the eAN. Note that the cell re-selection decision can be made at any time when the eAT is attached in the E-UTRAN (including as soon as the eAT has completed pre-registration). 3. The eAT retunes to eHRPD and either opens a connection with the eAN or informs the eAN that the eAT has performed an inter-technology idle handoff and is now tuned to eHRPD. 4. The eAN sends an A9-Setup-A8 message, with the Data Ready Indicator set to 0, the Handoff Indicator set to 0 and the Tunnel Mode indicator set to 0, to the ePCF and starts timer TA8-setup. 5. Since the HRPD session is in this subnet, the A10 connections already exist. The ePCF sends an A11Registration Request message for all A10 connections and starts timer Tregreq. The ePCF sets the Tunnel Mode indication in the A11-Registration Request message to indicate to the HSGW that a PMIP binding is needed. 6. Upon receipt of the A11-Registration Request message, the HSGW determines that it does not have a PMIP binding for this eAT and updates the PMIP binding. At this point the user plane is switched in the P-GW towards the eHRPD system via the HSGW.

3-11

3GPP2 A.S0022-0 v1.0

1 2 3 4 5 6

7. The A11-Registration Request message is validated and, if new A10 connections are being established, the HSGW accepts the A10 connections by returning an A11-Registration Reply message with an accept indication. The ePCF stops timer Tregreq. This step may occur any time after step 5. 8. The ePCF responds to the eAN with an A9-Release-A8 Complete message. The eAN stops timer TA8-setup.

7 8 9 10

3.2.3.2

Idle Handoff from E-UTRAN to eHRPD (Different eAN/ePCF)

This procedure is used in the case the eAT has a dormant HRPD packet data session in an eAN other than the target eAN, either through the pre-registration procedure or previous eHRPD attachment. This call flow shows both successful dormant handoff with UATI and prior session retrieval.
eAT E-UTRAN MME Target eAN/ePCF Source eAN/ePCF HSGW P-GW

1. eAT is idle in E-UTRAN 2. eAT decides to perform cell reselection 3. Initiate Session Establishment TA13req 4. A13-Session Information Request 5. A13-Session Information Response 6. Complete Session Establishment TA13res 7. Location Update Procedures 8. A13-Session Information Confirm
9. A11-Registration Request (non-zero lifetime, MEI, Tunnel Mode indication = 0)

Tregreq 11. A11-Registration Reply 12. A11-Registration Update 13. A11-Registration Ack 14. A11-Registration Request (lifetime = 0) 15. A11-Registration Reply
11 12

10. PMIP Binding Update

Tregupd

Tregreq

Figure 3.2.3.2-1

Idle Handoff from E-UTRAN to eHRPD (Different eAN/ePCF)

13 14 15 16 17 18

1. The eAT is attached to the E-UTRAN and is in idle state. The eAT has a dormant HRPD packet data session in the source eAN, either through the pre-registration procedure or previous eHRPD attachment. 2. Based on some trigger, the idle eAT decides to perform cell re-selection to the eHRPD. Note that the cell re-selection decision can be made at any time when the eAT is attached in the E-UTRAN (including as soon as the eAT has completed pre-registration). 3-12

3GPP2 A.S0022-0 v1.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

3. The eAT retunes to eHRPD and initiates HRPD session establishment with the target eAN. During this procedure, the eAT sends 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 eAN/ePCF attempts to retrieve the existing HRPD session State Information from the source eAN/ePCF. If the network is configured for prior session retrieval and the eAT has closed the session, the eAT 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 eAN/ePCF assigns the new UATI to the eAT. The target eAN/ePCF may request Hardware ID from the eAT at any time before step 4. The eAT performs the session establishment procedure by sending a Configuration Request message including PriorSession Attribute to the target eAN/ePCF. 4. The target eAN/ePCF sends an A13-Session Information Request message to the source eAN/ePCF to retrieve the context of the session. The A13-Session Information Request message shall include the received UATI, the Security Layer Packet and Sector ID. The message also contains the Hardware ID, if available. The target eAN/ePCF starts timer TA13req. 5. The source eAN/ePCF sends an A13-Session Information Response message to the target eAN/ePCF with the session information. The source eAN/ePCF starts timer TA13res. The target eAN/ePCF stops timer TA13req. 6. The eAT and target eAN/ePCF complete HRPD session establishment. Depending on the state of the eAT and the target eAN/ePCF, 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. 7. If the target eAN supports the Location Update procedure, the target eAN updates the ANID in the eAT using the Location Update procedure. The target eAN may also retrieve the PANID from the eAT if necessary (e.g., the Session Configuration retrieved in step 5 indicates that the source AN does not support the Location Update procedure). 8. The target eAN/ePCF informs the source eAN/ePCF that it now has control of the eAT via an A13Session Information Confirm message. Upon receipt of the A13-Session Information Confirm message the source AN deletes the associated AT HRPD session information. The source eAN/ePCF stops timer TA13res. 9. Since the HRPD session was not previously in this subnet, the A10 connections are created to the target ePCF. The target ePCF sends an A11-Registration Request message with a non-zero lifetime and with the Tunnel Mode indication set to 0 to cause the HSGW to move all A10 connections. The A11-Registration Request message includes the Mobility Event Indicator (MEI) within the Critical Vendor/Organization Specific Extension (CVSE). This message also includes a CVSE containing Accounting Data (A10 Connection Setup Airlink Record). The target ePCF starts timer Tregreq. 10. Upon receipt of the A11-Registration Request message for HRPD session with nonzero lifetime timer and with the Tunnel Mode indication set to 0, the HSGW determines that it does not have a PMIP binding for this eAT and updates the PMIP binding. At this point the user plane is switched in the PGW towards the eHRPD system via the HSGW. 11. The HSGW sends an A11-Registration Reply message with an accept indication. This step may occur any time after step 10. If the HSGW has data to send, it includes the Data Available Indicator within the CVSE. If the subscriber has a Subscriber QoS Profile, the HSGW includes it in a Normal Vendor Specific Extension (NVSE). The A10 connection binding information at the HSGW is updated to point to the target ePCF. The target ePCF stops timer Tregreq. 12. The HSGW sends an A11-Registration Update message to initiate closure of the A10 connections for the eAT with the source eAN/ePCF. The HSGW starts timer Tregupd. 13. The source eAN/ePCF acknowledges by sending an A11-Registration Ack message. The HSGW stops timer Tregupd. 3-13

3GPP2 A.S0022-0 v1.0

1 2 3 4 5

14. The source eAN/ePCF sends an A11-Registration Request message with lifetime=0 for all A10 connections. The source eAN/ePCF starts timer Tregreq. 15. The HSGW sends an A11-Registration Reply message to acknowledge the removal of the A10 connections by the source eAN/ePCF. The source eAN/ePCF stops timer Tregreq.

6 7 8 9 10

3.2.3.3

Idle Handoff from E-UTRAN to eHRPD with Prior Session Removal

This procedure is used in the case the eAT has a dormant HRPD packet data session in an eAN other than the target eAN, either through the pre-registration procedure or previous eHRPD attachment. This scenario shows prior session information removal in the case of expiration of the session retrieval timer (i.e., timer TA13req) or operators policy.
eAT E-UTRAN MME Target eAN/ePCF Source eAN/ePCF HSGW P-GW

1. eAT is idle in E-UTRAN 2. eAT decides to perform cell reselection 3. UATI Assignment 4. Hardware ID Acquisition 5. Configuration Request (Prior Session Attribute) 6. Configuration Response (Null) TA13rel

7. A13-Resource Release Request 8. A13-Resource Release Response Tregreq 9. A11-Registration Request (lifetime = 0) 10. A11-Registration Reply 12. A11-Registration Request (non-zero lifetime, MEI, Tunnel Mode indication = 0) 14. A11-Registration Reply

11. Complete Session Establishment

Tregreq

13. PMIP Binding Update

11 12

Figure 3.2.3.3-1

Idle Handoff from E-UTRAN to eHRPD with Prior Session Removal

13 14 15 16 17 18 19 20

1. The eAT is attached to the E-UTRAN and is in idle state. The eAT has a dormant HRPD packet data session in the source eAN, either through the pre-registration procedure or previous eHRPD attachment. 2. Based on some trigger, the idle eAT decides to perform cell re-selection to the eHRPD. Note that the cell re-selection decision can be made at any time when the eAT is attached in the E-UTRAN (including as soon as the eAT has completed pre-registration). 3. The eAT retunes to eHRPD and initiates HRPD session establishment with the target eAN/ePCF. The AT has closed the session. The eAT sends a UATIRequest message with a Random Access Terminal 3-14

3GPP2 A.S0022-0 v1.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

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. 4. The target eAN/ePCF may request Hardware ID from the AT at any time before step 7. 5. The AT performs the session establishment procedure using the Configuration Request message, including the Prior Session Attribute. If the target eAN/ePCF received the Prior Session Attribute in the Configuration Request message, this call flow assumes that the target eAN/ePCF is configured to release the prior session information on the source eAN/ePCF after receiving Prior Session Attribute. 6. The target eAN/ePCF sends the Configuration Response message with the Prior Session Attribute set to Null. 7. The target eAN/ePCF sends an A13-Resource Release Request message including the prior session UATI as the session identifier to the source eAN/ePCF and starts timer TA13rel. In addition, the target eAN/ePCF includes the Sector ID, Security Layer Packet and Hardware ID, if this information is available. 8. When the source eAN/ePCF receives the A13-Resource Release Request message, it (depending on operators policy) checks if requested session information is stored in the source eAN/ePCF, 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. The source eAN/ePCF sends the A13-Resource Release Response message including the result for handling the A13-Resource Release Request message to the target eAN/ePCF. Upon receipt of the A13-Resource Release Response message, the target eAN/ePCF stops timer TA13rel. 9. The source eAN/ePCF may initiate closure of the A10 connections by sending an A11-Registration Request message with Lifetime=0. The source eAN/ePCF starts timer Tregreq. 10. The HSGW send an A11-Registration Reply message to acknowledge the removal of the A10 connections by the source eAN/ePCF. Upon receipt of this message, the source eAN/ePCF stops timer Tregreq. 11. The eAT and target eAN/ePCF complete HRPD session establishment. A new HRPD session may be initiated if required. This step may occur any time after step 6. 12. The target ePCF sends an A11-Registration Request message with a non-zero lifetime and with the Tunnel Mode indication set to 0 to cause the HSGW to move all A10 connections. The A11Registration Request message includes the MEI within the CVSE, a Tunnel Mode indication set to 0, and a non-zero Lifetime. This message also includes a CVSE containing Accounting Data (A10 Connection Setup Airlink Record). The target eAN/ePCF starts timer Tregreq. 13. Upon receipt of the A11-Registration Request message for HRPD session with nonzero lifetime timer and with the Tunnel Mode indication set to 0, the HSGW determines that it does not have a PMIP binding for this eAT and updates the PMIP binding. At this point the user plane is switched in the PGW towards the eHRPD system via the HSGW. 14. The HSGW sends A11-Registration Reply message with an accept indication. This step may occur any time after step 12. If the HSGW has data to send, it includes the Data Available Indicator within the CVSE. If the subscriber has a Subscriber QoS Profile, the HSGW includes it in an NVSE. The A10 connection binding information at the HSGW is updated to point to the target ePCF. Upon receipt of this message, the target eAN/ePCF stops timer Tregreq.

43 44 45

3.3

eHRPD to E-UTRAN Handoff Call Flows

This section describes the call flows for idle and active handoff from eHRPD to E-UTRAN. Note that idle handoff from eHRPD to E-UTRAN can occur when the eAT simply selects an E-UTRAN cell, tunes to 3-15

3GPP2 A.S0022-0 v1.0

1 2

E-UTRAN, and performs normal E-UTRAN attach procedures. Idle handoff can also be accomplished using the procedure in the following subsection. 3.3.1 eHRPD to E-UTRAN Idle Handoff Call Flow

3 4 5 6 7

This section describes the procedure for non-optimized idle handoff from eHRPD to E-UTRAN. This procedure assumes that the eAT did not previously attach to the E-UTRAN. Prior to the handoff, the eAT is dormant on eHRPD. After the handoff, the eAT remains pre-registered in eHRPD (i.e., the eAT retains its HRPD session).

8 9

Figure 3.3.1-1 Non-Optimized eHRPD to E-UTRAN Idle Handoff 1. The eAT is idle in the HRPD system. 2. Based on some trigger, the eAT decides to perform cell re-selection to E-UTRAN. 3. The eAT switches over to E-UTRAN. 4. The eAT performs the E-UTRAN access procedure shown in TS 23.402 clause 8.2.1.2 [1], including notifying the HSGW to perform resource deallocation procedures. 5. The HSGW may wait an implementation-dependent amount of time before initiating A10 release procedures (refer to A.S0008 [3] and A.S0009 [4]) due to the possibility of ping-ponging.

10 11 12 13 14 15 16

3-16

3GPP2 A.S0022-0 v1.0

1 2

4
4.1

Messages, Information Elements and Timer Definitions

Message Definitions

3 4

5 6

4.1.1

A13 Message Definitions

7 8 9

4.1.1.1

A13-Session Information Request

This message is sent from the target AN/PCF to the source AN/PCF 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 A13 eHRPD Indicators Section Reference [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] 4.2.1.4 Element Direction Target Source Target Source Target Source Target Source Target Source Target Source Target Source Target Source Oa O O O
b

Type M R R R C C C C

Ob O O
c d

10 11 12 13 14

a. Refer to Section 2.5 of A.S0008 [3] and A.S0009 [4] for information on this IE. b. This IE is included when the information is available to the target AN/PCF. c. This IE may be included if the target AN/PCF supports data transfer during A13 session transfer. d. This IE is included when the target AN/PCF is an eAN/ePCF. The following table shows the bitmap layout for the A13-Session Information Request message. 4.1.1.1 A13-Session Information Request 7 6 (MSB) 5 4 3 2 1 0 Octet 1 1 2 3 4 (LSB) (MSB) Security Layer Packet: A13 Element Identifier = [02H] Length = [variable] Security Layer Packet 4-1 18 1 2 3 A13 Message Type = [01H] Length = [10H] UATI

UATI 128: A13 Element Identifier = [01H]

3GPP2 A.S0022-0 v1.0

4.1.1.1 A13-Session Information Request 7 6 5 4 (LSB) (MSB) 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> (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) A13 eHRPD Indicators: A13 Element Identifier = [21H] Length = [01H] 4-2 3 2 1 0 Octet 4 n 1 2 3 4 18 1 2 3 4 5 6 7 n 1 2 3 n 1 2 3 4 5 6 7 8 n 1 2

3GPP2 A.S0022-0 v1.0

4.1.1.1 A13-Session Information Request 7 6 5 4 3 2 1 0

Evolved AN/PCF = [1]

Octet 3

Reserved = 0000 000

2 3 4

4.1.1.2

A13-Session Information Response

This message is sent from the source AN/PCF to the target AN/PCF and includes the requested session control information. 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 Source HSGW H1 IPv4 Address Section Reference [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] 4.2.1.3 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 Source Target O O O O O O
a g

Type M R C C C R C C C C C C C C C

g,l g

b,c,d,f c,d,e,f

Og O O O
g

Og,h
g,i g,i g j

O O

5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

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 SSIR for the main HRPD personality, as specified in C.S0082 [23], C.S0063 [20] and C.S0087 [24]. Therefore the target AN/PCF 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 C.S0087 [24] if the corresponding personality includes those Sub Blobs. Refer to X.S0057 [26] and C.S0087 [24] 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 C.S0087 [24]. Multiple instances of this IE shall be sorted in order of increasing personality index. 4-3

3GPP2 A.S0022-0 v1.0

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

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/PCF. h. Subject to configuration 3, this IE is included if the information is available at the source AN/PCF. If the target AN/PCF subsequently receives this information from the PDSN, then the information received from the PDSN takes precedence. 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/PCF 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/PCF support data transfer during session transfer (as indicated in the A13-Session Information Request message) and the source AN/PCF has data to send.

j.

k. This IE is included when the source eAN/ePCF and the target eAN/ePCF are connected to HSGWs the ProtocolID indicates that this is an HRPD session for an eAT operating in evolved mode (refer to C.S0087 [24]) and the information is available at the source AN/PCF. l. The target eAN/ePCF can inspect the SSIRs/ESSIRs sent to it to determine whether the AT is operating as an eAT, and thus know that the PDSN address provided is actually an HSGW address. Otherwise, the target eAN/ePCF shall operate in legacy mode. 4.1.1.2 A13-Session Information Response 7 6 (MSB) 5 4 3 2 1 0 Octet 1 1 2 3 4 (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)

The following table shows the bitmap layout for the A13-Session Information Response message.

A13 Message Type = [04H] Length = [10H] UATI

UATI 128: A13 Element Identifier = [01H]

18 1 2
3

Identity Digit 3 = [0H-9H] (BCD)

Identity Digit 2 = [0H-9H] (BCD)

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.

4-4

3GPP2 A.S0022-0 v1.0

4.1.1.2 A13-Session Information Response 7 6 5 4 3 2 1 0 Octet n = [1111] (if even number of digits) (MSB) Identity Digit N+2 = [0H-9H] (BCD) n+1 1 2 3 4 5 (LSB) Access Network Identifiers: A13 Element Identifier = [07H] Type = 01H Length = [05H]
Reserved

Identity Digit N+1 = [0H-9H] (BCD)

Identity Digit N = [0H-9H] (BCD)

PDSN IP Address: A13 Element Identifier = [06H] Length = [04H] PDSN IP Address

6 1 2 3 4

(MSB)

SID (LSB) NID (LSB) PZID

5 6 7 8 1 2 3 4

(MSB)

(MSB) (MSB)

Session State Information Record: A13 Element Identifier = [08H] Length = [variable] (LSB) Session State Information Record (LSB)

n 1 2 3 4 5

(MSB)

Extended Session State Information Record: A13 Element Identifier = [09H] Length = [variable] (LSB) Reserved = [0000] Personality Index (LSB) Forward QoS Information: A13 Element Identifier = [0AH] Length = [variable]

(MSB)

Session State Information Record

n 1 2 j j+1

Forward QoS Information Entry { 1-31: Entry Length = [variable] SR_ID = [01H-1FH] 4-5

3GPP2 A.S0022-0 v1.0

4.1.1.2 A13-Session Information Response 7 6 Reserved = [000] 5 4 3 2 1 0 Octet j+2 k k+1 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] 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: A13 Element Identifier = [0CH] 1 2 3 4 (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 4-6 i i+1 i+2 i+3 j Personality Index = [0H FH] Forward Flow Count = [01H FFH] n 1 2 3 4 Length = [variable] Subscriber QoS Profile = <any value> Reverse Flow Count = [1 - 31]

Forward Flow Entry { Forward Flow ID Count :

3GPP2 A.S0022-0 v1.0

4.1.1.2 A13-Session Information Response 7 6 5 4 3 2 1 0 Octet 1 2 3 4 j j+1 j+2 j+3 (LSB) } Reverse Flow Entry (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 = [02H] RLP Count = [variable] RLP ID List for Data Transfer { RLP Count: RLP_ID = [00H FFH] } RLP ID List for Data Transfer (MSB) Source HSGW H1 IPv4 Address: A13 Element Identifier = [20H] Length = [04H] HSGW H1 IP IPv4 Address = <any value> 1 2 3 4 5 (LSB)
1

Reverse QoS Update Information: A13 Element Identifier = [0EH] Length = [variable] Reserved = [0000] Personality Index = [0H FH] Reverse Flow Count = [01H FFH]

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>

k 1 2 3 n 1 2 3 4 n

2 3

4.1.2

A14 Message Definitions

Refer to A.S0009 [4].

4-7

3GPP2 A.S0022-0 v1.0

1 2

4.1.3

A15 Message Definitions

Refer to A.S0009 [4]. 4.1.4 A16 Message Definitions

3 4 5

Refer to A.S0008 [3] and A.S0009 [4]. The content of these references shall apply except as superseded by the following subsections. 4.1.4.1 A16-Session Transfer Request

6 7 8

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 Source HSGW H1 IPv4 Address Section Reference [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] 4.2.4.3 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 Source Target O O O O O
b a

M R C R R R R C R C C C C C C C C C C C C C Oi

Oc
d

Oe O O O O O O O O O
f f

Og
h

Oh
j

Ok
l m

n o

Op
q

9 10 11 12 13 14

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. b. This IE carries the IP address of the A11 interface on the PDSN currently connected to the source PCF. When this element is included for an HRPD session in legacy mode, it includes the PDSN IP address. When this element is included for an HRPD session in evolved mode, it includes the HSGW IP address. 4-8

3GPP2 A.S0022-0 v1.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

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 C.S0087 [24] is configured for the current personality, then this IE carries a RouteUpdate message as specified in C.S0087 [24]. f. This IE is included if the information is available at the source AN. g. Subject to configuration 4, 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. q. This IE carries the IPv4 address of the H1 interface on the HSGW currently connected to the source PCF when the AT is operating in evolved mode. The following table shows the bitmap layout for the A16-Session Transfer Request message. 4.1.4.1 A16-Session Transfer Request 7 6 5 4 3 2 1 0 Octet 1 A16 Message Type = [01H]

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.

4-9

3GPP2 A.S0022-0 v1.0

4.1.4.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 3 = [0H-9H] (BCD)

Identity Digit 2 = [0H-9H] (BCD)

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+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

(MSB)

Source PDSN Address: A16 Element Identifier = [06H] Length = [04H] PDSN IP Address

4-10

3GPP2 A.S0022-0 v1.0

4.1.4.1 A16-Session Transfer Request 7 6 5 4 3 2 1 0 (LSB) Session State Information Record {1+: (MSB) (MSB) Session State Information Record: A16 Element Identifier = [03H] Length = [variable] (LSB) Session State Information Record 1 2 3 4 Octet 6

(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

Length = [variable] Forward QoS Information Entry { 1-31: Entry Length = [variable] SR_ID = [01H-1FH] Reserved = [000] Forward Flow Count = [1 - 31] Forward Flow Entry { Forward Flow ID Count : 4-11

3GPP2 A.S0022-0 v1.0

4.1.4.1 A16-Session Transfer Request 7 6 5 4 3 2 1 0 Octet k k+1 Entry Length = [01H] Forward Flow ID = [00H FFH] } 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 (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] 4-12 1 2 i i+1 i+2 i+3 j Personality Index = [0H FH] Forward Flow Count = [01H FFH] n 1 2 3 4 Length = [variable] Subscriber QoS Profile = <any value> Reverse Flow Count = [1 - 31]

3GPP2 A.S0022-0 v1.0

4.1.4.1 A16-Session Transfer Request 7 6 5 4 3 2 1 0 Octet 3 4 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 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> Personality Index = [0H FH]

Reverse Flow Count = [01H FFH]

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

(MSB) (MSB)

UDP Port = [0000H FFFFH] IPv4 Address = <any value> 4-13

3GPP2 A.S0022-0 v1.0

4.1.4.1 A16-Session Transfer Request 7 6 5 4 3 2 1 0 Octet 11 12 (LSB) } Sector Endpoint Information (MSB) Assigning SC IP Address: A16 Element Identifier = [20H] Length = [04H] Assigning SC IP Address 1 2 3 4 5 (LSB) Timer { 1: Timer Type = [01H (Tsclose) ] Timer Length = [05H] (MSB) Starting Time = <any value> 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> Reference 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 13

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> 4-14

3GPP2 A.S0022-0 v1.0

4.1.4.1 A16-Session Transfer Request 7 6 5 4 (LSB) Target Sector ID: A16 Element Identifier = [24H] Length = [11H] Reserved = [000 0000] Sector ID Same as OTA = [0,1] 3 2 1 0 Octet 19 1 2 3

(MSB)

Target Sector ID = <any value> (LSB)

4 19 1 2 3 4 5 (LSB) 6

(MSB)

Source HSGW H1 IPv4 Address: A16 Element Identifier = [25H] Length = [04H] HSGW H1 IPv4 Address

1 2 3

4.1.4.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 [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] 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

Oc,d,f Oe,f

4 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. If Signaling Link Protocol (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.

4-15

3GPP2 A.S0022-0 v1.0

1 2 3 4 5 6 7 8 9 10 11 12

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. The following table shows the bitmap layout for the A16-Session Transfer Response message. 4.1.4.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) Proposed Session State Information Record: A16 Element Identifier = [04H] Length = [variable] (LSB) 1 2 3

4-16

3GPP2 A.S0022-0 v1.0

4.1.4.2 A16-Session Transfer Response 7 (MSB) 6 5 4 3 2 1 0 Octet 4 Session State Information Record

(LSB) } Proposed 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 = <any value> Session State Information Record

1 2 3 4 5

(LSB) } Extended Session State Information Record

1 2

4.1.5

A17 Message Definitions

Refer to A.S0008 [3] and A.S0009 [4]. 4.1.6 A18 Message Definitions

3 4

Refer to A.S0008 [3] and A.S0009 [4]. 4.1.7 A19 Message Definitions

5 6

Refer to A.S0008 [3] and A.S0009 [4]. 4.1.8 A21 Message Definitions

7 8

Refer to A.S0008 [3] and A.S0009 [4].

9 10

4.2
4.2.1

Information Element Definitions

A13 Information Element Definitions

11 12 13

Refer to A.S0008 [3] and A.S0009 [4]. The content of these references shall apply except as superseded by the following subsections. 4.2.1.1 A13 Information Element Identifiers

14 15 16 17

The following table lists all the IEs that make up the messages defined in section 4.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 IEI (Hex) 01H 4-17 Reference [3], [4]

3GPP2 A.S0022-0 v1.0

Element Name 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 Source HSGW H1 IPv4 Address A13 eHRPD Indicators
1 2 3

IEI (Hex) 02H 03H 04H 05H 06H 07H 08H 09H 0AH 0BH 0CH 0DH 0EH 0FH 10H 11H 12H 13H 14H 15H 16H 17H 18H 19H 20H 21H

Reference [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] 4.2.1.3 4.2.1.4

4.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. Table 4.2.1.2-1 Information Element A13 1x LAC Encapsulated PDU A13 1x Message Transmission Control A13 eHRPD Indicators A13 Message Type Cross Reference of IEs with Messages Ref. [3], [4] [3], [4] 4.2.1.4 [3], [4] IEI 17H 18H 21H Used in These Messages A13-Paging Request A13-1x Air Interface Signaling A13-Paging Request A13-Session Information Request A13-Session Information Response A13-Session Information Confirm 4-18 Ref. [3], [4] [3], [4] [3], [4] 4.1.1.1 4.1.1.1 4.1.1.2 [3], [4]

none A13-Session Information Request

3GPP2 A.S0022-0 v1.0

Table 4.2.1.2-1 Information Element

Cross Reference of IEs with Messages Ref. IEI Used in These Messages 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 Ref. [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] 4.1.1.1 4.1.1.2 [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] 4.1.1.1 4.1.1.2 4.1.1.2 4.1.1.2

A13 Vendor-Specific Information Access Network Identifiers ADDS User Part AT Designated Frequency AT-ID

[3], [4] [3], [4] [3], [4] [3], [4] [3], [4]

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

[3], [4]

04H

A13-Session Information Reject A13-Resource Release Response A13-Keep Alive Response

Correlation ID

[3], [4]

11H

A13-Paging Request A13-Paging Request Ack A13-Paging Delivered A13-Paging Delivered Ack A13-1x Air Interface Signaling A13-1x Air Interface Signaling Ack

Data Transfer Extended SSIR Forward QoS Information

[3], [4] [3], [4] [3], [4]

19H 09H

A13-Session Information Request A13-Session Information Response A13-Session Information Response

0AH A13-Session Information Response 4-19

3GPP2 A.S0022-0 v1.0

Table 4.2.1.2-1 Information Element Forward QoS Update Information Hardware ID

Cross Reference of IEs with Messages Ref. IEI Used in These Messages Ref. 4.1.1.2 [3], [4] 4.1.1.1 [3], [4] 4.1.1.2 [3], [4] [3], [4] [3], [4] 4.1.1.2 4.1.1.2 4.1.1.2 4.1.1.1 [3], [4] 4.1.1.1 [3], [4] 4.1.1.2 [3], [4] 4.1.1.2 [3], [4] 4.1.1.1 4.1.1.2 [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4]

[3], [4] [3], [4]

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 Source HSGW H1 IPv4 Address Subscribed QoS Profile UATI 128

[3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] 4.2.1.3 [3], [4] [3], [4]

05H 13H 12H 06H 0FH 03H 02H 08H 20H 01H

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 A13-Session Information Response 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

0BH A13-Session Information Response

0CH A13-Session Information Response

1 2 3

4.2.1.3

Source HSGW H1 IPv4 Address

This IE is used to provide the source HSGW H1 IPv4 address to the target evolved AN/PCF. This address is passed to the target HSGW if the target eAN/ePCF cannot connect to the source HSGW. 4-20

3GPP2 A.S0022-0 v1.0

4.2.1.3 Source HSGW H1 IPv4 Address 7 6 5 4 Length (MSB) HSGW H1 IPv4 Address 3 2 1 0 Octet 1 2 3 4 5 (LSB)
1 2 3 4

A13 Element Identifier = [20H]

Length HSGW H1 IPv4 Address 4.2.1.4

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 the H1 interface (refer to X.S0057 [26]) of the source HSGW.

5 6

A13 eHRPD Indicators

This IE indicates that the sending AN/PCF is an eAN/ePCF. 4.2.1.4 A13 eHRPD Indicators 7 6 5 4 Length Reserved Evolved AN/PCF 3 2 1 0 Octet 1 2 3 A13 Element Identifier = [21H]

7 8 9 10 11

Length Evolved AN/PCF

This field contains the number of octets in this IE following this field as a binary number. This field shall be set to 1 to indicate that the target is an evolved AN/PCF. Otherwise this field shall be set to 0.

12 13

4.2.2

A14 Information Element Definitions

Refer to A.S0009 [4]. 4.2.3 A15 Information Element Definitions

14 15

Refer to A.S0009 [4]. 4.2.4 A16 Information Element Definitions

16 17

Refer to A.S0008 [3] and A.S0009 [4]. 4.2.4.1 A16 Information Element Identifiers

18 19 20 21

The following table lists all the IEs that make up the messages defined in section 4.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) Identifier (Hex) 01H 4-21 Reference [3], [4]

3GPP2 A.S0022-0 v1.0

Element Name 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 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 Source HSGW H1 IPv4 Address

Identifier (Hex) 02H 03H 04H 05H 06H 07H 08H 09H 0AH 0BH 0CH 0DH 0EH 0FH 10H 11H 12H 13H 14H 15H 16H 17H 18H 19H 1AH 1BH 1CH 1DH 1EH 1FH 20H 21H 22H 23H 24H 25H

Reference [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] N/A [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] 4.2.4.3

4-22

3GPP2 A.S0022-0 v1.0

1 2

4.2.4.2

A16 Cross Reference of IEs with Messages Table 4.2.4.2-1 A16 Cross Reference of IEs with Messages Ref. [3], [4] 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 A16-FL Signal Tunnel Ack A16-RL Signal Tunnel A16-RL Signal Tunnel Ack A16-Attributes Update A16-Attributes Update Ack [3], [4] [3], [4] [3], [4] [3], [4] 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 Ref. 4.1.4.1 4.1.4.2 [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] 4.1.4.1 [3], [4] 4.1.4.1 4.1.4.1 4.1.4.2 [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] 4.1.4.1 4.1.4.2

Information Element A16 Message Type

none A16-Session Transfer Request

Access Network Identifiers AssignedUATI Assigning SC IP Address AT-ID

0EH A16-Session Transfer Complete 0CH A16-Session Transfer Request

ConfirmedUATI Correlation ID

[3], [4] [3], [4]

0DH A16-Session Transfer Complete 18H A16-Session Transfer Request A16-Session Transfer Response 4-23

3GPP2 A.S0022-0 v1.0

Table 4.2.4.2-1 Information Element

A16 Cross Reference of IEs with Messages Ref. IEI Used in These Messages 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 Ref. [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] 4.1.4.1 [3], [4] [3], [4] 4.1.4.1 4.1.4.2 [3], [4] [3], [4] [3], [4] [3], [4] 4.1.4.1 4.1.4.1 [3], [4] 4.1.4.1 4.1.4.2 [3], [4] 4.1.4.1 4.1.4.1 4.1.4.1 4.1.4.1 [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] 4.1.4.1 4.1.4.1 [3], [4]

Encapsulated Message

[3], [4]

09H

A16-Session Transfer Request A16-FL Signal Tunnel A16-RL Signal Tunnel

Extended Session State Information Record

[3], [4]

05H

A16-Session Transfer Request A16-Session Transfer Response 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) Proposed Session State Information Record Reverse QoS Information Reverse QoS Update Information RTD Information Sector Endpoint Information Sequence Number

[3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [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

[3], [4] [3], [4] [3], [4] [3], [4] [3], [4]

13H 16H 22H

A16-Session Transfer Request A16-Session Transfer Request A16-Session Transfer Request A16-Attributes Update

1EH A16-Session Transfer Request 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

[3], [4] [3], [4]

23H

A16-Session Transfer Request A16-Session Transfer Complete

1CH A16-Session Transfer Request

4-24

3GPP2 A.S0022-0 v1.0

Table 4.2.4.2-1 Information Element Session Transfer Abort Cause Session Transfer Complete Parameters Session Transfer Reject Cause Session Transfer Information Session State Information Record

A16 Cross Reference of IEs with Messages Ref. [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] IEI Used in These Messages A16-Attributes Update 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 Ref. [3], [4] [3], [4] [3], [4] [3], [4] 4.1.4.2 4.1.4.1 [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] 4.1.4.1 4.1.4.1 4.1.4.1 4.1.4.1 4.1.4.1

0AH A16-Session Transfer Response

SLP-D Parameters SLP-F Parameters SLP Reset Message SEQ Info Source HSGW H1 IPv4 Address Source PDSN Address Subscriber QoS Profile Target Sector ID Timers
1 2 3

[3], [4] [3], [4] [3], [4] 4.2.4.3 [3], [4] [3], [4] [3], [4] [3], [4]

10H 11H 1FH 25H 06H 14H 24H 21H

A16-Session Transfer Complete A16-Session Transfer Complete A16-Session Transfer Complete A16-Session Transfer Request A16-Session Transfer Request A16-Session Transfer Request A16-Session Transfer Request A16-Session Transfer Request

4.2.4.3

Source HSGW H1 IPv4 Address

This IE is used to provide the source HSGW H1 IPv4 address to the target evolved AN. This address is passed to the target HSGW, when the target eAN cannot connect to the source HSGW. 4.2.4.3 Source HSGW H1 IPv4 Address 7 6 5 4 Length (MSB) HSGW H1 IPv4 Address 3 2 1 0 Octet 1 2 3 4 5 (LSB) 6 A16 Element Identifier = [25H]

4 5 6 7

Length HSGW H1 IPv4 Address 4.2.5

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 the H1 interface of the source HSGW.

8 9

A17, A18, and A19 Information Element Definitions

Refer to A.S0008 [3] and A.S0009 [4].

4-25

3GPP2 A.S0022-0 v1.0

1 2

4.2.6

A21 Information Element Definitions

Refer to A.S0008 [3] and A.S0009 [4].

3 4 5 6 7

4.3

Timer Definitions

Refer to A.S0008 [3], A.S0009 [4] for timers associated with the eHRPD IOS specification.

4-26

3GPP2 A.S0022-0 v1.0

1 2 3 4 5 6

Annex A

A8-A9 (AN - PCF) Interface Change Text (Normative)

Note: Annex A contains A9 messaging updates to A.S0008 [3] and A.S0009 [4] for eHRPD mode support. Use of an ellipsis () indicates that the base document is unchanged. For A9 eHRPD messaging that is unchanged from HRPD, refer to A.S0008 [3] and A.S0009 [4]. The section uses the terminology AT and AN unless the text is explicitly referring to a 1x system, in which case MS and BS are used, respectively. The MS and BS terms are also retained for all existing field names.

7 8

2.1

A8/A9 Interface Setup Procedures

This section contains the messages used to set up an A8 connection. 2.1.1 A9-Setup-A8

9 10 11

This message is sent from the BS in 1x systems or the AN in HRPD systems to the PCF to request the establishment of an A8 connection for a PDSI activation, hard or dormant handoff of a PDSI. 2.1.1.1 Successful Operation In 1x systems, when 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. In HRPD systems, the AN includes in the A9-Setup-A8 message the HRPD A9 Indicator IE with the Session Information Required Indicator bit set to 1, if the AN does not have session information to establish a traffic channel. For the case where the AN does not have the session information required to establish the traffic channel, the traffic channel is established after the A8 establishment procedure and retrieval of session information from the PCF. 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. For eHRPD, the A9-Setup-A8 message requests to setup the main A8 connection. In the case where the A9-Setup-A8 message is sent for pre-registration, the A9-Setup-A8 message includes the eHRPD A9 Indicators IE indicating that the message is sent for pre-registration and the EPS Information IE including parameters received via S101 interface. In the case where the A9-Setup-A8 message is sent for handoff execution, the A9-Setup-A8 message includes the eHRPD A9 Indicators IE indicating that the message is sent for handoff execution and EPS information IE including parameters received via S101 interface. If the eAN supports GKE then the eHRPD A9 Indicators IE also includes a request for Pairwise Master Key (PMK) information. 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) 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. 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.

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-1

3GPP2 A.S0022-0 v1.0

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23

In HRPD systems, when the AN supports GRE extensions and determines that a GRE extension for the IP flow discriminator is required, the AN 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 AT performs a hard handoff during packet data services, the target AN 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 AN sets the Handoff Indicator field of the A9-Setup-A8 message to 1 and the Data Ready Indicator to 1. When the AN receives a request for a dormant handoff from the AT (e.g., origination message with DRS bit set to 0 or including PREV_PZID, PREV_SID, or PREV_NID), the AN sends the A9-Setup-A8 message to the PCF and starts timer TA8-setup. In this case, the AN sets the Handoff Indicator to 0. If no other PDSI is active, the AN shall wait until the MSC has accepted the dormant handoff request (e.g., the AN receives an Assignment Request or ADDS Transfer Ack message) before sending the A9-Setup-A8 message. If the AT supports short data bursts and the AN allows short data bursts to be sent for the PDSI, the AN shall set the Short Data Burst (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 AN 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 AN may resend the A9Setup-A8 message to the PCF and restart timer TA8-setup a configurable number of times. In HRPD systems, if the PCF decides that validation of the Security Layer Packet received in the A9-Setup-A8 message failed, the PCF shall send an A9-Release-A8 Complete message with cause value indicating Authentication Failure. If the AN 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 AN does not resend the A9-Setup-A8 message, the AN shall initiate release of the AT 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

24 25 26 27 28 29 30 31 32 33 34 35 36 37 38

39 40

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 AN in response to an A9-Setup-A8 message. In HRPD systems, the PCF includes session information in the A9-Connect-A8 message if the Session Information Required Indicator bit is set in the HRPD A9 Indication IE and is included in the 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 A-2

41 42 43 44 45 46

3GPP2 A.S0022-0 v1.0

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

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 AN 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. For eHRPD systems, the ePCF sends the A9-Connect-A8 message including HSGW Information IE when the PCF receives HSGW related parameters over A11 interface. The ePCF includes the HSGW Information IE with PMK Information when the ePCF receives PMK Information over the A11 interface. 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. 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. 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 AN. The PCF starts timer Tdiscon9.

20 21 22

23 24 25 26

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.

27

2.2.1 A9-Release-A8 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.

28 29 30

31 32 33 34 35 36 37 38 39 40 41

A-3

3GPP2 A.S0022-0 v1.0

1 2 3 4 5 6 7 8 9 10 11

For eHRPD systems, the eAN includes eHRPD A9 Indicators with the Tunnel Mode indication set to 1 in the A9-Release-A8 message when the virtual HRPD connection is released. 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. 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.

12 13 14 15 16 17

18

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

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 AN to update the AN 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 AN. The A9-Update-A8 message is sent from the AN 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. For eHRPD systems, the eAN sends an A9-Update-A8 message to carry EPS information to the ePCF during handoff execution procedure when the A8 connection is established. 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 connection. 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 0x0000 in the U_QoS_SUB_BLOB for an IP flow, then the AN shall A-4

3GPP2 A.S0022-0 v1.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

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 C.S0087 [24]), 5 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 Flow Profile ID value to 0x0000 in the Forward/Reverse Updated QoS Sub-BLOB for the IP flow that the PDNS 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. The AN may send an A9-Update-A8 message to the PCF to indicate if short data bursts may be sent to the AT. The PCF may send an A9-Update-A8 message to the AN if the ATs SDB capability is cached at the PCF so the AN does not need to query the AT for its SDB capability. The AN may also send the A9Update-A8 message to the PCF to indicate a successful Short Data Burst delivery to the AT if the PCF was not informed previously that the SDB was delivered successfully to the AT. The A9-Update-A8 message is also used to inform the PCF of a access or terminal authentication failure at the MSC or at the AN-AAA for HRPD systems, following an access attempt by an AT undergoing dormant handoff. The AN can also use this message to inform the PCF that a dormant AT has powered down. In these two cases, the PCF initiates the release of all A10 connections associated with the AT. 2.5.1.1 Successful Operation If the A9-Update-A8 message is sent from the PCF to the AN 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 AN, the PCF starts timer Tupd9 and waits for an A9-Update-A8 Ack message from the AN. If the A9-Update-A8 message includes updated QoS and the AN does not have sufficient resources available, then the AN 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 AN only has resources available to comply with the updated QoS for some of the specified flows, the AN may respond by sending an A9-Update-A8 Ack message with cause value Partial QoS updated. The AN 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 AN to the PCF to pass accounting or authentication information, the AN 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.

28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43

i.e., ProfileType = NULL in ReservationKKQoSRequestFwd or ReservationKKQoSRequestRev.

A-5

3GPP2 A.S0022-0 v1.0

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

If the message is sent from the AN to the PCF or from the PCF to the AN to indicate if short data bursts may be sent to the AT, 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 AN 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 AN to the PCF to indicate a successful short data burst delivery to the AT, the AN shall set the Cause field to SDB successfully delivered (17H), start Tupd9 and wait for an A9Update-A8 Ack message from the PCF. For eHRPD, if the eAN sends an A9-Update-A8 message during the handoff execution procedure when the A8 connection is established, then the A9-Update-A8 message includes the eHRPD A9 Indicators IE indicating that the message is sent for handoff execution and the EPS information IE includes parameters received via the S101 interface. In eHRPD systems, this message also includes the HSGW Information IE to support sending PMK keys when they become available if they were unavailable when the eAN requested them. 2.5.1.2 Failure Operation When the message is sent from the PCF to the AN to update parameters for a PDSI, if Tupd9 expires, the PCF may resend the A9-Update-A8 message to the AN and restart timer Tupd9 a configurable number of times. If the A9-Update-A8-Ack message is not received from the AN, 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 AN 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 AN may resend the A9-Update-A8 message and restart timer Tupd9 a configurable number of times. If the acknowledgment is not received from the PCF, the AN ceases sending this message, and commences PDSI clearing. 2.5.2 A9-Update-A8 Ack

19 20 21 22 23 24 25 26 27 28 29

30 31 32 33

For eHRPD, the ePCF sends the A9-Update-A8 Ack message including HSGW Information IE in response to the A9-Update-A8 message when the ePCF receives HSGW related parameters over A11 interface.

34

3.1.1 A9-Setup-A8 This message is sent from the AN 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 Reference [3], [4] [3], [4] Element Direction AN -> PCF AN -> PCF M O R Type

35

36 37 38

A-6

3GPP2 A.S0022-0 v1.0

Information Element Correlation ID Mobile Identity (IMSI/ATI) 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 Sector ID Security Layer Packet System Time HRPD A9 Indicators Anchor PDSN Address Anchor P-P Address SR_ID Mobile Identity (MEID) Additional A8 Traffic ID Forward QoS Information Reverse QoS Information Assigning SC IP Address Timers eHRPD A9 Indicators EPS Information
1 2 3 4 5 6 7 8 9 10 11 12

Section Reference [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [4] [4] [4] [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [4] [4] 4.2.2 4.2.3

Element Direction AN -> PCF AN -> PCF AN -> PCF AN -> PCF BS -> PCF AN -> PCF AN -> PCF AN -> PCF AN -> PCF BS -> PCF BS -> PCF AN -> PCF AN -> PCF AN -> PCF AN -> PCF AN -> PCF AN -> PCF BS -> PCF BS -> PCF AN -> PCF AN -> PCF AN -> PCF AN -> PCF AN -> PCF AN -> PCF AN -> PCF eAN -> ePCF eAN -> ePCF Oa O O O O O O O O O O O O O O O O O O O O O O O O O
d e f g m n o n,s k b l c

Type C R C R C R R R R C C C C C C C C C C C C C C C C C C C

Op
h i j b q,t r,t r,t u u v,w v

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 AT. Inclusion of ESN, Mobile Equipment Identity (MEID) or both in this message is a network operator decision. c. For 1x systems, 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 and eHRPD messages. d. The User Zone ID is included if received from the MS. This IE shall not be included in HRPD and eHRPD messages. A-7

3GPP2 A.S0022-0 v1.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

e. For 1x systems, 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 and eHRPD messages. f. The Previous Access Network Identifiers are included if received from the AT or the MSC. g. This is the A11 interface IP address of the source PDSN or HSGW. In 1x systems, this 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 and eHRPD 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. For 1x systems, 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 and eHRPD messages. i. For 1x systems, 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 and eHRPD messages. This element specifies the SR_ID of the service instance in the Service Option element. In HRPD and eHRPD 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 and eHRPD systems, the IS-2000 CON_REF field of this IE shall be set to 00H for padding.

j.

k. The IMSI shall be included in 1x systems. In HRPD and eHRPD messages UATI32 shall be used. l.

m. This IE shall not be included in 1x systems. In HRPD and eHRPD messages, the AN shall include this IE which indicates the sector where the AN receives message from the AT. n. This IE shall not be included in 1x systems. In HRPD and eHRPD messages, the AN shall include this IE if the security layer packet has to be validated and the AN cannot validate security layer packet received from the AT. o. This IE is used to validate the security layer packet included in this message. p. This IE shall not be included in 1x systems. In HRPD and eHRPD messages, the ePCF assumes that all indicators are set to 0 if this IE is not included in the message. q. In HRPD and eHRPD 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. r. In HRPD and eHRPD 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. In HRPD and eHRPD systems, this is the service option of the main service connection. This IE is included if the information is available at the AN.

s. t.

u. This IE is included if available when the target AN sends the A9-Setup-A8 message in case of active handoff. This IE is not included in HRPD or eHRPD systems with SC/MM in the AN. v. This IE is included if the eAN receives EPS parameters over S101 interface in case of E-UTRAN to eHRPD pre-registration and handoff execution. w. This IE is included with the PMK Indicator set to 1 if the eAN supports GKE and is requesting PMK information from the HSGW. This IE is not required for a system with SC/MM in the ePCF.

A-8

3GPP2 A.S0022-0 v1.0

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/ATI): A9 Element Identifier = [0DH] Length = [06H-08H] (10-15 digits) Identity Digit 1 = [0H-9H] (BCD) Odd/even Type of Identity = [110 (IMSI) Indicator = 111 (ATI)] = [1,0] Identity Digit 2 = [0H-9H] (BCD) 6 1 2 3

A9 Message Type = [01H] A9 Element Identifier = [3FH] Length = [08H] Market ID = <any value>

Call Connection Reference:

Identity Digit 3 = [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) History Ind = [0H (Current)] (MSB) (MSB) Identity Digit N = [0H-9H] (BCD) Identity Digit N+2 = [0H-9H] (BCD)

n n+1

ATI Type = [2H (UATI 32)] (LSB) UATI024 = <any value> (LSB)

n+2 n+3 n+4 n+5 n+6 1 2

UATIColorCode = <any value>

Mobile Identity (ESN): A9 Element Identifier = [0DH] Length = [05H]

A-9

3GPP2 A.S0022-0 v1.0

3.1.1 7 6 5 4 Identity Digit 1 = [0000]

A9-Setup-A8 3 Odd/even Indicator = [0] 2 1 0 Octet 3 Type of Identity = [101] (ESN)

(MSB)

ESN = <any value>

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 10 11 12 13 (LSB) 14 1 2

CON_REF:

A9 Element Identifier = [01H]

Length = [01H] IS-2000 CON_REF = [00H FFH] Quality of Service Parameters: Reserved = [0000] A9 Cell Identifier: A9 Element Identifier = [07H] Length = [01H] Non-Assured Mode Packet Priority = [0000 1101] A9 Element Identifier = [06H] Length = [06H] Cell Identification Discriminator = [07H] (MSB) MSCID = <any value>

(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>

Address Type = [01H] (IPv4) (MSB) IP Address = <any value>

(MSB)

Service Option: A9 Element Identifier = [03H] Service Option

A-10

3GPP2 A.S0022-0 v1.0

3.1.1 7 6 5 4

A9-Setup-A8 3 2 1 0 (LSB) Octet 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)] for HRPD systems QoS Mode = [0, 1] A9 Indicators: A9 Element Identifier = [05H] Length = [02H] Packet GRE Boundary Segment. Supported Supported = [0] = [0,1] (ignored) Reserved =0 (MSB) Reserved =0 SDB/DoS Supported = [0,1] CCPD Mode = [0,1] Emergency Data Services = Ready [0,1] Indicator = [0,1] Reserved Reserved =0 =0

1 2 Handoff Indicator = [0, 1] 3

Reserved =0

Reserved =0

Reserved =0

Buffer Transfer = [0, 1]

User Zone ID:

A9 Element Identifier = [02H]

1 2 3 (LSB) 4 1 2 3 4

Length = [02H] UZID = <any value> IS-2000 Service Configuration Record: Reserved = [0000 0] (MSB) IS-2000 Service Configuration Record Content = <any value> Seventh Fill Bit if needed = [0 (if used as a fill bit)]
Reserved = [0]

A9 Element Identifier = [0EH] Bit-Exact Length Fill Bits = [000 111]

Bit-Exact Length Octet Count = <variable>

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:

A9 Element Identifier = [20H] SID = <any value> (LSB)

1 2 3 4 5 (LSB) 6 7 1 2 3 4

Length = [05H] (MSB)

(MSB)

NID = <any value> PZID = <any value> PDSN Address: A9 Element Identifier = [14H] Length = [04H] PDSN Address = <any value>

(MSB)

A-11

3GPP2 A.S0022-0 v1.0

3.1.1 7 6 5 4

A9-Setup-A8 3 2 1 0 (LSB) Octet 5 6 1 2 3 4 5

Sector ID:

A9 Element Identifier = [88H] Length = [11H]

Sector ID Discriminator = [01H (Sector ID128)] (MSB) Sector ID = <any value>

(LSB) (MSB) Security Layer Packet: A9 Element Identifier = [89H] Length = [variable] Security Layer Packet

19 1 2 3 4

(LSB) (MSB) System Time: A9 Element Identifier = [8CH] Length = [08H] CDMA System Time = <any value>

n 1 2 3 4

(LSB) HRPD A9 Indicators: Reserved = [0000 0] A9 Element Identifier = [8BH] Default Session Handoff Session Information Type = [0, 1] Indicator = Required = [0] [0, 1] Length = [04H] (MSB) Anchor PDSN Address = <any value> Length = [01H]

10 1 2 3

Anchor PDSN Address: A9 Element Identifier = [30H]

1 2 3 4 5 (LSB) 6 1 2 3 4 5

(MSB)

Anchor P-P Address:

A9 Element Identifier = [40H]

Length = [04H] Serving P-P IP Address = <any value>

A-12

3GPP2 A.S0022-0 v1.0

3.1.1 7 6 5 4

A9-Setup-A8 3 2 1 0 (LSB) Octet 6 1 2 3 1 2 Type of Identity = [001] (MEID) 3

SR_ID: A9 Element Identifier = [0BH] Length = [01H] SR_ID = [01H 1FH]

Mobile Identity (MEID): A9 Element Identifier = [0DH] Length = [08H] Odd/Even Indicator = 0

MEID Hex Digit 1 = [0H-FH]

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 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) for HRPD and eHRPD, 00 43H (HRPD Auxiliary Service Connection without higher layer framing for packet synchronization) for HRPD and eHRPD, 00 48H (HRPD auxiliary Packet Data IP Service with PDN multiplexing header) for eHRPD] (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)

n+15

A-13

3GPP2 A.S0022-0 v1.0

3.1.1 7 6 5 4 Forward ROHC Info{1:

A9-Setup-A8 3 2 1 0 Octet p p+1 (LSB) p+2 p+3 (LSB) p+4 p+5

Forward ROHC Info Length = <variable> (MSB) (MSB) Large CIDs = [0,1] Forward Profile { Forward ProfileCount: (MSB) Forward Profile = <any value encoded as specified in Internet Assigned Numbers Authority [33] (LSB) } Forward Profile } Forward ROHC Info Reverse ROHC Info{1: Reverse ROHC Info Length = <variable> (MSB) (MSB) Reverse Large CIDs = [0,1] Reverse Profile { Reverse ProfileCount: (MSB) Reverse Profile = <any value encoded as specified in Internet Assigned Numbers Authority [33] (LSB) } 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] Reverse MaxCID = <any value> (LSB) Reverse MRRU = <any value> (LSB) Reserved = [000 0000] Forward MaxCID = <any value> Forward MRRU = <any value> Reserved = [000 0000]

Forward ProfileCount = <any value>

p+6 q q+1

p p+1 p+2 p+3 p+4 p+5

Reverse ProfileCount = <any value>

p+6 q q+1

1 2 j j+1

A-14

3GPP2 A.S0022-0 v1.0

3.1.1 7
Use IP Flow Discrimination = [0,1]

A9-Setup-A8 3 2 1 0 Octet j+2 Reserved = [00 0000]

6 DSCP Included = [0,1] Reserved = [000]

Forward Flow Count = [1 31] Entry Length = [variable] Forward Flow ID = [00H FFH]

j+3 k k+1 Flow State = [0, 1] k+2

Forward Flow Entry { Forward Flow Count :

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] 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

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

A-15

3GPP2 A.S0022-0 v1.0

3.1.1 7 6 5 4

A9-Setup-A8 3 2 1 0 Octet

(LSB) } Reverse Flow Entry } Reverse QoS Information Entry (MSB) Assigning SC IP Address: A9 Element Identifier = [96H] Length = [04H] Assigning SC IP Address

1 2 3 4 5 (LSB) 6 1 2 n n+1 n+2 n+3 n+4 n+5 (LSB) n+6 1 2 Tunnel Mode = [0, 1] 3

Timer { 1:

Timers: A9 Element Identifier = [97H] Length = [04H] Timer Type = [01H (Tsclose) ] Timer Length = [05H]

(MSB)

Starting Time

} Timer eHRPD A9 Indicators: Reserved = [0000 0] A9 Element Identifier = [98H] PMK = [0, 1] Handoff Execution = [0, 1] Length = [01H]

PDN Information { 1+:

EPS Information: A9 Element Identifier = [99H] Length = [variable] PDN Information Entry Length = [variable]

1 2 n n+1 n+2 n+3 n+4 (LSB) p

APN Information { 0-1: Parameter Type = [01H (APN Information) ] Parameter Length = [variable] (MSB) APN

} APN Information

A-16

3GPP2 A.S0022-0 v1.0

3.1.1 7 6 5 4 S103 Source GRE Key Information { 0-1:

A9-Setup-A8 3 2 1 0 Octet n n+1 n+2 n+3 (LSB) p

Parameter Type = [02H (S103 Source GRE Key Information)] Parameter Length = [04H] (MSB) S103 Source GRE Key

} S103 Source GRE Key Information P-GW IP Address { 0-1: Parameter Type = [03H (P-GW IP Address) ] Parameter Length = [variable] Address Type = [01H (IPv4 Address), 02H (IPv6 Address)] (MSB) P-GW IP Address (LSB) } P-GW IP Address } PDN Information
1

n n+1 n+2 n+3 n+4 p

3.1.2

A9-Connect-A8

This message is sent from the PCF to the AN to complete the setup of the A8 connection.
Information Element A9 Message Type Call Connection Reference Correlation ID Mobile Identity (IMSI/ATI) Mobile Identity (ESN) CON_REF A8 Traffic ID Cause PDSN Address Session State Information Record Anchor PDSN Address Anchor P-P Address SR_ID Service Instance Info Section Element Direction Reference [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [4] [3], [4] [3], [4] [3], [4] [3], [4] PCF -> AN PCF -> AN PCF -> AN PCF -> AN PCF -> AN PCF -> AN PCF -> AN PCF -> AN PCF -> AN PCF -> AN PCF -> BS PCF -> BS PCF -> AN PCF -> BS M O O O O O O O O O O O O O
c j,l d e a h b i

Type

R C R C R R R C C C C C C

f g

A-17

3GPP2 A.S0022-0 v1.0

Information Element Mobile Identity (MEID) Extended Session State Information Record Additional A8 Traffic ID A9 Indicators Subscriber QoS Profile ROHC Configuration Parameters Mobile Identity (IMSI) Assigning SC IP Address HSGW 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

Section Element Direction Reference [3], [4] [4] [3], [4] [3], [4] [3], [4] [3], [4] [4] [4] 4.2.4 PCF -> AN PCF -> AN PCF -> AN PCF -> AN PCF -> AN PCF -> AN PCF -> AN PCF -> AN ePCF -> eAN Ob O O O O O O O

Type C C C C C C C C C

k,l,m n o p q r s t,u

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 AT. 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 or HSGW 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 AN, and included in the Handoff Required message in the event of a hard handoff. In HRPD and eHRPD messages in systems with SC/MM in the PCF, the PDSN or HSGW Address field of this IE shall be set to 00 00 00 00H for padding. d. For 1x systems, 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 and eHRPD messages. e. For 1x systems, 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 and eHRPD messages. f. In 1x systems, this element specifies the SR_ID of the connected service instance. In HRPD and eHRPD 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. For 1x systems, 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-Setup-A8 message was set to 1). This IE shall not be included for HRPD and eHRPD messages. h. The IMSI shall be included in 1x systems. In HRPD and eHRPD messages, UATI32 shall be used. i. The IS-2000 CON_REF field of this IE shall be set to 00H for padding, in HRPD and eHRPD messages. A-18

3GPP2 A.S0022-0 v1.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

j.

This IE shall not be included in 1x systems. In HRPD and eHRPD messages, this IE shall be included when the PCF decides that session information needs to be transferred to the AN. Multiple instances of this IE may be included, where one instance of this IE contains one SSIR as specified in C.S0087 [24].

k. This IE is included when the information on multiple personalities is available. Multiple instances of this IE may be included, where one instance of this IE contains one SSIR for an HRPD and eHRPD personality that is not the main personality, as specified in C.S0087 [24]. Multiple instances of this IE shall be sorted in order of increasing personality index. l. 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). This IE is not included in HRPD or eHRPD systems with SC/MM in the AN.

m. 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. n. 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. o. This IE shall be included if the PCF has enabled packet boundary indications. p. This IE is included if this information is available. q. This IE is included if this information is received from the PDSN or HSGW. It conveys the ROHC configuration parameters supported by the PDSN or HSGW when using ROHC on SO67 with header compression at the PDSN or HSGW. r. s. This IE shall only be included for session transfer over A16 interface in HRPD and eHRPD messages, and shall include IMSI. This IE is not included in HRPD or eHRPD systems with SC/MM in the AN. This IE shall be included when the PCF that sends this message manages LCM_UATI and indicates IP address of SC managing LCM_UATI. Otherwise, this IE shall not be included. This IE is not included in HRPD or eHRPD systems with SC/MM in the AN. This IE is included if the ePCF receives HSGW parameters over A11 interface in case of E-UTRAN to eHRPD handoff execution while A8 connection is disconnected.

t.

u. This IE is included if the ePCF receives PMK information from the HSGW. 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

32

A9 Message Type = [02H] A9 Element Identifier = [3FH] Length = [08H] Market ID = <any value>

Call Connection Reference:

A-19

3GPP2 A.S0022-0 v1.0

3.1.2 7 6 5 4

A9-Connect-A8 3 2 1 0 (LSB) Octet 9 10 1 2 3 4 5 (LSB) 6 1 2 3

(MSB)

Correlation ID: A9 Element Identifier = [13H] Length = [04H] Correlation Value = <any value>

Mobile Identity (IMSI/ATI): A9 Element Identifier = [0DH] Length = [06H-08H] (10-15 digits) Odd/even Type of Identity = [110 (IMSI) Indicator = 111 (ATI)] = [1,0] Identity Digit 2 = [0H-9H] (BCD)

Identity Digit 1 = [0H-9H] (BCD)

Identity Digit 3 = [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) History Ind = [0H (Current)] (MSB) (MSB) Identity Digit N = [0H-9H] (BCD) Identity Digit N+2 = [0H-9H] (BCD)

n n+1

ATI Type = [2H (UATI 32)] (LSB) UATI024 = <any value> (LSB)

n+2 n+3 n+4 n+5 n+6 1 2 3

UATIColorCode = <any value>

Mobile Identity (ESN): A9 Element Identifier = [0DH] Length = [05H] Odd/even Indicator = [0] ESN = <any value> Type of Identity = [101] (ESN)

Identity Digit 1 = [0000]

(MSB)

4 5 6 (LSB) 7 1 2 3 1 2 3

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)

A-20

3GPP2 A.S0022-0 v1.0

3.1.2 7 (MSB) (MSB) 6 5 4

A9-Connect-A8 3 2 1 0 (LSB) Octet 4 5 6 7 8 (LSB) 9 10 11 12 13 (LSB) 14 1 2 3

Protocol Type = [88 81H] (Unstructured byte stream) Key = <any value>

Address Type = [01H] (IPv4) (MSB) IP Address = <any value>

ext = [0]

Cause: A9 Element Identifier = [04H] Length = [01H] Cause Value = [13H (Successful operation), 7AH (Data ready to send)]

(MSB)

PDSN Address: A9 Element Identifier = [14H] Length = [04H] PDSN Address = <any value>

1 2 3 4 5 (LSB) 6 1 2 (LSB) 3 4

(MSB) (MSB)

Session State Information Record: Length = [variable]

A9 Element Identifier = [8AH]

Session State Information Record

(LSB) (MSB) Anchor PDSN Address: A9 Element Identifier = [30H] Length = [04H] Anchor PDSN Address = <any value> n 1 2 3 4 5 (LSB) (MSB) Anchor P-P Address: A9 Element Identifier = [40H] Length = [04H] Anchor P-P Address = <any value> 6 1 2 3 4

A-21

3GPP2 A.S0022-0 v1.0

3.1.2 7 6 5 4

A9-Connect-A8 3 2 1 0 (LSB) Octet 5 6 1 2 3 1 2 SR_ID-3 = [0,1] SR_ID-2 = [0,1] SR_ID-1 = [0,1] 3 4

SR_ID: A9 Element Identifier = [0BH] Length = [01H] SR_ID = [01H 1FH]

Service Instance Info: Reserved=[0000 0]

A9 Element Identifier = [41H]

Length = [00-0FH]

(MSB)

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

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] (MSB) Reserved (MSB)

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] Length = [variable] (LSB) Personality Index

4 5 6 7 8 9 10 1 2 3 4 5

Extended Session State Information Record: A9 Element Identifier = [8DH]

Session State Information Record

(LSB) Additional A8 Traffic ID: A9 Element Identifier = [92H] n 1

A-22

3GPP2 A.S0022-0 v1.0

3.1.2 7 6 5 4

A9-Connect-A8 3 2 1 0 Octet 2 n n+1 n+2

Length = [variable] 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) for HRPD and eHRPD, 00 43H (HRPD Auxiliary Service Connection without higher layer framing for packet synchronization) for HRPD and eHRPD, 00 48H (HRPD auxiliary Packet Data IP Service with PDN multiplexing header) for eHRPD] (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) } A8 Traffic ID Entry A9 Indicators: A9 Element Identifier = [05H] Length = [01H] QoS Packet GRE Mode = Boundary Segment [0] Supported Supported [0,1] (ignored) = [0] (ignored) (MSB) SDB/DoS Supported = [0] (ignored) CCPD Emergency Data Mode = Services = Ready [0] [0] Indicator = [0] (ignored) (ignored) (ignored) Handoff Indicator = [0] (ignored)

n+15 1 2 3

Subscriber QoS Profile: A9 Element Identifier = [90H] Length = [variable] Subscriber QoS Profile

1 2 3 4

(LSB) (MSB) ROHC Configuration Parameters: A9 Element Identifier = [93H] Length = [variable] MaxCID = <any value>

n 1 2 3

A-23

3GPP2 A.S0022-0 v1.0

3.1.2 7 (MSB) Large CIDs = [0,1] Profile { ProfileCount: (MSB) } Profile 6 5 4

A9-Connect-A8 3 2 1 0 (LSB) Octet 4 5 (LSB) 6 7

MRRU = <any value> Reserved = [000 0000]

ProfileCount = <any value> Profile = <any value encoded as specified in C.S0057 [19] (LSB) Mobile Identity (IMSI): A9 Element Identifier = [0DH] Length = [06H-08H] (10-15 digits) Identity Digit 1 = [0H-9H] (BCD) Odd/even Type of Identity = [110 (IMSI)] Indicator = [1,0] Identity Digit 2 = [0H-9H] (BCD)

8 p p+1 1 2 3

Identity Digit 3 = [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) (MSB) Identity Digit N = [0H-9H] (BCD) Identity Digit N+2 = [0H-9H] (BCD)

n n+1

Assigning SC IP Address: A9 Element Identifier = [96H] Length = [04H] Assigning SC IP Address

1 2 3 4 5 (LSB) 6 1 2 n n+1 n+2 n+3 (LSB) p n

HSGW Information: A9 Element Identifier = [9AH] Length = [variable]

HSGW S103 Information { 0-1: Parameter Type = [01H (T-HSGW S103 IP Address) ] Parameter Length = [variable] Address Type = [01H (IPv4 Address), 02H (IPv6 Address)] (MSB) T-HSGW S103 IP Address

Parameter Type = [02H (T-HSGW S103 Key) ]

A-24

3GPP2 A.S0022-0 v1.0

3.1.2 7 (MSB) 6 5 4

A9-Connect-A8 3 APN 2 1 0 Octet n+1 n+2 (LSB) p p+1 p+2 p+3 (LSB) p+4

Parameter Length = [variable]

(MSB) T-HSGW S103 Key

} HSGW S103 Information HSGW H1 Information { 0-1: Parameter Type = [03H (HSGW H1 Address Information) ] Parameter Length = [05H] Address Type = [01H (IPv4 Address)] (MSB) HSGW H1 IP Address (LSB) } HSGW H1 Information PMK Information { 0-1: Parameter Type = [04H (PMK Information)] Parameter Length = [variable] PMK Count = <any value> PMK { PMK Count+1: PMK Length = [variable] (MSB) PMK = <any value> (LSB) (MSB) PMK Lifetime = <any value> p p+1 q q+1 q+2 q+3 (LSB) } PMK } PMK Information
1

n n+1 n+2 n+3 n+4 n+5 n+6

n n+1 n+2

q+4

3.2.1 A9-Release-A8 This message is sent from the eAN to the ePCF to release an A8 connection. In HRPD systems, this message shall be used when performing any additions, deletions, remappings, and/or changes in granted A-25

3 4

3GPP2 A.S0022-0 v1.0

1 2 3

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 eHRPD A9 Indicators Section Element Direction Reference [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] 4.2.2 AN -> PCF AN -> PCF AN -> PCF AN -> PCF AN -> PCF AN -> PCF AN -> PCF AN -> PCF AN -> PCF AN -> PCF AN -> PCF AN -> PCF AN -> PCF AN -> PCF eAN -> ePCF M O 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 k

Type

R C R C R R R R C C C C C C

4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26

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 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 ePCF 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, this 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 ePCF should not stop data transmission over A8 connections indicated by this IE. Multiple instances of this IE may be included in the message.

A-26

3GPP2 A.S0022-0 v1.0

1 2 3 4 5 6 7 8 9

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.

k. This IE is included if the eAT is connected to the eHRPD system via the S101 tunnel.

10

The following table shows the bitmap layout for the A9-Release-A8 message.
3.2.1 A9-Release-A8 7 (MSB) (MSB) (MSB) 6 5 4 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 A9 Message Type = [04H] A9 Element Identifier = [3FH] Length = [08H] Market ID = <any value>

Call Connection Reference:

Identity Digit 3 = [0H-9H] (BCD)

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

Mobile Identity (ESN): A9 Element Identifier = [0DH]

A-27

3GPP2 A.S0022-0 v1.0

3.2.1 A9-Release-A8 7 6 5 4 3 Odd/even Indicator = [0] ESN = <any value> 2 1 Type of Identity = [101] (ESN) 0 Octet 2 3 Length = [05H] Identity Digit 1 = [0000]

(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 3

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) Key = <any value>

Address Type = [01H] (IPv4) (MSB) IP Address = <any value>

ext = [0]

Cause: A9 Element Identifier = [04H] Length = [01H] 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)]

(MSB)

Active Connection Time in Seconds: Length = [04H]

A9 Element Identifier = [0AH]

1 2 3

Active Connection Time = [00 00 00 00H FF FF FF FFH]

A-28

3GPP2 A.S0022-0 v1.0

3.2.1 A9-Release-A8 7 6 5 4 3 2 1 0 Octet 4 5 (LSB) SR_ID: A9 Element Identifier = [0BH] Length = [01H] SR_ID = [01H 1FH] Mobile Identity (MEID): A9 Element Identifier = [0DH] Length = [08H] MEID Hex Digit 1 = [0H-FH] Odd/Even Indicator = 0 Type of Identity = [001] (MEID) 6 1 2 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 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) 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

A-29

3GPP2 A.S0022-0 v1.0

3.2.1 A9-Release-A8 7 6 5 4 3 2 1 0 (LSB) } A8 Traffic ID Entry (MSB) Forward QoS Information: A9 Element Identifier = [8EH] Length = [variable] (LSB) Forward QoS Information Entry { 1-31: (MSB) Entry Length = [variable] (LSB) 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 j+3 1 2 3 Octet n+14 n+15

Forward Flow Count = [1 31]

j+4

Forward Requested QoS Length = [variable] (MSB) Forward Requested QoS = <any value>

k+2 k+3

(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 (MSB) Reverse QoS Information: A9 Element Identifier = [8FH] Length = [variable] (LSB) Reverse QoS Information Entry { 1-31: (MSB) Entry Length = [variable] (LSB) SR_ID = [01H-1FH] Reserved = [000] Reverse Flow Count = [1 31]

1 2 3 j j+1 j+2 j+3

A-30

3GPP2 A.S0022-0 v1.0

3.2.1 A9-Release-A8 7 6 5 4 3 2 1 0 Octet k k+1 Flow State = [0, 1] k+2 Reverse Flow Entry { Reverse Flow Count : Entry Length = [variable] Reverse Flow ID = [00H FFH] Reserved = [0000 000]

Reverse Requested QoS Length = [variable] (MSB) Reverse Requested QoS = <any value>

k+2 k+3

(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 eHRPD A9 Indicators: A9 Element Identifier = [98H] Length = [01H] Reserved = [0000 0] PMK = [0, 1] (ignored) Handoff Execution = [0, 1] (ignored) Tunnel Mode = [0, 1]

1 2 3

3.5 A9 Session Update Procedures

2 3

3.5.1

A9-Update-A8

5 6 7 8 9 10 11 12

This message is sent from the AN to the PCF to indicate a change to the session airlink parameters, whether SDBs may be sent to an AT, whether an SDB was successfully delivered to an AT, or to indicate an authentication failure. This message is also sent from the PCF to the AN to transfer new or updated packet data session parameters to the AN. In HRPD and eHRPD 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 and eHRPD systems, this message is also used to support QoS update by the PDSN or HSGW.
Information Element A9 Message Type Section Reference [3], [4] Element Direction AN <-> PCF M Type

A-31

3GPP2 A.S0022-0 v1.0

Information Element Call Connection Reference Correlation ID Mobile Identity (IMSI/ATI) 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 Reverse QoS Information Subscriber QoS Profile Forward QoS Update Information Reverse QoS Update Information eHRPD A9 Indicators EPS Information HSGW Information
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

Section Reference [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] 4.2.2 4.2.3 4.2.4

Element Direction AN <-> PCF AN <-> PCF AN <-> PCF AN -> PCF BS -> PCF AN -> PCF BS -> PCF BS -> PCF AN <-> PCF AN <- PCF AN <-> PCF AN -> PCF AN <-> PCF PCF -> AN PCF -> BS PCF -> BS AN -> PCF AN -> PCF PCF -> AN PCF -> AN PCF -> AN eAN -> ePCF eAN -> ePCF ePCF -> eAN O O O O O O O O O O O O O O O O O O O O O O O
d e b a i b c,j c,l c,j c,j

Type R C R C C C C C R C C C C C C C C C C C C C C C

f g h,j h,j k k h m,n m,n o o p

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 AT. 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 AN 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 or HSGW has sent the parameter to the PCF. e. In 1x systems, this element specifies the SR_ID of the service instance in the Service Option element. In HRPD and eHRPD 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.

A-32

3GPP2 A.S0022-0 v1.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

g. This element contains the A11 IP address of the PDSN or HSGW terminating the A10 connection. This element is included when A10 connections were established with a new PDSN or HSGW 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 and eHRPD messages This IE shall not be included in HRPD and eHRPD messages.

k. In HRPD and eHRPD 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 and eHRPD systems, this IE shall contain information for the main service connection. m. In HRPD and eHRPD systems, this IE is used when the PDSN or HSGW 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 and eHRPD 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 or HSGW should not use this procedure for flow ID FFH and FEH. o. This IE is included if the eAN receives EPS parameters over S101 interface in case of E-UTRAN to HRPD handoff. p. In eHRPD systems, this IE is used to send PMK Information when it is received by the ePCF in an A11-Session Update message.

31

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

A9 Message Type = [0EH] A9 Element Identifier = [3FH] Length = [08H] Market ID = <any value>

Call Connection Reference:

A-33

3GPP2 A.S0022-0 v1.0

3.5.1 7 6 (MSB) 5 4

A9-Update-A8 3 2 1 0 (LSB) Octet 10 1 2 3 4 5 (LSB) 6 1 2 Type of Identity = [110 (IMSI), 111 (ATI)] 3

Correlation ID: A9 Element Identifier = [13H] Length = [04H] Correlation Value = <any value>

Mobile Identity (IMSI/ATI): A9 Element Identifier = [0DH] Length = [06H-08H] (10-15 digits) Odd/even Indicator = [1,0]

Identity Digit 1 = [0H-9H] (BCD)

Identity Digit 3 = [0H-9H] (BCD)

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) History Ind = [0H (Current)] (MSB) (MSB) Identity Digit N = [0H-9H] (BCD) Identity Digit N+2 = [0H-9H] (BCD)

n n+1

ATI Type = [2H (UATI 32)] (LSB)

n+2 n+3 n+4 n+5 (LSB) n+6 1 2 3

UATIColorCode = <any value> UATI024 = <any value>

Mobile Identity (ESN): A9 Element Identifier = [0DH] Length = [05H] Odd/even Indicator = [0] ESN = <any value> Type of Identity = [101] (ESN)

Identity Digit 1 = [0000]

(MSB)

4 5 6 (LSB) 7 1 2 3 4

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>

A-34

3GPP2 A.S0022-0 v1.0

3.5.1 7 6 Seventh Fill Bit if needed = [0 (if used as a fill bit)] 5 Sixth Fill Bit if needed = [0 (if used as a fill bit)] 4 Fifth Fill Bit if needed = [0 (if used as a fill bit)]

A9-Update-A8 3 Fourth Fill Bit if needed = [0 (if used as a fill bit)] 2 Third Fill Bit if needed = [0 (if used as a fill bit)] 1 Second Fill Bit if needed = [0 (if used as a fill bit)] 0 First Fill Bit if needed = [0 (if used as a fill bit)] Octet 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)] for HRPD and eHRPD systems (MSB) User Zone ID: A9 Element Identifier = [02H] Length = [02H] UZID = <any value>

1 2 3 (LSB) 4 1 2 3 1 2 3

Quality of Service Parameters: Reserved = [0000]

A9 Element Identifier = [07H]

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] Mobile Identity (MEID): A9 Element Identifier = [0DH] Length = [08H]

1 2 3 1 2 3 1 2

A-35

3GPP2 A.S0022-0 v1.0

3.5.1 7 6 5 4 MEID Hex Digit 1 = [0H-FH]

A9-Update-A8 3 Odd/Even Indicator = 0 2 1 Type of Identity = [001] (MEID) 0 Octet 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] Length = [01H]

4 5 6 7 8 9 10 1 2 Handoff Indicator = [0,1] 3

A9 Indicators: A9 Element Identifier = [05H] CCPD Emergency Data Mode = Services = Ready [0,1] [0,1] Indicator = [0,1] (Ignored) (Ignored)

GRE SDB/DoS QoS Packet Mode Boundary Segment. Supported = [0,1] [0,1] Supported Supported [0,1] (Ignored) [0,1] (Ignored) (Ignored) (MSB)

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 j

(MSB)

Anchor P-P Address:

A9 Element Identifier = [40H]

Length = [04H] Serving P-P IP Address = <any value>

Forward QoS Information: A9 Element Identifier = [8EH] Length = [variable]

Forward QoS Information Entry { 1-31: Entry Length = [variable]

A-36

3GPP2 A.S0022-0 v1.0

3.5.1 7 Use IP Flow Discrim ination = [0,1] 6 DSCP Included= [0,1] 5 4

A9-Update-A8 3 2 1 0 Octet j+1 j+2

SR_ID = [01H-1FH] 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

DSCP

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] 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

Reverse Requested QoS Length = [variable] (MSB) Reverse Requested QoS = <any value>

k+3 k+4

(LSB) Reverse Granted QoS Length = [variable]

m m+1

A-37

3GPP2 A.S0022-0 v1.0

3.5.1 7 (MSB) 6 5 4

A9-Update-A8 3 2 1 0 Octet m+2

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

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 eHRPD A9 Indicators: A9 Element Identifier = [98H] Length = [variable] Reserved = [0000 0] PMK = [0, 1] Handoff Execution = [0, 1] Tunnel Mode = [0, 1]

m 1 2 3

EPS Information: A9 Element Identifier = [99H] Length = [variable]

1 2

A-38

3GPP2 A.S0022-0 v1.0

3.5.1 7 6 5 4 PDN Information { 1+:

A9-Update-A8 3 2 1 0 Octet n n+1 n+2 n+3 n+4 (LSB) p

PDN Information Entry Length = [variable] APN Information { 0-1: Parameter Type = [01H (APN Information) ] Parameter Length = [variable] (MSB) APN

} APN Information S103 Source GRE Key Information { 0-1: Parameter Type = [02H (S103 Source GRE Key Information)] Parameter Length = [04H] (MSB) S103 Source GRE Key (LSB) } S103 Source GRE Key Information P-GW IP Address { 0-1: Parameter Type = [03H (P-GW IP Address) ] Parameter Length = [variable] Address Type = [01H (IPv4 Address), 02H (IPv6 Address)] (MSB) P-GW IP Address (LSB) } P-GW IP Address } PDN Information HSGW Information: A9 Element Identifier = [9AH] Length = [variable] Parameter Type = [04H (PMK Information)] Parameter Length = [variable] PMK Count = <any value> PMK { PMK Count+1: PMK Length = [variable] (MSB) PMK = <any value> (LSB) p p+1 q 1 2 3 4 5 n+1 n+2 n+3 n+4 n+5 p n+1 n+2 n+3 n+4 p

A-39

3GPP2 A.S0022-0 v1.0

3.5.1 7 (MSB) 6 5 4

A9-Update-A8 3 2 1 0 Octet q+1 q+2 q+3 (LSB) q+4

PMK Lifetime = <any value>

} PMK
1

3.5.2 A9-Update-A8 Ack This message is sent from the PCF to the AN to acknowledge a change to the session airlink parameters. This message is also sent from the AN to the PCF to acknowledge the processing of any new or updated session parameters. In HRPD and eHRPD systems, this message is also used to acknowledge the QoS update. In eHRPD systems, this message is also used to acknowledge receipt of PMK information.
Information Element A9 Message Type Call Connection Reference Correlation ID Cause Mobile Identity (ATI) HSGW Information Section Element Direction Reference [3], [4] [3], [4] [3], [4] [3], [4] [4] 4.2.4 AN <-> PCF AN <-> PCF AN <-> PCF AN -> PCF AN <-> PCF ePCF -> eAN M O O O O
a b c d

3 4 5 6

Type

R C C C C

7 8 9 10 11 12 13 14 15 16

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 AN to the PCF to indicate if the updated session parameter(s), the QoS update, or the PMK information was accepted by the AN. c. This IE shall not be included in 1x systems. In HRPD and eHRPD systems with SC/MM in the PCF,, the AN shall include this IE. d. This IE is included if the ePCF receives HSGW parameters over A11 interface in case of E-UTRAN to eHRPD handoff execution while A8 connection is connected. The following table shows the bitmap layout for the A9-Update-A8 Ack message.
3.5.2 7 (MSB) (MSB) 6 5 4 A9-Update-A8 Ack 3 2 1 0 Octet 1 1 2 3 (LSB) Generating Entity ID = <any value> 4 5

A9 Message Type = [0FH] A9 Element Identifier = [3FH] Length = [08H] Market ID = <any value>

Call Connection Reference:

A-40

3GPP2 A.S0022-0 v1.0

3.5.2 7 (MSB) 6 5 4

A9-Update-A8 Ack 3 2 1 0 (LSB) Octet 6 7 8 9 (LSB) 10 1 2 3 4 5 (LSB) 6 1 2 3

Call Connection Reference = <any value>

(MSB)

Correlation ID: A9 Element Identifier = [13H] Length = [04H] Correlation Value = <any value>

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), 61H (PMK not requested)]

Mobile Identity (ATI): A9 Element Identifier = [0DH] Length = [06H] Odd/even Indicator = [1,0] Type of Identity = [111 (ATI)]

1 2 3

Reserved = [0000]

History Ind = [0H (Current)] (MSB) (MSB)

ATI Type = [2H (UATI 32)] (LSB)

4 5 6 7 (LSB) 8 1 2 n n+1 n+2 n+3 (LSB) p

UATIColorCode = <any value> UATI024 = <any value>

HSGW Information: A9 Element Identifier = [9AH] Length = [variable]

T-HSGW S103 Information { 0-1: Parameter Type = [01H (T-HSGW S103 IP Address) ] Parameter Length = [variable] Address Type = [01H (IPv4 Address), 02H (IPv6 Address)] (MSB) T-HSGW S103 IP Address

A-41

3GPP2 A.S0022-0 v1.0

3.5.2 7 6 5 4

A9-Update-A8 Ack 3 2 1 0 Octet n n+1 n+2 (LSB) p p+1 p+2 p+3 (LSB) p+4

Parameter Type = [02H (T-HSGW S103 Key) ] Parameter Length = [variable] (MSB) APN

(MSB) T-HSGW S103 Key

} HSGW S103 Information HSGW H1 Information { 0-1: Parameter Type = [03H (HSGW H1 Address Information) ] Parameter Length = [05H] Address Type = [01H (IPv4 Address)] (MSB) HSGW H1 IP Address (LSB) } HSGW H1 Information
1

n n+1 n+2 n+3 n+4 n+5 n+6

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

2 3 4 5 6 7 8 9

A9 Information Element Identifiers Sorted by Identifier Value

Identifier 01H 02H 03H 04H 05H 06H 07H 08H Reference [3], [4] [3], [4] [3], [4] 4.2.1 [3], [4] [3], [4] [3], [4] [3], [4]

Element Name

A-42

3GPP2 A.S0022-0 v1.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 Sector ID Security Layer Packet Session State Information Record HRPD A9 Indicators System Time Extended Session State Information Record 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 Assigning SC IP Address Timers eHRPD A9 Indicators EPS Information HSGW Information
1 2

Identifier 09H 0AH 0BH 0CH 0DH 0EH 0FH 13H 14H 20H 30H 31H 3DH 3FH 40H 41H 88H
a a a

Reference [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [4] [4] [4] [4] [4] [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [4] [4] 4.2.2 4.2.3 4.2.4

89H

8AH 8BH 8CH

a a a

8DH

8EH 8FH 90H 91H 92H 93H 94H 95H 96H 97H 98H 99H 9AH

a. This IE is also used in HRPD Systems on the A9 interface.

A-43

3GPP2 A.S0022-0 v1.0

4.1.4

Cross Reference of Information Elements With Messages

2 3

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

Cross Reference of Information Elements with Messages

Reference [3], [4] IEI 08H Used in These Messages A9-Setup-A8 A9-AL Connected A9-AL Disconnected A9-Connect-A8 A9-Disconnect-A8 A9-Release-A8 3.1.1 3.3.1 3.3.3 3.1.2 3.2.3 3.2.1 3.1.1 3.1.2 3.1.1 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

A9 Cell Identifier A9 Indicators

[3], [4] [3], [4]

06H 05H

A9-Setup-A8 A9-Connect-A8 A9-Setup-A8 A9-Short Data Delivery A9-Update-A8

A9 Message Type

[3], [4]

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 Ack A9-Update-A8 A9-Update-A8 Ack A9-Version Info A9-Version Info Ack

A9 PDSN Code

[3], [4]

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

Access Network Identifier Active Connection Time in Seconds Additional A8 Traffic ID

[3], [4] [3], [4] [3], [4]

A-44

3GPP2 A.S0022-0 v1.0

Table 4.1.4-1
Information Element ADDS User Part Anchor P-P Address

Cross Reference of Information Elements with Messages

Reference [3], [4] [3], [4] IEI 3DH 40H Used in These Messages A9-Release-A8 A9-Short Data Delivery A9-Setup-A8 A9-Connect-A8 A9-AL Connected Ack A9-Update-A8 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.1.1 3.1.2 3.3.1 3.3.2 3.3.3 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

Anchor PDSN Address

[3], [4]

30H

A9-Setup-A8 A9-Connect-A8 A9-AL Connected Ack A9-Update-A8

Assigning SC IP Address Call Connection Reference

[4] [3], [4]

96H 3FH

A9-Setup-A8 A9-Connect-A8 A9-AL Connected A9-AL Connected Ack A9-AL Disconnected 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

Cause

4.2.1

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

[3], [4]

01H

A9-Setup-A8 A9-Connect-A8 A9-Disconnect-A8 A9-Release-A8

Correlation ID

[3], [4]

13H

A9-AL Disconnected Ack A9-Short Data Delivery A9-Short Data Ack

A-45

3GPP2 A.S0022-0 v1.0

Table 4.1.4-1
Information Element

Cross Reference of Information Elements with Messages

Reference IEI Used in These Messages A9-Setup-A8 A9-Connect-A8 A9-Disconnect-A8 A9-Release-A8 A9-Release-A8 Complete 3.1.1 3.1.2 3.2.3 3.2.1 3.2.2 3.1.3 3.6.1 3.1.1 3.2.1 3.5.1 3.1.1 3.5.1 3.1.2 3.2.1 3.2.2 3.6.1 3.6.1 3.1.1 3.2.1 3.5.1 3.5.1 3.1.1 3.2.2 3.1.2 3.5.1 3.5.2 3.1.1 3.3.1 3.5.1 3.1.1 3.1.2 3.1.3 3.2.3 3.2.1 3.2.2 3.3.1 3.3.2 3.3.3

Data Count eHRPD A9 Indicators

[3], [4] 4.2.2

09H 98H

A9-BS Service Request A9-Short Data Delivery A9-Setup-A8 A9-Release-A8 A9-Update-A8

EPS Information Extended SSIR

4.2.3 [4]

99H 8DH

A9-Setup-A8 A9-Update-A8 A9-Connect-A8 A9-Release-A8 A9-Release-A8 Complete A9-Short Data Delivery

Flow ID Forward QoS Information

[3], [4] [3], [4]

91H 8EH

A9-Short Data Delivery A9-Setup-A8 A9-Release-A8 A9-Update-A8

Forward QoS Update Information HRPD A9 Indicators HSGW Information

[3], [4] [4] 4.2.4

94H 8BH 9AH

A9-Update-A8 A9-Setup-A8 A9-Release-A8 Complete A9-Connect-A8 A9-Update-A8 A9-Update-A8 Ack

IS-2000 Service Configuration Record

[3], [4]

0EH

A9-Setup-A8 A9-AL Connected A9-Update-A8

Mobile Identity

[3], [4]

0DH

A9-Setup A8 A9-Connect A8 A9-BS Service Request A9-Disconnect-A8 A9-Release-A8 A9-Release-A8 Complete A9-AL Connected A9-AL Connected Ack A9-AL Disconnected

A-46

3GPP2 A.S0022-0 v1.0

Table 4.1.4-1
Information Element

Cross Reference of Information Elements with Messages

Reference IEI Used in These Messages A9-AL Disconnected Ack A9-Short Data Delivery A9-Short Data Ack A9-Update-A8 A9-Update-A8 Ack 3.3.4 3.6.1 3.6.2 3.5.1 3.5.2 3.1.1 3.1.2 3.3.1 3.3.2 3.5.1 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.1 3.2.1 3.6.2 3.1.1 3.6.2 3.1.2 3.1.3 3.1.1 3.3.1 3.5.1 3.1.2 3.2.1 3.2.2 3.6.1 3.6.2 3.4.1 3.4.2 3.1.1 3.1.2 3.2.3

PDSN Address

[3], [4]

14H

A9-Setup-A8 A9-Connect-A8 A9-AL Connected A9-AL Connected Ack A9-Update-A8

Quality of Service Parameters

[3], [4]

07H

A9-Setup-A8 A9-AL Connected A9-Update-A8

Reverse QoS Information

[3], [4]

8FH

A9-Setup-A8 A9-Release-A8 A9-Update-A8

Reverse QoS Update Information RN-PDIT ROHC Configuration Parameters Sector ID

[3], [4] [3], [4] [3], [4] [4]

95H 0FH 93H 88H

A9-Update-A8 A9-Update-A8 A9-Connect-A8 A9-Setup-A8 A9-Release-A8 A9-Short Data Ack

Security Layer Packet Service Instance Info Service Option

[4] [3], [4] [3], [4]

89H 41H 03H

A9-Setup-A8 A9-Short Data Ack A9-Connect-A8 A9-BS Service Request A9-Setup-A8 A9-AL Connected A9-Update-A8

Session State Information Record

[4]

8AH

A9-Connect-A8 A9-Release-A8 A9-Release-A8 Complete A9-Short Data Delivery A9-Short Data Ack

Software Version SR_ID

[3], [4] [3], [4]

31H 0BH

A9-Version Info A9-Version Info Ack A9-Setup-A8 A9-Connect-A8 A9-Disconnect-A8

A-47

3GPP2 A.S0022-0 v1.0

Table 4.1.4-1
Information Element

Cross Reference of Information Elements with Messages

Reference IEI Used in These Messages 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 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 3.6.2 3.1.1 3.3.3 3.1.1 3.3.1 3.5.1

Subscriber QoS Profile System Time Timers User Zone ID

[3], [4] [4] [4] [3], [4]

90H 8CH 97H 02H

A9-Connect-A8 A9-Update-A8 A9-Setup-A8 A9-Short Data Ack A9-Setup-A8 A9-AL Disconnected A9-Setup-A8 A9-AL Connected A9-Update-A8

4.2.1 Cause This element is used to indicate the reason for occurrence of a particular event and is coded as shown below.
4.2.1 7 6 5 4 Length 0/1 Cause Value 3 Cause 2 1 0 Octet 1 2 3

2 3 4

A9 Element Identifier

5 6 7 8 9 10

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.1-1
Binary Values 000 001 010 011 100 Meaning Normal event Normal event Resource unavailable Service or option not available Service or option not implemented

Cause Class

A-48

3GPP2 A.S0022-0 v1.0

Binary Values 101 110 111

1 2

Meaning Invalid message (e.g., parameter out of range) Protocol error Interworking

Table 4.2.1-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 5 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 4 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 1 1 3 0 0 0 0 1 1 1 0 0 0 0 0 0 1 1 1 1 1 1 1 1 0 0 1 1 1 0 0 0 2 0 0 0 1 0 0 1 0 0 0 1 1 1 0 0 0 0 1 1 1 1 0 1 0 1 1 0 0 1 1 0 Hex Value

Cause Values
Cause

1 1 1 1 1

1 1 1 1 1

0 0

0 0

0 0

1 1 0 1 1 0 1 1 0 All other values

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 0 1 11 Service option not available 1 1 13 Successful operation 0 0 14 Normal call release 1 0 16 Initiate re-activation of packet data call 1 1 17 SDB successfully delivered 0 0 18 SDB couldnt be delivered 0 1 19 Power down from dormant state 1 0 1A Authentication failure 1 1 1B Capability update 0 0 1C Update Accounting: late traffic channel setup 0 1 1D Hard handoff failure 1 0 1E Update Accounting: parameter change 1 1 1F Air link lost 1 1 23 Authentication required 0 0 24 Session unreachable 1 1 2B BS resources are not available 0 0 2C Partial QoS updated 1 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 0 1 61 PMK not requested 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.

A-49

3GPP2 A.S0022-0 v1.0

4.2.2

eHRPD A9 Indicators

This IE is used to provide indications related to eHRPD operation.

4.2.2 7 6 5 4 Length Reserved PMK Handoff Execution Tunnel Mode eHRPD A9 Indicators 3 2 1 0 Octet 1 2 3

A9 Element Identifier = [98H]

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 Tunnel Mode

This field contains the number of octets in this IE following this field as a binary number. The field indicates whether or not the eAT is operating on the eHRPD radio, as follows: The Tunnel Mode indication is set to 0 to indicate that the eAT is operating on the eHRPD radio (e.g., the eAT is communicating directly via eHRPD). The Tunnel Mode indication is set to 1 to indicate that the eAT is not operating on the eHRPD radio (e.g., the eAT is communicating via a tunnel from another access technology).

When the eHRPD system supports optimized mobility between eHRPD and E-UTRAN, the eAN includes the Tunnel Mode indication in the A9-Setup-A8 messages sent to the ePCF for an evolved mode session, and sets the value of the Tunnel Mode indication value appropriately. The eAN may not include the Tunnel Mode indication in any A9-Setup-A8 messages sent to the ePCF for an evolved mode session if the eHRPD system does not support optimized mobility between eHRPD and E-UTRAN. The ePCF shall treat the absence of the Tunnel Mode indication from an A9-Setup-A8 message for an evolved mode session the same as Tunnel Mode indication of 0. Handoff Execution This field is set to 1 if the A9 message containing this IE is sent for handoff execution procedure. Otherwise, this field is set to 0. For an evolved mode session, the ePCF shall treat the absence of the E-UTRAN Handoff Info indication the same as Handoff Execution indication of 0. This field is set to 1 if the sending entity supports GKE and is requesting PMK information. Otherwise, this field is set to 0. For an evolved mode session, the ePCF shall treat the absence of the PMK indication the same as PMK indication of 0. EPS Information

PMK

34

4.2.3

35

This IE is used to carry EPS information from the E-UTRAN to the eHRPD RAN.

A-50

3GPP2 A.S0022-0 v1.0

4.2.3 7 6 5 4

EPS Information 3 2 1 0 Octet 1 2 variable variable variable

A9 Element Identifier = [99H] Length PDN Information 1 PDN Information 2 PDN Information N
1 2 3 4

Length PDN Information

This field contains the number of octets in this IE following this field as a binary number. This field contains information about a Packet Data Network to which the eAT is attached.
4.2.3-1 PDN Information 5 4 3 2 1 0 Octet n variable variable variable

PDN Information Entry Length PDN Parameter 1 PDN Parameter 2 PDN Parameter N
5 6 7 8 9

PDN Information Entry Length PDN Parameter

This field contains the number of octets in this entry following this field as a binary number. Each occurrence of this field contains information about a specific attribute of a PDN attachment of the eAT and is coded as follows.
4.2.3-1 PDN Information

Octet n+1 n+2 variable

Parameter Type Parameter Length Parameter Value

10 11

Parameter Type

This field indicates the type of parameter included in the Parameter Value field. The supported types are listed as follows.
PDN Parameter Type 01H 02H 03H All other values Description APN Information S103 Source GRE Key Information P-GW IP Address Reserved

12 13 14 15 16

Parameter Length Parameter Value

This field contains the number of octets in this entry following this field as a binary number. This field contains the specific PDN attribute and is coded as follows. A-51

3GPP2 A.S0022-0 v1.0

1 2

When the Parameter Type is set to 01H (APN Information), the Parameter Value field is coded as follows.
7 6 5 4 APN (LSB) 3 2 1 0 Octet n+3 p

3 4 5 6

APN

This field contains the fully qualified domain name of the access provider as an ASCII character string.

When the Parameter Type is set to 02H (S103 Source GRE Key Information), the Parameter Value field is coded as follows.
7 6 5 4 3 2 1 0 Octet n+4 n+4 n+5 (LSB) n+6 S103 Source GRE Key

7 8 9 10 11

S103 Source GRE Key

This is a four octet field. This field contains the same value that is used in the Key field in the GRE header on the associated connection between P-GW and HSGW or S-GW.

When the Parameter Type is set to 03H (P-GW IP Address), the Parameter Value field is coded as follows.
7 (MSB) 6 5 4 3 P-GW IP Address (LSB) 2 1 0 Octet n+3 p Address Type

12 13 14 15 16 17 18 19 20

Address Type

This field indicates the type and format of the IP address. This field is set to 01H for IPv4 IP address. This field is set to 02H for IPv6 IP address. This field identifies the IP address of the P-GW that terminates the GRE connection between P-GW and HSGW or S-GW. When the Address Type field is set to 01H, this field is coded with 4 octet length to include IPv4 address. When the Address Type field is set to 02H, this field is coded with 16 octet length to include IPv6 address.

P-GW IP Address

21

4.2.4

HSGW Information

22 23

This IE is used to carry HSGW information from the E-UTRAN to the eHRPD RAN and between ePCF and eAN.
4.2.4 7 6 5 4 HSGW Information 3 2 1 0 Octet 1

A9 Element Identifier = [9AH]

A-52

3GPP2 A.S0022-0 v1.0

4.2.4 7 6 5 4

HSGW Information 3 Length 2 1 0 Octet 2 variable variable variable

HSGW Parameter 1 HSGW Parameter 2 HSGW Parameter N

1 2 3

Length HSGW Parameter

7 6 5 4

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.
4.2.4-1 HSGW Parameter 3 2 1 0 Octet n n+1 variable Parameter Type Parameter Length Parameter Value

4 5

Parameter Type

This field indicates the type of parameter included in the Parameter Value field. The supported types are listed as follows.
HSGW Parameter Type 01H 02H 03H 04H All other values Description T-HSGW S103 IP Address T-HSGW S103 Key HSGW H1 Address Information PMK Information Reserved

6 7 8 9 10 11 12

Parameter Length Parameter Value

This field contains the number of octets in this entry following this field as a binary number. This field contains HSGW information and is coded as follows.

When the Parameter Type is set to 01H (T-HSGW S103 IP Address), the Parameter Value field is coded as follows.
7 (MSB) 6 5 4 3 2 1 0 Octet n+2 n+3 (LSB) p Address Type T-HSGW S103 IP Address

13 14 15 16 17 18

Address Type

This field indicates the type and format of the IP address. This field is set to 01H for IPv4 IP address. This field is set to 02H for IPv6 IP address. This field identifies the S103 IP address of the HSGW. When the Address Type field is set to 01H, this field is coded with 4 octet length to include IPv4 address. When the Address Type field is A-53

HSGW S103 IP Address

3GPP2 A.S0022-0 v1.0

1 2 3 4

set to 02H, this field is coded with 16 octet length to include IPv6 address. When the Parameter Type is set to 02H (T-HSGW S103 Key), the Parameter Value field is coded as follows.
7 (MSB) (LSB) (MSB) T-HSGW S103 Key 6 5 4 3 APN 2 1 0 Octet n+2 p p+1 p+2 p+3 (LSB) p+4

5 6 7 8 9 10 11 12 13

APN HSGW S103 Key

This field contains the fully qualified domain name of the access provider as an ASCII character string. This is a four octet field. This field contains the same value that is used in the Key field in the GRE header on the connection from the S-GW to the T-HSGW associated with the specified APN (refer to TS 29.276 [2]).

When the Parameter Type is set to 03H (HSGW H1 Address Information), the Parameter Value field is coded as follows.
7 (MSB) 6 5 4 3 2 1 0 Octet n+2 n+3 (LSB) p Address Type HSGW H1 IP Address

14 15 16 17 18 19 20

Address Type HSGW H1 IP Address

This field indicates the type and format of the IP address. This field is set to 01H for IPv4 address. When Address Type field is set to 01H, this field is coded with 4 octet length to include IPv4 address.

When the Parameter Type is set to 04H (PMK Information), the Parameter Value field is coded as follows.
0 1 2 3 4 5 6 7 Octet n+2 p p+1 (LSB) (MSB) PMK n Lifetime q q+1 q+2

PMK Count PMK n Length (MSB) PMK n

A-54

3GPP2 A.S0022-0 v1.0

7 (LSB)

Octet q+3 q+4

1 2 3 4 5 6 7 8

PMK Count PMK Length PMK PMK Lifetime

This field shall be set to the number of occurrences of the PMK field in this parameter record. This field indicates the length of a PMK in octets. This field contains a PairwiseMasterKey. This field indicates the length of time (in seconds) for which the included PMKs are valid as an unsigned 32-bit binary number.

A-55

3GPP2 A.S0022-0 v1.0

1 2 3 4 5

(This page intentionally left blank)

A-56

3GPP2 A.S0022-0 v1.0

1 2 3 4 5

Annex B

A10-A11 (AN/ePCF - PDSN) Interface Change Text (Normative)

Note: Annex B contains A11 messaging updates to A.S0008 [3] and A.S0009 [4] for eHRPD support. Use of an ellipsis () indicates that the base document is unchanged. For unchanged A11 HRPD messaging, refer to A.S0008 [3] and A.S0009 [4]. Note: Fast handoff as defined in this Annex B applies only to 1x systems.

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).

7 8 9 10

11 12 13 14 15

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 ePCF. For PDSN initiated A10 connection release, the PDSN requests that the ePCF release the connection. For HSGW initiated A10 connection release, the HSGW requests that the ePCF release the connection. 2.1.1 A11-Registration Request

16 17 18 19

This message is sent from the ePCF to the PDSN or HSGW 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 ePCF receives an A9-Setup-A8 message from a BS, the ePCF 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 ePCF 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) ePCF 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 ePCF initiates setup of an A10 connection by sending an A11-Registration Request message to the selected PDSN for legacy mode operation or HSGW for evolved mode operation (refer to section 1.14.3) with a non-zero Lifetime value. After sending this message, the ePCF shall start timer Tregreq. The A11Registration Request message is structured as specified in section 3.1. For evolved mode operation, the ePCF shall include the eHRPD Mode indication when establishing main A10 connection if the HSGW A11 IP address is shared with PDSN. The ePCF should not include the eHRPD Mode indication when establishing main A10 connection if the HSGW A11 IP address is not shared with the PDSN. If the ePCF includes an eHRPD Mode indication in an A11-Registration Request message, the HSGW should ignore it. If the eAT is operating in evolved mode and the eHRPD system supports optimized mobility between the eHRPD and E-UTRAN, then the A11-Registration Request message also includes the eHRPD Indicators NVSE. If the eAT is operating in evolved mode and this message is used for handoff from EUTRAN to eHRPD, then the A11-Registration Request message also includes APN information, if the information is available at the ePCF. If the eAN supports GKE then the A11-Registration Request message also includes the PMK indication. B-1

20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42

3GPP2 A.S0022-0 v1.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

If the connection setup request is accepted by PDSN, the PDSN (for legacy mode operation) creates a binding record for the A10 connection by creating an association between the PDSN Session Identifier (PDSN SID) and the MN ID, the MN Session Reference ID and PCF Addresses. If the connection setup request is accepted by HSGW, the HSGW (for evolved mode operation) creates a binding record for the A10 connection by creating an association between the HSGW Session Identifier (HSGW SID) and the MN ID, the MN Session Reference ID and ePCF Addresses. In the case of legacy and evolved mode operation, the MN-Session Reference_ID is not received from the AT during origination and the eAN/ePCF shall set this to the default value of 1. If both the ePCF and the PDSN or HSGW support a Session Identifier Version higher than 0, the PDSN or HSGW may choose any PDSN SID. Otherwise the PDSN SID shall be identical to the ePCF Session Identifier (ePCF SID). The MN ID that is used by the ePCF on A11 messages contains the same value as the Mobile Identity (IMSI) received in the A9-Setup A8 message. The ePCF and the PDSN or HSGW shall use the ePCF IP Address (sent in the A11-Registration Request message) and the PDSN or HSGW IP Address (returned in the Home Agent field in the A11-Registration Reply message) as the A10 connection endpoints for the transport of user traffic. The ePCF IP Address and the PDSN or HSGW IP Address form the unique link layer ID for each A10 connection. The ePCF and the PDSN or HSGW maintain an association of the MSs MN ID and MN Session Reference ID with the A10 connection. When establishing a new A10 connection in 1x and (if the PCF supports ANIDs) in HRPD and eHRPD systems, the PCF shall include the ANID NVSE with the CANID as specified in A.S0013 [7]. If the PCF received the ANID from the AN and if the PCF supports ANIDs, it shall populate it in the PANID field of the ANID NVSE sent in the A11-Registration Request message. In legacy mode operation, the first A10 connection to be established for a packet data session shall have SO59 (3BH) 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 evolved mode operation, the first A10 connection to be established for a packet data session shall have SO59 (3BH) and is by definition the main connection. Additional auxiliary A10 connections may have SO64 (40H) HRPD Accounting Records Identifier, SO67 (43H) HRPD Packet Data IP Service where Higher Layer Protocol is IP or ROHC, or SO72 (48H) HRPD auxiliary Packet Data IP Service with PDN multiplexing header. In legacy mode and evolved mode operation 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/ePCF 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/ePCF 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. In legacy mode and evolved mode operation, when establishing auxiliary A10 connection(s), the ePCF shall include information for all A10 connection(s) of the AT (including IP flow mapping information) in the A11-Registration Request message. The ePCF may specify that the PDSN or HSGW 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. For inter-HSGW mobility in evolved mode operation, the target PCF shall include the source HSGW H1 address, the eHRPD indication (if applicable), Additional Session Information for all auxiliary A10 connections, and Connection Setup airlink records for the main and auxiliary A10 connections. (These may be sent in one or multiple A11Registration Request messages.) For evolved mode operation, if this message is being sent to establish a connection for HRPD pre-registration while the eAT is on E-UTRAN, then the Tunnel Mode indication of value 1 shall be included in this message. The ePCF shall include the Tunnel Mode indication of B-2

3GPP2 A.S0022-0 v1.0

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23

value 1 in all A11-Registration Request messages sent to the HSGW for the A10 session while the eAT is connected to the eHRPD system via the S101 interface. When the Tunnel Mode indication of value 1 is present, A11-Registration Request messages sent for the A10 session do not result in PMIP binding update from HSGW to P-GW. For handoff from E-UTRAN to eHRPD, the target PCF shall include the users APN information, if available at the ePCF. For optimized handoff from eHRPD to E-UTRAN, the source ePCF shall include the E-UTRAN Handoff Information Request Indicator to request the users APN information from the HSGW. 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 ePCF is able to determine that the setup of the A10 connection is due to a dormant handoff or an inter-ePCF hard handoff (e.g., the A9-Setup-A8 message included the ANID IE or the Data Ready Indicator field in the A9 Indicators IE was set to 0), the ePCF shall include the Mobility Event Indicator (MEI) CVSE in the A11-Registration Request message. The ePCF may provide the PDSN or HSGW with an indication of ePCF 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 both legacy mode operation and evolved mode operation, 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. For evolved mode sessions, the ePCF shall set the QoS Mode Session Parameter to the value 01H. 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 or HSGW 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 or HSGW 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 ANID IE or the Data Ready Indicator field in the A9 Indicators IE is set to 0), the PCF shall include the MEI CVSE, if the PCF supports ANIDs, 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 or HSGW by sending an A11-Registration Request message with a non-zero Lifetime value before B-3

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.S0022-0 v1.0

1 2 3 4

the A10 connection registration Lifetime timer expires. After sending this message, the PCF shall start timer Tregreq. In legacy and evolved mode operation, the PCF shall include information for all A10 connections of the AT in the A11-Registration Request message for refresh operation. 2.1.1.3 Successful Release Operation The ePCF may initiate release of the A10 connection by sending an A11-Registration Request message to the PDSN or HSGW with Lifetime field set to zero. The ePCF shall include accounting related and other information in the A11-Registration Request message. After receiving this message, the PDSN or HSGW shall remove the binding record for the A10 connection and save the accounting related and other information for further processing. The PDSN or HSGW shall send an A11-Registration Reply message to the ePCF with the Lifetime parameter set to 0. Refer to section 2.1.2.3. In legacy mode operation and evolved mode operation, the ePCF sends an A11-Registration Request message to the PDSN or HSGW, respectively, with the Lifetime value set to zero when the ePCF releases all A10 connections for the AT. In legacy and evolved mode operation, the ePCF 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 or eHRPD session. If the ePCF 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 or HSGW: If the A11-Registration Request message is invalid, the PDSN or HSGW 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 or HSGW indicates identification mismatch (Code value 85H) in the A11-Registration Reply message, the PDSN or HSGW shall also include its own time in the 32 high-order bits of the Identification information element of this message to allow the ePCF to avoid identification mismatch for subsequent A11-Registration Request messages. If the Lifetime timer for an A10 connection expires before the PDSN or HSGW has received a valid A11Registration Request message from the ePCF, then the PDSN or HSGW shall delete the binding record for the A10 connection. Failure detection at the ePCF: If the ePCF does not receive a valid A11-Registration Reply message from the PDSN or HSGW before timer Tregreq expires, the ePCF 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 ePCF removes the binding record for the A10 connection. 2.1.2 A11-Registration Reply

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

The PDSN or HSGW sends this message to the ePCF to acknowledge receipt of an A11-Registration Request message.

B-4

3GPP2 A.S0022-0 v1.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

2.1.2.1 Successful Establishment Operation Upon receipt of an A11-Registration Request message with a nonzero Lifetime value, the PDSN or HSGW 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 or HSGW 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 A11Registration Request message. Upon receiving the A11-Registration Reply message, the ePCF shall perform authentication and identification checks. After the message passes the checks, the ePCF shall stop timer Tregreq and start the Lifetime timer initialized to the value of the returned Lifetime parameter. In HRPD or eHRPD systems, if the A11-Registration Reply message establishes the main A10 connection, then the PDSN or HSGW includes the Subscriber QoS Profile, if applicable (e.g., during dormant handoff) and the PMK Information, if requested and available. The HSGW also includes its HSGW Address Information for use in the event of a subsequent inter-HSGW handoff. In HRPD or eHRPD systems, when the PDSN or HSGW 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 do not already exist with that ePCF. If the PDSN or HSGW has data to send to the ePCF when it receives an A11-Registration Request message, the PDSN or HSGW shall include a Data Available Indication as a CVSE in the A11Registration Reply message. In 1x, 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. In eHRPD systems, if the HSGW receives an A11-Registration Request message containing the users APN Information, the HSGW shall include its S103 IP address and S103 GRE key in the Target HSGW Address Information NVSE in the A11-Registration Reply message. The target ePCF then relays this information to E-UTRAN on S101 in preparation for handoff from E-UTRAN to eHRPD. In eHRPD systems, if the HSGW receives an A11-Registration Request message containing the EUTRAN Handoff Information Request Indicator, the HSGW shall include the users APN Information in the A11-Registration Reply message. The source ePCF then relays this information to E-UTRAN on S101 in preparation for handoff from eHRPD to E-UTRAN. If the selected PDSN or HSGW does not accept establishment of the A10 connection, it shall return an A11-Registration Reply message with a reject result code in the Code IE. Upon receipt of this message, the ePCF shall stop timer Tregreq. The PDSN or HSGW may return an A11-Registration Reply message with result code 88H (Registration Denied unknown PDSN address). When code 88H is used, an alternate PDSN or HSGW address is included in the A11-Registration Reply message. The address of the alternate proposed PDSN or HSGW shall be returned in the Home Agent field of the A11-Registration Reply message. Upon receipt of this message, the ePCF shall stop timer Tregreq. On receipt of an A11-Registration Reply message with code 88H, the ePCF shall either initiate establishment of the A10 connection with the proposed PDSN or HSGW by sending a new A11Registration Request message as indicated in this section, or it shall use internal algorithms to select a new PDSN or HSGW. If the ePCF receives a valid A11-Registration Reply message before timer Tregreq expires that indicates identification mismatch (Code value 85H), the ePCF may adjust the clock that it uses for communication with the PDSN or HSGW, retransmit the A11-Registration Request message with a newly generated Identification IE, and restart timer Tregreq. B-5

3GPP2 A.S0022-0 v1.0

1 2 3 4 5

On receipt of a valid A11-Registration Reply message with another result code, depending on the result code, the ePCF may attempt to re-try setting up the A10 connection with the same or another PDSN or HSGW; refer to section 1.14.3. The PDSN or HSGW may provide the ePCF with an indication of PDSN or HSGW 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 or HSGW 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 ePCF shall stop timer Tregreq and start the Lifetime timer initialized to the value of the returned Lifetime parameter. If the ePCF receives a valid A11-Registration Reply message before timer Tregreq expires that indicates identification mismatch (Code value 85H), the ePCF may adjust the clock that it uses for communication with the PDSN or HSGW, 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 ePCF may resend the message with a newly generated Identification IE based on the clock it uses for communication with the PDSN or HSGW; otherwise the ePCF shall initiate release of the A10 connections to this PDSN or HSGW. 2.1.2.3 Successful Release Operation Upon receipt of a valid A11-Registration Request message with Lifetime field set to zero, the PDSN or HSGW shall respond with an A11-Registration Reply message with an accept indication. Upon receipt of this message, the ePCF shall remove the binding record for the A10 connection and stops timer Tregreq. In HRPD or eHRPD systems, upon receipt of a valid A11-Registration Request message with the Lifetime value set to zero, the PDSN or HSGW shall release all A10 connections for the AT. In HRPD or eHRPD systems, when the PDSN or HSGW receives an A11-Registration Request message including Additional Session Information with a non-zero Lifetime value, the PDSN or HSGW releases the A10 connections that are not referred to in the Additional Session Information. If the ePCF receives a valid A11-Registration Reply message before timer Tregreq expires that indicates identification mismatch (Code value 85H), the ePCF may adjust the clock that it uses for communication with the PDSN or HSGW, 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 ePCF may resend the message with a newly generated Identification IE based on the clock it uses for communication with the PDSN or HSGW; otherwise the ePCF shall initiate release of the A10 connections to this PDSN or HSGW. 2.1.2.4 Failure Operation Failure detection at the ePCF: If the A11-Registration Reply message is invalid, the ePCF shall discard the message. Failure detection at the PDSN or HSGW: None.

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

B-6

3GPP2 A.S0022-0 v1.0

1 2 3 4

2.1.3

A11-Registration Update

In 1x systems, the PDSN sends this message to the ePCF to initiate release of an A10 connection. In HRPD or eHRPD systems, the PDSN or HSGW sends this message to release all A10 connections associated with an AT. 2.1.3.1 Successful Operation The PDSN may send an A11-Registration Update message to the ePCF to initiate release of one A10 connection in 1x systems or all A10 connections associated with an AT in HRPD or eHRPD systems. The Home Agent field in the A11-Registration Update message is the PDSN Address and the Home Address is set to zero. The ePCF Session Identifier and other session specific information are sent within the Session Specific extension. After sending this message, the PDSN starts timer Tregupd. 2.1.3.2 Failure Operation Failure detection at the ePCF: If the A11-Registration Update message is invalid, the ePCF shall keep the binding for the A10 connection(s) and shall not update its Lifetime timer. The ePCF shall send an A11Registration Acknowledge message indicating identification mismatch (Status value 85H) or authentication failure (Status value 83H); refer to section 2.1.4. Failure detection at the PDSN or HSGW: If the PDSN or HSGW does not receive a valid A11Registration 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 or HSGW may retransmit the A11-Registration Update message with a new timestamp in the Identification information element and restart timer Tregreq a configurable number of times. If the PDSN or HSGW 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 or HSGW shall remove the binding record for the A10 connection.

5 6 7 8 9 10

11 12 13 14 15 16 17 18 19 20 21 22 23 24

25

2.2 A10-Connection Update Procedures

The PDSN or HSGW 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

26 27 28

29 30 31 32 33 34 35 36 37 38 39 40 41 42 43

The A11-Session Update message is sent from the PDSN or HSGW to the ePCF 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 or eHRPD systems, the A11-Session Update message is sent to deliver a new or updated Subscriber QoS Profile to the ePCF after establishment of the main A10 connection. In HRPD or eHRPD systems, this message may also be used by the PDSN or HSGW 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-ePCF handoff. The AN shall store the updated QoS information received from the PDSN or HSGW together with the personality index in use at the time the update was received. Whenever the specified personality B-7

3GPP2 A.S0022-0 v1.0

1 2 3 4 5 6 7 8 9 10 11 12

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 C.S0087 [24]) 6, regardless of the personality in use. Updated QoS information received from the PDSN or HSGW (via the ePCF) supersedes stored updated QoS information previously received from the PDSN or HSGW or from another AN (via A13 or A16). In HRPD or eHRPD 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 or HSGW wants to release. The PDSN or HSGW should not use this procedure for flow IDs FFH and FEH. In eHRPD systems, this message is also used to send PMK keys once they are available if the PMK Indicator was included in an A11-Registration Request message but the PMK Information was unavailable at the time that the corresponding A11-Registration Response message was sent. 2.2.1.1 Successful Operation The PDSN or HSGW may update session parameters of an A10 connection, 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 ePCF. The Home Agent field in A11-Session Update message is the PDSN or HSGW Address and the Home Address is set to zero. The ePCF Session Identifier and other session specific information are sent within the Session Specific Extension. The A11-Session Update message includes the session parameter(s), the Anchor P-P Address, the Subscriber QoS Profile, and/or QoS Update Information in NVSE(s). In HRPD or eHRPD systems, the A11-Session Update message includes the subscriber QoS profile and/or QoS Update Information. For session parameter(s), the ePCF shall update its session parameters or relay the parameters to the BS according to the specified behavior for the particular parameter. The ePCF shall relay the Anchor P-P Address to the BS. For the Subscriber QoS Profile, the ePCF 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 ePCF 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 ePCF may respond by sending an A11Session Update Ack message with the Status IE set to Partial QoS updated. The ePCF informs the PDSN or HSGW 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 or HSGW shall start timer Tsesupd. 2.2.1.2 Failure Operation Failure detection at the ePCF: If the A11-Session Update message is invalid, the ePCF shall not update any session parameters. The ePCF 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 or HSGW: If the PDSN or HSGW does not receive a valid A11-Session Update Acknowledge message before timer Tsesupd expires, the PDSN or HSGW may retransmit the

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

i.e., ProfileType = NULL in ReservationKKQoSRequestFwd or ReservationKKQoSRequestRev.

B-8

3GPP2 A.S0022-0 v1.0

1 2 3 4 5

A11-Session Update message with a new timestamp in the Identification information element a configurable number of times to the ePCF. If the PDSN or HSGW has not received an A11-Session Update Acknowledge with an accept indication (Status value 00H) after a configurable number of retransmissions, the PDSN or HSGW shall consider the update failed and shall maintain the A10 connection.

2.3 A10 Packet Accounting Procedures

The PCF uses the A11-Registration Request message to send accounting related and other information to the PDSN or HSGW. The accounting related information is accumulated at the PCF and sent to the PDSN or HSGW on occurrence of pre-defined triggers, which are listed in Tables 2.3-1 and 2.3-2. The occurrence of these predefined triggers is fully specified in X.S0011 [25]. The A10 connection binding record at the PDSN or HSGW and the PCF may also be updated appropriately depending on the setting of the Lifetime field. Table 2.3-1 Accounting Records Generated by the PCF in HRPD systems without IP Flow Based Accounting Accounting Records Generated by the PCF

7 8 9 10 11 12 13 14 15 16

Airlink Record Type (Y1) Y1=1 Y1=2 Y1=3 Y1=4

17 18 19

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 B-9

3GPP2 A.S0022-0 v1.0

Airlink Record Type (Y1) Y1=3

Accounting Records Generated by the PCF

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.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

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 or HSGW 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 or HSGW, as Remote Authentication Dial-In User Service (RADIUS) protocol encoded attributes, in the Application Data field of a CVSE element. If the PDSN or HSGW receives an unexpected airlink record it may reject the A11Registration Request message and the A11-Registration Reply message shall contain the code 86H (Registration Denied poorly formed request). If the PDSN or HSGW does not receive an accounting parameter that is expected, the PDSN or HSGW 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 HSGW), or code 86H (Registration Denied poorly formed request). If the PDSN or HSGW receives a RADIUS attribute that is not expected in a CVSE, the PDSN or HSGW 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

19 20 21 22 23 24 25

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

26 27 28

The Active-Start Airlink record shall be included in the A11-Registration Request message under the following circumstances: B-10

3GPP2 A.S0022-0 v1.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

1. For 1x systems when 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 A10 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 ePCF 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 or FEH 7 in HRPD systems, when an HRPD connection is established: during initial session setup when the main A10 connection is associated with the HRPD air interface, on transition from dormant to active state, or during handoff. The Active Start Airlink Record for the IP flows with ID FFH or FEH shall not be sent to the HSGW if the Tunnel Mode indication set to 1 in eHRPD Indicators is also included in the A11-Registration Request message. For IP flows with ID FFH or FEH in HRPD systems, accounting is bidirectional: one Active-Start Airlink record applies to both forward and reverse IP flows with ID FFH or FEH. This record does not include Granted QoS Parameters. 4. For IP flows with ID other than FFH or FEH 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 or FEH 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 Airlink record are made available at the ePCF at the time the message is sent). The ePCF 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

27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42

The Active Stop Airlink Record shall be included in the A11-Registration Request message under the following circumstances: 1. In 1x systems, when 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 or FEH11 in HRPD systems, when an HRPD connection is released. The Active-Stop Airlink Record for the IP flows with ID FFH or FEH shall not be sent to the HSGW if the Tunnel Mode indication with the value set to 1 is also included in the A11-Registration Request message. For IP flows with ID FFH or FEH in HRPD systems, accounting is bidirectional: one Active-Stop Airlink record applies to both forward and reverse IP flows with ID FFH or FEH. 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

FEH is optional, depending on whether or not the AN chooses to configure the session to use it.

B-11

3GPP2 A.S0022-0 v1.0

1 2 3 4 5 6

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-ePCF handoff, the source ePCF shall send an Active-Stop Airlink record for each activated IP flow to the PDSN, and the target ePCF shall send Active-Start Airlink records for each activated IP flow to the PDSN. In the case of circumstance (2) above, the Active Stop Airlink Record shall be sent and followed by an Active Start Airlink Record that shall contain the new set of parameters.

3.0
3.1

8 9

Message Formats
A11-Registration Request

10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27

This A11 interface message is sent from the ePCF to the HSGW to: establish one or more A10 connection (and identify the associated service option value and MN Session Reference ID/SR_ID); establish a connection for HRPD pre-registration while the AT is on E-UTRAN; periodically re-register all A10 connection(s) for the MS/eAT; clear one or more 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 and eHRPD systems; Request APN information from the HSGW in eHRPD systems. The A11-Registration Request messages may contain additional information to: pass inter-HSGW handoff, or inter-technology handoff related information; indicate support of features such as Short Data Indication; pass information related to E-UTRAN eHRPD handoff; indicate that the eAT is operating in evolved mode; pass information applicable to calls in eHRPD mode, such as a request for PMK information.
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 Section Reference [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] 4.2.14 [3], [4] Element Direction ePCF -> HSGW ePCF -> HSGW ePCF -> HSGW ePCF -> HSGW ePCF -> HSGW ePCF -> HSGW ePCF -> HSGW ePCF -> HSGW ePCF -> HSGW ePCF -> HSGW ePCF -> HSGW M O O O O O O O O O
i a,e l h

Type

R R R R R R R C C R

a,b,c,d,f,g,j,k,m,

n,o,p,q,r,s,t,u

B-12

3GPP2 A.S0022-0 v1.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

a. One or more instances of this element may be included. b. In 1x systems, 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. In 1x systems, 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. In HRPD and eHRPD systems, Application Type = Service Option contains the SO value for the main service connection. The main service connection 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 ePCF has enabled e.g., Short Data Indication. h. For HRPD and eHRPD 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 HRPD and eHRPD 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 and eHRPD 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. For HRPD and eHRPD systems, this IE contains the IPv4 address of the ePCF 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 and eHRPD, 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 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 and eHRPD systems, this IE is used to provide QoS information. o. In HRPD and eHRPD 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. For enhanced mode sessions, the ePCF shall set the QoS Mode Session Parameter to the value 01H. If the PDSN does not receive the QoS Mode, then the PDSN shall assume the QoS Mode is set to 0. p. This IE shall be included when this message is sent to convey information pertaining to the EUTRAN eHRPD handoff such as P-GW Addresses and GRE keys for uplink traffic. q. For inter-HSGW mobility in eHRPD systems, the target ePCF shall include the source HSGWs HSGW H1 IP Address. The target ePCF may include this IE if it is available. r. s. For handoff from E-UTRAN to eHRPD, the target ePCF shall include information for the eATs EPS information. For eHRPD, this element may be included to convey eHRPD Indicators. For an eHRPD system that supports GKE, the PMK indication may be set to 1 to request PMK information, for example when B-13

3GPP2 A.S0022-0 v1.0

1 2 3 4 5 6 7 8

establishing the main A10 connection upon setup or during inter-HSGW mobility. The ePCF shall not send eHRPD Indicators if the mobile is operating in legacy mode. t. For eHRPD, an instance of this element containing the eHRPD Mode indication shall be included in this message when establishing the main A10 connection if the HSGW A11 IP address is shared with PDSN The eHRPD Mode indication informs the receiver if it should operate as a PDSN or an HSGW.

u. For handoff from eHRPD to E-UTRAN, an instance of this element containing the E-UTRAN Handoff Parameter Request indication may be included to request parameters. 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

A11 Message Type = [01H] Flags = [0AH, 8AH] (MSB) Lifetime = [00 00H to FF FEH]

B-14

3GPP2 A.S0022-0 v1.0

3.1 0 1 2

A11-Registration Request 3 4 5 6 7 Octet 6 7 (LSB) Reserved = [00H] 8 9 Session ID Ver = [00 (Version 0), 01 (Version 1)] 10 11 (LSB) 12 13 (LSB) 14 15 16 17

Reserved = [0000 00] (MSB)

MN Session Reference Id = [00 01H - 00 06H], in 1x systems [00 01H] in HRPD and eHRPD systems MSID Type = [00 06H] (IMSI) MSID Length = [06-08H] (10-15 digits)

(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)}

Identity Digit N = [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> 1 2 m k

B-15

3GPP2 A.S0022-0 v1.0

3.1 0 (MSB) (MSB) 1 2

A11-Registration Request 3 4 Reserved = [00 00H] (LSB) 5 6 7 Octet 3 4 5 6 7 (LSB) 8 9

3GPP2 Vendor ID = [00 00 15 9FH]

Application Type = [06H, 08H, 09H, 0B-0DH, 0FH] (Indicators, Session Parameter, Service Option, PCF Enabled Features, Additional Session Information, QoS Information, Information) IF (Application Type = 06H (Indicators)) {1 Application Sub Type = [02H (eHRPD Mode), 03H (eHRPD Indicators)] IF (Application Sub Type = 02H (eHRPD Mode)){1: Reserved = [000 0000H] eHRPD Mode = [0,1] PMK = [0,1] EUTRAN Handoff Info = [0,1] Tunnel Mode = [0,1]

10

11

} Application Sub Type = 02H; ELSE IF (Application Sub Type = 03H (eHRPD Indicators)){1: Reserved = [0 0000H] 11

} Application Sub Type = 03H; } Application Type = 06H; ELSE IF (Application Type = 08H (Session Parameter)) {1 Application Sub Type = 03H (QoS Mode) QoS Mode = [00H-01H] } Application Type = 08H; ELSE IF (Application Type = 09H (Service Option)) {1: Application Sub Type = [01H] (MSB) Application Data = [00 3BH (HRPD main service instance)] for HRPD and eHRPD systems (LSB) } Application Type = 09H; ELSE IF (Application Type = 0BH (PCF Enabled Features)){1 Application Sub Type = [01H (Short Data Indication Supported), 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 = <variable> SR_ID = [02H-1FH] n n+1 10 10 10 11 12 10 11

B-16

3GPP2 A.S0022-0 v1.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) for HRPD and eHRPD, 00 43H (HRPD Auxiliary Service Connection without higher layer framing for packet synchronization) for HRPD and eHRPD, 00 48H (HRPD Auxiliary Packet Data IP Service with PDN multiplexing header)] for eHRPD system. (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 = <any value encoded as specified in Internet Assigned Numbers Authority [33]> (LSB) } 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 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

B-17

3GPP2 A.S0022-0 v1.0

3.1 0 Reverse LargeCIDs = [0,1] Reverse Profile { Reverse ProfileCount: (MSB) 1 2

A11-Registration Request 3 4 5 6 7 Octet p+5 Reserved = [000 0000]

Reverse ProfileCount = <any value> Reverse Profile = <any value encoded as specified in Internet Assigned Numbers Authority [33]> (LSB) } 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]

p+6 q q+1

10 11 12

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

Forward Requested QoS Length = [variable] (MSB) Forward Requested QoS = <any value>

n+3 n+4

(LSB) Forward Granted QoS Length = [variable] (MSB) Forward Granted QoS = <any value>

p p+1 p+2

(LSB) } Forward Flow Entry

} 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] n n+1 11 12

B-18

3GPP2 A.S0022-0 v1.0

3.1 0 1 2

A11-Registration Request 3 4 5 6 7 Flow State = [0, 1] Octet n+2

Reserved = [0000 000]

Reverse Requested QoS Length = [variable] (MSB) Reverse Requested QoS = <any value>

n+3 n+4

(LSB) Reverse Granted QoS Length = [variable] (MSB) Reverse Granted QoS = <any value>

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 (Cause Code), 02H (HSGW H1 Address Information), 03H (EPS Information)] IF (Application Sub Type = 01H (Cause Code)){1: Cause Value = [01H (Packet data session release), 02H (Air link lost)] Address Type = [01H (IPv4)] (MSB) HSGW H1 IP Address = <any value> (LSB) }Application Sub Type = 02H; ELSE IF (Application Sub Type = 03H (EPS Information)){1: PDN Information Entry { 1-N (where N = max number of APNs): PDN Information Entry Length = <variable> Parameter Type = [01H (APN Information)] Parameter Length = <variable> (MSB) APN = <any value> (LSB) Parameter Type = [02H (S103 Source GRE Key Information)] Parameter Length = [04H] (MSB) S103 Source GRE Key = <any value>

10

11

} Application Sub Type = 01H; ELSE IF (Application Sub Type = 02H (HSGW H1 Address Information)){1: 11 12 13 14 15

m m+1 m+2 m+3 n n+1 n+2 n+3 n+4

B-19

3GPP2 A.S0022-0 v1.0

3.1 0 1 2

A11-Registration Request 3 4 5 6 7 (LSB) Octet n+5 n+6 n+7 n+8 n+9 n+10 (LSB) } PDN Information Entry p

Parameter Type = [03H (P-GW IP Address)] Parameter Length = <variable> Address Type = [01H, 02H (IPv4, IPv6)] (MSB) P-GW IP Address = <any value>

}Application Sub Type = 03H; } Application Type = 0FH; ELSE IF (Application Type = 10H (HRPD Indicator)) {1: Application Sub Type = [01H (Emergency Services)] Emergency Services = [0, 1] Reserved 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 or HSGW to the PCF in response to an A11Registration Request message.
Information Element A11 Message Type Code Lifetime Home Address Home Agent Identification Section Element Direction Reference [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] HSGW -> ePCF HSGW -> ePCF HSGW -> ePCF HSGW -> ePCF HSGW -> ePCF HSGW -> ePCF M M M M Ma M Type

B-20

3GPP2 A.S0022-0 v1.0

Information Element 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 32 33 34

Section Element Direction Reference [3], [4] HSGW -> ePCF Mi Ob

Type

[3], [4]
4.2.14 [3], [4]

HSGW -> ePCF HSGW -> ePCF

HSGW -> ePCF

C C

h,j,k,l,m,n,o ,p,q

Oc,d,e,f,g,

a. This element can also be used to identify the IPv4 address of an alternative PDSN or HSGW. b. This element is included if the PDSN or HSGW has data available. c. In 1x systems, 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. In 1x systems during a fast handoff, the target PDSN includes the Anchor P-P Address to indicate that the fast handoff request was accepted. f. In 1x and HRPD systems, 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 or HSGW, the PDSN or HSGW shall include the NVSE with an Always-on indicator. h. This element is used by the PDSN or HSGW 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 and eHRPD 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 or eHRPD system, the PDSN or HSGW 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 and eHRPD systems with QoS, this element is included by the PDSN or HSGW when this message is sent to establish the main A10 connection. It provides the PDSN or HSGW ROHC channel parameter values when ROHC on SO67 is supported with ROHC in the PDSN or HSGW.

m. This IE may be used to indicate that the PDSN or HSGW supports receiving the GRE segmentation attribute in A10 GRE frames. n. If this message is sent to establish the main A10 connection in an eHRPD system, the HSGW shall include this IE to convey its H1 IP Address. This information is saved in the event of an inter-HSGW handoff. o. In eHRPD systems, this element is included by the HSGW to provide the Target HSGW S103 Information when this message is sent in response to an A11-Registration Request message containing the users APN Information. This information is used for handoff from E-UTRAN to eHRPD. The Serving GW uses this information to forward any stranded packets to the HSGW over the S103 tunnel.

B-21

3GPP2 A.S0022-0 v1.0

1 2 3 4 5

p. In eHRPD systems, this IE contains the users APN Information when requested by the presence of the E-UTRAN Handoff Information Request Indicator in the corresponding A11-Registration Request message. This information is used for handoff from eHRPD to E-UTRAN. q. In eHRPD systems, this IE contains PMK Information when requested by the presence of the PMK Indicator in the corresponding A11-Registration Request message. 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 1

A11 Message Type = [03H] [00H 80H 81H 82H 83H 85H 86H 88H 89H 8AH 8BH 8CH 8DH Code = (Registration Accepted), (Registration Denied reason unspecified), (Registration Denied administratively prohibited), (Registration Denied insufficient resources), (Registration Denied ePCF 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 ePCF to the PDSN.), 8EH (Registration Denied - nonexistent A10 or IP flow)] Lifetime = [00 00H to FF FEH] (LSB) (MSB) Home Address = [00 00 00 00H]

(MSB)

1 2 1 2 3 (LSB) 4 1 2 3 (LSB) 4 1 2 3 4 5 6 7 (LSB) 8

(MSB)

Home Agent = <any value>

(MSB)

Identification = <any value>

B-22

3GPP2 A.S0022-0 v1.0

3.2 0 1 2 3

A11-Registration Reply 4 5 6 7 Octet 1 2 3 (LSB) 4 5 6 7 (LSB) 8 9 Session ID Ver = [00 (Version 0), 01 (Version 1)] (LSB) 10 11 12 13 (LSB) 14 15 16 17

Session Specific Extension: Type = [27H] Length = [13H 15H] (MSB) (MSB) Protocol Type = [88 81H] Key = <any value>

Reserved = [00H] Reserved = [0000 00] (MSB) (MSB)

MN Session Reference Id = [00 01H] in HRPD and eHRPD systems MSID Type = [00 06H] (IMSI) 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)

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

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]

B-23

3GPP2 A.S0022-0 v1.0

3.2 0 1 2 3

A11-Registration Reply 4 5 6 7 Octet 6 7 (LSB) 8 9

Application Type 08H (Session Parameter), 0AH (PDSN Enabled Features), 0CH (Additional Session Information), 0DH (QoS Information), 0EH (Header Compression), 0FH (Information)] IF (Application Type = 08H (Session Parameter)){1 Application Sub Type = [02H (Always-on)] IF (Application Type = 0AH (PDSN Enabled Features)){1: Application Sub Type = [ 01H (Flow Control Enabled), 02H (Packet Boundary Enabled), 03H (GRE Segmentation Enabled)] Application Sub Type = [01H] GRE Key Information Entry { 1 - 30: Entry Length = [0DH] SR_ID = [02H-1FH] (MSB) Service Option = [00 40H (HRPD Accounting Records Identifier) for HRPD and eHRPD, 00 43H (HRPD Packet Data IP Service where Higher Layer Protocol is IP or ROHC) for HRPD and eHRPD, 00 48H (HRPD auxiliary Packet Data IP Service with PDN multiplexing header) for eHRPD] (LSB) (MSB) (MSB) Protocol Type = [88 81H] (LSB) Key = <any value>

10 10

} Application Type = 0AH; ELSE IF (Application Type = 0CH (Additional Session Information)) {1: 10 n n+1 n+2

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

B-24

3GPP2 A.S0022-0 v1.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) LargeCIDs = [0,1] MaxCID = <any value> (LSB) MRRU = <any value> (LSB) Reserved = [000 0000] ProfileCount = <any value> Profile {ProfileCount: (MSB) Profile = <any value encoded as specified in Internet Assigned Numbers Authority [33]> (LSB) } Profile } Application Type = 0EH; ELSE IF (Application Type = 0FH (Information)) {1+: Application Sub Type = [02H (HSGW H1 Address Information), 03H (EPS Information), 04H (Additional HSGW Information)] If (Application Sub Type = 02H (HSGW H1 Address Information)) {1: Address Type = [01H (IPv4)] (MSB) HSGW H1 IP Address = <any value>

n 10 11 12 13 14 15 16 n n+1

10

11 12 13 14 (LSB) 15

}Application Sub Type = 02H; ELSE IF (Application Sub Type = 03H (EPS Information)){1: PDN Information Entry { 1-N (where N = max number of APNs): PDN Information Entry Length = <variable> Parameter Type = [01H (APN Information)] Parameter Length = <variable> (MSB) APN = <any value> (LSB) Parameter Type = [02H (S103 Source GRE Key Information)] Parameter Length = [04H] (MSB) S103 Source GRE Key = <any value> m m+1 m+2 m+3 n n+1 n+2 n+3 n+4 n+5 (LSB) n+6

B-25

3GPP2 A.S0022-0 v1.0

3.2 0 1 2 3

A11-Registration Reply 4 5 6 7 Octet n+7 n+8 n+9 n+10 (LSB) } PDN Information Entry p

Parameter Type = [03H (P-GW IP Address)] Parameter Length = <variable> Address Type = [01H (IPv4) , 02H (IPv6)] (MSB) P-GW IP Address = <any value>

}Application Sub Type = 03H; ELSE IF (Application Sub Type = 04H (Additional HSGW Information)){1+: HSGW Parameter Entry {1+: Parameter Type = [01H-03H] (T-HSGW S103 IP Address, T-HSGW S103 Key, PMK Information) IF (Parameter Type = 01H) { Parameter Length = [variable] Address Type = [01H (IPv4), 02H (IPv6)] (MSB) T-HSGW S103 IP Address = <any value> (LSB) } Parameter Type 01H; ELSE IF Parameter Type = 02H (T-HSGW S103 Key) {1+: Parameter Length = [variable] (MSB) APN = <any value> (LSB) (MSB) T-HSGW S103 Key = <any value> p p+1 q q+1 q+2 q+3 (LSB) } Parameter Type = 02H; ELSE IF (Parameter Type = 03H) { Parameter Length = [variable] PMK Count = <any value> PMK { PMK Count+1: PMK Length = [variable] n n+1 (LSB) p p+1 p+2 m m+1 q+4 12 13 14 n 11

(MSB)

PMK = <any value>

(MSB)

PMK Lifetime = <any value>

B-26

3GPP2 A.S0022-0 v1.0

3.2 0 1 2 3

A11-Registration Reply 4 5 6 7 (LSB) Octet p+3 p+4

} PMK; } Parameter Type = 03H; } Application Sub Type = 04H; }Application Type = 0FH 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

22

2 3

3.3

A11-Registration Update
Section Element Direction Reference [3], [4] None [3], [4] [3], [4] [3], [4] [3], [4] 4.2.14 [3], [4] PDSN -> ePCF PDSN -> ePCF PDSN -> ePCF PDSN -> ePCF PDSN -> ePCF PDSN -> ePCF PDSN -> ePCF PDSN -> ePCF M Ma M M M Mc Ob M C Type

This A11 interface message is sent from the PDSN or HSGW to the ePCF to release A10 connections.
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

4 5 6 7

a. This field is set to zero by the PDSN or HSGW and ignored by the ePCF. b. This element is used by the PDSN or HSGW to provide a PDSN code to the ePCF. c. For HRPD or eHRPD, 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

Message Type = [14H]

B-27

3GPP2 A.S0022-0 v1.0

3.3 0 1 2 3

A11-Registration Update 4 5 6 7 Octet 1 2 3

Reserved = [00 00 00H]

(MSB)

Home Address = [00 00 00 00H]

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 (LSB) 8 9 Session ID Ver = [00 (Version 0), 01 (Version 1)] (LSB) 10

(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>

Reserved = [00H] Reserved = [0000 00]

(MSB) (MSB)

MN Session Reference Id = [00 01H] in HRPD and eHRPD systems MSID Type = [00 06H] (IMSI) (LSB) MSID Length = [06-08H] (10-15 digits)

11 12 13 14 15 16 17

Identity Digit 1 = [0H-9H] (BCD) Identity Digit 3 = [0H-9H] (BCD)

Odd/Even Indicator = [0000, 0001] Identity Digit 2 = [0H-9H] (BCD)

B-28

3GPP2 A.S0022-0 v1.0

3.3 0 1 2 3

A11-Registration 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)}

Identity Digit N = [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

2 3 4

3.4

A11-Registration Acknowledge

This A11 interface message is sent from the ePCF to the PDSN or HSGW in response to an A11Registration Update message.
Information Element A11 Message Type Reserved <2 octets> Status Home Address Care-of-Address Section Element Direction Reference [3], [4] None 4.2.9 [3], [4] [3], [4] ePCF -> PDSN ePCF -> PDSN ePCF -> PDSN ePCF -> PDSN ePCF -> PDSN M Ma M M M Type

B-29

3GPP2 A.S0022-0 v1.0

Information Element Identification Session Specific Extension Registration Update Authentication Extension
1 2 3 4

Section Element Direction Reference [3], [4] [3], [4] [3], [4] ePCF -> PDSN ePCF -> PDSN ePCF -> PDSN M

Type

Mb M

a. This field is set to zero by the ePCF and ignored by the PDSN or HSGW. b. For HRPD or eHRPD, 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 6 7 (LSB) 8 1 2 3 (LSB) 4

(MSB)

Care-of-Address = <any value>

(MSB)

Identification = <any value>

Session Specific Extension: Type = [27H] Length = [13H 15H] (MSB) Protocol Type = [88 81H]

B-30

3GPP2 A.S0022-0 v1.0

3.4 0 (MSB) 1 2

A11-Registration Acknowledge 3 4 Key = <any value> 5 6 7 Octet 5 6 7 (LSB) Reserved = [00H] 8 9 Session ID Ver = [00 (Version 0), 01 (Version 1)] (LSB) 10

Reserved = [0000 00]

(MSB) (MSB)

MN Session Reference Id = [00 01H] in HRPD and eHRPD systems MSID Type = [00 06H] (IMSI) (LSB) MSID Length = [06-08H] (10-15 digits)

11 12 13 14 15 16 17

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)}

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)

Authenticator = <any value > (keyed-MD-5 authentication)

(LSB)
1

22

2 3 4 5 6 7 8 9

3.5

A11-Session Update

This A11 interface message is sent from the PDSN or HSGW to the ePCF to add new or update parameters of an A10 connection. In 1x systems, it is also sent to update the ePCF with the Anchor P-P Address. In HRPD or eHRPD systems with QoS, this message is sent to convey or update the subscriber QoS profile after establishment of the main A10 connection. In HRPD or eHRPD systems with QoS, this message may also be used for QoS update by the PDSN or HSGW. In eHRPD systems, this message may also be used for sending PMK keys when they become available if they were unavailable when the ePCF requested them. B-31

3GPP2 A.S0022-0 v1.0

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
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 Element Direction Reference [3], [4] None [3], [4] [3], [4] [3], [4] [3], [4] 4.2.14 [3], [4] PDSN -> ePCF PDSN -> ePCF PDSN -> ePCF PDSN -> ePCF PDSN -> ePCF PDSN -> ePCF PDSN ->ePCF PDSN -> ePCF M Ma M M M Me

Type

Ob,c,d,f, C
g,h,i

a. This field is set to zero by the PDSN or HSGW and ignored by the ePCF. b. In 1x systems, 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. In 1x systems, this element is included by the PDSN to update the PCF with an Anchor P-P Address for fast handoff. e. For HRPD or eHRPD systems the MN Session Reference ID field of this IE shall be set to 00 01H. f. In HRPD or eHRPD 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-ePCF handoff. The target AN shall store the updated QoS lists received from the PDSN or HSGW and use them to grant the QoS irrespective of the contents of the subscriber QoS Profile.

g. In HRPD or eHRPD systems, this IE is used to release for one or more IP flows in the specified direction. The PDSN or HSGW 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 or HSGW should not use this procedure for flow IDs FFH and FEH. h. One or more instances of this element may be included. i. In eHRPD systems, this IE is used to send PMK Information once it is available when the PMK indication was included in an A11-Registration Request message but the PMK Information was unavailable at the time that the corresponding A11-Registration Response message was sent.

27

The following table shows the bitmap layout for the A11-Session Update message.
3.5 0 (MSB) 1 2 3 A11-Session Update 4 5 6 7 Octet 1 1

Message Type = [16H] Reserved = [00 00 00H]

B-32

3GPP2 A.S0022-0 v1.0

3.5 0 1 2 3

A11-Session Update 4 5 6 7 (LSB) Octet 2 3 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 (LSB) 8 9 Session ID Ver = [00 (Version 0), 01 (Version 1)] (LSB) 10

(MSB)

Home Address = [00 00 00 00H]

(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>

Reserved = [00H] Reserved = [0000 00]

(MSB) (MSB)

MN Session Reference Id = [00 01H] in HRPD or eHRPD systems MSID Type = [00 06H] (IMSI) (LSB) MSID Length = [06-08H] (10-15 digits)

11 12 13 14 15 16 17

Identity Digit 1 = [0H-9H] (BCD) Identity Digit 3 = [0H-9H] (BCD)

Odd/Even Indicator = [0000, 0001] Identity Digit 2 = [0H-9H] (BCD)

B-33

3GPP2 A.S0022-0 v1.0

3.5 0 1 2 3 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)}

A11-Session Update 4 5 6 7 Octet k Identity Digit N = [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 10 10

Application Type = 08H (Session Parameter), 0DH (QoS Information)] IF (Application Type = 08H (Session Parameter)) {1: Application Sub Type = [01H (RN-PDIT), 02H (Always-on)]] 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

(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] Forward Updated QoS Sub-BLOB Length = [variable] (MSB) Forward Updated QoS Sub-BLOB = <any value> p p+1 p+2 11

(LSB) } Forward Flow Entry

} 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] p 11

B-34

3GPP2 A.S0022-0 v1.0

3.5 0 (MSB) 1

A11-Session Update 6 7 Octet p+1 p+2

2 3 4 5 Reverse Updated QoS Sub-BLOB Length = [variable]

Reverse Updated QoS Sub-BLOB = <any value>

(LSB) } Reverse Flow Entry } Application Sub Type = FFH ; } Application Type = 0DH; ELSE IF (Application Type = 0FH (Information)){1: Application Sub Type = [04H (Additional HSGW Information)] HSGW Parameter Entry {1: Parameter Type = [03H] (PMK Information) Parameter Length = [variable] PMK Count = <any value> PMK { PMK Count+1: PMK Length = [variable]

10 m m+1 m+2 n n+1 (LSB) p p+1 p+2 p+3 (LSB) p+4

(MSB)

PMK = <any value>

(MSB)

PMK Lifetime = <any value>

} PMK; } Application Sub Type = 04H; }Application Type = 0FH; 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) (MSB) Authenticator = <any value > (keyed-MD-5 authentication) 6 7 8 9

(LSB)
1

22

B-35

3GPP2 A.S0022-0 v1.0

1 2 3

3.6

A11-Session Update Acknowledge

This A11 interface message is sent from the ePCF to the PDSN or HSGW in response to an A11-Session 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 [3], [4] None 4.2.9 [3], [4] [3], [4] [3], [4] [3], [4] [3], [4] ePCF -> PDSN ePCF -> PDSN ePCF -> PDSN ePCF -> PDSN ePCF -> PDSN ePCF -> PDSN ePCF -> PDSN ePCF -> PDSN M Ma M M M M M M Type

a. This field is set to zero by the ePCF and ignored by the PDSN or HSGW. 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) CAH (Update Denied PMK not requested) 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

(MSB)

Care-of-Address = <any value>

(MSB)

Identification = <any value>

B-36

3GPP2 A.S0022-0 v1.0

3.6 0 1 2

A11-Session Update Acknowledge 3 4 5 6 7 Octet 2 3 4 5 6 7 (LSB) 8 1 2 3 (LSB) 4 5 6 7 (LSB) Reserved = [00H] 8 9 Session ID Ver = [00 (Version 0), 01 (Version 1)] (LSB) 10

Session Specific Extension: Type = [27H] Length = [13H 15H] (MSB) (MSB) Protocol Type = [88 81H] Key = <any value>

Reserved = [0000 00]

(MSB) (MSB)

MN Session Reference Id = [00 01H] in HRPD or eHRPD systems MSID Type = [00 06H] (IMSI) (LSB) MSID Length = [06-08H] (10-15 digits)

11 12 13 14 15 16 17 k

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

(MSB)

Authenticator = <any value > (keyed-MD-5 authentication)

B-37

3GPP2 A.S0022-0 v1.0

3.6 0 1 2

A11-Session Update Acknowledge 3 (LSB) 4 5 6 7 Octet 9 22

4.2.9 Status 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

3 4

5 6

The supported Status values are listed in Table 4.2.9-1. Table 4.2.9-1
Hex Value 0 01H 80H 83H 85H 86H C9H CAH FDH FEH FFH Decimal Value 0 1 128 131 133 134 193 194 253 254 255 A11 Status 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 PMK not requested Update Denied QoS profileID not supported Update Denied insufficient resources Update Denied handoff in progress All other values reserved

A11 Status Values

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 ePCF 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 RFC 3115 [32]. For 1x, HRPD and eHRPD, this element may be included in the A11-Registration Request message to convey the PANID and CANID to the PDSN or HSGW. If ANID is sent to the HSGW, it shall be ignored. For 1x, this element may be included in A11-Registration Reply, A11-Registration Request, or A11Session Update messages to convey the Anchor PDSN Address for fast handoff when the ePCF 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

8 9 10 11 12 13 14 15 16 17 18 19

B-38

3GPP2 A.S0022-0 v1.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

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. For 1x, 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 ePCF shall send the All Dormant Indicator to its supporting PDSN when all service instances for the MS become dormant. The ePCF 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. For HRPD and eHRPD, this is the service option of the main service instance. For 1x, 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 ePCF. This element may be included in the A11-Registration Reply message to indicate the features enabled by the PDSN. For HRPD and eHRPD, 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 and eHRPD, this IE may be included in the A11-Registration Reply message to indicate SR_ID and Key for auxiliary A10 connection(s). For HRPD and eHRPD, 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 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 and eHRPD, this IE may be included in the A11-Session Update message to convey updated QoS information. For eHRPD, the ePCF shall include this IE with Application Type 06H, Application Sub Type 02H (eHRPD Mode indication) when establishing the main A10 connection if the HSGW A11 IP address is shared with PDSN. The ePCF should not include the eHRPD Mode indication when establishing the main A10 connection if the HSGW A11 IP address is not shared with PDSN. If the ePCF includes an eHRPD Mode indication in an A11-Registration Request message, the HSGW should ignore it. For eHRPD, this IE shall be included in the A11-Registration Request message with Application Type 06H, Application Sub Type 03H (eHRPD Indicators) if the eAT is operating in evolved mode and the eHRPD system supports optimized mobility between eHRPD and E-UTRAN. The ePCF shall not include eHRPD Indicators if the mobile is operating in legacy mode. The E-UTRAN Handoff Info indication is set to 1 if the sender is requesting information needed for handoff to E-UTRAN. For eHRPD, this IE shall be included in the A11-Registration Reply message with Application Type 0FH (Information), Application Sub Type 02H (HSGW H1 Address Information) to convey the HSGWs H1 IPv4 address when the ePCF establishes the main A10 connection.

B-39

3GPP2 A.S0022-0 v1.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

For eHRPD, the target PCF shall include this IE in the A11-Registration Request message with Application Type 0FH (Information), Application Sub Type 02H (HSGW H1 Address Information) when this message is sent for inter-HSGW handoff to convey the source HSGWs H1 IPv4 address received from the source PCF. For eHRPD, this IE may be included in the A11-Registration Reply message with Application Type 0FH (Information), Application Sub Type 03H (EPS Information), Parameter Types 01H (APN Information), 02H (S103 Source GRE Key Information) and 03H (P-GW IP Address) to send information needed for handoff from eHRPD to E-UTRAN in response to a request for this information. For handoff, this IE may be included in the A11-Registration Request message with Application Type 0FH (Information), Application Sub Type 03H (EPS Information), Parameter Types 01H (APN Information), 02H (S103 Source GRE Key Information) and 03H (P-GW IP Address) in preparation for handoff from E-UTRAN to eHRPD. For eHRPD, this IE may be included in the A11-Registration Reply message with Application Type 0FH (Information), Application Sub Type 04H (Additional HSGW Information), Parameter Types 01H (THSGW S103 IP Address) and 02H (T-HSGW S103 Key) to send the Target HSGW Address Information in preparation for handoff from E-UTRAN to eHRPD. Multiple instances of Parameter Type 02H may be included. For eHRPD, this IE may be included in the A11-Registration Request message to indicate that the eHRPD RAN is capable of GKE and to request PMK information. For eHRPD, this IE may be included in the A11-Registration Reply or A11-Session Update Request message with Application Type 0FH (Information), Application Sub Type 04H (Additional HSGW Information), Parameter Type 03H (PMK Information) to send PMK Information in support of GKE operation.
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)
25 26 27

Note that the Application Type and the Application Sub Type together correspond to the Vendor- NVSEType as defined in RFC 3115 [32]. Type: 86H

B-40

3GPP2 A.S0022-0 v1.0

1 2 3 4 5 6 7 8

Length: 3GPP2 Vendor ID: Application Type: Application Sub Type:

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 Value 04H Application Sub Type Name ANID Value 01H A11-Registration Request 3.1 Used in Message Reference

Access Network Identifiers (ANID) PDSN Identifier

All other values are reserved 05H Anchor P-P Address

a

01H

A11-Registration Request A11-Registration Reply A11-Session Update A11-Registration Request A11-Registration Request A11-Registration Request

3.1 3.2 3.5 3.1 3.1 3.1

All other values are reserved Indicators 06H All Dormant Indicatora eHRPD Mode eHRPD Indicators 01H 02H 03H

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-PDITa 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 01H 02H 03H A11-Registration Reply A11-Registration Reply A11-Registration Reply 3.2 3.2 3.2

All other values are reserved 01H A11-Registration Request 3.1

B-41

3GPP2 A.S0022-0 v1.0

Application Type Name Value

Application Sub Type Name GRE Segmentation Enabled Value 02H

Used in Message A11-Registration Request

Reference 3.1

All other values are reserved Additional Session Information 0CH Additional Session Information 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 Cause Code HSGW H1 Address Information EPS Information Additional HSGW Information 01H 02H 03H FEH FFH

All other values are reserved 01H A11-Registration Reply 3.2

All other values are reserved Information

0FH

01H 02H 03H 04H

A11-Registration Request A11-Registration Request A11-Registration Reply A11-Registration Request A11-Registration Reply

3.1 3.1 3.2 3.1 3.2

A11-Registration Reply
A11-Session Update

3.2
3.5 3.1

All other values are reserved HRPD Indicators 10H Emergency Services 01H A11-Registration Request

All other values are reserved All other values are reserved
1 2 3 4 5 6 7 8 9 10

a. This Application Sub Type does not apply to eHRPD systems. Application Data: For Application Type 04H (Access Network Identifiers), this field contains the PANID of the source ePCF in the PANID field (octets 1115) and the ANID of the target ePCF in the CANID field (octets 16-20). The PANID and CANID fields are formatted as specified for the Access Network Identifiers element (refer to A.S0016 [10]) 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 ePCFs 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 B-42

3GPP2 A.S0022-0 v1.0

1 2 3 4 5 6 7 8 9 10

Address is the P-P interface address (refer to X.S0057 [26]) of the anchor PDSN. For Application Type 06H (Indicators)and: Application Sub Type 01H (All dormant indicator), 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. Application Sub Type 02H (eHRPD Mode), this field shall be included if A11 IP addresses are shared between PDSN and HSGW. This field may be included if there are no IP addresses shared between PDSN and HSGW. This field is coded as follows:
3 Reserved 4 5 6 7 eHRPD Mode Octet 11

11 12 13 14 15 16

eHRPD Mode

This field is set to 1 if the eAT is operating in evolved mode and expects the receiver to operate as an HSGW. This field is set to 0 if the eAT is operating in legacy mode and expects the receiver to operate as a PDSN. Application Sub Type 03H (eHRPD Indicators), this field is coded as follows:
3 4 5 PMK 6 EUTRAN Handoff Info 7 Tunnel Mode Octet 11

2 Reserved

17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38

PMK

This field is set to 1 if the sending entity supports GKE and is requesting PMK information. Otherwise, this field is set to 0. The HSGW shall treat the absence of the PMK indication from an A11Registration Request message the same as PMK indication of 0. This field is set to 1 if this message is being used to request parameters needed to support handoff to E-UTRAN. Otherwise, this field is set to 0. The HSGW shall treat the absence of the E-UTRAN Handoff Info indication from an A11-Registration Request message the same as EUTRAN Handoff Info indication of 0. The field indicates whether or not the eAT is operating on the eHRPD radio, as follows: The Tunnel Mode indication is set to 0 to indicate that the eAT is operating on the eHRPD radio (e.g., the eAT is communicating directly via eHRPD). The Tunnel Mode indication is set to 1 to indicate that the eAT is not operating on the eHRPD radio (e.g., the eAT is communicating via a tunnel from another access technology).

E-UTRAN Handoff Info

Tunnel Mode

When the eHRPD system supports optimized mobility between eHRPD and E-UTRAN, the eAN/PCF includes the Tunnel Mode indication in all A11-Registration Request messages sent to the HSGW, and sets the value of the Tunnel Mode indication value appropriately. The eAN/PCF may not include the Tunnel Mode indication in any A11-Registration B-43

3GPP2 A.S0022-0 v1.0

1 2 3 4 5 6 7 8 9 10

Request messages sent to the HSGW if the eHRPD system does not support optimized mobility between eHRPD and E-UTRAN. The HSGW shall treat the absence of the Tunnel Mode indication from an A11-Registration Request message the same as Tunnel Mode indication of 0 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 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-ePCF 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

11 12 13 14 15 16 17 18 19 20 21

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:

0 (MSB)
22 23

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.

24 25 26 27 28

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 and eHRPD. B-44

3GPP2 A.S0022-0 v1.0

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

2 3

Service Option: Table 4.2.14-4 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

Table 4.2.14-5 HRPD and eHRPD Service Option Values

Service Option Value (hex) 003BH Description HRPD Main Service Instance

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

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. 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 (ePCF 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 ePCF in the A11-Registration Request message to request Short Data Indications via the GRE header. For Application Type 0BH (ePCF 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 ePCF 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.

B-45

3GPP2 A.S0022-0 v1.0

1 2

For Application Type 0CH (Additional Session Information), 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 ePCF): Forward ROHC Info Length (MSB) (MSB) Forward LargeCIDs Forward Profile {Forward ProfileCount: (MSB) }Forward Profile } Forward ROHC Info Reverse ROHC Info{0 (if sent by PDSN), 1 (if sent by ePCF): Reverse ROHC Info Length (MSB) (MSB) Reverse LargeCIDs Reverse MaxCID (LSB) Reverse MRRU (LSB) Reserved Reverse ProfileCount n n+1 n+2 n+3 n+4 n+5 n+6 Forward Profile (LSB) p p+1 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 = [00H-1FH] (MSB) Service Option

B-46

3GPP2 A.S0022-0 v1.0

0 (MSB) } Reverse Profile

4 Reverse Profile

Octet p

Reverse Profile { Reverse ProfileCount: (LSB) } Reverse ROHC Info } GRE Key Information Entry
1 2 3 4 5 6 7

p+1

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

Table 4.2.14-7 eHRPD Additional Session Info Service Option Values

Service Option Value (hex) 0040H 0043H 0048H Description HRPD Accounting Records Identifier HRPD Packet Data IP Service where Higher Layer Protocol is IP or ROHC HRPD auxiliary Packet Data IP Service with PDN multiplexing header

9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

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 ePCF 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 the main A10 connection) and different from the source IP address of the message containing this IE.

Key:

Source IP Address:

The remaining fields in this application type only apply in the ePCF to PDSN direction and are omitted when this NVSE is sent from the PDSN to the ePCF. B-47

3GPP2 A.S0022-0 v1.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

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 RFC 3095 [31]. This field contains the MRRU parameter for this ROHC channel as defined in RFC 3095 [31]. This field contains the LARGE_CIDS parameter for this ROHC channel as defined in RFC 3095 [31]. 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 Internet Assigned Numbers Authority [33]. 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 RFC 3095 [31]. This field contains the MRRU parameter for this ROHC channel as defined in RFC 3095 [31]. This field contains the LARGE_CIDS parameter for this ROHC channel as defined in RFC 3095 [31]. 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 Internet Assigned Numbers Authority [33]. 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.

Forward MaxCID: Forward MRRU: Forward LargeCIDs: Forward ProfileCount:

Forward Profile:

Reverse ROHC Info Length:

Reverse MaxCID: Reverse MRRU: Reverse LargeCIDs: Reverse ProfileCount:

Reverse Profile:

Octet 11

SR_ID = [00H-1FH]

B-48

3GPP2 A.S0022-0 v1.0

4 Reserved

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

Length: SR_ID: Use IP Flow Discrimination:

This field indicates the number of octets in this element following the Length field. 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 X.S0057 [26] for detailed information. If DSCP Included = 1, then this field contains the DSCP value of the flow identified in the corresponding Forward Flow ID B-49

DSCP Included:

Forward Flow Count: Entry Length: Forward Flow ID: DSCP:

3GPP2 A.S0022-0 v1.0

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

field. Otherwise, this field shall be set to 00 0000 and shall be ignored. 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. This field is set to zero if the IP flow has no Requested QoS Sub BLOB. For HRPD systems, this field contains the requested QoS Sub BLOB for this flow received from the AT. The format is as specified in X.S0057 [26]. This field contains the number of octets in the Forward Granted QoS field as a binary number. This field is set to zero if the IP flow has no Granted QoS Sub BLOB. For HRPD systems, this field contains the granted QoS Sub BLOB for this flow. The format is as specified in X.S0057 [26].

Forward Requested QoS Length:

Forward Requested QoS:

Forward Granted QoS Length:

Forward Granted QoS:

17 18 19

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 4 5 Reverse Flow Count 6 7 Octet 11 12 SR_ID = [00H-1FH]

(LSB) Reverse Granted QoS Length (MSB) Reverse Granted QoS

p p+1 p+2

(LSB) }Reverse Flow Entry

20 21 22 23 24

Length: SR_ID: Reverse Flow Count:

This field indicates the number of octets in this element following the Length field. This field identifies the service connection. This field indicates the number of Flow ID Entry contained in this Reverse QoS Information Entry.

B-50

3GPP2 A.S0022-0 v1.0

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

Entry Length: Reverse Flow ID: Flow State: Reverse Requested QoS Length:

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 X.S0057 [26] 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. This field is set to zero if the IP flow has no Requested QoS Sub BLOB. For HRPD systems, this field contains the requested QoS Sub BLOB for this flow received from the AT. The format is as specified in X.S0057 [26]. This field contains the number of octets in the Reverse Granted QoS field as a binary number. This field is set to zero if the IP flow has no Granted QoS Sub BLOB. For HRPD systems, this field contains the granted QoS Sub BLOB for this flow. The format is as specified in X.S0057 [26].

Reverse Requested QoS:

Reverse Granted QoS Length:

Reverse Granted QoS:

18 19

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)
20 21 22 23 24 25

Subscriber QoS Profile:

This field contains the Subscriber QoS Profile information sent from the PDSN or HSGW to the RAN. This field is coded as a list of Vendor Specific Attributes (VSAs) specified in X.S0057 [26] and each VSA includes Type, Length, Vendor-ID, VendorType, Vendor Length. Refer to X.S0057 [26] for detailed information.

26 27

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

(LSB) } Forward Flow Entry

B-51

3GPP2 A.S0022-0 v1.0

1 2 3 4 5 6 7 8 9 10

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 X.S0057 [26] 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 X.S0057 [26] for detailed information.

11 12

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

(LSB) } Reverse Flow Entry

13 14 15 16 17 18 19 20 21 22

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 X.S0057 [26] 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 X.S0057 [26] for detailed information.

23 24 25

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 1 2 3 4 MaxCID (LSB) MRRU (LSB) Reserved 5 6 7 Octet 1 2 3 4 5

B-52

3GPP2 A.S0022-0 v1.0

Octet 6 n

ProfileCount Profile {ProfileCount: (MSB) } Profile

1 2 3 4 5 6 7 8 9 10 11 12 13

Profile (LSB)

n+1

MaxCID: MRRU: LargeCIDs: ProfileCount:

This field contains MAX_CID supported by the PDSN as defined in RFC 3095 [31]. This field contains the MRRU supported by the PDSN as defined in RFC 3095 [31]. This field contains the LARGE_CIDS supported by the PDSN as defined in RFC 3095 [31]. 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 Internet Assigned Numbers Authority [33].

Profile:

14 15 16

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:
0 1 2 3 4 5 6 7 Octet 1

Cause Value
17 18 19

Cause Value:

This field is a single octet field as indicated in the table below. Table 4.2.14-8 Cause Values
Values 01H 02H Meaning Packet data session release Air link lost

20

21 22

For Application Type 0FH (Information), Application Sub Type 02H (HSGW H1 Address Information), the Application Data field is coded as follows:
0 (MSB) 1 2 3 4 5 6 7 Octet 1 2 3 4 (LSB) 5 Address Type HSGW H1 IP Address

23

Address Type:

This field indicates the type and format of the IP Address that follows. B-53

3GPP2 A.S0022-0 v1.0

Value 01H

Address Type Internet Protocol IPv4 All other values reserved.

Length of IP Address 4 octets

1 2 3 4

HSGW H1 IP Address:

This field has a variable length that is dependent on the value of the H1 Address Type field. This field identifies the IP address of the H1 interface on the HSGW.

5 6

For Application Type 0FH (Information), Application Sub Type 03H (EPS Information) the Application Data field is coded as follows:
0 1 2 3 4 5 6 7 Octet variable variable variable PDN Information Entry 1 PDN Information Entry 2 PDN Information Entry M

PDN Information Entry

0 1 2

This field contains information for one PDN and is coded as follows.
3 4 5 6 7 Octet 1 2 variable variable PDN Information Entry Length PDN Parameter 1 PDN Parameter 2 PDN Parameter n

8 9 10

PDN Information Entry Length: This field contains the number of octets in this entry following this field as a binary number. PDN Parameter:
0 1 2

This field contains a PDN parameter and is coded as follows.

3 4 5 6 7 Octet 1 2 variable Parameter Type Parameter Length Parameter Value

11 12 13 14 15 16

Parameter Type:

This field indicates the type of parameter included in the Parameter Value field. Possible values are: 01H (APN Information), 02H (APN Key Information), and 03H (P-GW IP Address). This field contains the number of octets in this PDN Parameter following this field as a binary number. This field is coded as shown below.

Parameter Length: Parameter Value:

17

When Parameter Type is set to 01H (APN Information), the Parameter Value is coded as follows:
0 (MSB) 1 2 3 4 APN 5 6 7 Octet 3

B-54

3GPP2 A.S0022-0 v1.0

7 (LSB)

Octet m

1 2 3

APN:

This field contains the fully qualified domain name of the access provider as an ASCII character string.

4 5

When Parameter Type is set to 02H (S103 Source GRE Key Information), the Parameter Value is coded as follows:
0 (MSB) 1 2 3 4 5 6 7 Octet 3 4 5 (LSB) 6 S103 Source GRE Key

6 7 8 9

S103 Source GRE Key:

This is a four octet field. This field contains the same value that is used in the Key field in the GRE header on the associated connection between P-GW and HSGW or S-GW.

10

When Parameter Type is set to 03H (P-GW IP Address), the Parameter Value is coded as follows:
Address Type (MSB) P-GW IP Address (LSB) 3 4 n

11 12

Address Type:
Value 01H 02H

This field indicates the type and format of the IP Address that follows.
Address Type Internet Protocol IPv4 Internet Protocol IPv6 All other values reserved. Length of IP Address 4 octets variable

13 14 15

P-GW IP Address:

This field has a variable length that is dependent on the value of the Address Type field. This field identifies the IP address of the P-GW that terminates the GRE connection identified in this NVSE.

16 17

For Application Type 0FH (Information), Application Sub Type 04H (Additional HSGW Information) the Application Data field is coded as follows:
0 1 2 3 4 5 6 7 Octet variable variable variable HSGW Parameter Entry 1 HSGW Parameter Entry 2 HSGW Parameter Entry N

18

HSGW Parameter Entry

This field contains HSGW information and is coded as follows. B-55

3GPP2 A.S0022-0 v1.0

Octet 1 2 variable

Parameter Type Parameter Length Parameter Value

1 2 3 4 5 6

Parameter Type:

This field indicates the type of parameter included in the Parameter Value field. Possible values are: 01H (T-HSGW S103 IP Address), 02H (T-HSGW S103 Key), 03H (PMK Information). This field contains the number of octets in this entry following this field as a binary number. This field contains parameter information and is coded as follows.

Parameter Length: Parameter Value:

7 8

When the Parameter Type is set to 01H (T-HSGW S103 IP Address), the Parameter Value is coded as follows.
0 (MSB) T-HSGW S103 IP Address (LSB) 1 2 3 4 5 6 7 Octet 3 4 5 n Address Type

Address Type:
Value 01H 02H

This field indicates the type and format of the IP Address that follows.
Address Type Internet Protocol IPv4 Internet Protocol IPv6 All other values reserved. Length of IP Address 4 octets variable

10 11 12

T-HSGW S103 IP Address:

This field has a variable length that is dependent on the value of the S103 Address Type field. This field identifies the IP address of the S103 interface on the T-HSGW.

13

When Parameter Type is set to 02H (T-HSGW S103 Key), the Parameter Value is coded as follows:
0 (MSB) (LSB) (MSB) T-HSGW S103 Key 1 2 3 4 APN 5 6 7 Octet 3 m m+1 m+2 m+3 (LSB) m+4

14 15

APN:

This field contains the fully qualified domain name of the access provider as an ASCII character string.

B-56

3GPP2 A.S0022-0 v1.0

1 2 3

T-HSGW S103 Key:

This is a four octet field. This field contains the same value that is used in the Key field in the GRE header on the connection from the S-GW to the T-HSGW associated with the specified APN.

4 5

When the Parameter Type is set to 03H (PMK Information), the HSGW Parameter Entry is coded as follows.
0 1 2 3 4 5 6 7 Octet m m+1 m+2 n n+1 (LSB) (MSB) PMK-n Lifetime p p+1 p+2 p+3 (LSB) p+4 Parameter Type = [03H] Parameter Length PMK Count PMK n Length (MSB) PMK-n

6 7 8 9 10 11 12 13 14 15

Parameter Type Parameter Length PMK Count PMK Length PMK PMK Lifetime

This field indicates the type of timer information. This field shall be set to 03H (PMK Information). This field contains the number of octets in this entry following this field as a binary number. This field shall be set to the number of occurrences of the PMK field in this parameter record This field indicates the length of a PMK in octets. This field contains a PairwiseMasterKey. This field indicates the length of time (in seconds) for which the included PMKs are valid as an unsigned 32-bit binary number.

16 17 18

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

19 20 21 22

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.

B-57

3GPP2 A.S0022-0 v1.0

1 2 3 4 5 6

(This page intentionally left blank)

B-58