A.S0008-0_v3.0_callflow_evdo

8/2/2019 A.S0008-0_v3.0_callflow_evdo

1/126

A.S0008-0 v3.0 (TIA-878-1)May 2003 IOS HRPD Publication Version

COPYRIGHT 2003, 3GPP2

3GPP2 and its Organizational Partners claim copyright in this document and individual Organizational Partnersmay copyright and issue documents or standards publications in individual Organizational Partner's name based onthis 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 tothat Organizational Partner. See www.3gpp2.org for more information.

1

3GPP2 A.S0008-0 v3.0

Date: May 2003

Interoperability Specification (IOS) for High Rate Packet2Data (HRPD) Access Network Interfaces 3

Revision 04

(Post SDO Ballot, Pre-SDO Publication Version) 56

7


2/126


3/126


i

Table of Contents1

Foreword................. .................. .................. ................. .................. .................. .................. ................. .......... v 2

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

1.1 Scope.............................................................................................................................................1-1 4

1.2 Document Convention ................. ................. .................. ................. ................. .................. .......... 1-1 5

1.3 References.....................................................................................................................................1-1 6

1.3.1 TIA / EIA .................. .................. .................. ................. .................. .................. ................. ..........1-1 7

1.3.2 3GPP2 ................ .................. .................. .................. .................. .................. ................. ................ 1-2 8

1.3.3 Other ................. ................. .................. .................. .................. ................. ................. .................. .1-2 9

1.4 Terminology..................................................................................................................................1-3 10

1.4.1 Acronyms......................................................................................................................................1-3 11

1.4.2 Definitions ................. .................. .................. .................. ................. .................. ................ ..........1-4 12

1.5 HRPD IOS Architecture Reference Model...................................................................................1-5 131.6 HRPD Micro-Mobility and Macro-Mobility Concepts ................ ................ ............... ................ .1-5 14

1.7 Compatibility with IS-2001 Standards..........................................................................................1-5 15

1.8 HRPD IOS Assumptions...............................................................................................................1-6 16

2 HRPD IOS Interfaces....................................................................................................................2-1 17

2.1 A8-A9 (AN - PCF) Interface ................... .................. .................. .................. .................. ............. 2-1 18

2.2 A10-A11 (PCF - PDSN) Interface................................................................................................2-1 19

2.3 A12 (AN - AN-AAA) Interface....................................................................................................2-1 20

2.3.1 PPP Session...................................................................................................................................2-2 21

2.3.1.1 Establishment..............................................................................................................2-2 22

2.3.1.2 Termination.................................................................................................................2-2 23

2.3.1.3 Access Authentication ............... ................. ................. ................. ................. ............. 2-2 24

2.3.2 AN-AAA Support ................. .................. .................. ................... .................. .................. ............. 2-2 25

2.3.3 AN-AAA Requirements................................................................................................................2-3 26

2.4 A13 (AN - AN) Interface..............................................................................................................2-3 27

2.4.1 A13 Interface Network/Transport Protocol Specification ................ ............... ................ ............. 2-4 28

2.4.2 A13 Interface Procedures..............................................................................................................2-4 29

2.4.2.1 A13-Session Information Request ................ ................ ................. ................ ............. 2-5 30

2.4.2.1.1 Successful Operation............... ................. ................. ................. ................. ............... 2-5 31

2.4.2.1.2 Failure Operation........................................................................................................2-5 32

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



2.4.2.3 A13-Session Information Confirm..............................................................................2-5 36


4/126

A.S0008-0 v3.0 (TIA-878-1)IOS HRPD Publication Version May 2003

ii



2.4.2.4 A13-Session Information Reject.................................................................................2-6 3



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

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

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

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

3.2 Re-authentication..........................................................................................................................3-4 10

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

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

3.3 Data Delivery................................................................................................................................3-6 13

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

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

3.4 Connection Release.......................................................................................................................3-8 16

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

3.4.2 Connection Release on HRPD Network - Initiated by the AN.....................................................3-9 18

3.5 Session Release...........................................................................................................................3-10 19

3.5.1 HRPD Session Release - Initiated by the AT (A8 Connection Established) .............. ................ 3-10 20

3.5.2 HRPD Session Release - Initiated by the AT (No A8 Connection Established) ............. ...........3-11 21

3.5.3 HRPD Session Release - Initiated by the AN (A8 Connection Established)..............................3-12 22

3.5.4 HRPD Session Release - Initiated by the AN (No A8 Connection Established)........................3-13 23

3.5.5 Packet Data Session Release - Initiated by the PDSN................................................................3-14 24

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

3.6.1 AN-AN Dormant Handoff with Successful Retrieval of HRPD Session Information ............... 3-15 26

3.6.2 Dormant AN-AN Handoff with HRPD Session Information Transfer Failure ................ ..........3-17 27

3.7 Active HRPD Session.................................................................................................................3-19 28

3.7.1 AN Detects a Loss of the Airlink During an Active HRPD Session ............... .................. .........3-19 29

3.7.2 AT Initiated Packet Data Session Establishment from an Established HRPD Session .............. 3-20 30

4 HRPD and cdma2000 IOS Transition Call Flows ................ .................. .................. .................. ..4-1 31

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

4.1.1 cdma2000 to HRPD Dormant Packet Data Session Handoff - Existing HRPD Session.......... ....4-1 33

4.1.2 cdma2000 to HRPD Dormant Packet Data Session Handoff - New HRPD Session................. ...4-3 34

4.1.3 HRPD to cdma2000 Dormant Packet Data Session Handoff ................. ................ ................. .....4-5 35

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

4.2.1 MS/AT Terminated Voice Call During Active HRPD Data Packet (Intra-PDSN/Inter-PCF) .....4-7 37


5/126


iii

4.2.2 AT Leaving During an Active 1xEV-DO Data Session ................ .................. .................. ...........4-9 1

4.2.3 MS/AT Terminated Voice Call During Active HRPD Packet Data Session (Intra-PCF) ..........4-11 2

4.3 cdma2000 to HRPD Active Packet Data Session Handoff.........................................................4-13 3

4.4 Status Management Supported by Feature Invocation................................................................4-14 4

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

5.1 Message Definitions......................................................................................................................5-1 6

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

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

5.1.1.2 A13-Session Information Confirm..............................................................................5-2 9

5.1.1.3 A13-Session Information Reject.................................................................................5-2 10

5.1.1.4 A13-Session Information Response............................................................................5-3 11

5.2 Information Element Definitions ................ ................. ................ ................. ................ ................ 5-5 12

5.2.1 A13 Information Element Definitions ................. ................ ................. ................ ................. .......5-5 13

5.2.1.1 Information Element Identifiers..................................................................................5-5 14

5.2.1.2 A13 Message Type .................. ................. ................. .................. ................. .............. 5-5 15

5.2.1.3 Unicast Access Terminal Identifier (UATI 128). ............... ................. ................ ....... 5-5 16

5.2.1.4 Security Layer Packet ................ ................. ................. ................. ................. ............. 5-6 17

5.2.1.5 SectorID............... ................. .................. ................. ................. ................. ................. 5-6 18

5.2.1.6 Cause...........................................................................................................................5-6 19

5.2.1.7 Mobile Identity (MN ID) ............... ................. ................. ................. ................. ......... 5-7 20

5.2.1.8 PDSN IP Address........................................................................................................5-7 21

5.2.1.9 Access Network Identifiers.........................................................................................5-8 22

5.2.1.10 Session State Information Record...............................................................................5-8 23

5.3 Timer Definitions..........................................................................................................................5-9 24

5.3.1 Timer Descriptions........................................................................................................................5-9 25

5.3.1.1 Timer T airdrop ................................................................................................................5-9 26

5.3.1.2 Timer T A13req ................................................................................................................5-9 27

5.3.1.3 Timer T airdrop ................................................................................................................5-9 28

Annex A A8-A9 (AN - PCF) Interface Change Text .................. ................... ................... .................. .. A-1 29

Annex B A10-A11 (AN/PCF - PDSN) Interface Change Text ................. .................. .................. ........ B-1 30

Annex C A12 RADIUS Attributes .................. ................... .................. .................. .................. ............. C-1 31

Annex D Revision History .................. ................. .................. .................. ................. .................. .......... D-1 32

33

34


6/126


iv

Table of Figures1

2

Figure 1.5-1 HRPD IOS Architecture Reference Model......................................................................1-5 3

Figure 1.6-1 Packet Data Mobility Architecture for HRPD ............... ................ ................. ................ .1-5 4

Figure 2.3-1 RADIUS Protocol Reference Model ............... ................. .................. ................. ............2-2 5

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

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

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

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

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

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

Figure 3.4.1-1 AT Initiated Connection Release.....................................................................................3-8 12

Figure 3.4.2-1 AN Initiated Connection Release.....................................................................................3-9 13Figure 3.5.1-1 AT Initiated HRPD Session Release (A8 Connection Established) .............. ............... .3-10 14

Figure 3.5.2-1 AT Initiated HRPD Session Release (No A8 Connection Established) ............. ........... 3-11 15

Figure 3.5.3-1 AN Initiated HRPD Session Release (A8 Connection Established)..............................3-12 16

Figure 3.5.4-1 AN Initiated HRPD Session Release (No A8 Connection Established)... ............... ......3-13 17

Figure 3.5.5-1 PDSN Initiated Packet Data Session Release ............... ................ ................ ............... ..3-14 18

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

Figure 3.6.2-1 Inter-PCF/Intra-PDSN Dormant AN-AN HO - Transfer Failure ................. ................. 3-17 20

Figure 3.7.1-1 AN Detects Loss of Airlink During Active HRPD Session...........................................3-19 21

Figure 3.7.2-1 AT Initiated Packet Data Session Establishment from Established HRPD Session...... 3-20 22

Figure 4.1.1-1 cdma2000 to HRPD Dormant Packet Data Session HO - Existing HRPD Session ........4-1 23

Figure 4.1.2-1 cdma2000 to HRPD Dormant Packet Data Session Handoff - New HRPD Session..... ..4-3 24

Figure 4.1.3-1 HRPD to cdma2000 Dormant Packet Data Session Handoff ............... ................ ...........4-5 25

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

Figure 4.2.2-1 AT Leaving During an Active 1xEV-DO Data Session .................. .................. .............. 4-9 27

Figure 4.2.3-1 Voice Call Termination During Active HRPD Packet Data Session (Intra-PCF).........4-11 28

Figure 4.4-1 Terminal Based Status Management (Using Feature Invocation) .............. ............... ....4-14 29

Figure C-1 3GPP2 RADIUS Attribute Format ............... .................. .................. ................. ............. C-1 30

31

32

33


7/126


v

Foreword1

While based on TIA/EIA/IS-2001-A, the interfaces defined in this document are compatible with a2TIA/EIA/IS-2001 or higher release. This document describes the protocol and some generic procedures to3support the following High Rate Packet Data (HRPD) IOS features. Conformance to the IOS may be4claimed on a feature-by-feature and/or interface-by-interface basis. If conformance on a given interface is5claimed for the HRPD IOS feature, it shall be supported as defined in this standard.6

Features:7

Access authentication8

Data delivery9

Session handoff between ANs10

Status management11

12

13


8/126


vi

No text.1

2


9/126


1-1

1 Introduction1

2

1.1 Scope3

This document provides an interoperability specification for a Radio Access Network (RAN) that4supports HRPD. This document contains message procedures and formats necessary to obtain this inter-5operability.6 AT originates a HRPD session (including access authentication)7 HRPD data delivery (both AT terminated and AT originated)8 Re-authentication of an AT9 HRPD connection release10 HRPD session release11 Dormant handoff of HRPD AT between ANs served by the same PDSN12 Dormant (voice or packet) cdma2000 handoff to/from HRPD, served by the same PDSN13 MS/AT terminated voice call during active HRPD data session14 cdma2000 to HRPD active packet data session handoff 15 Loss of the airlink during an active HRPD session16 Status Management supported by feature invocation17

18

Interface DescriptionA8-A9 (AN - PCF) Interface TIA/EIA/IS-2001-A delta text ( Annex A) A10-A11 (PCF - PDSN) Interface TIA/EIA/IS-2001-A delta text ( Annex B)

A12 (AN - AN-AAA) Interface New HRPD IOS defined text (Section 2.3)

A13 (AN - AN) Interface New HRPD IOS defined text (Section 2.4)

19

1.2 Document Convention20

Shall and shall not identify requirements to be followed strictly to conform to the standard and from21which no deviation is permitted. Should and should not indicate that one of several possibilities is22recommended as particularly suitable, without mentioning or excluding others; that a certain course of 23action is preferred but not necessarily required; or (in the negative form) that a certain possibility or24course of action is discouraged but not prohibited. May and need not indicate a course of action25permissible within the limits of the standard. Can and cannot are used for statements of possibility26and capability, whether material, physical, or causal.27

28

1.3 References29

1.3.1 TIA / EIA30

For ease of cross referencing, the Telecommunications Industry Association (TIA) / Electronics Industry31Association (EIA) references provided in this section are aligned with the 3GPP2 references, provided in32section 1.3.2. For consistency between RAN specifications, the most commonly referenced documents33[1~17] are maintained or left as Reserved if not used in this specification.34

[1] TIA/EIA/IS-2000-A-2, cdma2000 Standards for Spread Spectrum Systems Release A, March352000.36


10/126


11/126


1-3

[21] RFC 1750, Randomness Recommendations for Security , December 1994.1

[22] RFC 1994, PPP Challenge Handshake Authentication Protocol (CHAP) , August 1996.2

[23] RFC 2002, IP Mobility Support , October 1996.3

[24] RFC 2486, The Network Access Identifier , January 1999.4

[25] RFC 2865, Remote Authentication Dial In User Service (RADIUS) , June 2000.5

6

1.4 Terminology7

8

1.4.1 Acronyms9

AAA Authentication, Authorization and AccountingACCM Async-Control-Character-Map

AN Access Network ANID Access Network IdentifiersAT Access TerminalBS Base StationBSC Base Station ControllerCANID Current Access Network IdentifiersCHAP Challenge Handshake Authentication ProtocolCVSE Critical Vendor/Organization S ecific ExtensionHRPD High Rate Packet DataIMSI International Mobile Subscriber Identity

IOS Inter-Operability SpecificationLCP Link Control ProtocolMAC Medium Access ControlMEI Mobility Event IndicatorMN ID Mobile Node IdentificationMS Mobile StationMSC Mobile Switching CenterNAI Network Access IdentifierNID Network IdentificationPANID Previous Access Network IdentifiersPCF Packet Control FunctionPDSN Packet Data Serving NodePPP Point-to-Point ProtocolPZID Packet Zone IdentificationRADIUS Remote Authentication Dial-In User ServiceSID System IdentificationSKey Session KeyUATI Unicast Access Terminal Identifier


12/126


1-4

1.4.2 Definitions1

Access Authentication A procedure in which the Access Terminal (AT) is authenticated by the AN-2AAA (Access Network Authentication, Authorization and Accounting entity).3

Access Stream The HRPD stream whose end-points are the access terminal and the access net-4work (radio network). This stream is used for access authentication.5

Access Network The network equipment providing data connectivity between a packet switched6data network (typically the Internet) and the access terminals. An access network 7is equivalent to a base station in cdma2000 systems.8

Access Terminal A device providing data connectivity to a user. An access terminal may be9connected to a computing device such as a laptop personal computer or it may be10a self-contained data device such as a personal digital assistant. An access11terminal is equivalent to a mobile station in cdma2000 systems.12

AN-AAA An entity that performs access authentication and authorization functions for the13Access Network.14

Connection A connection is a particular state of the air-link in which the access terminal is15assigned a Forward Traffic Channel, a Reverse Traffic Channel and associated16Medium Access Control (MAC) Channels. During a single HRPD session the17access terminal and the access network can open and can close a connection18multiple times.19

Hybrid MS/AT A device capable of operating on both cdma2000 and HRPD access networks.20

Service Stream The HRPD stream used when exchanging data between the access terminal and21the PDSN.22

HRPD session An HRPD session refers to a shared state between the access terminal and the23access network. This shared state stores the protocols and protocol configurations24that were negotiated and are used for communications between the access25terminal and the access network. Other than to open a session, an access terminal26

cannot communicate with an access network without having an open session.27Note that it is possible that the A10/A11 connection is not established even28though the HRPD session is established. Refer to [10], Section 1.9.29

Packet Data Session An instance of use of packet data service by a mobile user. A packet data session30begins when the user invokes packet data service. A packet data session ends31when the user or the network terminates packet data service. During a particular32packet data session, the user may change locations but the same IP address is33maintained. Refer to [11], Section 1.6.2.34

35


13/126


1-5

1.5 HRPD IOS Architecture Reference Model1

The HRPD IOS messaging and call flows are based on the Architecture Reference Model shown in Figure21.5-1, HRPD IOS.3

Source AccessNetwork (AN)

Target AccessNetwork (AN)

PCFA8

PDSNA9

A10

A11

AN AAAA13AccessTerminal (AT)

A12Air Interface

4

Figure 1.5- 1 HRPD IOS Architecture Reference Model5

1.6 HRPD Micro-Mobility and Macro-Mobility Concepts6

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

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)

8

Figure 1.6- 1 Packet Data Mobility Architecture for HRPD9

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

The A10/A11 interfaces support mobility between PCFs under the same PDSN.11 Mobile IP supports mobility between PDSNs under the same Home Agent.12

1.7 Compatibility with IS-2001 Standards13

The HRPD IOS interface, as defined in this specification, is compatible with a TIA/EIA/IS-2001 or high-14er release, with the provision that the HRPD capabilities are the same as those supported by the inter-15operability specification, for the access network(s) in use. For example, when inter-operating with a16TIA/EIA/IS-2001 system, the portions of this specification related to concurrent services and support for17Previous/Current Access Network Identifiers (PANID/CANID) are not applicable.18


14/126


1-6

Note: When the procedures between TIA/EIA/IS-95-B or cdma2000 and HRPD systems differ, the1HRPD procedures are identified separately within this specification. When the TIA/EIA/IS-2001 text is2applied to the HRPD RAN specification, the procedures related to the MSC shall be ignored. Hard Hand-3off procedures, as defined in [11], are not applicable to HRPD.4

5

1.8 HRPD IOS Assumptions6

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

1. A packet data session may transition from a serving cdma2000 system to a serving HRPD system and8from a serving HRPD system to a serving cdma2000 system.9

2. A unique value, 59 (3BH), is used in the Service Option fields in accounting records transported on10the A9 and A11 interfaces to identify accounting records associated with HRPD packet data service.11

3. For the case of dormant inter-AN inter-PCF handoff, the target PCF may use the PDSN address12received from the source AN to send the A11-Registration Request message. Otherwise, the target13PCF shall use the PDSN selection algorithm (if supported and if the IMSI is available) or internal14algorithms to select a PDSN.15

4. Following a dormant handoff, the target AN sends the SID, NID, PZID triplet (ANID), if received16from the AT, to the target PCF. If the AT does not send the ANID, or the AN chooses not to request17this information from the AT, then the target AN may send the ANID received in the A13-Session18Information Response message from the source AN. If the target PCF supports ANIDs, then it sets19the PANID to the ANID received from the AN, and the CANID to its own ANID in the A1120messages.21

5. For the instance of Packet Application terminated in the AN, the AT shall support Challenge22Handshake Authentication Protocol (CHAP) access authentication. In this case, the AT shall send a23Network Access Identifier (NAI) of the form specified in [24]. 24

6. For the instance of Packet Application terminated in the AN (i.e., AN access authentication), the gen-25eration of the NAI and password are the responsibility of the service provider. The NAI and password26should be chosen and managed using procedures that minimize the likelihood of compromise.27

7. If the access authentication feature is used, the AN shall always propose CHAP as a PPP option in an28initial Link Control Protocol (LCP) Configure-Request during the PPP establishment.29

8. The Mobile Node Identification (MN ID) that is used by the AN and the PCF on A8/A9 and A10/A1130messages is unique within the operators network, and is determined as follows:31

If the HRPD AN uses the access authentication feature, the MN ID field shall be set to the MN ID32value returned by the AN-AAA (e.g., IMSI) following successful access authentication.33

Otherwise, the AN/PCF shall set the MN ID field to a value that conforms to a valid MN ID34format (i.e., IMSI format). In this case, the MN ID is determined by other means.35

9. After the AT indicates it is ready to exchange data on the access stream, the AT and the AN initiate36 PPP procedures according to [19]. 37

10. The AT may support packet data service as specified in [9]. 38

39

40


15/126


2-1

2 HRPD IOS Interfaces1

This section describes the Radio Access Network interfaces associated with this specification. Where2there are differences identified in the application of the IOS to cdma2000 as opposed to HRPD, the terms3in the right column of the following table are used explicitly. Otherwise, the terms in the left column of 4the table shall be mapped to the corresponding terms in the right column when interpreting Annex B and5Annex C of this specification.6

cdma2000 Term HRPD Term

BS ANBase Station Access Network BSC ANBase Station Controller Access Network MS ATMobile Station Access Terminal

7

2.1 A8-A9 (AN - PCF) Interface8

The specification for the A8-A9 interface is defined in [11] with identified bug-fixes applicable to this9interface defined in [12]. While no new signaling information is defined for the interface between the AN10and the PCF, updates to address HRPD (intended to incorporated into a future revision of IS-2001) are11included in Annex B.12

2.2 A10-A11 (PCF - PDSN) Interface13

The specification for the A10-A11 interface is defined in [11] with identified bug-fixes applicable to this14interface defined in [12]. While no new signaling information is defined for the interface between the15PCF and the PDSN, updates to address HRPD (intended to incorporated into a future revision of IS-2001)16

are included in Annex C.17

2.3 A12 (AN - AN-AAA) Interface18

The A12 interface between the AN and the AN-AAA entities is used for the following purposes:191. to transmit data used to perform AN-level access authentication of the AT device (by authenticating20

the results of a CHAP challenge/response operation invoked by the AN).212. to return the MN ID that is used on the A8/A9 and A10/A11 interfaces (following successful access22

authentication of the AT device). This identifier permits handoffs of PDSN packet data sessions23between ANs and between HRPD and cdma2000 systems.24

If the AT device access authentication feature is not used by an HRPD system, the MN ID that is used by25the AN on the A8/A9 and A10/A11 interfaces is determined by other means.26

The A12 interface is based on the Remote Authentication Dial-In User Service (RADIUS) protocol as27defined in [18] and [25]. The interface is shown in Figure 1.5-1. 28

The A12 interface consists of the following messages:29

A12 Access-Request30 A12 Access-Accept31 A12 Access-Reject 32

Note: In the call flows of this document these message names are prefixed with A12, to conform to IOS33notation convention.34


16/126


2-2

Figure 2.3-1 shows the protocol reference model for the A12 interface. The AN-AAA in the visited access1provider and home access provider IP networks communicate via AN-AAA proxy servers and one or2more AN-AAA brokers. Note that the use of AN-AAA brokers is optional.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

4

Figure 2.3- 1 RADIUS Protocol Reference Model5

6

2.3.1 PPP Session7

2.3.1.1 Establishment8

After the AT indicates it is ready to exchange data on the access stream, the AN shall initiate PPP9procedures according to [19] by sending an LCP Configure-Request. PPP shall support transparency in10accordance with section 4.2 of [20]. The AN and AT shall attempt to negotiate a control character11mapping, with the minimum number of escape characters by proposing an Async-Control-Character-Map12(ACCM) of 0x 00000000. Additionally, if no PPP session is present, the AN may re-authenticate the AT13by reinitiating the PPP session.14

2.3.1.2 Termination15

The AN may release the PPP connection after the access authentication of the AT has been performed.16The AN may support a PPP inactivity timer for each PPP session. When the inactivity timer expires, the17AN shall terminate the PPP session.18

2.3.1.3 Access Authentication19

The AT shall support CHAP for the PPP instance on the access stream. If the AN supports access20authentication, the AN shall support CHAP for the PPP instance on the access stream. In this case, the21AN shall always propose CHAP as a PPP option in an initial LCP Configure-Request during the PPP22establishment.23

2.3.2 AN-AAA Support24

If the AN supports access authentication and the A12 interface, the AN shall support the RADIUS client25protocol in accordance with [25] and shall communicate user CHAP access authentication information to26the visited AN-AAA in an Access-Request message on the A12 interface. For an AN-AAA to recognize27that the transaction is related to access authentication, the Access-Request message may contain an addit-28ional 3GPP2 vendor specific attribute. Refer to Annex C, RADIUS Attributes. If the Access-Request29message on the A12 interface contains a 3GPP2 Vendor Specific Attribute, the proxy AN-AAA shall in-30clude the attribute in the Access-Request message forwarded to the home AN-AAA on the A12 interface.31


17/126


2-3

On receipt of the ATs CHAP response, the AN shall send an Access-Request message, on the A121interface, containing at a minimum:2

User-Name (1) 1 = NAI3 CHAP-Password (3) = CHAP ID and CHAP-response4 NAS-IP-Address (4) = IP address of AN5 CHAP-Challenge (60) = challenge value issued by AN6

The Access-Request message may additionally contain:7

HRPD Access Authentication vendor specific attribute (defined in Annex D), which is used to8indicate that the Access-Request message is sent in the context of access authentication.9

Note: The CHAP access authentication password should be cryptographically strong. One recommendat-10ion for password generation can be found in [21], Randomness Recommendations for Security, Section117.1.12

Upon successful access authentication the visited AN-AAA shall send an Access-Accept message to the13AN on the A12 interface. The Access-Accept message shall contain at a minimum the RADIUS Callback-14Id attribute (Type=20) populated with the MN ID (e.g., IMSI) and the String field shall be set as follows:15

0 1 2 3 4 5 6 7 OctetASCII 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.3.3 AN-AAA Requirements16

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

If the AN performs access authentication using CHAP, the AN-AAA receives a RADIUS Access-Request18message on the A12 interface from the AN with CHAP access authentication information. If the AN-19AAA does not have the authority to accept/deny the request, it forwards the request to the home network 20or a peer (e.g., a broker), in accordance with [25]. In this case, the AN-AAA later receives an Access-21Accept message from the home or broker network. The AN-AAA shall then send the Access-Accept22message to the AN, on the A12 interface.23

Communications between AN-AAAs may optionally be protected with IP security. The establishment of 24this security association is outside the scope of this standard. Refer also to [25] for additional RADIUS25security requirements.26

2.4 A13 (AN - AN) Interface27

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

is explained as follows.29

The information content in the target to source direction is as follows:30 Unicast Access Terminal Identifier (UATI). This is the UATI received by the target AN using the31

UATI Color Code and UATI024 received from the AT, which allows the source AN to determine the32session configuration parameters that are requested by the target. Note that some parts of the UATI33determined by the target may not be meaningful. However, it is assumed that the source AN has34enough information to identify the corresponding session.35

1 The numbers in this list correspond to the RADIUS attribute type defined in [25].


18/126


2-4

Security Layer Packet. This is the Security Layer packet, including protocol header and trailer, as1received from the AT.2

Sector ID. The target AN shall set this field to the 128-bit identifier of the sector on which the UATI-3Request message is received.4

The information content in the source to the target direction is as follows:5 MN ID used by the source AN over the A11 interface. This allows the target AN to use the same MN6

Identifier from the previous A10 connection, once a new A10 connection has been setup.7 Session Configuration Parameters. These parameters including the air interface protocols states, allow8

the target AN to continue to use the air interface protocols previously negotiated between the AT and9the source AN.10

PDSN address. This IP v4 address allows the target AN to reconnect (when possible) to the same11PDSN without executing a PDSN re-selection algorithm (if specified) or an internal PDSN selection12algorithm. For the case of dormant inter-AN inter-PCF handoff, the target PCF may use the PDSN13address received from the source AN to send the A11-Registration Request message. Otherwise, the14target PCF shall use the PDSN selection algorithm (if supported) or internal algorithms to select a15PDSN.16

PANID. This information allows the target AN to inform the PDSN of the PANID, in the case that it17is not provided by the AT over the air interface. The PANID, along with CANID information, allows18the PDSN to determine if there is a need to do an agent advertisement.19

Note: The AT may transition a packet data session from a serving HRPD system to a serving20cdma2000 system and back to a serving HRPD system. Therefore, following a dormant handoff, the21target AN shall send the PANID received from the AT to the target PCF. Otherwise, if the AT does22not send the PANID or the AN chooses not to request this information from the AT, then the target23AN may use the PANID received in the A13-Session Information Response message from the source24AN.25

2.4.1 A13 Interface Network/Transport Protocol Specification26

The IOS application is independent of the underlying physical transport medium, which is left to the27discretion of operators and manufacturers. The signaling protocol stack available to operators and28manufacturers for the A13 interface is:29

IOS Application30UDP31IP32Link Layer33Physical Layer34

The following UDP port value is reserved for signaling on the A13 interface:35 A13 (AN-to-AN) 3125/udp - This is the well-known UDP port number to be used for signaling36

interconnection to another AN.37

2.4.2 A13 Interface Procedures38

This section describes the messages and procedures used between ANs on an A13 connection. The pro-39cedure for the A13 interface is a message flow to exchange AT and PDSN information between the ANs.40The information is exchanged via the following messages:41 A13-Session Information Request42 A13-Session Information Response43 A13-Session Information Confirm44 A13-Session Information Reject45

The procedures for how the target AN discovers the source AN and how the target AN determines the46UATI are not specified.47


19/126


2-5

2.4.2.1 A13-Session Information Request1

The A13-Session Information Request message is sent by the target AN to request information about an2AT from a source AN when the target AN does not have this information.3

2.4.2.1.1 Successful Operation4

When the target AN receives a packet from an AT that contains a UATI that is not in a subnet that is5associated with the target AN, the target AN attempts to retrieve session related information from the6source AN for the AT. The target AN sends an A13-Session Information Request message to the source7AN to indicate the information requested. The target AN shall include the determined UATI, Security8Layer Packet and Sector ID. The target AN then starts timer T A13req .9

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

2.4.2.1.2 Failure Operation11

If timer T A13req expires, the target AN may resend the A13-Session Information Request message to the12source AN and restart timer TA13req a configurable number of times. If the A13-Session Information13Response message is not received from the source AN, the target AN may begin a new session14

establishment with the AT.15

2.4.2.2 A13-Session Information Response16

The A13-Session Information Response message is used by the source AN to respond to the target ANs17request to retrieve information about an AT.18


When the source AN receives an A13-Session Information Request message it checks if the session in-20formation for the requested AT exists and if it can authenticate the target AN request. After the source21AN has successfully authenticated the message contained in the A13-Session Information Request22message and has the requested session state information, it sends an A13-Session Information Response23message to the target AN with the requested information.24

Upon receipt of the A13-Session Information Response message, the target AN stops timer T A13req .25

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


None.28

2.4.2.3 A13-Session Information Confirm29

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


When the target AN receives the A13-Session Information Response message from the source AN with33the requested AT information it shall send an A13-Session Information Confirm to the source AN. Upon34receipt of the A13-Session Information Confirm message, the source AN shall remove the stored session35information related to the AT in question.36

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


None.39


20/126


2-6

2.4.2.4 A13-Session Information Reject1

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


When the source AN receives an A13-Session Information Request message and it can not retrieve the5session information or can not authenticate the identity of the target AN, the source AN responds by6sending an A13-Session Information Reject message to the target AN.7

Upon receipt of the A13-Session Information Reject message, the target AN stops timer T A13req . After8sending the A13-Session Information Reject message, the source AN may retain the session information,9if it exists.10

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


None.13

14


21/126


3-1

3 HRPD IOS Call Flows1

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

3.1 AT Originates HRPD Session3

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 Authentication5

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 Exchange8

a. The AT and the AN initiate HRPD session establishment. During this procedure, the AN does not9receive a UATI for an existing HRPD session. Since no session exists between the AT and AN, a10session is established where protocols and protocol configurations are negotiated, stored and used for11communications between the AT and the AN. Refer to [10], Section 5, Session Layer.12


22/126


3-2

b. The AT indicates that it is ready to exchange data on the access stream (e.g., the flow control protocol1for 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 access3authentication. Refer to [19]. 4

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

accordance with [22]. 6

e. When the AN receives the CHAP response message from the AT, it sends an Access-Request7message on the A12 interface to the AN-AAA which acts as a RADIUS server in accordance with8[25]) .9

f. The AN-AAA looks up a password based on the User-name attribute in the Access-Request message10and if the access authentication passes (as specified in [22] and [25]) , the AN-AAA sends an Access-11Accept message on the A12 interface in accordance with [25] (RADIUS). The Access-Accept12message contains a RADIUS attribute with Type set to 20 (Callback-Id), which is set to the MN ID of 13the AT. Refer to Section 2.3.2, AN-AAA Support.14

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

h. If the AN supports the Location Update procedure, the AN updates the ANID in the AT using the16Location Update procedure. The AN may also retrieve the PANID from the AT if necessary. This17step 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-19col for the default packet application bound to the packet data network is in the open state). Note that20this 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 to22establish the A8-Connection and starts timer T A8-setup . The A9-Setup-A8 message shall not be sent23before the AT indicates that it is ready to exchange data on the service stream, as identified in step i.24

k. The PCF recognizes that no A10 connection associated with the AT is available and selects a PDSN.25The PCF sends an A11-Registration Request message to the PDSN which includes the Mobility26

Event Indicator (MEI) within the Critical Vendor/Organization Specific Extension (CVSE). The PCF27starts timer T regreq .28

l. The A11-Registration Request message is validated and the PDSN accepts the connection by return-29ing an A11-Registration Reply message with an accept indication and Lifetime set to the configured30Trp value. If the PDSN has data to send, it includes the Data Available Indicator within the CVSE.31The A10 connection binding information at the PDSN is updated to point to the PCF. The PCF stops32timer T regreq .33

m. The PCF sends the A9-Connect-A8 message to the AN. When the AN receives the A9-Connect-A834message it stops timer T A8-setup .35

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

[9]. 37o. At this point the connection is established and packet data can flow between the AT and the PDSN.38

39

40


23/126


3-3

3.1.2 AT Originates HRPD Session - Unsuccessful Access Authentication1

This scenario describes the call flow for an unsuccessful AT call origination in the AN, due to access2authentication 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 Authentication5

a. The AT and the AN initiate HRPD session establishment. During this procedure, the AN does not6 receive a UATI for an existing HRPD session. Since no session exists between the AT and AN, a7session is established where protocols and protocol configurations are negotiated, stored and used for8communications between the AT and the AN. Refer to [10], Section 5, Session Layer.9


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

d. The AN generates a random challenge and sends it to the AT in a CHAP Challenge message, in13accordance with [22]. 14

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 [25] ).16

f. The AN-AAA looks up a password based on the User-name attribute in the Access-Request message17and if the access authentication fails (as specified in [22] and [25]) , the AN-AAA sends an Access-18Reject message on the A12 interface in accordance with [25] (RADIUS).19

Note: For ANs that perform access authentication, the network requires that no use of a dedicated20resource, 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 [22] .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


24/126


3-4

3.2 Re-authentication1

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 State3

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

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 State7

a. The AN determines that re-authentication of an AT is required and initiates connection establishment8procedures with the AT.9


c. The AT and the AN initiate PPP and LCP negotiations for access authentication. Refer to [19]. This12step 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 in14accordance with [22]. 15

e. When the AN receives the CHAP response message from the AT, it sends an Access-Request16message on the A12 Interface to the AN-AAA which acts as a RADIUS server in accordance with17[25]. 18

f. The AN-AAA looks up a password based on the User-name attribute in the Access-Request message19and if the access authentication passes (as specified in [22] and [25]) , the AN-AAA sends an Access-20Accept message on the A12 interface in accordance with [25] (RADIUS). The Access-Accept21message contains a RADIUS attribute with Type set to 20 (Callback-Id), which is set to the MN ID of 22the AT. Refer to Section 2.3.2, AN-AAA Support.23

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

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

26

27


25/126


3-5

3.2.2 Re-authentication of an AT in Active State1

This scenario describes the call flow associated with re-authentication of an active AT. It is assumed that2the 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

AT Ready to ExchangeData on Service Stream

4

Figure 3.2.2- 1 Re-authentication of an AT in Active State5

a. The AN determines that re-Authentication of an AT is required and indicates to the AT that it wants6to 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 default8packet application bound to the PDSN is in the close state). The AT indicates that it is ready to9exchange data on the access stream (e.g., the flow control protocol for the default packet application10bound 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 [19]. This12step 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 in14accordance with [22]. 15

d. When the AN receives the CHAP response message from the AT, it send an Access-Request message16on the A12 Interface to the AN-AAA which acts as a RADIUS server in accordance with [25]17(RADIUS).18

e. The AN-AAA looks up a password based on the User-name attribute in the Access-Request message19and if the access authentication passes (as specified in [22] and [25]) , the AN-AAA sends an Access-20Accept message on the A12 interface in accordance with [25] (RADIUS). The Access-Accept21message contains a RADIUS attribute with Type set to 20 (Callback-Id), which is set to the MN ID of 22the AT. Refer to Section 2.3.2, AN-AAA Support.23

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

g. If necessary, the AT indicates that it is ready to exchange data on the service stream (e.g., the flow25control protocol for the default packet application bound to the PDSN is in the open state).26

27

28


26/126


3-6

3.3 Data Delivery1

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 State3

In this scenario, it is assumed that the AT has already established a packet data session and also an HRPD4 session, however it does not have an HRPD connection and there is no A8 connection between the AN5and the PCF.6



PCF PDSNAT

a

b

time


d

A9-BS Service Response

A9-BS Service Request

c

e

Page message

h

AN

fA9-Setup-A8

A9-Connect-A8

TA8-setupg

Tbsreq9

Tnet_conn

7

Figure 3.3.1- 1 Network Initiated Call Re-activation from Dormant State8

a. The PDSN sends packet data to the PCF.9b. The PCF sends an A9-BS Service Request message to the AN in order to request packet service, and10

starts timer T bsreq9 .11

c. The AN responds with an A9-BS Service Response. The PCF stops timer T bsreq9 upon receipt of the12A9-BS Service Response message and starts timer T net_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 Forward15Traffic Channel, Reverse Power Control Channel and Reverse Traffic Channel. Refer to [10], Section166.4.5.6, Connection Setup State.17

f. After the traffic channel is established, the AN sends an A9-Setup-A8 message to the PCF with Data18Ready Indicator set to 1 to establish the A8-Connection and starts timer T A8-setup . When the PCF19receives the A9-Setup-A8 message, it stops timer T net_conn .20

g. The PCF sends the A9-Connect-A8 message to the AN. When the AN receives the A9-Connect-A821message it stops timer T A8-setup .22

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

24

25


27/126


3-7

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


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. The6AN assigns a Forward Traffic Channel, Reverse Power Control Channel and Reverse Traffic7Channel. Refer to [10], Section 6.4.5.6, Connection Setup State.8

b. After the traffic channel is established, the AN sends an A9-Setup-A8 message to the PCF with DRI9set to 1 to establish the A8-Connection and starts timer T A8-setup .10

c. The PCF sends the A9-Connect-A8 message to the AN. When the AN receives the A9-Connect-A811message it stops timer T A8-setup . Refer to [11], Section 2.14.7.6, MS Initiated Call Re-activation from12

Dormant State.13

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

15

16


28/126


3-8

3.4 Connection Release1

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

3.4.1 Connection Release on HRPD Network - Initiated by the AT3

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

TregreqA11-Registration Request

A11-Registration Reply

5

Figure 3.4.1- 1 AT Initiated Connection Release 6

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

b. The AN sends an A9-Release-A8 message with a cause value set to Packet call going dormant, to8the PCF to request the PCF to release the A8 connection. The AN starts timer T rel9 .9

c. The PCF sends an A11-Registration Request message to send an Active Stop accounting record to the10PDSN and starts timer T regreq .11

d. The PDSN sends an A11-Registration Reply message to the PCF. The PCF stops timer T regreq upon12receipt of this message.13

e. The PCF initiates procedures for releasing the A8 connection and sends an A9-Release-A8 Complete14message to the AN. The AN stops timer T rel9 . At this time, A10 connection for this call is retained.15

16

17


29/126


3-9

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

b

A9-Release-A8 a

c

AN

TA8-setup


3

Figure 3.4.2- 1 AN Initiated Connection Release4

a. The AN initiates release of the A8 connection by transmitting an A9-Release-A8 message to the PCF5with the cause value set to Packet call going dormant, to request the PCF to release the associated6

dedicated resources. The AN starts timer T rel9 .7b. The PCF acknowledges the A9-Release-A8 message by returning an A9-Release-A8 Complete8

message. The AN stops timer T rel9 .9

c. The AN shall initiate HRPD connection release. This step may occur in parallel with steps a and b.10Refer to [10], Section 6, Connection Layer.11

12

13


30/126


3-10

3.5 Session Release1

This section describes the call flows associated with HRPD session and packet data session releases.2

3.5.1 HRPD Session Release - Initiated by the AT (A8 Connection Established)3

This scenario describes the call flows associated with an HRPD session release initiated by an AT. This4 subsequently leads to a packet data session release, if present. It is assumed that the A8 connection is al-5ready established.6

Session Release(Initiated by the AT)

PCF PDSNAT

a

b

time

c

A9-Release-A8


Trel9d

AN

TregreqA11-Registration Reply (Lifetime=0, Accept)

e

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

7

Figure 3.5.1- 1 AT Initiated HRPD Session Release (A8 Connection Established) 8

a. The AT initiates HRPD session release. Refer to [10], Section 5, Session Layer.9

b. After the AN closes the HRPD session, the AN sends an A9-Release-A8 message with a cause value10set to Normal call release, to the PCF to request the PCF to release the associated dedicated11resource and the associated A10 connection. The AN starts timer T rel9 .12

c. The PCF sends an A11-Registration Request message to the PDSN with a Lifetime timer value of 13zero to close the A10 connection. Accounting data is included in the message. The PCF starts timer14Tregreq . Refer to [11], Section 2.15.5.6, Packet Data Service Session Clearing - MS Initiated.15

d. The PDSN stores the accounting data for further processing and responds with an A11-Registration16Reply message to complete the release of the A10 connection. The PCF stops timer T regreq .17

e. The PCF sends an A9-Release-A8 Complete message to the AN. The AN stops timer T rel9 .18

19

20


31/126


3-11

3.5.2 HRPD Session Release - Initiated by the AT (No A8 Connection Established)1

This scenario describes the call flows associated with an HRPD session release initiated by an AT. This2subsequently leads to a packet data session release, if present. It is assumed that the A8 connection is not3established.4

Session Release(Initiated by the AT)

PCF PDSNAT

a

b

time

c

A9-Update-A8

A9-Update-A8 Ack

Tupd9d

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 (No A8 Connection Established)6

a. The AT initiates HRPD session tear-down. Refer to [10], Section 5, Session Layer.7

b. After the AN closes the HRPD session, the AN sends an A9-Update-A8 message with a cause value8set to Power down from dormant state, to the PCF to request the PCF to release the associated9dedicated resource and the associated A10 connection. The AN starts timer T upd9 .10


d. The PDSN stores the accounting data for further processing and responds with an A11-Registration14Reply to complete the release of the A10 connection. The PCF stops timer T regreq .15

e. The PCF sends an A9-Update-A8 Ack message to the AN. The AN stops timer T upd9 .16

17

18


32/126


3-12

3.5.3 HRPD Session Release - Initiated by the AN (A8 Connection Established)1

This scenario describes the call flow associated with an HRPD session release initiated by the AN. This2subsequently leads to a packet data session release, if present. It is assumed that the A8 connection is al-3ready established.4

PCF PDSNAT

a

b

time

c

Session Release(Initiated by the AN)

d

AN

A9-Release-A8


Trel9

A11-Registration Request (Lifetime=0)

A11-Registration Reply (Lifetime=0, accept)

e

Tregreq

5

Figure 3.5.3- 1 AN Initiated HRPD Session Release (A8 Connection Established)6

a. The AN initiates HRPD session release. Refer to [10], Section 5, Session Layer.7

b. The AN sends an A9-Release-A8 message with a cause value set to Normal call release, to the PCF8to request the PCF to release the associated dedicated resource and the associated A10 connection.9The AN starts timer T rel9 .10

c. The PCF sends an A11-Registration Request message with Lifetime set to zero, to the PDSN. The11PCF starts timer T regreq .12

d. The PDSN sends an A11-Registration Reply message to the PCF. The PCF closes the A10 connection13

for the AT and stops timer T regreq .14

e. The PCF sends an A9-Release-A8 Complete message to the AN. The AN stops timer T rel9 .15

16

17


33/126


3-13

3.5.4 HRPD Session Release - Initiated by the AN (No A8 Connection Established)1

This scenario describes the call flows associated with an HRPD session release initiated by an AN. This2subsequently leads to a packet data session release, if present. It is assumed that the A8 connection is not3established.4

PCF PDSNAT

a

b

time

c

Session Release(Initiated by the AN)

d

AN

A9-Update-A8

A9-Update-A8 Ack

Tupd9



e

Tregreq

5

Figure 3.5.4- 1 AN Initiated HRPD Session Release (No A8 Connection Established)6

a. The AN initiates HRPD session tear-down. Refer to [10], Section 5, Session Layer.7

b. After the AN closes the HRPD session, the AN sends an A9-Update-A8 message with a cause value8set to Power down from dormant state, to the PCF to request the PCF to release the associated9dedicated resource and the associated A10 connection. The AN starts timer T upd9 .10


d. The PDSN stores the accounting data for further processing and responds with an A11-Registration14Reply to complete the release of the A10 connection. The PCF stops timer T regreq .15

e. The PCF sends an A9-Update-A8 Ack message to the AN. The AN stops timer T upd9 .16

17

18


34/126


3-14

3.5.5 Packet Data Session Release - Initiated by the PDSN1

This scenario describes the call flow associated with an A10 release initiated by the PDSN. This pro-2cedure 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



Tregreq

b

A11-Registration Update

A11-Registration Acknowledge

f

g

Tregupd

Connection Release h

4

Figure 3.5.5- 1 PDSN Initiated Packet Data Session Release5

a. The PDSN initiates closure of the A10 connection by sending an A11-Registration Update message to6the PCF. The PDSN starts timer T regupd .7

b. The PCF responds with an A11-Registration Acknowledge message. The PDSN stops timer T regupd .8

c. The PCF sends an A11-Registration Request message with Lifetime set to zero, to the PDSN. The9PCF starts timer T regreq .10

d. The PDSN sends an A11-Registration Reply message to the PCF. The PCF closes the A10 connection11for the AT and stops timer T regreq .12

Note: If there is no existing A8 connection the remaining steps are omitted.13

e. The PCF sends an A9-Disconnect-A8 message to the AN and starts timer T discon9 .14

f. The AN sends an A9-Release-A8 message with a cause value set to Normal call release, to the PCF15to request the PCF to release the associated dedicated resources. The AN starts timer T rel9 . The PCF16stops timer T discon9 .17

g. The PCF acknowledges the A9-Release-A8 message by returning an A9-Release-A8 Complete18message. The AN stops timer T rel9 .19

h. The AN may initiate HRPD connection release. Refer to [10], Section 6, Connection Layer.20

21

22


35/126


3-15

3.6 Dormant Handoff of HRPD AT between ANs - Served by the Same PDSN1

This section describes the call flows associated with AT dormant handoff between ANs.2

3.6.1 AN-AN Dormant Handoff with Successful Retrieval of HRPD Session Information3

This scenario describes the call flow associated with a dormant handoff between ANs when the HRPD4 session information is successfully retrieved over the A13 interface. It is assumed that the AT has crossed5a mobility boundary.6

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

7

Figure 3.6.1- 1 Inter-PCF/Intra-PDSN Dormant AN-AN HO - Successful Operation8

a. The AT and the target AN initiate HRPD session establishment. During this procedure, the target AN9receives the UATI of an existing HRPD session (if available). The UATI can be used as an identifier10for the existing HRPD session when the target AN attempts to retrieve the existing HRPD session11State Information from the source AN.12

b. The target AN sends an A13-Session Information Request message to the source AN to request the13HRPD session information for the AT. The A13-Session Information Request message shall include14the received UATI, the Security Layer Packet and Sector ID. The target AN starts timer T A13req .15


36/126


3-16

c. The source AN validates the A13-Session Information Request and sends the requested HRPD sess-1ion information of the AT to the target AN in an A13-Session Information Response message. The2target AN stops timer T A13req .3

d. The AT and the target AN complete the establishment of the HRPD session. Depending on the state4of the AT and the target AN, either an existing HRPD session may be re-established, or a new HRPD5session may be initiated if required. This step may be null if no further over-the-air signaling is6required.7

e. If the target AN supports the Location Update procedure, the target AN updates the ANID in the AT8using the Location Update procedure. The target AN may also retrieve the PANID from the AT if 9necessary (e.g., the Session Configuration retrieved in step c indicates that the source AN does not10support the Location Update procedure).11

f. The target AN sends an A13-Session Information Confirm to the source AN to indicate that the target12AN has received the HRPD session information. Upon receipt of the A13-Session Information13Confirm message the source AN deletes the associated AT HRPD session information.14

g. The target AN sends an A9-Setup-A8 message, with Data Ready Indicator set to 0, to the target PCF15and starts timer T A8-setup . The handoff indicator of the A9 Indicators IE shall be set to 0.16

h. The target PCF selects the PDSN using the PDSN address provided in the A13-Session Information17Response message or using PDSN selection algorithms as specified in [11], and sends an A11-18Registration Request message to the PDSN. The A11-Registration Request message includes the MEI19within the CVSE. The target PCF starts timer T regreq . Refer to [11], Section 2.15.5.8, Inter-PCF20Dormant Handoff - Mobile Continues to be Served by the Serving PDSN.21

i. The A11-Registration Request message is validated and the PDSN accepts the connection by22returning an A11-Registration Reply message with an accept indication and the Lifetime set to the23configured T rp value. If the PDSN has data to send, it includes the Data Available Indicator within the24CVSE. The A10 connection binding information at the PDSN is updated to point to the target PCF.25The target PCF stops timer T regreq .26

j. The PDSN initiates closure of the A10 connection with the source PCF by sending an A11-Registrat-27ion Update message. The PDSN starts timer T regupd .28

k. The source PCF responds with an A11-Registration Acknowledge message. The PDSN stops timer29Tregupd .30

l. The source PCF sends an A11-Registration Request message with Lifetime set to zero, to the PDSN.31The source AN/PCF starts timer T regreq .32

m. The PDSN sends an A11-Registration Reply message to the source PCF. The source PCF closes the33A10 connection for the AT and stops timer T regreq .34

n. Assuming the Data Availability Indicator was not present in step i, the target PCF responds to the35target AN with an A9-Release-A8-Complete message. The target AN stops timer T A8-setup . Note that36

this step can occur any time after step i.3738

39


37/126


3-17

3.6.2 Dormant AN-AN Handoff with HRPD Session Information Transfer Failure1

This scenario describes the call flow associated with a dormant handoff between ANs when the HRPD2session 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)




A11-Registration Request (Lifetime, MEI)

Access Authentication

Location UpdateProcedures

h

A11-Registration Reply(Lifetime=0, accept)

Complete SessionEstablishment

Initiate SessionEstablishment

Connection Release o

4

Figure 3.6.2- 1 Inter-PCF/Intra-PDSN Dormant AN-AN HO - Transfer Failure5

a. The AT and the target AN initiate HRPD session establishment. During this procedure, the target AN6determines the UATI of an existing HRPD session (if available). The UATI can be used as an7identifier for the existing HRPD session when the target AN attempts to retrieve the existing HRPD8session State Information from the source AN.9

b. The target AN sends an A13-Session Information Request message to the source AN to request the10HRPD session information for the AT. The A13-Session Information Request message shall include11the determined UATI and the Security Layer Packet. The target AN starts timer T A13req .12

c. The source AN cannot validate the A13-Session Information Request or does not have the requested13AT HRPD session information and sends an A13-Session Information Reject message to the target14AN. The target AN stops the timer T A13req .15


38/126


3-18

d. The AT and the target AN complete the establishment of the HRPD session. Depending on the state1of the AT and the target AN, either an existing session may be re-established, or a new HRPD session2may 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 AT4using the Location Update procedure. The target AN may also retrieve the PANID from the AT if 5necessary.6

f. If access authentication is enabled/supported at the target AN, it shall initiate PPP on the access7stream. The AN initiates an access authentication of the AT using CHAP according to [22]. The AN8authenticates the results of the challenge with the AN-AAA, which acts as a RADIUS server9according to [25]. The AN shall use the MN ID received from the AN-AAA in the A12 Access-10Accept message, in messages on the A9/A11 interfaces. Refer to Section 2.3, A12 (AN-AN-AAA)11Interface.12

g. The target AN transmits an A9-Setup-A8 message, with Data Ready Indicator set to 0, to target PCF13and starts timer T A8-setup . The handoff indicator of the A9 Indicators IE shall be set to 0.14

h. The target PCF selects a PDSN for this call using PDSN selection algorithms as specified in [10]. The15target PCF sends an A11-Registration Request message to the selected PDSN. The A11-Registration16

Request message includes the MEI within the CVSE. The target PCF starts timer T regreq . Refer to17

[11], Section 2.15.5.8, Inter-PCF Dormant Handoff - Mobile Continues to be Served by the Serving18PDSN.19

i. The A11-Registration Request message is validated and the PDSN accepts the connection by20returning an A11-Registration Reply message with an accept indication and the Lifetime set to the21configured T rp value. If the PDSN has data to send, it includes the Data Available Indicator within the22CVSE. The A10 connection binding information at the PDSN is updated to point to the target PCF.23The target PCF stops timer T regreq .24

j. The PDSN initiates closing of the A10 connection with the source PCF by sending an A11-Registrat-25ion Update message. The PDSN starts timer T regupd .26

k. The source PCF responds with an A11-Registration Acknowledge message. The PDSN stops timer27Tregupd .28

l. The source PCF sends an A11-Registration Request message with Lifetime set to zero, to the PDSN.29The source AN/PCF starts timer T regreq .30

m. The PDSN sends an A11-Registration Reply message to the source PCF. The source PCF closes the31A10 connection for the AT and stops timer T regreq .32

n. Assuming the Data Availability Indicator was not present in step i, the target PCF responds to the33target AN with an A9-Release-A8 Complete message. The target AN stops timer T A8-setup . Note that34this step can occur any time after step i.35

o. The AN may initiate HRPD connection release. Refer to [10], Section 6, Connection Layer.36

37

38


39/126


3-19

3.7 Active HRPD Session1

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

3.7.1 AN Detects a Loss of the Airlink During an Active HRPD Session3

This scenario describes the call flow associated with an AT detecting an airlink loss during an active4 HRPD session.5

Tald9

AN PDSNAT

a

time

c

e

AN loses the airlink to the AT

f

b

PCF

Tairdrop A9-AL Disconnected Ack

A9-AL Disconnected

Active HRPD Session

AN detects the airlink to the AT

Talc9A9-AL Connected Ack

A9-Al Connected

d

6

Figure 3.7.1- 1 AN Detects Loss of Airlink During Active HRPD Session7

a. The AN determines that it is not receiving any transmissions from the AT and starts timer Tairdrop

.8

b. The AN sends an A9-AL Disconnected message to the PCF to stop data flow and starts timer T ald9 .9

c. Upon receipt of the A9-AL Disconnected message, the PCF sends an A9-AL Disconnected Ack 10message to the

Documents

A.S0008-0_v3.0_callflow_evdo