Interoperability Specification (IOS) for High Rate Packet ... · Interoperability Specification (IOS) for High Rate Packet ... ... 1 Foreword

COPYRIGHT © 2006, 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 [email protected]. Requests to reproduce individual Organizational Partner's documents should be directed to that Organizational Partner. See www.3gpp2.org for more information.

3GPP2 A.S0008-A v1.0 Date: March 2006

Interoperability Specification (IOS) for High Rate Packet 1

Data (HRPD) Radio Access Network Interfaces with 2

Session Control in the Access Network 3

4

5

6

A.S0008-A v1.0 March 2006 IOS HRPD

i

Table of Contents 1

Foreword....................................................................................................................................................viii 2

1 Introduction...................................................................................................................................1-1 3

1.1 Overview.......................................................................................................................................1-1 4

1.1.1 Purpose..........................................................................................................................................1-2 5

1.1.2 Scope.............................................................................................................................................1-2 6

1.1.3 Document Convention ..................................................................................................................1-2 7

1.2 References.....................................................................................................................................1-2 8

1.2.1 Normative References...................................................................................................................1-2 9

1.2.2 Informative References.................................................................................................................1-3 10

1.3 Terminology..................................................................................................................................1-3 11

1.3.1 Acronyms......................................................................................................................................1-3 12

1.3.2 Definitions ....................................................................................................................................1-5 13

1.4 HRPD IOS Architecture Reference Model (SC/MM in the AN) .................................................1-9 14

1.5 HRPD Micro-Mobility and Macro-Mobility Concepts ..............................................................1-10 15

1.6 Compatibility with IOS Standards ..............................................................................................1-10 16

1.7 HRPD IOS Assumptions.............................................................................................................1-11 17

1.7.1 IOS Assumptions ........................................................................................................................1-11 18

1.7.2 QoS Assumptions .......................................................................................................................1-12 19

1.8 State Definition ...........................................................................................................................1-12 20

1.8.1 Packet Data Session State ...........................................................................................................1-12 21

1.8.2 IP Flow State...............................................................................................................................1-13 22

2 HRPD IOS Interfaces....................................................................................................................2-1 23

2.1 A1/A1p Interface (HRPD AN - MSC)..........................................................................................2-1 24

2.2 A8-A9 (AN - PCF) Interface ........................................................................................................2-2 25

2.3 A10-A11 (PCF - PDSN) Interface................................................................................................2-2 26

2.4 A12 (AN - AN-AAA) Interface....................................................................................................2-2 27

2.4.1 PPP Session...................................................................................................................................2-3 28

2.4.1.1 Establishment.................................................................................................................2-3 29

2.4.1.2 Termination ...................................................................................................................2-3 30

2.4.1.3 Access Authentication ...................................................................................................2-3 31

2.4.2 AN-AAA Support .........................................................................................................................2-3 32

2.4.3 AN-AAA Requirements................................................................................................................2-4 33

2.5 A13 (AN - AN) Interface..............................................................................................................2-5 34

2.5.1 A13 Interface Network/Transport Protocol Specification ............................................................2-5 35

2.5.2 A13 Interface Procedures..............................................................................................................2-6 36

A.S0008-A v1.0 IOS HRPD March 2006

ii

2.5.2.1 A13-Session Information Request.................................................................................2-6 1

2.5.2.1.1 Successful Operation ..................................................................................................2-6 2

2.5.2.1.2 Failure Operation........................................................................................................2-6 3

2.5.2.2 A13-Session Information Response ..............................................................................2-7 4



2.5.2.3 A13-Session Information Confirm ................................................................................2-7 7



2.5.2.4 A13-Session Information Reject....................................................................................2-7 10



3 HRPD IOS Call Flows..................................................................................................................3-1 13

3.1 AT Originates HRPD Session.......................................................................................................3-1 14

3.1.1 AT Originates HRPD Session - Successful Access Authentication .............................................3-1 15

3.1.2 AT Originates HRPD Session - Unsuccessful Access Authentication .........................................3-3 16

3.2 Re-authentication ..........................................................................................................................3-4 17

3.2.1 Re-authentication of an AT in Dormant State ..............................................................................3-4 18

3.2.2 Re-authentication of an AT in Active State ..................................................................................3-5 19

3.3 Data Delivery................................................................................................................................3-6 20

3.3.1 Network Initiated Call Re-activation from Dormant State ...........................................................3-6 21

3.3.2 AT Initiated Call Re-activation from Dormant State (Existing HRPD Session) ..........................3-8 22

3.3.3 AT Initiated Packet Data Session Establishment from an Established HRPD Session ................3-9 23

3.4 Connection Release.....................................................................................................................3-10 24

3.4.1 Connection Release on HRPD Network - Initiated by the AT ...................................................3-10 25

3.4.2 Connection Release on HRPD Network - Initiated by the AN...................................................3-11 26

3.5 HRPD Session Release ...............................................................................................................3-12 27

3.5.1 HRPD Session Release - Initiated by the AT or AN (A8 Connections Exist)............................3-12 28

3.5.2 HRPD Session Release - Initiated by the AT or AN (A8 Connections do not Exist).................3-13 29

3.6 Packet Data Session Release - Initiated by the PDSN................................................................3-14 30

3.7 Dormant Handoff of HRPD AT between ANs - Served by the Same PDSN.............................3-15 31

3.7.1 AN-AN Dormant Handoff with Successful Retrieval of HRPD Session Information ...............3-15 32

3.7.2 AN-AN Dormant Handoff with HRPD Session Information Transfer Failure ..........................3-18 33

3.8 Miscellaneous Active HRPD Session Call Flows.......................................................................3-20 34

3.8.1 Deactivation/Activation of Data Flow During an Active HRPD Packet Data Session ..............3-20 35

3.9 Multiple Connection Procedures.................................................................................................3-21 36

3.9.1 Initial HRPD Call Setup (Default IP Flows Establishment) .......................................................3-21 37


iii

3.9.2 IP Flow Mapping Update with Service Connection Establishment............................................3-21 1

3.9.3 IP Flow Mapping Update with Service Connection Release ......................................................3-22 2

3.9.4 IP Flow to A8/A10 Connection Mapping Update ......................................................................3-23 3

3.9.5 Subscriber QoS Profile Delivery ................................................................................................3-24 4

3.10 Support for Data Over Signaling Protocol..................................................................................3-25 5

3.10.1 AT Originated DOS ....................................................................................................................3-25 6

3.10.2 AT Terminated DOS...................................................................................................................3-26 7

3.10.2.1 DOS Delivery from the PDSN to the AT ..................................................................3-26 8

3.10.2.2 DOS Request from the PDSN – AN Refuses Request ..............................................3-27 9

4 HRPD and 1x IOS Transition Call Flows.....................................................................................4-1 10

4.1 Dormant Cross System Handoff - AT Served by the Same PDSN...............................................4-1 11

4.1.1 1x to HRPD Dormant Packet Data Session Handoff - Existing HRPD Session...........................4-1 12

4.1.2 1x to HRPD Dormant Packet Data Session Handoff - New HRPD Session ................................4-3 13

4.1.3 HRPD to 1x Dormant Packet Data Session Handoff....................................................................4-5 14

4.2 MS/AT Terminated Voice Call During Active HRPD Packet Data Session................................4-7 15

4.2.1 MS/AT Terminated Voice Call During Active HRPD Packet Data Session (Intra-PDSN/Inter-16

PCF) ..............................................................................................................................................4-7 17

4.2.2 MS/AT Terminated Voice Call During Active HRPD Packet Data Session (Intra-PCF) ............4-9 18

4.3 1x to HRPD Active Packet Data Session Handoff .....................................................................4-11 19

4.4 Status Management Supported by Feature Invocation................................................................4-12 20

4.5 CSNA in the HRPD System .......................................................................................................4-13 21

4.5.1 SMS – Mobile Originated Point-to-Point (ADDS Transfer) ......................................................4-13 22

4.5.2 SMS – Mobile Terminated Point-to-Point (ADDS Page / ADDS Page Ack) ............................4-14 23

4.5.3 1x Page Delivery to the MS/AT in an HRPD System (Paging Request)....................................4-15 24

4.5.4 HRPD Page Delivery in a 1x System - MS/AT Idle...................................................................4-16 25

4.5.5 HRPD Page Delivery in a 1x System - MS/AT on a Traffic Channel (TCH) ............................4-18 26

4.6 Mobility Management for CSNA in the HRPD System.............................................................4-20 27

4.6.1 1x Registration Over HRPD .......................................................................................................4-20 28

5 Messages, Information Elements and Timer Definitions..............................................................5-1 29

5.1 Message Definitions......................................................................................................................5-1 30

5.1.1 A13 Message Definitions..............................................................................................................5-1 31

5.1.1.1 A13-Session Information Request.................................................................................5-1 32

5.1.1.2 A13-Session Information Response ..............................................................................5-2 33

5.1.1.3 A13-Session Information Confirm ................................................................................5-5 34

5.1.1.4 A13-Session Information Reject....................................................................................5-5 35

5.2 Information Element Definitions ..................................................................................................5-7 36

5.2.1 A13 Information Element Definitions ..........................................................................................5-7 37


iv

5.2.1.1 Information Element Identifiers ....................................................................................5-7 1

5.2.1.2 Cross Reference of IEs with Messages..........................................................................5-7 2

5.2.1.3 A13 Message Type ........................................................................................................5-8 3

5.2.1.4 Unicast Access Terminal Identifier (UATI 128). ..........................................................5-8 4

5.2.1.5 Security Layer Packet....................................................................................................5-8 5

5.2.1.6 SectorID.........................................................................................................................5-9 6

5.2.1.7 Cause .............................................................................................................................5-9 7

5.2.1.8 Mobile Identity (MN ID).............................................................................................5-10 8

5.2.1.9 PDSN IP Address ........................................................................................................5-10 9

5.2.1.10 Access Network Identifiers .......................................................................................5-11 10

5.2.1.11 Session State Information Record .............................................................................5-11 11

5.2.1.12 Extended Session State Information Record .............................................................5-12 12

5.2.1.13 Forward QoS Information .........................................................................................5-12 13

5.2.1.14 Reverse QoS Information ..........................................................................................5-14 14

5.2.1.15 Subscriber QoS Profile ..............................................................................................5-15 15

5.3 Timer Definitions........................................................................................................................5-16 16

5.3.1 Timer Descriptions......................................................................................................................5-16 17

5.3.1.1 Timer TA13req ................................................................................................................5-16 18

5.3.1.2 Timer Tnet_conn...............................................................................................................5-16 19

Annex A Transport Change Text (Normative) .......................................................................................... 1 20

Annex B A1/A1p Interface (BS - MSC) Interface Change Text (Normative) .......................................... 1 21

Annex C A8-A9 (AN - PCF) Interface Change Text (Normative)............................................................ 1 22

Annex D A10-A11 (AN/PCF - PDSN) Interface Change Text (Normative) ............................................ 1 23

Annex E A12 RADIUS Attributes (Normative)........................................................................................ 1 24

25

26


v

Table of Figures 1

2

Figure 1.4-1 HRPD IOS Architecture Reference Model (SC/MM in the AN) ....................................1-10 3

Figure 1.5-1 Packet Data Mobility Architecture for HRPD .................................................................1-10 4

Figure 1.8.1-1 Packet Data Session State Transitions ...........................................................................1-13 5

Figure 1.8.2-1 IP Flow State Transitions...............................................................................................1-13 6

Figure 2.4-1 RADIUS Protocol Reference Model .................................................................................2-3 7

Figure 3.1.1-1 Initial AT Origination with HRPD Session Establishment and Key Exchange...............3-1 8

Figure 3.1.2-1 Initial AT Origination - Unsuccessful Access Authentication.........................................3-3 9

Figure 3.2.1-1 Re-authentication of an AT in Dormant State .................................................................3-4 10

Figure 3.2.2-1 Re-authentication of an AT in Active State.....................................................................3-5 11

Figure 3.3.1-1 Network Initiated Call Re-activation from Dormant State ..............................................3-6 12

Figure 3.3.2-1 AT Initiated Call Re-activation from Dormant State (Existing HRPD Session) .............3-8 13

Figure 3.3.3-1 AT Initiated Packet Data Session Establishment from Established HRPD Session........3-9 14

Figure 3.4.1-1 AT Initiated Connection Release ...................................................................................3-10 15

Figure 3.4.2-1 AN Initiated Connection Release...................................................................................3-11 16

Figure 3.5.1-1 AT or AN Initiated HRPD Session Release (A8 Connections Exist)............................3-12 17

Figure 3.5.2-1 AT Initiated HRPD Session Release (A8 Connections do not Exist)............................3-13 18

Figure 3.6-1 PDSN Initiated Packet Data Session Release ..................................................................3-14 19

Figure 3.7.1-1 Inter-PCF/Intra-PDSN Dormant AN-AN HO - Successful Operation ..........................3-15 20

Figure 3.7.2-1 Inter-PCF/Intra-PDSN Dormant AN-AN HO - Transfer Failure ..................................3-18 21

Figure 3.8.1-1 Activation /De-activation of Data Flow During Active HRPD Session........................3-20 22

Figure 3.9.2-1 IP Flow Mapping Update with Service Connection Establishment...............................3-21 23

Figure 3.9.3-1 IP Flow Mapping Update with Service Connections Release .......................................3-22 24

Figure 3.9.4-1 IP Flow Mapping Update...............................................................................................3-23 25

Figure 3.9.5-1 Subscriber QoS Profile Transfer....................................................................................3-24 26

Figure 3.10.1-1: HRPD DOS from an AT to the PDSN...........................................................................3-25 27

Figure 3.10.2.1-1: HRPD DOS from the PDSN to the AT......................................................................3-26 28

Figure 3.10.2.2-1: DOS from the PDSN to the AT – AN Refuses DOS Request ...................................3-27 29

Figure 4.1.1-1 1x to HRPD Dormant Packet Data Session HO - Existing HRPD Session .....................4-1 30

Figure 4.1.2-1 1x to HRPD Dormant Packet Data Session Handoff - New HRPD Session ...................4-3 31

Figure 4.1.3-1 HRPD to 1x Dormant Packet Data Session Handoff.......................................................4-5 32

Figure 4.2.1-1 Voice Call Termination During Active HRPD Packet Data Session (Inter-PCF) ...........4-7 33

Figure 4.2.2-1 Voice Call Termination During Active HRPD Packet Data Session (Intra-PCF) ...........4-9 34

Figure 4.4-1 Terminal Based Status Management (Using Feature Invocation) ...................................4-12 35

Figure 4.5.1-1 Mobile Originated Point-to-Point SMS in an HRPD System........................................4-13 36


vi

Figure 4.5.2-1 Mobile Terminated Point-to-Point SMS in an HRPD System.......................................4-14 1

Figure 4.5.3-1 1x Page Delivery to the MS/AT in an HRPD System ...................................................4-15 2

Figure 4.5.4-1 HRPD Page Delivery in a 1x System - MS/AT Idle......................................................4-16 3

Figure 4.5.5-1 HRPD Page Delivery in a 1x System - MS/AT on TCH...............................................4-18 4

Figure 4.6.1-1 1x Registration Over HRPD ..........................................................................................4-20 5

Figure Annex E-1 3GPP2 RADIUS Attribute Format .............................................................................. 1 6

Figure Annex E-2 AT Hardware Identifier ............................................................................................... 1 7

8

9

10


vii

Table of Tables 1

2

Table 2-1 Terminology Cross Reference between 1x and HRPD..........................................................2-1 3

Table 2.1-1 A1 and A1p Messages [A.S0014-C] Implemented in this Document.................................2-1 4

Table 5.2.1.2-1 Cross Reference of IEs with Messages............................................................................5-7 5

6

7


viii

Foreword 1

While based on [11]~[17], the interface specifications in this document are compatible with an Inter-2

Operability Specification (IOS) v4.0 (refer to [11]) or higher release. Refer to section 1.6. This document 3

describes the interface protocols and procedures to support High Rate Packet Data (HRPD) IOS features 4

listed in section 1.1. Conformance to the IOS may be claimed on a feature-by-feature and/or interface-by-5

interface basis. If conformance on a given interface is claimed for the HRPD IOS feature, it shall be 6

supported as defined in this standard. 7

8

Revision History

November 2001 A.S0007-0 v2.0 publication.

May 2003 A.S0008-0 v3.0 publication.

March 2006 A.S0008-A v1.0 publication.

9

10


1-1

1 Introduction 1

2

1.1 Overview 3

This document includes a description of the interface protocols and procedures to support the following 4

features and functions. Conformance to this standard may be claimed on a feature by feature and/or 5

interface by interface basis. If conformance on a given interface is claimed for a feature, it shall be 6

supported as defined in this standard. 7

New features and enhancements supported in this release: 8

• HRPD-1x cdma2000®1 Circuit Services Notification Application (CSNA) 9

• Multiple personalities in the session configuration protocol 10

• Multi-Flow Packet Application (MFPA) and Quality of Service (QoS) 11

• Data Over Signaling (DOS) 12

• Generic Routing Encapsulation (GRE) segmentation 13

• Update of IOS annexes to map to IOS v5.0 (refer to [11]) 14

Features and functions explicitly supported in this standard: 15

• AT (Access Terminal) originates an HRPD session (including access authentication) 16

• Re-authentication of an AT 17

• HRPD data delivery (both AT terminated and AT originated) 18

• HRPD connection release 19

• HRPD session release 20

• Dormant handoff of HRPD AT between ANs served by the same Packet Data Serving Node (PDSN) 21

• Dormant 1x handoff to/from HRPD, served by the same PDSN 22

• MS (Mobile Station)/AT terminated voice call during active HRPD data session 23

• 1x to HRPD packet data session handoff 24

• Loss of the airlink during an active HRPD session 25

• Status Management supported by feature invocation 26

• HRPD-1x cdma2000 Circuit Services Notification Application 27

• Multiple personalities in the session configuration protocol 28

• Multi-Flow Packet Application and Quality of Service 29

• Data Over Signaling (DOS) 30

• GRE segmentation 31

• Update of IOS annexes to re-map to IOS v5.0 (refer to [11]) 32

Note: Fast Handoff is not supported in this version of the standard. Fast handoff related information 33

elements (Anchor PDSN Address, Anchor P-P Address, PDSN Address) specified in any messages in this 34

version of the standard are not included in HRPD systems. 35

1 cdma2000® is the trademark for the technical nomenclature for certain specifications and standards of the Organizational Partners (OPs) of 3GPP2. Geographically (and as of the date of publication), cdma2000® is a registered trademark of the Tele-communications Industry Association (TIA-USA) in the United States.


1-2

1.1.1 Purpose 1

The purpose of this document is to provide a standard and call flows for the IOS HRPD interfaces within 2

the Radio Access Network (RAN). 3

1.1.2 Scope 4

This document provides an interoperability specification for a RAN that supports HRPD. The RAN 5

architecture in this document logically locates the Session Control and Mobility Management (SC/MM) 6

function in the Access Network (AN). This document contains message procedures and formats necessary 7

to obtain this interoperability. 8

9

1.1.3 Document Convention 10

“Shall” and “shall not” identify requirements to be followed strictly to conform to the standard and from 11

which no deviation is permitted. “Should” and “should not” indicate that one of several possibilities is 12

recommended as particularly suitable, without mentioning or excluding others; that a certain course of 13

action is preferred but not necessarily required; or (in the negative form) that a certain possibility or 14

course of action is discouraged but not prohibited. “May” and “need not” indicate a course of action 15

permissible within the limits of the standard. “Can” and “cannot” are used for statements of possibility 16

and capability, whether material, physical, or causal. 17

In the Annexes that show deltas relative to the base documents [11]~[17], underscore indicates additions, 18

strikeout indicates deletions, and an ellipsis (…) indicates that the base document is unchanged. 19

1.2 References 20

21

1.2.1 Normative References 22

For consistency between RAN specifications, the most commonly referenced documents [1~17] are 23

maintained or left as “Reserved” if not used in this specification. 24

[1] 3GPP2: C.S0001-D v2.0, Introduction to cdma2000 Standards for Spread Spectrum Systems, 25

July 2005. 26

[2] 3GPP2: C.S0002-D v2.0, Physical Layer Standard for cdma2000 Spread Spectrum Systems, 27

July 2005. 28

[3] 3GPP2: C.S0003-D v2.0, Medium Access Control (MAC) Standard for cdma2000 Spread 29

Spectrum Systems, July 2005. 30

[4] 3GPP2: C.S0004-D v2.0, Signaling Link Access Control (LAC) Standard for cdma2000 31

Spread Spectrum Systems, July 2005. 32

[5] 3GPP2: C.S0005-D v2.0, Upper Layer (Layer 3) Signaling Standard for cdma2000 Spread 33

Spectrum Systems, July 2005. 34

[6] 3GPP2: C.S0006-D v2.0, Analog Signaling Standard for cdma2000 Spread Spectrum 35

Systems, July 2005. 36

[7] Reserved. 37

[8] 3GPP2: X.S0011-D, Wireless IP Network Standard, February 2006. 38

[9] Reserved. 39

[10] 3GPP2: C.S0024-A v2.0, cdma2000 High Rate Packet Data Air Interface Specification, June 40

2005. 41


1-3

[11] 3GPP2: A.S0011-C, Interoperability Specification (IOS) for cdma2000 Access Network 1

Interfaces – Part 1 Overview, February 2005. 2


Interfaces – Part 2 Transport, February 2005. 4


Interfaces – Part 3 Features, February 2005. 6


Interfaces – Part 4 (A1, A1p, A2, and A5 Interfaces), February 2005. 8


Interfaces – Part 5 (A3 and A7 Interfaces), February 2005. 10





[18] 3GPP2: C.R1001-E v1.0, Administration of Parameter Value Assignments for cdma2000 15

Spread Spectrum Standards, August 2005. 16

[19] IETF: RFC 768, User Datagram Protocol, August 1980. 17

[20] IETF: RFC 793, Transmission Control Protocol, September 1981. 18

[21] IETF: RFC 1661, Point-to-Point Protocol, July 1994. 19

[22] IETF: RFC 1662, PPP in HDLC-Like Framing, July 1994. 20

[23] IETF: RFC 1750, Randomness Recommendations for Security, December 1994. 21

[24] IETF: RFC 1994, PPP Challenge Handshake Authentication Protocol (CHAP), August 22

1996. 23

[25] IETF: RFC 2486, The Network Access Identifier, January 1999. 24

[26] IETF: RFC 2865, Remote Authentication Dial In User Service (RADIUS), June 2000. 25

[27] 3GPP2: C.S0075 v1.0, cdma2000 Interworking Specification for 3G1x and High Rate Packet 26

Data Systems, March 2006. 27

1.2.2 Informative References 28

[1] IETF: RFC 2002, IP Mobility Support, October 1996. 29

30

1.3 Terminology 31

32

1.3.1 Acronyms 33

3GPP2 3rd Generation Partnership Project 2 AAA Authentication, Authorization and Accounting ACCM Async-Control-Character-Map AN Access Network ANID Access Network Identifiers


1-4

AT Access Terminal BLOB BLock Of Bits BS Base Station CANID Current Access Network Identifiers CHAP Challenge Handshake Authentication Protocol CSNA Circuit Services Notification Application CVSE Critical Vendor/Organization Specific Extension DOS Data Over Signaling DRI Data Ready Indicator GRE Generic Routing Encapsulation HRPD High Rate Packet Data IE Information Element IMSI International Mobile Subscriber Identity IOS Inter-Operability Specification IP Internet Protocol IWS Interworking Solution LCP Link Control Protocol MAC Medium Access Control MEI Mobility Event Indicator MEID Mobile Equipment Identity MN ID Mobile Node Identification MS Mobile Station MSC Mobile Switching Center MSCe Mobile Switching Center Emulation NAI Network Access Identifier NID Network Identification NVSE Normal Vendor Specific Extension PANID Previous Access Network Identifiers PCF Packet Control Function PDSI Packet Data Service Instance PDSN Packet Data Serving Node PPP Point-to-Point Protocol PZID Packet Zone Identification QoS Quality of Service RADIUS Remote Authentication Dial-In User Service RAN Radio Access Network RLP Radio Link Protocol SC/MM Session Control / Mobility Management SDB Short Data Burst SID System Identification SLP Signaling Link Protocol SMS Short Message Service SSIR Session State Information Record


1-5

TCH Traffic Channel TCP Transmission Control Protocol UATI Unicast Access Terminal Identifier VPI Virtual Page Indicator VSA Vendor Specific Attribute

1

1.3.2 Definitions 2

1x Refer to “cdma2000 1x” below. 3

Access Authentication A procedure in which the Access Terminal (AT) is authenticated by the AN-4

AAA (Access Network Authentication, Authorization and Accounting 5

entity). 6

Access Stream The HRPD stream whose end-points are the AT and the access network 7

(AN). This stream is used for access authentication. 8

Access Network A logical entity in the Radio Access Network (RAN) used for radio 9

communications with the Access Terminal (AT). An AN is equivalent to a 10

base station (BS) in 1x systems. The PCF definition is provided in [11]. In 11

addition, the AN for this specification logically contains the SC/MM 12

function. Refer to the definition of SC/MM function. 13

Access Terminal A device providing data connectivity to a user. An AT may be connected to a 14

computing device such as a laptop personal computer or it may be a self-con-15

tained data device such as a personal digital assistant. An AT is equivalent to 16

a mobile station in 1x systems. 17

AN-AAA An entity that performs access authentication, authorization, and accounting 18

functions for the RAN. 19

cdma2000 1x The version of cdma2000 defined by [1]~[6] and also supported by 20

[11]~[17]. 21

Circuit-Switched MSC A circuit-switched MSC provides processing, control and bearer path for 22

calls and services. The MSC provides signaling capability via an SS7-based 23

connection to the BS PCF on the A1 interface and bearer paths via terrestrial 24

circuits on the A2 and A5 interfaces. 25

Connection A connection, in this specification, refers to either an air interface connection 26

or a signaling or user traffic connection in the RAN. An air interface 27

connectionis a particular state of the air-link in which the access terminal is 28

assigned a Forward Traffic Channel, a Reverse Traffic Channel and 29

associated Medium Access Control (MAC) Channels. During a single HRPD 30

session the AT and the AN can open and can close a connection multiple 31

times. A signaling or user traffic connection is a particular state shared 32

between two nodes in the RAN or between a node in the RAN and a network 33

entity outside the RAN. Examples of a connection in the RAN are A8 and 34

A10 connections, which are used for user traffic. 35

Flow ID An identifier which, combined with a direction, uniquely identifies an IP 36

flow for an AT. 37

Granted QoS Sub BLOB The QoS Sub BLOB (Block of Bits) containing the QoS granted for a given 38

IP flow. Refer to [8] and [10]. 39

HRPD Packet Zone Area that is serviced by one HRPD PCF. 40


1-6

HRPD session An HRPD session refers to a shared state between the AT and the AN. This 1

shared state stores the protocols and protocol configurations that were 2

negotiated and are used for communications between the AT and the AN. 3

Other than to open a session, an AT cannot communicate with an AN 4

without having an open session. Note that it is possible that the A10/A11 5

connection is not established even though the HRPD session is established. 6

Refer to [10], Section 1.8. 7

Hybrid MS/AT A device capable of operating on both 1x and HRPD systems. 8

IP Flow A unidirectional bearer traffic flow identified by a particular pair of source 9

and destination IP addresses and port numbers. An IP flow is identified by 10

the Flow ID and direction. 11

IWS Interworking Solution (IWS) is logically located in the AN and provides the 12

functionality to translate between IOS A1/A1p messages received from/sent 13

to a Mobile Switching Center (MSC) and 3G1x service messages 14

sent/received over the air interface. 15

Link Flow Unidirectional data flow over the air interface. Refer to RLP (Radio Link 16

Protocol) Flow. 17

Mobile Switching Center The MSC switches MS/AT-originated or MS/AT-terminated traffic. An MSC 18

connects to one or more BS PCFs . It may connect to other public networks 19

(PSTN, ISDN, etc.), other MSCs in the same network, or MSCs in different 20

networks. (It has been referred to as Mobile Telephone Switching Office, 21

MTSO.) It provides the interface for user traffic between the wireless 22

network and other public switched networks, or other MSCs. 23

In this document, for signaling, the term MSC refers to either a circuit-24

switched MSC or an MSCe. For bearer path, the term MSC refers to either a 25

circuit-switched MSC or a MGW. In situations where a statement applies to 26

either the circuit-switched or packet-based MSC exclusively, the type of 27

MSC will be specifically identified (i.e. “circuit-switched MSC” or 28

“MSCe”). 29

Mobile Switching Center Emulation The MSCe provides processing and control for calls and 30

services. The MSCe provides signaling capabilities equivalent to a circuit-31

switched MSC on the A1p interface. The MSCe connects to a BS/PCF via IP 32

based protocols. 33

MS/AT A device capable of operating on both 1x and HRPD systems. 34

Packet Control Function An entity in the radio access network that manages the relay of packets 35

between the BS/AN and the PDSN. 36

Packet Data Serving Node An entity that routes AT originated or AT terminated packet data traffic. A 37

PDSN establishes, maintains and terminates link layer sessions to ATs. 38

Packet Data Session An instance of use of packet data service by a mobile user. A packet data 39

session begins when the user invokes packet data service. A packet data 40

session ends when the user or the network terminates packet data service. 41

During a particular packet data session, the user may change locations but the 42

same IP address is maintained. Refer also to [11] definitions. 43

QoS Sub BLOB An object formatted as specified in [8] containing QoS attribute sets or QoS 44

Profile IDs. 45

Flow Profile ID An identifier used to identify the service needs for an application flow. Refer 46

to [18]. 47


1-7

Radio Access Network The network entities providing data connectivity between the packet 1

switched data network (typically the Internet) and the AT. The RAN may be 2

divided into the following logical entities: ANs, AN-AAAs, and PCFs. The 3

interfaces between these entities, the interfaces between the PCF and the 4

Packet Data Serving Node (PDSN), and the interfaces between the AN and 5

the Mobile Switching Center (MSC) are considered parts of the RAN. Refer 6

to section 1.4. 7

Requested QoS Sub BLOB The QoS Sub BLOB containing the QoS requested by a MS/AT for a given 8

IP flow. Refer to [8] and [10]. 9

Reservation Air interface resources needed to carry an IP flow. Refer to [10]. 10

Reservation Label An identifier, which combined with a direction, uniquely identifies a 11

reservation. Reservation labels are also used as Flow IDs. 12

RLP Flow Unidirectional data flow over the air interface. This specification refers to 13

this as Link flow. Refer to [10]. 14

SC/MM function: SC/MM (Session Control and Mobility Management) is logically located in 15

the AN and includes the following functions: 16

• Storage of HRPD session related information: This function keeps HRPD 17

session related information (e.g., Keep Alive timer, MNID, mapping between 18

MNID and UATI, etc.) for dormant ATs. 19

• Assignment of UATI (Unicast AT identifier): This function assigns a new 20

UATI to an AT. 21

• Access Authentication: This function performs the access authentication 22

procedure. This function judges whether an AT should be authenticated or 23

not when the AT is accessing the HRPD RAN. The SC/MM performs Point-24

to-Point Protocol (PPP) procedures for access authentication. 25

• Mobility Management: This function manages the location of an AT. 26

Service Connection A bidirectional logical connection between the AT and PDSN that may 27

persist for the life of the PPP session. A service connection is identified by 28

the SR_ID2 and has an associated service option value. A service connection 29

may be mapped to a unique forward air interface link flow, reverse air 30

interface link flow, A8 connection and A10 connection associated with the 31

AT at any given time. PPP signaling is carried over the main service 32

connection, which is associated with the main A8/A10 connection. Auxiliary 33

service connections may be established as needed. Every IP flow is 34

associated with a service connection. 35

Service Stream The HRPD stream used when exchanging data between the AT and the 36

PDSN. Refer to [10]. 37

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

connection. 39

Subscriber QoS Profile The set of QoS-related information sent from the PDSN that the RAN uses to 40

authorize QoS requests for a given subscriber. Refer to [8]. 41

42

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


1-8

1

2


1-9

1.4 HRPD IOS Architecture Reference Model (SC/MM in the AN) 1

The interfaces defined in this specification are described as follows. 2

A1 The A1 interface carries signaling information between the call control and mobility 3

management functions of the circuit-switched MSC and the IWS function in the AN. For 4

A1 descriptions, refer to section 2.1. A1 interface changes required for HRPD are provid-5

ed in Annex B. 6

A1p The A1p interface carries signaling information between the call control and mobility 7

management functions of the Mobile Switching Center Emulation (MSCe) and the IWS 8

function in the AN. It is recommended that the A1p interface be applied for interworking 9

between the 1x system and the HRPD system. For A1p descriptions, refer to section 2.1. 10

A1p interface changes required for HRPD are provided in Annex B. 11

A8 The A8 interface carries user traffic between the Access Network (AN) and the Packet 12

Control Function (PCF). For A8 descriptions, refer to section 2.2. A8 interface changes 13

required for HRPD are provided in Annex C. 14

A9 The A9 interface carries signaling information between the AN and the PCF. For A9 15

descriptions, refer to section 2.2. A9 interface changes required for HRPD are specified 16

in Annex C. 17

A10 The A10 interface carries user traffic between the PCF and the PDSN. For A10 descript-18

ions, refer to section 2.3. A10 interface changes required for HRPD are specified in 19

Annex D. 20

A11 The A11 interface carries signaling information between the PCF and the PDSN. For A11 21

descriptions, refer to section 2.3. A11 interface changes required for HRPD are specified 22

in Annex D. 23

A12 The A12 interface carries signaling information related to access authentication between 24

the SC/MM function in the AN and the AN-AAA (Authentication, Authorization and 25

Accounting entity). For a description of the A12 interface, refer to section 2.4. 26

A13 The A13 interface carries signaling information between the SC/MM function in the 27

source AN and the SC/MM function in the target AN. For a description of the A13 28

interface, refer to section 2.5. 29

30

The HRPD IOS messaging and call flows are based on the Architecture Reference Model shown in Figure 31

1.4-1. 32


1-10

PCF

A8

PDSNA9

A10

A11

AN AAAA13AT A12

Air Interface

MSC/MSCe

Source AN

SC/MMFunction

Target AN

SC/MMFunction

IWSFunction

A1/A1p

1

Figure 1.4-1 HRPD IOS Architecture Reference Model (SC/MM in the AN) 2

1.5 HRPD Micro-Mobility and Macro-Mobility Concepts 3

The figure below provides a conceptual view of levels of HRPD packet data mobility. 4

Home Agent

PDSN PDSN

PCF PCF PCF

AN AN ANAN

Mobility betweenPDSNs (Mobile IP)

Mobility betweenPCFs (A10/A11

Interfaces)

Mobility between ANs(A8/A9 Interfaces)

5

Figure 1.5-1 Packet Data Mobility Architecture for HRPD 6

• The A8/A9 interfaces support mobility between ANs under the same PCF. 7

• The A10/A11 interfaces support mobility between PCFs under the same PDSN. 8

• Mobile IP supports mobility between PDSNs under the same Home Agent, as specified in [1]. 9

1.6 Compatibility with IOS Standards 10

The HRPD IOS architecture reference model in section 1.4 includes the following interfaces that also 11

exist in the 1x architecture reference model (refer to [11]): A1/A1p, A8/A9, and A10/A11. To the extent 12

possible, this specification reuses the 1x IOS transport requirements and interface definitions for these 13

interfaces. Some changes are required for these interfaces to work when used in HRPD systems. For 14

example, HRPD service option values are different from 1x service option values. The 1x IOS version 15

specified in [11]~[17] are used as the “base documents” for this specification. The changes required for 16

HRPD are shown as delta text relative to the 1x IOS version of the base documents 17


1-11

1.7 HRPD IOS Assumptions 1

This section describes assumptions in this standard. 2

1.7.1 IOS Assumptions 3

The following assumptions are made regarding AN/AT behavior: 4

1. A packet data session may transition from a serving 1x system to a serving HRPD system and from a 5

serving HRPD system to a serving 1x system. 6

2. Service option values 59 (3BH) and 64 (40H) are used in the Service Option fields in accounting 7

records transported on the A9 and A11 interfaces to identify accounting records associated with 8

HRPD packet data service. 9

3. Subnets do not span more than one HRPD packet zone. There may be more than one subnet within an 10

HRPD packet zone and intra-PCF handoffs may occur. 11

4. For the case of dormant inter-AN inter-PCF handoff, the target PCF may use the PDSN address 12

received from the source AN to send the A11-Registration Request message. Otherwise, the target 13

PCF shall use the PDSN selection algorithm (if supported and if the International Mobile Subscriber 14

Identity, IMSI, is available) or internal algorithms to select a PDSN. 15

5. Following a dormant handoff, the target AN sends the ANID to the target PCF. If the AT sends the 16

SID, NID, and PZID, then the ANID consists of a triplet containing the received values. If the AT 17

does not send the triplet, or the AN chooses not to request this information from the AT, then the 18

target AN may send the ANID received in the A13-Session Information Response message from the 19

source AN. If the target PCF supports ANIDs, then it sets the PANID to the ANID received from the 20

target AN, and the CANID to its own ANID in the A11 messages. 21

6. For the instance of Packet Application terminated in the AN, the AT shall support Challenge 22

Handshake Authentication Protocol (CHAP) access authentication. In this case, the AT shall send a 23

Network Access Identifier (NAI) of the form specified in [25]. 24

7. For the instance of Packet Application terminated in the AN (i.e., AN access authentication), the gen-25

eration of the NAI and password are the responsibility of the service provider. The NAI and password 26

should be chosen and managed using procedures that minimize the likelihood of compromise. 27

8. If the access authentication feature is used, the AN shall always propose CHAP as a PPP option in an 28

initial Link Control Protocol (LCP) Configure-Request during the PPP establishment. 29

9. The Mobile Node Identification (MN ID) that is used by the AN and the PCF on A9 and A11 30

messages is unique within the operator’s network, and is determined as follows: 31

o If the HRPD AN uses the access authentication feature, the MN ID field shall be set to the MN ID 32

value returned by the AN-AAA (e.g., IMSI) following successful access authentication. 33

o Otherwise, the AN/PCF shall set the MN ID field to a value that conforms to a valid MN ID 34

format (i.e., IMSI format). In this case, the MN ID is determined by other means. 35

10. After the AT indicates it is ready to exchange data on the access stream, the AT and the AN initiate 36

PPP procedures according to [21]. 37

11. The AT may support packet data service as specified in [8]. 38

12. If the access authentication feature is used, the AN may acquire the AT hardware identifier via air-39

interface signaling, based on the network operator policies. 40

13. The AN and AT do not pass default attributes and attributes of hardlinked protocols. Refer to [10]]. 41

42


1-12

1.7.2 QoS Assumptions 1

The following assumptions are made regarding the QoS architecture: 2

1. The IP flows identified as Flow ID = {0xFF, Forward} and {0xFF, Reverse} are always associated 3

with the Main A10 connection. 4

2. A8 and A10 connections are bi-directional. 5

3. HRPD service option values are sent over the A9 and A11 interface but not over the HRPD air 6

interface. 7

4. An IP flow is identified by a Flow ID and a direction. For HRPD, the Flow ID is set to the value of 8

the air interface Reservation Label. 9

5. There is an M:1 mapping of IP flows to A8/A10 connection in the forward direction. That is, one 10

A8/A10 connection may carry multiple forward IP flows. 11

6. There is an N:1 mapping of IP flows to A8/A10 connection in the reverse direction. That is, one 12

A8/A10 connection may carry multiple reverse IP flows. 13

7. There is a 1:1 coupling of A8 and A10 connections. All IP flows mapped to a given A10 connection 14

are mapped to the A8 connection corresponding to that A10 connection. 15

8. Each A8/A10 connection is associated with zero or one forward link flow. Subject to the network 16

operator’s policy (e.g., accounting), this does not prohibit an IP flow from using a default link flow 17

when its associated forward link flow is unavailable or when it (the IP flow) is in the deactivated 18

state. 19

9. Each A8/A10 connection is associated with zero or one reverse link flow. 20

10. An AN is able to detect when a forward IP flow transitions to the active state, and to identify the 21

activated forward IP flow (e.g., using Flow ID in the GRE extension). 22

11. The A8 and A10 connections with SR_ID 1 are defined to be the main A8 and A10 connection, 23

respectively. 24

25

1.8 State Definition 26

This section describes state definitions for the HRPD system. 27

1.8.1 Packet Data Session State 28

For purposes of the protocol of this standard, there are three packet data session states: Active/Connected, 29

Dormant, and Null/Inactive. In the Active/Connected State, a physical traffic channel exists between the 30

AT and the AN over which data may be sent. When transitioning to this state, all A8 connections for the 31

packet data session are established and, if transitioning from the Null/Inactive State, all A10 connections 32

for the packet data session are established. In the Dormant State, no physical traffic channel exists 33

between the AT and the AN and no A8 connections exist between the AN and the PCF, however the PPP 34

link between the AT and the PDSN is maintained. When transitioning to this state, all A8 connections for 35

the packet data session are released and all A10 connections for the packet data session are kept. In the 36

Null/Inactive State, there is no traffic channel between the AT and the AN and no PPP link between the 37

AT and the PDSN. When transitioning to this state all A10 connections for the packet data session are 38

released and, if transitioning from the Active/Connected State, all A8 connections for the packet data 39

session are released. Figure 1.8.1-1 shows the possible transitions between the states of a packet data 40

session. 41


1-13

Active / Connected

State

Dormant State

Null / InactiveState

1

Figure 1.8.1-1 Packet Data Session State Transitions 2

1.8.2 IP Flow State 3

There are two IP flow states: Activated and Deactivated. In the Activated State, the IP flow is in service. 4

The Activated State corresponds to the Multi-Flow Packet Application Reservation Open state specified 5

in [10]. In the Deactivated State, the IP flow is temporarily out of service. Information on the IP flow is 6

kept in the RAN so that the IP flow may be reactivated. The Deactivated State corresponds to the Multi-7

Flow Packet Application Reservation Close state specified in [10]. Figure 1.8.2-1 shows the possible 8

transitions between the states of an IP flow. 9

DeactivatedState

Activated State

Initial state of IP flow

other than FFH Initial state

of IP flow FFH

10

Figure 1.8.2-1 IP Flow State Transitions 11

12

13


1-14

1

(This page intentionally left blank) 2

3

4


2-1

2 HRPD IOS Interfaces 1

This section describes the RAN interfaces associated with this specification. 2

Where there are differences identified in the application of the IOS to 1x as opposed to HRPD, the terms 3

in the right column of Table 2-1 are used explicitly. Otherwise, the terms in the left column of the table 4

shall be mapped to the corresponding terms in the right column when interpreting Annex A through 5

Annex D of this specification. 6

Note: Annex B through Annex D contain specific A1, A9 and A11 messaging text from [14], [16] and 7

[17] with all HRPD related changes identified through the use of underscores (additions) and strikeouts 8

(deletions). 9

Table 2-1 Terminology Cross Reference between 1x and HRPD 10

1x Term HRPD Term BS AN Base Station Access Network BSC AN Base Station Controller Access Network MS AT Mobile Station Access Terminal

11

2.1 A1/A1p Interface (HRPD AN - MSC) 12

Note: In this specification A1 messages are used by both the A1 and A1p interfaces and the term MSC 13

refers to either a circuit-switched MSC or an MSCe. 14

The specification for the A1/A1p interfaces is defined in [14]. Updates to address HRPD are included in 15

Annex B. The A1/A1p messages contained in Table 2.1-1 may be supported in HRPD systems 16

Table 2.1-1 A1 and A1p Messages [A.S0014-C] Implemented in this Document 17

Call Processing Messages:

Paging Request BS Service Request BS Service Response

Supplementary Services Messages

Mobility Management Messages:

Location Updating Request Location Updating Accept Location Updating Reject Event Notification

Application Data Delivery Service (ADDS) Messages:

ADDS Page ADDS Page Ack ADDS Transfer

18


2-2

The A1/A1p interface between the HRPD AN and the MSC is used to support CSNA (refer to [10]) and 1

HRPD reactivation via the cdma2000 1x network. The CSNA functionality is included to address 2

operation of a hybrid MS/AT that otherwise would have to periodically check the 1x system for pages 3

while it is monitoring the HRPD system. For example, CSNA allows the MS/AT to receive a 1x 4

notification over HRPD while receiving a service such as Broadcast Multicast Service (BCMCS) over 5

HRPD. A corresponding enhancement is for an MS/AT to receive notification of data pending delivery in 6

the HRPD system while it is monitoring the 1x system. 7

HRPD AN - MSC assumptions: 8

1. The operation described in this document is achieved in part by reusing a subset of the messages 9

defined on the A1/A1p interface between the 1x BS and the MSC. 10

2. The MSC keeps track of which RAN (1x or HRPD) from which a 1x registration was most recently 11

received. 12

3. If the same PDSN is shared between the 1x PCF and HRPD PCF, the A10 can only be connected to 13

either the 1x PCF or the HRPD PCF for a given MS/AT. The MS/AT cannot have both a 1x packet 14

data service option and an HRPD service option active at the same time. 15

2.2 A8-A9 (AN - PCF) Interface 16

The specification for the A8-A9 interface is defined in [16]. Updates to address HRPD are included in 17

Annex C. 18

2.3 A10-A11 (PCF - PDSN) Interface 19

The specification for the A10-A11 interface is defined in [17]. Updates to address HRPD are included in 20

Annex D. 21

2.4 A12 (AN - AN-AAA) Interface 22

Support for the A12 interface and access authentication is optional in an HRPD radio access network. The 23

requirements and provisions in this section apply insofar as the A12 interface is supported. 24

The A12 interface between the AN and the AN-AAA entities is used for the following purposes: 25

1. to transmit data used to perform AN-level access authentication of the AT device (by authenticating 26

the results of a CHAP challenge/response operation invoked by the AN). 27

2. to return the MN ID that is used on the A1/A1p, A8/A9 and A10/A11 interfaces (following successful 28

access authentication of the AT device). This identifier permits packet data session handoffs between 29

ANs, between HRPD and 1x systems, and is also used in support of CSNA. 30

If the AT device access authentication feature is not used by an HRPD system, the MN ID that is used by 31

the AN on the A1/A1p, A9 and A11 interfaces is determined by other means. 32

The A12 interface is based on the Remote Authentication Dial-In User Service (RADIUS) protocol as 33

defined in [26]. The interface is shown in Figure 1.4-1. 34

The A12 interface consists of the following messages: 35

• A12 Access-Request 36

• A12 Access-Accept 37

• A12 Access-Reject 38

Note: In the call flows of this document these message names are prefixed with “A12”, to conform to IOS 39

notation convention. 40

Figure 2.4-1 shows the protocol reference model for the A12 interface. The AN-AAA in the visited access 41

provider and home access provider IP networks communicate via AN-AAA proxy servers and one or 42

more AN-AAA brokers. Note that the use of AN-AAA brokers is optional. 43


2-3

AN

RADIUS

IP

PL

LinkLayer

UDP

RADIUS

IP

PL

LinkLayer

UDP

VisitedAN-AAA

RADIUS

UDP

IP

LinkLayer

PL

HomeAN-AAA

RADIUS

IP

PL

LinkLayer

UDP

BrokerAN-AAA(optional)

RADIUS

UDP

IP

LinkLayer

PL

RADIUS

IP

PL

LinkLayer

UDP

1

Figure 2.4-1 RADIUS Protocol Reference Model 2

3

2.4.1 PPP Session 4

2.4.1.1 Establishment 5

If the AN supports access authentication and the A12 interface, after the AT indicates it is ready to 6

exchange data on the access stream, the AN shall initiate PPP procedures according to [21] by sending an 7

LCP Configure-Request. PPP shall support transparency in accordance with section 4.2 of [22]. The AN 8

and AT shall attempt to negotiate a control character mapping, with the minimum number of escape 9

characters by proposing an Async-Control-Character-Map (ACCM) of 0x 00000000. Additionally, if no 10

PPP session is present, the AN may re-authenticate the AT by reinitiating the PPP session. 11

2.4.1.2 Termination 12

The AN may release the PPP connection after the access authentication of the AT has been performed. 13

The AN may support a PPP inactivity timer for each PPP session. When the inactivity timer expires, the 14

AN shall terminate the PPP session. 15

2.4.1.3 Access Authentication 16

The AT shall support CHAP for the PPP instance on the access stream. If the AN supports access 17

authentication, the AN shall support CHAP for the PPP instance on the access stream. In this case, the 18

AN shall always propose CHAP as a PPP option in an initial LCP Configure-Request during the PPP 19

establishment. 20

2.4.2 AN-AAA Support 21

If the AN supports access authentication and the A12 interface, the AN shall support the RADIUS client 22

protocol in accordance with [26] and shall communicate user CHAP access authentication information to 23

the visited AN-AAA in an Access-Request message on the A12 interface. For an AN-AAA to recognize 24

that the transaction is related to access authentication, the Access-Request message may contain an 25

additional 3rd Generation Partnership Project 2 (3GPP2) Vendor Specific Attribute (VSA). Refer to 26

Annex E, RADIUS Attributes. If the Access-Request message on the A12 interface contains a 3GPP2 27

VSA, the proxy AN-AAA shall include the attribute in the Access-Request message forwarded to the 28

home AN-AAA on the A12 interface. 29

The AN may acquire the AT hardware identity information as specified in [10]. This acquisition proced-30

ure is independent of any provisioning procedures that are performed locally on the AT, and the acquired 31


2-4

AT hardware identity information represents the hardware identity of the AT obtained via air-interface 1

signaling. 2

On receipt of the AT’s CHAP response, the AN shall send an Access-Request message, on the A12 3

interface, containing at a minimum: 4

• User-Name (1)3 = NAI 5

• CHAP-Password (3) = CHAP ID and CHAP-response 6

• NAS-IP-Address (4) = IP address of AN 7

• CHAP-Challenge (60) = challenge value issued by AN 8

In addition, the Access-Request message may contain: 9

• HRPD Access Authentication VSA (defined in Annex E), which is used to indicate that the Access-10

Request message is sent in the context of access authentication. 11

• HRPD AT Hardware Identifier VSA (defined in Annex E), which contains the AT hardware identifier 12

value and type obtained via air-interface signaling. 13

Note: The CHAP access authentication password should be cryptographically strong. One recommendat-14

ion for password generation can be found in [23], Randomness Recommendations for Security, Section 15

7.1. 16

Note: Based on network operator’s policy, the AN-AAA may use the AT hardware identifier in the AT 17

Hardware Identifier VSA for verification purposes. If the policy of the home operator requires the usage 18

of the AT hardware identifier and the AT Hardware Identifier VSA is absent from the Access-Request 19

message, then the AN-AAA responds with an Access-Reject message. 20

Upon successful access authentication the visited AN-AAA shall send an Access-Accept message to the 21

AN on the A12 interface. The Access-Accept message shall contain at a minimum the RADIUS Callback-22

Id attribute (Type=20) populated with the MN ID (e.g., IMSI) and the String field shall be set as follows: 23

0 1 2 3 4 5 6 7 Octet ASCII encoded MN ID Type [30H denotes IMSI] 1

ASCII encoded most significant Identity Digit = [30-39H] 2

… … ASCII encoded least significant Identity Digit = [30-39H] N

2.4.3 AN-AAA Requirements 24

The AN-AAA shall act as a RADIUS server and shall follow the guidelines specified in [26]. 25

If the AN performs access authentication using CHAP, the AN-AAA receives a RADIUS Access-Request 26

message on the A12 interface from the AN with CHAP access authentication information. If the AN-27

AAA does not have the authority to accept/deny the request, it forwards the request to the home network 28

or a peer (e.g., a broker), in accordance with [26]. In this case, the AN-AAA later receives an Access-29

Accept message from the home or broker network. The AN-AAA shall then send the Access-Accept 30

message to the AN, on the A12 interface. 31

Communications between AN-AAAs may optionally be protected with IP security. The establishment of 32

this security association is outside the scope of this standard. Refer also to [26] for additional RADIUS 33

security requirements. 34

3 The numbers in this list correspond to the RADIUS attribute type defined in [26].


2-5

If the policy of the home operator requires the usage of the AT hardware identifier information, then the 1

AN-AAA uses the AT hardware identifier information in the Access-Request message. The AN-AAA 2

stores and returns the MN_ID that is used on the A9 and A11 interfaces. 3

2.5 A13 (AN - AN) Interface 4

Information may be exchanged in either the source to target direction or the target to source direction and 5

is explained as follows. 6

The information content in the target to source direction is as follows: 7

• Unicast Access Terminal Identifier (UATI). This is the UATI received by the target AN using the 8

UATI Color Code and UATI024 received from the AT, which allows the source AN to determine the 9

session configuration parameters that are requested by the target. Note that some parts of the UATI 10

determined by the target may not be meaningful. However, it is assumed that the source AN has 11

enough information to identify the corresponding HRPD session. 12

• Security Layer Packet. This is the Security Layer packet, including protocol header and trailer, as 13

received from the AT. 14

• Sector ID. The target AN shall set this field to the 128-bit identifier of the sector on which the UATI-15

Request message is received. 16

The information content in the source to the target direction is as follows: 17

• MN ID used by the source AN over the A11 interface. This allows the target AN to use the same MN 18

Identifier from the previous A10 connection, once a new A10 connection has been setup. 19

• Session Configuration Parameters. These parameters including the air interface protocols states, allow 20

the target AN to continue to use the air interface protocols previously negotiated between the AT and 21

the source AN. 22

• PDSN address. This IPv4 address allows the target AN/PCF to reconnect (when possible) to the same 23

PDSN without executing a PDSN re-selection algorithm (if specified) or an internal PDSN selection 24

algorithm. For the case of dormant inter-AN inter-PCF handoff, the target PCF may use the PDSN 25

address received from the source AN to send the A11-Registration Request message. Otherwise, the 26

target PCF shall use the PDSN selection algorithm (if supported) or internal algorithms to select a 27

PDSN. 28

• PANID. This information allows the target AN to inform the PDSN of the PANID, in the case that it 29

is not provided by the AT over the air interface. The PANID, along with CANID information, allows 30

the PDSN to determine if there is a need to do an agent advertisement. 31

Note: The AT may transition a packet data session from a serving HRPD system to a serving 1x 32

system and back to a serving HRPD system. Therefore, following a dormant handoff, the target AN 33

shall send the PANID received from the AT to the target PCF. Otherwise, if the AT does not send the 34

PANID or the AN chooses not to request this information from the AT, then the target AN may use 35

the PANID received in the A13-Session Information Response message from the source AN. 36

2.5.1 A13 Interface Network/Transport Protocol Specification 37

The IOS application is independent of the underlying physical transport medium, which is left to the 38

discretion of operators and manufacturers. The signaling protocol stack available to operators and 39

manufacturers for the A13 interface is: 40

41

IOS Application UDP

IP Link Layer

Physical Layer


2-6

1

The following UDP [19] port value is reserved for signaling on the A13 interface: 2

• A13 (AN-to-AN) 3125/udp - This is the registered UDP port number to be used for signaling inter-3

connection to another AN. 4

The destination port number in the UDP packet that carries an A13-Session Information Request message 5

shall be set to 3125 (refer to Section 2.5.1). 6

The receiver of the A13-Session Information Request message shall set the <source port, source IP 7

address> and <destination port, destination IP address> of the UDP packet that carries the corresponding 8

A13-Session Information Response/Reject message to the <destination port, destination IP address> and 9

<source port, source IP address> of the UDP packet that carried the A13-Session Information Request 10

message, respectively. 11

The receiver of the A13-Session Information Response message shall set the <source port, source IP 12

address> and <destination port, destination IP address> of the UDP packet that carries the corresponding 13

A13-Session Information Confirm message to the <destination port, destination IP address> and <source 14

port, source IP address> of the UDP packet that carried the A13-Session Information Response message, 15

respectively. 16

The standard UDP protocol, as described in [19], shall be used. 17

Note: Care should be taken in addressing ANs designed per 3GPP2 A.S0008-0, where this port usage 18

specification was not made. 19

2.5.2 A13 Interface Procedures 20

This section describes the messages and procedures used between ANs on the A13 interface. The pro-21

cedure for the A13 interface is a message flow to exchange AT and PDSN information between the ANs. 22

The information is exchanged via the following messages: 23

• A13-Session Information Request 24

• A13-Session Information Response 25

• A13-Session Information Confirm 26

• A13-Session Information Reject 27

The procedures for how the target AN discovers the source AN and determines the UATI are not 28

specified. 29

2.5.2.1 A13-Session Information Request 30

The A13-Session Information Request message is sent by the target AN to request information about an 31

AT from a source AN when the target AN does not have this information. 32

2.5.2.1.1 Successful Operation 33

When the target AN receives a packet from an AT that contains a UATI that is not in a subnet that is 34

associated with the target AN, the target AN attempts to retrieve session related information from the 35

source AN for the AT. The target AN sends an A13-Session Information Request message to the source 36

AN to indicate the information requested. The target AN shall include the determined UATI, Security 37

Layer Packet and Sector ID. The target AN then starts timer TA13req. 38

Refer to section 5.1.1.1, A13-Session Information Request, for the format and content of this message. 39

2.5.2.1.2 Failure Operation 40

If timer TA13req expires, the target AN may resend the A13-Session Information Request message to the 41

source AN and restart timer TA13req a configurable number of times. If the A13-Session Information 42


2-7

Response message is not received from the source AN, the target AN may begin a new session 1

establishment with the AT. 2

2.5.2.2 A13-Session Information Response 3

The A13-Session Information Response message is used by the source AN to respond to the target AN’s 4

request to retrieve information about an AT. 5


When the source AN receives an A13-Session Information Request message it checks if the session in-7

formation for the requested AT exists and if it can authenticate the target AN request. After the source 8

AN has successfully authenticated the information contained in the A13-Session Information Request 9

message and has the requested session state information, it sends an A13-Session Information Response 10

message to the target AN with the requested information. 11

The source AN includes SSIRs for the main personality and E-SSIRs for all personalities other than the 12

main personality in the A13-Session Information Response message. The target AN determines the 13

current personality from the SessionConfigurationToken attribute of the main personality. For detailed 14

information, refer to [10]. 15

Upon receipt of the A13-Session Information Response message, the target AN stops timer TA13req. 16

Refer to section 5.1.1.2, A13-Session Information Response, for the format and content of this message. 17


If timer TA13res expires, the target AN may re-send this message a configurable number of times. 19

2.5.2.3 A13-Session Information Confirm 20

The A13-Session Information Confirm message is used by the target AN to inform the source AN that the 21

target AN has successfully received the session information about an AT. 22


When the target AN receives the A13-Session Information Response message from the source AN with 24

the requested AT information it shall send an A13-Session Information Confirm to the source AN. Upon 25

receipt of the A13-Session Information Confirm message, the source AN shall remove the stored session 26

information related to the AT in question. 27

Refer to section 5.1.1.3, A13-Session Information Confirm, for the format and content of this message. 28


None. 30

2.5.2.4 A13-Session Information Reject 31

The A13-Session Information Reject message is used by the source AN to reject a request from the target 32

AN to retrieve session information from source AN. 33


When the source AN receives an A13-Session Information Request message and it can not retrieve the 35

session information or can not authenticate the identity of the AT, the source AN responds by sending an 36

A13-Session Information Reject message to the target AN. 37

Upon receipt of the A13-Session Information Reject message, the target AN stops timer TA13req. After 38

sending the A13-Session Information Reject message, the source AN may retain the session information, 39

if it exists. 40


2-8

Refer to section 5.1.1.4, A13-Session Information Reject, for the format and content of this message. 1


None. 3

4

5


3-1

3 HRPD IOS Call Flows 1

This section describes the call flows associated with an HRPD AT. 2

3.1 AT Originates HRPD Session 3

This section describes the call flows associated with an AT call origination in the AN. 4

3.1.1 AT Originates HRPD Session - Successful Access Authentication 5

This scenario describes the call flow for a successfully authenticated AT call origination in the AN. 6

CHAP Challenge - Response

PPP and LCP Negotiation

Transmitting Packet Data

Establishing PPP connection

Session Establishment

A9-Setup-A8

A9-Connect-A8

TA8-setup

AN AAA PCF PDSN timeAT

A12 Access-Request

A12 Access-Accept

c

d

f

b

a

g

j

k

l

m

n

AN

e

h

i

CHAP - Authentication Success

A11-Registration Request (Lifetime, MEI)Tregreq

A11-Registration Reply (Lifetime, accept)

AT Ready to ExchangeData on Access Stream

AT Ready to ExchangeData on Service Stream

Location Update Procedure

o

7

Figure 3.1.1-1 Initial AT Origination with HRPD Session Establishment and Key Exchange 8

a. The AT and the AN initiate HRPD session establishment. During this procedure, the AN does not 9

receive a UATI for an existing HRPD session. Since no session exists between the AT and AN, a 10

session is established where protocols and protocol configurations are negotiated, stored and used for 11

communications between the AT and the AN. Refer to [10], Section 8, Session Layer. 12


3-2

b. The AT indicates that it is ready to exchange data on the access stream (e.g., the flow control protocol 1

for the default packet application bound to the AN is in the open state). 2

c. The AT and the AN initiate Point-to-Point Protocol (PPP) and LCP negotiations for access 3

authentication. Refer to [21]. 4

d. The AN generates a random challenge and sends it to the AT in a CHAP Challenge message in 5

accordance with [24]. 6

e. When the AN receives the CHAP response message from the AT, it sends an Access-Request 7

message on the A12 interface to the AN-AAA which acts as a RADIUS server in accordance with 8

[26]). 9

f. The AN-AAA looks up a password based on the User-name attribute in the Access-Request message 10

and if the access authentication passes (as specified in [24] and [26]), the AN-AAA sends an Access-11

Accept message on the A12 interface in accordance with [26] (RADIUS). The Access-Accept 12

message contains a RADIUS attribute with Type set to 20 (Callback-Id), which is set to the MN ID of 13

the AT. Refer to Section 2.4.2, AN-AAA Support. 14

g. The AN returns an indication of CHAP access authentication success to the AT. Refer to [24]. 15

h. If the AN supports the Location Update procedure, the AN updates the ANID in the AT using the 16

Location Update procedure. The AN may also retrieve the PANID from the AT if necessary. This 17

step may occur any time after step ‘a’. 18

i. The AT indicates that it is ready to exchange data on the service stream (e.g., the flow control proto-19

col for the default packet application bound to the packet data network is in the open state). Note that 20

this step may occur at any time after step ‘a’. 21

j. The AN sends an A9-Setup-A8 message to the PCF with Data Ready Indicator (DRI) set to ‘1’ to 22

establish the main A8 connection and starts timer TA8-setup. The A9-Setup-A8 message shall not be 23

sent before the AT indicates that it is ready to exchange data on the service stream, as identified in 24

step i. Note: This message is sent after the access accept message is received on the A12 interface in 25

step ‘f’. 26

k. The PCF recognizes that no A10 connection associated with the AT is available and selects a PDSN. 27

The PCF sends an A11-Registration Request message to the PDSN which includes the Mobility 28

Event Indicator (MEI) within the Critical Vendor/Organization Specific Extension (CVSE) to set up 29

the main A10 connection. The PCF starts timer Tregreq. 30

l. The A11-Registration Request message is validated and the PDSN accepts the connection by return-31

ing an A11-Registration Reply message with an accept indication and Lifetime set to a non-zero 32

value. If the PDSN has data to send, it includes the Data Available Indicator within the CVSE. The 33

A10 connection binding information at the PDSN is updated to point to the PCF. The PCF stops timer 34

Tregreq. 35

m. The PCF sends the A9-Connect-A8 message to the AN. When the AN receives the A9-Connect-A8 36

message it stops timer TA8-setup. 37

n. PPP connection establishment procedure is performed between the AT and the PDSN, according to 38

[8]. 39

o. At this point the main connection is established and packet data can flow between the AT and the 40

PDSN. 41

42

43


3-3

3.1.2 AT Originates HRPD Session - Unsuccessful Access Authentication 1

This scenario describes the call flow for an unsuccessful AT call origination in the AN, due to access 2

authentication failure. 3



Session Establishment

AN AAA PCF PDSN timeAT

A12 Access-Request

A12 Access-Reject

a

b

c

d

e

AN

f

g

h

i

CHAP - Authentication Failure

SessionClose

SessionClose


4

Figure 3.1.2-1 Initial AT Origination - Unsuccessful Access Authentication 5

a. The AT and the AN initiate HRPD session establishment. During this procedure, the AN does not 6

receive a UATI for an existing HRPD session. Since no session exists between the AT and AN, a 7

session is established where protocols and protocol configurations are negotiated, stored and used for 8

communications between the AT and the AN. Refer to [10], Section 8, Session Layer. 9



c. The AT and the AN initiate PPP and LCP negotiations for access authentication. Refer to [21]. 12

d. The AN generates a random challenge and sends it to the AT in a CHAP Challenge message, in 13


e. When the AN receives the CHAP response message from the AT, it sends an Access-Request mess-15

age on the A12 interface to the AN-AAA (which acts as a RADIUS server, in accordance with [26]). 16


and if the access authentication fails (as specified in [24] and [26]), the AN-AAA sends an Access-18

Reject message on the A12 interface in accordance with [26]. 19

Note: For ANs that perform access authentication, the network requires that no use of a dedicated 20

resource, such as access to a PDSN, be allowed if authentication fails. 21

g. The AN returns an indication of CHAP access authentication failure to the AT. Refer to [24]. 22

h. The AN sends a SessionClose message to the AT to close the HRPD session. 23

i. The AT responds with a SessionClose message. 24


3-4

3.2 Re-authentication 1

This section describes the call flows associated with the re-authentication of an AT. 2

3.2.1 Re-authentication of an AT in Dormant State 3

This scenario describes the call flow associated with re-authentication of a dormant AT. It is assumed that 4

the AT has already established an HRPD session. 5



Connection Establishment

AN AAA timeAT

A12 Access-Request

A12 Access-Accept

b

c

e

a

f

AN

d

g

h



Connection Tear-Down (initiated by the AN)

6

Figure 3.2.1-1 Re-authentication of an AT in Dormant State 7

a. The AN determines that re-authentication of an AT is required and initiates connection establishment 8

procedures with the AT. 9



c. The AT and the AN initiate PPP and LCP negotiations for access authentication. Refer to [21]. This 12

step is omitted when the AN and AT keep the PPP connection after initial access authentication. 13

d. The AN generates a random challenge and sends it to the AT in a CHAP Challenge message in 14


e. When the AN receives the CHAP response message from the AT, it sends an Access-Request 16

message on the A12 Interface to the AN-AAA which acts as a RADIUS server in accordance with 17

[26]. 18






g. The AN returns an indication of CHAP access authentication success to the AT. Refer to [24]. 24

h. The AN initiates HRPD connection tear-down. Refer to [10], Section 9, Connection Layer. 25

26

27


3-5

3.2.2 Re-authentication of an AT in Active State 1

This scenario describes the call flow associated with re-authentication of an active AT. It is assumed that 2

the AT has already established an HRPD session. 3



AN AAA timeAT

A12 Access-Request

A12 Access-Accept

a

b

d

e

AN

c

f

g


AN and AT Ready to ExchangeData on Access Stream


4

Figure 3.2.2-1 Re-authentication of an AT in Active State 5

a. The AN determines that re-Authentication of an AT is required and indicates to the AT that it wants 6

to open the access stream by sending the Data Ready indicator on the Access stream. 7

Note: The AT may turn off flow on the Service stream (e.g., the flow control protocol for the default 8

packet application bound to the PDSN is in the close state). The AT indicates that it is ready to 9

exchange data on the access stream (e.g., the flow control protocol for the default packet application 10

bound to the AN is in the open state). 11

b. The AT and the AN initiate PPP and LCP negotiations for access authentication. Refer to [21]. This 12

step is omitted when the AN and AT keep the PPP connection after initial access authentication. 13

c. The AN generates a random challenge and sends it to the AT in a CHAP Challenge message in 14


d. When the AN receives the CHAP response message from the AT, it send an Access-Request message 16

on the A12 Interface to the AN-AAA which acts as a RADIUS server in accordance with [26]. 17

e. The AN-AAA looks up a password based on the User-name attribute in the Access-Request message 18





f. The AN returns an indication of CHAP access authentication success to the AT. Refer to [24]. 23

g. If necessary, the AT indicates that it is ready to exchange data on the service stream (e.g., the flow 24

control protocol for the default packet application bound to the PDSN is in the open state). 25

26

27


3-6

3.3 Data Delivery 1

This section describes the call flows associated with AT terminated and AT originated data delivery. 2

3.3.1 Network Initiated Call Re-activation from Dormant State 3

In this scenario, it is assumed that the AT has already established a packet data session and also an HRPD 4

session, however it does not have an HRPD connection and there is no A8 connection between the AN 5

and the PCF. 6



PCF PDSNAT

a

b

time


d

A9-BS Service Response

A9-BS Service Request

c

e

Page message

j

AN

fA9-Setup-A8

A9-Connect-A8

TA8-setup

i

Tbsreq9

Tnet_conn

g

h

A11-Registration Request

A11-Registration Reply

Tregreq

7

Figure 3.3.1-1 Network Initiated Call Re-activation from Dormant State 8

a. The PDSN sends packet data to the PCF. 9

b. The PCF sends an A9-BS Service Request message to the AN in order to request packet service, and 10

starts timer Tbsreq9. 11

c. The AN responds with an A9-BS Service Response. The PCF stops timer Tbsreq9 upon receipt of the 12

A9-BS Service Response message and starts timer Tnet_conn. 13

d. The AN sends a Page message to the AT, on the control channel. 14

e. The AT initiates connection establishment procedures with the AN. The AN assigns a Forward 15

Traffic Channel, Reverse Power Control Channel and Reverse Traffic Channel. Refer to [10], Section 16

9.4.6.1.6, Connection Setup State. 17

f. After the traffic channel is established, the AN sends an A9-Setup-A8 message to the PCF with Data 18

Ready Indicator set to ‘1’ to establish the A8 connections and starts timer TA8-setup. When the PCF 19

receives the A9-Setup-A8 message, it stops timer Tnet_conn. 20

g. The PCF sends an A11-Registration Request message to the PDSN with accounting information and 21

starts timer Tregreq. 22

h. The PDSN responds with an A11-Registration Reply message. The PCF stops timer Tregreq. 23


3-7

i. The PCF sends the A9-Connect-A8 message to the AN. When the AN receives the A9-Connect-A8 1

message it stops timer TA8-setup. 2

j. At this point the connection is established and packet data can flow between the AT and the PDSN. 3

4

5


3-8

3.3.2 AT Initiated Call Re-activation from Dormant State (Existing HRPD Session) 1

This scenario describes the data origination from a dormant AT, i.e., the AT has already established a 2

packet data session. The AT has also established an HRPD session. 3


PCF PDSNAT

a

b

time

A9-Setup-A8

A9-Connect-A8

TA8-setup

c

d

AN




e

f

Tregreq

4

Figure 3.3.2-1 AT Initiated Call Re-activation from Dormant State (Existing HRPD Session) 5

a. If the AT has data to send, the AT initiates connection establishment procedures with the AN. The 6

AN assigns a Forward Traffic Channel, Reverse Power Control Channel and Reverse Traffic 7

Channel. Refer to [10], Section 9.4.6.1.6, Connection Setup State. 8

b. After the traffic channel is established, the AN sends an A9-Setup-A8 message to the PCF with DRI 9

set to ‘1’ to establish all A8 connections needed for the IP flow mapping maintained by the AN and 10

starts timer TA8-setup. 11

c. The PCF sends an A11-Registration Request message to the PDSN with accounting information and 12


d. The PDSN responds with an A11-Registration Reply message. The PCF stops timer Tregreq. 14

e. The PCF sends the A9-Connect-A8 message to the AN. When the AN receives the A9-Connect-A8 15

message it stops timer TA8-setup. Refer to [13], Section 3.17.4.22, MS Initiated Call Re-activation 16

from Dormant State. 17

f. At this point the connection is established and packet data can flow between the AT and the PDSN. 18

19


3-9

3.3.3 AT Initiated Packet Data Session Establishment from an Established HRPD Session 1

This scenario describes the call flow associated with an AT establishing a PPP session to the PDSN. It is 2

assumed that the AT and the AN already have an established HRPD Session, that no corresponding A10 3

connection between the PCF and the PDSN exists. 4

PCF PDSNAT

ab

time

d

A9-Connect-A8

c

e

TA8-setup

AN

A9-Setup-A8A11-Registration Request


(Lifetime, MEI)

(Lifetime, Accept)

Tregreq

PPP and LCP Negotiation f

Transmitting Packet Data g

AT is ready to exchangedata on the Service Stream

5

Figure 3.3.3-1 AT Initiated Packet Data Session Establishment from Established HRPD Session 6

a. The AT indicates that it is ready to exchange data on the service stream. 7

b. The AN sends an A9-Setup-A8 message to the PCF with Data Ready Indicator (DRI) set to ‘0’ to 8

establish A8 connection and starts timer TA8-setup. 9

c. The PCF recognizes that no associated A10 connection for the AT is available and selects a PDSN. 10

The PCF sends an A11-Registration Request message to the PDSN which includes the Mobility 11

Event Indicator (MEI) within the CVSE. The PCF starts timer Tregreq. 12

d. The A11-Registration Request message is validated and the PDSN accepts the connection by return-13

ing an A11-Registration Reply message with an accept indication and Lifetime set to a non-zero 14

value. The PDSN includes the Data Available Indicator within the CVSE. The A10 connection 15

binding information at the PDSN is updated to point to the PCF. The PCF stops timer Tregreq. 16

e. The PCF sends the A9-Connect-A8 message to the AN. When the AN receives this message it stops 17

timer TA8-setup. 18

f. The PDSN sends an LCP configure request to initiate PPP and LCP negotiations between the AT and 19

the PDSN according to [8]. 20

At this point PPP connection is established and packet data can flow between the AT and the PDSN. 21

22


3-10

3.4 Connection Release 1

This section describes the call flows associated with an HRPD connection release. 2

3.4.1 Connection Release on HRPD Network - Initiated by the AT 3

This scenario describes the call flow associated with a connection release initiated by an AT. 4

Connection Release(Initiated by the AT)

PCF PDSNAT

a

b

time

A9-Release-A8 Complete

A9-Release-A8

c

AN

Trel9d

e

Tregreq



5

Figure 3.4.1-1 AT Initiated Connection Release 6

a. The AT initiates HRPD connection release. Refer to [10], Section 9, Connection Layer. 7

b. The AN sends an A9-Release-A8 message with a cause value set to “Packet call going dormant”, to 8

the PCF to request the PCF to release all A8 connections. The AN starts timer Trel9. 9

c. The PCF sends an A11-Registration Request message to send an Active Stop accounting record to the 10

PDSN for all IP flows in the activated state associated with the AT and starts timer Tregreq. 11

d. The PDSN sends an A11-Registration Reply message to the PCF. The PCF stops timer Tregreq upon 12

receipt of this message. 13

e. The PCF initiates procedures for releasing all A8 connections and sends an A9-Release-A8 Complete 14

message to the AN. The AN stops timer Trel9. At this time, A10 connections for this call are retained. 15

16

17


3-11

3.4.2 Connection Release on HRPD Network - Initiated by the AN. 1

This scenario describes the call flow associated with a connection release initiated by the AN/PCF. 2

Connection Release(Initiated by the AN)

PCF PDSNAT time

c

A9-Release-A8 a

e

AN

Trel9




bTregreq

d

3

Figure 3.4.2-1 AN Initiated Connection Release 4

a. The AN initiates release of the A8 connections by transmitting an A9-Release-A8 message to the PCF 5

with the cause value set to “Packet call going dormant”, to request the PCF to release the associated 6

dedicated resources. The AN starts timer Trel9. 7

b. The PCF sends an A11-Registration Request message to send Active Stop accounting records to the 8

PDSN for all IP flows in the activated state associated with the AT and starts timer Tregreq. 9

c. The PDSN responds with an A11-Registration Reply message. The PCF stops timer Tregreq. 10

d. The PCF acknowledges the A9-Release-A8 message by returning an A9-Release-A8 Complete 11

message. The AN stops timer Trel9. 12

e. The AN shall initiate HRPD connection release. This step may occur in parallel with steps a and b. 13

Refer to [10], Section 9, Connection Layer. 14

15

16


3-12

3.5 HRPD Session Release 1

This section describes the call flows associated with HRPD session release. 2

3.5.1 HRPD Session Release - Initiated by the AT or AN (A8 Connections Exist) 3

This scenario describes the call flows associated with an HRPD session release initiated by an AT. This 4

subsequently leads to a packet data session release, if present. It is assumed that the A8 connections are 5

already established. 6

Session Release

PCF PDSNAT

a

b

time

c

A9-Release-A8


Trel9

d

AN

Tregreq

A11-Registration Reply (Lifetime=0, Accept)

e

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

7

Figure 3.5.1-1 AT or AN Initiated HRPD Session Release (A8 Connections Exist) 8

a. The AT or AN initiates HRPD Session Release. Refer to [10], Section 8, Session Layer. 9

b. After the AN closes the HRPD session, the AN sends an A9-Release-A8 message with a cause value 10

set to “Normal call release”, to the PCF to request the PCF to release all associated dedicated 11

resources and all associated A10 connections. The AN starts timer Trel9. 12

c. The PCF sends an A11-Registration Request message to the PDSN with a Lifetime timer value of 13

zero to close the A10 connections. Active Stop accounting records are included in the message for all 14

IP flows in the activated state associated with the AT. The PCF starts timer Tregreq. Refer to [13], 15

Section 3.17.5.6, Packet Data Service Session Clearing - MS Initiated. 16

d. The PDSN stores the accounting data for further processing and responds with an A11-Registration 17

Reply message to complete the release of the A10 connections. The PCF stops timer Tregreq. 18

e. The PCF sends an A9-Release-A8 Complete message to the AN. The AN stops timer Trel9. 19

20

21


3-13

3.5.2 HRPD Session Release - Initiated by the AT or AN (A8 Connections do not Exist) 1

This scenario describes the call flows associated with an HRPD session release initiated by an AT. This 2

subsequently leads to a packet data session release, if present. It is assumed that no A8 connections are 3

not established. 4

Session Release

PCF PDSNAT

a

b

time

c

A9-Update-A8

A9-Update-A8 Ack

Tupd9

d

AN

Tregreq

A11-Registration Reply (Lifetime=0, Accept)

e

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

5

Figure 3.5.2-1 AT Initiated HRPD Session Release (A8 Connections do not Exist) 6

a. The AT or AN initiates HRPD Session Release. Refer to [10], Section 8, Session Layer. 7

b. After the AN closes the HRPD session, the AN sends an A9-Update-A8 message with a cause value 8

set to “Power down from dormant state”, to the PCF to request the PCF to release all associated 9

dedicated resources and all associated A10 connections. The AN starts timer Tupd9. 10

c. The PCF sends an A11-Registration Request message to the PDSN with a Lifetime timer value of 11

zero to close the A10 connections. Active Stop accounting records are included in the message for all 12

IP flows in the activated state associated with the AT. The PCF starts timer Tregreq. Refer to [13], 13

Section 3.17.5.6, Packet Data Service Session Clearing - MS Initiated. 14

d. The PDSN stores the accounting data for further processing and responds with an A11-Registration 15

Reply to complete the release of the A10 connections. The PCF stops timer Tregreq. 16

e. The PCF sends an A9-Update-A8 Ack message to the AN. The AN stops timer Tupd9. 17

18

19


3-14

3.6 Packet Data Session Release - Initiated by the PDSN 1

This scenario describes the call flow associated with packet data session release initiated by the PDSN. 2

This procedure shall be executed when the PDSN closes the Packet Data (PPP) session. 3

PCF PDSNAT

a

c

time

d

A9-Release-A8

A9-Disconnect-A8

Trel9

e

AN


Tdiscon9

A11-Registration Request (Lifetime=0)

A11-Registration Reply (Lifetime=0, accept)

Tregreq

b

A11-Registration Update

A11-Registration Acknowledge

f

g

Tregupd

Connection Release h

4

Figure 3.6-1 PDSN Initiated Packet Data Session Release 5

a. The AT and PDSN close the PPP session. 6

b. The PDSN initiates closure of the A10 connections by sending an A11-Registration Update message 7

to the PCF. The PDSN starts timer Tregupd. 8

c. The PCF responds with an A11-Registration Acknowledge message. The PDSN stops timer Tregupd. 9

d. The PCF sends an A11-Registration Request message with Lifetime set to zero, to the PDSN. The 10

PCF starts timer Tregreq. 11

e. The PDSN sends an A11-Registration Reply message to the PCF. The PCF closes the A10 12

connections for the AT and stops timer Tregreq. 13

Note: If there are no existing A8 connections the remaining steps are omitted. 14

f. The PCF sends an A9-Disconnect-A8 message to the AN and starts timer Tdiscon9. 15

g. The AN sends an A9-Release-A8 message with a cause value set to “Normal call release”, to the PCF 16

to request the PCF to release the associated dedicated resources. The AN starts timer Trel9. The PCF 17

stops timer Tdiscon9. 18

h. The PCF acknowledges the A9-Release-A8 message by returning an A9-Release-A8 Complete 19

message. The AN stops timer Trel9. 20

i. The AN may initiate HRPD connection release. Refer to [10], Section 9, Connection Layer. 21

22

23


3-15

3.7 Dormant Handoff of HRPD AT between ANs - Served by the Same PDSN 1

This section describes the call flows associated with AT dormant handoff between ANs. 2

Note: If both HRPD and 1x systems are present, then the 1x BS may indicate to the MS/AT whether 1x 3

packet zone boundaries are also HRPD subnet boundaries. If subnet boundaries are also packet zone 4

boundaries, the MS/AT tunes to the HRPD frequency to update its UATI upon crossing a 1x packet zone 5

boundary. (i.e., an HRPD subnet boundary), but not necessarily an HRPD packet zone boundary. Refer to 6

[27]. 7

3.7.1 AN-AN Dormant Handoff with Successful Retrieval of HRPD Session Information 8

This scenario describes the call flow associated with a dormant handoff between ANs when the HRPD 9

session information is successfully retrieved over the A13 interface. It is assumed that the AT has crossed 10

a mobility boundary. 11

TA13req

Tregreq

Tregreq

Tregupd

TargetAN

SourceAN PDSNAT

b

c

time

f

g



a

j

k

A11-Registration Request(Lifetime=0)

A11-Registration Reply(Lifetime=0, accept)

h

i

l

m

n

d

TargetPCF

SourcePCF

TA8-setup


A11-Registration Request (Lifetime, MEI)

A9-Release-A8-Complete

A9-Setup-A8

A13-Session Information Request

Location UpdateProcedures e

A13-Session Information Confirm

A13-Session Information Response

Complete SessionEstablishment

Initiate SessionEstablishment

12

Figure 3.7.1-1 Inter-PCF/Intra-PDSN Dormant AN-AN HO - Successful Operation 13

a. After the AT crosses a mobility boundary, the AT requests an HRPD connection and the AT and the 14

target AN initiate HRPD session establishment. During this procedure, the target AN receives the 15

UATI of an existing HRPD session (if available). The UATI can be used as an identifier for the 16


3-16

existing HRPD session when the target AN attempts to retrieve the existing HRPD session State 1

Information from the source AN. 2

b. The target AN sends an A13-Session Information Request message to the source AN to request the 3

HRPD session information for the AT. The A13-Session Information Request message shall include 4

the received UATI, the Security Layer Packet and Sector ID. The target AN starts timer TA13req. 5

c. The source AN validates the A13-Session Information Request and sends the requested HRPD sess-6

ion information of the AT to the target AN in an A13-Session Information Response message. The 7

target AN stops timer TA13req. 8

d. The AT and the target AN complete the establishment of the HRPD session. Depending on the state 9

of the AT and the target AN, either an existing HRPD session may be re-established, or a new HRPD 10

session may be initiated if required. This step may be null if no further over-the-air signaling is 11

required. 12

e. If the target AN supports the Location Update procedure, the target AN updates the ANID in the AT 13

using the Location Update procedure. The target AN may also retrieve the PANID from the AT if 14

necessary (e.g., the Session Configuration retrieved in step c indicates that the source AN does not 15

support the Location Update procedure). 16

f. The target AN sends an A13-Session Information Confirm to the source AN to indicate that the target 17

AN has received the HRPD session information. Upon receipt of the A13-Session Information 18

Confirm message the source AN deletes the associated AT HRPD session information. 19

g. The target AN sends an A9-Setup-A8 message, with Data Ready Indicator set to ‘0’, to the target PCF 20

and starts timer TA8-setup. This message contains information on all A8 connections needed for the IP 21

flow mapping maintained by the AN as negotiated over the air. This message includes the PDSN 22

address received from the source AN in the A13 Session Information Response message in step ‘c’. 23

The handoff indicator of the A9 Indicators IE shall be set to ‘0’. Note that if the AT has not crossed 24

an HRPD packet zone, the target PCF is same entity as the source PCF. 25

h. The target PCF selects the PDSN using the PDSN address provided in the A13-Session Information 26

Response message or using PDSN selection algorithms as specified in [13], and sends an A11-27

Registration Request message to the PDSN to set up an A10 connection for each service connection 28

signaled by the AN is step ‘g’. The A11-Registration Request message includes the MEI within the 29

CVSE and a non-zero Lifetime. This message also includes a CVSE containing Accounting Data 30

(A10 Connection Setup Airlink Record), if new A10 connections are being established, and an NVSE 31

including ANID information (CANID/PANID). The target PCF starts timer Tregreq. Refer to [13], 32

Section 3.17.5.8, Inter-PCF Dormant Handoff - Mobile Continues to be Served by the Serving PDSN. 33

i. The A11-Registration Request message is validated and the PDSN accepts the A10 connections by 34

returning an A11-Registration Reply message with an accept indication and the Lifetime set to the 35

configured Trp value. If the PDSN has data to send, it includes the Data Available Indicator within the 36

CVSE. If the subscriber has a Subscriber QoS Profile, the PDSN includes it in an NVSE. The A10 37

connection binding information at the PDSN is updated to point to the target PCF. The target PCF 38

stops timer Tregreq. 39

j. If the PDSN has A10 connections to another PCF (e.g., the source-PCF), it initiates closure of the 40

A10 connections with that PCF by sending an A11-Registration Update message. The PDSN starts 41

timer Tregupd. 42

k. The source PCF responds with an A11-Registration Acknowledge message. The PDSN stops timer 43

Tregupd. 44

l. The source PCF sends an A11-Registration Request message with Lifetime set to zero, to the PDSN. 45

The source AN/PCF starts timer Tregreq. 46


3-17

m. The PDSN sends an A11-Registration Reply message to the source PCF. The source PCF closes the 1

A10 connection for the AT and stops timer Tregreq. 2

n. Assuming the Data Availability Indicator was not present in step i, the target PCF responds to the 3

target AN with an A9-Release-A8-Complete message. The target AN stops timer TA8-setup. Note that 4

this step can occur any time after step i. 5

6

7


3-18

3.7.2 AN-AN Dormant Handoff with HRPD Session Information Transfer Failure 1

This scenario describes the call flow associated with a dormant handoff between ANs when the HRPD 2

session information can not be retrieved successfully from the source AN. 3

TA13req

Tregreq

Tregreq

Tregupd

TargetAN

SourceAN PDSNAT

b

c

time

e

f

a

j

g

i

k

l

m

d

TargetPCF

SourcePCF

A9-Setup-A8

n

TA8-setup

AAA-AN

A13-Session Information Request

A13-Session Information Reject

A9-Release-A8-Complete

A11-Registration Request(Lifetime=0)





Access Authentication

Location UpdateProcedures

h

A11-Registration Reply(Lifetime=0, accept)

Complete SessionEstablishment

Initiate SessionEstablishment

Connection Release o

4

Figure 3.7.2-1 Inter-PCF/Intra-PDSN Dormant AN-AN HO - Transfer Failure 5

a. The AT and the target AN initiate HRPD session establishment. During this procedure, the target AN 6

determines the UATI of an existing HRPD session (if available). The UATI can be used as an 7

identifier for the existing HRPD session when the target AN attempts to retrieve the existing HRPD 8

session state information from the source AN. 9

b. The target AN sends an A13-Session Information Request message to the source AN to request the 10

HRPD session information for the AT. The A13-Session Information Request message shall include 11

the determined UATI and the Security Layer Packet. The target AN starts timer TA13req. 12

c. The source AN cannot validate the A13-Session Information Request or does not have the requested 13

AT HRPD session information and sends an A13-Session Information Reject message to the target 14

AN. The target AN stops the timer TA13req. 15


3-19

d. The AT and the target AN complete the establishment of the HRPD session. Depending on the state 1

of the AT and the target AN, either an existing session may be re-established, or a new HRPD session 2

may be initiated if required. This step may be null if no further over-the-air signaling is required. 3

e. If the target AN supports the Location Update procedure, the target AN updates the ANID in the AT 4


necessary. 6

f. If access authentication is enabled/supported at the target AN, it shall initiate PPP on the access 7

stream. The AN initiates an access authentication of the AT using CHAP according to [24]. The AN 8

authenticates the results of the challenge with the AN-AAA, which acts as a RADIUS server 9

according to [26]. The AN shall use the MN ID received from the AN-AAA in the A12 Access-10

Accept message, in messages on the A9/A11 interfaces. Refer to Section 2.4, A12 (AN-AN-AAA) 11

Interface. 12

g. The target AN transmits an A9-Setup-A8 message, with Data Ready Indicator set to ‘0’, to target PCF 13

and starts timer TA8-setup. This message contains information on all A8 connections needed for the IP 14

flow mapping maintained by the AN as negotiated over the air. The handoff indicator of the A9 15

Indicators IE shall be set to ‘0’. 16

h. The target PCF selects a PDSN for this call using PDSN selection algorithms as specified in [13]. The 17

target PCF sends an A11-Registration Request message to the selected PDSN to set up an A10 18

connection for each service connection signaled by the AN is step ‘g’. The A11-Registration Request 19

message includes the MEI within the CVSE and a non-zero Lifetime. This message also includes 20

Accounting Data (A10 Connection Setup Airlink Record) as well as ANID information 21

(CANID/PANID). The target PCF starts timer Tregreq. Refer to [13], Section 3.17.5.8, Inter-PCF 22

Dormant Handoff - Mobile Continues to be Served by the Serving PDSN. 23

i. The A11-Registration Request message is validated and the PDSN accepts the A10 connections by 24



CVSE. If the subscriber has a Subscriber QoS Profile, the PDSN includes it in an NVSE. The A10 27

connection binding information at the PDSN is updated to point to the target PCF. The target PCF 28

stops timer Tregreq. 29

j. The PDSN initiates closing of the A10 connections with the source PCF by sending an A11-Regis-30

tration Update message. The PDSN starts timer Tregupd. 31

k. The source PCF responds with an A11-Registration Acknowledge message. The PDSN stops timer 32

Tregupd. 33

l. The source PCF sends an A11-Registration Request message with Lifetime set to zero, to the PDSN. 34

The source AN/PCF starts timer Tregreq. 35

m. The PDSN sends an A11-Registration Reply message to the source PCF. The source PCF closes the 36

A10 connection for the AT and stops timer Tregreq. 37

n. Assuming the Data Availability Indicator was not present in step i, the target PCF responds to the 38

target AN with an A9-Release-A8 Complete message. The target AN stops timer TA8-setup. Note that 39

this step can occur any time after step i. 40

o. The AN may initiate HRPD connection release. Refer to [10], Section 9, Connection Layer. 41

42

43


3-20

3.8 Miscellaneous Active HRPD Session Call Flows 1

This section describes miscellaneous call flows associated with an established HRPD session. 2

3.8.1 Deactivation/Activation of Data Flow During an Active HRPD Packet Data Session 3

This scenario describes the call flow associated with the deactivation and activation of A8 traffic data 4

flow during an active HRPD packet data session. 5

Tald9

AN PDSNAT

a

time

c

e

f

b

PCF

A9-AL Disconnected Ack

A9-AL Disconnected

Active HRPD Packet Data Session

Talc9A9-AL Connected Ack

A9-AL Connected

d

DataData

Data

DataData g

6

Figure 3.8.1-1 Activation /De-activation of Data Flow During Active HRPD Session 7

a. The PDSN transfers data to the AN through the PCF during an active HRPD packet data session. 8

b. The AN determines that it is preferable not to receive A8 traffic data from the PCF, and the AN sends 9

an A9-AL Disconnected message to the PCF to stop all the data flows for the AT and starts timer 10

Tald9. 11

c. Upon receipt of the A9-AL Disconnected message the PCF sends an A9-AL Disconnected Ack 12

message to the AN. The AN stops timer Tald9. 13

d. The PCF stops the data flow and may buffer data received from the PDSN. Alternatively, the PCF 14

may send an XOFF signal to the PDSN to prevent a buffer overflow at the PCF. In this case, the 15

PDSN may optionally buffer the data. 16

e. When the AN determines that it is preferable for all data flows for the AT to resume, the AN sends an 17

A9-AL Connected message to PCF and starts timer Talc9. 18

f. The PCF responds to the AN with an A9-AL Connected Ack message. The AN stops timer Talc9. 19

g. The PCF resumes transmitting data received from the PDSN and buffered data if it exists. 20

21

22


3-21

3.9 Multiple Connection Procedures 1

2

3.9.1 Initial HRPD Call Setup (Default IP Flows Establishment) 3

As part of HRPD air interface connection establishment, forward and reverse IP flows with Flow ID = 4

FFH are automatically established in the Activated state, and hence the main service connection is set up. 5

After this step completes, the AT may request additional IP flows, which the AN may map to auxiliary 6

service connections, using the procedures in section 3.9.2. 7

3.9.2 IP Flow Mapping Update with Service Connection Establishment 8

This scenario describes the call flow associated with additions, deletions, remappings, and/or changes in 9

granted QoS of IP flows that require establishment of a new service connection. The new mapping of IP 10

flows may make existing service connections obsolete, in which case these service connections are 11

released. 12

PCF PDSN timeAN



A9-Connect-A8

A9-Setup-A8

a

b

c

d

AT

Flow Configuration

e

(Lifetime)TA8-setupTregreq

13

Figure 3.9.2-1 IP Flow Mapping Update with Service Connection Establishment 14

a. The AT and the AN perform session configuration for the IP flows and the AN maps new IP flows or 15

reactivated IP flows to new service connections. For flow configuration, refer to [10]. 16

b. The AN sends an A9-Setup-A8 message to the PCF to establish the A8 connection and starts timer 17

TA8-setup. The A9-Setup-A8 message includes the A8 Traffic ID for the main connection and 18

Additional A8 Traffic IDs for auxiliary A8 connections. The A9-Setup-A8 message includes 19

information on all A8 connections required for the new mapping, both those already established, and 20

those to be established. A8 connections to be released are not included in the A9-Setup-A8 message. 21

c. The PCF sends an A11-Registration Request message to establish the A10 connection. The PCF starts 22

timer Tregreq. The A11-Registration Request message includes the Session Specific Extension IE for 23

the main connection and Additional Session Information for auxiliary connections in NVSEs. The 24

PCF includes information on all A10 connections corresponding to A8 connections for which 25

information was received in step ‘b’.. 26

d. The PDSN adds the new A10 connection and sends an A11-Registration Reply message to the PCF. 27

The PCF stops timer Tregreq. The A11-Registration Reply message includes the Session Specific 28

Extension for the main connection and Additional Session Information(s) in the NVSE for auxiliary 29

connection.The PDSN includes information on all A10 connections for which information was 30

received in step ‘c’. The PDSN and PCF release the A10 connections for which information was not 31

included in this message. 32


3-22

e. The PCF adds the new A8 connection and sends an A9-Connect-A8 message to the AN. The AN 1

stops timer TA8-setup. The A9-Connect-A8 message includes the A8 Traffic ID for the main 2

connection and Additional A8 Traffic ID(s) for auxiliary connection.The A9-Connect-A8 message 3

includes information on all A8 connections for which information was received in step ‘b’. The PCF 4

and AN release the A8 connections which information was not included in this message. 5

3.9.3 IP Flow Mapping Update with Service Connection Release 6

This scenario describes the call flow associated with additions, deletions, remappings, and/or changes in 7

granted QoS of IP flows that require release of one or more service connections, but no service 8

connection establishment. This procedure applies to cases where one or more but not all of the established 9

A8/A10 connections are released. This call flow does not apply to release of Flow ID=FFH. 10

Trel9

PCF PDSN timeAN



A9-Release-A8

a

b

c

d

AT

Flow Configuration

e

(Cause; Partial connection release)

(Lifetime)Tregreq


11

Figure 3.9.3-1 IP Flow Mapping Update with Service Connections Release 12

a. The AT and the AN perform session configuration for the IP flows and the AN maps the IP flows to a 13

proper subset of the existing service connections. For flow configuration, refer to [10]. 14

b. The AN sends an A9-Release-A8 message with the Cause value set to “Partial connection release” to 15

the PCF and starts timer Trel9. The A9-Release-A8 message includes the A8 Traffic ID for the main 16

connection and Additional A8 Traffic IDs for auxiliary connections. The A9-Release-A8 message 17

includes information on A8 connections that are to be used after this release procedure. Information 18

on A8 connections to be released is not included in the A9-Release-A8 message. 19

c. The PCF sends an A11-Registration Request message with lifetime set to a non-zero value to the 20

PDSN. The A11-Registration Request message includes the Session Specific Extension for the main 21

connection and Additional Session Information in the NVSE for auxiliary connections. The A11-22

Registration Request message includes information on A10 connections corresponding to A8 23

connections for which information was received in step ‘b’. Information on A10 connections to be 24

released is not included in the A11-Registration Request message. The PCF starts timer Tregreq. 25

d. The PDSN releases the A10 connections that were not included in the A11-Registration Request 26

message and sends an A11-Registration Reply message to the PCF. The A11-Registration Reply 27

message includes the Session Specific Extension for the main connection and Additional Session 28

Information for auxiliary connections in NVSEs. The A11-Registration Reply message includes 29

information on A10 connections for which information was received in step ‘c’. Information on 30

released A10 connections is not included in the A11-Registration Reply message. The PCF stops 31

timer Tregreq. The PCF releases the A10 connections for which information was not included in this 32

message 33


3-23

e. The PCF releases the A8 connections that were not included in the A9-Release-A8 message and sends 1

an A9-Release-A8 Complete message to the AN. The AN stops Trel9. The AN releases A8 2

connections for which information was not included in this message. 3

4

3.9.4 IP Flow to A8/A10 Connection Mapping Update 5

This scenario describes the call flow associated with additions, deletions, remappings, changes in granted 6

QoS, and/or changes in flow state of IP flows, provided no new service connections are established and 7

no existing service connections are release during an active HRPD packet data session. 8

PCF PDSN timeAN



A9-Update-A8 Ack

A9-Update-A8

a

b

c

d

AT

Flow Configuration

e

(Lifetime)TregreqTupd9

9

Figure 3.9.4-1 IP Flow Mapping Update 10

a. The AT and the AN perform session configuration for the IP flow(s) and the AN maps the IP flows to 11

the existing service connections. For flow configuration, refer to [10]. 12

b. The AN sends an A9-Update-A8 message to the PCF to update the flow mapping information and 13

starts timer Tupd9. 14

c. The PCF sends an A11-Registration Request message including flow mapping changes, with lifetime 15

set to a non-zero value to the PDSN. The A11-Registration Request message includes information on 16

all A10 connections corresponding to service connections for which information was received in step 17

‘b’. The PCF starts timer Tregreq. Steps ‘c’ and ‘d’ may be performed in parallel with step ‘e’. 18

d. The PDSN sends an A11-Registration Reply message to the PCF. The A11-Registration Reply 19

message includes information on all A10 connections for which information was received in step ‘c’.. 20

The PCF stops timer Tregreq. 21

e. The PCF sends an A9-Update-A8 Ack message. The AN stops timer Tupd9. 22

23

24


3-24

3.9.5 Subscriber QoS Profile Delivery 1

This scenario describes the call flow associated with delivery of a new or updated Subscriber QoS Profile. 2

Subscriber QoS Profile delivery occurs when the PDSN receives the Subscriber QoS information in a 3

RADIUS Access-Accept message and the PPP session exists. The PDSN shall save the Subscriber QoS 4

Profile and include it in an A11-Registration Reply message to the target PCF in the event of a dormant 5

handoff. For Subscriber QoS Profile transfer during dormant handoff, refer to section 3.7. After receiving 6

the Subscriber QoS Profile, the AN may initiate IP Flow Update procedure if needed. 7

PCF PDSN t im eAN

A11-Session Update Ack

A11-Session Update

A9-Update-A8 Ack

A9-Update-A8

a

b

c

d

IP F low M apping Update e

AT

T sesupdT upd9

condit ional

8

Figure 3.9.5-1 Subscriber QoS Profile Transfer 9

a. a. The AT has an active or dormant packet data session. The PDSN has a new or updated Subscriber 10

QoS profile to deliver to the RAN. The PDSN sends an A11-Session Update message including the 11

Subscriber QoS profile information to the PCF. The PDSN starts timer Tsesupd. 12

b. The PCF sends an A9-Update-A8 message containing the Subscriber QoS profile to the AN and starts 13

timer Tupd9. 14

c. The AN sends an A9-Update-A8 Ack message to provide the results of the A9-Update-A8 message. 15

The PCF stops timer Tupd9 upon receipt of this message. 16

d. The PCF sends an A11-Session Update Ack message to the PDSN to show the result of A11-Session 17

Update message. The PDSN stops timer Tsesupd upon receipt of this message. 18

e. If the AN remaps the IP flows, the procedures in sections 3.9.2 to 3.9.5 are performed. This step may 19

occur anytime after step ‘b’. 20

21

22


3-25

3.10 Support for Data Over Signaling Protocol 1

This section describes call flows associated with the Data Over Signaling (DOS) feature. 2

3.10.1 AT Originated DOS 3

DOS messages support sending small amounts of data from the AT to the AN over the signaling channel 4

when the AT has a dormant packet data session. The AN should only enable reverse link DOS as defined 5

in [10] for IP flows that require expedited service. 6

If an AT with a currently dormant packet data session has a small amount of data to send for a given IP 7

flow and the AN has enabled reverse link DOS for that IP flow, then the AT may transmit the data to the 8

AN in DOS format as specified in [10]. 9

This scenario describes the call flow associated with the receipt of a DOS message as specified in [10], 10

from the AT and the delivery of the data contained therein to the PDSN. 11

PDSNPDSNPDSNPDSN timeATATATAT ANANANAN

a

b

c

d

AAAA9999----Short Data DeliveryShort Data DeliveryShort Data DeliveryShort Data Delivery

PCFPCFPCFPCF

IP Flow ReactivationIP Flow ReactivationIP Flow ReactivationIP Flow Reactivation

DOS MessagingDOS MessagingDOS MessagingDOS Messaging

Packet DataPacket DataPacket DataPacket Data

optional

Dormant HRPD Packet Data SessionDormant HRPD Packet Data SessionDormant HRPD Packet Data SessionDormant HRPD Packet Data Session


12

Figure 3.10.1-1: HRPD DOS from an AT to the PDSN 13

a. The AT decides to send a higher-layer packet in DOS format since the packet data session is dormant. 14

If the IP flow for which the packet needs to be sent is in the Deactivated state, it is transitioned to the 15

Activated state. 16

b. The AT sends DOS messaging to deliver the higher-layer packet to the AN via the common channel. 17

c. The AN sends the data to the PCF in a DOS message format in the A9-Short Data Delivery message 18

(refer to Annex C). This message includes the Flow ID of the IP flow in the case that it was re-19

activated. 20

d. The PCF sends the data with expedited treatment to the PDSN as normal packet data. 21

22

23


3-26

3.10.2 AT Terminated DOS 1

When a small amount of data destined for an IP flow on an AT is received at the PCF, the PCF may send 2

this data to the AN in DOS format as specified in [10]. The PDSN may indicate suitability of sending the 3

data to the AT in DOS format via an attribute in its GRE payload as specified in Annex A. 4

If the AN determines that a DOS message is to be used to deliver the data to the AT, the AN sends the 5

data, in DOS format as specified in [10], directly to the AT. The PCF is informed of successful delivery 6

of the DOS message via the A9-Short Data Ack message and may subsequently discard the buffered data. 7

If after receiving data from the PCF in DOS format the AN determines that the packet data session should 8

be re-activated, it shall reject the PCF’s request to send the data in DOS format by sending the cause 9

value ‘Initiate re-activation of packet data call’ in the A9-Short Data Ack message. The PCF shall then be 10

required to initiate the re-activation of the packet data session. Once the session is active, the buffered 11

data shall be resent to the AN for transmission to the AT as normal packet data. 12

3.10.2.1 DOS Delivery from the PDSN to the AT 13

This scenario describes the call flow associated with the receipt of a short data message from the PCF and 14

its delivery to the AT over the control channel. 15

PDSNPDSNPDSNPDSN timeATATATAT ANANANAN

a

b

c

d

AAAA9999----Short Data AckShort Data AckShort Data AckShort Data Ack

PCFPCFPCFPCF

IP Flow ReactivationIP Flow ReactivationIP Flow ReactivationIP Flow Reactivation

DOS MessagingDOS MessagingDOS MessagingDOS Messaging

Packet DataPacket DataPacket DataPacket Data

AAAA9999----Short Data DeliveryShort Data DeliveryShort Data DeliveryShort Data Delivery

Tsdd9

e

optional


16

Figure 3.10.2.1-1: HRPD DOS from the PDSN to the AT 17

a. The PDSN sends packet data to the PCF on an existing PPP connection and A10 connection 18

associated with a specific AT. The GRE header may also include an attribute indicating suitability of 19

the payload for transmission in DOS format. 20

b. The PCF sends the packet data to the AN in the A9-Short Data Delivery message and starts timer 21

Tsdd9. The data is sent in DOS format as specified in [10] and is encapsulated in the ADDS user part 22

IE. This message includes the Flow ID of the IP flow from the GRE header of the packet received 23

across the A10 interface. The PCF buffers the data sent. 24

c. If the IP flow identified in the A9-Short Data Delivery message is in the De-activated state, the AN 25

initiates signaling to transition it into the “active” state. 26

d. The AN may send the packet data in DOS format by sending a DOS message directly to the AT, or 27

alternatively the AN may also decide to deliver the data to the AT over a traffic channel after re-28

activating the packet data session. Subsequent steps in the call flow assume delivery of the message 29

via DOS messaging to the AT. 30


3-27

e. The AN sends an A9-Short Data Ack message to the PCF to indicate successful delivery of the data 1

to the AT in DOS format. The PCF stops timer Tsdd9 and discards the buffered data. This message 2

has the cause value set to “SDB successfully delivered” or “SDB couldn’t be delivered” to indicate 3

whether the SDB was successfully delivered to the AT. 4

3.10.2.2 DOS Request from the PDSN – AN Refuses Request 5

This scenario describes the call flow associated with the AN refusal of the PCF DOS request, and 6

subsequent delivery of the data to the AT on a traffic channel. 7

PDSN timeAT AN

a

b

c

d

A9-Short Data Ack

PCF

Network initiated callre-activation from

Dormant State

Packet Data

A9-Short Data DeliveryTsdd9


Dormant HRPD Packet Data Session

8

Figure 3.10.2.2-1: DOS from the PDSN to the AT – AN Refuses DOS Request 9

a. The PDSN sends packet data to the PCF on an existing PPP connection and A10 connection 10

associated with a specific AT. The GRE header may include an attribute indicating suitability of the 11

payload for SDB transmission in DOS format. 12

b. The PCF sends the packet data to the AN in the A9-Short Data Delivery message and starts timer 13

Tsdd9. The data is sent in DOS format as specified in [10] and is encapsulated in the ADDS user part 14

IE. This message includes the Flow ID of the IP flow from the GRE header of the packet received 15

across the A10 interface. The PCF buffers the data sent. 16

c. The AN makes the determination, based on its internal algorithm, the data count field in the A9-Short 17

Data Delivery, or any other factors, not to send a DOS message to the AT. The AT sends an A9-Short 18

Data Ack message to the PCF with an indication that a DOS message is not to be sent to the AT by 19

setting the cause value to “Initiate re-activation of packet data call”. The PCF stops timer Tsdd9. 20

d. The PCF initiates reactivation of the packet data service. Refer to section 3.3.1. Once the packet data 21

session is active, the PCF sends the data buffered earlier for the AT to the AN which forwards the 22

data on to the AT. 23

24

25


3-28

1

(This page intentionally left blank) 2

3


4-1

4 HRPD and 1x IOS Transition Call Flows 1

This section describes the call flows associated with handoffs between HRPD and 1x systems for hybrid 2

MS/ATs. Where the AN and PCF are combined into one entity in this section, it is assumed that the 3

messaging on A8/A9 is identical to the corresponding call flows in section 3. When the BS and the PCF 4

are combined into one entity, refer to [16] for details on A8/A9 messaging. 5

While specific air interface messages may be identified in the HRPD IOS call flows, they are provided 6

only for AN trigger references. Refer to [10] for the definitions and formats of these messages. 7

Note: For simplicity, the 1x and HRPD transition scenarios (sections 4.1and 4.2) do not show interactions 8

with the MSC. 9

Note: Only the main A10 connection may be handed off between the HRPD system and 1x system. 10

4.1 Dormant Cross System Handoff - AT Served by the Same PDSN. 11

This section describes the call flows for dormant handoffs between HRPD and 1x systems. 12

4.1.1 1x to HRPD Dormant Packet Data Session Handoff - Existing HRPD Session 13

This scenario describes the call flow associated with an MS/AT dormant handoff from an 1x to an HRPD 14

system, when the HRPD system supports unsolicited Location Notification messages. Refer to [13]. 15

Based on the MS/AT changing to a different ANID or for other reasons, a dormant handoff from 1x to 16

HRPD is determined to be required. In this scenario, it is assumed that the MS/AT has already established 17

an HRPD session, however it does not have a connection established. In addition, it is assumed that the 18

MS/AT is configured to send unsolicited location notifications upon return to the HRPD system. This call 19

flow assumes that no HRPD mobility boundary has been crossed since the MS/AT last reported a 20

mobility event to any HRPD system. If an HRPD mobility boundary has been crossed, the target AN may 21

retrieve the HRPD session information from the source AN over the A13 interface (refer to section 3.7.1). 22

TargetPCF

SourceBSC/PCF PDSNMS/AT

a

time

c

d

e


Tregreq

f



Tregupd



Tregreq

g

h

i

Location UpdateProcedures


TargetAN

b

TA8-setup

A9-Setup-A8

A9-Release-A8Complete

23

Figure 4.1.1-1 1x to HRPD Dormant Packet Data Session HO - Existing HRPD Session 24

a. The change of AN is indicated by the Location Update procedures as defined in [10]. 25


4-2

b. The target AN sends an A9-Setup-A8 message, with Data Ready Indicator set to ‘0’, to the target PCF 1

and starts timer TA8-setup. The handoff indicator of the A9 Indicators IE shall be set to ‘0’. If the 2

target AN successfully retrieved the previous ANID of the MS/AT in step ‘a’, the Access Network 3

Identifiers IE is populated with this value and included in this message. 4

c. The target PCF determines a PDSN for this connection. The target PCF sends an A11-Registration 5

Request message to the PDSN. The A11-Registration Request message includes the MEI within the 6

CVSE and the PANID and CANID within the NVSE. The target PCF starts timer Tregreq. 7

d. The A11-Registration Request message is validated and the PDSN accepts the connection by 8



CVSE. The A10 connection binding information at the PDSN is updated to point to the target PCF. 11

The target PCF stops timer Tregreq. 12

e. The PDSN initiates closure of the A10 connection with the source BS/PCF by sending an A11-Regis-13


f. The source BS/PCF responds with an A11-Registration Acknowledge message. The PDSN stops 15

timer Tregupd. 16

g. The source BS/PCF sends an A11-Registration Request message with Lifetime set to zero, to the 17

PDSN. The source BS/PCF starts timer Tregreq. 18

h. The PDSN sends an A11-Registration Reply message to the source BS/PCF. The source BS/PCF 19

closes the A10 connection for the MS/AT and stops timer Tregreq. 20

i. The target PCF responds to the target AN with an A9-Release-A8 Complete message. The target AN 21

stops timer TA8-setup. Note that this step can occur any time after step d. 22

23

24


4-3

4.1.2 1x to HRPD Dormant Packet Data Session Handoff - New HRPD Session 1

This scenario describes the call flow associated with an MS/AT dormant handoff from an 1x to an HRPD 2

system. Based on an MS/AT report that it crossed a network specified threshold for signal strength or for 3

other reasons, a dormant handoff from 1x to HRPD is determined to be required when the dormant 4

MS/AT transitions from 1x to HRPD. 5

TargetAN/PCF

SourceBSC/PCF PDSNMS/

AT

c

time

b

d

e

f

Tregreq

g

Tregupd

Tregreq

i

Session Establishment a

j

k



TargetAN AAA

A12 Access-Request

A12 Access-Accept


n

m

l

o

hLocation Update Procedures









6

Figure 4.1.2-1 1x to HRPD Dormant Packet Data Session Handoff - New HRPD Session 7

a. The AT and the target AN initiate HRPD session establishment. During this procedure, the target AN 8

does not receive a UATI for an existing HRPD session. Since no HRPD session exists between the 9

MS/AT and target AN/PCF, an HRPD session is established where protocols and protocol con-10

figurations are negotiated, stored and used for communications between the MS/AT and the target 11

AN. Refer to [10], Section 8, Session Layer. 12


for the default packet application bound to the target AN is in the open state). 14

c. After HRPD session configuration the MS/AT initiates PPP and LCP negotiations for access authent-15

ication. Refer to [21]. 16

d. The target AN/PCF generates a random challenge and sends it to the MS/AT in a CHAP Challenge 17

message in accordance with [24]. 18


4-4

e. When the target AN/PCF receives the CHAP response message from the MS/AT, it sends an Access-1

Request message on the A12 interface to the target AN-AAA which acts as a RADIUS server in 2


f. The target AN-AAA looks up a password based on the User-name attribute in the Access-Request 4

message and if the access authentication passes (as specified in [24] and [26]), the target AN-AAA 5

sends an Access-Accept message on the A12 interface in accordance with [26] (RADIUS). The 6

Access-Accept message contains a RADIUS attribute with Type set to 20 (Callback-Id), which is set 7

to the MN ID of the AT. Note that in this scenario the MN ID is the same as the AT’s IMSI. Refer to 8

Section 2.4.2, AN-AAA Support. 9

g. The target AN/PCF returns an indication of CHAP access authentication success to the MS/AT. Refer 10

to [24]. 11

h. If the target AN supports the Location Update procedure, the target AN updates the ANID in the AT 12


necessary. This step may occur any time after step a. 14

i. The AT indicates that it is ready to exchange data on the service stream. (E.g., the flow control 15

protocol for the default packet application bound to the packet data network is in the open state). 16

j. The target AN/PCF sends an A11-Registration Request message to the PDSN. The A11-Registration 17

Request message includes the MEI within the CVSE and the PANID and the CANID within the 18

NVSE. If PANID is not sent in step h, the target AN/PCF sets the PANID field to zero and the 19

CANID field to its own ANID. The target AN/PCF starts timer Tregreq. 20

k. The A11-Registration Request message is validated and the PDSN accepts the connection by return-21

ing an A11-Registration Reply message with an accept indication and Lifetime set to the configured 22

Trp value. If the PDSN has data to send, it includes the Data Available Indicator within the CVSE. 23

The A10 connection binding information at the PDSN is updated to point to the target AN/PCF. The 24

target AN/PCF stops timer Tregreq. 25

l. The PDSN initiates closure of the A10 connection with the source BS/PCF by sending an A11-Regis-26


m. The source BS/PCF responds with an A11-Registration Acknowledge message. The PDSN stops 28

timer Tregupd. 29

n. The source BS/PCF sends an A11-Registration Request message with Lifetime set to zero, to the 30

PDSN. The source BS/PCF starts timer Tregreq. 31

o. The PDSN sends an A11-Registration Reply message to the source BS/PCF. The source BS/PCF 32


34

35


4-5

4.1.3 HRPD to 1x Dormant Packet Data Session Handoff 1

This scenario describes the call flow associated with an MS/AT dormant handoff from an HRPD to a 1x 2

system. Based on the MS/AT changing to a different ANID or for other reasons, a dormant handoff from 3

HRPD to 1x is determined to be required. In this scenario, it is assumed that the MS/AT has already 4

established an HRPD session, however it does not have a connection established. 5

SourceAN/PCF

TargetBSC/PCF PDSNMS/AT time

Origination (DRS='0')

BS Ack Order

e

f

g

Tregreq

h

Tregupd

Tregreq

a

b




c

d




6

Figure 4.1.3-1 HRPD to 1x Dormant Packet Data Session Handoff 7

a. Upon transitioning to the 1x system, the MS/AT transmits an Origination Message with DRS set to 8

‘0’ and with layer 2 acknowledgment required, over the access channel of the air interface to the 9

target BS/PCF to request service. This message may contain the SID, NID and PZID corresponding 10

to the source PCF from which the MS/AT is coming, if this capability is supported by the air 11

interface. If available, these values are used to populate the PANID field of the A11-Registration 12

Request message that the target BS/PCF sends to the PDSN. 13

b. The target BS/PCF acknowledges receipt of the Origination Message with a Base Station Acknow-14

ledgment Order to the MS/AT. 15

c. The target BS/PCF sends an A11-Registration Request message to the PDSN. The A11-Registration 16

Request message includes the MEI within the CVSE and the PANID and the CANID within the 17

NVSE. The target BS/PCF starts timer Tregreq. 18

d. The A11-Registration Request message is validated and the PDSN accepts the connection by return-19

ing an A11-Registration Reply message with an accept indication and the Lifetime set to the configur-20

ed Trp value. If the PDSN has data to send, it includes the Data Available Indicator within the CVSE. 21

The A10 connection binding information at the PDSN is updated to point to the target BS/PCF. The 22

target BS/ PCF stops timer Tregreq. 23

If the PDSN responds to the target BS/PCF with the Data Available Indicator, the target BS/PCF 24

establishes a traffic channel. 25

e. The PDSN initiates closure of the A10 connection with the source AN/PCF by sending an A11-Reg-26

istration Update message. The PDSN starts timer Tregupd. 27


4-6

f. The source AN/PCF responds with an A11-Registration Acknowledge message. The PDSN stops 1

timer Tregupd. 2

g. The source AN/PCF sends an A11-Registration Request message with Lifetime set to zero, to the 3

PDSN. The source AN/PCF starts timer Tregreq. 4

h. The PDSN sends an A11-Registration Reply message to the source AN/PCF. The source AN/PCF 5


7

8


4-7

4.2 MS/AT Terminated Voice Call During Active HRPD Packet Data Session 1

This section describes the call flows associated with an MS/AT terminated 1x voice call during an active 2

HRPD packet data session. when there is no connection between the HRPD and 1x systems. The call 3

flows in this section assume that the MS/AT periodically retunes to the 1x system to check for pages 4

while it is monitoring the HRPD system. 5

For call flows using the A1/A1p interface and CSNA, refer to sections 4.5 and 4.6. 6

4.2.1 MS/AT Terminated Voice Call During Active HRPD Packet Data Session (Intra-7

PDSN/Inter-PCF) 8

This scenario describes the call flow associated with an MS/AT terminated voice call while the MS/AT 9

has an active HRPD packet data session. The HRPD packet data session may be handed off to the 1x 10

system as a concurrent call service if the 1x system has this capability and the MS/AT selects this 11

capability. 12

Tregreq

Tregup

PDSN timeMS/AT

b

d

e

BS

c

f

g

AN

h

i

j

Page

HRPD active data session

a

k*

m*

PCF2

MS/AT stops transmitting to the AN

A9-Release-A8

Trel9

Page Response

p*

q*

r*

s*

t*

l*

TregreqTA8-setup

PCF11x HRPD

(Cause: Air link lost)

A9-Release-A8Complete

TCH setup

AWI

Origination forconcurrent service

A9-Setup-A8


A9-Connect-A8


cdma2000 active data session

TregreqA11-Registration Request


n*


A11-Registration Ack

(Lifetime=0)



(Lifetime=0, accept)

* = conditional

Connect Order

o*

13

Figure 4.2.1-1 Voice Call Termination During Active HRPD Packet Data Session (Inter-PCF) 14


4-8

a. The BS sends a Page Message containing the MS/AT address over the paging channel. If the user 1

elects to continue the HRPD session, then the MS/AT takes no further action, and the remaining steps 2

are not performed. 3

b. b. The MS/AT stops transmitting to the AN. The AN determines that it is not receiving any 4

transmissions from the MS/AT and considers the connection to be lost at this point. 5

c. The AN sends an A9-Release-A8 message with cause value indicating ‘Air link lost’, to PCF2 and 6

starts timer Trel9. The AN may send an A9-AL Disconnected message to the PCF2 (refer to section 7

3.8.1) before it determines that a connection has been lost. 8

d. PCF2 sends an A11-Registration Request message containing an Active Stop accounting record to the 9

PDSN and starts timer Tregreq. 10

e. The PDSN sends an A11-Registration Reply message to PCF2. PCF2 stops timer Tregreq upon receipt 11

of this message. 12

f. PCF2 sends an A9-Release-A8 Complete message to the AN. The AN stops timer Trel9. 13

g. The MS/AT sends a Page Response message to the BS. This step can occur any time after step b. 14

h. The BS establishes a traffic channel. 15

i. The BS sends an Alert with Info message to instruct the MS/AT to ring. 16

j. The MS/AT sends a Connect Order message when the call is answered at the MS/AT. 17

k. If the 1x system supports concurrent services and the MS/AT selects to transition the packet data 18

session to the 1x system, the MS/AT and the 1x system set up the packet data session as a concurrent 19

service Refer to [13], Section 3.18.1.1. Otherwise the call flow ends here. 20

l. The BS sends an A9-Setup-A8 message to PCF1 to establish the A8 connection and starts timer TA8-21

setup. If the MS/AT has indicated the presence of data ready to send, the BS shall set the Data Ready 22

Indicator to ‘1’; otherwise, the BS shall set the Data Ready Indicator to ‘0’. 23

m. PCF1 sends an A11-Registration Request message to the PDSN to establish the A10 connection. 24

PCF1 starts timer Tregreq. 25

n. The A11-Registration Request message is validated and the PDSN accepts the connection by return-26

ing an A11-Registration Reply message with an accept indication. PCF1 stops timer Tregreq. 27

o. PCF1 sends an A9-Connect-A8 message after the completion of the A10 connection setup. The BS 28

stops timer TA8-setup. 29

p. At this point, the packet data session is successfully transitioned from the HRPD to the 1x system. 30

q. The PDSN Initiates closure of the A10 connection with PCF2 by sending an A11-Registartion Update 31

message. The PDSN starts timer Tregupd. This step may occur immediately after step l. 32

r. PCF2 responds with an A11-Registartion Acknowledge message. The PDSN stops timer Tregupd. 33

s. PCF2 sends an A11-Registration Request message with Lifetime set to zero, to the PDSN. PCF2 34


t. The PDSN sends an A11-Registration Reply message to PCF2. PCF2 closes the A10 connection for 36

the MS/AT and stops timer Tregreq. 37

38

39


4-9

4.2.2 MS/AT Terminated Voice Call During Active HRPD Packet Data Session (Intra-PCF) 1

This scenario describes the call flow associated with an MS/AT terminated voice call while the MS/AT 2

has an active HRPD packet data session. The HRPD packet data session is transitioned to the 1x system 3

as a concurrent call service if the 1x system has this capability and the MS/AT selects this capability. 4

AN PDSNMS/AT

a

b

time

c

TCH Setup

A9-Release-A8(Cause: Air Link Lost)

d


e

BS PCFHRPD1x

Page

Page Response

Alert with Info

Connect Order

f

g

h

i

j

k

l

m

n

o

MS/AT stops trans-mitting to the AN

Origination forConcurrent Service

Active 1x Packet Data Session

TA8-setupA11-Registration RequestTregreqA11-Registration Reply

p

Trel9

A9-Connect-A8

A9-Setup-A8


A11 Registration ReplyTregreq

X


5

Figure 4.2.2-1 Voice Call Termination During Active HRPD Packet Data Session (Intra-PCF) 6

a. The BS sends a Page Message containing the MS/AT address over the paging channel. If the user 7

elects to continue the HRPD session, then the MS/AT takes no further action, and the remaining steps 8

are not performed. 9

b. The MS/AT stops transmitting to the AN. The AN determines that it is not receiving any 10

transmissions from the MS/AT considers the connection to be lost at this point. The AN may send an 11

A9-AL Disconnected message to the PCF (refer to section 3.8.1) before it determines that a 12

connection has been lost. 13

c. The AN sends an A9-Release-A8 message with cause value indicating ‘Air link lost’, to the PCF and 14

starts timer Trel9. 15

d. The PCF sends an A11-Registration Request message containing an Active Stop accounting record to 16

the PDSN and starts timer Tregreq. 17

e. The PDSN sends an A11-Registration Reply message to the PCF. The PCF stops the timer Tregreq 18

upon receipt of the message. 19


4-10

f. Upon receipt of the A9-Release-A8 message, the PCF sends an A9-Release-A8 Complete message to 1

the AN. The AN stops timer Trel9. 2

g. The MS/AT sends a Page Response message to the BS. This step can occur any time after step b. 3

h. The BS establishes a traffic channel. 4

i. The BS sends an Alert with Info message to instruct the MS/AT to ring. 5

j. The MS/AT and 1x system set up the packet data session as a concurrent service if the MS/AT 6

supports concurrent services and selects to transition the packet data session to the 1x system. Refer 7

to [13], Section 2.17.2.1 steps (a) to step (g). 8

k. The BS sends an A9-Setup-A8 message to the PCF to establish the A8 connection and starts timer 9

TA8-setup. If the MS/AT has indicated the presence of data ready to send, the BS shall set the Data 10

Ready Indicator to ‘1’; otherwise, the BS shall set the Data Ready Indicator to ‘0’. 11

l. The PCF sends an A11-Registration Request message containing an Active Start accounting record to 12

the PDSN and starts timer Tregreq. 13

m. The PDSN sends an A11-Registration Reply message to the PCF. The PCF stops the timer Tregreq 14

upon receipt of the message. 15

n. The PCF sends an A9-Connect-A8 message to the BS. The BS stops timer TA8-setup. 16

o. At this point, the packet data session has successfully transitioned from the HRPD system to the 1x 17

system. 18

p. The MS/AT sends a Connect Order message when the call is answered at the MS/AT. This step can 19

occur any time after step ‘i’. 20

21

22


4-11

4.3 1x to HRPD Active Packet Data Session Handoff 1

This section describes the call flow associated with an MS/AT AN change from an 1x to an HRPD 2

system. The MS/AT determines that an AN change from 1x to HRPD is required. In this scenario, it is 3

assumed that the MS/AT has already established an HRPD session, however it does not have a connection 4

established. 5

Handoff of the active 1x packet data session occurs via the dormant state. The transition from 1x active to 6

dormant may occur, e.g., according to [13] 3.17.4.3, MS Initiated Call Release to Dormant State. The 7

dormant handoff from 1x to HRPD occurs according to section 4.1.1 or 4.1.2 (1x to HRPD Dormant 8

Packet Data Session Handoff - Existing or New HRPD Session) as appropriate. Finally, the MS/AT 9

transitions from dormant to active on HRPD according to section 3.3.2, AT Initiated Call Re-activation 10

from Dormant State (Existing HRPD Session). 11

12

13


4-12

4.4 Status Management Supported by Feature Invocation 1

This scenario describes the call flow associated with status management using feature invocation. 2

Mobile Originating Call Setup

ANMS/AT

a

b

time

c

Origination

d

BS

e

MSC

(Feature Code)

1x HRPD

MSC Initiated Call Clearing

Mobile Initiated HRPD Connection Setup

Origination(Feature Code)

MSC Initiated Call Clearing

f

g

h

Mobile Initiated HRPD Connection Release

Mobile Originating Call Setup

3

Figure 4.4-1 Terminal Based Status Management (Using Feature Invocation) 4

a. The MS/AT sends an Origination Message, including the feature code as the called number, to the BS 5

when the MS/AT starts the HRPD communication. This feature code indicates that the MSC should 6

activate a feature (e.g., do not disturb). 7

b. The BS and the MSC set up the call. Refer to [13], Section 3.1.1, Mobile Origination. 8

c. The BS and the MSC clear the call. Refer to [13], Section 3.2.4.3, Call Clear Initiated by MSC. 9

d. The MS/AT starts communication on the HRPD session. Refer to Section 3.3.2, AT Initiated Call Re-10

activation from Dormant State (Existing HRPD Session). 11

e. The MS/AT terminates communication on the HRPD session when the HRPD session goes dormant 12

or inactive. Refer to Section 3.5.2, HRPD Session Release - Initiated by the AT (A8 Connections do 13

not Exist). 14

f. The MS/AT sends an Origination Message, including the feature code as the calling number, to the 15

BS when the MS/AT ends the HRPD communication. This feature code indicates that the MSC 16

should deactivate the feature activated in step a. 17

g. The BS and the MSC set up the call. Refer to [13], Section 3.1.1, Mobile Origination. 18

h. The BS and the MSC clear the call. Refer to [13], Section 3.2.4.3, Call Clear Initiated by MSC. 19

20

21


4-13

4.5 CSNA in the HRPD System 1

This section describes the call flows associated with the MS/AT receiving a 1x notification in an HRPD 2

system or an HRPD service option notification in a 1x system. The call flows in this section and section 3

4.6 use the A1/A1p interface to tunnel certain 1x messages between the HRPD AN and the 1x MSC in 4

support of CSNA. 5

The CSNA functionality addresses operation of an MS/AT that otherwise would have to periodically 6

retune to the 1x system to check for pages while it is monitoring the HRPD system. For CSNA, the AT 7

and the AN configure a filtering mechanism to allow notifications associated with certain services to be 8

tunneled between 1x and HRPD systems. CSNA also ensures that the AT stays registered in the 1x core 9

circuit network even when it is monitoring the HRPD system. 10

For call flows showing voice call delivery during an active HRPD session without CSNA, refer to section 11

4.2. 12

In this section, “HRPD:” denotes a message sent using the HRPD air interface and frequency while “1x:” 13

denotes a message sent using the 1x air interface and frequency. Refer to [10] and [27]. 14

Note: The HRPD AN only tunnels 1x messages to the MS/AT in the HRPD system if the Idle Tunnel 15

timer is active. For the call flows in this section and section 4.6, where the MS/AT is registered in and 16

monitoring the HRPD system, it is assumed that the Idle Tunnel timer is active. Support for the MS/AT 17

receiving an HRPD service option while in the 1x system has been added to this specification in 18

anticipation of the publication of [27]. 19

4.5.1 SMS – Mobile Originated Point-to-Point (ADDS Transfer) 20

This scenario describes the call flow for delivery of unicast Short Message Service (SMS) sent from an 21

MS/AT over the HRPD air interface. The MS/AT is registered in and monitoring the HRPD system when 22

the SMS message is sent. 23

HRPD AN MSC

a

b

time

HRPD encapsulated message:data burst message

MS/AT

ADDS Transfer

HRPD: ack

c

conditional

24

Figure 4.5.1-1 Mobile Originated Point-to-Point SMS in an HRPD System 25

a. The MS/AT sends a short message to the HRPD AN. 26

b. If an acknowledgement was solicited, the HRPD AN acknowledges the receipt of the short message. 27

c. The HRPD AN sends an ADDS Transfer message to the MSC. 28

29

30


4-14

4.5.2 SMS – Mobile Terminated Point-to-Point (ADDS Page / ADDS Page Ack) 1

This scenario describes the call flow for delivery of unicast SMS to an MS/AT over the HRPD air inter-2

face. The MS/AT is registered in and monitoring the HRPD system when the SMS message arrives at the 3

MSC, destined for the MS/AT. 4

HRPD AN MSC

a

b

time

HRPD: data burst message

c

MS/AT

ADDS Page Ack

ADDS Page

T3113

d

HRPD: ack conditional

conditional

5

Figure 4.5.2-1 Mobile Terminated Point-to-Point SMS in an HRPD System 6

a. The MSC determines that a point-to-point short message is to be sent to an MS/AT. The MSC sends 7

an ADDS Page message to the HRPD AN. The ADDS Page message contains the short message in its 8

ADDS User Part information element (IE). If the MSC requires an acknowledgement, it includes the 9

Tag IE in the ADDS Page message and starts timer T3113. 10

b. The HRPD AN sends the short message to the MS/AT. Before sending the short message, the HRPD 11

AN may perform vendor specific procedures such as paging the MS/AT to determine the cell in 12

which the MS/AT is located. If a Layer 2 Ack was requested by the MSC, the HRPD AN requests an 13

ack from the MS/AT. 14

c. If an acknowledgement was solicited, the MS/AT acknowledges the receipt of the message. 15

d. If the MSC requested an acknowledgment by including the Tag IE in the ADDS Page message, the 16

HRPD AN replies with an ADDS Page Ack message including the Tag IE set identical to the value 17

sent by the MSC. If timer T3113 was previously started, it is now stopped. 18

19

20


4-15

4.5.3 1x Page Delivery to the MS/AT in an HRPD System (Paging Request) 1

This scenario describes the call flow associated with an MS/AT 1x call termination, paging and service 2

option notification over the HRPD air interface. The MS/AT is registered in and monitoring the HRPD 3

system when the call arrives at the MSC, destined for the MS/AT. 4

1x BS MSCMS/AT

a

time

b

c

HRPD AN

1x: Page Response Message

Paging Request

T3113

Paging Request

HRPD: 3G1XServices packet(General Page Message)

Complete L3 Info:Paging Response d

T3113

f

e1x MT Call Setup Proceeds

Event Notification optional

5

Figure 4.5.3-1 1x Page Delivery to the MS/AT in an HRPD System 6

a. The MSC determines that an incoming call terminates to an MS/AT within its serving region. The 7

MSC sends a Paging Request message to the HRPD AN and one or more 1x BSs reachable by an 8

MS/AT within the HRPD AN’s paging area. The MSC starts an instance of timer T3113 for each 9

Paging Request message sent. Note that the Paging Request message may contain a Virtual Page 10

Indicator (VPI) identifying that the 1x BS shall prepare to receive a Page Response Message from the 11

MS/AT. 12

b. The HRPD AN sends a General Page Message to the MS/AT. 13

c. The MS/AT tunes to the 1x system and acknowledges the page by transmitting a Page Response 14

message over the 1x Access Channel. 15

d. The 1x BS constructs the Paging Response message, places it in the Complete Layer 3 Information 16

message, and sends the message to the MSC. If the Paging Request message contained a Tag IE, the 17

1x BS includes this IE in the Paging Response message. The MS/AT is implicitly registered in the 1x 18

system. Refer to [13] for completion of the MS call termination in the 1x system. The MSC stops all 19

instances of timer T3113 for this MS/AT. 20

e. The 1x BS/MSC continues with MT call setup procedures. Refer to [13] for completion of the MS 21

call termination in the 1x system. 22

f. The MSC may determine that the MS/AT, which has subscribed to Cross Notification services, has 23

registered with the 1x system and send an Event Notification message to the HRPD AN containing 24

registration event. This step can occur anytime after step ‘d’. 25

26

27


4-16

4.5.4 HRPD Page Delivery in a 1x System - MS/AT Idle 1

This scenario describes the call flow associated with delivery of an HRPD page to the MS/AT over the 1x 2

air interface and data delivered over the HRPD air interface. The MS/AT is registered in and monitoring 3

the 1x system and idle when the packet data arrives at the HRPD AN/PCF, destined for the MS/AT. Refer 4

to section 4.5.5 when the MS/AT is active with a voice call. 5

Note: If the MS/AT decides not to accept the HRPD page, the call flow would end at step ‘g’. 6

1x BS MSC PDSNMS/AT

c

time

b

d

eT3113

i

a

j*

l

HRPD AN/PCF

Data flow

Connection establishment

Paging Request

1x: page

T311BS Service Response

BS Service Request

A11 acct.

packet data

Data flow

1x: Page ResponseComplete L3 Info: Paging

Response

1x: L2 Ack

f*

g*

h*

* = optional

k

Registration and location updating procedures

7

Figure 4.5.4-1 HRPD Page Delivery in a 1x System - MS/AT Idle 8

a. The PDSN sends packet data to the HRPD AN/PCF on an existing PPP connection associated with a 9

specific MS/AT and dormant packet data session. 10

b. Based on vendor specific procedures (e.g., stored information indicating that the MS/AT has register-11

ed with the 1x system), the HRPD AN sends a BS Service Request message, containing an HRPD 12

service option, to the MSC and starts timer T311. This message contains a data burst of type 7; refer to 13

[C.S0075-0 v1.0]. 14

c. The MSC responds with a BS Service Response message. The HRPD AN stops timer T311. 15

d. Receipt of a BS Service Request message, containing the HRPD service option, triggers the MSC to 16

send a Paging Request message, containing the HRPD service option, to the 1x BS. The MSC starts 17

timer T3113. 18

e. The 1x BS pages the MS/AT with the HRPD service option. 19

f. If required by the BS, the MS/AT acknowledges the page by transmitting a Page Response message 20

over the 1x Access Channel. Otherwise the MS/AT proceeds to step ‘i’. 21

g. The 1x BS constructs the Paging Response message, places it in a Complete Layer 3 Information 22

message and sends the message to the MSC. The MSC stops timer T3113 upon receipt of the Paging 23

Response message. 24

Note: The 1x BS does not start timer T303 and does not anticipate receiving an Assignment Request 25

message from the MSC or an SCCP connection response from the MSC. 26


4-17

h. The 1x BS sends a Layer 2 Ack to the MS/AT in response to the Page Response. 1

i. The MS/AT tunes to the HRPD system and initiates connection establishment procedures with the 2

HRPD AN. Refer to [10], section 9.4.6.1.6, Connection Setup State. 3

j. The MS/AT may register with the HRPD AN/PCF and the HRPD AN/PCF may then perform 4

Location Updating procedures with the MSC. Refer to section 4.6.1 for registration and location 5

updating procedures 6

k. A11 accounting procedures take place on the A11 interface. 7

l. At this point the connection is established and HRPD packet data can flow between the MS/AT and 8

the PDSN. 9

10

11


4-18

4.5.5 HRPD Page Delivery in a 1x System - MS/AT on a Traffic Channel (TCH) 1

This scenario describes the call flow associated with delivery and acceptance of an HRPD page to the 2

MS/AT over the 1x air interface and data delivered over the HRPD air interface. The MS/AT is registered 3

in the 1x system and on a traffic channel when the packet data arrives at the HRPD AN/PCF, destined for 4

the MS/AT. 5

Note: If the MS/AT decides not to accept the HRPD page, the call flow would end at step ‘g’. 6

1x BS MSC PDSNMS/AT

c

time

b

d

eT3113

l

a

o

p

HRPD AN/PCF

Data flow

Connection establishment

ADDS Deliver

1x: Data Burst Message

T311BS Service Response

BS Service Request

A11 acct.

packet data

Data flow

1x: Layer 2 Ack

ADDS Deliver Ack

1x: release

f

g

h1x: release

Clear Request

Clear Command

Clear Complete

k

j

i

m

T315

T300

n*Registration and location updating procedures

* = optional 7

Figure 4.5.5-1 HRPD Page Delivery in a 1x System - MS/AT on TCH 8

a. The PDSN sends packet data to the HRPD AN/PCF on an existing PPP connection associated with a 9

specific MS/AT and dormant packet data session. 10

b. Based on vendor specific procedures (e.g., stored information indicating that the MS/AT has 11

registered with the 1x system), the HRPD AN sends a BS Service Request message indicating that 12

packet data is received at the HRPD system to the MSC and starts timer T311. This message contains 13

a data burst of type 7; refer to [C.S0075-0 v1.0]. 14

c. The MSC responds with a BS Service Response message. The HRPD AN stops timer T311. 15

d. Receipt of the BS Service Request message, and the MS/AT being on a traffic channel, triggers the 16

MSC to send an ADDS Deliver message to the 1x BS. The MSC starts timer T3113. 17

e. The 1x BS transmits the data burst received in step ‘d’ over the forward traffic channel. 18

f. The MS/AT acknowledges delivery of the data burst on the traffic channel with a Layer 2 Ack. 19

g. If the MSC had requested a response by including the Tag IE in the ADDS Deliver message, the 1x 20

BS replies with an ADDS Deliver Ack message including the same Tag IE in the in the ADDS 21


4-19

Deliver message when it has received acknowledgement from the MS/AT that the message was 1

delivered. 2

h. The MS/AT initiates call clearing by transmitting a release over the reverse traffic channel. 3

i. The 1x BS sends a Clear Request message to the MSC to initiate the call clearing transaction. The 1x 4

BS starts timer T300. 5

j. The MSC sends a Clear Command message to the 1x BS to instruct the 1x BS to release the associat-6

ed dedicated resource and starts timer T315. The 1x BS stops timer T300. 7

k. In response to the Clear Command message the 1x BS releases the terrestrial circuit, if allocated. The 8

1x BS then acknowledged the MS/AT by sending a release over the forward traffic channel and 9

releases the radio resource. 10

l. The 1x BS returns a Clear Complete message to the MSC. The MSC stops timer T315 upon receipt of 11

the Clear Complete message and releases the underlying transport connection. 12

m. The MS/AT tunes to the HRPD system and initiates connection establishment procedures with the 13

HRPD AN. refer to [10], section 9.4.6.1.6, Connection Setup State. 14

n. The MS/AT may register with the HRPD AN/PCF and the HRPD AN/PCF may then perform 15

Location Updating procedures with the MSC. Refer to section 4.6.1 for registration and location 16

updating procedures. 17

o. A11 accounting procedures take place on the A11 interface. 18

p. At this point the connection is established and HRPD packet data can flow between the MS/AT and 19

the PDSN. 20

21

22


4-20

4.6 Mobility Management for CSNA in the HRPD System 1

This section describes how mobility management is performed with the HRPD network while the MS/AT 2

is monitoring 1x and vice-versa. 3

4.6.1 1x Registration Over HRPD 4

This scenario describes the call flow associated with an MS/AT in an HRPD system maintaining registrat-5

ion in the 1x system. The HRPD air interface may or may not broadcast route update triggers on the 6

control channel. When route update triggers are sent, the MS/AT (both in idle or connected state), uses 7

this information to send a RouteUpdate message for subsequent determination as to whether registration 8

is required. If route update triggers are not provided, determination for sending a RouteUpdate message 9

for the idle MS/AT may also be due to noticing a new registration zone during a periodic visit to the 1x 10

system. 11

This call flow does not take into consideration how the HRPD AN determines that registration is required, 12

only that a registration is to be performed with the 1x system. 13

HRPD AN TargetMSCMS/AT

a

b

time

d

c

HRPD: RouteUpdate

HRPD: Registration Accepted Order)

Location Updating RequestT3210

HRPD: Registration Order)

HRPD: Registration Message)

Location Updating Accept e

f 14

Figure 4.6.1-1 1x Registration Over HRPD 15

a. The MS/AT sends a RouteUpdate message. 16

b. The HRPD AN determines that registration is required and sends a Registration Order to the MS/AT. 17

c. The MS/AT sends a Registration message to the HRPD AN. 18

d. On reception of the Registration message, the HRPD AN constructs the Location Updating Request 19

message, places it in the Complete Layer 3 Information message, and sends it to the target MSC. The 20

HRPD AN then starts timer T3210. 21

e. The target MSC sends the Location Updating Accept message to the HRPD AN to indicate that the 22

Location Updating Request message has been processed. Upon receipt of the Location Updating 23

Accept message, the HRPD AN stops timer T3210. 24

f. The HRPD AN sends a Registration Accepted Order to the MS/AT. 25

26

27

28

29

30


5-1

5 Messages, Information Elements and Timer Definitions 1

5.1 Message Definitions 2

5.1.1 A13 Message Definitions 3

5.1.1.1 A13-Session Information Request 4

This message is sent from the target AN to the source AN to request session control information for a 5

particular AT. 6

Information Element Section Reference Element Direction Type A13 Message Type 5.2.1.3 Target → Source M

UATI 128 5.2.1.4 Target → Source Oa R Security Layer Packet 5.2.1.5 Target → Source O R

Sector ID (target) 5.2.1.6 Target → Source O R

a. Refer to section 2.5 for information on this IE. 7

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

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

⇒⇒⇒⇒ A13 Message Type = [01H] 1

⇒⇒⇒⇒ UATI 128: A13 Element Identifier = [01H] 1

Length = [10H] 2

(MSB) UATI 3 4

… … (LSB) 18

⇒⇒⇒⇒ Security Layer Packet: A13 Element Identifier = [02H] 1

Length = [variable] 2

(MSB) Security Layer Packet 3 4

… … (LSB) N

⇒⇒⇒⇒ Sector ID: A13 Element Identifier = [03H] 1

Length = [10H] 2 (MSB) Sector ID 3

4

… … (LSB) 18

9

10


5-2

5.1.1.2 A13-Session Information Response 1

This message is sent from the source AN to the target AN and includes the requested session control 2

information. 3

Information Element Section Reference Element Direction Type A13 Message Type 5.2.1.3 Source → Target M UATI 128 5.2.1.4 Source → Target Oa R

Mobile Identity (MN ID) 5.2.1.8 Source → Target O R

PDSN IP Address 5.2.1.9 Source → Target O R

Access Network Identifiers 5.2.1.10 Source → Target O R

Session State Information Record 5.2.1.11 Source → Target Ob,c,d,f R

Extended Session State Information Record 5.2.1.12 Source → Target Od,e,f C

Forward QoS Information 5.2.1.13 Source → Target Og C Reverse QoS Information 5.2.1.14 Source → Target Og C

Subscriber QoS Profile 5.2.1.15 Source → Target Oh C

a. The UATI is set to the same value as the UATI sent in the A13-Session Information Request 4

message. 5

b. Multiple instances of this IE may be included, where one instance of this IE contains one Session 6

State Information Record (SSIR) for the main HRPD personality, as specified in [10]. Therefore the 7

target AN knows that the Personality Index for this SSIR is 0. 8

c. SSIR includes the requested QoS Sub Blob and granted QoS Sub Blob formatted as specified in [10]. 9

Refer to [8] and [10] for detailed information. 10

d. Attributes with default values shall not be sent to the target node. If an attribute is not contained in the 11

SSIR, the target node shall assume that the missing attribute(s) have the default values (specified for 12

each attribute in each protocol). 13

e. This IE is included when the HRPD session includes on multiple personalities is available. Multiple 14

instances of this IE may be included, where one instance of this IE contains one SSIR for an HRPD 15

personality that is not the main personality, as specified in [10]. Multiple instances of this IE shall be 16

sorted in order of increasing personality index. 17

f. Protocols with default and hardlink subtypes shall be coded as specified in [10]. 18

g. This IE is included if the information is available at the source AN. 19

h. Subject to configuration4, this IE is included if the information is available at the source AN. If the 20

target AN subsequently receives this information from the PDSN, then the information received from 21

the PDSN takes precedence. 22

23

4 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 A13-Session Information Response message instead. This information should not be sent over both A11 and A13.


5-3

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

5.1.1.2 A13-Session Information Response 7 6 5 4 3 2 1 0 Octet



Length = [10H] 2 (MSB) UATI 3

4

… … (LSB) 18

⇒⇒⇒⇒ Mobile Identity (MN ID): A13 Element Identifier = [05H] 1

Length = 10-15 digits 2 Identity Digit 1 = [0H-9H] (BCD) Odd/even

Indicator = [1,0]

Type of Identity = [110] (MN ID)

3

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

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

n = [1111] (if even number of digits) Identity Digit N+2 = [0H-9H] (BCD) n+1

⇒⇒⇒⇒ PDSN IP Address: A13 Element Identifier = [06H] 1

Length = [04H] 2 (MSB) PDSN IP Address 3

4 5

(LSB) 6

⇒⇒⇒⇒ Access Network Identifiers: A13 Element Identifier = [07H] 1

Type = 01H 2

Length = [05H] 3 Reserved (MSB) SID 4

(LSB) 5 (MSB) NID 6

(LSB) 7 PZID 8

⇒⇒⇒⇒ Session State Information Record: A13 Element Identifier = [08H] 1

(MSB) Length = [variable] 2

(LSB) 3 (MSB) Session State Information Record 4


5-4


… …! (LSB) n

⇒⇒⇒⇒ Extended Session State Information Record: A13 Element Identifier = [09H] 1


(LSB) 3 Reserved = [0000] Personality Index 4

(MSB) Session State Information Record 5

… … (LSB) n

⇒⇒⇒⇒ Forward QoS Information: A13 Element Identifier = [0AH] 1


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

Reserved = [0 0000] SR_ID = [1 - 7] j+1

Reserved = [000] Forward Flow Count = [0 - 31] j+2

Forward Flow Entry { Forward Flow ID Count : Entry Length = [02H] k

Forward Flow ID = [00H – FFH] k+1

} Forward Flow Entry } Forward QoS Information Entry

⇒⇒⇒⇒ Reverse QoS Information: A13 Element Identifier = [0BH] 1


Reverse QoS Information Entry { 1-7: Entry Length = [variable] j

Reserved = [0 0000] SR_ID = [1 - 7] j+1 Reserved = [000] Reverse Flow Count = [0 - 31] j+2

Reverse Flow Entry { Reverse Flow Count : Entry Length = [02H] k

Reverse Flow ID = [00H – FFH] k+1

} Reverse Flow Entry } Reverse QoS Information Entry

⇒⇒⇒⇒ Subscriber QoS Profile: A13 Element Identifier = [0CH] 1

Length = [variable] 2 (MSB) Subscriber QoS Profile = <any value> 3

4


5-5


… … (LSB) n

1

5.1.1.3 A13-Session Information Confirm 2

This message is sent from the target AN to the source AN to indicate that the target AN has successful-3

ly received the session control information for the requested AT. 4

Information Element Section Reference Element Direction Type A13 Message Type 5.2.1.3 Target → Source M UATI 128 5.2.1.4 Target → Source Oa R

a. The UATI is set to the same value as the UATI sent in the A13-Session Information Request message. 5

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

5.1.1.3 A13-Session Information Confirm 7 6 5 4 3 2 1 0 Octet



Length = [10H] 2 (MSB) UATI 3

4

… … (LSB) 18

7

5.1.1.4 A13-Session Information Reject 8

This message is sent from the source AN to the target AN to indicate that the request for session control 9

information has been denied. 10

Information Element Section Reference Element Direction Type A13 Message Type 5.2.1.3 Source → Target M UATI 128 5.2.1.4 Source → Target Oa R

Cause 5.2.1.7 Source → Target O R

a. The UATI is set to the same value as the UATI sent in the A13-Session Information Request message. 11

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

5.1.1.4 A13-Session Information Reject 7 6 5 4 3 2 1 0 Octet



5-6

5.1.1.4 A13-Session Information Reject 7 6 5 4 3 2 1 0 Octet


Length = [10H] 2

(MSB) UATI 3 4

… … (LSB) 18

⇒⇒⇒⇒ Cause: A13 Element Identifier = [04H] 1

Length = [01H] 2

Cause Value = [ 01H (Protocol Subtype Not Recognized), 02H (Protocol Subtype Attribute(s) Not Recognized) 03H (Protocol Subtype Attribute(s) Missing) 04H (Requested Session Not Found) 05H (Requested Session Not Authentic)]

3

1

2


5-7

5.2 Information Element Definitions 1

5.2.1 A13 Information Element Definitions 2

5.2.1.1 Information Element Identifiers 3

The following table lists all the IEs that make up the messages defined in section 5.1. The table includes 4

the Information Element Identifier (IEI) coding which distinguishes one IE from another. The table also 5

includes a section reference indicating where the IE coding can be found. 6

Element Name IEI (Hex) Reference UATI 128 01H 5.2.1.4 Security Layer Packet 02H 5.2.1.5 SectorID 03H 5.2.1.6 Cause 04H 5.2.1.7 Mobile Identity (MN ID) 05H 5.2.1.8 PDSN IP Address 06H 5.2.1.9 Access Network Identifiers 07H 5.2.1.10 Session State Information Record 08H 5.2.1.11 Extended Session State Information Record 09H 5.2.1.12 Forward QoS Information 0AH 5.2.1.13 Reverse QoS Information 0BH 5.2.1.14 Subscriber QoS Profile 0CH 5.2.1.15

7

5.2.1.2 Cross Reference of IEs with Messages 8

The following table provides a cross reference between the IEs and the messages defined in this specifi-9

cation. 10

Table 5.2.1.2-1 Cross Reference of IEs with Messages

Information Element Ref. IEI Used in These Messages Ref. A13 Message Type 5.2.1.3 none A13-Session Information Request 5.1.1.1 A13-Session Information Response 5.1.1.2 A13-Session Information Confirm 5.1.1.3 A13-Session Information Reject 5.1.1.4

Access Network Identifiers 5.2.1.10 07H A13-Session Information Response 5.1.1.2

Cause 5.2.1.7 04H A13-Session Information Reject 5.1.1.4 Extended SSIR 5.2.1.12 09H A13-Session Information Response 5.1.1.2 Forward QoS Information 5.2.1.13 0AH A13-Session Information Response 5.1.1.2 Mobile Identity (MN ID) 5.2.1.8 05H A13-Session Information Response 5.1.1.2 PDSN IP Address 5.2.1.9 06H A13-Session Information Response 5.1.1.2 Reverse QoS Information 5.2.1.14 0BH A13-Session Information Response 5.1.1.2 SectorID 5.2.1.6 03H A13-Session Information Request 5.1.1.1


5-8

Table 5.2.1.2-1 Cross Reference of IEs with Messages

Information Element Ref. IEI Used in These Messages Ref. Security Layer Packet 5.2.1.5 02H A13-Session Information Request 5.1.1.1 Session State Information Record 5.2.1.11 08H A13-Session Information Response 5.1.1.2 Subscribed QoS Profile 5.2.1.15 0CH A13-Session Information Response 5.1.1.2 UATI 128 0 01H A13-Session Information Request 5.1.1.1 A13-Session Information Response 5.1.1.2 A13-Session Information Confirm 5.1.1.3 A13-Session Information Reject 5.1.1.4

1

5.2.1.3 A13 Message Type 2

The A13 Message Type IE is used to indicate the type of message on the A13 interface. 3

A13 Message Name A13 Message Type Section Reference A13-Session Information Request 01H 5.1.1.1 A13-Session Information Confirm 02H 5.1.1.3 A13-Session Information Reject 03H 5.1.1.4 A13-Session Information Response 04H 5.1.1.2

4

5.2.1.4 Unicast Access Terminal Identifier (UATI 128). 5

This IE is set to the terminal identifier associated with the AT. 6

5.2.1.4 Unicast Access Terminal Identifier (UATI 128). 7 6 5 4 3 2 1 0 Octet

A13 Element Identifier = [01H] 1

Length 2 (MSB) UATI 3

4

… … (LSB) 18

Length This field contains the number of octets in this IE following this field as a binary number. 7

UATI This is set to the 128-bit terminal identifier associated with the AT and is determined by 8

the target AN. Refer to section 2.5. 9

10

5.2.1.5 Security Layer Packet 11

This IE is set to the security layer packet received from the AT. 12


5-9

5.2.1.5 Security Layer Packet 7 6 5 4 3 2 1 0 Octet

A13 Element Identifier = [02H] 1 Length 2

(MSB) Security Layer Packet 3 4

… … (LSB) n

Length This field contains the number of octets in this IE following this field as a binary 1

number. 2

Security Layer Packet This is set to the security layer packet received from the AT. 3

4

5.2.1.6 SectorID 5

The AN shall set this field to the address of the sector on which the access from the AT was received. The 6

Sector ID is used with the Security Layer Packet to authenticate the session information request. 7

5.2.1.6 SectorID 7 6 5 4 3 2 1 0 Octet


(MSB) Sector ID 3 4

… … (LSB) 18


Sector ID This is set to the 128-bit address of the sector. 9

10

5.2.1.7 Cause 11

This IE is used to indicate the reason for occurrence of a particular event and is coded as follows. 12

5.2.1.7 Cause 7 6 5 4 3 2 1 0 Octet


(MSB) Cause Value (LSB) 3


Cause Value This field is set to the range of values as follows: 14


5-10

Hex Values Meaning 01 Protocol Subtype Not Recognized 02 Protocol Subtype Attribute(s) Not Recognized 03 Protocol Subtype Attribute(s) Missing 04 Requested Session Not Found 05 Requested Session Not Authentic

1

5.2.1.8 Mobile Identity (MN ID) 2

This IE is used to provide the AT’s Mobile Node Identification (MN ID). 3

5.2.1.8 Mobile Identity (MN ID) 7 6 5 4 3 2 1 0 Octet

A13 Element Identifier = [05H] 1 Length = 14-15 digits 2

Identity Digit 1 = [0H-9H] (BCD) Odd/even Indicator = [1,0]

Type of Identity = [110] (MN ID)

3


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

= [1111] (if even number of digits) Identity Digit N+2 = [0H-9H] (BCD) n+1


5

5.2.1.9 PDSN IP Address 6

This IE is used to provide the PDSN address. 7

5.2.1.9 PDSN IP Address 7 6 5 4 3 2 1 0 Octet


(MSB) PDSN IP Address 3

4 5

(LSB) 6

Length This field contains the number of octets in this IE following this field as a binary 8

number. If the PDSN IP Address is not available, the length field shall be set to 9

00H. 10

PDSN IP Address This field is set to the IPv4 address of a PDSN. 11


5-11

1

5.2.1.10 Access Network Identifiers 2

This IE uniquely identifies the PCF and is used by the PDSN to determine if it owns the connection. If so 3

the PDSN does not need to send agent advertisements. If not, then the PDSN needs to trigger an MIP 4

Registration Request so that the Foreign Agent/Home Agent tunnel is set up properly. 5

5.2.1.10 Access Network Identifiers 7 6 5 4 3 2 1 0 Octet

A13 Element Identifier = [07H] 1 Type = 01H 2

Length 3 Reserved (MSB) SID 4

(LSB) 5 (MSB) NID 6

(LSB) 7 PZID 8

Type This field identifies the ANID Sub Type (01H). 6


SID This two octet field is coded to a value that uniquely identifies the cellular or PCS 8

system. 9

NID This two octet field is coded to a value that uniquely identifies the network within a 10

cellular or PCS system. 11

PZID This one octet field is coded to a value that uniquely identifies the PCF coverage Area 12

within a particular SID/NID area. The combined SID/NID/PZID triplet is unique to a 13

PCF. 14

15

5.2.1.11 Session State Information Record 16

This IE is used to send HRPD Session Information for one [protocol type, protocol subtype] pair for the 17

main HRPD personality (i.e., the personality with Personality Index = 0) as specified in [10]. 18

If the AT’s HRPD session does not support personalities, then this element is used to send HRPD Session 19

Information for one [protocol type, protocol subtype] pair of the HRPD session as specified in [10]. 20

5.2.1.11 Session State Information Record 7 6 5 4 3 2 1 0 Octet

A13 Element Identifier = [08H] 1 (MSB) Length 2

(LSB) 3 (MSB) Session State Information Record 4

… …


5-12

5.2.1.11 Session State Information Record 7 6 5 4 3 2 1 0 Octet

(LSB) n

Length This field contains the number of octets in this IE following this 1

field as a binary number. 2

Session State Information Record This field contains the air interface protocol attributes and assoc-3

iated public data for one [protocol type, protocol subtype] pair. 4

The format is as specified in [10]. 5

6

5.2.1.12 Extended Session State Information Record 7

This IE is used to send HRPD Session Information for one [protocol type, protocol subtype] pair of an 8

HRPD personality that is not the main personality, as specified in [10]. 9

5.2.1.12 Extended Session State Information Record 7 6 5 4 3 2 1 0 Octet

A13 Element Identifier = [09H] 1 (MSB) Length 2

(LSB) 3 Reserved Personality Index 4

(MSB) Session State Information Record 5

… … (LSB) n



Personality Index This field identifies the applicable HRPD personality of which 12

this SSIR is a part. Refer to [10]. 13

Session State Information Record This field contains the air interface protocol attributes and assoc-14

iated public data for one [protocol type, protocol subtype] pair. 15

The format is as specified in [10]. 16

17

5.2.1.13 Forward QoS Information 18

This IE provides mappings of forward IP flow(s) to service connection. 19

5.2.1.13 Forward QoS Information 7 6 5 4 3 2 1 0 Octet

A13 Element Identifier = [0AH] 1

Length 2 Forward QoS Information Entry 1 variableForward QoS Information Entry 2 variable


5-13


… … Forward QoS Information Entry n variable



Forward QoS Information Entry Each Forward QoS Information Entry specifies all of the forward 3

IP flow(s) that are associated with a given service connection. 4

Each entry is coded as follows. 5

6


Entry Length 1 Reserved SR_ID 2

Reserved Forward Flow Count 3

Forward Flow Entry 1 variableForward Flow Entry 2 variable

… … Forward Flow Entry n variable

7

Entry Length This field contains the number of octets in this entry following 8

the Entry Length field as a binary number. 9

SR_ID This field identifies the service connection. 10

Forward Flow Count This field indicates the number of Forward Flow Entry fields 11

contained in this Forward QoS Information Entry. 12

Forward Flow Entry i This set of fields contains the forward flow ID(s) associated with 13

the service connection identified by the SR_ID field. Each 14

Forward Flow Entry is coded as follows. 15

16


Entry Length 1

Forward Flow ID i 2 17



Forward Flow ID i This field contains the flow ID of a given forward IP flow. Refer 20

to [8] for detailed information. 21


5-14

5.2.1.14 Reverse QoS Information 1

This IE provides mappings of reverse IP flow(s) to service connection. 2

5.2.1.14 Reverse QoS Information 7 6 5 4 3 2 1 0 Octet

A13 Element Identifier = [0BH] 1

Length 2 Reverse QoS Information Entry 1 variableReverse QoS Information Entry 2 variable

… … Reverse QoS Information Entry n variable

3



Reverse QoS Information Entry Each Reverse QoS Information Entry specifies all of the reverse 6




Entry Length 1 Reserved SR_ID 2

Reserved Reverse Flow Count 3

Reverse Flow Entry 1 variableReverse Flow Entry 2 variable

… … Reverse Flow Entry n variable

9



SR_ID This field identifies the service connection. 12

Reverse Flow Count This field indicates the number of Reverse Flow Entry fields 13

contained in this Reverse QoS Information Entry. 14

Reverse Flow Entry i This set of fields contains the reverse flow ID(s) associated with 15


Reverse Flow Entry is coded as follows. 17

18


Entry Length 1

Reverse Flow ID i 2


5-15

1



Reverse Flow ID i This field contains the flow ID of a given reverse IP flow. Refer 4


6

5.2.1.15 Subscriber QoS Profile 7

This IE is used to provide Subscriber QoS Profile. 8

5.2.1.15 Subscriber QoS Profile 7 6 5 4 3 2 1 0 Octet

A13 Element Identifier = [0CH] 1 Length 2

Subscriber QoS Profile variable 9



Subscriber QoS Profile This field contains Subscriber QoS Profile formatted as RADIUS 12

attributes. Refer to [8] for detailed information. 13

14

15

16


5-16

5.3 Timer Definitions 1

This section describes the timers associated with the HRPD IOS specification. 2

Timer Name

Default Value

(seconds)

Range of Values

(seconds)

Granularity

(seconds)

Section Reference

Classification

TA13req 1 0.1 - 60.0 0.1 5.3.1.1 A13 interface Tnet conn 5 0.1 - 60.0 0.1 5.3.1.2 A9 interface

3

5.3.1 Timer Descriptions 4

5.3.1.1 Timer TA13req 5

This AN timer is started when the target AN sends an A13-Session Information Request message to the 6

source AN and is stopped when the A13-Session Information Response message or A13-Session In-7

formation Reject message is received. 8

5.3.1.2 Timer Tnet_conn 9

This PCF timer is started when the PCF receives the A9-BS Service Response message from the AN and 10

is stopped when the A9-Setup-A8 message is received from the AN. 11

12

13

14


A-1

Annex A Transport Change Text (Normative) 1

Note: Annex A, contains specific Transport text from [12] with all HRPD related changes identified 2

through the use of underscores (additions) and strikeouts (deletions). Use of an ellipsis (…) indicates that 3

the base document is unchanged. All references in the following sections of this annex pertain to [12]. 4

... 5

2.4.4 Transport Network IP Quality of Service (QoS) Framework 6

To ensure that the transport network provides the necessary performance characteristics, the end nodes 7

and transport network interfaces which require transport QoS shall support the Differentiated Services 8

(DiffServ) framework as specified in [33], with the following clarifications: 9

• The A1p/A2p, A3/A7, A8/A9 and A10/A11 network portions of the RAN transport network may be 10

over-provisioned in comparison to the air interface (BS to MS) capacity, and the A1p/A2p, A3/A7, 11

A8/A9 and A10/A11 network traffic loads, or both. In case a RAN transport network is over-12

provisioned, the QoS framework in this section is not applicable to that transport network. 13

• Transport nodes (e.g., interior routers) shall support the following: 14

o Per packet classification according to the Type of Service (TOS)/Differentiated Services Code 15

Point (DSCP) field in the IPv4 header 16

o One or more queuing disciplines to meet the interface’s delay/jitter requirements. 17

• Edge transport nodes (e.g., border routers) shall support the following: 18

o Policing disciplines to meet the traffic flow requirements. 19

• End host nodes (e.g., BS, PCF, PDSN’s) shall support the following when required: 20

o Per packet marking of a DSCP via the IPv4 TOS octet according to the prescribed DSCP value 21

(refer to section 2.6.2). 22

o Four or more traffic classes as defined by the relevant interface. The parameters of each class 23

include mandatory and optional traffic types, service delay, and packet loss rate. 24

... 25

2.5.1 Message Delimiting in TCP 26

TCP provides a reliable transfer of byte streams between two application entities. Because the protocol in 27

this standard uses IOS Application messages to communicate, these messages shall be delimited in the 28

TCP byte stream. Such delimitation shall be done by means of a message delimitation header, comprising 29

of a one byte field and a variable length message delimiter whose format is specified by the version in 30

use, inserted at the beginning of each IOS Application message. two byte flag field and a two byte length 31

field inserted at the beginning of each message sent over a TCP connection. The flag field shall contain 32

the hex value “F634”. The purpose of the flag field is to facilitate verification of message boundaries and 33

to speed up reestablishment of synchronization if synchronization of message boundaries is lost. Refer to 34

Figure 2.5.1-1. 35

A TCP segment (i.e., a segment of the byte stream transferred in one TCP PDU) may contain all or 36

portions of several IOS Application messages. IOS Application messages follow each other in the TCP 37

byte stream. The beginning of each IOS Application message is preceded immediately by a message 38

delimitation header as shown in the Figure 2.5.1-1. 39


A-2

When a TCP connection is opened, the first octet of the payload of the first TCP segment sent over that 1

connection shall coincide with the Version field of a message delimitation header. 2

3


A-3

1

7 6 5 4 3 2 1 0

Version

(MSB)

…

Message Delimiter

(LSB)

First Octet of IOS Application Message

Second Octet of IOS Application Message

Message Third Octet of IOS Application Message

… Last Octet of IOS Application Message

Figure 2.5.1-1 Delimiting Messages in an IOS Application TCP Byte Stream 2

Version This field contains the version number and specifies the remainder of the 3

message delimiter format. This field is set to the range of values as follows: 4

Binary Values Meaning 0000 0000 Reserved 0000 0001 Version 1

All other values Reserved

Message Delimiter: The contents of this field are specified by the version of the message delimitation 5

header. For version ‘0000 0001’, the delimiter format is coded as follows: 6

7 6 5 4 3 2 1 0 Octet

(MSB) Length 1

2

3

(LSB) 4

Length: This field contains the number of octets in the IOS Application message follow-7

ing this field as a binary number. 8

9

... 10

11


A-4

2.6.1.1 1x SDB/HRPD DOS Indicator 1

If the packet is tagged by the PDSN as being suitable for 1x SDB or HRPD Data Over Signaling (DOS) 2

transmission, it is identified by an attribute defined as follows: 3

0 1 2 3 4 5 6 7 Octet

E = [0,1] Type = ‘000 0001’ 1

Length = 02H 2

SDI/DOS = ‘1’

Reserved 3

Reserved 4

Type ‘000 0001’ – Short Data Indication 4

Length 02H 5

SDI/DOS 0 – Reserved 6

1 – packet suitable for 1x SDB or HRPD DOS transmission 7

... 8

2.6.1.3 IP Flow Discriminator 9

If the BS has specified use of IP flow discrimination for a given forward A8 connection, the PCF shall 10

include this attribute in all GRE frames for the specified forward A8 connection. If the PCF has specified 11

use of IP flow discrimination for a given forward A10 connection, the PDSN shall include this attribute in 12

all GRE frames for the specified forward A10 connection. 13

14

0 1 2 3 4 5 6 7 Octet

Flow ID 2

Type: 3 – IP Flow Discriminator 15

Length: 01H 16

Value: The one octet of the Value field is coded as follows. 17

Flow ID: This field contains the flow ID. Refer to [8] for detailed information. 18

19

2.6.1.4 Segmentation Indication: 20

If the packet is segmented, sequence numbers shall be required and the overall User Traffic length is 21

identified by an attribute defined as follows: 22

0 1 2 3 4 5 6 7 Octet

E = [0,1] Type = ‘000 0100’ 1

Length = 02H 2

Value = ‘00’-‘10’ Reserved 3

Reserved 4

Type: 04H - Segmentation Indication 23


A-5

Length: 02H 1

Value: The segmentation indication Value is coded as shown below. 2

‘00’ - Packet started 3

‘01’ - Packet continued 4

‘10’ - Packet ended 5

Other - reserved 6

7

... 8

2.6.2 Relationship of GRE tunnel to Quality of Service 9

The user’s IP traffic associated with the packet data service is tunneled across the RAN using GRE/IP 10

transport. The inner IP packet is the packet transmitted between the user (e.g. Mobile Station (MS)) and 11

its correspondent node (e.g. Internet server). The outer IP packet transports (or tunnels) a portion of the 12

inner packet between the RAN components (i.e. BS, PCF, PDSN). Thus, the inner and outer packets may 13

have inner and outer DSCP values whose usage is described as follows. 14

If the RAN supports QoS on the A8/A9 and A10/A11 interfaces, the RAN shall have a local RAN 15

transport network QoS policy which that indicates which outer DSCP values can be used by the PDSN, 16

PCF and BS for traffic. These DSCP values shall be made available to the PDSN (e.g. via OAM&P 17

functions) to enable QoS for the RAN transport network. 18

When QoS is required for GRE tunnels across the A8/A10 transport network, the IOS shall implement 19

Diffserv as described in section 2.4.4 to support intra-network QoS requirements. In addition, the BS, 20

PCF and PDSN shall follow specific mapping rules as follows: 21

22

1. The PDSN shall mark packets in the GRE tunnel packets (outer DSCP value) in the forward direction 23

according to the network operator’s choice from the following options. 24

the policy in use by the RAN transport network (refer to section 2.4.4) connecting the PDSN to the PCF. 25

This policy is local and specifies the DSCP values for use on each GRE tunnel (i.e. service instance) 26

instantiated on the PDSN. 27

a. Mark packets autonomously. If the RAN supports IP flow based (subscriber) QoS functionality, 28

then the PDSN may take into account the subscriber QoS profile and the granted QoS for the IP 29

flow when marking packets. 30

b. Use the inner DSCP value to determine the outer DSCP value. 31

c. Set the DSCP value of each forward GRE packet to the value specified by the PCF for that IP 32

flow. For this option to apply, the PCF shall inform the PDSN of the DSCP value that the PDSN 33

shall use to mark forward GRE packets. If GRE sequencing is used, then the PCF shall specify 34

the same DSCP value for all IP flows in the same A10 connection. 35

In all cases the markings selected by the PCF and PDSN shall comply with the local transport QoS 36

policy in use by the RAN transport network (refer to section 2.4.4) connecting the PDSN to the PCF 37

38

2. The PCF and BS shall mark the GRE tunnel packets (outer DSCP value) according to the network 39

operator’s choice from the following options. 40


A-6

The PCF and BS shall use the local QoS policy (refer to section 2.4.4) to set the outer DSCP value of the 1

packets in the GRE tunnels (i.e. service instance). Since the PCF and BS are not required to inspect 2

the encapsulated IP packets to derive the inner DSCP value, the PCF and BS may mark all GRE 3

packets in the same service instance (SI) with the same DSCP value. The PCF and BS may also set 4

the DSCP value of all GRE packets associated with the same user to the same value if this is the local 5

policy. 6

a. Mark packets autonomously. If the RAN supports IP flow based (subscriber) QoS functionality, 7

then the PCF and BS may take into account the subscriber QoS profile and the granted QoS for 8

the IP flow when marking packets. 9

b. In the forward direction at the PCF, set the DSCP value of each forward GRE packet to the value 10

used on the corresponding GRE packets on the A10 interface. 11

c. In the forward direction at the PCF, set the DSCP value of each forward GRE packet to the value 12

specified by the BS for that IP flow. For this option to apply, the BS shall inform the PCF of the 13

DSCP value that the PCF shall use to mark forward GRE packets. If GRE sequencing is used, 14

then the BS shall specify the same DSCP value for all IP flows in the same A8 connection. 15

In all cases the markings selected by the BS and PCF shall comply with the local transport QoS 16

policy in use by the RAN transport network (refer to section 2.4.4) connecting the PCF to the AN 17

18

3. The BS may use the outer DSCP value for RAN QoS functions (e.g. RLP frame prioritization). 19

However, in cdma2000 systems without user quality of service functionality, the BS is not required to 20

differentiate between packets in the same SI or between users. 21

... 22

3.1.3.4.5 SCCP Transfer of DTAP and BSMAP Messages 23

The DTAP and BSMAP messages on the A1 interface are contained in the user data field of the 24

exchanged SCCP frames. Table 3.1.3.4.5-1 below summarizes the use of the User Data Field in SCCP 25

frames. 26

Table 3.1.3.4.5-1 Use of the User Data Field in SCCP Frames 27

SCCP Frame User Data Field (BSMAP/DTAP)

Connection Oriented Protocol Class 2

SCCP Connection Request (CR) Optional SCCP Connection Confirm (CC) Optional SCCP Connection Refused (CREF) Optional SCCP Released (RLSD) Optional SCCP Release Complete (RLC) Not Applicable SCCP Data Transfer 1 (DT1) Mandatory

Connectionless Protocol Class 0

SCCP Unit Data (UDT) Mandatory

For connection oriented transactions, a connection is requested, obtained or refused using the following 28

SCCP messages (protocol class 2): 29

• SCCP Connection Request (CR) 30

• SCCP Connection Confirm (CC) 31

• SCCP Connection Refused (CREF) 32


A-7

• SCCP Released (RLSD) and SCCP Release Complete (RLC) messages are used to break a 1

connection. 2

The use of the User Data Field in SCCP frames in the various establishment and release cases is described 3

in section 3.1.3.4.1, “Connection Establishment” and section 3.1.3.4.2, “Connection Release”. 4

For connection oriented (protocol class 2) transactions, once the signaling connection is confirmed 5

between the MSC and the BS, all A1 interface messages are transported in the SCCP Data Transfer 1 6

(DT1) message until the connection is to be dropped. 7

For Connectionless (protocol class 0) transactions, where there is no SCCP connection, A1 interface 8

messages are transported in the SCCP Unit Data (UDT) message. 9

Table 3.1.3.4.5-2 below indicates which SCCP messages shall be used to transport each of the application 10

messages on the A1 interface. All A1 messages exchanged between an MSC and an HRPD AN are sent in 11

SCCP UDT messages. 12

... 13

3.2.2.6.4 SUA Transfer of DTAP and BSMAP Messages 14

The DTAP and BSMAP messages on the A1p interface are contained in the user data field of the 15

exchanged SUA frames. Table 3.2.2.6.4-1 below summarizes the use of the User Data Field in SUA 16

frames. 17

Table 3.2.2.6.4-1 Use of the User Data Field in SUA Frames 18

SUA Frame User Data Field (BSMAP/DTAP)

Connection Oriented Protocol Class 2

SUA Connection Request (CORE) Optional SUA Connection Acknowledge (COAK) Optional SUA Connection Refused (COREF) Optional SUA Release Request (RELRE) Optional SUA Release Complete (RELCO) Not Applicable SUA Connection Oriented Data Transfer (CODT)

Mandatory

Connectionless Protocol Class 0

SUA Connectionless Data Transfer (CLDT)

Mandatory

For connection oriented transactions, a connection is requested, obtained or refused using the following 19

SUA messages (protocol class 2): 20

• SUA Connection Request (CORE) 21

• SUA Connection Acknowledge (COAK) 22

• SUA Connection Refused (COREF) 23

• SUA Release Request (RELRE) and SUA Release Complete (RELCO) messages are used to break a 24

connection. 25

The use of the User Data Field in SUA frames in the various establishment and release cases is described 26

in section 3.2.2.6.1 and section 3.2.2.6.2. 27

For connection oriented (protocol class 2) transactions, once the signaling connection is confirmed 28

between the MSCe and the BS, all A1p interface messages are transported in the SUA Connection 29

Oriented Data Transfer (CODT) message until the connection is to be dropped. 30


A-8

For Connectionless (protocol class 0) transactions, where there is no SUA connection, A1p interface 1

messages are transported in the SUA Connectionless Data Transfer (CLDT) message. 2

Table 3.2.2.6.4-2 below indicates which SUA messages shall be used to transport each of the application 3

messages on the A1p interface. All A1p messages exchanged between an MSC and an HRPD AN are sent 4

in SUA CLDT messages. 5

... 6

7

3.4 A8 and A9 Interfaces 8

... 9

3.4.3 Use of GRE 10

For general use of GRE, refer to section 2.6. 11

The BS shall set the Key field in the GRE header to the value in the Key field in the A8 Traffic ID 12

element in the A9-Connect-A8 message received from the PCF indicating that the PCF accepts the A8 13

connection. The PCF shall set the Key field in the GRE header to the value in the Key field in the A8 14

Traffic ID element in the A9-Setup-A8 message received from the BS requesting the establishment of the 15

A8 connection. Refer to [16] for details on these A9 messages. 16

On the A8 interface, valid attributes (refer to section 2.6.1) that may be included in the GRE frames when 17

the Protocol Type field is set to "3GPP2 Packet" include: no attributes have been defined (refer to section 18

2.6.1) that may be included in the GRE frames when the Protocol Type field is set to “3GPP2 Packet”. 19

• IP Flow Discriminator 20

• Segmentation Indication 21

22

... 23

3.5 A10 and A11 Interface 24

... 25

3.5.2 Use of GRE 26

For general use of GRE, refer to section 2.6. 27

The PCF shall set the Key field in the GRE header to the value in the Key field in the Session Specific 28

Extension in the A11-Registration Reply message received from the PDSN indicating that the PDSN 29

accepts the A10 connection. The PDSN shall set the Key field in the GRE header to the value in the Key 30

field in the Session Specific Extension in the A11-Registration Request message received from the PCF 31

requesting the establishment of the A10 connection. Refer to [17] for details on these A11 messages. 32

On the A10 interface, valid attributes (refer to section 2.6.1) that may be included in the GRE frames 33

when the Protocol Type field is set to “3GPP2 Packet” include: 34

• Short Data Indicator 35

• Flow Control Indication 36

• IP Flow Discriminator 37

• Segmentation Indication 38


A-9

1

2


A-10

1

(This page intentionally left blank)No text. 2

3

4


B-1

Annex B A1/A1p Interface (BS - MSC) Interface Change Text (Normative) 1

Note: Annex B contains specific A1 messaging text from [14] with all HRPD related changes identified 2


the base document is unchanged. 4

In this section, A1 messages are used by both the A1 and A1p interfaces except where indicated. In this 5

section, BS is used to refer to either a 1x BS or an HRPD AN except where indicated. 6

Note: Refer to section 2 for a cross reference of 1x and HRPD terminology. 7

... 8

9

2.1.4 Paging Request 10

This BSMAP message is sent from the MSC to the BS to initiate a mobile terminated call setup scenario. 11

This message may also be sent for location purposes. 12

2.1.4.1 Successful Operation 13

The MSC determines that an MS in its serving area needs to be paged and initiates the paging procedure. 14

It starts timer T3113, sends the Paging Request message to the BS, and waits for the Complete Layer 3 15

information containing a Paging Response message. 16

In 1x systems, if the BS is not utilizing direct channel assignment, and if the Paging Request message 17

does not contain a Page Indicator IE, or if the Paging Request message contains a Page Indicator IE but 18

the VPI field is set to 0, then when the BS receives the Paging Request message from the MSC, it 19

determines from which cell(s) to broadcast the page request. The page messages are distributed to the 20

appropriate cell(s), which broadcast the page message over their paging channels. Where necessary, the 21

page message is inserted into the computed paging channel slot. If the A2p Bearer Format-Specific 22

Parameters IE is included in the received Paging Request message and contains a list of bearer format 23

parameters, then the BS is to attempt to page the MS using the service option associated with the first 24

bearer format in the list that is supported by the BS. 25

In 1x systems, if the BS and MS support direct channel assignment, and if the Paging Request message 26

does not contain a Page Indicator IE, or if the Paging Request message contains a Page Indicator IE but 27

the VPI field is set to 0, then when the BS receives a Paging Request from the MSC, it may page the MS 28

as described above and simultaneously signal to the MS to prepare to receive an Extended Channel 29

Assignment Message5. The BS then immediately assigns a traffic channel to the MS without waiting for a 30

response to the Page Message. Alternatively, the BS sends an extended channel assignment message to 31

the MS in place of the page message. 32

In 1x systems, if the BS receives a Paging Request message which contains a Page Indicator IE and the 33

VPI field is set to 1, the BS shall prepare to receive a Page Response message from the MS. 34

When paging for HRPD service, the MSC uses SO69 to specify that the MS is required to send a page 35

response prior to the MS tuning to the HRPD system. Otherwise, the MSC uses SO59. 36

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


B-2

2.1.4.2 Failure Operation 1

If a Complete Layer 3 Information message containing a Paging Response message has not been received 2

by the MSC before timer T3113 expires, the MSC may repeat the Paging Request message and restart 3

timer T3113 a configurable number of times. 4

2.1.5 Paging Response 5

This DTAP message is sent from the BS to the MSC, after receipt of a Page Response Message from the 6

MS, in response to a Paging Request message. This message is also sent when the BS utilizes direct 7

channel assignment and the BS begins receiving traffic channel preamble frames from the MS on the 8

reverse traffic channel. The Paging Response and the subsequent MSC response are used for connection 9

establishment. 10


When the MS recognizes a page message containing its identity, it sends a response message to the BS. 12

The BS constructs the Paging Response message using the information received from the MS, 13

encapsulates it in a Complete Layer 3 Information message (refer to section 2.1.1, Complete Layer 3 14

Information), and sends this message to the MSC. The BS may also send this message when the BS 15

utilizes direct channel assignment and the BS begins receiving traffic channel preamble frames from the 16

MS on the reverse traffic channel. The BS starts timer T303 to await reception of the Assignment Request 17

message. The MSC stops timer T3113 upon receiving the Paging Response message. 18

In the Access Probe Handoff scenario, the source BS (the BS on which the first access probe was sent), 19

upon receiving a page response for the same MS and the same call forwarded via an A7 connection from 20

another BS, may choose to send a second Paging Response to the MSC. The MSC shall be able to handle 21

a Paging Response for an MS that is already engaged in a termination attempt by sending a Clear 22

Command message to the BS containing a cause value of “Do not notify MS”. The MSC shall send this 23

message on the underlying signaling connection associated with the second Paging Response. The BS 24

shall be able to handle Clear Command messages from the MSC for duplicated Paging Response 25

messages. 26

The BS may select an available channel based on the MS’s capabilities, and assign the MS to that channel 27

at any time following the receipt of a Page Response Message from the MS. 28


No action is taken at the BS on failure to receive a Paging Response from the MS. 30

If the BS fails to receive an Assignment Request message or Clear Command message in response to the 31

Paging Response message prior to expiration of timer T303, then it may send a Release message to the 32

MS, and clear all associated resources. 33

2.1.5.3 Abnormal Operation 34

If a Paging Response is received by the MSC for a call that is no longer active, the MSC may clear the 35

call. 36

... 37

2.1.17 BS Service Request 38

This BSMAP message is sent from the BS to the MSC to begin a BS initiated call setup. In HRPD 39

systems, this message is used to initiate an HRPD page in the 1x system. It is also used to initiate an 40

ADDS Page or ADDS Deliver procedure to deliver a Short Data Burst (SDB) to an MS. For SDBs, the 41

message is used to transport the data to the MSC for delivery to an MS. 42


B-3


To initiate a call setup, the BS sends a BS Service Request message to the MSC containing the identity of 2

the MS to be paged. In HRPD systems, when the AN/PCF receives data from the PDSN, based on vendor 3

specific procedures (e.g., stored information indicating that the MS/AT has registered with the 1x 4

system), it sends a BS Service Request message to the MSC containing HRPD service option 59, to 5

reactivate the packet data session in the HRPD system. When the 1x BS/PCF receives data from the 6

PDSN destined for an MS with a dormant packet data service instance, the BS may deliver the data as an 7

SDB to the MSC, by sending a BS Service Request message including the application data to be sent to 8

the MS. The 1x BS or HRPD AN starts timer T311 and awaits the reception of the BS Service Response 9

message. The MSC delivers the SDB using the ADDS Page message if the MS is idle, or the ADDS 10

Deliver message if the MS is on a traffic channel, e.g., the user is engaged in a voice call. 11


If a BS Service Response message is not received at the BS before the expiration of timer T311 the BS 13

may resend the BS Service Request message and restart timer T311 a configurable number of times. For 14

SDB delivery to an MS, if the BS times out waiting for a BS Service Response message from the MSC, 15

the BS shall not resend the BS Service Request message, and shall discard the data. 16

2.1.18 BS Service Response 17

This BSMAP message is sent from the MSC to the BS in response to a BS Service Request. 18


The MSC shall send a BS Service Response message to the BS originating the BS Service Request 20

message. Upon receiving a BS Service Response message the BS stops timer T311. 21


None. 23

... 24

2.3.7 Location Updating Request 25

This DTAP message is sent by the BS to the MSC to request an update to the MS’s location area 26

(registration) when the MS moves to a new location or frequency from its previous location or frequency. 27


When the MS’s registration message is received by the BS, it constructs the Location Updating Request 29

message, places it in the Complete Layer 3 Information message (refer to section 2.1.1), sends the 30

message to the MSC, and starts timer T3210. 31

If the MSC had started timer Tordreg, the MSC shall stop this timer upon receipt of the Location Updating 32

Request message. 33


If timer T3210 expires before the receipt of a Location Updating Accept message, a Location Updating 35

Reject message, or a Service Redirection message, the BS may re-send the Location Updating Request 36

message and restart timer T3210 a configurable number of times. 37


B-4

2.3.8 Location Updating Accept 1

This DTAP message is sent from the MSC to the BS to indicate that the Location Updating Request has 2

been successfully processed. 3


The MSC sends a Location Updating Accept message to the BS when a location registration procedure 5

has been successfully completed at the MSC. Upon receipt of this message, the BS stops timer T3210 and 6

may send the appropriate response (a Registration Accepted order) to the MS over the control channel in 7

use. 8


None. 10

... 11

2.3.23 Event Notification 12

This BSMAP message may be sent from the MSC to the HRPD AN to notify that AN about a 1x event 13

(e.g., registration or power down) associated with an MS/AT which had requested Cross Notification 14

Services. 15


When the MSC detects a 1x event (e.g., registration or power down) associated with a MS/AT for which 17

it is supporting Cross Notification Services, the MSC sends this message to the corresponding HRPD AN. 18


None 20

21

... 22

3.1.4 Paging Request 23

This BSMAP message is sent from MSC to BS and contains sufficient information to allow the paging to 24

be transmitted by the correct cells, in the correct format at the correct time. 25

Information Element Section Reference

Element Direction

Type

Message Type 4.2.4 MSC -> BS M Mobile Identity (IMSI/ESN) 4.2.13 MSC -> BS Ma

Tag 4.2.46 MSC -> BS Oh C Cell Identifier List 4.2.18 MSC -> BS Ob C Slot Cycle Index 4.2.14 MSC -> BS Oc,f C

Service Option 4.2.49 MSC -> BS Od,k R

IS-2000 Mobile Capabilities 4.2.53 MSC -> BS Oe,f,i C Protocol Revision 4.2.79 MSC -> BS Og C MS Designated Frequency 4.2.88 MSC -> BS Of, e C A2p Bearer Format-Specific Parameters 4.2.90 MSCe -> BS Oj C


B-5

Page Indicator 4.2.91 MSC -> BS Ol C

1

a. This element shall be set to ESN when the BS and MS are operating in DS-41 mode and IMSI 2

otherwise6. 3

b. This element is only required for a multi-cell BS. More than one cell identifier element may be 4

included to allow the paging request of several cells within a BS on receipt of a single paging request 5

message from the MSC. When absent, paging request at all cells controlled by the BS is assumed. 6

This IE may be ignored by the AN. 7

c. This element is included where slotted paging is performed on the paging channels. It is used by the 8

BS to compute the correct paging channel slot on each paging channel. If this element is absent, then 9

it is assumed that the MS is operating in non-slotted mode. This IE may be ignored by the AN. 10

d. The MSC may decide to page the MS with the preferred service option selected from the subscribed 11

service option record. 12

e. This element is only included when the MSC has previously been given this information by a BS. 13

This IE may be ignored by the HRPD AN. 14

f. These elements shall not be included by the MSC when the BS and MS are operating in DS-41 mode. 15

g. This element contains the MS’s MOB_P_REV of the current band class and shall be included if the 16

value is greater than or equal to 7. 17

h. If this element is present in the message, the value shall be saved at the BS to be included in the 18

corresponding Paging Response message. 19

i. If the MSC does not have the information required to correctly populate a field in this IE, it shall code 20

the field to zero. 21

j. The MSCe may include this element to indicate the preferred service options for paging. The first 22

entry in the bearer format list of this information element should be consistent with the Service 23

Option IE. If it is not consistent, then the Service Option IE shall take precedence. 24

k. The following service options are not permissible when this message is sent from an MSCe: "003E 25

(Wideband Speech Codec), 0004H (Async Data Rate Set 1), 000CH (Async Data Rate Set 2), 0005H 26

(G3 Fax Rate Set 1), 000DH (G3 Fax Rate Set 2), 0025H (ISDN Interworking Service), 0039H (32 27

kbps Circuit Switched Video Conferencing) and 003AH (64 kbps Circuit Switched Video 28

Conferencing). When sent to an HRPD AN, the only valid service options are: 8000H (13K speech), 29

0011H (13K high rate voice service), 0003H (EVRC), 003E (Wideband Speech Codec), 003BH 30

(HRPD Packet Data; page response not required), and 0045H (HRPD Packet Data; page response 31

required). When sent to a 1x BS to page for HRPD service, the valid service options are: 003BH 32

(HRPD Packet Data; page response not required), and 0045H (HRPD Packet Data; page response 33

required). 34

l. This IE is included to provide paging details to the BS (e.g., Virtual Page Indicator field identifies 35

whether the 1x BS shall be prepared to receive a Page Response Message from the MS/AT). This IE 36

may be ignored by the HRPD AN. 37

38

The following table shows the bitmap layout for the Paging Request message. 39

6 In DS-41 mode, ESN is used because an IMSI may not be available, e.g., emergency calls to an MS without a subscriber

identity module.


B-6

3.1.4 Paging Request

7 6 5 4 3 2 1 0 Octet

⇒⇒⇒⇒ BSMAP Header: Message Discrimination = [00H] 1

Length Indicator (LI) = <variable> 2

Message Type = [52H] 1

⇒⇒⇒⇒ Mobile Identity (IMSI/ESN): A1 Element Identifier = [0DH] 1

Length = [05H-08H] (10-15 digits) 2


Type of Identity = [101 (ESN),110 (IMSI)]

3

IF(Type of Identity = 101), Identity {1:

(MSB) ESN = <any value> 4

5

6

(LSB) 7

} OR IF (Type of Identity = 110), Identity {1:


… …

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

= [1111] (if even number of digits), Identity Digit N+3 = [0H-9H] (BCD) (if odd

number of digits)

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

} Type of Identity

⇒⇒⇒⇒ Tag: A1 Element Identifier = [33H] 1

(MSB) Tag Value = <any value> 2

3

4

(LSB) 5

⇒⇒⇒⇒ Cell Identifier List: A1 Element Identifier = [1AH] 1

Length = <variable> 2

Cell Identification Discriminator = [02H,05H] 3

IF (Discriminator = 02H), Cell Identification {1+:

(MSB) Cell = [001H-FFFH] j

Sector = [0H-FH] (0H = Omni) (LSB) j+1

} OR IF (Discriminator = 05H), Cell Identification {1+:

(MSB) LAC = [0001H-FFFFH] j

(LSB) j+1

} Cell Identification

⇒⇒⇒⇒ Slot Cycle Index: A1 Element Identifier = [35H] 1

Reserved = [00000] Slot Cycle Index = [000-111] 2

⇒⇒⇒⇒ Service Option: A1 Element Identifier = [03H] 1


B-7


7 6 5 4 3 2 1 0 Octet

(MSB) Service Option 2

= [8000H (13K speech), 0011H (13K high rate voice service), 0003H (EVRC), 003EH (Wideband Speech Codec), 801FH (13K Markov), 0009H (13K Loopback), 0004H (Async Data Rate Set 1), 000CH (Async Data Rate Set 2), 0005H (G3 Fax Rate Set 1), 000DH (G3 Fax Rate Set 2), 0006H (SMS Rate Set 1), 000EH (SMS Rate Set 2), 0021H (3G High Speed Packet Data), 0012H (OTAPA Rate Set 1), 0013H (OTAPA Rate Set 2), 0025H (ISDN Interworking Service), 0020H (TDSO), 0036H (IS-2000 Markov), 0037H (IS-2000 Loopback), 0023H (PDS Rate Set 1), 0024H (PDS Rate Set 2), 0038H (SMV), 0039H (32 kbps Circuit Switched Video Conferencing), 003AH (64 kbps Circuit Switched Video Conferencing) 003BH (HRPD Packet Data; page response not required ), 0045H (HRPD Packet Data; page response required)] for 1x systems = [8000H (13K speech), 0011H (13K high rate voice service), 0003H (EVRC), 003EH (Wideband Speech Codec), 003BH (HRPD Packet Data; page response not required), 0045H (HRPD Packet Data; page response required)] for HRPD systems]

(LSB) 3

⇒⇒⇒⇒ IS-2000 Mobile Capabilities: A1 Element Identifier = [11H] 1


REV_ PDCH

Supported = [0, 1]

FOR_ PDCH

Supported =[0,1]

ERAM Supported

= [0,1]

DCCH Supported

= [0,1]

FCH Supported

= [0,1]

OTD Supporte

d = [0,1]

Enhanced RC CFG

Supported= [0,1]

QPCH Supported

= [0,1]

3


B-8


7 6 5 4 3 2 1 0 Octet

FCH Information: Bit-Exact Length – Octet Count = [00H to FFH]

4

Reserved = [0]

Geo Location Type = <any value> (Ignored)

Geo Location

Included = <any

value> (Ignored)

FCH Information: Bit-Exact Length – Fill Bits

= [000 to 111]

5

(MSB) 6

FCH Information Content = <any value>

…

Seventh Fill Bit – if needed = [0 (if

used as a fill bit)]

Sixth Fill Bit

– if needed = [0 (if used as

a fill bit)]

Fifth Fill Bit – if needed = [0 (if


Fourth Fill Bit – if needed= [0 (if


Third Fill Bit –

if needed = [0 (if


Second Fill Bit – if needed= [0 (if


First Fill Bit – if needed = [0 (if


k

DCCH Information: Bit-Exact Length – Octet Count = [00H to FFH]

k+1

Reserved = [0000 0]

DCCH Information: Bit-Exact Length – Fill Bits

= [000 to 111]

k+2

(MSB) k+3

DCCH Information Content = <any value>

…



Sixth Fill Bit


a fill bit)]



Fourth Fill Bit – if needed = [0 (if


Third Fill Bit –

if needed = [0 (if






m

FOR_PDCH Information: Bit-Exact Length – Octet Count = [00H-FFH]

m+1

Reserved = [0000 0]

FOR_PDCH Information: Bit-Exact Length – Fill Bits

= [000 to 111]

m+2

( MSB) m+3

FOR_PDCH Information Content = <any value>

…


B-9


7 6 5 4 3 2 1 0 Octet



Sixth Fill Bit


a fill bit)]





Third Fill Bit

– if needed= [0 (if used as

a fill bit)]



First Fill Bit


a fill bit)]

n

REV_PDCH Information: Bit-Exact Length – Octet Count = [00H-FFH]

n+1

Reserved = [0000 0]

REV_PDCH Information: Bit-Exact Length – Fill Bits

= [000 to 111]

n+2

( MSB) n+3

REV_PDCH Information Content = <any value>

…



Sixth Fill Bit


a fill bit)]





Third Fill Bit – if needed = [0 (if


Second Fill Bit

– if needed= [0 (if used as

a fill bit)]



p

⇒⇒⇒⇒ Protocol Revision: A1 Element Identifier = [3BH] 1

Length = [01H] 2

MOB_P_REV = [07H-FFH] 3

⇒⇒⇒⇒ MS Designated Frequency: A1 Element Identifier = [73H] 1

Length = [05H] 2

Band Class = [00000 – 11111] CDMA channel (high part) = [000 – 111] 3

CDMA channel (low part) = [00H – FFH] 4

⇒⇒⇒⇒ A2p Bearer Format-Specific Parameters: A1p Element Identifier = [46H] 1


Number of Bearer Formats = <variable> Bearer IP Address Type= [00 = IPv4]

3

Bearer Format Parameters {1+:

Bearer Format Length = <variable> m

Ext = [0,1]

Bearer Format Tag Type = [001-100]

Bearer Format ID = [0000 – 0111] m+1


B-10


7 6 5 4 3 2 1 0 Octet

RTP Payload Type = [00H = (PCMU), 08H = (PCMA), 0CH = (13K Vocoder), 60H - 7FH (dynamically assigned = EVRC), 60H - 7FH (dynamically assigned = EVRC0), 60H - 7FH (dynamically assigned = SMV), 60H - 7FH (dynamically assigned = SMV0), 60H - 7FH (dynamically assigned = telephone-event)]

Bearer Addr

Flag= [0, 1]

m+2

(MSB) Bearer IP Address = <any value> i

… …

(LSB) j

(MSB) Bearer UDP Port= <any value> j+1

(LSB) j+2

Extension Length = [0001] Extension ID = [0000] k

Extension Parameters = <any value> k+1

} Bearer Format Parameters ⇒⇒⇒⇒ Page Indicator: A1 Element Identifier = [7DH] 1

Length = [01H] 2

Reserved = [0000 000] VPI = [0,1]

3

1

3.1.17 BS Service Request 2

This BSMAP message is sent from the BS to the MSC to request a BS initiated mobile terminated call 3

setup. This message is also used for mobile terminated SDB delivery. This message may also be used to 4

notify the MSC that the AN/PCF has received data from the PDSN for a specific MS/AT. 5


Element Direction

Type

Message Type 4.2.4 BS -> MSC M Mobile Identity (IMSI) 4.2.13 BS -> MSC M Mobile Identity (ESN) 4.2.13 BS -> MSC Oa C Service Option 4.2.49 BS -> MSC Ob R Tag 4.2.46 BS -> MSC Oc C ADDS User Part 4.2.50 BS -> MSC Od C Service Reference Identifier (SR_ID) 4.2.86 BS -> MSC Oe C Mobile Identity (MEID) 4.2.13 BS -> MSC Of C

6

a. This IE is included if the necessary information is available at the BS. This IE is included if the ESN 7

is available at the BS. ESN containing a pseudo ESN is not required to be sent if the MEID is sent. 8


B-11

b. This element indicates the service option requested by the BS. 1

c. If this element is present in the message, the value shall be saved at the MSC to be included in a BS 2

Service Response message. 3

d. This element is included if this message is used for mobile terminated SDB delivery. The Application 4

Data Message field is included and contains the SDB received from the PCF. For HRPD, this element 5

may be included if containing a data burst of type 7. 6

e. This element is passed to the MSC when the network reactivates a packet data service instance and 7

the SR_ID is available at the BS. The element identifies the reactivated service instance. 8

f. This IE is included if the MEID is available at the BS. 9

The following table shows the bitmap layout for the BS Service Request message. 10

3.1.17 BS Service Request

7 6 5 4 3 2 1 0 Octet



⇒⇒⇒⇒ Message Type = [09H] 1

⇒⇒⇒⇒ Mobile Identity (IMSI): A1 Element Identifier = [0DH] 1



Type of Identity = [110] (IMSI)

3


… …



number of digits)


⇒⇒⇒⇒ Mobile Identity (ESN): A1 Element Identifier = [0DH] 1

Length = [05H] 2

Identity Digit 1 = [0000] Odd/even Indicator

= [0]

Type of Identity = [101] (ESN)

3


5

6

(LSB) 7


(MSB) Service Option = [00 21H (3G High Speed Packet Data] for 1x systems = [00 3BH (HRPD Packet Data)] for HRPD systems)]

2

(LSB) 3




B-12

3.1.17 BS Service Request

7 6 5 4 3 2 1 0 Octet

3

4

(LSB) 5

⇒⇒⇒⇒ ADDS User Part: A1 Element Identifier = [3DH] 1


Reserved Data Burst Type = [000110] (SDB)

[000111]

3

(MSB) Application Data Message = <any value> 4

… …

(LSB) n

⇒⇒⇒⇒ Service Reference Identifier (SR_ID): A1 Element Identifier = [71H] 1

Length = [01H] 2

SR_ID = [00H-1FH] 3

Reserved = [0000 0] SR_ID = [001 – 110]

3

⇒⇒⇒⇒ Mobile Identity (MEID): A17 Element Identifier = [0DH] 1

Length = [08H] 2

MEID Hex Digit 1 = [0H-FH] Odd/Even Indicator

= ‘0’

Type of Identity = [001] (MEID)

3

MEID Hex Digit 3 = [0H-FH] MEID Hex Digit 2 = [0H-FH] 4






Fill = [FH] MEID Hex Digit 14 = [0H-FH] 10

... 1

2

3.3.7 Location Updating Request 3

This DTAP message is sent by the BS to the MSC to request an update to the MS’s location area 4

(registration) when the MS moves to a new location from its previous location. 5


Element Direction

Type

Protocol Discriminator 4.2.31 BS -> MSC Mi Reserved Octet 4.2.32 BS -> MSC M Message Type 4.2.4 BS -> MSC M


B-13


Element Direction

Type

Mobile Identity (IMSI) 4.2.13 BS -> MSC Ma, i, m

Classmark Information Type 2 4.2.12 BS -> MSC Ob, i, k R Registration Type 4.2.45 BS -> MSC Oi R Mobile Identity (ESN) 4.2.13 BS -> MSC Oc C Slot Cycle Index 4.2.14 BS -> MSC Od, l C Authentication Response Parameter (AUTHR) 4.2.36 BS -> MSC Oe C Authentication Confirmation Parameter (RANDC) 4.2.33 BS -> MSC Of C Authentication Parameter COUNT 4.2.37 BS -> MSC Oo C Authentication Challenge Parameter (RAND) 4.2.35 BS -> MSC Og C Authentication Event 4.2.61 BS -> MSC Oh C User Zone ID 4.2.26 BS -> MSC Oo C

IS-2000 Mobile Capabilities 4.2.53 BS -> MSC Oj, l, p C Return Cause 4.2.83 BS -> MSC On C MS Designated Frequency 4.2.88 BS -> MSC Ol, qc C Mobile Identity (MEID) 4.2.13 BS -> MSC Oc C

1

a. This element contains an IMSI. 2

b. If an MS is capable of supporting multiple band classes, and this information is available at the BS, it 3

shall be indicated in the Band Class Entry field as shown in section 4.2.12. 4

c. This IE is present if the information is received from the MS. 5

d. The slot cycle index is included when provided by the MS. 6

e. This element contains the authentication response signature (AUTHR) received from an 7

authentication capable MS when broadcast authentication is active. 8

f. This element contains the RANDC received from the MS. RANDC shall be included whenever it is 9

received from the MS and authentication is enabled. 10

g. This element is included when broadcast authentication is performed, and contains the random 11

number (RAND) value used when the BS is responsible for RAND assignment and can correlate this 12

parameter with the RAND used by the MS in its authentication computation. 13

h. This element is present when an authentication enabled BS does not receive the authentication 14

parameters (AUTHR, RANDC and COUNT) from the MS, or when a RAND/RANDC mismatch has 15

occurred. 16

i. If any of these elements are not correctly present, call failure handling may be initiated by the MSC. 17

j. This element is only included when the MS operates at revision level 6 or greater as defined by 18

[1]~[6]. 19

k. When the BS is operating in DS-41 mode, only the following fields in the Classmark Type 2 IE shall 20

be considered valid by the MSC: MOB_P_REV, NAR_AN_CAP, Mobile Term, PSI (PACA 21

Supported Indicator), SCM Length, Count of Band Class Entries, Band Class Entry Length, Band 22

Class n, Band Class n Air Interfaces Supported, Band Class n MOB_P_REV. 23

l. These elements shall not be included by the BS when the BS and MS are operating in DS-41 mode. 24

m. Because this IE is sent as a mandatory IE in a DTAP message, the IE identifier is not included. 25


B-14

n. This element is included if the MS re-sends the Registration Message with Return Cause to the BS 1

because it failed to be redirected to the desired system. This IE shall not be included in HRPD 2

messages. 3

o. This IE is included if the necessary information was received from the MS. 4

p. If the BS does not have the information required to correctly populate a field in this IE, it shall code 5


q. This IE shall not be included in HRPD messages. 7

... 8

9

3.3.8 Location Updating Accept 10

No changes from A.S0014-C. 11

... 12

3.3.23 Event Notification 13

This BSMAP message is sent from the MSC to the AN to notify the HRPD AN about a 1x event 14

associated with an AT which had requested Cross Notification Services. 15


Element Direction

Type

Message Type 4.2.4 MSC -> AN M

Mobile Identity (IMSI) 4.2.13 MSC -> AN M

Event 4.2.92 MSC -> AN M

The following table shows the bitmap layout for the Event Notification message. 16

3.3.23 Event Notification

7 6 5 4 3 2 1 0 Octet



⇒⇒⇒⇒ Message Type = [xxH] 1





3


… …



number of digits)


⇒⇒⇒⇒ Event: A1 Element Identifier = [7EH] 1


B-15

3.3.23 Event Notification

7 6 5 4 3 2 1 0 Octet

Length = [05H] 2

Event Identifier = [ 01H (1x Registration) 02H (1x Power Down]

3

... 1

2

3.6.1 ADDS Page 3

This BSMAP message is sent from the MSC to the BS to request delivery of an application data message 4

on the paging channel. 5


Element Direction

Type

Message Type 4.2.4 MSC -> BS M Mobile Identity (IMSI/Broadcast Address) 4.2.13 MSC -> BS Ma

ADDS User Part 4.2.50 MSC -> BS Mb

Tag 4.2.46 MSC -> BS Oc C Cell Identifier List 4.2.18 MSC -> BS Od C Slot Cycle Index 4.2.14 MSC -> BS Oe,f C IS-2000 Mobile Capabilities 4.2.53 MSC -> BS Of, h C Protocol Revision 4.2.79 MSC -> BS Og C MS Designated Frequency 4.2.88 MSC -> BS Of, i C

6

a. When sent to a 1x BS, tThis element contains an IMSI or Broadcast Address; when sent to an HRPD 7

AN, this element contains an IMSI. 8

b. This element contains the application data information to be sent to the mobile user, encoded using 9

the syntax appropriate for the current radio channel and service type. When this message is used to 10

deliver an SDB to the MS, the Application Data Message field is included and contains the SDB. 11

c. If this element is present in this message, the value shall be saved at the BS to be included if an 12

ADDS Page Ack message is sent in response to this message. 13

d. The cell identifiers indicate the cells and location areas in which the BS is to attempt delivery of the 14

message. When the Cell Identifier IE is absent, the BS shall attempt delivery in all cells controlled by 15

the BS. This IE may be ignored by the AN. 16

e. This element is included when slotted paging is performed on cdma2000 paging channels. It is used 17

by the BS to compute the correct paging channel slot on each paging channel. In cdma2000 systems, 18

if this element is absent, then it is assumed that the MS is operating in non-slotted mode. Note: For 19

SMS Broadcast, the presence or absence of this element does not indicate the slotted/non-slotted 20

operating mode of the MS. This IE may be ignored by the AN. 21

f. This element shall not be included when the BS and MS are operating in DS-41 mode. 22

g. This element contains the MS’s MOB_P_REV of the current band class and shall be included if the 23

value is greater than or equal to 7. 24


B-16

h. If the MSC does not have the information required to correctly populate a field in this IE, it shall code 1

the field to zero. This IE may be ignored by the AN. 2

i. This element is included when the MSC has the information available. 3

... 4

3.6.2 ADDS Page Ack 5

This BSMAP message is sent from the BS to the MSC to indicate that the BS received a Layer 2 Ack 6

from the MS indicating that the point-to-point application data message was successfully delivered, or 7

that the BS received the ADDS Page message to send an SMS broadcast message, or that the ADDS 8

message was too long for delivery on the Paging channel, or that an internal BS failure has occurred with 9

respect to the ability to complete an ADDS Page activity. 10


Element Direction

Type

Message Type 4.2.4 BS -> MSC M Mobile Identity (IMSI/Broadcast Address) 4.2.13 BS -> MSC Ma

Tag 4.2.46 BS -> MSC Oe R Mobile Identity (ESN) 4.2.13 BS -> MSC Ob C Cause 4.2.16 BS -> MSC Oc C Cell Identifier 4.2.17 BS -> MSC Od C Mobile Identity (MEID) 4.2.13 BS -> MSC Of C

11

a. When sent to a 1x BS, tThis element contains an IMSI or Broadcast Address; when sent to an HRPD 12

AN, this element contains an IMSI. 13

b. This IE is included if the ESN is available at the BS. ESN containing a pseudo ESN is not required to 14

be sent if the MEID is sent. This IE shall not be included in HRPD messages. 15

c. This element is used to indicate an error situation. In particular, this element can be used to carry 16

information to the MSC that the ADDS User Part element contained in the ADDS Page message is 17

too long to be carried on the paging channel. 18

d. This element identifies the cell where the air interface acknowledgement was received corresponding 19

to the paging channel message sent as a result of an ADDS Page message. This element is not 20

included for SMS Broadcast. This IE shall not be included in HRPD messages. 21

e. This IE contains the same value received in the ADDS Page message. 22

f. This IE is included if the MEID is available at the BS. 23

... 24

25

3.6.3 ADDS Transfer 26

This BSMAP message is sent from the BS to the MSC whenever an application data message is received 27

from the MS on the access channel. It is also sent from the BS to the MSC to transfer authentication 28

parameters when an MS originates a Short Data Burst, requests CCPD mode, or requests alternate 29

dormant mode handoff from the network. 30


B-17


Element Direction

Type

Message Type 4.2.4 BS -> MSC M Mobile Identity (IMSI) 4.2.13 BS -> MSC M ADDS User Part 4.2.50 BS -> MSC Ma

Mobile Identity (ESN) 4.2.13 BS -> MSC Ob C Authentication Response Parameter AUTHR 4.2.36 BS -> MSC Oc C Authentication Confirmation Parameter RANDC 4.2.33 BS -> MSC Od C Authentication Parameter COUNT 4.2.37 BS -> MSC Oe C Authentication Challenge Parameter RAND 4.2.35 BS -> MSC Of C Authentication Event 4.2.61 BS -> MSC Og C Cell Identifier 4.2.17 BS -> MSC Oh R CDMA Serving One Way Delay 4.2.57 BS -> MSC Oi C Authentication Data 4.2.62 BS -> MSC Oj C Tag 4.2.46 BS -> MSC Ok C Classmark Information Type 2 4.2.12 BS -> MSC Ol, m,q C Slot Cycle Index 4.2.14 BS -> MSC Ol,n,o C Service Option 4.2.49 BS -> MSC Ol,q C User Zone ID 4.2.26 BS -> MSC Ol C IS-2000 Mobile Capabilities 4.2.53 BS -> MSC Ol,o,p,r C Mobile Identity (MEID) 4.2.13 BS -> MSC Os C

1

a. This element contains the application data information that was received from the MS. When this 2

message is used to transfer authentication parameters to the MSC after the BS has received a SDB or 3

a request for CCPD mode from the MS, the Data Burst Type field is set to ‘SDB (000110)’ and the 4

Application Data Message field is not included. When this message is used to transfer authentication 5

parameters to the MSC after the BS has received a request for alternate dormant mode handoff from 6

the MS, the Data Burst Type field is set to ‘Asynchronous Data Services (000001)’ and the 7

Application Data Message field is not included. 8

b. This IE is included if the ESN is available at the BS. ESN containing a pseudo ESN is not required to 9

be sent if the MEID is sent. This IE shall not be included in HRPD messages. 10

c. This element is included when broadcast authentication is performed and contains the Authentication 11

Response Parameter, AUTHR, as computed by the MS. 12

d. This element contains the RANDC received from the MS. RANDC shall be included whenever it is 13

received from the MS and authentication is enabled. 14

e. This element is included when broadcast authentication is performed and contains the MS’s call 15

history count for authentication operations. 16

f. This element is included when broadcast authentication is performed and contains the random number 17

(RAND) value used when the BS is responsible for RAND assignment and can correlate this 18

parameter with the RAND used by the MS in its authentication computation. 19

g. This element is present when an authentication enabled BS does not receive the authentication 20

parameters (AUTHR, RANDC and COUNT) from the MS, or when a RAND/RANDC mismatch has 21

occurred. 22


B-18

h. This element identifies the cell where the application data (e.g., SMS-MO) was received from the 1

MS. Discriminator type ‘0000 0010’ (Cell ID) may be used in the ADDS Transfer message. For more 2

information, refer to section 4.2.17. In HRPD messages the cell identifier discriminator type shall be 3

set to a valid value and the cell id may be set to any value. 4

i. This element is included if the data burst type is set to ‘05H (PDS)’, if applicable to the geo-location 5

technology, and if this technology is supported at the base station. 6

j. This element is included if the BS determines that authentication should be applied. 7

k. These elements are required when the ADDS user part element data burst type field is set to SDB for 8

Short Data Burst or Asynchronous Data Services for dormant handoff, and shall be returned in the 9

ADDS Transfer Ack message. This IE shall not be included in HRPD messages. 10

l. This element is included if the message is triggered by an Origination Message from the MS. This IE 11

shall not be included in HRPD messages. 12

m. When the BS is operating in DS-41 mode, only the following fields in the Classmark Type 2 IE shall 13

be considered valid by the MSC: MOB_P_REV, NAR_AN_CAP, Mobile Term, PSI (PACA 14

Supported Indicator), SCM Length, Count of Band Class Entries, Band Class Entry Length, Band 15

Class n, Band Class n Air Interfaces Supported, Band Class n MS Protocol Level. 16

n. This element applies only to MSs operating in slotted mode (discontinuous reception). It contains an 17

index value used in paging channel slot computation. The Slot Cycle Index shall be stored by the 18

MSC, and returned to the BS for call termination to the MS to ensure that the Paging Message is 19

broadcast in the paging channel slots monitored by the MS. 20

o. These elements shall not be included by the BS when the BS and MS are operating in DS-41 mode. 21

p. This element is only included when the MS operates at revision level 6 or greater as defined by 22

[1]~[6]. 23

q. If any of these elements are not correctly present in case of dormant handoff, failure handling may be 24

initiated by the MSC. 25

r. If the BS does not have the information required to correctly populate a field in this IE, it shall code 26


s. This IE is included if the MEID is available at the BS. 28

... 29

3.6.5 ADDS Deliver 30

This DTAP message is sent from the MSC to the BS to request delivery of an application data message to 31

an MS on a traffic channel. This message can also be sent from the BS to the MSC to deliver an 32

application data message received on the traffic channel. 33


Element Direction

Type

Protocol Discriminator 4.2.31 MSC <-> BS M Reserved Octet 4.2.32 MSC <-> BS M Message Type 4.2.4 MSC <-> BS M ADDS User Part 4.2.50 MSC <-> BS Ma,d

Tag 4.2.46 MSC -> BS Ob C CDMA Serving One Way Delay 4.2.57 BS->MSC Oc C

a. This element contains the application data information that was received from or is to be delivered to 34

the MS. This element may contain an SDB in the MSC-to-BS direction only. When this message is 35


B-19

used to deliver an SDB to the MS, the Application Data Message field is included and contains the 1

SDB. This element may also be included in a 1x system for notifying an MS/AT about data awaiting 2

delivery on the HRPD system. 3

b. If this element is used in this message, it shall be returned to the MSC in the ADDS Deliver Ack. 4

c. This element is included if the Data Burst Type field of the ADDS User Part IE is set to ‘000101 5

(PDS)’, if applicable to the geo-location technology, and if this technology is supported at the base 6

station. 7

d. Because this IE is sent as a mandatory IE in a DTAP message, the IE identifier is not included. 8

The following table shows the bitmap layout for the ADDS Deliver message. 9

3.6.5 ADDS Deliver

7 6 5 4 3 2 1 0 Octet

⇒⇒⇒⇒ DTAP Header: Message Discrimination = [01H] 1

Data Link Connection Identifier (DLCI) = [00H] 2


Reserved = [0000] ⇒⇒⇒⇒ Protocol Discriminator = [0011] 1

⇒⇒⇒⇒ Reserved Octet = [00H] 1


⇒⇒⇒⇒ ADDS User Part: Length = <variable> 1

Reserved = [00] Data Burst Type = [[000011] (SMS), [000100] (OTASP), [000101] (PDS), [000110] (SDB), [000111]]

2


… …

(LSB) n



3

4

(LSB) 5

⇒⇒⇒⇒ CDMA Serving One Way Delay: A1 Element Identifier = [0CH] 1

Length = [08H, 0BH] 2

Cell Identification Discriminator = [02H,07H] 3

IF (Discriminator = 02H), Cell Identification {1:

(MSB) Cell = [001H-FFFH] j


} OR IF (Discriminator = 07H), Cell Identification {1:

(MSB) MSCID = <any value> j

j+1


B-20

3.6.5 ADDS Deliver

7 6 5 4 3 2 1 0 Octet

(LSB) j+2

(MSB) Cell = [001H-FFFH] j+3


} Cell Identification

(MSB) CDMA Serving One Way Delay = [0000H-FFFFH] k

(LSB) k+1

Reserved = [0000 00] Resolution = [00, 01, 10]

k+2

(MSB) CDMA Serving One Way Delay Time Stamp = [00 00H – FF FFH] k+3

(LSB) k+4

... 1

4.1.2 Information Element Identifiers 2

The following table contains a list of all IEs that make up the messages defined in section 3.0. The table is 3

sorted by the IE Identifier (IEI) coding which distinguishes one IE from another. The table also includes a 4

reference to the section where the element coding can be found. 5

A listing of IEs, sorted by name, is included in Table 4.1.5-1, which also specifies the messages in which 6

each IE is used. 7

Table 4.1.2-1 A1 Information Element Identifiers Sorted by Identifier Value

Element Name IEI (Hex)

Reference

…... …... …... Page Indicator 7D 4.2.91 Event 7E 4.2.92 …... …... …...

... 8

4.1.5 Cross Reference of Information Elements With Messages 9

The following table provides a cross reference between the elements defined in this specification and the 10

messages defined herein. 11

4.1.5 Cross Reference of Information Elements With Messages4.1.5 Cross Reference of Information Elements With Messages4.1.5 Cross Reference of Information Elements With

Messages4.1.5 Cross Reference of Information Elements With Messages

Information Element Reference IEI Used in These Messages Reference

A2p Bearer Session-Level Parameters

4.2.89 45H Additional Service Request 3.1.20

Assignment Complete 3.1.8

Assignment Request 3.1.7


B-21




Bearer Update Request 3.1.21 Bearer Update Required 3.1.23

Bearer Update Response 3.1.22

CM Service Request 3.1.2

Handoff Request 3.4.2

Handoff Request Acknowledge

3.4.3

Paging Response 3.1.5

A2p Bearer Format-Specific Parameters

4.2.90 46H Additional Service Notification

3.1.19

Additional Service Request 3.1.20



Bearer Update Request 3.1.21

Bearer Update Required 3.1.23





3.4.3

Paging Request 3.1.4


Access Network Identifiers 4.2.70 20H Handoff Request 3.4.2

Handoff Required 3.4.1

ADDS User Part 4.2.50 3DH ADDS Deliver 3.6.5

ADDS Page 3.6.1

ADDS Transfer 3.6.3

BS Service Request 3.1.17

AMPS Hard Handoff Parameters 4.2.75 25H Handoff Command 3.4.4

Anchor PDSN Address 4.2.78 30H Handoff Request 3.4.2


Anchor P-P Address 4.2.80 7CH Handoff Request 3.4.2


Authentication Challenge Parameter 4.2.35 41H ADDS Transfer 3.6.3

(RAND/RANDU/RANDBS/RANDSSD)

Authentication Request 3.3.1

Base Station Challenge 3.3.5


Location Updating Request 3.3.7


B-22




PACA Update 3.2.7


SSD Update Request 3.3.3

Authentication Confirmation Parameter

4.2.33 28H ADDS Transfer 3.6.3

(RANDC) CM Service Request 3.1.2


PACA Update 3.2.7


Authentication Data 4.2.62 59H ADDS Transfer 3.6.3

CM Service Request 3.1.2 Authentication Event 4.2.61 4AH ADDS Transfer 3.6.3



PACA Update 3.2.7

Paging Response 3.1.5 Authentication Parameter COUNT 4.2.37 40H ADDS Transfer 3.6.3



PACA Update 3.2.7

Paging Response 3.1.5 Authentication Response Parameter 4.2.36 42H ADDS Transfer 3.6.3 (AUTHR/AUTHU/AUTHBS) Authentication Response 3.3.2 Base Station Challenge

Response 3.3.6



PACA Update 3.2.7

Paging Response 3.1.5 Band Class 4.2.76 37H Handoff Off p Performed 3.4.9

Called Party ASCII Number 4.2.59 5BH Additional Service Request 3.1.20


CM Service Request Contin-uation

3.1.3

Called Party BCD Number 4.2.40 5EH Additional Service Request 3.1.20


CM Service Request Contin-uation

3.1.3

Flash with Information 3.2.1


B-23




Cause 4.2.16 04H ADDS Deliver Ack 3.6.6

ADDS Page Ack 3.6.2

ADDS Transfer Ack 3.6.4

Assignment Failure 3.1.9


Bearer Update Required 3.1.23

Block 3.5.1

BS Service Response 3.1.18

Clear Command 3.1.14

Clear Request 3.1.13

Handoff Command 3.4.4

Handoff Failure 3.4.8

Handoff Performed 3.4.9


3.4.3


Handoff Required Reject 3.4.7

Location Updating Accept 3.3.8

PACA Command Ack 3.2.6

PACA Update Ack 3.2.8

Radio Measurements for Position Response

3.2.10

Reset 3.5.7

Reset Circuit 3.5.5

Service Release 3.1.11

Transcoder Control Acknowledge

3.5.10

Cause Layer 3 4.2.42 08H Clear Command 3.1.14



SSD Update Response 3.3.4

CDMA Serving One Way Delay 4.2.57 0CH ADDS Deliver 3.6.5

ADDS Transfer 3.6.3






3.2.10


B-24




Cell Identifier 4.2.17 05H ADDS Page Ack 3.6.2 ADDS Transfer 3.6.3

Complete Layer 3 Information 3.1.1

Cell Identifier List 4.2.18 1AH ADDS Page 3.6.1


Feature Notification 3.2.3





3.4.3



Registration Request 3.3.19

Status Request 3.3.14

User Zone Reject 3.3.18

Channel Number 4.2.5 23H Assignment Complete 3.1.8


Channel Type 4.2.6 0BH Assignment Request 3.1.7


Circuit Group 4.2.66 19H Block 3.5.1

Reset Circuit 3.5.5

Unblock 3.5.3

Circuit Identity Code 4.2.19 01H Additional Service Request 3.1.20


Block 3.5.1

Block Acknowledge 3.5.2



Reset Circuit 3.5.5

Reset Circuit Acknowledge 3.5.6

Unblock 3.5.3

Unblock Acknowledge 3.5.4

Circuit Identity Code Extension 4.2.20 24H Handoff Request 3.4.2

Classmark Information Type 2 4.2.12 12H ADDS Transfer 3.6.3





B-25




Location Updating Request 3.3.7 Paging Response 3.1.5

CM Service Type 4.2.39 9XHa CM Service Request 3.1.2

Data Link Connection Identifier (DLCI)

4.2.2 noneb Additional Service Request 3.1.20

ADDS Deliver 3.6.5

ADDS Deliver Ack 3.6.6

Alert with Information 3.1.16


Authentication Response 3.3.2


Base Station Challenge Response

3.3.6

Connect 3.1.10


Flash with Information Ack 3.2.2


Location Updating Reject 3.3.9

Parameter Update Confirm 3.3.11

Parameter Update Request 3.3.10

Progress 3.1.6

Rejection 3.7.1

Service Redirection 3.8.1


Service Release Complete 3.1.12




Status Response 3.3.15


User Zone Update 3.3.17

User Zone Update Request 3.3.16

Downlink Radio Environment 4.2.22 29H Handoff Request 3.4.2


Downlink Radio Environment List 4.2.65 2BH Radio Measurements for Position Response

3.2.10

Encryption Information 4.2.10 0AH Assignment Complete 3.1.8




B-26




Handoff Required 3.4.1 Privacy Mode Command 3.3.12

Privacy Mode Complete 3.3.13

Extended Handoff Direction Parameters

4.2.56 10H Handoff Command 3.4.4


3.4.3

Geographic Location 4.2.64 2CH Radio Measurements for Position Response

3.2.10

Handoff Power Level 4.2.25 26H Handoff Command 3.4.4

Hard Handoff Parameters 4.2.47 16H Handoff Command 3.4.4


3.4.3

Information Record Requested 4.2.77 2EH Status Request 3.3.14

IS-2000 Cause Value 4.2.60 62H Rejection 3.7.1

IS-2000 Channel Identity 4.2.27 09H Handoff Command 3.4.4



3.4.3


IS-2000 Channel Identity 3X 4.2.23 27H Handoff Command 3.4.4



3.4.3


IS-2000 Mobile Capabilities 4.2.53 11H ADDS Page 3.6.1

ADDS Transfer 3.6.3












IS-2000 Non-Negotiable Service Configuration Record

4.2.52 0FH Handoff Command 3.4.4


B-27




Handoff Request 3.4.2 Handoff Request

Acknowledge 3.4.3


IS-2000 Redirection Record 4.2.82 67H Service Redirection 3.8.1

IS-2000 Service Configuration Record

4.2.51 0EH Handoff Command 3.4.4



3.4.3


IS-95 Channel Identity 4.2.9 22H Handoff Command 3.4.45



3.4.3


Layer 3 Information 4.2.30 17H Complete Layer 3 Information 3.1.1

Message Type 4.2.4 noneb Additional Service Notification

3.1.19


ADDS Deliver 3.6.5


ADDS Page 3.6.1

ADDS Page Ack 3.6.2

ADDS Transfer 3.6.3










3.3.6

Block 3.5.1

Block Acknowledge 3.5.2

BS Authentication Request 3.3.21

BS Authentication Request Ack

3.3.22


B-28




BS Service Request 3.1.17 BS Service Response 3.1.18

Clear Command 3.1.14

Clear Complete 3.1.15



CM Service Request Continuation

3.1.3

Complete Layer 3 Information 3.1.1

Connect 3.1.10


Feature Notification Ack 3.2.4




Handoff Commenced 3.4.5

Handoff Complete 3.4.6

Handoff Failure 3.4.8




3.4.3


Handoff Required Reject 3.4.7




PACA Command 3.2.5

PACA Command Ack 3.2.6

PACA Update 3.2.7






Privacy Mode Command 3.3.12


Progress 3.1.6


B-29




Radio Measurements for Position Request

3.2.9


3.2.10


Rejection 3.7.1

Reset 3.5.7

Reset Acknowledge 3.5.8

Reset Circuit 3.5.5

Reset Circuit Acknowledge 3.5.6








Transcoder Control Acknowledge

3.5.109

Transcoder Control Request 3.5.98

Unblock 3.5.3

Unblock Acknowledge 3.5.4




Mobile Identity 4.2.13 0DH Additional Service Notification

3.1.19

ADDS Page 3.6.1

ADDS Page Ack 3.6.2

ADDS Transfer 3.6.3




BS Authentication Request 3.3.21

BS Authentication Request Ack

3.3.22





B-30




Feature Notification 3.2.3 Feature Notification Ack 3.2.4




PACA Update 3.2.7





Rejection 3.7.1





MS Designated Frequency 4.2.88 73H ADDS Page 3.6.1





PACA Update 3.2.7






MS Information Records 4.2.55 15H Alert with Information 3.1.16



3.1.3


Flash With Information 3.2.1

Progress 3.1.6


MS Measured Channel Identity 4.2.29 64H Handoff Request 3.4.2


Origination Continuation Indicator 4.2.81 A0H CM Service Request 3.1.2

PACA Order 4.2.68 5FH PACA Update 3.2.7


B-31




PACA Reorigination Indicator 4.2.69 60H CM Service Request 3.1.2 PACA Timestamp 4.2.67 4EH Assignment Request 3.1.7

PACA Command 3.2.5

Packet Session Parameters 4.2.85 70H Handoff Request 3.4.2


Power Down Indicator 4.2.44 A2H Clear Complete 3.1.15

Priority 4.2.15 06H Assignment Request 3.1.7

PACA Command 3.2.5

PACA Update 3.2.7


Protocol Discriminator 4.2.31 noneb Additional Service Request 3.1.20

ADDS Deliver 3.6.5







3.3.6



3.1.3

Connect 3.1.10









Progress 3.1.6

Rejection 3.7.1







B-32




Status Request 3.3.14 Status Response 3.3.15




Protocol Revision 4.2.79 3BH ADDS Page 3.6.1










Protocol Type 4.2.54 18H Handoff Request 3.4.2


PSMM Count 4.2.63 2DH Radio Measurements for Position Request

3.2.9

Public Long Code Mask Identifier 4.2.87 72H Handoff Required 3.4.1



3.4.3


Quality of Service Parameters 4.2.41 07H Assignment Request 3.1.7



Radio Environment and Resources 4.2.58 1DH CM Service Request 3.1.2


Registration Type 4.2.45 1FH Location Updating Request 3.3.7

Reject Cause 4.2.34 44H Location Updating Reject 3.3.9

Reserved – Octet 4.2.32 noneb Additional Service Request 3.1.20

ADDS Deliver 3.6.5







B-33





3.3.6



3.1.3

Connect 3.1.10









Progress 3.1.6

Rejection 3.7.1











Response Request 4.2.28 1BH Handoff Required 3.4.1

Return Cause 4.2.83 68H CM Service Request 3.1.2


RF Channel Identity 4.2.7 21H Handoff Command 3.4.4

Service Option 4.2.49 03H Additional Service Notification

3.1.19


ADDS Transfer 3.6.3





Handoff Complete 3.4.6


B-34




Handoff Request 3.4.2 Handoff Required 3.4.1



Service Option Connection Identifier 4.2.73 1EH Additional Service Request 3.1.20

(SOCI) Alert with Information 3.1.16





Connect 3.1.10




Progress 3.1.6

Rejection 3.7.1



Service Option List 4.2.74 2AH Handoff Command 3.4.45



3.4.3


Service Redirection Info 4.2.84 69H Service Redirection 3.8.1

Service Reference Identifier (SR_ID) 4.2.86 71H Assignment Request 3.1.7


SID 4.2.8 32H Handoff Command 3.4.4

Signal 4.2.38 34H Assignment Request 3.1.7



Progress 3.1.6

Slot Cycle Index 4.2.14 35H ADDS Page 3.6.1

ADDS Transfer 3.6.3







B-35




Location Updating Request 3.3.7 Paging Request 3.1.4





Software Version 4.2.48 31H Reset 3.5.7

Reset Acknowledge 3.5.8

Source PDSN Address 4.2.24 14H Handoff Request 3.4.2


Source RNC to Target RNC Transparent Container

4.2.71 39H Handoff Request 3.4.2


Special Service Call Indicator 4.2.21 5AH Additional Service Request 3.1.20


Tag 4.2.46 33H ADDS Deliver 3.6.5


ADDS Page 3.6.1

ADDS Page Ack 3.6.2

ADDS Transfer 3.6.3







Feature Notification Ack 3.2.4





Target RNC to Source RNC Transparent Container

4.2.72 3AH Handoff Command 3.4.4


3.4.3

Transcoder Mode 4.2.43 36H Transcoder Control Request 3.5.9

User Zone ID 4.2.26 02H ADDS Transfer 3.6.3




B-36




Location Updating Request 3.3.7 User Zone Reject 3.3.18



Voice Privacy Request 4.2.11 A1H Additional Service Request 3.1.20




a. This is a type 1 IE (refer to section 4.1.3). The X in the IEI column is data. 1

b. This is a type 3 IE (refer to section 4.1.3) that is contained as a mandatory element in a DTAP 2

message. 3

... 4

4.2.4 Message Type 5

The Message Type is used to identify a message. Element Format: 6

4.2.4 Message Type4.2.4 Message Type4.2.4 Message Type4.2.4 Message Type

7 6 5 4 3 2 1 0 Octet

Message Type 1

Message Type: 7

This octet is coded as shown in Table 4.2.4-1. 8

BSMAP messages are used to perform functions at the MSC or BS while DTAP 9

messages carry information primarily used by the MS. For details, refer to [12]. 10

11

Table 4.2.4-1 BSMAP Messages

BSMAP Message Name

Message Type Value

Message Category

Section

ReferenceAdditional Service Notification 69H Call Processing 3.1.19 ADDS Page 65H Supplementary

Services 3.6.1

ADDS Page Ack 66H Supplementary Services

3.6.2

ADDS Transfer 67H Supplementary Services

3.6.3

ADDS Transfer Ack 68H Supplementary Services

3.6.4

Assignment Complete 02H Call Processing 3.1.8 Assignment Failure 03H Call Processing 3.1.9


B-37


BSMAP Message Name

Message Type Value

Message Category

Section

ReferenceAssignment Request 01H Call Processing 3.1.7 Authentication Request 45H Mobility Management 3.3.1 Authentication Response 46H Mobility Management 3.3.2 Base Station Challenge 48H Mobility Management 3.3.5 Bearer Update Request 58H Call Processing 3.1.21 Bearer Update Required 5AH Call Processing 3.1.23 Bearer Update Response 59H Call Processing 3.1.22 Base Station Challenge Response 49H Mobility Management 3.3.6 Block 40H Facilities Management 3.5.1 Block Acknowledge 41H Facilities Management 3.5.2 BS Service Request 09H Call Processing 3.1.17 BS Service Response 0AH Call Processing 3.1.18 Clear Command 20H Call Processing 3.1.14 Clear Complete 21H Call Processing 3.1.15 Clear Request 22H Call Processing 3.1.13 Complete Layer 3 Information 57H Call Processing 3.1.1 Feature Notification 60H Supplementary

Services 3.2.3

Feature Notification Ack 61H Supplementary Services

3.2.4

Handoff Command 13H Radio Resource Mgmt.

3.4.4

Handoff Commenced 15H Radio Resource Mgmt.

3.4.5

Handoff Complete 14H Radio Resource Mgmt.

3.4.6

Handoff Failure 16H Radio Resource Mgmt.

3.4.8

Handoff Performed 17H Radio Resource Mgmt.

3.4.9

Handoff Request 10H Radio Resource Mgmt.

3.4.2

Handoff Request Acknowledge 12H Radio Resource Mgmt.

3.4.3

Handoff Required 11H Radio Resource Mgmt.

3.4.1

Handoff Required Reject 1AH Radio Resource Mgmt.

3.4.7

PACA Command 6CH Supplementary Services

3.2.5

PACA Command Ack 6DH Supplementary Services

3.2.6


B-38


BSMAP Message Name

Message Type Value

Message Category

Section

ReferencePACA Update 6EH Supplementary

Services 3.2.7

PACA Update Ack 6FH Supplementary Services

3.2.8

Paging Request 52H Call Processing 3.1.4 Privacy Mode Command 53H Call Processing 3.3.12 Privacy Mode Complete 55H Call Processing 3.3.13 Radio Measurements for Position Request

23H Supplementary Services

3.2.9


25H Supplementary Services

3.2.10

Rejection 56H Call Processing 3.7.1 Registration Request 05H Mobility Management 3.3.19 Reset 30H Facilities Management 3.5.7 Reset Acknowledge 31H Facilities Management 3.5.8 Reset Circuit 34H Facilities Management 3.5.5 Reset Circuit Acknowledge 35H Facilities Management 3.5.6 Status Request 6AH Mobility Management 3.3.14 Status Response 6BH Mobility Management 3.3.15 Transcoder Control Acknowledge 39H Facilities Management 3.5.10 Transcoder Control Request 38H Facilities Management 3.5.9 Unblock 42H Facilities Management 3.5.3 Unblock Acknowledge 43H Facilities Management 3.5.4 User Zone Reject 0BH Mobility Management 3.3.18 BS Authentication Request 07H Mobility Management 3.3.21 BS Authentication Request Ack 08H Mobility Management 3.3.22

... 1

2

4.2.49 Service Option 3

This element indicates the service option requested by the MS, or by the network. It is coded as follows: 4

4.2.49 Service Option

7 6 5 4 3 2 1 0 Octet

A1 Element Identifier 1


(LSB) 3

Service Option: For signaling type TIA/EIA/IS-2000, the Service Option field in octets 2 and 3 is 5

coded as defined in [24]. 6


B-39

The service options supported are given in Table 4.2.49-1. 1

Table 4.2.49-1 Service Option Values 2

Service Option Value (hex)

Description

8000H 13K speech 0011H 13K high rate voice service 0003H EVRC 801FH 13K Markov 0004H Asynchronous Data rate set 1 0005H Group 3 Fax rate set 1 0007Ha Packet Data Service: Internet or ISO Protocol Stack (Revision 0) 0023H Position Determination Service (PDS) Rate Set 1 0024H Position Determination Service (PDS) Rate Set 2 0009H 13K loopback 0038H Selectable Mode Vocoder (SMV) 000CH Asynchronous Data rate set 2 000DH Group 3 Fax rate set 2 0006H SMS rate set 1 000EH SMS rate set 2 000FHa Packet Data Service: Internet or ISO Protocol Stack (14.4 kbps) 0012H OTAPA Rate Set 1 0013H OTAPA Rate Set 2 0020H IS-2000 Test Data 0036H IS-2000 Markov 0037H IS-2000 Loopback 0016Ha High Speed Packet Data Service:

Internet or ISO Protocol Stack (RS1 forward, RS1 reverse) 0017Ha High Speed Packet Data Service:



Internet or ISO Protocol Stack (RS2 forward, RS2 reverse) 0021H (3G High Speed Packet Data) 0025H (ISDN Interworking Service (64 kbps)) 0039H (32 kbps Circuit Switched Video Conferencing) 003AH (64 kbps Circuit Switched Video Conferencing) 003BH HRPD Packet Data; page response not required 003CHb Link-Layer Assisted Header Removal 003DHb Link-Layer Assisted Robust Header Compression 003EH Wideband Speech Codec 0045H HRPD Packet Data; page response required 1007Ha Packet Data Service: Internet or ISO Protocol Stack, Revision 1 (9.6 or 14.4 kbps)


B-40

1

a. These values are only used to indicate intergeneration handoff (refer to [13]). Any other use of these 2

values is outside the scope of this version of the standard. 3

b. This value can only be assigned to auxiliary services instances (e.g. when an SO33 has been 4

allocated) 5

6

... 7

4.2.91 Page Indicator 8

This element provides paging details to the BS. It is coded as follows: 9

7 6 5 4 3 2 1 0 Octet

A1 Element Identifier = [7DH] 1

Length 2

Reserved VPI 3

Length: This field indicates the number of octets in this element following the Length field. 10

VPI When the field is set to ‘1’, the 1x BS shall be prepared to receive a Page Response 11

Message from the MS/AT. Otherwise this field is set to ‘0’. 12

13

4.2.92 Event 14

The element is included by the MSC to indicate an event associated with the MS/AT. 15

7 6 5 4 3 2 1 0 Octet

A1 Element Identifier = [7EH] 1

Length 2

Event Identifier 3


Event: This field is coded as follow: 17

Binary Values Meaning

0000 0001 1x Registration 0000 0010 1x Power Down

All other values are reserved

18

19


C-1

Annex C A8-A9 (AN - PCF) Interface Change Text (Normative) 1

Note: Annex C, contains specific A9 messaging text from [16] with all HRPD related changes identified 2



... 5

6

1.2 References 7

... 8

1.2.1 TIA/EIA 9

[10] TIA-856-A-1, cdma2000 High Rate Packet Data Air Interface Specification, July 2005. 10

11

1.2.2 3GPP2 12

[10] C.S0024-A v2.0, cdma2000 High Rate Packet Data Air Interface Specification, July 2005. 13

14

... 15

16

2.0 Message Procedures 17

Note: When the procedures between 1x and HRPD systems differ, the HRPD procedures are identified 18

separately within this specification. Hard Handoff procedures are not applicable to HRPD. 19

2.1 A8/A9 Interface Setup Procedures 20

This section contains the messages used to set up an A8 connection. 21

2.1.1 A9-Setup-A8 22

This message is sent from the BS to the PCF to request the establishment of an A8 connection for a 23

packet data service instance (PDSI) activation, hard or dormant handoff of a PDSI, or to initiate CCPD 24

mode setup. 25


In 1x systems, Wwhen the BS receives a request for a PDSI activation from the MS (e.g., origination 27

message with DRS bit set to ‘1’) or when the BS receives a request for re-activation of a PDSI from the 28

PCF (e.g., A9-BS Service Request) or MSC (e.g., Paging Request), and the MS has responded to a page 29

(if not already on a traffic channel), it initiates service negotiation to put the PDSI onto radio traffic 30

channels, sends an A9-Setup-A8 message indicating normal call setup (i.e., the Handoff Indicator field of 31

the A9-Setup-A8 message is set to ‘0’), and starts timer TA8-setup. If no other PDSI is active, the BS shall 32

wait until the MSC has authorized the activation of the packet data session (e.g., the BS receives an 33


C-2

Assignment Request message) before sending the A9-Setup-A8 message. In an HRPD system, the PCF 1

stops timer Tnet_conn. 2

In HRPD systems, when the AN establishes the first A8 connection, the AN sends an A9-Setup-A8 3

message to the PCF with SR_ID 1, and starts timer TA8-setup. The A8 connection for SR_ID 1 is defined 4

as the main service instance and carries forward and reverse flows with Flow ID FFH. Note that other IP 5

Flows may be carried over the main A8 connection. 6

In HRPD systems, when the AN determines that additional A8 connections are required (e.g., when a new 7

link flow is established), the AN sends an A9-Setup-A8 message including the Additional A8 Traffic ID 8

IE, to the PCF, and starts timer TA8-setup. 9

When the BS supports the GRE extension and determines that GRE extension for the IP flow 10

discriminator is required, the BS sets the Use IP Flow Discriminator to ‘1’ in the A9-Setup-A8 message 11

for each A8 connection that requires the GRE extension. 12

When the MS performs a hard handoff during packet data services, the target BS sends an A9-Setup-A8 13

message to the PCF to establish an A8 connection upon receipt of the Handoff Request message from the 14

MSC and starts timer TA8-setup. In this case, the BS sets the Handoff Indicator field of the A9-Setup-A8 15

message to ‘1’ and the Data Ready Indicator to ‘1’. 16

When the BS receives a request for a dormant handoff from the MS (e.g., origination message with DRS 17

bit set to ‘0’ or including PREV_PZID, PREV_SID, or PREV_NID) or upon completion of the UATI 18

assignment procedures in HRPD systems, the BS sends the A9-Setup-A8 message to the PCF and starts 19

timer TA8-setup. In this case, the BS sets the Handoff Indicator to ‘0’. If no other PDSI is active, the BS 20

shall wait until the MSC has accepted the dormant handoff request (e.g., the BS receives an Assignment 21

Request or ADDS Transfer Ack message) before sending the A9-Setup-A8 message. 22

To indicate that CCPD Mode will be used for the PDSI associated with the A8 connection being 23

established, the BS sets the CCPD Mode bit to ‘1’. The BS shall wait until the MSC has accepted the 24

service request (e.g., the BS receives an ADDS Transfer Ack message) before sending the A9-Setup-A8 25

message. 26

If the MS supports short data bursts and the BS allows short data bursts to be sent for the PDSI, the BS 27

shall set the SDB/DOS Supported field in the message to ‘1’. Otherwise this field shall be set to ‘0’. 28


If the BS fails to receive an A9-Connect-A8 message or an A9-Release-A8 Complete message in 30

response to an A9-Setup-A8 message before the expiration of timer TA8-setup, the BS may resend the A9-31

Setup-A8 message to the PCF and restart timer TA8-setup a configurable number of times. If the BS fails 32

to receive an A9-Connect-A8 message or an A9-Release-A8 Complete message before timer TA8-setup 33

expires after a configurable number of tries or the BS does not resend the A9-Setup-A8 message, the BS 34

shall initiate release of the MS or service negotiation to remove the PDSI from the traffic channel (if 35

required). 36

In HRPD systems, if the AN fails to receive an A9-Connect-A8 message or an A9-Release-A8 Complete 37

message in response to the A9-Setup-A8 message for setting up additional A8 connections before timer 38

TA8-setup expires after a configurable number of times or the AN does not resend the A9-Setup-A8 39

message, the AN may initiate release of the AT or session configuration to remove the link flow 40

corresponding to the A8 connections (if required). 41

2.1.2 A9-Connect-A8 42

This A9 message is used to respond to an A9-Setup-A8 message. 43


C-3


The PCF sends an A9-Connect-A8 message to the BS in response to an A9-Setup-A8 message. If 2

establishment of an A10 connection is needed (e.g., during normal call setup), this message shall be sent 3

after the connection establishment is successful. If the Handoff Indicator field of the A9-Setup-A8 4

message is set to ‘1’, the PCF starts timer Twaitho9 after sending the first A9-Connect-A8 message. The 5

PCF stops timer Twaitho9 upon receipt of the A9-AL (Air Link) Connected or the A9-Release-A8 6

messages. Upon receiving the A9-Connect-A8 message, the BS stops the timer TA8-setup. 7

In HRPD systems, if the A9-Connect-A8 message establishes the main A8 connection, then the PCF 8

includes the subscriber QoS profile, if applicable. 9

In HRPD systems, when the PCF receives an A9-Setup-A8 message including the Additional A8 Traffic 10

ID IE, the PCF shall send an A9-Connect-A8 message for successful operation. If A10 connection 11

establishment is needed, the message shall be sent after connection establishment is successful. The A9-12

Connect-A8 message shall include connection information for the same number of A8 connections as in 13

the corresponding A9-Setup-A8 message. Upon receiving the A9-Connect-A8 message, the AN shall stop 14

timer TA8-setup. 15


If the timer Twaitho9 expires, the PCF should initiate clearing of the A8 connection by sending an A9-17

Disconnect-A8 message to the BS. The PCF starts timer Tdiscon9. 18

2.1.3 A9-BS Service Request 19

... 20

This A9 interface message is sent from the PCF to the BS to begin a network initiated call setup. 21


To initiate the reactivation of a dormant service instance, the PCF sends an A9-BS Service Request 23

message to the BS. The PCF starts timer Tbsreq9 and awaits the reception of the A9-BS Service Response 24

message. 25


If an A9-BS Service Response message is not received at the PCF before the expiration of timer Tbsreq9, 27

then the PCF may resend the A9-BS Service Request message and restart timer Tbsreq9 a configurable 28

number of times. 29

2.1.4 A9-BS Service Response 30

This A9 interface message is sent from the BS to the PCF in response to an A9-BS Service Request. 31


The BS shall send an A9-BS Service Response message to the PCF originating the A9-BS Service 33

Request message. Upon receiving the A9-BS Service Response Message, the PCF stops timer Tbsreq9. 34

In HRPD systems, the PCF also starts timer Tnet_conn and waits for an A9-Setup-A8 message. If timer 35

Tnet_conn expires prior to receiving the A9-Setup-A8 message, the PCF may resend the A9-BS Service 36

Request message. 37


None. 39


C-4

2.2 A8/A9 Interface Clearing Procedures 1

Procedures for clearing the A8 connection are described in this section. A8 connection clearing is initiated 2

whenever the PDSI state changes from active to dormant or null. Clearing the A8 connection does not 3

necessarily correspond to clearing of the traffic channel or the packet data service session. 4

A8 connection(s) clearing occurs: 5

• When a packet data inactivity timer in the BS expires for a PDSI. If it is the only active PDSI for the 6

MS, the BS requests the MSC to clear the service, sends an A9-Release-A8 message to the PCF and 7

starts timer Trel9. Otherwise, if it is not the only active PDSI, the BS sends an A9-Release-A8 8

message to the PCF and starts timer Trel9. For either case, the PCF responds with an A9-Release-A8 9

Complete message and the BS stops timer Trel9. The two scenarios are illustrated by the “BS Initiated 10

PDSI Release to Dormant State when no other PDSI is active” and the “BS Initiated PDSI Release to 11

Dormant State when other PDSIs are active” in [13]. The HRPD system call flow scenario is 12

illustrated in the IOS HRPD specification section 3.4.2, “Connection Release on HRPD Network - 13

Initiated by the AN”. 14

• When the BS receives a Release Order requesting the transition to dormant of a PDSI or connection 15

release procedures for HRPD systems, the BS performs the same procedures as in the BS initiated 16

scenarios. The two scenarios are illustrated by the “MS Initiated PDSI Release to Dormant State 17

when no other PDSI is active” and the “MS Initiated PDSI Release to Dormant State when other 18

PDSIs are active” in [13]. The HRPD system call flow scenario is illustrated in the IOS HRPD 19

specification section 3.4.1, “Connection Release on HRPD Network - Initiated by the AT”. 20

• In 1x systems, wWhen the MS releases the packet data session and . When the BS receives a Release 21

Order, the BS requests the MSC to clear the service, sends an A9-Release-A8 message to the PCF 22

with a cause value set to normal release if only one A8 connection is active and starts timer Trel9. If 23

this is not the only active PDSI, the cause value is set to packet data session release and sent for only 24

one of the A8 connections. The PCF responds with an A9-Release-A8 Complete message. The BS 25

stops timer Trel9. The “Active MS Power Down” and “MS Initiated Call Release to Null State” 26

scenarios are shown in [13]. 27

• In HRPD systems, when the AT or AN release the HRPD session and the A8 connection is already 28

established, the AN sends an A9-Release-A8 message to the PCF with a cause value set to “Normal 29

call release”. The HRPD system call flow scenario is illustrated in the IOS HRPD specification, 30

section 3.5.1, “HRPD Session Release – Initiated by the AT (A8 Connection Established)”When the 31

A10 connection is released by the PDSN. When the PCF detects that an A10 connection is released, 32

the PCF sends an A9-Disconnect-A8 message to the BS and starts timer Tdiscon9. The BS initiates 33

release of the A8 connection by sending an A9-Release-A8 message and starts timer Trel9. The PCF 34

responds with an A9-Release-A8 Complete message and stops timer Tdiscon9. If this is the last PDSI, 35

the BS clears any terrestrial resources and releases the air resources. Otherwise if this is not for the 36

last PDSI, the BS renegotiates the traffic channel. The two scenarios are illustrated by the “PDSN 37

Initiated Release of an active PDSI - Packet data session becomes dormant or inactive” and the 38

“PDSN Initiated Release of an active PDSI - Packet data session remains active” in [13].. 39

2.2.1 A9-Release-A8 40

This A9 interface message is sent from the BS to the PCF to request the release of the associated 41

dedicated resource. 42


When the BS needs to release an A8 connection, it sends an A9-Release-A8 message to the PCF. 44

In HRPD systems, the AN sends an A9-Release-A8 message without the Additional A8 Traffic ID IE 45

when the AN releases all A8 connections for the AT. 46


C-5

In HRPD systems, the AN sends an A9-Release-A8 message with the cause value “Partial connection 1

release”, including the Additional A8 Traffic ID IE to the PCF when the AN decides to release at least 2

one but not all A8 connections for an AT. The A9-Release-A8 message does not include information on 3

A8 connections to be released. The IP Flow=FFH shall not be released by the A9-Release-A8 message 4

with the cause value “Partial connection release”. When the PCF receives an A9-Release-A8 message 5

with a cause value of “Partial connection release”, the PCF releases all A8 connections for the AT. 6

When the BS releases an A8 connection for the case where the MS has powered down, the BS sends an 7

A9-Release-A8 message to the PCF with the cause value Packet Data Session Release included. This 8

message triggers the PCF to release all A10 connections associated with the MS. 9

When the BS releases an A8 connection for the case where a service instance is transitioning to the 10

Dormant State, the BS sends an A9-Release-A8 message to the PCF with the Cause value “Packet data 11

call going dormant” included. This message does not trigger the PCF to release any A10 connections. 12

The BS starts timer Trel9 and waits for the A9-Release-A8 Complete message from the PCF. 13

When the PCF receives the A9-Release-A8 message, it stops timer Tdiscon9, Taldak, or Twaitho9 if active 14

and performs the appropriate procedure to release the associated dedicated resources. 15


If an A9-Release-A8 Complete message is not received from the PCF before timer Trel9 expires, the BS 17

may resend the A9-Release-A8 message to the PCF and restart timer Trel9 a configurable number of 18

times. If the A9-Release-A8 Complete message is not received from the PCF, the BS shall cease further 19

supervision of this PDSI, release the dedicated resources associated with this PDSI, and release the A8 20

connection. 21

2.2.3 A9-Release-A8 Complete 22


2.2.4 A9-Disconnect-A8 24

This A9 interface message is sent from the PCF to the BS to request the release of the associated 25

dedicated resource. 26


In 1x System, wWhen the PCF needs to release an A8 connection, it sends an A9-Disconnect-A8 message 28

to the BS. The PCF starts timer Tdiscon9. In HRPD systems, the PCF sends an A9-Disconnect-A8 message 29

when the PCF releases all A8 connections for the AT. 30


If an A9-Release-A8 message is not received from the BS before timer Tdiscon9 expires, the PCF may 32

resend the A9-Disconnect-A8 message to the BS and restart timer Tdiscon9 a configurable number of 33

times. If the A9-Release-A8 message is not received from the BS, the PCF shall cease further supervision 34

of this A8 connection, send the A9-Release-A8 Complete message, and release the resources associated 35

with the A8 connection. 36

2.3 A8/A9 Interface Handoff Procedures 37

This section contains the messages used during handoff procedures. 38


C-6

2.3.1 A9-Air Link (AL) Connected 1

In 1x systems, this This message is sent from the target BS to the PCF after the MS performs hard 2

handoff. This message notifies the PCF that the handoff is successfully completed (i.e. that the air link 3

has been established between the MS and the target BS) and that the PCF can send packets on the 4

established A8 connection. The message may also be sent from the source BS to the PCF in the case of 5

handoff with return on failure. In this situation, the message notifies the PCF that the MS has re-6

established the air link with the source BS, and the PCF can resume sending packets to the source BS. 7

In HRPD systems, the A9-AL Connected message is sent from the AN managing the active air link to the 8

PCF when it determines that data flow stopped by the A9-AL Disconnected message from the PCF 9

should be resumed. This message is employed to notify the PCF that it can send packets on the A8 10

connection. An A9-AL Connected Ack message is expected in response to this message. 11


In 1x systems, after After the MS performs hard handoff including the case of return on failure, the BS 13

managing the active air link sends the A9-AL Connected message to the PCF. In the case of handoff with 14

return on failure the PCF stops timer Taldak upon receipt of this message. 15

Upon the receipt of the A9-AL Connected message, the PCF updates its routing table to route packet data 16

sent from the PDSN to the BS managing the active air link, stops the timers Twaitho9 for all established 17

A8 connections, and starts timer Talc9. The A9-AL Connected message triggers the PCF to establish A10 18

connections for all established A8 connections if needed (inter-PCF handoff). If the PCF is unable to 19

establish an A10 connection, it sends an A9-Disconnect-A8 message to the BS for the corresponding A8 20

connection. 21

If the PCF supports fast handoff, and the A10 connections have already been established if needed for all 22

A8 connections, when the PCF receives the A9-AL Connected message it starts to forward the data from 23

the PDSN to the BS on all A8 connections. 24

In HRPD systems, after the AN determines that data flow stopped by the A9-AL Disconnected message 25

from the PCF should be resumed, it sends the A9-AL Connected message to the PCF and starts timer 26

Talc9. Upon the receipt of the A9-AL Connected message, the PCF updates its routing table to route 27

packet data sent from the PDSN to the AN managing the active air link. 28


If timer Talc9 expires, the BS may resend the A9-AL-Connected message and restart timer Talc9 a 30

configurable number of times. If the A9-AL-Connected message is not resent or resending of this 31

message also results in failure, the BS shall initiate release of the packet data session. 32

If timer Twaitho9 expires, the PCF shall send an A9-Disconnect-A8 message for the associated A8 33

connection to the BS. The PCF shall start timer Tdiscon9. 34

2.3.2 A9-Air Link (AL) Connected Ack 35


2.3.3 A9-Air Link (AL) Disconnected 37

When the MS performs hard handoff or the AN determines that data flow from the PCF should be 38

stopped for all A8 connections, the A9-AL Disconnected message is sent from the source BS to the 39

source PCF. This message is sent to notify the source PCF that the air link is temporarily disconnected. 40

An A9-AL Disconnected Ack message is expected in response. 41


C-7


When the source BS receives the Handoff Command message which instructs it to perform hard handoff 2

or when the AN determines that data flow from the PCF should be stopped in the HRPD system for all 3

A8 connections, the source BS shall send an A9-AL Disconnected message to the PCF and start timer 4

Tald9. 5

Upon receipt of an A9-AL Disconnected message from the source BS, the PCF shall stop transmitting 6

packet data to the BS for all PDSIs and start buffering packets from the PDSN. 7


If timer Tald9 expires, the BS may resend the A9-AL Disconnected message and restart timer Tald9 a 9

configurable number of times. 10

2.3.4 A9-Air Link (AL) Disconnected Ack 11


2.4 A8/A9 Interface Maintenance Procedures 13

This section describes the A9 version control messages. 14

2.4.1 A9-Version Info 15


2.4.2 A9-Version Info Ack 17


2.5 A9 Session Update Procedures 19

This section contains message procedures for passing update information over the A9 interface. The A8 20

connection may or may not be established prior to sending an update on the A9 interface. 21

2.5.1 A9-Update-A8 22

The A9-Update-A8 message is sent from the PCF to the BS to update the BS with new or updated 23

parameters for a PDSI or packet data session. The packet data session shall be active when this message is 24

sent to the BS. 25

The A9-Update-A8 message is sent from the BS to the PCF to convey accounting information to the PCF 26

if the A8 connection is established before traffic channel establishment (in which case the PCF resumes 27

data transmission on the A8 connection only after it receives the A9-Update-A8 message) or while a 28

PDSI is active following accounting parameter changes which need to be conveyed to the PDSN 29

indirectly via the PCF. 30

In HRPD systems, the A9-Update-A8 message is sent from the AN to the PCF to convey IP flow-to--31

serviceservice connection mapping information IP flow QoS information when the IP flow-to-service 32

connection mapping does not require establishment of new A8 connections or release of existing A8 33

connection. This message may be sent when the AT is in the Active or Dormant State. 34

In HRPD systems, the A9-Update-A8 message is sent from the PCF to the AN to convey the Subscriber 35

QoS Profile. The packet data session may be active or dormant when this message is sent to the AN. 36

The BS may send an A9-Update-A8 message to the PCF to indicate if short data bursts may be sent to the 37

MS. The PCF may send an A9-Update-A8 message to the BS if the MS’s SDB capability is cached at the 38

PCF so the BS does not need to query the MS for its SDB capability. The BS may also send the A9-39


C-8

Update-A8 message to the PCF to indicate a successful Short Data Burst delivery to the MS if the PCF 1

was not informed previously that the SDB was delivered successfully to the MS. 2

The A9-Update-A8 message is also used to inform the PCF of an access authentication failure at the MSC 3

or at the AN-AAA for HRPD systems, following an access attempt by an MS undergoing dormant 4

handoff. The BS can also use this message to inform the PCF that a dormant MS has powered down. In 5

these two cases, the PCF initiates the release of all A10 connections associated with the MS. 6


If the A9-Update-A8 message is sent from the PCF to the BS to update packet data session parameters or 8

to convey the subscriber QoS profile, the PCF includes the Cause element set to ‘Session parameter 9

update’ upon reception of any new or updated session parameters or the subscriber QoS profile from the 10

PDSN. After sending the message to the BS, the PCF starts timer Tupd9 and waits for an A9-Update-A8 11

Ack message from the BS. 12

If the message is sent from the BS to the PCF to pass accounting or authentication information, the BS 13

shall set the Cause field to the appropriate value (1CH or 1EH), start timer Tupd9, and wait for an A9-14

Update-A8 Ack message from the PCF. 15

If the message is sent from the BS to the PCF or from the PCF to the BS to indicate if short data bursts 16

may be sent to the MS, the sending entity shall set the SDB/DOS Supported bit to ‘1’, set the Cause field 17

to ‘Capability update’ (1BH), start timer Tupd9 and wait for an A9-Update-A8 Ack message from the 18

receiving entity. 19

If the message is sent from the BS to the PCF to indicate a successful short data burst delivery to the MS, 20

the BS shall set the Cause field to ‘SDB successfully delivered’ (17H), start Tupd9 and wait for an A9-21

Update-A8 Ack message from the PCF. 22


When the message is sent from the PCF to the BS to update parameters for a PDSI, if Tupd9 expires, the 24

PCF may resend the A9-Update-A8 message to the BS and restart timer Tupd9 a configurable number of 25

times. If the A9-Update-A8-Ack message is not received from the BS, the session update procedure is 26

considered failed and the PCF notifies the PDSN. In the event of a failure, if an A8 connection was active 27

prior to the session update procedure, it shall remain connected. 28

When the message is sent from the BS to the PCF to pass accounting or authentication information, if an 29

A9-Update-A8 Ack message is not received from the PCF before timer Tupd9 expires, the BS may resend 30

the A9-Update-A8 message and restart timer Tupd9 a configurable number of times. If the 31

acknowledgment is not received from the PCF, the BS ceases sending this message, and commences 32

PDSI clearing. 33

2.5.2 A9-Update-A8 Ack 34


36

2.6 A8/A9 Interface Data Delivery Procedures 37

38

2.6.1 A9-Short Data Delivery 39

This A9 interface message is sent from the BS to the PCF when it receives a short data burst from the 40

MS. In HRPD systems, the AT does not send DOS messages unless the AN enables reverse link DOS for 41

that IP flow. Data received from the AT in a DOS message as specified in [10] do not contain a Flow ID, 42


C-9

but the A9-Short Data Delivery message carrying the data should be given expedited treatment through 1

the RAN transport network to the PDSN. If short data bursts are supported for the PDSI, this message 2

may also be sent from the PCF to the BS when there is a small amount of packet data to be sent from the 3

PDSN to an MS, and the PCF determines that a short data burst should be used to transmit this data. In 1x 4

systems, Tthis message is used when the MS’s PDSI is dormant. The data is encapsulated in the ADDS 5

user part element in SDB format as specified in [18]. In HRPD systems, the data is encapsulated in DOS 6

format as specified in [10]. In HRPD systems, in the PCF to AN direction, the message shall also includes 7

the Flow ID of the IP Flow which constitutes the payload of the ADDS user part element. 8

When used in the PCF to BS direction, the PCF retains a copy of the data sent in the message. The 9

message also contains a count of the number of additional bytes of data remaining at the PCF for the 10

PDSI. This information may be used by the BS, for example in determining whether short data bursts for 11

1x systems and DOS for HRPD systems could be used to deliver the data to the MS. 12


The BS sends the A9-Short Data Delivery message to the PCF after receiving a short data burst from the 14

MS and after optionally authenticating the MS. Upon receipt of this message by the PCF, the packet data 15

is sent to the PDSN on the A10 connection associated with service instance indicated in the A9-Short 16

Data Delivery. 17

The PCF sends the A9-Short Data Delivery message to the BS when it determines that there is a small 18

amount of data to be sent to a dormant PDSI at the MS or if the packet data service is operating in CCPD 19

Mode. The PCF shall send this message only if short data bursts are supported for the PDSI. The PCF 20

starts timer Tsdd9 and waits for an A9-Short Data Ack message from the BS. In 1x systems if the BS 21

decides that the data can be sent to the MS as a Short Data Burst, an A9-Short Data Ack message is sent 22

to the PCF with a successful cause value. In HRPD systems, if the AN decides that the data can be sent in 23

DOS format, it attempts to deliver the packet via DOS messages. The result of the DOS messaging is 24

conveyed from the AN to the PCF via an A9-Short Data Ack message. If the BS does not initiate the 25

ADDS Page procedure to deliver the SDB, the BS may alternatively send the A9-Short Data Ack message 26

to the PCF, with the cause value indicating if the data was successfully delivered, after the data has been 27

sent to the MS. The BS may also reject the PCF’s request for a short data burst delivery via the A9-Short 28

Data Ack message. 29


If timer Tsdd9 expires before the PCF receives an A9-Short Data Ack or an A9-Update A8 message from 31

the BS, the buffered data at the PCF is discarded. 32

2.6.2 A9-Short Data Ack 33

In 1x systems, Tthis message is sent from the BS to the PCF to acknowledge the receipt of the A9-Short 34

Data Delivery message from the PCF. It also indicates to the PCF whether the data received is to be sent 35

to the MS as a short data burst or alternatively whether the data was successfully delivered to the MS. In 36

HRPD systems, the A9-Short Data Ack message is used to indicate to the PCF the result of DOS 37

messaging i.e., whether or not the DOS message was successfully delivered. 38


If the BS decides to send the data received from the PCF to the MS as a short data burst, it shall indicate 40

this to the PCF in the A9-Short Data Ack message. Upon receiving this indication, the PCF stops timer 41

Tsdd9 and discards its copy of the buffered data. Note that acceptance of the data is independent of the 42

mechanism the BS chooses to send the data to the MS over the air interface. The BS may send this data 43

directly to the MS via a short data burst, or it may forward the data to the MSC using the BS Service 44

Request/Response procedure. If the BS is unsuccessful in delivering the data to the MS on its own, it may 45

choose to send the data to the MSC for delivery to the MS via the ADDS Page procedure. This procedure 46

is not used in HRPD systems. 47


C-10

If the BS decides against delivering the data to the MS as an SDB/DOS,, it shall respond to the PCF with 1

an A9-Short Data Ack message with a reject indication. Upon reception of this message, the PCF shall 2

stop timer Tsdd9 and then initiate re-activation of the 1x PDSI or HRPD packet data session from the 3

dormant state by sending an A9-BS Service Request message to the BS. Refer to [13] for more details. 4

The BS may also try to send the SDB/DOS data to the mobile before sending the A9-Short-Data Ack 5

message to the PCF. In this case, the A9-Short-Data Ack message contains a cause value indicating if the 6

data was successfully delivered. If the SDB/DOS data was successfully delivered to the MS, the PCF 7

proceeds to flush the data from its buffer. If the data could not be delivered to the MS, the PCF may 8

initiate a re-activation of the packet data session to deliver the packet data. 9


None. 11

... 12

3.1.1 A9-Setup-A8 13

This message is sent from the BS to the PCF to request the establishment of an A8 connection. In HRPD 14

systems, this message shall be used when performing any additions, deletions, remappings, and/or 15

changes in granted QoS of IP flows that require establishment of an A8 connection. 16


Element Direction Type

A9 Message Type 4.2.13 BS -> PCF M Call Connection Reference 4.2.10 BS -> PCF O R Correlation ID 4.2.11 BS -> PCF Oa C Mobile Identity (IMSI) 4.2.2 BS -> PCF Ok R Mobile Identity (ESN) 4.2.2 BS -> PCF Ob C CON_REF 4.2.14 BS -> PCF Ol R Quality of Service Parameters 4.2.7 BS -> PCF Oc C A9 Cell Identifier 4.2.15 BS -> PCF O R A8 Traffic ID 4.2.16 BS -> PCF O R Service Option 4.2.8 BS -> PCF Oo R A9 Indicators 4.2.17 BS -> PCF O R User Zone ID 4.2.6 BS -> PCF Od C IS-2000 Service Configuration Record 4.2.20 BS -> PCF Oe C Access Network Identifiers 4.2.19 BS -> PCF Of C PDSN Address 4.2.5 BS -> PCF Og C Anchor PDSN Address 4.2.22 BS -> PCF Oh C Anchor P-P Address 4.2.12 BS -> PCF Oi C SR_ID 4.2.4 BS -> PCF Oj R Mobile Identity (MEID) 4.2.2 BS -> PCF Ob C Additional A8 Traffic ID 4.2.32 BS -> PCF Om C Forward QoS Information 4.2.33 BS -> PCF On C Reverse QoS Information 4.2.34 BS -> PCF On C

17


C-11

a. If this element is included in this message, its value shall be returned in the corresponding element in 1

the A9-Connect-A8 or A9-Release-A8 Complete message sent in response to this message. 2

b. If an additional occurrence of the Mobile Identity information element (in addition to the Mobile 3

Identity Type, IMSI) is included, it shall contain the indicated Mobile Identity Type of the MS/AT. 4

Inclusion of ESN, MEID or both in this message is a network operator decision. 5

c. This information element is included if QoS information is available at the BS. In this version of this 6

standard, this element is used to carry the current non-assured mode priority of the packet data 7

session. This IE shall not be included in HRPD messages. 8

d. The User Zone ID is included if received from the MS. This IE shall not be included in HRPD 9

messages. 10

e. This information element may be omitted if the BS does not possess this information at the time the 11

message is created. This IE shall not be included in HRPD messages. 12

f. The Previous Access Network Identifiers are included if received from the MS or the MSC. 13

g. This is the A11 interface IP address of the source PDSN. This element is only present if the BS 14

received this information from the source BS as part of a hard or fast handoff request. In HRPD 15

systems, if this information element is included in the A13-Session Information Response message, 16

then this information element is included and contains the value received in the A13-Session 17

Information Response message. 18

h. This is the A11 interface IP address of the anchor PDSN. This element is only present if the BS 19

received this information from the source BS as part of a fast handoff request. If this IE is included in 20

the A13-Session Information Response message, then this IE is included and contains the value 21

received in the A13-Session Information Response message. 22

i. This is the P-P interface IP address of the anchor PDSN. This element is only present if the BS 23

received this information from the source BS as part of a fast handoff request. 24

j. This element specifies the SR_ID of the service instance in the Service Option element. In HRPD 25

systems, the SR_ID shall be set to 01H (the main service connection). 26

k. This IE element shall be set to the MN ID, associated with the A10 connection, in HRPD messages. 27

l. The IS-2000 CON_REF field of this IE shall be set to 00H for padding, in HRPD messages. 28

m. In HRPD systems, this IE shall include all auxiliary A8 connections (existing connections to keep as 29

well as new connections to establish) associated with the AT. A8 connections to be released shall be 30

omitted. 31

n. In HRPD systems, this IE shall include the IP flow-to-service connection mapping for all IP flows in 32

the specified direction (existing IP flows to keep as well as new IP flows to establish) associated with 33

the AT. IP flows to be released shall be omitted. Existing IP flows may be remapped to a different A8 34

connection and may have a change in granted QoS. 35

o. In HRPD systems, this is the service option of the main service connection. 36

The following table shows the bitmap layout for the A9-Setup-A8 message. 37

3.1.1 A9-Setup-A8

7 6 5 4 3 2 1 0 Octet


⇒⇒⇒⇒ Call Connection Reference: A9 Element Identifier = [3FH] 1

Length = [08H] 2

(MSB) Market ID = <any value> 3


C-12

3.1.1 A9-Setup-A8

7 6 5 4 3 2 1 0 Octet

(LSB) 4

(MSB) Generating Entity ID = <any value> 5

(LSB) 6

(MSB) Call Connection Reference = <any value> 7

8

9

(LSB) 10

⇒⇒⇒⇒ Correlation ID: A9 Element Identifier = [13H] 1

Length = [04H] 2

(MSB) Correlation Value = <any value> 3

4

5

(LSB) 6




Type of Identity = [110] (IMSI) 3


… …


Identity Digit N+3 = [0H-9H] (BCD) (if odd number of digits)

= [1111] (if even number of digits)



Length = [05H] 2


= [0]

Type of Identity = [101] (ESN) 3


5

6

(LSB) 7

⇒⇒⇒⇒ CON_REF: A9 Element Identifier = [01H] 1

Length = [01H] 2

IS-2000 CON_REF = [00H – FFH] 3

⇒⇒⇒⇒ Quality of Service Parameters: A9 Element Identifier = [07H] 1

Length = [01H] 2


C-13

3.1.1 A9-Setup-A8

7 6 5 4 3 2 1 0 Octet

Reserved = [0000] Non-Assured Mode Packet Priority = [0000 – 1101]

3

⇒⇒⇒⇒ A9 Cell Identifier: A9 Element Identifier = [06H] 1

Length = [06H] 2

Cell Identification Discriminator = [07H] 3

(MSB) MSCID = <any value> 4

5

(LSB) 6

(MSB) Cell = [001H-FFFH] 7

(LSB) Sector = [0H-FH] (0H = Omni) 8

⇒⇒⇒⇒ A8 Traffic ID: A9 Element Identifier = [08H] 1

Length = [0CH] 2

A8 transport protocol stack = [01H] (GRE/IP) 3

(MSB) Protocol Type = [88 81H] (Unstructured byte stream) 4

(LSB) 5

(MSB) Key = <any value> 6

7

8

(LSB) 9

Address Type = [01H] (IPv4) 10

(MSB) IP Address = <any value> 11

12

13

(LSB) 14



= [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

(LSB) 3

⇒⇒⇒⇒ A9 Indicators: A9 Element Identifier = [05H] 1

Length = [01H] 2

QoS Mode

= [0, 1]

Packet Boundary Supported

= [0] (ignored)

GRE Segment. Supported

= [0,1]

SDB/DOS Supported

= [0,1]

CCPD Mode =

[0,1]

Reserved =[0]

Data Ready

Indicator = [0,1]

Handoff Indicator = [0, 1]

3

⇒⇒⇒⇒ User Zone ID: A9 Element Identifier = [02H] 1


C-14

3.1.1 A9-Setup-A8

7 6 5 4 3 2 1 0 Octet

Length = [02H] 2

(MSB) UZID = <any value> 3

(LSB) 4

⇒⇒⇒⇒ IS-2000 Service Configuration Record: A9 Element Identifier = [0EH] 1

Bit-Exact Length – Octet Count = <variable> 2

Reserved = [0000 0]

Bit-Exact Length – Fill Bits = [000 – 111]

3

(MSB) 4

IS-2000 Service Configuration Record Content = <any value> … Seventh

Fill Bit – if needed = [0 (if


Sixth Fill Bit – if needed = [0 (if






Third Fill Bit – if needed= [0 (if






k

⇒⇒⇒⇒ Access Network Identifiers: A9 Element Identifier = [20H] 1

Length = [05H] 2 Reserved

= [0] (MSB) SID = <any value> 3

(LSB) 4

(MSB) NID = <any value> 5

(LSB) 6

PZID = <any value> 7

⇒⇒⇒⇒ PDSN Address: A9 Element Identifier = [14H] 1

Length = [04H] 2

(MSB) PDSN Address = <any value> 3

4

5

(LSB) 6

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

Length = [04H] 2

(MSB) Anchor PDSN Address = <any value> 3

4

5

(LSB) 6

⇒⇒⇒⇒ Anchor P-P Address: A9 Element Identifier = [40H] 1

Length = [04H] 2

(MSB) Serving P-P IP Address = <any value> 3

4

5


C-15

3.1.1 A9-Setup-A8

7 6 5 4 3 2 1 0 Octet

(LSB) 6

⇒⇒⇒⇒ SR_ID: A9 Element Identifier = [0BH] 1

Length = [01H] 2

SR_ID = [00H-1FH] 3

Reserved = [0000 0] IS-2000 SR_ID = [001 - 110] 3


Length = [08H] 2

MEID Hex Digit 1 = [0H-FH] Odd/Even Indicator =

‘0’


3








⇒⇒⇒⇒ Additional A8 Traffic ID: A9 Element Identifier = [92H] 1


A8 Traffic ID Entry { 1-6 :

Entry Length = [0FH] n

SR_ID = [00H-1FH] n+1

(MSB) Service Option = [00 40H (High Rate Packet Data – Auxiliary) ] n+2

(LSB) n+3

A8 transport protocol stack = [01H] (GRE/IP) n+4

(MSB) Protocol Type = [88 81H] (Unstructured byte stream) n+5

(LSB) n+6

(MSB) Key = <any value> n+7

n+8

n+9

(LSB) n+10

Address Type = [01H] (IPv4) n+11

(MSB) IP Address = <any value> n+12

n+13

n+14

(LSB) n+15

} A8 Traffic ID Entry

⇒⇒⇒⇒ Forward QoS Information: A9 Element Identifier = [8EH] 1


C-16

3.1.1 A9-Setup-A8

7 6 5 4 3 2 1 0 Octet


(LSB) 3

Forward QoS Information Entry { 1-7:

(MSB) Entry Length = [variable] j

(LSB) j+1

SR_ID = [00H-1FH] j+2 Use IP Flow

Discrimi-nation =

[0,1]

DSCP Included

Reserved = [0 0000] j+3

Reserved = [000] Forward Flow Count = [0 – 31] j+4

Forward Flow Entry { Forward Flow Count :

Entry Length = [variable] k

Forward Flow ID = [00H – FFH] k+1

Reserved = [0]

DSCP = [00H – 3FH] Flow State = [0, 1]

k+2

Forward Requested QoS Length = [variable] k+2

(MSB) Forward Requested QoS = <any value> k+3

… … (LSB) m

Forward Granted QoS Length = [variable] m+1

(MSB) Forward Granted QoS = <any value> m+2

… … (LSB) n

} Forward Flow Entry

} Forward QoS Information Entry

⇒⇒⇒⇒ Reverse QoS Information: A9 Element Identifier = [8FH] 1


(LSB) 3

Reverse QoS Information Entry { 1-7:

(MSB) Entry Length = [variable] j

(LSB) j+1

SR_ID = [00H-1FH] j+2

Reserved = [000] Reverse Flow Count = [0 – 31] j+3

Reverse Flow Entry { Reverse Flow Count :

Entry Length = [variable] k

Reverse Flow ID = [00H – FFH] k+1


C-17

3.1.1 A9-Setup-A8

7 6 5 4 3 2 1 0 Octet

Reserved = [0000 000] Flow State = [0, 1]

k+2

Reverse Requested QoS Length = [variable] k+2

(MSB) Reverse Requested QoS = <any value> k+3

… … (LSB) m

Reverse Granted QoS Length = [variable] m+1

(MSB) Reverse Granted QoS = <any value> m+2

… … (LSB) n

} Reverse Flow Entry

} Reverse QoS Information Entry

1

3.1.2 A9-Connect-A8 2

This message is sent from the PCF to the BS to complete the setup of the A8 connection. 3



A9 Message Type 4.2.13 PCF -> BS M Call Connection Reference 4.2.10 PCF -> BS O R Correlation ID 4.2.11 PCF -> BS Oa C Mobile Identity (IMSI) 4.2.2 PCF -> BS Oh R Mobile Identity (ESN) 4.2.2 PCF -> BS Ob C CON_REF 4.2.14 PCF -> BS Oi R A8 Traffic ID 4.2.16 PCF -> BS O R Cause 4.2.3 PCF -> BS O R PDSN Address 4.2.5 PCF -> BS Oc C Anchor PDSN Address 4.2.22 PCF -> BS Od C Anchor P-P Address 4.2.12 PCF -> BS Oe C SR_ID 4.2.4 PCF -> BS Of R Service Instance Info 4.2.25 PCF -> BS Og C Mobile Identity (MEID) 4.2.2 PCF -> BS Ob C Additional A8 Traffic ID 4.2.32 PCF -> BS Oj C A9 Indicators 4.2.17 PCF -> BS Ok C Subscriber QoS Profile 4.2.35 PCF -> BS Ol C

4

a. This element shall only be included if it was also included in the A9-Setup-A8 message. This element 5

shall be set to the value received in that message. 6


C-18


Identity Type, IMSI) is included, it shall contain the indicated Mobile Identity Type of the MS. 2


c. This is the A11 interface IP address of the target PDSN that terminates the A10 connection 4

corresponding to the just-established A8 connection. If an A10 connection has been established, this 5

element is included in this message and saved by the BS, and included in the Handoff Required 6

message in the event of a hard handoff. 7

d. This is the A11 interface IP address of the anchor PDSN. This element shall be included if the Anchor 8

P-P Address is included. During a fast handoff, it shall contain the same value as the Anchor PDSN 9

Address received in the A9-Setup-A8 message; otherwise it shall be set to the same value as the 10

PDSN Address. It is saved by the BS and included in the Handoff Required message in the event of a 11

fast handoff. During a fast handoff, inclusion of this field indicates acceptance of the fast handoff. 12

e. This is the IP address for establishing P-P connections to the serving PDSN . This element shall be 13

included if fast handoff is supported and if the value was received from the PDSN. It is saved by the 14

BS and included in the Handoff Required message in the event of a fast handoff. During a fast 15

handoff, inclusion of this field indicates acceptance of the fast handoff. 16

f. This element specifies the SR_ID of the connected service instance. In HRPD systems, the SR_ID 17

shall be set to 01H (the main service connection). 18

g. This element identifies all service instances for which the PCF has an A10 connection, excluding the 19

service instance identified by the SR_ID information element. This element shall be included on 20

transition of the packet data session to the Active State, i.e., when the first A8 connection of a packet 21

data session is being established, but not during handoff (i.e., the Handoff Indicator in the A9-Setup-22

A8 message was set to ‘1’). This IE shall not be included for HRPD messages. 23

h. This IE shall be set to the MN ID, associated with the A10 connection, in HRPD messages. 24

i. The IS-2000 CON_REF field of this IE shall be set to 00H for padding, in HRPD messages. 25

j. This IE shall be included if it was included in the corresponding A9-Setup-A8 message. The number 26

of forward A8 connections included in this IE shall be same as the number of reverse GRE 27

connections included in the Additional A8 Traffic ID IE in the corresponding A9-Setup-A8 message. 28

k. This element shall be included if PCF has enabled packet boundary indications. 29

l. This IE is included if this information is available. 30

31

The following table shows the bitmap layout for the A9-Connect-A8 message. 32

3.1.2 A9-Connect-A8

7 6 5 4 3 2 1 0 Octet



Length = [08H] 2


(LSB) 4


(LSB) 6


8


C-19

3.1.2 A9-Connect-A8

7 6 5 4 3 2 1 0 Octet

9

(LSB) 10


Length = [04H] 2


4

5

(LSB) 6





3


… …






Length = [05H] 2


= [0]


3


5

6

(LSB) 7


Length = [01H] 2

IS-2000 CON_REF = [00H – FFH] 3


Length = [0CH] 2



(LSB) 5


7

8


C-20

3.1.2 A9-Connect-A8

7 6 5 4 3 2 1 0 Octet

(LSB) 9



12

13

(LSB) 14


Length = [01H] 2

ext = [0] Cause Value = [13H (Successful operation), 7AH (Data ready to send)]

3


Length = [04H] 2


4

5

(LSB) 6


Length = [04H] 2


4

5

(LSB) 6


Length = [04H] 2

(MSB) Anchor P-P Address = <any value> 3

4

5

(LSB) 6


Length = [01H] 2

Reserved = [0000 0] IS-2000 SR_ID = [001 - 011] 3

⇒⇒⇒⇒ Service Instance Info: A9 Element Identifier = [41H] 1

Length = [00-0FH] 2

Reserved=[0000 0] SR_ID-3 = [0,1]

SR_ID-2 = [0,1]

SR_ID-1 = [0,1]

3


C-21

3.1.2 A9-Connect-A8

7 6 5 4 3 2 1 0 Octet

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

4

(LSB) 5

… …

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

2n+2

(LSB) 2n+3


Length = [08H] 2


‘0’


3












Reserved = [0000 0] SR_ID = [2 –7] n+1


(LSB) n+3



(LSB) n+6


n+8

n+9

(LSB) n+10



n+13


C-22

3.1.2 A9-Connect-A8

7 6 5 4 3 2 1 0 Octet

n+14

(LSB) n+15



Length = [01H] 2

QoS Mode =

[0] (ignored)


= [0,1]

GRE Segment

Supported = [0]

(ignored)

SDB/DOSSupported

= [0] (ignored)

CCPD Mode =

[0] (ignored)

Reserved = [0]

(ignored)

Data Ready

Indicator = [0]

(ignored)

Handoff Indicator

= [0] (ignored)

3

⇒⇒⇒⇒ Subscriber QoS Profile: A9 Element Identifier = [90H] 1


(MSB) Subscriber QoS Profile 3

4

… …

(LSB) n

1

2

3.1.3 A9-BS Service Request 3

This message is sent from the PCF to the BS to request re-activation of a dormant PDSI. In HRPD 4

systems, this message requests re-activation of all service connections for the packet data session. 5



A9 Message Type 4.2.13 PCF -> BS M Correlation ID 4.2.11 PCF -> BS Oa C Mobile Identity (IMSI) 4.2.2 PCF -> BS Oe R Mobile Identity (ESN) 4.2.2 PCF -> BS Ob C Service Option 4.2.8 PCF -> BS Of R Data Count 4.2.18 PCF -> BS Oc C SR_ID 4.2.4 PCF -> BS Od R Mobile Identity (MEID) 4.2.2 PCF -> BS Ob C

6


the A9-BS Service Response message sent in response to this message. 8




c. This IE may be included by the PCF to indicate to the BS the amount of data remaining at the PCF 12

that is to be transmitted. 13


C-23

d. This element specifies the SR_ID of the service instance in the Service Option element. 1

e. This IE shall be is set to the MN ID, associated with the A10 connection, in HRPD messages. 2

f. In 1x systems, this element specifies the service option value of the PDSI to be re-activated 3

The following table shows the bitmap layout for the A9-BS Service Request message. 4

3.1.3 A9-BS Service Request

7 6 5 4 3 2 1 0 Octet



Length = [04H] 2


4

5

(LSB) 6





3


… …






Length = [05H] 2


= [0]


3


5

6

(LSB) 7



= [00 21H (3G High Speed Packet Data)] for 1x systems = [00 3BH (HRPD Main Service Connection)] for HRPD systems

(LSB) 3

⇒⇒⇒⇒ Data Count: A9 Element Identifier = [09H] 1

Length = [02H] 2

Count = <any value> 3


C-24

3.1.3 A9-BS Service Request

7 6 5 4 3 2 1 0 Octet

… 4


Length = [01H] 2

Reserved = [0000 0] IS-2000 SR_ID = [001 - 011] 3


Length = [08H] 2


‘0’


3








... 1

3.2.1 A9-Release-A8 2

This message is sent from the BS to the PCF to release an A8 connection. In HRPD systems, this message 3

shall be used when performing any additions, deletions, remappings, and/or changes in granted QoS of IP 4

flows that require release of one or more A8 connections but no A8 connection establishment. (For A8 5

connection release with A8 connection establishment, refer to section 3.1.1.). 6



A9 Message Type 4.2.13 BS -> PCF M


C-25

Call Connection Reference 4.2.10 BS -> PCF O R Correlation ID 4.2.11 BS -> PCF Oa C Mobile Identity (IMSI) 4.2.2 BS -> PCF Of R Mobile Identity (ESN) 4.2.2 BS -> PCF Ob C CON_REF 4.2.14 BS -> PCF Og R A8 Traffic ID 4.2.16 BS -> PCF Oh R Cause 4.2.3 BS -> PCF Oc R Active Connection Time in Seconds 4.2.1 BS -> PCF Od R SR_ID 4.2.4 BS -> PCF Oe,h R Mobile Identity (MEID) 4.2.2 BS -> PCF Ob C Additional A8 Traffic ID 4.2.32 BS -> PCF Oi C Forward QoS Information 4.2.33 BS -> PCF Oj C Reverse QoS Information 4.2.34 BS -> PCF Oj C

1

a. This element shall be included if it was also included in the A9-Disconnect-A8 message. This 2

element shall be set to the value received in that message. If this element was not included in that 3

message, it may be included in this message. 4




c. The cause value Normal Call Release indicates that the PDSI has been released and therefore the A10 8

resources associated with this service instance should be dropped. If the cause value indicates Packet 9

Data Session Release, all services have been released by the MS and therefore all A10 connections 10

associated with the MS shall be released. If the cause value indicates a hard handoff failure, the PCF 11

shall not release any A10 connection associated with the packet data session (intra-PCF hard handoff 12

failure). In HRPD systems, any cause value other than “Partial connection release” indicates that all 13

A8 connections associated with the AT shall be released. 14

d. This element shall be included to indicate the active connection time for a traffic channel. For HRPD 15

systems, this element indicates the current value of the active connection time for the traffic channel 16

at the time this message is sent. 17

e. In 1x systems, tThis element specifies the SR_ID of the service instance to be released. 18

f. This IE shall be set to the MN ID, associated with the A10 connection, in HRPD messages. 19

g. The IS-2000 CON_REF field of this IE shall be set to 00H for padding, in HRPD messages. 20

h. In HRPD systems, this IE shall contain information for the main A8 connection. 21

i. In HRPD systems, this IE shall be included if the Cause value is set to “Partial connection release”. It 22

specifies all auxiliary A8 connections to keep. A8 connections to be released shall be omitted. This 23

IE shall be omitted when releasing all A8 connections for the AT. 24

j. In HRPD systems, this IE shall include the IP flow-to-service connection mapping for all IP flows in 25

the specified direction (IP flows to keep) associated with the AT. IP flows to be released shall be 26

omitted. Existing IP flows may be remapped to a different A8 connection and may have a change in 27

granted QoS. 28

29

The following table shows the bitmap layout for the A9-Release-A8 message. 30


C-26

3.2.1 A9-Release-A8

7 6 5 4 3 2 1 0 Octet



Length = [08H] 2


(LSB) 4


(LSB) 6


8

9

(LSB) 10


Length = [04H] 2


4

5

(LSB) 6





3


… …






Length = [05H] 2


= [0]


3


5

6

(LSB) 7


Length = [01H] 2


C-27

3.2.1 A9-Release-A8

7 6 5 4 3 2 1 0 Octet

IS-2000 CON_REF = [00H – FFH] 3


Length = [0CH] 2



(LSB) 5


7

8

(LSB) 9



12

13

(LSB) 14


Length = [01H] 2

ext = [0] 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)]

3

⇒⇒⇒⇒ Active Connection Time in Seconds: A9 Element Identifier = [0AH] 1

Length = [04H] 2

(MSB) Active Connection Time = [00 00 00 00H – FF FF FF FFH] 3

4

… 5

(LSB) 6


Length = [01H] 2

Reserved = [0000 0] IS-2000 SR_ID = [001 - 011] 3


Length = [08H] 2


C-28

3.2.1 A9-Release-A8

7 6 5 4 3 2 1 0 Octet


‘0’


3












Reserved = [0000 0] SR_ID = [2 – 7] n+1


(LSB) n+3



(LSB) n+6


n+8

n+9

(LSB) n+10



n+13

n+14

(LSB) n+15





Entry Length = [variable] j

Use IP Flow

Discrimi-nation =

[0,1]

DSCP Included = [0,1]

Reserved = [000] SR_ID = [1 - 7] j+1



C-29

3.2.1 A9-Release-A8

7 6 5 4 3 2 1 0 Octet


Forward Flow ID = [00H – FFH] k

Reserved = [0]

DSCP = [00H – 3FH] Flow State = [0, 1]

k+1


(MSB) Forward Requested QoS BLOB = <any value> k+3

… … (LSB) m


(MSB) Forward Granted QoS BLOB = <any value> m+2

… … (LSB) n







Reserved = [0 0000] SR_ID = [1 - 7] j+1



Reverse Flow ID = [00H – FFH] k


k+1


(MSB) Reverse Requested QoS BLOB = <any value> k+3

… … (LSB) m


(MSB) Reverse Granted QoS BLOB = <any value> m+2

… … (LSB) n



1

... 2


C-30

3.2.2 A9-Release-A8 Complete 1

This message is sent from the PCF to the BS either to acknowledge the release of an A8 connection or to 2

indicate that an A8 does not need to be or cannot be set up. 3



A9 Message Type 4.2.13 PCF -> BS M Call Connection Reference 4.2.10 PCF -> BS O R Correlation ID 4.2.11 PCF -> BS Oa C Cause 4.2.3 PCF -> BS Ob C A9 PDSN Code 4.2.23 PCF -> BS Oc C SR_ID 4.2.4 PCF -> BS Od R

a. This element shall only be included if it was also included in the A9-Release-A8 message. This 4

element shall be set to the value received in that message. 5

b. This information element is present in the case where an A8 connection is not established during a 6

setup request. The element contains a release cause. 7

c. This information element may be present if a code is received from the PDSN. If this element is 8

present the Cause element shall be coded to ‘PCF (or PDSN) resources unavailable’ or ‘Packet call 9

going dormant’. 10

d. In 1x systems, tThis element indicates the SR_ID of the service instance that was released. In HRPD 11

systems, this IE shall contain information for the main A8 connection. 12

The following table shows the bitmap layout for the A9-Release-A8 Complete message. 13

3.2.2 A9-Release-A8 Complete

7 6 5 4 3 2 1 0 Octet



Length = [08H] 2


(LSB) 4


(LSB) 6


8

9

(LSB) 10


Length = [04H] 2


4

5

(LSB) 6


C-31


7 6 5 4 3 2 1 0 Octet


Length = [01H] 2

ext = [0] Cause Value = [01H (Partial connection release), 10H (Packet call going dormant), 07H (OAM&P intervention), 1AH (Authentication failure), 20H (Equipment failure), 23H (Authentication required), 24H (Session unreachable), 32H (PCF resources are not available), 60H (State mismatch), 79H (PDSN resources are not available)]

3

⇒⇒⇒⇒ A9 PDSN Code: A9 Element Identifier = [0CH] 1

Length = [01H] 2

PDSN Code = [00H (Registration Accepted), 80H (Registration Denied – reason unspecified) 81H (Registration Denied – administratively prohibited) 82H (Registration Denied – insufficient resources) 83H (Registration Denied – mobile node failed authentication) 85H (Registration Denied – identification mismatch) 86H (Registration Denied – poorly formed request) 88H (Registration Denied – unknown PDSN address) 89H (Registration Denied – requested reverse tunnel unavailable) 8AH (Registration Denied – reverse tunnel is mandatory and ‘T’ bit not set) 8DH (Registration Denied – unsupported vendor ID or unable to interpret

data in the CVSE)]

3


Length = [01H] 2

Reserved = [0000 0] IS-2000 SR_ID = [001 - 011] 3





Use IP Flow

Discrimi-nation =

[0,1]

DSCP Included

Reserved = [000] SR_ID = [1 - 7] j+1




C-32


7 6 5 4 3 2 1 0 Octet


Reserved DSCP Flow State = [0, 1]

k+1



… … (LSB) m



… … (LSB) n







Reserved = [0 0000] SR_ID = [1 - 7] j+1


Reverse Flow Entry {Reverse Flow Count :



k+1



… … (LSB) m



… … (LSB) n



1

3.2.3 A9-Disconnect-A8 2

This message is sent from the PCF to the BS to request the release of an A8 connection. 3


C-33



A9 Message Type 4.2.13 PCF -> BS M Call Connection Reference 4.2.10 PCF -> BS O R Correlation ID 4.2.11 PCF -> BS Oa C Mobile Identity (IMSI) 4.2.2 PCF -> BS Oe R Mobile Identity (ESN) 4.2.2 PCF -> BS Ob C CON_REF 4.2.14 PCF -> BS Of R A8 Traffic ID 4.2.16 PCF -> BS O R Cause 4.2.3 PCF -> BS O R A9 PDSN Code 4.2.23 PCF -> BS O

c C

SR_ID 4.2.4 PCF -> BS Od R Mobile Identity (MEID) 4.2.2 PCF -> BS Ob C

1


the A9-Release-A8 message sent in response to this message. 3




c. This information element may be present if a release code is received from the PDSN. If this element 7

is present, the Cause element shall be coded to ‘PCF (or PDSN) resources unavailable’. 8

d. This element specifies the SR_ID of the service instance to be disconnected. 9

e. This IE shall be set to the MN ID, associated with the A10 connection, in HRPD messages. 10

f. The IS-2000 CON_REF field of this IE shall be set to 00H for padding, in HRPD messages. 11

The following table shows the bitmap layout for the A9-Disconnect-A8 message. 12

3.2.3 A9-Disconnect-A8

7 6 5 4 3 2 1 0 Octet



Length = [08H] 2


(LSB) 4


(LSB) 6


8

9

(LSB) 10


Length = [04H] 2


C-34


7 6 5 4 3 2 1 0 Octet


4

5

(LSB) 6





3


… …






Length = [05H] 2


= [0]


3


5

6

(LSB) 7


Length = [01H] 2

IS-2000 CON_REF = [00H – FFH] 3


Length = [0CH] 2



(LSB) 5


7

8

(LSB) 9



12


C-35


7 6 5 4 3 2 1 0 Octet

13

(LSB) 14


Length = [01H] 2

ext = [0] Cause Value = [ 14H (Normal call release), 20H (Equipment failure), 07H (OAM&P intervention), 2AH (PCF resources are not available), 79H (PCF PDSN) resources are not available)]

3

⇒⇒⇒⇒ A9 PDSN Code: A9 Element Identifier = [0CH] 1

Length = [01H] 2

PDSN Code = [C1H (Connection Release - reason unspecified), C2H (Connection Release - PPP time-out ), C3H (Connection Release - registration time-out), C4H (Connection Release - PDSN error), C5H (Connection Release - inter-PCF handoff), C6H (Connection Release - inter-PDSN handoff), C7H (Connection Release - PDSN OAM&P intervention), C8H (Connection Release - accounting error ) CAH (Connection Release – user (NAI) authentication failure)]

3


Length = [01H] 2

Reserved = [0000 0] IS-2000 SR_ID = [001 - 011] 3


Length = [08H] 2


‘0’


3








... 1


C-36

3.3 A8/A9 Interface Handoff Messages 1

... 2

3.3.1 A9-AL (Air Link) Connected 3

This message is sent from the BS to the PCF to indicate that a traffic channel has been established to the 4

MS during hard or fast handoff or in HRPD systems when the AN determines that data flow stopped by 5

the A9-AL Disconnected message from the PCF should resume. 6



A9 Message Type 4.2.13 BS -> PCF M Call Connection Reference 4.2.10 BS -> PCF O R Correlation ID 4.2.11 BS -> PCF Oa C A8 Traffic ID 4.2.16 BS -> PCF O R PDSN Address 4.2.5 BS -> PCF Ob,c C IS-2000 Service Configuration Record 4.2.20 BS -> PCF Of R Service Option 4.2.8 BS -> PCF Oi R User Zone ID 4.2.6 BS -> PCF Og C Quality of Service Parameters 4.2.7 BS -> PCF Oh R Access Network Identifiers 4.2.19 BS -> PCF Oc,d C

7


the A9-AL Connected Ack message sent in response to this message. 9

b. This is the IP address for the A11 interface of the source PDSN. 10

c. This element shall be omitted if this message is sent as part of a fast handoff because the 11

corresponding A10 connection has already been established. Otherwise, this element shall be 12

included. 13

d. The Access Network Identifiers are those of the source PCF communicated by the source BS via the 14

MSC (Handoff Required, Handoff Requested messages), in 1x systems. 15

e. This information element is included if available to the BS. 16

f. The Bit-Exact Length - Octet Count field and the Bit-Exact Length - Fill Bits field of this IE shall set 17

to ‘0’, in HRPD messages. 18

g. The UZID field of this IE shall be set to ‘00H’ for padding, in HRPD messages. 19

h. The Non-Assured Mode Packet Priority field of this IE shall set to ‘0H’ for padding, in HRPD 20

messages. 21

i. In 1x systems, this element specifies the service option value of the PDSI to be re-activated. 22

The following table shows the bitmap layout for the A9-AL Connected message. 23

3.3.1 A9-AL (Air Link) Connected

7 6 5 4 3 2 1 0 Octet




C-37


7 6 5 4 3 2 1 0 Octet

Length = [08H] 2


(LSB) 4


(LSB) 6


8

9

(LSB) 10


Length = [04H] 2


4

5

(LSB) 6


Length = [0CH] 2



(LSB) 5


7

8

(LSB) 9



12

13

(LSB) 14


Length = [04H] 2


4

5

(LSB) 6


Bit-Exact Length – Octet Count = [00H to FFH]

2


C-38


7 6 5 4 3 2 1 0 Octet

Reserved = [0000 0]

Bit-Exact Length – Fill Bits = [000 to 111]

3

(MSB) 4

IS-2000 Service Configuration Record Content = <any value>

…



Sixth Fill Bit –

if needed = [0 (if






Third Fill Bit –

if needed = [0 (if


Second Fill Bit –

if needed = [0 (if




k



= [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;


(LSB) 3


Length = [02H] 2


(LSB) 4


Length = [01H] 2


3

⇒⇒⇒⇒Access Network Identifiers: A9 Element Identifier = [20H] 1

Length = [05H] 2 Reserved

= [0] (MSB) SID = <any value> 3

(LSB) 4

(MSB) NID = <any value> 5

(LSB) 6

PZID = <any value> 7

1

3.3.2 A9-AL (Air Link) Connected Ack 2


... 4


C-39

3.3.4 A9-AL Disconnected Ack 1


... 3

3.5 A9 Session Update Procedures 4

5

3.5.1 A9-Update-A8 6

This message is sent from the BS to the PCF to indicate a change to the session airlink parameters, 7

whether SDBs may be sent to an MS, whether an SDB was successfully delivered to an MS, or to indicate 8

an authentication failure. This message is also sent from the PCF to the BS to transfer new or updated 9

packet data session parameters to the BS. In HRPD systems, this message shall be used when performing 10

any additions, deletions, remappings, changes in granted QoS, and/or changes in flow state of IP flows, 11

provided no A8 connections are established and no existing A8 connections are released. 12



A9 Message Type 4.2.13 BS <-> PCF M Call Connection Reference 4.2.10 BS <-> PCF O R Correlation ID 4.2.11 BS <-> PCF Oa C Mobile Identity (IMSI) 4.2.2 BS <-> PCF Oi R Mobile Identity (ESN) 4.2.2 BS -> PCF Ob C IS-2000 Service Configuration Record 4.2.20 BS -> PCF Oc,j C Service Option 4.2.8 BS -> PCF Oc,j,o C User Zone ID 4.2.6 BS -> PCF Oc C Quality of Service Parameters 4.2.7 BS -> PCF Oc,j C Cause 4.2.3 BS <-> PCF O R RN-PDIT 4.2.24 BS <- PCF Od C SR_ID 4.2.4 BS <-> PCF Oe,n R Mobile Identity (MEID) 4.2.2 BS -> PCF Ob C A9 Indicators 4.2.17 BS <-> PCF Of C PDSN Address 4.2.5 PCF -> BS Og C Anchor PDSN Address 4.2.22 PCF -> BS Oh C Anchor P-P Address 4.2.12 PCF -> BS Oh C Forward QoS Information 4.2.33 BS -> PCF Ok C Reverse QoS Information 4.2.34 BS -> PCF Ok C Subscriber QoS Profile 4.2.35 PCF -> BS Ol,m C

13


the A9-Update-A8-Ack message sent in response to this message. 15





C-40

c. These elements are required when the message is sent from the BS to the PCF unless the message is 1

used to indicate Dormant Power down or Authentication Failure. 2

d. This element is included in the message when the PDSN has sent the parameter to the PCF. 3

e. This element specifies the SR_ID of the service instance in the Service Option element. 4

f. This element is included when used to indicate if the PDSI supports Short Data bursts. 5

g. This element contains the A11 IP address of the PDSN terminating the A10 connection. This element 6

is included when A10 connections were established with a new PDSN during an active packet data 7

session. 8

h. These IEs are included if this information is received from the PDSN. 9

i. This IE shall be set to the MN ID, retrieved from AN-AAA, in HRPD messages. 10

j. This information element shall not be included in HRPD messages. 11

k. The IS-2000 CON_REF field of this information element shall be set to 00H for padding, in HRPD 12

messages. 13

l. In HRPD systems, this IE shall include the IP flow-to-service connection mapping for all IP flows in 14

the specified direction (existing IP flows to keep as well as new IP flows to establish) associated with 15

the AT. IP flows to be released shall be omitted. Existing IP flows may be remapped to a different 16

A8 connection and may have a change in granted QoS. 17

m. This IE is included if this information is received from the PDSN. 18

n. In HRPD systems, this IE shall contain information for the main service connection. 19

o. In 1x systems, this element specifies the service option value of the PDSI to be re-activated. 20

21

The following table shows the bitmap layout for the A9-Update-A8 message. 22

3.5.1 A9-Update-A8

7 6 5 4 3 2 1 0 Octet

⇒⇒⇒⇒ A9 Message Type = [0EH] 1


Length = [08H] 2


(LSB) 4


(LSB) 6


8

9

(LSB) 10


Length = [04H] 2


4

5


C-41

3.5.1 A9-Update-A8

7 6 5 4 3 2 1 0 Octet

(LSB) 6





2


… …






Length = [05H] 2


= [0]


3


5

6

(LSB) 7


Bit-Exact Length – Octet Count = <variable> 2

Reserved = [0000 0]

Bit-Exact Length – Fill Bits = [000 – 111]

3

(MSB) IS-2000 Service Configuration Record Content = <any value> 4

… Seventh

Fill Bit – if needed = [0 (if


Sixth Fill Bit – if needed = [0 (if






Third Fill Bit


a fill bit)]



First Fill Bit


a fill bit)]

k



= [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;


(LSB) 3



C-42

3.5.1 A9-Update-A8

7 6 5 4 3 2 1 0 Octet

Length = [02H] 2


(LSB) 4


Length = [01H] 2


3


Length = [01H] 2

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), 7BH (Session parameter update)]

3

⇒⇒⇒⇒ RN-PDIT: A9 Element Identifier = [0FH] 1

Length = [01H] 2

RN-PDIT = [01H-FFH] 3


Length = [01H] 2

Reserved = [0000 0] IS-2000 SR_ID = [001 - 011] 3


Length = [08H] 2


‘0’


3









Length = [01H] 2


C-43

3.5.1 A9-Update-A8

7 6 5 4 3 2 1 0 Octet

QoS Mode = [0, 1]

(ignored)


[0,1] (ignored)


= [0,1] (ignored)

SDB/DOS Supported

= [0,1]

CCPD Mode =

[0,1] (Ignored)

Reserved = [0]

Data Ready

Indicator = [0,1]

(Ignored)

Handoff Indicator = [0,1]

(Ignored)

3


Length = [04H] 2


4

5

6


Length = [04H] 2


4

5

(LSB) 6


Length = [04H] 2

(MSB) Serving P-P IP Address = <any value> 3

4

5

(LSB) 6





Use IP Flow

Discrimi-nation =

[0,1]

DSCP Included

Reserved = [000] SR_ID = [1 - 7] j+1





k+1



… …


C-44

3.5.1 A9-Update-A8

7 6 5 4 3 2 1 0 Octet

(LSB) m Forward Granted QoS Length = [variable] m+1


… … (LSB) n







Reserved = [0 0000] SR_ID = [1 - 7] j+1


Reverse Flow Entry {Reverse Flow Count :



k+1



… … (LSB) m



… … (LSB) n



⇒⇒⇒⇒ Subscriber QoS Profile: A9 Element Identifier = [90H] 1



4

… …

(LSB) n

1

3.5.2 A9-Update-A8 Ack 2



C-45

... 1

3.6 A8/A9 Interface Data Delivery Messages 2

3

3.6.1 A9-Short Data Delivery 4

This message is sent from the BS to the PCF when a short data burst is received from an MS. It may be 5

sent from the PCF to the BS when a small amount of data is received for a dormant PDSI. 6



A9 Message Type 4.2.13 PCF <-> BS M Correlation ID 4.2.11 PCF -> BS Oa C Mobile Identity (IMSI) 4.2.2 PCF <-> BS O R Mobile Identity (ESN) 4.2.2 PCF <-> BS Ob C SR_ID 4.2.4 PCF <-> BS O R Data Count 4.2.18 PCF -> BS Oc C ADDS User Part 4.2.9 PCF <-> BS Od R A9 Indicators 4.2.17 PCF -> BS Oe C Mobile Identity (MEID) 4.2.2 PCF <-> BS Ob C Flow ID 4.2.36 PCF -> BS Of C

7

a. If this element is included, its value shall be returned in the corresponding element in the A9-Short 8

Data Ack message from the BS. 9




c. This element is included in this message when sent from the PCF to the BS and indicates the number 13

of additional bytes of data queued at the PCF and waiting to be sent to a specific MS. 14

d. This element contains the packet data received from the PDSN or an MS in a SDB format as specified 15

in [18]. 16

e. This information element is included when the PDSI is operating in CCPD Mode. 17

f. This information element is included when the PCF has the information available from the corres-18

ponding GRE packet received across the A10 interface. 19

20

The following table shows the bitmap layout for the A9-Short Data Delivery message. 21

3.6.1 A9-Short Data Delivery

7 6 5 4 3 2 1 0 Octet

⇒⇒⇒⇒ A9 Message Type = [0CH] 1

⇒⇒⇒⇒ Correlation ID: A8/A9 Element Identifier = [13H] 1

Length = [04H] 2



C-46


7 6 5 4 3 2 1 0 Octet

4

5

(LSB) 6




Type of Identity = [110] (IMSI) 3


… …






Length = [05H] 2


= [0]

Type of Identity = [101] (ESN) 3


5

6

(LSB) 7


Length = [01H] 2

Reserved = [0000 0] IS-2000 SR_ID = [001 - 011] 3

⇒⇒⇒⇒ Data Count: A9 Element Identifier = [09H] 1

Length = [02H] 2

Count = <any value> 3

… 4

⇒⇒⇒⇒ ADDS User Part: A9 Element Identifier = [3DH] 1


Reserved = [00] Data Burst Type = [00H (DOS), 06H (Short Data Burst)]

3


… …

(LSB) n



C-47


7 6 5 4 3 2 1 0 Octet

Length = [01H] 2

QoS Mode = [0, 1]

(ignored)


[0,1] (ignored)


= [0,1] (ignored)

SDB /DOSSupported

= [1]

CCPD Mode = [1]

(ignored)

Reserved = [0]

Data Ready Indicator = [0,1]

(ignored)

Handoff Indicator = [0, 1] (ignored)

3


Length = [08H] 2


‘0’


3








⇒⇒⇒⇒ Flow ID: A9 Element Identifier = [91H] 1

Length = [01H] 2

Flow ID = [00H-FFH] 3

1

2

3.6.2 A9-Short Data Ack 3

This message is sent from the BS to the PCF to acknowledge reception of the A9-Short Data Delivery 4

message and to indicate to the PCF whether the data was accepted for delivery to the MS. 5



A9 Message Type 4.2.13 BS -> PCF M Correlation ID 4.2.11 BS -> PCF Oa C Mobile Identity (IMSI) 4.2.2 BS -> PCF O R Mobile Identity (ESN) 4.2.2 BS -> PCF Ob C Cause 4.2.3 BS -> PCF Oc R Mobile Identity (MEID) 4.2.2 BS -> PCF Ob C

6

a. This element shall be included if it was included in the A9-Short Data Delivery message sent from the 7

PCF. This element shall be set to the value of the corresponding element received in that message. 8





C-48

c. If the BS rejects the SDB, it includes the cause value ‘16H’ (Initiate re-activation of packet data call). 1

If the BS agrees to deliver the SDB to the MS and sends this message before it attempts to deliver the 2

SDB, the BS includes the cause value ‘13H’ (Successful operation). 3

If the BS attempts to deliver the SDB before sending this message, it includes either cause value 4

‘17H’ (SBD successfully delivered) or cause value ‘18H’ (SDB couldn’t be delivered) depending on 5

the outcome of that attempt. 6

7

The following table shows the bitmap layout for the A9-Short Data Ack message. 8

3.6.2 A9-Short Data Ack

7 6 5 4 3 2 1 0 Octet

⇒⇒⇒⇒ A9 Message Type = [0DH] 1

⇒⇒⇒⇒ Correlation ID: A8/A9 Element Identifier = [13H] 1

Length = [04H] 2


4

5

(LSB) 6





2


… …






Length = [05H] 2


= [0]


3


5

6

(LSB) 7


Length = [01H] 2


C-49

3.6.2 A9-Short Data Ack

7 6 5 4 3 2 1 0 Octet

ext = [0] Cause Value = [13H (Successful operation), 16H (Initiate re-activation of packet data call) 17H (SDB successfully delivered) 18H (SDB couldn’t be delivered)]

3


Length = [08H] 2


‘0’


3








1

2

... 3

4.1.2 Information Element Identifiers 4

The following table contains a list of all information elements that make up the messages defined in 5

section 3.0. The table is sorted by the Information Element Identifier (IEI) coding which distinguishes one 6

information element from another. The table also includes a reference to the section where the element 7

coding can be found. 8

A listing of information elements, sorted by name, is included in Table 4.1.4-1, which also specifies the 9

messages in which each information element is used. 10

Table 4.1.2-1 A9 Information Element Identifiers Sorted by Identifier Value 11

Element Name Identifier Reference

CON_REF 01H 4.2.14 User Zone ID 02H 4.2.6 Service Option 03H 4.2.8 Cause 04H 4.2.3 A9 Indicators 05H 4.2.17 A9 Cell Identifier 06H 4.2.15 Quality of Service Parameters 07H 4.2.7 A8 Traffic ID 08H 4.2.16 Data Count 09H 4.2.18


C-50

Element Name Identifier Reference

Active Connection Time in Seconds 0AH 4.2.1 SR_ID 0BH 4.2.4 A9 PDSN Code 0CH 4.2.23 Mobile Identity 0DH 4.2.2 IS-2000 Service Configuration Record 0EH 4.2.20 RN-PDIT 0FH 4.2.24 Correlation ID 13H 4.2.11 PDSN Address 14H 4.2.5 Access Network Identifiers 20H 4.2.19 Anchor PDSN Address 30H 4.2.22 Software Version 31H 4.2.21 ADDS User Part 3DH 4.2.9 Call Connection Reference 3FH 4.2.10 Anchor P-P Address 40H 4.2.12 Service Instance Info 41H 4.2.25 Additional A8 Traffic ID 92H 4.2.32 Forward QoS Information 8EH 4.2.33 Reverse QoS Information 8FH 4.2.34 Subscriber QoS Profile 90H 4.2.35 Flow ID 91H 4.2.36

... 1

4.1.4 Cross Reference of Information Elements With Messages 2

The following table provides a cross reference between the elements defined in this specification and the 3

messages defined herein. 4

Table 4.1.4-1 Cross Reference of Information Elements with Messages


A8 Traffic ID 4.2.16 08H A9-Setup-A8 3.1.1 A9-AL Connected 3.3.1 A9-AL Disconnected 3.3.3 A9-Connect-A8 3.1.2 A9-Disconnect-A8 3.2.3 A9-Release-A8 3.2.4 A9 Cell Identifier 4.2.15 06H A9-Setup-A8 3.1.1 A9 Indicators 4.2.17 05H A9-Connect-A8A9-Setup-

A8 3.1.23.1.1

A9-Setup-A8 3.1.1 A9-Short Data Delivery 3.6.1 A9-Update-A8 3.5.1


C-51



A9 Message Type 4.2.13 None A9-Setup-A8 3.1.1 A9-AL Connected 3.3.1 A9-AL Connected Ack 3.3.2 A9-AL Disconnected 3.3.3 A9-AL Disconnected Ack 3.3.4 A9-BS Service Request 3.1.3 A9-BS Service Response 3.1.4 A9-Connect-A8 3.1.2 A9-Disconnect-A8 3.2.3 A9-Release-A8 3.2.1 A9-Release-A8 Complete 3.2.2 A9-Short Data Delivery 3.6.1 A9-Short Data Delivery Ack 3.6.2 A9-Update-A8 3.5.1 A9-Update-A8 Ack 3.5.2 A9-Version Info 3.4.1 A9-Version Info Ack 3.4.2

A9 PDSN Code 4.2.23 0CH A9-Disconnect-A8 3.2.3

A9-Release-A8 Complete 3.2.2 Access Network Identifier 4.2.19 20H A9-Setup-A8 3.1.1 A9-AL Connected 3.3.1 Active Connection Time in Seconds 4.2.1 0AH A9-Release-A8 3.2.1 Additional A8 Traffic ID 4.2.32 92H A9-Setup-A8 3.1.1 A9-Connect-A8 3.1.2 A9-Release-A8 3.2.1 ADDS User Part 4.2.9 3DH A9-Short Data Delivery 3.6.1 Anchor P-P Address 4.2.12 40H A9-Setup-A8 3.1.1 A9-Connect-A8 3.1.2 A9-AL Connected Ack 3.3.2 A9-Update-A8 3.5.1 Anchor PDSN Address 4.2.22 30H A9-Setup-A8 3.1.1 A9-Connect-A8 3.1.2 A9-AL Connected Ack 3.3.2 A9-Update-A8 3.5.1 Call Connection Reference 4.2.10 3FH A9-AL Connected 3.3.1 A9-AL Connected Ack 3.3.2 A9-AL Disconnected 3.3.3 A9-AL Disconnected Ack 3.3.4 A9-Connect-A8 3.1.2


C-52



A9-Disconnect-A8 3.2.3 A9-Setup-A8 3.1.1 A9-Release-A8 3.2.1 A9-Release-A8 Complete 3.2.2 A9-Update-A8 3.5.1 A9-Update-A8 Ack 3.5.2 Cause 4.2.3 04H A9-Connect-A8 3.1.2 A9-Disconnect-A8 3.2.3 A9-Release-A8 3.2.1 A9-Release-A8 Complete 3.2.2 A9-BS Service Response 3.1.4 A9-Short Data Ack 3.6.2 A9-Update-A8 3.5.1

A9-Update-A8 Ack 3.5.2 A9-Version Info 3.4.1

CON_REF 4.2.14 01H A9-Setup-A8 3.1.1 A9-Connect-A8 3.1.2 A9-Disconnect-A8 3.2.3 A9-Release-A8 3.2.1 Correlation ID 4.2.11 13H A9-AL Disconnected Ack 3.3.4 A9-Short Data Delivery 3.6.1 A9-Short Data Delivery Ack 3.6.2 A9-Setup-A8 3.1.1 A9-Connect-A8 3.1.2 A9-Disconnect-A8 3.2.3 A9-Release-A8 3.2.1 A9-Release-A8 Complete 3.2.2 Data Count 4.2.18 09H A9-BS Service Request 3.1.3 A9-Short Data Delivery 3.6.1

Flow ID 4.2.36 91H A9-Short Data Delivery 3.6.1

A9-Short Data Ack 3.6.2 Forward QoS Information 4.2.33 8EH A9-Setup-A8 3.1.1 A9-Release-A8 Complete 3.2.2 A9-Update-A8 3.5.1 IS-2000 Service Configuration Record 4.2.20 0EH A9-Setup-A8 3.1.1 A9-AL Connected 3.3.1 A9-Update-A8 3.5.1 Mobile Identity 4.2.2 0DH A9-Setup-A8 3.1.1 A9-Connect A8 3.1.2


C-53



A9-Disconnect-A8 3.2.3 A9-Release-A8 3.2.1 A9-BS Service Request 3.1.3 A9-Short Data Delivery 3.6.1 A9-Short Data Delivery Ack 3.6.2 A9-Update-A8 3.5.1 PDSN Address 4.2.5 14H A9-Setup-A8 3.1.1 A9-Connect-A8 3.1.2 A9-AL Connected 3.3.1 A9-AL Connected Ack 3.3.2 Subscriber QoS Profile 4.2.35 90H A9-Update-A8 3.5.1 Quality of Service Parameters 4.2.7 07H A9-Setup-A8 3.1.1 A9-AL Connected 3.3.1 A9-Update-A8 3.5.1 Reverse QoS Information 4.2.34 8FH A9-Setup-A8 3.1.1 A9-Release-A8 Complete 3.2.2 A9-Update-A8 3.5.1 RN-PDIT 4.2.24 0FH A9-Update-A8 3.5.1 Service Instance Info 4.2.25 41H A9-Connect-A8 3.1.2 Service Option 4.2.8 03H A9-BS Service Request 3.1.3 A9-Setup-A8 3.1.1 A9-AL Connected 3.3.1 A9-Update-A8 3.5.1 Software Version 4.2.21 31H A9-Version Info 3.4.1 A9-Version Info Ack 3.4.2 SR_ID 4.2.4 0BH A9-Setup-A8 3.1.1

A9-Connect-A8 3.1.2

A9-Disconnect-A8 3.2.3

A9-Release-A8 3.2.1

A9-Release-A8 Complete 3.2.2

A9-BS Service Request 3.1.3

A9-BS Service Response 3.1.4

A9-Short Data Delivery 3.6.1 A9-Update-A8 3.5.1 User Zone ID 4.2.6 02H A9-Setup-A8 3.1.1 A9-AL Connected 3.3.1 A9-Update-A8 3.5.1

1


C-54

... 1

4.2.3 Cause 2

This element is used to indicate the reason for occurrence of a particular event and is coded as shown 3

below. 4

4.2.3 Cause

7 6 5 4 3 2 1 0 Octet


Length 2

0/1 Cause Value 3


Cause Value: This field is a single octet field if the extension bit (bit 7) is set to ‘0’. If bit 7 of octet 3 is 6

set to ‘1’ then the cause value is a two octet field. If the value of the first octet of the 7

cause field is ‘1XXX 0000’ then the second octet is reserved for national applications, 8

where ‘XXX’ indicates the Cause Class as indicated in the table below. 9

Table 4.2.3-1 Cause Class 10

Binary Values Meaning

000 Normal event 001 Normal event 010 Resource unavailable 011 Service or option not available 100 Service or option not implemented 101 Invalid message (e.g., parameter out of range) 110 Protocol error 111 Interworking

11

Table 4.2.3-2 Cause Values 12

6 5 4 3 2 1 0 Hex Value Cause

Normal Event Class (000 xxxx and 001 xxxx) 0 0 0 0 0 0 1 01 Partial connection release 0 0 0 0 1 1 1 07 OAM&P intervention 0 0 0 1 0 0 0 08 MS busy 0 0 0 1 0 1 1 0B Handoff successful 0 0 0 1 1 1 1 0F Packet data session release 0 0 1 0 0 0 0 10 Packet call going dormant 0 0 1 0 0 0 1 11 Service option not available 0 0 1 0 0 1 1 13 Successful operation 0 0 1 0 1 0 0 14 Normal call release 0 0 1 0 1 1 0 16 Initiate re-activation of packet data call 0 0 1 0 1 1 1 17 SDB successfully delivered 0 0 1 1 0 0 0 18 SDB couldn’t be delivered 0 0 1 1 0 0 1 19 Power down from dormant state 0 0 1 1 0 1 0 1A Authentication failure 0 0 1 1 0 1 1 1B Capability update


C-55

6 5 4 3 2 1 0 Hex Value Cause 0 0 1 1 1 0 0 1C Update Accounting: late traffic channel setup 0 0 1 1 1 0 1 1D Hard handoff failure 0 0 1 1 1 1 0 1E Update Accounting: parameter change 0 0 1 1 1 1 1 1F Air link lost 0 1 0 1 0 1 0 2A PCF resources are not available

Resource Unavailable Class (010 xxxx) 0 1 0 0 0 0 0 20 Equipment failure

Service or Option Not Available Class (011 xxxx) 0 1 1 0 1 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) 1 1 0 0 0 0 0 60 State mismatch

Interworking (111 xxxx) 1 1 1 1 0 0 1 79 PDSN resources are not available 1 1 1 1 0 1 0 7A Data ready to send 1 1 1 1 0 1 1 7B Session parameter update

All other values Reserved for future use.

... 1

4.2.8 Service Option 2

This element indicates the service option requested by the MS, or by the network. It is coded as follows: 3

7 6 5 4 3 2 1 0 Octet



(LSB) 3

4

The service options supported are given in Table 4.2.8-1. 5

Table 4.2.8-1 Service Option Values 6


Description

0021H 3G High Speed Packet Data 003BH HRPD Main Service Connection 003CH Link Layer Assisted Header Removal 003DH Link-Layer Assisted Robust Header Compression (LLA-ROHC) 0040H HRPD Auxiliary Service Connection

7

4.2.9 ADDS User Part 8

This element contains the application data message. 9

4.2.9 ADDS User Part


C-56

7 6 5 4 3 2 1 0 Octet


Length 2

Reserved Data Burst Type 3

Application Data Message 4-n

The Length field is defined as the number of octets following the Length field and has a value greater 1

than zero. 2

The Data Burst Type field is coded as follows: 3

For CDMA Short Data Burst: the 6-bit Data Burst Type defined in [18] is contained in bits 5 through 0, 4

with bits 6 and 7 set to zero. 5

For HRPD DOS, this field is not used and set to zero. 6

The Application Data Message field has variable length and is encoded as follows: 7

For Short Data Burst, the Application Data Message is the SDB as specified in [18]. 8

For HRPD DOS, the Application Data Message is a complete higher layer packet and encoded as 9

specified in [10]. 10

... 11

4.2.17 A9 Indicators 12

This information element indicates properties of the A8 connection and of the MS. 13

4.2.17 A9 Indicators

7 6 5 4 3 2 1 0 Octet


Length 2

QoS ModeRes

erved



SDB/DOS Supported

CCPD Mode

Reserved Data Ready

Indicator

Handoff Indicator

3

Length: This field indicates the number of octets in this element following the 14

Length field. 15

Handoff Indicator: This field indicates whether or not a handoff was performed. Refer to 16

[13]. When this IE is included in the A9-Setup-A8 message, the 17

following conditions hold: 18

• The field is set to ‘0’ to indicate normal call setup 19

• The field is set to ‘1’ to indicate that a hard handoff is to be 20

performed, and that is not necessary to establish the A10 connection 21

immediately 22

• The field is set to ‘0’ for dormant handoffs 23

• The field is set to ‘0’ for fast handoffs, because an A10 connection 24

needs to be set up immediately 25

When this IE is included in the A9-Short Data Delivery message, this 26

field is ignored. 27


C-57

When this IE is included in the A9-Update-A8 message, this field is 1

ignored. 2

Data Ready Indicator: This field indicates whether there is data ready to be sent from the MS to 3

the network. It reflects the value of the DRS bit of the air interface. If 4

this field is set to ‘0’, it indicates that data is not ready to be sent and the 5

A9-Setup-A8 message is reporting a mobility event. Otherwise (set to 6

‘1’) it indicates that data is ready to be sent. 7

CCPD Mode: This field indicates that an MS has requested CCPD Mode. The PCF is 8

not required to allocate an A8 connection when this bit is set. Any 9

signaling or data exchanged between the PCF and BS is sent over the A9 10

signaling channel. 11

SDB/DOS Supported: This field indicates if Short Data Bursts can be sent for the PDSI. For 12

HRPD, this field indicates whether Data Over Signaling messages can be 13

sent for the connection. 14

Table 4.2.17-1 A9 Indicators – SDB/DOS Supported 15

Values Meaning

0 Short Data Bursts/Data Over Signaling not supported for the PDSI/connection

1 Short Data Bursts/Data Over Signaling supported for the PDSI/connection

GRE Segmentation Supported: This field is set to ‘1’ if the AN is capable of receiving the GRE 16

segmentation attribute in the GRE header for the corresponding A8 17

connection, for packets fragmented over one or more GRE frames. 18

Packet Boundary Supported: This field is set to ‘1’ if the PCF guarantees IP packet boundaries. The 19

PCF guarantees packet boundaries either by encapsulating one packet in 20

one GRE frame or by supplying GRE segmentation indication in the 21

GRE frame (if supported by the AN) for the corresponding A8 22

connection. 23

QoS Mode: This field indicates whether the IP flow based QoS is available over the 24

air for the current personality of the AT. 25

Table 4.2.17-2 QoS Mode Values 26

QoS Mode Description

0 The air interface protocol currently in use does not support IP flow based QoS.

1 The air interface protocol currently in use supports IP flow based QoS.

27

... 28

29


C-58

4.2.32 Additional A8 Traffic ID 1

This information element identifies the connection used by the MS/AT for packet data service. 2

4.2.32 Additional A8 Traffic ID

7 6 5 4 3 2 1 0 Octet


Length 2

A8 Traffic ID Entry 1 variable

A8 Traffic ID Entry 2 variable

… …

A8 Traffic ID Entry n variable


Length field. 4

A8 Traffic ID Entry: This field contains A8 Traffic ID for auxiliary service instance. This field 5

is coded as follows. 6

7 6 5 4 3 2 1 0 Octet

Entry Length 1

SR_ID = [00H-1FH] 2


(LSB) 4

A8 transport protocol stack 5

(MSB) Protocol Type 6

(LSB) 7

(MSB) Key 8

9

10

(LSB) 11

Address Type 12

(MSB) IP Address 13

… …

(LSB) k

Entry Length: This field contains the number of octets in this entry following the Entry 7

Length field as a binary number. 8

SR_ID: This field identifies the service connection associated with the A8 9

connection. 10

11


C-59

Service Option: This field indicates the service option for the A8 connection associated 1

with the value in the SR_ID field. 2

Table 4.2.32-1 Additional A8 Traffic ID - Service Option Values 3


Description

00 40H HRPD Auxiliary Service Connection

A8 transport protocol stack: This field is used to identify the A8 transport protocol stack to be used 4

for the A8 connection. 5

Table 4.2.32-2 Additional A8 Traffic ID - A8 Transport Protocol Stack 6

Values Meaning

01H GRE/IP All Others Reserved

Protocol Type: This field is used to indicate the protocol type to be tunneled across the 7

A8 interface, and contains the same value that is used in the Protocol 8

Type field in the GRE header on the associated A8 connection. This field 9

is set to 0x88 81H (Unstructured Byte Stream). 10

Key: This is a four octet field. This field is used to indicate the A8 connection 11

identification, and contains the same value that is used in the Key field in 12

the GRE header on the associated A8 connection. 13

Address Type: This field indicates the type and format of the IP Address that follows. 14

15

Table 4.2.32-3 A8 Traffic ID - Address Type 16

Value Address Type Length of IP Address

01H Internet Protocol IPv4 4 octets 02H Internet Protocol IPv6 variable

All other values reserved

17

IP Address: This field has a variable length that is dependent on the Type field. This 18

field is used to indicate the IP address of the A8 bearer port on the 19

sending entity. That is, when the BS sends the A9-Setup-A8 message 20

containing this element, this field contains the IP address at the BS where 21

the A8 user traffic connection terminates. 22

4.2.33 Forward QoS Information 23

This information element provides mappings of forward IP flow(s) to service connection. 24

4.2.33 Forward QoS Information

7 6 5 4 3 2 1 0 Octet


Length 2

Forward QoS Information Entry 1 variable

Forward QoS Information Entry 2 variable


C-60

4.2.33 Forward QoS Information

7 6 5 4 3 2 1 0 Octet

… …

Forward QoS Information Entry n variable

Length: This field indicates the number of octets in this element 1

following the Length field. 2

Forward QoS Information Entry: Each Forward QoS Information Entry specifies all of the forward 3



7 6 5 4 3 2 1 0 Octet

Entry Length 1

SR_ID = [00H-1FH] 2

Use IP Flow

Discrimi-nation =

[0,1]

DSCP Included

Reserved = [0 0000] 3


Forward Flow Entry 1 variable

Forward Flow Entry 2 variable

… …

Forward Flow Entry n variable

Entry Length: This field contains the number of octets in this entry following 6


SR_ID: This field identifies the service connection. 8

DSCP Included: This field indicates whether DSCP values are included in this 9

element. If option 2c in section 2.6.2 of [12] is used, then the 10

value shall be set to ‘1’. Otherwise, the value shall be set to ‘0’ 11

and all DSCP fields in this element shall be ignored. 12

Use IP Flow Discrimination: This field indicates if the PCF shall include GRE extension for 13

IP flow discrimination. If this field is set to '0', the PCF shall not 14

include the GRE extension for IP flow discrimination in the 15

bearer packets for the A8 connection identified in the SR_ID 16

field of this Forward Flow Entry. Otherwise (set to '1') it 17

indicates that the Flow ID shall be included. 18

Forward Flow Count: This field indicates the number of Forward Flow Entry contained 19

in this Forward QoS Information Entry. 20

Forward Flow Entry i: This set of fields contains the forward flow IDs associated with 21


Forward Flow Entry is coded as follows. 23

7 6 5 4 3 2 1 0 Octet

Entry Length 1

Forward Flow ID i 2


C-61

7 6 5 4 3 2 1 0 Octet

Reserved DSCP Flow State 3 Forward Requested QoS Length i 4

(MSB) Forward Requested QoS i 5

… … (LSB) n

Forward Granted QoS Length i n+1

(MSB) Forward Granted QoS i n+2

… … (LSB) p



Forward Flow ID i: This field contains the flow ID of a given forward flow. Refer to 3

[8] for detailed information. 4

Flow State: This field indicates the IP flow state of the flow identified in the 5

Forward Flow ID i field. This field is set to '0' if it is deactivated. 6

This field is set to '1' if it is activated. 7

DSCP: If DSCP Included = ‘1’, then this field contains the DSCP value 8

of the flow identified in the corresponding Forward Flow ID 9

field. Otherwise, this field shall be set to ‘00 0000’ and shall be 10

ignored. 11

Forward Requested QoS Length i: This field indicates the number of octets in the Forward 12

Requested QoS i field. 13

Forward Requested QoS i: For HRPD systems, this field contains the requested QoS Sub 14

Blob for this flow received from the AT. The format is as 15


Forward Granted QoS Length i: This field indicates the number of octets in the Forward Granted 17

QoS i field. 18

Forward Granted QoS i: For HRPD systems, this field contains the granted QoS Sub Blob 19

for this flow. The format is as specified in [8]. 20

21

4.2.34 Reverse QoS Information 22

This information element provides mappings of reverse IP flow(s) to service connection. 23

4.2.34 Reverse QoS Information

7 6 5 4 3 2 1 0 Octet


Length 2

3

Reverse QoS Information Entry 1 variable

Reverse QoS Information Entry 2 variable

… …


C-62

4.2.34 Reverse QoS Information

7 6 5 4 3 2 1 0 Octet

Reverse QoS Information Entry n variable

Length: This field indicates the number of octets in this element 1

following the Length field. 2

Reverse QoS Information Entry: Each Reverse QoS Information Entry specifies all of the reverse 3



7 6 5 4 3 2 1 0 Octet

Entry Length 1

SR_ID = [00H-1FH] 2


Reverse Flow Entry 1 variable

Reverse Flow Entry 2 variable

… …

Reverse Flow Entry n variable






Reverse Flow Count: This field indicates the number of Reverse Flow Entry contained 11

in this Reverse QoS Information Entry. 12

Reverse Flow Entry i: This set of fields contains the reverse flow IDs associated with 13


Reverse Flow Entry is coded as follows. 15

16

7 6 5 4 3 2 1 0 Octet

Entry Length 1

Reverse Flow ID i 2

Reserved Flow State 3 Reverse Requested QoS Length i 4

(MSB) Reverse Requested QoS i 5

… … (LSB) n

Reverse Granted QoS Length i n+1

(MSB) Reverse Granted QoS i n+2

… … (LSB) p


C-63



Reverse Flow ID i: This field contains the flow ID of a given reverse IP flow. Refer 3


Flow State This field indicates the IP flow state of the flow identified in the 5

Reverse Flow ID i field. This field is set to '0' if it is deactivated. 6

This field is set to '1' if it is activated. 7

Reverse Requested QoS Length i: This field indicates the number of octets in the Reverse 8

Requested QoS i field. 9

Reverse Requested QoS i: For HRPD systems, this field contains the requested QoS Sub 10



Reverse Granted QoS Length i: This field indicates the number of octets in the Reverse Granted 13

QoS i field. 14

Reverse Granted QoS i: For HRPD systems, this field contains the granted QoS Sub Blob 15


4.2.35 Subscriber QoS Profile 17

This information element following the Length field. 18

Subscriber QoS Profile: This field contains Subscriber QoS Profile. Refer to [8] for detailed 19

information. 20

21

4.2.36 Flow ID 22

This information element is used to identify an individual IP Flow. 23

24

4.2.36 Flow ID

7 6 5 4 3 2 1 0 Octet


Length 2

Flow ID 3


Flow ID: This field identifies an individual IP Flow. 26

27

28

29

30


D-1

Annex D A10-A11 (AN/PCF - PDSN) Interface Change Text (Normative) 1

Note: Annex D, contains specific A11 messaging text from [17] with all HRPD related changes identified 2



... 5

6

1.2 References 7

... 8

1.2.1 TIA/EIA 9

[10] TIA-856-A-1, cdma2000 High Rate Packet Data Air Interface Specification, June 2005. 10

11

1.2.2 3GPP2 12

[10] C.S0024-A v2.0, cdma2000 High Rate Packet Data Air Interface Specification, June 2005. 13

14

... 15

16

2.0 Message Procedures 17

This section describes message procedures for the A10/A11 interface. In the following sections, the term 18

“valid” is used for messages that pass authentication and whose Identification information element is 19

valid (refer to section 4.2.7). 20

2.1 A10 Connection Establishment, Refresh and Release Procedures 21

This section describes message procedures to establish, refresh or release an A10 connection. The release 22

of an A10 connection is controlled by the PCF. For PDSN initiated A10 connection release, the PDSN 23

requests that the PCF release the connection. 24

2.1.1 A11-Registration Request 25

This message is sent from the PCF to the PDSN to initiate establishment, refresh or release of an A10 26

connection. In addition, accounting information pertaining to an A10 connection may be included in any 27

A11-Registration Request message for that connection. Refer to section 2.3 for further details. 28

2.1.1.1 Successful Establishment Operation 29

When the PCF receives an A9-Setup-A8 message from a BS, the PCF shall initiate setup of an A10 30

connection as indicated below unless it has an existing A10 connection for the identified user and SR_ID. 31

• If the A9-Setup-A8 message does not contain a handoff indication, then the PCF shall initiate setup of 32

the A10 connection upon receiving the A9-Setup-A8 message. 33


D-2

• In a fast handoff situation, the (target) PCF shall initiate setup of the A10 connection upon receiving 1

the A9-Setup-A8 message. 2

• In all other handoff situations, the (target) PCF shall initiate setup of the A10 connection when the 3

(target) BS captures the MS (i.e., upon receiving an A9-AL Connected message from the BS). 4

The PCF initiates setup of an A10 connection by sending an A11-Registration Request message to the 5

selected PDSN (refer to “PDSN Selection Algorithm” in [13]) with a non-zero Lifetime value. After 6

sending this message, the PCF shall start timer Tregreq. The A11-Registration Request message is 7

structured as specified in section 3.1. 8

If the connection setup request is accepted, the PDSN creates a binding record for the A10 connection by 9

creating an association between the PDSN Session Identifier (PDSN SID) and the MN ID IMSI, the MN 10

Session Reference ID and PCF Addresses. In the case of HRPD, the MN-SR_ID is not received from the 11

AT during origination and the AN/PCF shall set this to the default value of 1. If both the PCF and the 12

PDSN support a Session Identifier Version higher than ‘0’, the PDSN may choose any PDSN SID, 13

otherwise the PDSN SID shall be identical to the PCF Session Identifier (PCF SID). In the case of 14

multiple A10 connections for an MS, each A10 connection has its own binding record and Lifetime timer. 15

When the A10/A11 interface is used between an HRPD AN/PCF and a PDSN, the MN ID that is used by 16

the AN and the PCF on A8/A9 and A10/A11 messages is determined as follows: 17

• If the HRPD AN uses the access authentication feature, the MN ID field shall be set to the MN ID 18

value returned by the AN-AAA (e.g., IMSI) following successful access authentication. 19

• Otherwise, the AN/PCF shall set the MN ID field to a value that conforms to a valid MN ID format 20

(e.g., IMSI format). In this case, the MN ID is determined by other means. 21

The PCF and the PDSN shall use the PCF IP Address (sent in the A11-Registration Request message) and 22

the PDSN IP Address (returned in the A11-Registration Reply message) as the A10 connection endpoints 23

for the transport of user traffic. The PCF IP Address and the PDSN IP Address form the unique link layer 24

ID for each A10 connection. The PCF and the PDSN maintain an association of the MS’s IMSI address 25

MN ID and MN Session Reference ID with the A10 connection. 26

When establishing a new A10 connection, the PCF shall include the ANID NVSE with the Current 27

Access Network Identifiers (CANID) as specified in [13]. If the PCF received the ANID from the BS, it 28

shall populate it in the PANID field of the ANID NVSE sent in the A11-Registration Request message. 29

In HRPD systems, when establishing auxiliary A10 connection(s), the PCF shall include information for 30

all A10 connection(s) of the AT (including IP flow mapping information) in the A11-Registration 31

Request message. The PCF may specify that the PDSN shall include the GRE extension for IP flow 32

discrimination in all bearer packets for a given forward A10 connection. The A10 connection with SR_ID 33

1 is defined to be the main A10 connection. At a minimum, forward and reverse Flow IDs 0xFF are 34

mapped to the main A10 connection. 35

If the PCF is able to determine that the setup of the A10 connection is due to a dormant handoff or an 36

inter-PCF hard handoff (e.g., the A9-Setup-A8 message included the Access Network Identifiers (ANID) 37

IE or the Data Ready Indicator field in the A9 Indicators IE was set to ‘0’), the PCF shall include the 38

Mobility Event Indicator (MEI) CVSE in the A11-Registration Request message. The PCF may provide 39

the PDSN with an indication of PCF enabled features for the A10 connection (e.g. short data indication). 40

In a fast handoff, the (target) PCF shall set the flag bit S to ‘1’, include the Anchor P-P Address and set 41

the Lifetime value to Tpresetup in the A11-Registration Request message. In other cases the PCF shall set 42

the Lifetime to Trp. 43

In HRPD systems, the QoS Mode Session Parameter shall be included in an NVSE when this message is 44

sent for setting up the main A10 connection, to indicate QoS mode. If the PDSN does not receive the QoS 45

Mode, then the PDSN shall assume the QoS Mode is set to ‘0’. 46

47


D-3

2.1.1.2 Successful Refresh Operation 1

All A11-Registration Request messages with a non-zero Lifetime value sent for an existing A10 2

connection have the effect of requesting a refresh of that A10 connection. When sending an A11-3

Registration Request message for an already existing A10 connection, the PCF shall use the same Key 4

value (refer to the Session Specific Extension in section 4.2.12). 5

• If the A9-Setup-A8 message does not contain a handoff indication, then the PCF shall send an A11-6

Registration Request message to the PDSN upon receiving the A9-Setup-A8 message. 7

• In a fast handoff, the (target) PCF shall send an A11-Registration Request message to the PDSN upon 8

receiving the A9-Setup-A8 message. 9

• In all other handoff situations, the (target) PCF shall send an A11-Registration Request message to 10

the PDSN to initiate setup of the A10 connection when the (target) BS captures the MS (i.e., upon 11

receiving an A9-AL Connected message from the BS). 12

If the PCF is able to determine that an inter-PCF hard handoff has occurred (e.g., the A9-Setup-A8 13

message included the Access Network Identifiers (ANID) IE or the Data Ready Indicator field in the A9 14

Indicators IE is set to ‘0’), the PCF shall include the MEI CVSE and the ANID NVSE in the A11-15

Registration Request message. 16

In a fast handoff case the Lifetime value shall be set to Tpresetup; in all other cases the Lifetime value 17

shall be set to Trp. 18

If the PCF set the Lifetime value to Tpresetup in the A11-Registration Request message (i.e., in the case 19

of a fast handoff), then the PCF shall not refresh the A10 connection unless it is notified that the MS has 20

successfully accessed the target BS. At that time, the PCF refreshes the A10 connection with the PDSN 21

by sending an A11-Registration Request message with Lifetime value set to Trp. 22

If the PCF set the Lifetime value to Trp, then the PCF periodically refreshes the A10 connection with the 23

PDSN by sending an A11-Registration Request message with a non-zero Lifetime value before the A10 24

connection registration Lifetime timer expires. After sending this message, the PCF shall start timer 25

Tregreq. 26

In HRPD systems, the PCF shall include information for all A10 connections of the AT in the A11-27

Registration Request message for refresh operation. 28

2.1.1.3 Successful Release Operation 29

The PCF may initiate release of the A10 connection by sending an A11-Registration Request message to 30

the PDSN with Lifetime field set to zero. The PCF shall include accounting related and other information 31

in the A11-Registration Request message. After receiving this message, the PDSN shall remove the 32

binding record for the A10 connection and save the accounting related and other information for further 33

processing. The PDSN shall send an A11-Registration Reply message to the PCF with the Lifetime 34

parameter set to ‘0’; refer to section 2.1.2.3. 35

In HRPD systems, the PCF sends an A11-Registration Request message to the PDSN with the Lifetime 36

value set to zero when the PCF releases all A10 connections for the AT. 37

In HRPD systems, the PCF sends an A11-Registration Request message to release A10 connections that 38

are no longer to be used. The message includes a non-zero Lifetime value and Additional Session 39

Information for the A10 connections that are to be used after the release procedure. Information on A10 40

connections to be released shall not be included in the A11-Registration Request message. 41

Release of the main A10 connection results in the release of all A10 connections for the HRPD session. If 42

the PCF sends an A11-Registration Request message to release the main A10 connection, an NVSE 43

containing the Additional Session Information Application Type is not included in the message. 44


D-4


Failure detection at the PDSN: If the A11-Registration Request message is invalid, the PDSN shall send 2

an A11-Registration Reply message indicating authentication failure (Code value 83H) or identification 3

mismatch (Code value 85H) and shall then discard the A11-Registration Request message; refer to section 4

2.1.2. If the PDSN indicates identification mismatch (Code value 85H) in the A11-Registration Reply 5

message, the PDSN shall also include its own time in the 32 high-order bits of the Identification 6

information element of this message to allow the PCF to avoid identification mismatch for subsequent 7

A11-Registration Request messages. 8

If the Lifetime timer for an A10 connection expires before the PDSN has received a valid A11-9

Registration Request message from the PCF, then the PDSN shall delete the binding record for the A10 10

connection. 11

Failure detection at the PCF: If the PCF does not receive a valid A11-Registration Reply message from 12

the PDSN before timer Tregreq expires, the PCF may retransmit the A11-Registration Request message 13

with a new timestamp in the Identification information element and restart timer Tregreq. A connection 14

establishment or refresh is considered to have failed if no valid A11-Registration Reply message is 15

received after a configurable number of A11-Registration Request message retransmissions. For a 16

connection refresh or release, on failure to receive a valid A11-Registration Reply message in response to 17

a configurable number of A11-Registration Request message retransmissions, the PCF removes the 18

binding record for the A10 connection. 19

2.1.2 A11-Registration Reply 20

The PDSN sends this message to the PCF to acknowledge receipt of an A11-Registration Request 21

message. 22

2.1.2.1 Successful Establishment Operation 23

Upon receipt of an A11-Registration Request message with a nonzero Lifetime value, the PDSN shall 24

respond with an A11-Registration Reply message containing the appropriate value in the Code IE. For a 25

valid A11-Registration Request message, if the PDSN accepts establishment of the A10 connection, it 26

shall send a Registration Accepted indication (Code value 00H) and a non-zero Lifetime parameter value 27

in the message. The value of the Lifetime parameter in the A11-Registration Reply message shall be less 28

or equal to the value of the Lifetime parameter received in the A11-Registration Request message. Upon 29

receiving the A11-Registration Reply message, the PCF shall perform authentication and identification 30

checks. After the message passes the checks, the PCF shall stop timer Tregreq and start the Lifetime timer 31

initialized to the value of the returned Lifetime parameter. 32

In HRPD systems, if the A11-Registration Reply message establishes the main A10 connection, then the 33

PDSN includes the subscriber QoS profile, if applicable (e.g., during dormant handoff). 34

In HRPD systems, when the PDSN receives an A11-Registration Request message including Additional 35

Session Information with a non-zero Lifetime value, the PDSN establishes the corresponding A10 36

connection(s) that do not already exist with that PCF. 37

If the PDSN has data to send to the PCF when it receives an A11-Registration Request message, the 38

PDSN shall include a Data Available Indication as a CVSE in the A11-Registration Reply message. 39

If the PDSN accepts a fast handoff request, the A11-Registration Reply message shall include an NVSE 40

containing the Anchor P-P Address value copied from the corresponding A11-Registration Request 41

message. If the PDSN supports fast handoff and becomes the anchor PDSN, the PDSN shall include its 42

Anchor P-P Address in an NVSE in the A11-Registration Reply message. 43

If the selected PDSN does not accept establishment of the A10 connection, it shall return an A11-44

Registration Reply message with a reject result code in the Code IE. Upon receipt of this message, the 45

PCF shall stop timer Tregreq. 46


D-5

The PDSN may return an A11-Registration Reply message with result code ‘88H’ (Registration Denied – 1

unknown PDSN address). When code ‘88H’ is used, an alternate PDSN address is included in the A11-2

Registration Reply message. The address of the alternate proposed PDSN shall be returned in the Home 3

Agent field of the A11-Registration Reply message. Upon receipt of this message, the PCF shall stop 4

timer Tregreq. 5

On receipt of an A11-Registration Reply message with code ‘88H’, the PCF shall either initiate 6

establishment of the A10 connection with the proposed PDSN by sending a new A11-Registration 7

Request message as indicated in this section, or it shall use internal algorithms to select a new PDSN. 8

If the PCF receives a valid A11-Registration Reply message before timer Tregreq expires that indicates 9

identification mismatch (Code value 85H), the PCF may adjust the clock that it uses for communication 10

with the PDSN, retransmit the A11-Registration Request message with a newly generated Identification 11

IE, and restart timer Tregreq. 12

On receipt of a valid A11-Registration Reply message with another result code, depending on the result 13

code, the PCF may attempt to re-try setting up the A10 connection with the same or another PDSN; refer 14

to “PDSN Selection Algorithm” in [13]. 15

The PDSN may provide the PCF with an indication of PDSN enabled features for the A10 connection 16

(e.g. flow control). 17

2.1.2.2 Successful Refresh Operation 18

Upon receipt of a valid A11-Registration Request message with a nonzero Lifetime value, the PDSN shall 19

respond with an A11-Registration Reply message with an accept indication (Code value 00H), including a 20

Lifetime parameter value less or equal to the value of the received Lifetime parameter and restart the 21

Lifetime timer initialized to the value of the returned Lifetime parameter. Upon receipt of this message, 22

the PCF shall stop timer Tregreq and start the Lifetime timer initialized to the value of the returned 23

Lifetime parameter. 24




IE and restart timer Tregreq. 28

On receipt of a valid A11-Registration Reply message that contains a Code other than “Registration 29

accept” (00H) or “Identification mismatch” (85H), the PCF may resend the message with a newly 30

generated Identification IE based on the clock it uses for communication with the PDSN; otherwise the 31

PCF shall initiate release of the A10 connections to this PDSN. 32

2.1.2.3 Successful Release Operation 33

Upon receipt of a valid A11-Registration Request message with Lifetime field set to zero, the PDSN shall 34

respond with an A11-Registration Reply message with an accept indication. Upon receipt of this message, 35

the PCF shall remove the binding record for the A10 connection and stops timer Tregreq. 36

In HRPD systems, upon receipt of a valid A11-Registration Request message with the Lifetime value set 37

to zero, the PDSN shall release all A10 connections for the AT. 38

In HRPD systems, when the PDSN receives an A11-Registration Request message including Additional 39

Session Information with a non-zero Lifetime value, the PDSN releases the A10 connections that are not 40

referred to in the Additional Session Information. 41




IE and restart timer Tregreq. 45


D-6

On receipt of a valid A11-Registration Reply message that contains a Code other than “Registration 1

accept” (00H) or “Identification mismatch” (85H), the PCF may resend the message with a newly 2

generated Identification IE based on the clock it uses for communication with the PDSN; otherwise the 3

PCF shall initiate release of the A10 connections to this PDSN. 4


Failure detection at the PCF: If the A11-Registration Reply message is invalid, the PCF shall discard the 6

message. 7

Failure detection at the PDSN: None. 8

2.1.3 A11-Registration Update 9

In a 1x system, the PDSN sends this message to the PCF to initiate release of an A10 connection. In an 10

HRPD system, the PDSN sends this message to release all A10 connections associated with an AT. 11


The PDSN may send an A11-Registration Update message to the PCF to inititiate release of one A10 13

connection in a 1x system or all A10 connections associated with an AT in an HRPD system. The Home 14

Agent field in the A11-Registration Update message is the PDSN Address and the Home Address is set to 15

zero. The PCF Session Identifier and other session specific information are sent within the Session 16

Specific extension. After sending this message, the PDSN starts timer Tregupd. 17


Failure detection at the PCF: If the A11-Registration Update message is invalid, the PCF shall keep the 19

binding for the A10 connection(s) and shall not update its Lifetime timer. The PCF shall send an A11-20

Registration Acknowledge message indicating identification mismatch (Status value 85H) or 21

authentication failure (Status value 83H); refer to section 2.1.4. 22

Failure detection at the PDSN: If the PDSN does not receive a valid A11-Registration Acknowledge 23

message or an A11-Registration Request message (with the Lifetime parameter set to ‘0’ and accounting 24

related information included) before timer Tregupd expires, the PDSN may retransmit the A11-25

Registration Update message with a new timestamp in the Identification information element and restart 26

timer Tregreq a configurable number of times. 27

If the PDSN has not received a valid A11-Registration Acknowledge message with an update accepted 28

status indication (Status value 00H) or an A11-Registration Request message (with Lifetime parameter set 29

to ‘0’ and accounting related information included) after a configurable number of retransmissions, the 30

PDSN shall remove the binding record for the A10 connection. 31


2.1.4 A11-Registration Acknowledge 33


2.2 A10-Connection Update Procedures 35

The PDSN initiates the update of new or additional packet data session parameters on an existing A10 36

connection with the messages described in this section. 37

2.2.1 A11-Session Update 38

The A11-Session Update message is sent from the PDSN to the PCF to add, change, or update session 39

parameters for an A10 connection. It is also sent to update the PCF with the Anchor P-P Address. 40


D-7

In HRPD systems, the A11-Session Update message is sent to deliver a new or updated Subscriber QoS 1

Profile to the PCF. 2

3


The PDSN may update session parameters of an A10 connection, or the Anchor P-P Address, or the 5

Subscriber QoS Profile by sending an A11-Session Update to the PCF. The Home Agent field in A11-6

Session Update message is the PDSN Address and the Home Address is set to zero. The PCF Session 7

Identifier and other session specific information are sent within the Session Specific Extension. 8

The A11-Session Update message includes the session parameter(s), or the Anchor P-P Address, or the 9

Subscriber QoS Profile in NVSE(s). For session parameter(s), the PCF shall update its session parameters 10

or relay the parameters to the BS according to the specified behavior for the particular parameter. The 11

PCF shall relay the Anchor P-P Address to the BS. For the Subscriber QoS Profile, the PCF shall update 12

its Subscriber QoS Profile if the packet data session is dormant or relay the parameters to the AN if the 13

packet data session is active. 14

After sending the A11-Session Update message, the PDSN shall start timer Tsesupd. 15


Failure detection at the PCF: If the A11-Session Update message is invalid, the PCF shall not update any 17

session parameters. The PCF shall send an A11-Session Update Acknowledge message indicating 18

identification mismatch (Status value 85H) or authentication failure (Status value 83H); refer to section 19

2.2.2. 20

Failure detection at the PDSN: If the PDSN does not receive a valid A11-Session Update Acknowledge 21

message before timer Tsesupd expires, the PDSN may retransmit the A11-Session Update message with a 22

new timestamp in the Identification information element a configurable number of times to the PCF. 23

If the PDSN has not received an A11-Session Update Acknowledge with an accept indication (Status 24

value 00H) after a configurable number of retransmissions, the PDSN shall consider the update failed and 25

shall maintain the A10 connection. 26

2.2.2 A11-Session Update Acknowledge 27


… 29

2.3 A10 Packet Accounting Procedures 30

The PCF uses the A11-Registration Request message to send accounting related and other information to 31

the PDSN. The accounting related information is accumulated at the PCF and sent to the PDSN on 32

occurrence of pre-defined triggers, which are listed in Tables 2.34-1 and 2.3-2 below. The occurrence of 33

these predefined triggers is fully specified in [8]. The A10 connection binding record at the PDSN and the 34

PCF may also be updated appropriately depending on the setting of the Lifetime field. 35

36


D-8

Table 2.3-1 Accounting Records Generated by the PCF in 1x and HRPD systems without IP 1

Flow Based Accounting 2

Airlink Record

Type (Y1)

Accounting Records Generated by the PCF

Y1=1 Connection Setup: Setup of A10 connection initiated Y1=2 Active Start: A10 connection is associated with the traffic

channel(s) or new parameters are set. Y1=3 Active Stop: A10 connection is disassociated from the traffic

channel(s) or parameter settings are no longer valid. Y1=4 A forward or reverse short data burst (SDB) was exchanged with

the MS. This record is not used in the HRPD system.

3

Table 2.3-2 Accounting Records Generated by the PCF in HRPD Systems with IP Flow Based 4

Accounting 5

Airlink Record

Type (Y1)

Accounting Records Generated by the PCF

Y1=1 Connection Setup: Setup of A10 connection initiated Y1=2 Active Start:

For IP flows with ID FFH, when • the main A10 connection is associated with the traffic channel;

or • new parameters are set. For all other IP flows, when • both of the following become true for that IP flow:

o the IP flow is in the active state, and o its associated link flow is associated with the traffic

channel; or • when new parameters are set

Y1=3 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.

6


D-9

In addition, the PCF generates an “Active Stop (Y1=3)” accounting record followed by an “Active Start 1

(Y1=2)” accounting record when certain parameters change value. Refer to section 2.3.7 for details. For 2

successful operation, the PDSN saves the accounting related and other information for further processing, 3

and responds with an A11-Registration Reply message containing an accept indication. 4

The Airlink Record information is transferred from the PCF to the PDSN, as RADIUS protocol encoded 5

attributes, in the Application Data field of a CVSE element. If the PDSN receives an unexpected airlink 6

record it may reject the A11-Registration Request message and the A11-Registration Reply message shall 7

contain the code ‘86H’ (Registration Denied – poorly formed request). If the PDSN does not receive an 8

accounting parameter that is expected, the PDSN may reject the A11-Registration Request message, and 9

the associated A11-Registration Reply message shall contain either: 10

• code ‘8DH’ (Registration Denied – unsupported Vendor ID or unable to interpret Application Type or 11

Application Sub Type in the CVSE sent by the PCF to the PDSN), or 12

• code ‘86H’ (Registration Denied – poorly formed request). 13

If the PDSN receives a RADIUS attribute that is not expected in a CVSE, the PDSN shall ignore that 14

attribute and process the remainder of the CVSE to the extent possible. Refer to section 4.2.13 for further 15

details. 16

2.3.1 A10 Connection Setup Airlink Record 17

The A10 Connection Setup Airlink record shall be included in the A11-Registration Request message at 18

the time of establishment of a new A10 connection. It is also included in the A11-Registration Request 19

message if an A10 connection is pre-setup during fast handoff. 20

In HRPD systems, if a single A11-Registration Request message is used to establish multiple A10 21

connections, an A10 Connection Setup Airlink record is included for each of the A10 connections to be 22

established. 23

2.3.2 Active-Start Airlink Record 24

The Active-Start Airlink record shall be included in the A11-Registration Request message under the 25

following circumstances: 26

1. For 1x systems Wwhen a traffic channel is assigned to a packet data service instance: during initial 27

service instance setup when the service instance becomes associated with the air interface, on 28

transition from dormant to active state or during handoff or for an HRPD system when the air 29

interface is in an appropriate state such that bearer data is ready to be exchanged. The Active-Start 30

Airlink record may follow the connection Setup Airlink record in the same A11-Registration Request 31

message (assuming that all the parameters required in the Active-Start Airlink record are made 32

available at the PCF at the time the message is sent). 33

2. Following an Active-Stop Airlink record when any of the parameters specified in section 2.3.7 are 34

changed. The Active Start Airlink Record shall contain the new set of parameters. 35

3. For IP flows with ID FFH in HRPD systems, when an HRPD connection is established: during initial 36

session setup when the main A10 connection is associated with the air interface, on transition from 37

dormant to active state, or during handoff. For IP flows with ID FFH in HRPD systems, accounting is 38

bidirectional: one Active-Start Airlink record applies to both forward and reverse IP flows with ID 39

FFH. This record does not include Granted QoS Parameters. 40

4. For IP flows with ID other than FFH in HRPD systems, when transitioning to a state where 41

the IP flow is in the active state and its associated link flow is associated with the traffic channel. 42

For IP flows with ID other than FFH in HRPD systems, accounting is unidirectional: separate 43

Active-Start Airlink records are generated per {IP flow, Direction} pair. This record shall include 44

Granted QoS Parameters. 45

46


D-10

In HRPD systems, the Active-Start Airlink record may follow the A10 connection Setup Airlink record in 1

the same A11-Registration Request message (assuming that all the parameters required in the Active-Start 2

Airlink record are made available at the PCF at the time the message is sent). 3

2.3.3 Active-Stop Airlink Record 4

The Active Stop Airlink Record shall be included in the A11-Registration Request message under the 5

following circumstances: 6

1. In 1x systems, Wwhen the traffic channel is disassociated from the packet data service instance: 7

during service instance release, on transition from active state to dormant, or during handoff. 8

2. When any of the parameters specified in section 2.3.7 are changed. 9

3. For IP flows in HRPD systems, when the HRPD connection (traffic channel) is released. 10

4. For IP flows with ID FFH in HRPD systems, when an HRPD connection is released. For IP flows 11

with ID FFH in HRPD systems, accounting is bidirectional: one Active-Stop Airlink record applies to 12

both forward and reverse IP flows with ID FFH. This record does not include Flow ID Parameter and 13

Flow Status. 14

5. For IP flows with ID other than FFH in HRPD systems, when the IP flow is removed or transitions to 15

the deactivated state while its associated link flow is associated with the traffic channel, during 16

handoff, or when the IP flow’s associated link flow is disassociated with the traffic channel while the 17

IP flow is in the activated state. For IP flows with ID other than FFH in HRPD systems, accounting is 18

unidirectional: separate Active-Stop Airlink records are generated per {IP flow, Direction} pair. 19

For inter-PCF handoff, the source PCF shall send an Active-Stop Airlink record for each activated IP 20

flow to the PDSN, and the target PCF shall send Active-Start Airlink records for each activated IP flow to 21

the PDSN. 22

In the case of (2), the Active Stop Airlink Record shall be sent and followed by an Active Start Airlink 23

Record that shall contain the new set of parameters. 24

2.3.4 SDB Airlink Record 25

The SDB Airlink Record is used by the PCF to report to the PDSN the transfer of Short Data Burst 26

information to and from the user. 27

The PCF should be notified when a successful SDB is delivered to the MS or successfully received by the 28

BS. 29

… 30

3.0 Message Formats 31

32

3.1 A11-Registration Request 33

This A11 interface message is sent from the PCF to the PDSN to: 34

• establish one or more an A10 connection (and identify the associated service option value and MN 35

Session Reference ID/SR_ID); 36

• periodically re-register an all A10 connection(s) for the MS/AT; 37

• clear one or more an A10 connection(s); 38

• pass accounting related information per the triggers listed in Table 2.3-1 and Table 2.3-2;. 39

• perform any additions, deletions, remappings, and/or changes in granted QoS of IP flows in HRPD 40

systems. 41


D-11

The A11-Registration Request messages may contain additional information to: 1

• indicate that all packet data service instances have gone dormant; 2

• pass fast handoff related information;. 3

• indicate support of features such as Short Data Indication 4

5


Element Direction

Type

A11 Message Type 4.2.1 PCF -> PDSN M Flags 4.2.2 PCF -> PDSN O R Lifetime 4.2.3 PCF -> PDSN Oh R Home Address 4.2.4 PCF -> PDSN O R Home Agent 4.2.5 PCF -> PDSN O R Care-of-Address 4.2.6 PCF -> PDSN Ol R Identification 4.2.7 PCF -> PDSN O R Session Specific Extension 4.2.12 PCF -> PDSN Oi R Critical Vendor/Organization Specific Extension 4.2.13 PCF -> PDSN Oa,e C

Normal Vendor/Organization Specific Extension 4.2.14 PCF -> PDSN Oa,b,c,d,f,g,j,l,m C

Mobile-Home Authentication Extension 4.2.10 PCF -> PDSN O R

a. One or more instances of this element may be included. 6

b During a fast handoff, this element is used to provide the Anchor P-P Address to the target PDSN 7

when the PCF supports fast handoff. If an Anchor P-P Address is included in the message and the 8

PDSN supports fast handoff, then the PDSN shall process the fast handoff request, and disregard the 9

ANID values. 10

c. If this message contains the Active Stop Airlink Record for the last service instance going dormant 11

(i.e., all packet data service instances for the user are dormant) in the CVSE, then an instance of this 12

element containing the All Dormant Indicator shall be included in this message. 13

d. This element shall be included when this message is sent for A10 connection setup and the PCF is 14

capable of supporting multiple service instances. In 1x systems, Application Type = Service Option It 15

contains the Service Option value received from the BS for the PDSI. [FROM SF-841r3: ]In HRPD, 16

Application Type = Service Option contains the SO value for the main service instance. The main 17

service instance is defined to have SR_ID=1. 18

e. During a handoff, this element is used to provide the MEI. 19

f. During a handoff, this element is used to provide the ANIDs. 20

g. This element may indicate the features that the PCF has enabled e.g., Short Data Indication. 21

h. For HRPD systems, Lifetime applies to all A10 connections set up by this message when this 22

message is sent. If the lifetime field is set to ‘0’, all A10 connections associated with the HRPD 23

session are released. 24

i. This element contains information for the main service instance. 25

j. If the PCF supports ANIDs, then this IE shall be included to convey the Access Network Identifiers 26

to the PDSN. 27

k. For HRPD system, this element may be used to set up auxiliary A10 connections. When setting up 28

auxiliary A10 connections, this element is also used to send information for all existing A10 29

connections. 30


D-12

l. This element contains the IPv4 address of the PCF that terminates the main A10 connection 1

(identified in the Session Specific Extension IE). Note that this address may be different from the 2

source IP address of this message. 3

m. For HRPD, this element may be included to specify IP flows associated with the A10 connections and 4

to convey QoS information for those IP flows (Flow State, Requested QoS, and Granted QoS). Each 5

instance of this element with QoS Information application type contains QoS information for IP flows 6

associated with one direction of one A10 connection. Multiple instances of the QoS Information 7

application type NVSE are used for transmission of QoS Information in both directions of an A10 8

connection and for multiple A10 connections (i.e., multiple SR_IDs) in the same A11-Registration 9

Request message. 10

11

n. For HRPD systems, this IE is used to provide QoS information. 12

13

The following table shows the bitmap layout for the A11-Registration Request message. 14

3.1 A11-Registration Request

0 1 2 3 4 5 6 7 Octet


⇒⇒⇒⇒ Flags = [0AH, 8AH] 1

(MSB) ⇒⇒⇒⇒ Lifetime = [00 00H to FF FEH] 1

(LSB) 2

(MSB) ⇒⇒⇒⇒ Home Address = [00 00 00 00H] 1

2

3

(LSB) 4

(MSB) ⇒⇒⇒⇒ Home Agent = <any value> 1

2

3

(LSB) 4

(MSB) ⇒⇒⇒⇒ Care-of-Address = <any value> 1

2

3

(LSB) 4

(MSB) ⇒⇒⇒⇒ Identification = <any value> 1

2

3

4

5

6

7

(LSB) 8

⇒⇒⇒⇒ Session Specific Extension: = [27H] 1


D-13


0 1 2 3 4 5 6 7 Octet

Length = [13H–15H] 2

(MSB) Protocol Type = [88 81H] 3

(LSB) 4


6

7

(LSB) 8

Reserved = [00H] 9

Reserved = [0000 00] Session ID Ver = [‘00’ (Version 0),

‘01’ (Version 1)]

10

(MSB) MN Session Reference Id = [00 01H - 00 06H] 11

(LSB) 12

(MSB) MSID Type = [00 06H] (IMSI) 13

(LSB) 14

MSID Length = [06-08H] (10-15 digits) 15

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


… … … If (Odd/Even Indicator = 0000 (even)) {Identity Digit N+1 = [FH] (BCD)}

Else If (Odd/Even Indicator = 0001 (odd)) {Identity Digit N+1 = [0H-9H] (BCD)}

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

⇒⇒⇒⇒ Critical Vendor/Organization Specific Extension: Type = [26H] 1

Reserved = [0000 0000] 2

(MSB) Length = <variable> 3

(LSB) 4

(MSB) 3GPP2 Vendor ID = 00 00 15 9FH 5

6

7

(LSB) 8

Application Type = [01H, 02H] 9

IF (Application Type = 01H (Accounting) {1:

Application Sub Type = [01H] 10

(MSB) Application Data (contains accounting information) 11

… (LSB) k

} Application Type = 01H; ELSE IF (Application Type = 02H (Mobility Event Indicator)) {1:

Application Sub Type = [01H] m


D-14


0 1 2 3 4 5 6 7 Octet

} Application Type = 02H

⇒⇒⇒⇒ Normal Vendor/Organization Specific Extension: Type = [86H] 1


(MSB) Reserved = [00 00H] 3

(LSB) 4

(MSB) 3GPP2 Vendor ID = [00 00 15 9FH] 5

6

7

(LSB) 8

Application Type = [04H-06H, 08H, 09H, 0B-0DH] (Access Network Identifiers, PDSN Identifier, Indicators, Session Parameter, Service Option, PCF Enabled Features,

Additional Session Information, QoS Information)

9

IF (Application Type = 04H (Access Network Identifiers)) {1:


(MSB) Application Data = <any value> (contains PANID and CANID) 11

… (LSB) 20

} Application Type = 04H, ELSE IF (Application Type = 05H (PDSN Identifier)) {1:

Application Sub Type = [01H (Anchor P-P Address)] 10

(MSB) Application Data (contains an IPv4 address) 11

12

13

(LSB) 14

} Application Type = 05H; ELSE IF (Application Type = 06H (Indicators)) {1

Application Sub Type = [01H (All Dormant Indicator)] 10

(MSB) Application Data = 00 00H 11

(LSB) 12

} Application Type = 06H; ELSE IF (Application Type = 08H (Session Parameter)) {1:ELSE IF (Application Type = 09H (Service Option)) {1:

Application Sub Type = [03H (QoS Mode)]Application Sub Type = [01H] 10

Application Data = [00H-01H] 11

(MSB) Application Data (contains Service Option) 11

(LSB) 12

} Application Type = 08H; ELSE IF (Application Type = 09H (Service Option)) {1:


(MSB) Application Data [ 00 3BH (HRPD Main Service Connection)] 11

(LSB) 12

} Application Type = 09H; ELSE IF (Application Type = 0BH (PCF Enabled Features)){1


D-15


0 1 2 3 4 5 6 7 Octet

Application Sub Type = [01H (Short Data Indication Supported) = 01H], 02H (GRE Segment Enabled)]

10

} Application Type = 0BH; ELSE IF (Application Type = 0CH (Additional Session Information)) {1:



GRE Key Information Entry { 1-6:

Entry Length = [09H] n

SR_ID = [00H-1FH] n+1

(MSB) Service Option = [ 00 40H (HRPD Auxiliary Service Connection) ] n+2

(LSB) n+3

(MSB) Protocol Type = [88 81H] n+4

(LSB) n+5


n+7

n+8

(LSB) n+9

(MSB) Source IP Address = <any value> n+10

n+11

n+12

(LSB) n+13

} GRE Key Information Entry

} Application Type = 0CH; ELSE IF (Application Type = 0DH (QoS Information)){1:

Application Sub Type = [01H - 02H] 10

IF (Application Sub Type = 01H (Forward QoS Information)){1: Length = [variable] 11

SR_ID = [00H-1FH] 12

Use IP Flow

Discrimi-nation =

[0,1]

DSCP Included

Reserved = [0 0000] 13

Reserved = [000] Forward Flow Count = [0 – 31] 14


Entry Length = [variable] n

Forward Flow ID = [00H - FFH] n+1


n+2

Forward Requested QoS Length = [variable] n+3

(MSB) Forward Requested QoS = <any value> n+4


D-16


0 1 2 3 4 5 6 7 Octet

… … (LSB) p

Forward Granted QoS Length = [variable] p+1

(MSB) Forward Granted QoS = <any value> p+2

… … (LSB) q


} Application Sub Type = 01H; ELSE IF (Application Sub Type = 02H (Reverse QoS Information)){1: Length = [variable] 10

SR_ID = [00H-1FH] 11

Reserved = [000] Reverse Flow Count = [0 – 31] 12


Entry Length = [variable] n

Reverse Flow ID = [00H - FFH] n+1


n+2

Reverse Requested QoS Length = [variable] n+3

(MSB) Reverse Requested QoS = <any value> n+4

… … (LSB) p

Reverse Granted QoS Length = [variable] p+1

(MSB) Reverse Granted QoS = <any value> p+2

… … (LSB) q


} Application Sub Type = 02H

} Application Type = 0DH

⇒⇒⇒⇒ Mobile-Home Authentication Extension: Type = [20H] 1

Length = [14H] 2

(MSB) SPI = [00 00 01 00H to FF FF FF FFH] 3

4

5

(LSB) 6

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

8

9

… …


D-17


0 1 2 3 4 5 6 7 Octet

(LSB) 22

3.2 A11-Registration Reply 1

This A11 interface message is sent from the PDSN to the PCF in response to an A11-Registration 2

Request message. 3



A11 Message Type 4.2.1 PDSN -> PCF M Code 4.2.8 PDSN -> PCF M Lifetime 4.2.3 PDSN -> PCF M Home Address 4.2.4 PDSN -> PCF M Home Agent 4.2.5 PDSN -> PCF Ma Identification 4.2.7 PDSN -> PCF M Session Specific Extension 4.2.12 PDSN -> PCF Mi

Critical Vendor/Organization Specific Extension 4.2.13 PDSN -> PCF Ob C

Normal Vendor/Organization Specific Extension 4.2.14 PDSN -> PCF Oc,d,e,f,g,

h,j,k C

Mobile-Home Authentication Extension 4.2.10 PDSN -> PCF O R

4

a. This element can also be used to identify the IPv4 address of an alternative PDSN. 5

b. This element is included if the PDSN has data available. 6

c. This element is used by the anchor PDSN to provide an Anchor P-P Address when the PDSN 7

supports fast handoff. 8

d. One or more instances of this element may be included. 9

e. During a fast handoff, the target PDSN includes the Anchor P-P Address to indicate that the fast 10

handoff request was accepted. 11

f. This element is used to send a Radio Network Packet Data Inactivity Timer (RN-PDIT) to the PCF 12

when supported. 13

g. When an Always-on Indicator is present at the PDSN, the PDSN shall include the NVSE with an 14

Always-on indicator. 15

h. This element is used by the PDSN to indicate that flow control is enabled for the packet data service 16

instance. 17

i. This element contains information for the main service instance. 18

j. [FROM SF-837: If this message is sent to establish the main A10 connection during dormant handoff 19

in an HRPD system, the PDSN shall include the NVSE with the saved Subscriber QoS Profile, if 20

any]. 21

k. This element contains information (in the Additional Session Information application type) for 22

auxiliary A10 connection(s) requested in the corresponding A11-Registration Request message. 23

The following table shows the bitmap layout for the A11-Registration Reply message. 24


D-18

3.2 A11-Registration Reply

0 1 2 3 4 5 6 7 Octet


⇒⇒⇒⇒ Code = [00H (Registration Accepted),

80H (Registration Denied – reason unspecified), 81H (Registration Denied – administratively prohibited), 82H (Registration Denied – insufficient resources), 83H (Registration Denied – PCF failed authentication), 85H (Registration Denied – identification mismatch), 86H (Registration Denied – poorly formed request), 88H (Registration Denied – unknown PDSN address), 89H (Registration Denied – requested reverse tunnel unavailable), 8AH (Registration Denied – reverse tunnel is mandatory and ‘T’ bit not set), 8DH (Registration Denied – unsupported vendor ID or unable to interpret Application

Type or Application Sub Type in the CVSE sent by the PCF to the PDSN.)]

1

(MSB) ⇒⇒⇒⇒ Lifetime = [00 00H to FF FEH] 1

(LSB) 2


2

3

(LSB) 4


2

3

(LSB) 4


2

3

4

5

6

7

(LSB) 8

⇒⇒⇒⇒ Session Specific Extension: Type = [27H] 1

Length = [13H – 15H] 2


(LSB) 4


6

7

(LSB) 8


D-19


0 1 2 3 4 5 6 7 Octet

Reserved = [00H] 9

Reserved = [0000 00] Session ID Ver = [‘00’ (Version 0),

‘01’ (Version 1)]

10


(LSB) 12


(LSB) 14


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

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

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

Reserved = [0000 0000] 2 (MSB) Length = [00 06H] 3

(LSB) 4


6 7

(LSB) 8

Application Type = [03H] (Data Availability Indicator) 9 Application Sub Type = [01H] 10


Length = <variable> 2 Reserved = [00 00H] 3

4


6 7

(LSB) 8

Application Type = [05H (PDSN Identifier, 08H (Session Parameter), 0AH (PDSN Enabled Features), 0CH (Additional Session Information)]

9

IF (Application Type = 05H (PDSN Identifier)){1



D-20


0 1 2 3 4 5 6 7 Octet

(MSB) Application Data (contains an IPv4 address)> 11 12

13

(LSB) 14

} Application Type = 05H; ELSE IF (Application Type = 08H (Session Parameter)){1

Application Sub Type = [01H (RN-PDIT), 02H (Always-on)] 10 IF (Application Sub Type = 01H (RN-PDIT)) {1

(MSB) Application Data = [01H – FFH] (LSB) 11 } Application Sub Type =01H, } Application Type = 08H; ELSE IF (Application Type = 0AH (PDSN

Enabled Features)){1: Application Sub Type = [01H (Flow Control Enabled), 02H (Packet Boundary Enabled)] 10

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



GRE Key Information Entry { 1 - 6:

Entry Length = [09H] n

Reserved = [0000 0] SR_ID = [2 - 7] n+1

(MSB) Service Option = [ 00 40H (HRPD Auxiliary Service Connection) ] n+2

(LSB) n+3

(MSB) Protocol Type = [88 81H] n+4

(LSB) n+5


n+7

n+8

(LSB) n+9


} Application Type = 0CH; ELSE IF (Application Type = 0DH (QoS Information)) {1:

Application Sub Type = [03H (Subscriber QoS Profile)] 10


(MSB) Subscriber QoS Profile = <any value> 12

13

14

… … (LSB) n

} Application Type = 0DH

⇒⇒⇒⇒ Mobile-Home Authentication Extension: Type = [20H] 1

Length = [14H] 2


D-21


0 1 2 3 4 5 6 7 Octet


4

5

(LSB) 6


8

9

… … (LSB) 22

1

3.3 A11-Registration Update 2

This A11 interface message is sent from the PDSN to the PCF to release an A10 connections. 3



A11 Message Type 4.2.1 PDSN -> PCF M Reserved <3 octets> None PDSN -> PCF Ma Home Address 4.2.4 PDSN -> PCF M Home Agent 4.2.5 PDSN -> PCF M Identification 4.2.7 PDSN -> PCF M Session Specific Extension 4.2.12 PDSN -> PCF Mc Normal Vendor/Organization Specific Extension

4.2.14 PDSN -> PCF Ob C

Registration Update Authentication Extension

4.2.11 PDSN -> PCF M

a. This field is set to zero by the PDSN and ignored by the PCF. 4

b. This element is used by the PDSN to provide a PDSN code to the PCF. 5

c. For HRPD, the MN Session Reference Id field in this element shall be set to 1. 6

The following table shows the bitmap layout for the A11-Registration Update message. 7

3.3 A11-Registration Update

0 1 2 3 4 5 6 7 Octet


⇒⇒⇒⇒ Reserved = [00 00 00H] 1

2

3


2

3


D-22


0 1 2 3 4 5 6 7 Octet

(LSB) 4


2

3

(LSB) 4


2

3

4

5

6

7

(LSB) 8


Length = [13H – 15H] 2


(LSB) 4


6

7

(LSB) 8

Reserved = [00H] 9

Reserved = [0000 00] Session ID Ver = [‘00’ (Version 0), ‘01’ (Version 1)]

10

(MSB) MN Session Reference Id = [00 01H-00 06H] 11

(LSB) 12


(LSB) 14




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





D-23


0 1 2 3 4 5 6 7 Octet


(LSB) 4


6

7

(LSB) 8

Application Type = [07H (PDSN CODE)] 9


Application Data = [C1H-C8H, CAH] 11

⇒⇒⇒⇒ Registration Update Authentication Extension: Type = [28H] 1

Length = [14H] 2


4

5

(LSB) 6


8

9

… … (LSB) 22

1

2

3.4 A11-Registration Acknowledge 3

This A11 interface message is sent from the PCF to the PDSN in response to an A11-Registration Update 4

message. 5



A11 Message Type 4.2.1 PCF -> PDSN M Reserved <2 octets> None PCF -> PDSN Ma Status 4.2.9 PCF -> PDSN M Home Address 4.2.4 PCF -> PDSN M Care-of-Address 4.2.6 PCF -> PDSN M Identification 4.2.7 PCF -> PDSN M Session Specific Extension 4.2.12 PCF -> PDSN Mb Registration Update Authentication Extension

4.2.11 PCF -> PDSN M

a. This field is set to zero by the PCF and ignored by the PDSN. 6


D-24

b. For HRPD, the MN Session Reference Id field in this element shall be set to 1. 1

2


D-25

The following table shows the bitmap layout for the A11-Registration Acknowledge message. 1

3.4 A11-Registration Acknowledge

0 1 2 3 4 5 6 7 Octet


⇒⇒⇒⇒ Reserved = [00 00H] 1

2

⇒⇒⇒⇒ Status = [00H (Update Accepted)

80H (Update Denied – reason unspecified) 83H (Update Denied – sending node failed authentication) 85H (Update Denied – identification mismatch) 86H (Update Denied – poorly formed registration update)]

1


2

3

(LSB) 4

(MSB) ⇒⇒⇒⇒ Care-of-Address = <any value> 1

2

3

(LSB) 4


2

3

4

5

6

7

(LSB) 8


Length = [13H – 15H] 2


(LSB) 4


6

7

(LSB) 8

Reserved = [00H] 9


10

(MSB) MN Session Reference Id = [00 01H – 00 06H] 11


D-26

3.4 A11-Registration Acknowledge

0 1 2 3 4 5 6 7 Octet

(LSB) 12


(LSB) 14




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



Length = [14H] 2


4

5

(LSB) 6


8

9

… … (LSB) 22

1

3.5 A11-Session Update 2

This A11 interface message is sent from the PDSN to the PCF to add new or update parameters of an A10 3

connection. It is also sent to update the PCF with the Anchor P-P Address. In HRPD systems, this 4

message is also sent to deliver a new or updated Subscriber QoS Profile to the PCF. 5



A11 Message Type 4.2.1 PDSN -> PCF M Reserved <3 octets> None PDSN -> PCF Ma Home Address 4.2.4 PDSN -> PCF M Home Agent 4.2.5 PDSN -> PCF M Identification 4.2.7 PDSN -> PCF M Session Specific Extension 4.2.12 PDSN -> PCF Me Normal Vendor/Organization Specific Extension

4.2.14 PDSN ->PCF Ob,c, d C

Registration Update Authentication Extension

4.2.11 PDSN -> PCF M


D-27

1

a. This field is set to zero by the PDSN and ignored by the PCF. 2

b. This element is used by the PDSN to provide an RN-PDIT value to the PCF. 3

c. When an Always-on Indicator is present at the PDSN, the PDSN shall include the NVSE with an 4

Always-on indicator 5

d. This element is included by the PDSN to update the PCF with an Anchor P-P Address for fast 6

handoff. 7

e. For HRPD systems the MN Session Reference ID field of this IE shall be set to 00 01H. 8

The following table shows the bitmap layout for the A11-Session Update message. 9

3.5 A11-Session Update

0 1 2 3 4 5 6 7 Octet


(MSB) ⇒⇒⇒⇒ Reserved = [00 00 00H] 1

2

(LSB) 3


2

3

(LSB) 4


2

3

(LSB) 4


2

3

4

5

6

7

(LSB) 8


Length = [13H – 15H] 2


(LSB) 4


6

7

(LSB) 8


D-28


0 1 2 3 4 5 6 7 Octet

Reserved = [00H] 9


10


(LSB) 12


(LSB) 14




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



Length = <any value> 2


(LSB) 4


66

7

(LSB) 8

Application Type = [05H (PDSN Identifier), 08H (Session Parameter), 0DH (QoS Information)]

9

IF (Application Type = 05H (PDSN Identifier)){1:


(MSB) Application Data = (contains an IPv4 address) 11

12

13

(LSB) 14

} Application Type = 05H; ELSE IF (Application Type = 08H (Session Parameter)) {1:

Application Sub Type = [01H (RN-PDIT), 02H (Always-on)]] 10

IF (Application Sub Type = 01H (RN-PDIT)) {1

(MSB) Application Data = [01H–FFH] (LSB) 11

} Application Sub Type =01H} Application Sub Type =01H, } Application Type = 08H;

} Application Type = 08H; ELSE IF (Application Type = 0DH (QoS Information)) {1:

Application Sub Type = [03H (Subscriber QoS Profile)] 10



D-29


0 1 2 3 4 5 6 7 Octet

(MSB) Subscriber QoS Profile = <any value> 12

13

14

… … (LSB) n

} Application Type = 0DH;


Length = [14H] 2


4

5

(LSB) 6


8

9

… … (LSB) 22

1

3.6 A11-Session Update Acknowledge 2


… 4

4.2 Information Elements 5

6

4.2.1 A11 Message Type 7


4.2.2 Flags 9


11

4.2.3 Lifetime 12


4.2.4 Home Address 14



D-30

4.2.5 Home Agent 1


4.2.6 Care-of-Address 3

This element identifies the IPv4 address of the PCF that terminates the main A10 connection. Note that 4

this address may be different from the source IP address of the message containing this IE. The structure 5

of the element conforms to [21] and is shown below. 6

4.2.6 Care-of-Address

0 1 2 3 4 5 6 7 Octet

(MSB) Care-of-Address 1

2

3

(LSB) 4

7

4.2.7 Identification 8


4.2.8 Code 10


4.2.9 Status 12


4.2.10 Mobile-Home Authentication Extension 14


4.2.11 Registration Update Authentication Extension 16


4.2.12 Session Specific Extension 18


4.2.13 Critical Vendor/Organization Specific Extension (CVSE) 20

This element may be present in the A11-Registration Request message to convey accounting information 21

from the PCF to the PDSN. This element may also be present in the A11-Registration Request message to 22

convey the Mobility Event Indicator from the PCF to the PDSN during dormant handoffs and active/hard 23

handoffs. The coding format of the CVSE defined herein conforms to [26]. 24

This element may be present in the A11-Registration Reply message to convey the Data Available 25

Indicator (DAI) from the PDSN to the PCF during handoff. 26

This element reflects Application Type and Application Sub-Types supported in IOS v4.0. New 27

Application Type or Application Sub-Types shall be added to the Normal Vendor/Organization Specific 28

Extension (NVSE) (refer to section 4.2.14). 29


D-31

When used to convey accounting information, the accounting records are contained within the 1

Application Data field of this element. The accounting records conveyed from the PCF to the PDSN 2

conform to the specifications in [8]. Each application type 01H (Accounting) CVSE contains one and 3

only one airlink record as specified by Tables 4.2.13-2 through 4.2.13-5, and shall include all the 4

parameters listed in the corresponding table unless otherwise specified. For transmission of multiple 5

airlink records in the same A11-Registration Request message, multiple instances of accounting type 6

CVSEs are used. 7

4.2.13 Critical Vendor/Organization Specific Extension (CVSE)

0 1 2 3 4 5 6 7 Octet

A11 Element Identifier (Type) 1

Reserved 2

(MSB) Length 3

(LSB) 4

(MSB) 3GPP2 Vendor ID 5

6

7

(LSB) 8

Application Type 9

Application Sub Type 10

(MSB) Application Data 11

12

… …

(LSB) k

Note that the Application Type and the Application Sub Type together correspond to the Vendor- CVSE-8

Type as defined in [26]. 9

Type: 26H 10

Length: This field indicates the number of octets in this element following the Length 11

field. 12

3GPP2 Vendor ID: 00 00 15 9FH 13

Application Type: This field indicates the type of application to which the extension relates. The 14

supported values are listed in Table 4.2.13-1. 15

Application Sub Type: This one octet field indicates the Application sub-type within the Application 16

Type. The supported values are listed in Table 4.2.13-1. 17

Table 4.2.13-1 Application Type and Sub Type 18

Application Type Application Sub Type Name Value Name Value

Used in Message Reference

RADIUS 01H A11-Registration Request 3.1

DIAMETER 02H Not used

Accounting 01H



D-32

Mobility 01H A11-Registration Request 3.1 Mobility Event Indicator 02H


Data Ready to Send 01H A11-Registration Reply 3.2 Data Available Indicator 03H



Application Data: For Application Type 01H (Accounting), this field contains all the accounting 1

parameters contained in one airlink record conveyed from the PCF to the PDSN 2

as specified in [8]. In this version of this standard, only Application Sub Type = 3

RADIUS is used. Each of the accounting parameters is structured in the format of 4

RADIUS attributes specified in [23] and [24]. Refer to the following text for 5

more details. 6

For Application Type 02H (Mobility Event Indicator), this field is zero bytes in 7

length. 8

For Application Type 03H (Data Available Indicator), this field is zero bytes in 9

length. 10

For Application Type 01H (Accounting), all 3GPP2 specific Accounting Parameters are coded using 11

RADIUS Vendor-Specific-Attribute format as follows: 12

1 2 3 4 5 6 7 8 Octet

Type 1

Length 2

(MSB) 3GPP2 Vendor-Id 3

4

5

(LSB) 6

Vendor-Type 7

Vendor-Length 8

(MSB) Vendor-Value (variable number of octets) 9

10

…

(LSB) k

Type: 1AH 13

Length: Type (1 octet) + Length (1 octet) + 3GPP2 Vendor Id (4 octets) + { Vendor-Type 14

(1 octet), Vendor-Length (1 octet), Vendor-Value (variable octets) of the 3GPP2 15

specific parameter comprising the airlink record being coded.} 16

Vendor ID: 00 00 15 9FH 17

Vendor Type: Sub-Type value from the Airlink Record tables below. 18

Vendor-Length: Vendor-Type (1 octet) + Vendor-Length (1 octet) + Payload Length (in octets) 19

from the Airlink Record tables below. 20

Vendor-Value: Payload of the accounting parameter. 21


D-33

For Application Type 01H (Accounting) all RADIUS specific Airlink Record Parameters are coded as 1

follows: 2

1 2 3 4 5 6 7 8 Octet

Type 1

Length 2

(MSB) Value (variable number of octets) 3

4

… (LSB) k

Type: Type value from the Airlink Record tables below. 3

Length: Type (1 octet) + Length (1 octet) + Payload Length (in octets) from the Airlink Record 4

tables below. 5

Value: Payload of the accounting parameter. 6

Airlink Record Fields Tables: 7

Table 4.2.13-2 A10 Connection Setup Airlink Record (Connection Setup) 8

Parameter Type Sub-Type

Max. Payload Length (octet)

Format

Airlink Record Type = 1 (Setup) 26 40 4 Integer A10 R-P Connection ID 26 41 4 Integera

Airlink Sequence number 26 42 4 Integer MSID 31 N/A 15 Stringb

ESNf 26 52 15 Stringd

MEIDf 26 116 14 Stringe

Serving PCF 26 9 4 Ip-addr

BSID (SID+NID+Cell Identifier)g 26 10 12 Stringc

ESNf 26 52 15 Stringd

MEIDf 26 116 14 Stringe

Subnetg 26 108 37 String

9

a. This parameter shall be set to the same value as the Key field in the Session Specific Extension 10

information element sent in the A11-Registration Request message. 11

b. Each digit is encoded an ASCII character. 12

c. The string is the result of the concatenation of SID+NID+ Cell Identifier (Type 2), where each item is 13

encoded using four hexadecimal uppercase ASCII characters. 14

d. The string consists of the 8-bit ASCII encoding of the uppercase hexadecimal representation of the 15

ESN. 16

e. The string consists of the 8-bit ASCII encoding of the uppercase representation of the Mobile 17

Equipment Identifier. 18

f. Inclusion of ESN, MEID or both parameters in this record is a network operator decision. Even if the 19

network operator uses MEID, it is possible that the Connection Setup Airlink Record does not include 20


D-34

MEID parameter. This is because MEID may not be available in the RAN at the time of A10 1

connection establishment. 2

g. In 1X systems, BSID is included and Subnet is omitted. In HRPD systems, Subnet is included and 3

BSID is omitted. 4

Table 4.2.13-3 Active Start Airlink Record 5



Format

Airlink record type = 2 (START) 26 40 4 Integer A10 R-P Connection ID 26 41 4 Integer

Airlink Sequence number 26 42 4 Integer

MEIDg 26 116 14 Stringh

BSID (SID+NID+Cell Identifier)i 26 10 12 String

Subneti 26 108 37 String

User Zonef 26 11 4 Integera

Forward FCH Mux Optiond,f 26 12 4 Integerb

Reverse FCH Mux Optiond,f 26 13 4 Integerb

Service Option 26 16 4 Integer

Forward Traffic Typed 26 17 4 Integer

Reverse Traffic Type (Primary, Secondary)d,f

26 18 4 Integer

FCH Frame Size (0/5/20ms)d,f 26 19 4 Integerc

Forward FCH RCd,f 26 20 4 Integerb

Reverse FCH RCd,f 26 21 4 Integerb

DCCH Frame Size (0/5/20 ms)d,f 26 50 4 Integerc

Forward PDCH RCd,f 26 83 4 Integerb

Forward DCCH Mux Optiond,f 26 84 4 Integerb

Reverse DCCH Mux Optiond,f 26 85 4 Integerb

Forward DCCH RCd,f 26 86 4 Integerb

Reverse DCCH RCd,f 26 87 4 Integerb

Reverse PDCH RCd,f 26 114 4 Integerb

Airlink Priorityd 26 39 4 Integer

Forward PDCH RC 26 83 4 Integerb

Reverse PDCH RC 26 114 4 Integerb

Granted QoS Parameters 26 132 variable Integere

6

a. This parameter shall either be set to 00 00 00 00H or not be included if the PCF does not have the 7

information available. 8

b. This parameter shall not be included if the corresponding physical channel type is not part of the 9

current channel configuration. This note is only applicable to 1x systems. 10


D-35

c. This parameter shall be set to zero if the corresponding physical channel type is not part of the current 1

channel configuration. This note is only applicable to 1x systems. 2

d. In 1x systems, if the PCF has not received this information from the AN, the PCF shall set this field 3

to a default value of 0. 4

e. This parameter is included if received from the PCF, except that this parameter shall not be included 5

for Flow ID FFH. 6

f. This parameter need not be included in HRPD systems. If it is included, the PCF shall set this field to 7

a default value of 0. 8

g. This parameter may be included. Refer to [8]. 9

h. The string consists of the 8-bit ASCII encoding of the uppercase representation of the Mobile 10

Equipment Identifier. 11

i. In 1X systems, BSID is included and Subnet is omitted. In HRPD systems, Subnet is included and 12

BSID is omitted. 13

14

Table 4.2.13-4 Active Stop Airlink Record 15



Format

Airlink record type = 3 (STOP) 26 40 4 Integer A10 R-P Connection ID 26 41 4 Integer

Airlink Sequence number 26 42 4 Integer Active Connection Time or Flow

Activated Time in Seconds 26 49 4 Integer

Flow ID Parametera 26 144 2 Integer

Flow Statusa 26 145 4 Integer

a. This parameter is included if received from the PCF, except it that this parameter shall not be 16

included for Flow ID FF. 17

18

Table 4.2.13-5 SDB Airlink Record (1X systems) 19



Format

Airlink record type = 4 (SDB) 26 40 4 Integer A10 R-P Connection ID 26 41 4 Integer

Airlink Sequence number 26 42 4 Integer Mobile Orig./Term. Indicator 26 45 4 Integer

SDB Octet Count 26 31/32a 4 Integer

a. Subtype 31 is for terminating SDB octet count, and subtype 32 is for originating SDB octet count. 20

An example coding of the Active Stop Airlink Record within the CVSE element is illustrated below: 21

0 1 2 3 4 5 6 7 Octet

A11 Element Identifier = 26H 1

Reserved 2


D-36

0 1 2 3 4 5 6 7 Octet

(MSB) Length = 36H 3

(LSB) 4


6

7

(LSB) 8

Application Type = 01H 9

Application Sub Type = 01H 10

Parameter Name: Airlink Record Type = 3 (Active Stop)

Type = 1AH 11

Length = 0CH 12

(MSB) 3GPP2 Vendor-Id = 00 00 15 9FH 13

14

15

(LSB) 16

Vendor-Type = 28H 17

Vendor-Length = 06H 18

MSB Vendor-Value = 3 (Active Stop) 19

20

21

(LSB) 22

Parameter Name: R-PA10 Connection ID

Type = 1AH 23

Length = 0CH 24


26

27

(LSB) 28

Vendor-Type = 29H 29


(MSB) Vendor-Value = PCF Session Identifier 31

32

33

(LSB) 34

Parameter Name: Airlink Sequence Number

Type = 1AH 35

Length = 0CH 36


38


D-37

0 1 2 3 4 5 6 7 Octet

39

(LSB) 40

Vendor-Type = 2AH 41


(MSB) Vendor-Value = Sequence Number 43

44

45

(LSB) 46

Parameter Name: Active Connection Time

Type = 1AH 47

Length = 0CH 48


50

51

(LSB) 52

Vendor Type = 31H 53

Length = 06H 54

(MSB) Value = Active Connection Time (in seconds) 55

56

57

(LSB) 58

1

4.2.14 Normal Vendor/Organization Specific Extension (NVSE) 2

This element may be included in the A11-Registration Request, A11-Registration Reply, A11-3

Registration Update, and A11-Session Update messages to convey information between the PCF and the 4

PDSN. Any new Application Types or Application Sub-Types supported after IOS v4.0 shall be added to 5

this element. The coding format of the NVSE defined herein conforms to [26]. 6

This element may be included in the A11-Registration Request message to convey the Previous and 7

Current Access Network Identifiers (PANID, CANID) to the PDSN. 8

This element may be included in A11-Registration Reply, A11-Registration Request, or A11-Session 9

Update messages to convey the Anchor PDSN Address for fast handoff when the PCF establishes an A10 10

connection. When sent by the PCF, the Anchor P-P Address is the address received in the fast handoff 11

request from the source BS/PCF. When sent by the PDSN, the Anchor P-P Address value is copied from 12

the corresponding A11-Registration Request if the PDSN accepts a fast handoff request. It is the PDSN’s 13

own P-P address if the PDSN supports fast handoff and becomes the anchor PDSN. 14

If the receiver does not recognize the NVSE Vendor-ID or the NVSE Application Type or Application 15

Sub Type, it shall ignore the NVSE and process the remainder of the message to the extent possible. 16

This element may be included in the A11-Registration Request message to send the All Dormant 17

Indicator for the case of an MS in fast handoff. The serving PCF shall send the All Dormant Indicator to 18

its supporting PDSN when all service instances for the MS become dormant. The PCF shall send this 19


D-38

indication in the same message as the Active Stop Airlink Record for the last service instance that 1

becomes dormant. 2

This element may be included in the A11-Registration Update message to indicate the reason the PDSN 3

initiated the release of the packet data session. 4

This element may be included in the A11-Registration Reply or A11-Session Update messages to change 5

the value of a session parameter. 6

This element may be included in the A11-Registration Request message to indicate the service option of a 7

service instance. 8

This element may be included in the A11-Session Update message to indicate a PDSN Identifier. 9

This element may be included in the A11-Registration Request message to indicate the features enables 10

by the PCF. 11

This element may be included in the A11-Registration Reply message to indicate the features enabled by 12

the PDSN. 13

For HRPD, this element may be included in the A11-Registration Request message to indicate SO, 14

SR_ID, Key, Protocol Type for auxiliary A10 connection(s). 15

For HRPD, this element may be included in the A11-Registration Request message to convey QoS 16

information (IP Flow ID, Flow State, Requested QoS, and Granted QoS). Each instance of the NVSE IE 17

with QoS Information application type contains QoS information for IP flows associated with one 18

direction of one A10 connection. For transmission of QoS Information in both directions of an A10 19

connection or for multiple A10 connections (i.e., multiple SR_IDs) in the same A11-Registration 20

Request, multiple instances of the QoS Information application type NVSE are used. 21

22

4.2.14 Normal Vendor/Organization Specific Extension (NVSE)

0 1 2 3 4 5 6 7 Octet

A11 Element Identifier (Type) 1

Length 2

(MSB) Reserved 3

(LSB) 4

(MSB) 3GPP2 Vendor ID 5

6

7

(LSB) 8

Application Type 9

Application Sub Type 10

(MSB) Application Data 11

12

… …

(LSB) k

Note that the Application Type and the Application Sub Type together correspond to the Vendor- NVSE-23

Type as defined in [26]. 24

Type: 86H 25


D-39


Length field. 2

3GPP2 Vendor ID: 00 00 15 9FH. 3

Application Type: This field indicates the type of application to which the extension relates. 4

The supported values are listed in Table 4.2.14-1. 5

Application Sub Type: This one octet field indicates the Application sub-type within the 6

Application Type. The supported values are listed in Table 4.2.14-1. 7

Table 4.2.14-1 Application Sub Type 8



ANID 01H A11-Registration Request 3.1 Access Network Identifiers (ANID)

04H


Anchor P-P Address 01H A11-Registration Request A11-Registration Reply A11-Session Update

3.1 3.2 3.5

PDSN Identifier 05H


All Dormant Indicator 01H A11-Registration Request 3.1 Indicators 06H


PDSN CODE 01H A11-Registration Update 3.3 PDSN Code 07H


RN-PDIT 01H A11-Registration Reply A11-Session Update

3.2 3.5

Always-On 02H A11-Registration Reply A11-Session Update

3.2 3.5

QoS Mode 03H A11-Registration Request 3.1

Session Parameter 08H


Service Option Value 01H A11-Registration Request 3.1 Service Option 09H


Flow Control Enabled 01H A11-Registration Reply 3.2

Packet Boundary Enabled

02H A11-Registration Reply 3.2

PDSN Enabled Features 0AH


Short Data Indication Supported

01H A11-Registration Request 3.1

GRE Segmentation Enabled


PCF Enabled Features 0BH


Additional Session Information

01H A11-Registration Request A11-Registration Reply

3.1 3.2

Additional Session Information

0CH



D-40



Forward QoS Information


Reverse QoS Information


Subscriber QoS Profile

03H A11-Registration Reply A11-Session Update

3.2 3.5

QoS Information 0DH



Application Data: For Application Type 04H (Access Network Identifiers), this field 1

contains the PANID of the source PCF in the PANID field (octets 11-15) 2

and the ANID of the target PCF in the CANID field (octets 16-20). The 3

PANID and CANID fields are formatted as specified for the Access 4

Network Identifiers element (refer to [16]) from octet 3-7. If PANID 5

information is not available, it shall be coded as all zeros. The CANID 6

field shall be populated with the PCF’s own ANID. 7

For Application Type 05H (PDSN Identifier), this field contains an IPv4 8

address in octets 11-14. This is the Anchor P-P Address. The Anchor P-P 9

Address is the P-P interface address (refer to [8]) of the anchor PDSN. 10

For Application Type 06H (Indicators), this field contains the All 11

Dormant Indicator in octets 11-12. A value of ‘00 00H’ indicates that all 12

MS packet data service instances are dormant. All other values are 13

reserved. 14

For Application Type 07H (PDSN CODE), the field contains a PDSN 15

Code indicating the reason the packet data connection is being released 16

by the PDSN. The PDSN Code values and their meanings are listed in 17

Table 4.2.14-2. 18

Table 4.2.14-2 PDSN Code Values 19

Hex Value

Decimal Value

PDSN Code

C1H 193 Connection Release - reason unspecified C2H 194 Connection Release - PPP time-out C3H 195 Connection Release - registration time-out C4H 196 Connection Release - PDSN error C5H 197 Connection Release - inter-PCF handoff C6H 198 Connection Release - inter-PDSN handoff C7H 199 Connection Release - PDSN OAM&P intervention C8H 200 Connection Release - accounting error CAH 202 Connection Release - user (NAI) failed authentication

All other values reserved

For Application Type 08H (Session Parameter) and Application Sub-20

Type 01H, the Application Data field contains the Radio Network Packet 21

Data Inactivity Timer (RN-PDIT) value in seconds. This field is one 22

octet in length and has range 01H–FFH, corresponding to timer values 1–23

255 seconds. For Application Sub Type 02H (Always-on indicator), the 24

Application Data is zero bytes in length. 25


D-41

For Application Type 08H (Session Parameter) and Application Sub-1

Type 03H (QoS Mode), the Application data field is one octet in length 2

and indicates whether IP flow based QoS is available for the current 3

personality of the AT. The application data field is coded as follows: 4

5

0 1 2 3 4 5 6 7 Octet

(MSB) QoS Mode (LSB) 1

QoS Mode: 6

Table 4.2.14-3 QoS Mode Values 7

QoS Mode Description

00H The AT and the AN apply air interface protocol that IP flow based QoS is unavailable.

01H The AT and the AN apply air interface protocol that IP flow based QoS is available.

8

For Application Type 09H (Service Option), this field contains the 9

Service Option value for the service instance associated with the A10 10

connection. 11

For Application Type 09H, the Application Data field is coded as follows: 12

0 1 2 3 4 5 6 7 Octet


(LSB) 2

Service Option: 13

Table 4.2.14-43 1x Service Option Values 14


Description

0021H 3G High Speed Packet Data 003CH Link Layer Assisted Header Removal 003DH Link Layer Assisted RObust Header Compression

Table 4.2.14-5 HRPD Service Option Values 15


Description

003BH HRPD Main Service Connection 00 40H HRPD Auxiliary Service Connection

For Application Type 0AH (PDSN Enabled Features) and Application 16

Sub-Type 01H (Flow Control Enabled), the Application Data field is 17

zero bytes in length. This Application Sub-Type is included if the PDSN 18

enables flow control for the corresponding A10 connection. 19

For Application Type 0AH (PDSN Enabled Features) and Application Sub-Type 02H (Packet Boundary 20

Enabled), the Application Data field is zero bytes in length. This 21

Application Sub-Type is included if the PDSN guarantees packet 22


D-42

boundaries either by encapsulating one packet in one GRE frame or by 1

supplying GRE segmentation indication in the GRE frame (if supported 2

by the RAN) for the corresponding A10 connection. 3

4

For Application Type 0BH (PCF Enabled Features) and Application 5

Sub-Type 01H (Short Data Indication Supported), the Application Data 6

field is zero bytes in length. This Application Sub-Type is included by 7

the PCF in the A11-Registration Request message to request Short Data 8

Indications via the GRE header. 9

For Application Type 0BH (PCF Enabled Features) and Application 10

Sub-Type 02H (GRE Segmentation Enabled), the Application Data field 11

is zero bytes in length. This Application Sub-Type shall be included if 12

the PCF is capable of receiving the GRE segmentation attribute in the 13

GRE header for the corresponding A10 connection, for packets 14

fragmented over one or more GRE frames. 15

For Application Type 0CH (Additional Session Information), the 16

Application Data field is coded as follows. 17

0 1 2 3 4 5 6 7 Octet

GRE Key Information Entry { 1-6:

Entry Length 1

SR_ID = [00H-1FH] 2


(LSB) 4

(MSB) Protocol Type 5

(LSB) 6

(MSB) Key 7

8

9

(LSB) 10

(MSB) Source IP Address 11

12

13

(LSB) 14


Entry Length: This field contains the number of octets in this entry following the Entry 18

Length field as a binary number. 19

SR_ID: This field contains the identifier of the service connection associated 20

with this A10 connection. 21

Service Option: This field contains the service option for the A10 connection associated 22

with the value in the SR_ID field. 23

Table 4.2.14-6 HRPD - Service Option Values 24


Description


D-43

00 40H HRPD Auxiliary Service Connection

Protocol Type: This field is used to indicate the protocol type to be tunneled across the 1

A10 interface, and contains the same value that is used in the Protocol 2

Type field in the GRE header on the associated A10 connection when the 3

packet doesn’t include GRE attributes. This field is set to 0x88 81H 4

(Unstructured Byte Stream). 5

Key: This is a four octet field. This field is used to indicate the A10 6

connection identification, and contains the same value that is used in the 7

Key field in the GRE header on the associated A10 connection. 8

Source IP Address: This field identifies the IPv4 address of the PCF that terminates the A10 9

connection identified in this entry. Note that this address may be 10

different from the source IP address of other A10 connections (including 11

the main A10 connection) and different from the source IP address of the 12

message containing this IE. 13

For Application Type 0DH (QoS Information) and Application Sub-Type 14

01H (Forward QoS Information), the Application Data field specifies all 15

of the forward IP flow(s) that are associated with a given service 16

connection. It is coded as follows. 17

0 1 2 3 4 5 6 7 Octet

SR_ID = [00H-1FH] 1

Use IP Flow

Discrimi-nation =

[0,1]

DSCP Included

Reserved = [0 0000] 2


Forward Flow Entry {Forward Flow Count :

Entry Length n

Forward Flow ID n+1

Reserved DSCP Flow State

n+2

Forward Requested QoS Length n+3

(MSB) Forward Requested QoS n+4

… … (LSB) p

Forward Granted QoS Length p+1

(MSB) Forward Granted QoS p+2

… … (LSB) q

}Forward Flow Entry

18


Use IP Flow Discrimination: This field indicates if the PDSN shall include GRE extension for 20

IP flow discrimination. If this field is set to '0', the PDSN shall 21


D-44

not include the GRE extension for IP flow discrimination in the 1

bearer packets for the A10 connection identified in the SR_ID 2

field of this Forward Flow Entry. Otherwise (set to '1') it 3

indicates that the GRE extension for IP flow discrimination shall 4

be included. 5

DSCP Included: This field indicates whether DSCP values are included in this 6

element. If option 1c in section 2.6.2 of the transport document is 7

used, then the value shall be set to ‘1’. Otherwise, the value shall 8

be set to ‘0’ and all DSCP fields in this element shall be ignored. 9

Forward Flow Count: This field indicates the number of Flow ID Entry contained in 10

this Forward QoS Information Entry. 11



Forward Flow ID: This field contains the flow ID of a given forward IP flow. Refer 14


DSCP: If DSCP Included = ‘1’, then this field contains the DSCP value 16

of the flow identified in the corresponding Forward Flow ID 17

field. Otherwise, this field shall be set to ‘00 0000’ and shall be 18

ignored. 19

Flow State: This field indicates the IP flow state of the flow identified in the 20

corresponding Flow ID field. This field is set to '0' if it is 21

deactivated. This field is set to '1' if it is activated. 22

Forward Requested QoS Length: This field contains the number of octets in the Forward 23

Requested QoS field as a binary number. 24

Forward Requested QoS: For HRPD systems, this field contains the requested QoS Sub 25



Forward Granted QoS Length: This field contains the number of octets in the Forward Granted 28

QoS field as a binary number. 29

Forward Granted QoS: For HRPD systems, this field contains the granted QoS Sub Blob 30


For Application Type 0DH (QoS Information) and Application 32

Sub-Type 02H (Reverse QoS Information), the Application Data 33

field specifies all of the reverse IP flow(s) that are associated 34

with a given service connection. It is coded as follows. 35

0 1 2 3 4 5 6 7 Octet

Reserved SR_ID 1



Entry Length n

Reverse Flow ID n+1

Reserved Flow State

n+2

Reverse Requested QoS Length n+3

(MSB) Reverse Requested QoS n+4


D-45

0 1 2 3 4 5 6 7 Octet

… … (LSB) p

Reverse Granted QoS Length p+1

(MSB) Reverse Granted QoS p+2

… … (LSB) q

}Reverse Flow Entry

Reverse Flow Count: This field indicates the number of Flow ID Entry contained in 1

this Reverse QoS Information Entry. 2




Reverse Flow ID: This field contains the flow ID of a given reverse IP flow. Refer 6


Flow State: This field indicates the IP flow state. This field is set to '0' if it is 8

deactivated. This field is set to '1' if it is activated. 9

Reverse Requested QoS Length: This field contains the number of octets in the Reverse 10

Requested QoS BLOB field as a binary number. 11

Reverse Requested QoS: For HRPD systems, this field contains the requested QoS Sub 12



Reverse Granted QoS Length: This field contains the number of octets in the Reverse Granted 15

QoS field as a binary number. 16

Reverse Granted QoS: For HRPD systems, this field contains the granted QoS Sub Blob 17


For Application Type 0DH (QoS Information) and Application Sub-Type 03H (Subscriber QoS Profile), 19

the Application Data field is coded as follows. 20

0 1 2 3 4 5 6 7 Octet


2

3

… … (LSB) n

Subscriber QoS Profile: This field contains the Subscriber QoS Profile information sent from the 21

PDSN to the RAN. Refer to [8] for detailed information. 22

23

24

25

26


E-1

Annex E A12 RADIUS Attributes (Normative) 1

This is the general Vendor Specific Format for all 3GPP2 RADIUS attributes. The type and vendor ID are 2

the same for every attribute. The vendor-ID of 5535 (159FH) is used to indicate 3GPP2. Note that all 3

integers are in network byte order. 4

5

1 2 3

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

Type Length Vendoer-ID

Vendoer-ID (cont) Vendoer-Type Vendoer-Length

Vendor-Vvalue

Figure Annex EAnnex EAnnex EAnnex E-1111 3GPP2 RADIUS Attribute Format 6

HRPD Access Authentication: Indicates whether the Access Request is in the context of access 7

authentication. This optionally appears in an Access-Request message, on the A12 interface. 8

Type = 26 (1AH) 9

Length = 12 (0CH) 10

Vendor-ID = 5535 (0000 159FH) 11

Vendor-Type = 60 (3CH) 12

Vendor-Length = 6 (06H) 13

Vendor-Value = 1 (0000 0001H) - HRPD Access Authentication 14

15

AT Hardware Identifier: Indicates the AT hardware identifier type and the AT hardware identifier value 16

in the context of AT authentication. This information provides the hardware identity of the AT, which is 17

obtained via air-interface signaling. The hardware identity type is based on the encoding specified in the 18

IOS for Mobile Identity. If the AN requests the AT hardware identity, then this VSA is present in an 19

Access-Request message, over the A12 interface. 20

21

1 2 3

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

Type Length Vendor-ID

Vendor-ID (cont) Vendor-Type Vendor-Length

Sub-Type (=1) Vendor-value

Length Vendor-Value (=AT hardware identifier type)

………………………………………………..

Sub-Type (=2) Length

Vendor-Value (=AT hardware identifier value)

………….

Vendor-Value (=AT hardware identifier value)

Figure Annex E-2 AT Hardware Identifier 22


E-2

Type: 26 (1AH) 1

Length = Variable, greater than 8 2

Vendor ID: 5535 (0000 159FH) 3

Vendor-Type = 61 (3DH) 4

Vendor-Length = Variable, greater than 2 5

6

Sub-Type = 1 (01H) 7

Length = 6 (06H) 8

Vendor-Value = AT hardware identifier type (AT Type of Identity Coding) as specified in [16] 9

Sub-Type = 2 (02H) 10

Length = Length of the AT hardware identifier (e.g., ESN, MEID) as specified in [10] 11

Vendor-Value = AT hardware identifier value as specified in [10] 12

13

14

15

16

Annex FRevision History 17

18

June 14, 2001 A.S0007-0 Ballot text.

October 15, 2001 A.S0007-0 Pre-publication text.

May 12, 2003 A.S0008-0 Ballot resolution text (including August 09, 2002 updates for IOS v4.1 bug fixes and errata through July 2002).

19

20

21


E-3

No text. 1

2

3

Documents

Interoperability Specification (IOS) for High Rate Packet ... · Interoperability Specification (IOS) for High Rate Packet ... ... 1 Foreword